引き続きgithubへの「ミラーリング配信」は行います。issueもgithubの方へ書いて頂いて大丈夫です。

Forgejo とは何か

見た方が早いでしょう。githubみたいな、だけど自分のサーバでも動かせる何かです。

公式サイト：Forgejo – Beyond coding. We forge.

(2024/02/10 追記) 翻訳始めました

#74 – [AGREEMENT] ledyba application to the localization team – forgejo/governance – Codeberg.org

翻訳する人がいないなら…もう自分でやるしかないじゃない！あなたも！わたしも！

なぜ移行したのか

まぁ突き詰めると「最近のGithub、なんか『違う』な」ってだけなんですけど、ためしに列挙してみましょう。全部は無理だと思うけど。

倫理観や定義がグローバル基準ではない

サンプル画像として用いている弊サークルのイラスト（複数）が、githubではないものの、海外のイラストサイトから「児童ポルノ」という事で実際にBANされた事がありました。わたしたちは、「児童」も「ポルノ」も、描いてるつもりは、ないのですが…？ 小説、レシピ、（作曲した）曲、3Dモデルなど、一般的には「ソフトウェア」とは呼ばれないであろうジャンルのリポジトリもあります。これらすべてについてまで「グローバル基準」な倫理の判定を行われた際に、違反しない自信がありません。以前でしたら「どうせそこまでチェックしてないし、技術的にも資本的にも無理だし、まぁいいか」でしたが、なんでもかんでもTokenにして「AI」と書かれた脳みそのイラストにすべてが放り込まれ、「生産性の向上」「ソフトウェア・サプライチェーンのセキュリティ」なるものがひたすらに叫ばれる昨今、雑に機械で判定されてBANされてしまう危険性は高まっていると感じています。利用規約でも「わいせつ」なものはダメだと書いてあります。その定義をよんでも、わたしには、何が何だか、さっぱり意味が分かりませんでしたが…。

まぁ、わたしのアカウントがBANされるまでなら「バックアップしとけバーカ」で終わるのですが、参照されてしまうと、使っている人も困ってしまいます。オープンソース、ですからね。そんなわけで、弊サーバでホストしつつ、githubへのミラーリングという二段構えの構成をとることとしました。

Githubが寡占しすぎで怖い

なぜ人は寡占をすると付け込まれる事を覚えないのでしょうか。mixiもTwitterも、IE6も、もう忘れたか？

寡占したら次に始まるのは何でしょう？

そう、ロックインですね。まだ逃げ出せる今のうちに、移行しておかなければ、という気持ちになったので、えいやっ！とやりました。

Github Copilot 押しが、あまりにもきな臭く感じる

右上の “Code 55% faster with GitHub Copilot” にご注目ください。

これ料理のレシピですよ？これ55%速くなります？Githubくんは、適当な事を、書いてるだけですよね？Github Copilotくんが料理を作って味見して「おいしい料理のレシピ」を、ぼくの倍速で作ってくれるんですか？

どうも観察すると、Rustだろうが、PHPだろうが、6502のアセンブリだろうが、Cubaseのプロジェクトだろうが、55%速くコーディングできるそうです。

• tiny-ray.rs/src/render.rs at magistra · ledyba/tiny-ray.rs
• kotoba.php/kotoba.php at magistra · ledyba/kotoba.php
• Cycloa/roms/thwaite-0.03/src/cutscripts.s at magistra · ledyba/Cycloa
• cold_rhyme.cubase/cold_rhyme.cpr at magistra · ledyba/cold_rhyme.cubase

アポロ11号のカルマンフィルタの実装も、もちろん、Github Copilot を使えば55%高速に書けるとPRしています。アポロ11号がギリギリ60年代の1969年に着陸して「遅延」したのも、NASAはGithub Copilotへの課金をケチった馬鹿野郎の集まりだからなんでしょうかね？

kotoba.phpには色々な人の、人生に裏打ちされ、丹精に込めて紡がれたであろう、そんな言葉が、たくさん含まれています。これら言葉も、みな、”Code 55% faster with GitHub Copilot” なのだそうです。ほんと、いい加減にしろよ。

• GitHub、Copilotの将来像となる「Copilot Workspace」発表。人間がコードを書くことなく、Copilotが仕様作成からコード作成、デバッグまで実行。GitHub Universe 2023 － Publickey

これがもしできて、そして、これにお金を出せる酔狂な人は、ぜひ「Copilot Workspace自身」と「仕様を明瞭に記述」したとき、その通りに出力してくれたか教えてください。できたら、あともう料金払わなくてすみますよ。そうじゃなかったら？詐欺だよね？やっぱりもう料金払わなくて、いいよね？

