@monyoNERVA
一方 Rust では、

```Rust

struct Point {
x : i32,
y : i32
};

let coordinate : Point = { x : 0, y : 42 };

let a = coordinate;
a.x = 8;
coordinate.x = 3; // compile error! 所有権が a に移動済みのため
```

:- )

@monyoNERVA たとえば kernel が GPU のようなデバイス資源を管理するとき、デバイス資源に紐付くメモリ上の構造体は別に複製されていろいろな人が持って欲しいとはあんまり思わないため

@monyoNERVA あと、C や C++ なら、

```C++
Point a = { 0, 42 };
Point b = a;
a.x = 8;
b.x = 3;
```

のように基本は動作はコピーなので、まあこれはこれで悪いってわけじゃないしコンパイラの最適化次第では実際にはコピーにならなかったりする代入もあるけど、プログラマの予期しない複製が発生して困る、とかもあるときにはある

@monyoNERVA

```C++

struct {
int x;
int y;
} Point;

Point coordinate = { 0, 42 };
Point *p_point_1 = &coordinate;
Point *p_point_2 = &coordinate;

p_point_1->x = 8;
p_point_2->x = 3;
```

C++ だとこういう風にポインタ張ればアクセス元いくらでも増やせるけど、たとえばこの p_point_1 と p_point_2 がそれぞれ別のスレッドで作られてたら、事故るのは容易に想像付くわけです

@monyoNERVA 所有権 (ownership) はその部分ではなく、資源へのアクセス権利のことですね。ある資源に対し owner（所有者）が居ると考えたとき、owner 以外のアクセスができないような概念を構築することで、資源へのアクセスの競合が起きないようにするとか、うっかり共有してしまうことで起きる事故を防ぐとか、そういった部分が主眼

@monyoNERVA それは単に GC の話で、たとえば確保した領域にアクセスするラベルの数をカウントしておいて、誰も参照しなくなっていたら（カウントが 0 なら）解放する、というアルゴリズムが参照カウンタと呼ばれる。C++ だと shared_ptr というスマートポインタで実現できるけど、概念は比較的簡単なので C でもサクっと実現できたり。ただしスマートポインタの管理外で勝手に生ポインタ張って後で参照カウントが 0 になってリソースが解放されたとき、生ポインタが残っててダングリングポインタ化するとか、これは Rust でもそうだけど循環参照の解決がむずかしいとか、問題はある

This account is not set to public on notestock.

This account is not set to public on notestock.

@monyoNERVA move semantics や所有権はメモリとかと完全に独立した概念だよ。むしろメモリとポインタ知ってれば、あるアドレスにある値に対してラベルが複数用意すればそれぞれのラベルを通じてアクセスできる、と考えるほうが自然だと思う。（事実スマートポインタでない既存の生ポインタはそうなっているし、だからこそ C++ では unique_ptr を使って、さらに singleton のような仕組みを用意してようやくそれが実現されるわけで

Lisp、組み込みで実装しないといけない function が 8 つくらいしかないのと、あと S 式は今をときめく WebAssembly のテキスト表現でも使われてるんだぜ的なところで最近の記述に接続しやすい良さがある

This account is not set to public on notestock.

@monyoNERVA メモリやポインタわかってるひとはだいたい C わかってる説／でも問題はそこじゃなくて move semantics とかそこらへんだと思うよ

べつに forth でなくて Lisp とかでいいと思う。構文解析木作るのサボれるし

ML 系言語っぽいセマンティクスだけど記法はやや C 系の struct とかみたく書ける、みたいな落としどころになってる意味で C++ 知らずに Rust もまあ、と思わなくはないけど、Rust 特有の特徴について C++ 知ってると対比した説明がしやすい側面はある

これそもそもアルゴリズムそこまで考えずナイーヴに書いていたとしても問題に対して期待の出力が吐けるコードになってるかというと微妙そうな気がしているけど、 10 億とかじゃなくてもっと小さな 100 とか 1000 とか与えたとき手元で期待の値吐くか確認したりしてるのだろうか、とふと思った

This account is not set to public on notestock.

問題わからないからなんともだけど、めちゃくちゃ効率悪い書き方にはなってそうな気がする。直観的に

This account is not set to public on notestock.

？？？？？？？？

This account is not set to public on notestock.

This account is not set to public on notestock.

思ったより近くてわろた

私が Skeb アカウントを建てて依頼を！？

まずあっきぃさんのばーすでぇいつなんかしらんのよ

？？？？？？？？？？？

チュンカ呼びかわいいな

オンライン講義が過半を越えてるとアウト

https://www.mext.go.jp/kaigisiryo/content/000130435.pdf

Q. なんでいままではよかったの
A. べつにいままでも誰も許してはないが感染対策の名分で緊急避難的になんとなく黙認された

怒られかたが完全に遊びにきた孫に小遣い渡して怒られる祖父母のそれっぽい

大学が今年度対面講義増やしているの、全部オンラインのままだと何らかの法令上で通信制大学（放送大学みたいな）の区分になってしまうので、そのような認可を受けていない大学としては対面講義を増やすしかないなどがあると聞いている

