ﾃﾞｯｻﾞｲﾝ超重視ならさておき、 markdown から生成する程度の文字メインなコンテンツでフォントを弄るの本当はやめてほしい
なんで文字読むだけなのにｺﾞｯｺﾞﾖのｻｯﾊﾞにアクセス履歴残してそこそこのデカさのフォント落としてこないといけないの (しかもフォント落とされた時点でレイアウトが変わるので読んでた位置がずれる)

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

っ【アカシックレコード】

真面目な話をするとそんなものはたぶんないので、標準的なデバッグやトラブルシュートのテクニックと、バグトラッカーやナレッジベースの検索に慣れるしかない

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

そもそも「Linux」と人々が呼んでいるシステム、様々な人が別々に作ったソフトウェアの集合体だからね (だから Linux “ディストリビューション”)

Linux kernel に問題があると確信しているならそっちの開発とか追っかけしてるプロに聞けばそれなりの情報は得られるだろうけど、そうでないならまず「どこに問題があるか」から始めないといけないし、それは構成次第としか

だいたい Windows みたいに企業サポートレベルのものが欲しいなら、 RedHat の顧客になるとかするしかない (つまり他人を使うなら金は大事)

バーチャルイベントプラットフォーム運営のクラスター株式会社　総額8.3億円の資金調達実施｜クラスター株式会社のプレスリリース
https://prtimes.jp/main/html/rd/p/000000078.000017626.html

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

署名あたりのあれこれと、インスタンス種別のキャッシュ (これはクライアントとか外部サーバの問題) がどうにかなるならどうとでもなるのでは

知らんけど

眠い……

布団から出ます

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

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

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

RSA の功罪よな……

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

これは実際そうで、「暗号鍵」「復号鍵」「署名鍵」「検証鍵」という言葉があるので使い分けた方が明確ではある

実際 PGP とかでも、 ECDH 鍵対は暗号化・復号のみに使えて、 EdDSA 鍵対は署名・検証のみに使えるなど、暗号化と署名それぞれにしか使えないアルゴリズムなどあるので

latest kernel のバグ踏んでつらいマンとしてもな……

5.5 はよ……

@motorailgun https://mstdn.anqou.net/@anqou/103440649232700806

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

どうでもいいけど

平文 → [暗号化] → 暗号文
暗号文 → [復号] → 平文

この非対称性がいつも微妙に気に入らないのでモヤっとする (まあ仕方ない)

そもそも「平文 (ひらぶん)」も何やねんという感じはあるけど

暗号社員を復号すると平社員になる #適当

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

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

というか diff がテキスト特化なだけで一般的な差分アルゴリズムはバイナリにも普通に適用できる (表示は難しい) し、なんなら「x86 の機械語について効率よく差分をとれる」みたいなアルゴリズムもあったよね

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

これ正解

コミットメッセージの規約、 README とかで表明されている場合もあるし、ツール使ってる場合もあるし、人手でやってる場合もあるので場合による

コミットメッセージから CHANGELOG 生成するユーティリティみたいなのもあるので、そういうの使ってたらちゃんと形式合わせないとよろしくない

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

fork するか否かって git リポジトリとしては本質的に全く差異がないはずだけど…… (アクセス権程度の違い)

そもそも git が「分散型」VCS だというのは、コミットが所属リポジトリの名前や URL ではなく中身のデータと過去の歴史でのみ識別されるということ。
つまり、全く同じ履歴を共有した同一のコミットから派生したふたつのブランチを merge する操作は、リポジトリの実体や URL が同じだろうが別だろうが内部的には全く同じなので差異はない

ありがちなミスとしては、 fork 先のリポジトリで upstream の master とかをちゃんと pull してこないまま、古いコミットから新たなブランチを生やして……みたいなことをしてしまうケースがある。
この場合はだいぶ昔のコミットからブランチを生やすことになるので若干の混乱があるかもしれない

まあこれもローカルで git pull しないままブランチ生やしてリモートの (ローカルより進んだ) master とかに merge しようとしたときに起きることと同じだし、 fork かどうかは全く関係ない

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

https://qiitadon.com/@yume_yu/103440747299095961

そういうことだったっぽいですね

それはそれとして私は git-flow (あるいは類似のブランチングモデル) の信奉者なので、 fast-forward はあまり使わない (fast-forward 可能でもデフォで merge commit を作るようにしている)

pull のときは標準で fast-forward のみ受け入れにしてるけど (それはまあそう)

Synology の NAS で docker 使って IPFS companion に HTTPS と Basic Auth を使わせたいんだけど、どうも docker-compose か何か使うなりしないとコンテナ単体では無理っぽいので悲しくなっている

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

SUSE はありまSUSE #適当 #文脈を大事にしたジョーク

いやあるか知らないけど (何の話かさえ知らないけど)

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

納豆wwwww

