JavaScript 対応の w3m かつて存在していたが今は

アムロに 3 分で 12 機撃破されたやつだよ

これすき

事実ともかくしないで

まるでわたしが人ではないみたいな言い方

いろいろなツール，歴史的な経緯で発生していると思うのでその原点や流れを追うことも必要だという考えなので Web の人が言う「今は〇〇が cool だから前時代的な ✗✗ は触らなくていい」というのあんまり信用してない

jQuery すら触ったことないのだし

フロントエンドやっぱりなにもわからない

私が見た記事だと webpack のお陰で gulp や Grunt の既述がだいぶ減ってラクになるしあるいみタスクランナーの一種みたいな書かれ方をしていたけれどもなんだか parcel とかいうのも出てるようだしなんもわからん

勘弁してくれ

webpack はもう流行ってないの？

タスクランナーとはなんぞやと調べてて「いやこれ Makefile でいいだろ」って思ってたら 2015 年頃にはそう思った人わりといたようだけどそこで Web フロントエンドの人たちが書いてた Makefile がわりと Makefile の慣習外してたりしてああッてなった

あはー，仕方ないですねぇ

インターネットがスパムとかヘンな広告で溢れはじめたのも……

このアカウントは、notestockで公開設定になっていません。

かぶばぶ粒子

@babukaru それとさっきかるばぶさんが言ってた asd を無効化してみるというのも試すと良いのかもしれない（べつの critical-chain が見えてくるかもしれないし，あるいはそもそも plot みる限りかなりの unit がほぼ同時に起動してるけどそれがかえって並列すぎて遅くなってるだけかもしんないし）

@babukaru Arch Wiki によると“/home の自動マウントによる高速化は 1 秒か 2 秒ぐらい”だそうなのでもしかしたらあんまり意味ないかもしれない

@babukaru noauto は自動でマウントをしなくなるオプションだけどこれに加えて x-systemd.automount を付けてあげると systemd が必要になったときに mount してくれるので便利

@babukaru noauto,x-systemd.automount を fstab のオプションに追加すれば，たとえばこのオプションを /home について追加すると /home を使わない service はこれのマウントを待たずにとっとと起動できるので，そういうことをすると良いと思います

@babukaru plot をみると asd は 42ms で起動できてるし asd のために色々なファイルシステムのマウントとか tmpfs の準備とかを待とうとしてしまってそれで遅くなっているかもしれない，systemd の起動直後にあらゆるデヴァイスやストレージの準備を一斉に開始してるし。

@babukaru で，その起動 target の ciritical-chain になってるのが asd とその asd が依存する basic.target で，basic.target は *.mount のようなストレージのマウントを待ったりする起動に最低限必要なもののための target

@babukaru unit のうち .target のものはいくつかの unit の依存先となることで複数の service や socket，device などの unit の起動を待つためだけの存在。multi-user.target はマルチユーザーモードで起動するのに必要な unit の起動を待つだけなので multi-user.target が何か起動してるわけではないです

@babukaru で，systemd-analyze critical-chain に出てるのがそのブートが遅い一番の原因の unit で，@ の後ろの時間は unit が起動した後の時間で，unit の起動にかかる時間ではない（systemd-analyze critical-chain で unit が起動にかかった時間 N は +Ns で表示される）

@babukaru まずクリティカルパスとかクリティカルチェーンという言葉をご存知でしょうか……。

@babukaru plot もみないとわからないけど，その service 自体の長い／短いが問題なんじゃなくてそれらが起動するのに必要な要素が問題なんじゃ（critical chain になっている以上はそれらが起動をしはじめる時間がより早ければ全体が早くなるので

systemd-analyze critical-chain asd.service とか systemd-analyze critical-chain basic.target もやってみると良さそう

critical-chain に asd や basic が出てるし，basic.target（ストレージのマウントとか）が遅い→ストレージと tmpfs を同期するサーヴィスである asd が遅い→asd が所属する multi-user.target が遅い，みたいなことなってるのでは

systemd list-dependencies multi-user.target とか，あるいは systemd critical-chain で multi-user.target の下に出てくるヤツとかに対して list-dependencies してみて，遅い target や service が何に依存して何のせいで遅くなってるのか見てみれば良いのでは

かるばぶのパラドクス

じゃあ systemd-analyze plot で図示するとか

あと一番遅い原因は systemd-analyze critical-chain で探せる

systemd-analyze blame してみては

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

Blender って 2.49 から 2.5.x になったときすごいモダンな感じになってびっくりしたよね

decimate しよう

いい

このアカウントは、notestockで公開設定になっていません。

なぁに

おるみんさんだよ

17 歳だから関係なさそう

ときわ書店とは

ローポリゴンモデルの強い味方，テクスチャマジック

ホーム画面のテクスチャをシェーダーかなんかで屈折させてる風にしたのをベイクするとか

液晶画面部分を一回り小さくして透明で屈折率のあるポリゴンを一枚被せるとか

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

仮想通貨 Watch 創刊の挨拶 - 仮想通貨 Watch https://crypto.watch.impress.co.jp/docs/common/notice/1121931.html