「Git版Fediverse」であるForgefedに期待だ

さて、このforgejo、設定次第ではあるのですが、今建てたインスタンスではユーザー登録は基本的に管理人しかできません。２人ユーザーがいますが、わたしがアカウントを払いだしました。するとgithubのように「ふらっとやってきた人が、不具合を報告していく、直していく」とか、そういう事は基本的にできません。まぁ、それも、ほんとうに、「ごくたまに」しか、発生しないし、いや、でも、昔は掲示板でも置いとけばアカウント登録なんかしなくても不具合の報告ぐらいは、できたんですけどね。そもそもforkボタンなんか押さなくたって、gitコマンドがあればforkはできますし。よくわかんないや。

まぁいいや。しかしながら、たまには誰かが開発に参加してくれたりするのも、事実でございます。

まぁメールでもブログのコメント欄でも、連絡をくれればアカウント作るぐらいはできますよ。実際、それで十分な時もあります。それでも敷居が高い？しょうがないにゃあ・・。いいよ。そんな時の仕組みとして、今頑張って開発されているのがFederation機能、通称ForgeFedです：

プロトコルないし理念：

• ForgeFed

実装：

• #59 – [FEAT] implement federation – forgejo/forgejo – Codeberg.org
• Support federated pull requests · Issue #184 · go-gitea/gitea
• Federating GitLab through ForgeFed-ActivityPub (#30672) · イシュー · GitLab.org / GitLab · GitLab

短文ブログに比べればかなり機能は多く、実装は難しいものの、歩みも熱量もゼロではありません。技術的にも原理的にも、不可能ではないことも分かり切っています。そのうち、なんとかなるんじゃないかなと思っています。

短文ブログのFederationがはやり始めてから、7年になろうとしています。たしかに「メインストリーム」には、なっていないかもしれませんが、だからこそ、穏やかに続いている。そんな印象です。オープンソースでfederationが出来ても、あるいは出来なくても、そんな感じに落ち着くんじゃないでしょうか。これはわたしの「夢」も半分、なのかもしれませんけどね。

Github”なんか”おっせーよなぁ

forgejoの方が速いよなぁ：

帰ってVPSでforgejo建てようぜ

• 7io-org/code-compose: Compose forgejo & postgresql – ledyba.org

githubからのbackupには、次のgithubにあるスクリプトを使わせてもらいました：

• maxkratz/github2gitea-mirror: Mirror GitHub single repos/users/orgas/starred repos to a Gitea or Forgejo instance.

githubを以てgithubを制す。バイドを以て、バイドを制す！

まぁ一周しただけなんだけどね

昔は同じドメインに建てたSVNサーバ使ってました1：

git-svn-id: http://ledyba.org/svn/src/Applications/ServerSideWebApps/buffalin@1 74a9cb86-dd52-4021-9b0c-c77737e5d92d · aec3b4320d – ledyba/Buffalin – ledyba.org

githubくんはもう忘れちゃったそうですが

「GitHub」で「Subversion」プロトコルのサポートが終了 – 窓の杜

1. たぶん自作サーバですね。そのうちVPSも厳しくなってきて、自宅サーバに戻るかもしれません。ただ、いつまで家に公開IPv4/v6アドレスが来るのだろうか…。 [↩]

お久ぶりでございます。最近はUnityでfloatと格闘しております（趣味で）。

ふと気になったのが、「ところで、floatの32ビットの中にNaNって何個ぐらいあるんだろう？」。

そんなわけで数えてみました。

ソースコード

#include <iostream>
#include <cmath>

int main() {
  uint64_t normal = 0;
  uint64_t subNormal = 0;
  uint64_t positiveZero = 0;
  uint64_t negativeZero = 0;
  uint64_t neutralZero = 0;
  uint64_t positiveInfinity = 0;
  uint64_t negativeInfinity = 0;
  uint64_t notANumber = 0;
  uint64_t unknown = 0;
  uint64_t total = 0;
  std::cerr << "Start" << std::endl;
  for (int64_t i = 0; i <= 0xffffffff; ++i) {
    total++;
    uint32_t const j = static_cast<uint32_t>(i);
    float const f = *reinterpret_cast<float const*>(&j);
    switch (std::fpclassify(f)) {
      case FP_INFINITE:
        if (f > 0) {
          positiveInfinity++;
        } else if(f < 0) {
          negativeInfinity++;
        } else {
          throw std::logic_error("Zero infinity?");
        }
        break;
      case FP_NAN:
        notANumber++;
        break;
      case FP_NORMAL:
        normal++;
        break;
      case FP_SUBNORMAL:
        subNormal++;
        break;
      case FP_ZERO:
        if (1/f > 0) {
          positiveZero++;
        } else if(1/f < 0) {
          negativeZero++;
        } else {
          neutralZero++;
        }
        break;
      default:
        unknown++;
        std::cerr << "Unknown: " << f << std::endl;
        break;
    }
  }
  std::cout << "Total: " << total << "(" << (((double)total)/((double)total) * 100.0) << "%)" << std::endl;
  std::cout << "Normal: " << normal << "(" << (((double)normal)/((double)total) * 100.0) << "%)" << std::endl;
  std::cout << "SubNormal: " << subNormal << "(" << (((double)subNormal)/((double)total) * 100.0) << "%)" << std::endl;
  std::cout << "Positive zero: " << positiveZero << "(" << (((double)positiveZero)/((double)total) * 100.0) << "%)" << std::endl;
  std::cout << "Negative zero: " << negativeZero << "(" << (((double)negativeZero)/((double)total) * 100.0) << "%)" << std::endl;
  std::cout << "Neutral zero: " << neutralZero << "(" << (((double)neutralZero)/((double)total) * 100.0) << "%)" << std::endl;
  std::cout << "Positive infinity: " << positiveInfinity << "(" << (((double)positiveInfinity)/((double)total) * 100.0) << "%)" << std::endl;
  std::cout << "Negative infinity: " << negativeInfinity << "(" << (((double)negativeInfinity)/((double)total) * 100.0) << "%)" << std::endl;
  std::cout << "Not A Number: " << notANumber << "(" << (((double)notANumber)/((double)total) * 100.0) << "%)" << std::endl;
  std::cout << "Unknown: " << unknown << "(" << (((double)unknown)/((double)total) * 100.0) << "%)" << std::endl;

  return 0;
}

かなり素直なコードです。40億回ループを回しても30秒もかかりません。最近のプロセッサすごい（５年前のモデルだけど）！

少しテクニックがあるとすれば…

• std::fpclassify を使うと種類が返ってきます。知らんかった。
• ゼロが正か負か判断するために(f == -0.0)を最初書いたのですが、これは必ずfalseらしい（CLion談）ので、1で割ることでプラスマイナスどちらかの無限大に飛んでいくことを利用して判断してます。
• forでカウンターで回す限りはuint64_tを使わないとダメです。最初uint32_tにしたら0xfffffffの次が0になって無限ループになってしまいました。do while文ならuint32_tでも行けるかもしれない。
• カテゴリ多すぎだろ気が狂うわ

結果

Total: 4294967296(100%)
Normal: 4261412864(99.2188%)
Sub Normal: 16777214(0.390625%)
Positive zero: 1(2.32831e-08%)
Negative zero: 1(2.32831e-08%)
Neutral zero: 0(0%)
Positive infinity: 1(2.32831e-08%)
Negative infinity: 1(2.32831e-08%)
Not A Number: 16777214(0.390625%)
Unknown: 0(0%)

使ってる環境は次の通り：

• Ryzen Threadripper 1950x
• Windows 10 64bit、よくしらんけどこの記事の時点で最新
• コンパイラはVS2022、よくしらんけどこの記事の時点で最新

所感

ゼロと無限大はちょうど１つずつあるんだなぁというところに素直に関心しました。

非正規化数とnot a numberの数が等しいのも面白いです。なんでなのかは知らん。IEEE754の仕様書読んで教えてくれ。

IEE754はまぁまぁ複雑ですが、それでも変なケースを1%以下に抑えてるのはえらい…と言って良いのかな？

「ぼくのかんがえたさいきょうの浮動小数点フォーマット」を考えてみたくなりました。

まとめ

小学生の夏休みの自由研究でも許されなさそう

暗号学的ハッシュ関数、使ってますか。わたしはよく使ってます。たとえば、このブログでは画像のファイル名として、その中身をMD5ハッシュに掛けたものを使っています（そういうWordPressプラグインを作りました）1。

で、今日は暗号学的ハッシュ関数の中でもまだまだ現役のものの１つ、SHA256でデータが混ざり合う様を色を使って可視化してみました：

githubリポジトリはこちら：

• ledyba/visualizing-sha256:
  Visualizing how bits are mixed together in SHA256 using color.

今回はCanvas 2Dを使ってます。実際に動くデモサイト。

入力は512ビット

SHA256は入力として512ビット( = 32bit × 16)の「ブロック」を単位としてを受け取りながら計算します。今回は便宜上、１ブロックだけ与えられた事にしました。左上の「input」の下にかかれている点々（512個あります）がその入力のビット列です。ビットには、それぞれに異なる色を塗って区別できるようにしてあります。

前準備

SHA256では、次の疑似コードにそって「w」と呼ばれる2048ビットの値を計算します：

create a 64-entry message schedule array w[0..63] of 32-bit words
(The initial values in w[0..63] don't matter, so many implementations zero them here)
copy chunk into first 16 words w[0..15] of the message schedule array

Extend the first 16 words into the remaining 48 words w[16..63] of the message schedule array:
for i from 16 to 63
    s0 := (w[i-15] rightrotate 7) xor (w[i-15] rightrotate 18) xor (w[i-15] rightshift 3)
    s1 := (w[i-2] rightrotate 17) xor (w[i-2] rightrotate 19) xor (w[i-2] rightshift 10)
    w[i] := w[i-16] + s0 + w[i-7] + s1

真ん中にある「ｗ」と書かれている下の点々の塊の部分がそれです（上から下に行くにつれてiが増える方向になっています）。計算式を見ると分かるのですが、すこし前（w[i-15]とw[i-2]）の値を混ぜ合わせながら計算されているので、下の方に行けばいくほど色が似たりよったりになって、くすんでいきます。

圧縮関数

wの計算が終わったら、SHA256では「圧縮関数」と呼ばれる、次の64回のループを行います（h0〜h7は素数の平方根の小数部分だそうで、つまり定数です）。

Initialize working variables to current hash value:
a := h0
b := h1
c := h2
d := h3
e := h4
f := h5
g := h6
h := h7

Compression function main loop:
for i from 0 to 63
    S1 := (e rightrotate 6) xor (e rightrotate 11) xor (e rightrotate 25)
    ch := (e and f) xor ((not e) and g)
    temp1 := h + S1 + ch + k[i] + w[i]
    S0 := (a rightrotate 2) xor (a rightrotate 13) xor (a rightrotate 22)
    maj := (a and b) xor (a and c) xor (b and c)
    temp2 := S0 + maj
 
    h := g
    g := f
    f := e
    e := d + temp1
    d := c
    c := b
    b := a
    a := temp1 + temp2

この時に出てくる、a〜hまでの変数を右に並べました。それぞれ32ビットの値なので、32個の箱が上から下に並んでいます。ステップごとに最初はがやがやしてた色が、途中ぐらいからくすんだ紫一色になっていくのがわかります。

出力

で、64回のループが終わったら、次のコードでh0〜h7を更新して、h0〜h7を連結して256bit（=32bit ×8）の「ハッシュ」が得られる、という仕組みになっております：

    Add the compressed chunk to the current hash value:
    h0 := h0 + a
    h1 := h1 + b
    h2 := h2 + c
    h3 := h3 + d
    h4 := h4 + e
    h5 := h5 + f
    h6 := h6 + g
    h7 := h7 + h

Produce the final hash value (big-endian):
digest := hash := h0 append h1 append h2 append h3 append h4 append h5 append h6 append h7

虹色が紫になった

そんなこんなで、無事SHA256というポテトミキサーで混ぜ合わせたビット列は、元の虹色を失って、よくわからんくすんだ紫色の256個のビットとなりまあしたとさ。

なぜ紫色になるのか？

オリジナルの512個のビットの色を平均したら（80, 80, 80）になっているのは確かめたのですが、SHA256にかけてみたら（149, 81, 145）というくすんだ紫色になってしまいました。doubleの誤差のせいとかなのか、彩色ルール（後に書く）のせいなのか、そもそもそういうもんなのか、何か実装がバグってるのか、…それはよくわかりませんｗ

（一応、空っぽの入力を入れた時にWikipediaに書かれてるのと同じ値が得られる事は確認してあるので、バグではないと思うのですが…）

追記：色の塗り方の縦横を入れ替えると灰色になった

わからん、全然わからん。でもこっちのほうが見ていて楽しいですね。

参考：彩色ルール

二項演算子に関するルール

ビット同士で下記の演算が起こった時は、結果のビットの色はそれぞれの平均とする：

• add（繰り上がりが有るときは、色は３ビットの平均）
• xor
• and

ただし、定数やゼロクリアされた後のビットなどは「無彩色」とし、これらと演算するときは平均する時には考慮しない

例：

• 無彩色のビット同士で演算が行われたら結果は無彩色のビットになる
• 無彩色のビットと赤色のビットをandしたら、同じ赤色のbitになる
• 赤色のビットと青色のビットをxorしたら、結果は紫のbitになる

単項演算子に関するルール

not演算（１の補数）や単項マイナス演算(-x)、シフト演算が行われた時はビットの色の情報は変化しない。

1. MD5はもはや暗号学的には全く安全ではないそうですが、べつに改ざんの検出を行いたいわけではなく、単に重複しないファイル名を考えるのを自動でやってほしいだけなのと、出てきた結果が20バイトと大変短いことから採用しています。 [↩]