コグノスケ

独自のaptサーバー - その1 - ディレクトリ構成

目次: apt

会社で独自のDebianパッケージを配布する際に、難しくてかなり困ったので、下調べの結果を兼ねてメモしておきます。

やりたいこととしては、独自に作成したDebianパッケージ（*.debファイル）を、

• 複数のOS: Debian, Ubuntuなど
• 複数の版: stable, testing, nightlyなど
• 複数のアーキテクチャ: amd64, arm64など

この3つをどのように組み合わせても対応できるような、ディレクトリ構成と、aptサーバーの設定を作成することです。

Dockerが参考になる

ディレクトリ構成は、最初から考えるのは大変なので、参考としてDockerのaptリポジトリ（リンク）を見てみます。

debian/
    dists/
        buster/ : Debian 10.0
            edge/ : なんだろ？
            nightly/ : 1日ごとにビルドされた版
            pool/ : *.debが入っているディレクトリ
            stable/ : 安定版
            test/ : テスト版？
        jessie/  : Debian 8.0
        stretch/ : Debian 9.0
        wheezy/  : Debian 7.0
    gpg : GnuPGの公開鍵、apt-keyで追加する

ubuntu/
    dists/
        artful/  : Ubuntu 17.10
        bionic/  : Ubuntu 18.04 LTS
        cosmic/  : Ubuntu 18.10
        disco/   : Ubuntu 19.04
        trusty/  : Ubuntu 14.04 LTS
        xenial/  : Ubuntu 16.04 LTS
        yakkety/ : Ubuntu 16.10
        zesty/   : Ubuntu 17.04
    gpg : GnuPGの公開鍵、apt-keyで追加する

こんな作りになっています。debian/distsもしくはubuntu/distsの下に各バージョンのコードネームが並んでいます。例えばdebian/dists/busterであればDebian 10.0用です。

コードネームのディレクトリの下には、各版stable, test用のディレクトリが並んでいます。poolディレクトリは版名ではなくて、パッケージファイル *.debを格納するディレクトリです。

debian/
    dists/
        buster/ : Debian 10.0
            edge/ : なんだろ？
            nightly/ : 1日ごとにビルドされた版
                binary-amd64/ : PC, 64bit用パッケージ情報
                    Packages   : パッケージ一覧
                binary-arm64/ : AArch64用パッケージ情報
                binary-armhf/ : AArch32用パッケージ情報
                Contents-amd64 : PC, 64bit用
                Contents-arm64 : AArch64用
                Contents-armhf : AArch32用
            pool/ : *.debが入っているディレクトリ
                edge/ : stableと同じ構成
                nightly/ : stableと同じ構成
                stable/
                    amd64/ : PC, 64bit用 *.deb
                    arm64/ : AArch64用 *.deb
                    armhf/ : AArch32用 *.deb
                test/ : stableと同じ構成
            stable/ : 安定版
            test/ : テスト版
            InRelease   : GnuPGの署名が追記されたReleaseファイル
            Release     : Contents, PackagesのSHAハッシュ一覧が書かれたファイル
            Release.gpg : GnuPGの署名だけ書かれたファイル

Debian向けとUbuntu向けはほぼ同じ構成です。

ヘッドフォンの謎のノイズ

オーディオは専門ではないし、神の耳も持っていないので、細かい音質うんぬんは全くわからないし、高級○○ケーブルなどはオカルトの一種とすら思っていますが……。

音質で唯一体験したことを思い出したので、メモしておきます。

以前はテレビのファーム開発をしていたため、職場ではテストのために少し良い（1万円〜2万円レベルの）ヘッドホン（SHURE SRH440-A）を使っていました。

何も鳴らしていないのに、ヘッドホンからたまにブーン……という微かなノイズと、バリ、バリ！という大きめのノイズが聞こえていました。

スマホとヘッドフォン

最初、評価ボードか機材の故障を疑っていたのですが、なんと原因は自分のスマホでした。

前者のブーン……ノイズは、ヘッドホンのケーブルをくるくると丸めて束ねた上に、スマホを置いていたため、スマホの電波を拾ってノイズになっていたようです。

たまにしか鳴らないのは、パケット通信のときしか強く電波を発しないからですかね？スマホを机の上に置かないようにしたらノイズは聞こえなくなりました。