Moxie Marlinspike >> Blog >> My first impressions of web3
https://moxie.org/2022/01/07/web3-first-impressions.html

@zgock999 @mitarashi_dango 二人して怒られる、ってところがなんかほんわかエピソードだ

This account is not set to public on notestock.

This account is not set to public on notestock.

@mzp プロだ

なぜ我々はsession.cookieを変更しなければならなかったのか - BASEプロダクトチームブログ
https://t.co/9YvTERoyV1

Public Suffix List の用途と今起こっている問題について | blog.jxck.io
https://blog.jxck.io/entries/2021-04-21/public-suffix-list.html

Git security fixes released [LWN.net]
https://lwn.net/Articles/891112/#Comments

わたしは神でも悪魔でもないんだよなぁっ

This account is not set to public on notestock.

Ans. ここのところインターネットも現実もいつも燃えていて忙しいため

This account is not set to public on notestock.

@mzp 打つ

@mzp @rinsuki http://www.brl.ntt.co.jp/J/2017/05/latest_topics_201705191427.html

マジノ線じゃなくてマンネルヘイム線で行こう

@monyoNERVA “Accepted GSoC contributors spend the summer coding with guidance from a mentor.”
https://summerofcode.withgoogle.com/how-it-works

@monyoNERVA GSoC は貢献が目的というよりは contribution を今後しようとしている人のためのきっかけ作りが目的で、GSoC の参加者にはメンターがプロジェクトから一人割り振られてメンターが参加の方法やらなんやら教えてくれる、といった流れです

@monyoNERVA ちなみに merge window の間の patch の commit message をまとめると自動的に Linux kernel の release note みたいなもの作れたりする。LWN.net なんかは merge window の度に part 1, 2 でまとめてくれるから新機能のウォッチにべんり

5.18 Merge window, part 1 https://lwn.net/Articles/888736/
5.18 Merge window, part 2 https://lwn.net/SubscriberLink/889266/f11e758b54a71766/

いまは 5.18-RC2 だけどこれが出たことも LWN みてるとわかる https://lwn.net/Articles/890940/
(RC = release candidate = リリース候補)

@monyoNERVA Go

@monyoNERVA 基本的には ML が主体で、それもみんながみてる ML ではなく基本的にはサブシステムごとの ML に投げる（なおたさんのやってる btrfs のファイルシステムならば、btrfs の ML に投げる）。
ある種サブシステムごとに独立したプロジェクトになってて、そこで patch review の遣り取りの結果 ack されたらメンテナの git のツリーに merge されて、そのあと linus のツリーに merge window が開いている間に投げて、merge されたら次の RC に入って、RC でテストして問題なければリリースされる、というサイクル。

This account is not set to public on notestock.

規模や特性や参加者次第で最適なフローとツールは異なるので、メーリングリスト開発も最近のイケてる tracker でやるのも、どっちも必要なんだなあ

なので規模ややり方によっては GitHub でやるのは間違いじゃなくて、GitHub の考える「おれの考えたさいきょーフロー」みたいなのが自分のやってるプロジェクトの規模や性質にマッチしていれば GitHub のほうがべんり、というだけなのだなあ

そのうえで、BitKeeper とか使ってたの使えなくなったから Linux の開発にフォーカスしてめちゃくちゃツール書いた結果の Git

email がインターネット黎明に Unix と共にあるため広く使えテキストで処理する手法が元から発達してる、あたりで順序が逆だと思う

そうですね……

This account is not set to public on notestock.

コルモ・ザ・アサシン

This account is not set to public on notestock.

Git 自体そのフローに最適化されてるとこもあって、Git に bug tracker とかないしあとここも微妙！みたいなのは「そりゃそういうフローに合わせて設計してないからね」みたいなのはある。でもだからってみんな fossil とか使うかっていうとそうでもないけど

This account is not set to public on notestock.

まったく使わないわけじゃないけど、下っ端で one shot のパッチ投げるだけなら……

lkml.org とかは ML ちゃんと検索できるようにしてる

メーリスだとしょーもないやつは ggrks って返すか、そもそもスルーして見なかったことにしてそのまま押し流してしまえば残りもしなくて、その上でこれは重要だなみたいなやつだけ bug tracker とかに転記する、とかできたりはある

kernel でなくても、 人気巨大 OSS の GitHub issues って reddit でやれみたいな初歩の質問やドキュメント読めばわかる環境と設定の問題とか乱立しててあんまり見通せないことも多いのでなんともだ。bot とか導入して自動でクローズしたりいろいろ工夫してるけど

飲み込めてないじゃないか！

たぶん数人規模とかだとメーリングリストでやるのは効率微妙になりがちだけど、世界中に分散してる開発者が数千人以上は居るとかだと開発をスケールさせるのにメーリングリストは普通に考えられる手段になってしまう。べつに Google Groups とかで代替してもよいけど

ちなみにひとつ言うと、メーリングリストで開発するときべつにメーリングリストの購読リストはなにかに使ったりしないし極論メンテナとかでなければ購読する必要すらないです

いろいろあるのをぐっと飲み込んだ