FSF の納豆要素は soybeans と social beings をかけたものであり云々 #適当

適当発言のプロです (適当)

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

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

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

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

signing key も encryption key も public key の部分集合 (のはず) だから、まあ間違ってはいない……

@tacumi 秘密鍵を秘密にしろということだけ知っておけば最低限の利用はできるというのは、まあそうだと思います (そういう理解の人々がどれだけ実効性のある秘匿をするのかはさておき)

私なら絶対謝罪とかしなかったと思うので、まあ腰が低いなぁというか学級会文化の一部だなぁというか

もしかして「AGPL サービスのソースコード開示を渋ることで OSS コミュニティの和を乱した」みたいな話した方がいい？ (超適当)

例の謝罪が強要されて出たものでないなら、べつにそれ自体を理由に誰かを批難する必要もないとは思ってるけど (それはそれとして学級会文化の助長はｳｰﾝという気持ちになるけど、私が参加しなければいいだけの話なので無視)

まあ他人のことはいいんですよ、自分が気に入らない文化の一部にならないことが大切

うぅ……プロプライエタリソフトウェアを書いて飯を食っていく人生……ううぅ……

どぼじで……

非対称鍵暗号と署名技術は別物！ RSA とかの一部アルゴリズムはたまたま都合の良い性質を持っているだけ！！

RSA 、アルゴリズムとしてはわかりすい部類だけど、あれが標準だと思うとだいたい余計な (都合の良い) 性質が沢山付いてるのでよくない

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

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

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

