JavaScript 対応の w3m かつて存在していたが今は
「今はMIPSがクールだから前時代的なx86は触らなくていい」
「今はPowerPCがクールだから前時代的なx86は触らなくていい」
「今はRISC-Vがクールだから前時代的なx86は触らなくていい」
まあおるみんさんが触る分には何の問題もないであろうことはわかってるけど人が人だと抜け出せなくなるのが大きいみたい
いろいろなツール，歴史的な経緯で発生していると思うのでその原点や流れを追うことも必要だという考えなので Web の人が言う「今は〇〇が cool だから前時代的な ✗✗ は触らなくていい」というのあんまり信用してない
私が見た記事だと webpack のお陰で gulp や Grunt の既述がだいぶ減ってラクになるしあるいみタスクランナーの一種みたいな書かれ方をしていたけれどもなんだか parcel とかいうのも出てるようだしなんもわからん
タスクランナーとはなんぞやと調べてて「いやこれ Makefile でいいだろ」って思ってたら 2015 年頃にはそう思った人わりといたようだけどそこで Web フロントエンドの人たちが書いてた Makefile がわりと Makefile の慣習外してたりしてああッてなった
このアカウントは、notestockで公開設定になっていません。
ワニマガジン公式サイト、画像が全てワニになる緊急回避ボタンが発見され話題に 担当者「悲劇を繰り返してはならない」 - ねとらぼ
http://nlab.itmedia.co.jp/nl/articles/1805/22/news097.html
担当者：「利き手が塞がっている場合の対応をなんとかしてほしい」とご要望をいただきましたが、色んな意味で手遅れではとお答えしました。
@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 critical-chain で探せる
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Blender って 2.49 から 2.5.x になったときすごいモダンな感じになってびっくりしたよね
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
仮想通貨 Watch 創刊の挨拶 - 仮想通貨 Watch https://crypto.watch.impress.co.jp/docs/common/notice/1121931.html