家の安いヘッドホンで同じことをしても、ノイズは聞こえなかったので、感度の良いヘッドホンじゃないと拾わない（？）のかもしれません。

後者のバリバリ！ノイズは、ヘッドホンアンプの上にスマホを置きっぱにしたときに鳴っていました。ノイズを増幅するのか、かなり目立つバリバリ音が聞こえていました。

これもスマホとアンプを遠ざけて置くことで、ノイズが消えました。

謎が解ければ何てこと無い原因でしたけど、最初はわからなくて、このヘッドフォン壊れているんだろうか？不良品かしら……？とか思っていました。冤罪でした、ごめんねヘッドホンさん。

タチの悪い内蔵音源

音質でもう一つ思い出したのが、先代ノートPC（ThinkPad Edge E420）のアナログオーディオ出力は、常にシューシューというノイズが聞こえていたことです。

2010年は遥かに過ぎて、こんなにノイズが鳴るオーディオがあるはずない、聞き間違いだろうと思いきや、安物のオシロで見てもすぐわかるくらいノイズが載っていてショックでした。Conexantさん勘弁してよ……と思いました。

測定結果は、以前の日記に書いています（2014年10月18日の日記参照）。あれからもう五年も経ったのか。早いものだ。

メモ: 技術系？の話はFacebookから転記しておくことにした。リンクなどを追記。

RISC-V原典

RISC-V原典という本も買って読んでいます。どちらかというと頭から読む本ではなく、辞書的な本です。命令一覧の章はとても便利ですね。

RISC-V原典では「過去のアーキテクチャが患ったインクリメンタリズム」と他のアーキテクチャの複雑さを評していましたが、RISC-Vは出来たばかりなので「今」シンプルなのは当然だよね……などと思ったりしました。

RISC-Vと昔のARM

RISC-Vは命令セットの独自拡張を許しているため、同じRISC-V CPUを名乗っていても「A社CPUとB社CPUでは、同じバイナリが実行できない」ことがありえます。

ARMやx86も互換性のないCPUは存在しますが、共通の命令セットが大きいためあまり問題にはなりません。一方RISC-Vは共通命令セットが小さい（RV32I、MMUなしのマイコンレベル）ので、非互換性で問題が起きそうですね。ARMでいうとCortex-A系とCortex-M系を混ぜて売るようなもので、混乱を招きそうです……。

このタイプの命令拡張方式で私が思い出したのはARMです。ARMも昔はARMv5TEJのように、対応する拡張命令をアルファベットで追記する、似たような方式を採用していましたが、ARMv6で拡張命令に全て対応したため、拡張命令方式は消滅しました。

未来予想

私の予想としては、スマートフォン、デジタル家電、PCのような、比較的高性能な分野にはRV64GC（G = IMAFD、multiple, atomic, float, double）が共通命令セットになり、マイコン系にはRV32IかIMくらいが共通命令セットになる、辺りが落としどころかなと思います。

RISC-Vも「インクリメンタリズム」に陥る未来は避けられず、拡張に次ぐ拡張でゴチャゴチャになる未来を迎えると思いますが、20年後、

• RISC-Vがそもそも使われているか
• RISC-Vは今と同じことを言えるくらいシンプルを維持できるか
• RISC-Vが別のアーキから同じ欠点を指摘されていないか（歴史は繰り返す…）

期待が大きいだけに、将来的にどうなるか、楽しみです。

強いオセロ

どうやっても圧勝してしまう「最弱オセロ」（リンク）が話題ですが、実はその横に「強いオセロ」（リンク）もあります。URLから推測するにこちらの方が先に作られたように見えます。

名前に偽りはなく、ものすごく強いです。私のような素人の実力ですと50石（ほぼ真っ白）〜64石（全て白）で完敗します。終盤に一気にひっくり返され、全く勝てません。

まともにやっても全く勝てなかったので、どんな手でも良いから、1度でも勝てないだろうか？と試行錯誤するうちに、ちょっとしたクセが見えてきました。このAIは「終盤の大逆転」を重視していて、序盤〜中盤は石数が不利でも無視する傾向があります。

このクセを逆手に取り、中盤戦でとにかくゴリ押しして、白を全滅させる作戦を取ると、ごくたまに勝てることがあります。下記はその例です。

中盤でゴリ押しして勝てたケース

中盤で押し切れなければ負けです。20〜30局やりましたが、これ以外の勝ち方はできませんでした……。