そのとおりのはずやで (ただし、改変に関連する日時と作者の表示が云々 (つまり ChangeLog の同梱) というのも要件に入ってたはずなので、手動で changelog 書く気がないなら git repo だったり git log なりを公開する必要がある、はず #TINLA

たとえば GNU の orgadoc というプロジェクトにはこんな感じの ChangeLog ファイルが入ってるんですが、これ書くくらいなら git log を各自で参照してもらった方が楽じゃないですか？

つまりそういうことです

とはいえ、要件を満たしていればいいわけで、「GitHub (や類似のサービス) で git リポジトリ自体を公開しなければならない」は嘘のはず #TINLA

OrgaDoc - GNU Project - Free Software Foundation
https://www.gnu.org/software/orgadoc/

orgadoc は document を organize する感じの文書管理スクリプトです

> GNU OrgaDoc is designed to easily copy and maintain a pool of documents between computers. You can synchronise your documents pool with rsync or unison. You only need OrgaDoc to generate html (or other formats) pages

lo48576-graveyard / 2019-fft-exercise
https://gitlab.cardina1.red/lo48576-graveyard/2019-fft-exercise

これ https://mastodon.cardina1.red/@lo48576/102656009069189632 で遊んでたときの墓石を立てた

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

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

そういや STK 1.0 リリースされたんだっけ (だいぶ前の話か)

lo48576-graveyard / 2019-fft-exercise
https://gitlab.cardina1.red/lo48576-graveyard/2019-fft-exercise

牛角「1万1000円で焼き肉食べ放題」の定額パス、急きょ販売終了に　予約殺到で来店できない状況に（ねとらぼ） - Yahoo!ニュース
https://headlines.yahoo.co.jp/hl?a=20200107-00000074-it_nlab-bus_all

予定調和バイラルマーケティング大成功じゃん

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

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

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

そうなの！？

STK したいなぁと思いつつ放置している、まだまだ Portal でやることがあるので ()

修論！！！！

CD 何で焼いてたっけなぁ……

そうだ私は gnome 系使ってたので brasero だったわ

Burningミュージックをリリースする機運が (???)

github/dmca: Repository with text of DMCA takedown notices as received.

また使いやすそうなデータが……

sony/sonyflake: A distributed unique ID generator inspired by Twitter's Snowflake
https://github.com/sony/sonyflake

おい Sony wwww

ブランドで遊ぶの本当にずるい

古事記 (Arch wiki)

https://wiki.archlinux.jp/index.php/%E5%8F%A4%E4%BA%8B%E8%A8%98

Gentoo Linux はいいぞ

裏で何が起きているかわからないのは初心者向けではないし、何かが起きたら詰んで問題を解決する手がなくなるのも初心者向けとはいえない。

その点 gentoo は完璧ですよ

「このパッケージバグっとるやんけ、古いバージョンをｲﾝｽｺしとこ」とかできるんやで

特殊なリポジトリとかの導入なしに。標準で。

何かあったとき大抵どうにかできるという点で、 gentoo は大変信頼できる

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

Emacs は OS 原理主義者だ！！！

Emacs is a great operating system, lacking only a decent editor.

べつにビルドしてる間なにもできないわけじゃないし……
あとメモリ余ってるなら tmpfs でビルドすると爆速になりますよ (文字通り)

I/O がボトルネックだったのがメモリの速度になって CPU がボトルネックになるからね、本当に早くなる

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

LinuxFromScratch 、「パッケージマネージャとリポジトリがないだけ」程度の話なので、どうしても LFS にする必要があるのでもないなら PM とリポジトリ自作して distro 作ろうとでもした方がよほど面白いと思う

全てを /usr/local に入れようとするようなもんでしょ LFS (殴られそう)

いや distro のメンテナが独自に当ててたりするパッチとかは自分で入手してくる必要があるか。でもパッチ拾ってきて当てたいだけなら gentoo でもできるよ…… (???)

パッケージマネージャならﾁﾏﾁﾏ作っていけば実際動くものは作れるんだろうけど、本当に面倒なのはパッケージリポジトリのメンテナンスでしょ

最小機能なら依存の事前チェック (依存解決ではない) とファイル展開とインストールスクリプト実行・アンインストールスクリプト実行程度の機能があれば十分だろうし。
でも依存の自動インストールとかしようとした瞬間、すべての関連パッケージがリポジトリに存在していることを要求され……

ｽﾏﾋｮにｷｰﾄﾞｰﾎﾞ繋いだことないのでｽﾏﾎｮで SKK 使ったことなし

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

autoconf のビルドに make が必要で make のビルドに autoconf が必要系の話、たのしい (?) (記憶が朧げ)

まあバイナリ配布のリポジトリならビルド時の依存はひとまず考えないことができるので

-dev と -devel の話は……

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

not HD とか (jargon)

rust コンパイラのブートストラップの話するか？

thepowersgang/mrustc: Alternative rust compiler (re-implementation)
https://github.com/thepowersgang/mrustc

Rust コンパイラが Rust で書かれてて困るので、 reproducible build 界隈の人が何をするかというと、

* C++ 製の不完全な Rust コンパイラで rust 1.19.0 をビルド
* ビルドされた rust 1.19.0 で rust 1.20.0 をビルド
* 1.20.0 で 1.21.0 を
* 1.21.0 で (以下略)

Bootstrapping Rust — 2018 — Blog — GNU Guix
https://guix.gnu.org/blog/2018/bootstrapping-rust/

リポジトリを見る感じだと今は 1.29.0 からビルドできるようになってるっぽい？ すごいなぁ

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

今だと GCC も C++ で書かれているので、ブートストラップには C で書かれている古い時代の GCC から上げていく必要あるはず (複数バージョン飛ばして上げられそうではあるけど)

C コンパイラくらいなら頑張れば書けるので、まあそれでいいよねという感じ

gentoo で詰んだことないよ

まあ texlive あたりとかは昔は結構面倒だったけど……

デフォがどうかは知らないけど、たしか systemd フラグの立った stage 3 が配布されているので、たぶん最初から journald ですねその場合は

gentoo は選択です

stage 3 のビルドはさすがにやったことない (どうせ stage 3 落とした後 gcc ｱｯﾌﾟﾃﾞｰﾖして emerge -e @world するのでバイナリ全部入れ替わるはず)

icedtea のブートストラップはクッソ面倒で泣いた (idcedtea-8 のビルドに icedtea-7 か icedtea-bin-8 が必要で、 icedtea-7 をビルドするには icedtea{,-bin}-7 か gcj が必要で、 gcj はもう masked でしかもファイル足りなくて動かない)

Add dev-java/gcj-jdk · lo48576/lo48576-portage-overlay@34c738c
https://github.com/lo48576/lo48576-portage-overlay/commit/34c738cb63f1e81d9d000510b1f6e217c3faaddf#diff-20ab6e40f22f7ba8dcbe23782285a7de

これはその名残り

Dvorak 配列はいいぞ

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

あとアルペジオ打鍵とかも複数の指が同時に動かないとパフォーマンス上がらないので、親指だけで打つには不便なのでは >Dvorak

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

自分で権利持ってないものをアイコンに使うの、普通にこわくない？
私はこわいのでいつでもアイコン変える覚悟してるし、永続的に使うリソースは絶対自分で生成すると決めている

べつに OSS みたく「いかなる主張や行動についても、利用を制限されない」という極めて許容的なライセンスのかわいい女の子アイコンとかモデルがあったらそれ使うんですが、まずないでしょ。
だいたいそういうのは宗教に使うなとか良識がどうとか「非商用なら」とか、そういう曖昧だったり制限強いものばかり (べつにそれが悪いと言っているのではない)。

これでアイデンティティを完全に載せる気になれるわけないじゃない？

誰が悪いとかではなく、マジで「自分で優先的な権利を持つしかない」という話で、これはアイコンやアバターに限った話ではなく何にでも言えること (だからこそこうして Mastodon サーバを立てている)

おえかきできるマンはその辺り強いよなぁ。アイデンティティの表現がしやすい

プログラムは基本的にアイコンにならないからなぁ