パスワードを忘れた? アカウント作成
13495947 story
GNU is Not Unix

GnuPG2のフォーク「NeoPG」、開発中 54

ストーリー by hylom
刷新となるか 部門より
osdn曰く、

PGPやGnuPGには近年いくらかの批判もありますが、開発は情熱的に続いています(過去記事:PGPの32ビット鍵IDが問題に、Linus Torvalds氏などの偽造鍵も確認されるPGPは有害無益?)。

とはいえ、GnuPGは20年以上の開発によって内部構造が複雑になりすぎています。これに伴う種々の問題に取り組むため、NeoPGという新たなプロジェクトが発足しています。

スライドによると、GnuPGは49万行のコードから成り、400近くのコマンドラインオプション、2種類のOpenPGPパーザ、自前のHTTPクライアントやDNSリゾルバ関連コードを持つ、重厚長大なプロジェクトです。NeoPGでは、できるだけレガシーコードを減らし、外部ライブラリを積極的に利用することで、開発を容易にするつもりです。スライドの時点で、すでに行数はほぼ半減し、コマンドラインオプションも120ほど減っているそうです。

ブログでは、そのほかにもautoconfではなくCMakeCPPマクロではなくC++テンプレート数多くの小さなバイナリではなく単一バイナリ長生きするデーモンではなく、すぐ終了するヘルパープロセスといった劇的な設計変更の理由について説明しています。(このうちの一部はUNIX哲学からの逸脱と見られかねないことも理解したうえで、使い勝手や開発/メンテナンスのコスト、コンピュータ性能の発達などを考慮した結果とのことです。)

ライセンスについても、GitHubのREADME.mdによれば「今のところGPLやLGPLなど様々なライセンスのコードを含んでいるが、新規コードはSimplified BSDライセンスに限っている」という書き方からして、GPLからの脱却を目指しているようです。

全体的に、ここ10年程度のトレンドを慎重に取捨選択して、そつなくリファクタリングしているように見えますが、皆さまはどう評価されるでしょうか。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2018年01月05日 16時49分 (#3340231)

    CMakeホントにいいかなあ。

    autoconfの場合、基礎的な仕組みとad hoc なルールが明確に切り分けられてて、
    後者はすべてマクロで構築されてるので、足りない部分は既存のマクロを参考に自分で用意するとか容易だけど、
    CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
    CMakeであらかじめ対応しているプラットフォーム向けは簡単な記述で済むし実行速度も速いけど、
    ちょっと想定から外れた使い方しようとすると途端に面倒くさくなって落差が激しい感じ。

    よく知らない頃は ad hoc なルールの類は全部組み込みスクリプティング言語で書いてあるかと思ってたら
    全然そうじゃないので、なんかコレジャナイ感が。

    • by Anonymous Coward

      ほんとこれ

      さらにつけ加えると互換性問題も以外と酷い
      cmake_minimum_required (VERSION 3.10.1) みたいなのがまれに良く出てくる

      ArchやGentooなどの、最新版こそ正義みたいなポリシーのディストリ使ってるならともかく
      stableって古いことだと勘違いしてるDebianみたいなディストリ使ってると、ただ単純に動かすだけでも一苦労

      ついでにいっとくと、cmake_minimum_requiredみたいなイカレたディレクティブ名からお察しできるように
      VBAでもリスペクトしてんのかっていうくらい、全てのディレクティブが無駄にバカ長い

      include_directories(${CMAKE_CURRENT_SOURCE_DIR}) とか
      ad

      • by Anonymous Coward

        CMakeFile.txt じゃなくて、もっと長い CMakeFiles.txt だよね

      • by Anonymous Coward

        たぶん同意する人は少数だよ。今時autoconfの暗号めいたキーワードを喜ぶのは独りよがりなオタクだけ。
        今は冗長でも覚えやすいキーワードにするのが主流。
        UNIXシェル環境でも、最近のCLIツールは比較的長いコマンドが多くなっている(gitのサブコマンドシステムなど)。

        その考え方を一貫して適用したのがWindowsのPowerShellという新しいシェル環境で、
        すべてのコマンドやオプションが一貫した命名規則に従っている。
        実に覚えやすく、ヘルプを見る回数が圧倒的に少ない。
        新しいコマンドの習熟もあっという間だし、しばらく使っていなかったコマンドの使い方も忘れにくい。

        • by Anonymous Coward

          省略名だと、変に寿命長いモノの場合「その名前は既に使われてます」で後半になると被ってハマるから、PowerShell的な規則の方が無難だなとは思ってる。

          かと言って古い奴は一文字でも減らして消費量減らそうという面もあったからなぁ。。

        • by Anonymous Coward

          フルネームで記述するのが最終解なのだろうと信じつつ、
          しかしやはりそのルールでコードを書いていると、
          識別名が果てしなく長大化することがあって、それはそれで悩む。
          (lintツールに関数名が長すぎると怒られて思わず唸った事も...)
          directoryとdirの混在にも若干の葛藤が見受けられる。

          解読容易なら長い分にはセーフ、という思想は、
          10年後にはもう一度再考されたルールが主流になってるかもしれない、とも思う。
          (略記の辞書定義記述が標準化される、とか)

        • by Anonymous Coward

          実に覚えやすく、ヘルプを見る回数が圧倒的に少ない。
          新しいコマンドの習熟もあっという間だし、しばらく使っていなかったコマンドの使い方も忘れにくい。

          嘘だ、ちっとも覚えられないよ、あれ。
          挙句に結果がオブジェクトだから、その仕様まで覚えてないとつらい。
          shで書く方がまだ覚えられる。おぼえなければならない量が全然違うもの。
          そりゃ日々なにがしかps書いてりゃ覚えられるだろうが、たまにしか書かないならヘルプやエディタの支援がなければ無理。
          ありゃエディタの支援有りきだよ。その分強力になってるんだから。

    • by Anonymous Coward

      菜切包丁で魚捌けないと嘆いてるような感じ?

    • by Anonymous Coward

      >CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、

      それはCMakeは関係ない。クロスプラットフォームなコードを書くときに、ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルドというのが嫌われているだけ。

      それにVisualStudio の各バージョン対応のようなものをスクリプトで前処理する方が数倍めんどくさいと思うが、そういう事やったことあって言ってる?

      • by Anonymous Coward

        >>CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
        >
        > それはCMakeは関係ない。クロスプラットフォームなコードを書くときに、ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルドというのが嫌われているだけ。

        「ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルド」の
        「特定のツール」って何のこと?
        autoconf の場合、配布されたソースをビルドするのに autoconf を含め特定のツールは必要ないと思うんだけど。
        まあ UNIX互

        • by Anonymous Coward

          え?config.h的なものを生成してビルドすることを言っててるんだと思ったんだが違うのか?
          >VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて

          というのが何を指してるのかわからん。Generatorの話ならVisual Studioは大抵古いバージョンのを指定してソリューション生成しても新しいバージョンで開いてビルド出来るし、IDE必要ないならMakefile生成して好きなコンパイラ使えばいいし。
          Makefileしか生成出来ないautoconfと何を比べてるのか解らん

          • by Anonymous Coward

            > え?config.h的なものを生成してビルドすることを言っててるんだと思ったんだが違うのか?

            違いますね。
            config.h は、-DHAVE_機能 というコマンドラインオプションを生成しているようなものなので
            全然問題ないでしょう。

            >> VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて
            >
            > というのが何を指してるのかわからん。Generatorの話なら...

            Generator の話です。
            こういう特定のツールに依存した機能を、プラグインとして分離せず CMake 本体に組み込んじゃうセンスがついていけないって話。

            • by Anonymous Coward

              特定のツール(Make)だけに依存したautoconfを持ち上げてそう言われてもなあ…

              • by Anonymous Coward

                > 特定のツール(Make)だけに依存したautoconfを持ち上げてそう言われてもなあ…

                makeはUNIXでは普遍的に存在しているし、
                UNIX どころかごくマイナーな OS でも互換実装があるし、
                もちろん Windows にもあるし Visual Studio にもついてくるし、
                それどころか MS-DOS の頃だって互換実装があったし、
                autoconf (autotools) は UNIX version 7 の頃からある make の機能にしか依存してないわけで、
                そんなの問題にする方がおかしいって感じ。

                それよりは Bourne shell その他の UNIXツール群に依存している方を問題にした方がいいと思うけど。
                もっとも autoconf は当初 UNIX系 OS しかターゲットにしてなかったから、autoconf が悪いわけではない。
                これが問題になるのは autoconf が当初の目標を越えて成功しすぎたせい。

            • by Anonymous Coward

              CMakeがVisualStudioに対応してるんだから
              それを本体に組み込もうがプラグインにしようが
              それはCMakeの勝手じゃないの?

              • by Anonymous Coward

                > それを本体に組み込もうがプラグインにしようが
                > それはCMakeの勝手じゃないの?

                もちろん CMake の勝手なんだけど、そこは最初からプラグインとして外に出しておいた方が設計として筋がいいと思うって話。
                VisualStudio じゃなくて別の開発ツールに対して同じような機能つけたくなることもあるのに、
                同じようなことするのに CMake 本体側をいじる方が簡単になるような設計方針はちょっと微妙なセンスなんじゃないかってこと。

              • by Anonymous Coward

                >VisualStudio じゃなくて別の開発ツールに対して同じような機能つけたくなることもあるのに
                autoconfに対してmakeじゃなくてじゃなくて「別の開発ツールに対して同じような機能つけたくなること」はないの?なんでCMakeにだけそれを求めるの?

              • by Anonymous Coward

                > autoconfに対してmakeじゃなくてじゃなくて「別の開発ツールに対して同じような機能つけたくなること」はないの?なんでCMakeにだけそれを求めるの?

                autoconf は make 以外のツールに使うこともできます。
                autotools は、autoconf と automake と libtool が主な構成要素で、
                このうち make を前提しているのは automake だけです。
                autoconf を Makefile ではない他のビルドツール生成に使うってのは普通にできます。
                こういう機能分割とカスタマイズ・ポイントの提供という意味で、
                autotools は良くできてますよ。

                CMake の方は VisualStudio だけのためのツ

              • by Anonymous Coward

                >autoconf を Makefile ではない他のビルドツール生成に使うってのは普通にできます。
                そうなんですね。ググってもすぐ見つかりませんでしたが、例えばどのようなものがあるのでしょうか?

              • by Anonymous Coward

                >そういうカスタマイズしたいようなポイント
                いうほどそんなところカスタマイズしたいと思わないと思うんだけど・・・
                新規でビルドツールを作る人ってかなり少数派だと思うぞ。一番最近でそれなりに使われてるのNinjaぐらいでしょ。

              • by Anonymous Coward

                > そうなんですね。ググってもすぐ見つかりませんでしたが、例えばどのようなものがあるのでしょうか?

                make は普遍的に存在していて、ニーズが少ないから見つからないでしょうね。

                autoconf っていうのは、本質的には m4 マクロを使ってシェルスクリプトを生成するツールに過ぎず、
                その m4 マクロとして、システム付属のヘッダファイルやライブラリを参照した結果に応じて
                テンプレートをベースにファイルを生成する仕組みが完備しているというものです。

                このコアの仕組みには make への依存はまったくありません。
                生成するファイルも Makefile とは限らず、configure.ac で逐一指定するようになってます。
                デフォルトで用意されているマクロに automake 用のものが沢山用意されていて、
                普通は au

              • by Anonymous Coward

                > いうほどそんなところカスタマイズしたいと思わないと思うんだけど・・・
                > 新規でビルドツールを作る人ってかなり少数派だと思うぞ。一番最近でそれなりに使われてるのNinjaぐらいでしょ。

                ビルドツールを作りたいって話じゃないです。
                CMake がサポートしていないマイナーな IDE やビルドツールを使いたいって話です。

              • by Anonymous Coward

                >CMake がサポートしていないマイナーな IDE やビルドツールを使いたい
                ってことが言うほど無いって言ってるんですが。
                それにAutotools使ったらそれらを簡単に使えるんでしょうか?

              • by Anonymous Coward

                普遍的に存在しているmakeへの出力をcmakeも対応してるんですが、Ninjaなどのビルドツールへの対応もされてますよね。そこには需要があるからです。

                なぜautoconfでNinja対応が見つからないのでしょうか?貴方が言うように普通にできてカスタマイズポイントの提供が出来ているというのであれば、そのカスタマイズポイントを使って提供されていると思うんですが。
                まさかautotoolsのようなメジャーなツールをNinjaチームが対応可能なのにあえて無視するとは思えません。

                https://github.com/ninja-build/ninja/wiki/List-of-generators-producing... [github.com]

              • by Anonymous Coward

                > ってことが言うほど無いって言ってるんですが。

                多い少ないとかいう問題ではなくて、CMake の設計方針が微妙って話をしてます。

                > それにAutotools使ったらそれらを簡単に使えるんでしょうか

                無理です。
                CMake の方が新しいし機能が多いのは明らかです。
                で、新しいんだから、設計も優れてると期待して使い始めたら、そこはそうでもなかったなという話です。

              • by uxi (5376) on 2018年01月08日 1時57分 (#3341021)

                本当、Autotools を使って make 以外でビルドしてる例って凄いレアケースだと思う。
                上で挙げられてる cccl も CL.EXE を cc 互換にする wrapper (つまり make を利用してる)だし、少なくとも自分は make 以外の事例を例を見たことがない。

                たいへん興味があるので、もしも知っているプロジェクトがあるなら、後学のために例示して頂けると嬉しい。

                --
                uxi
                親コメント
    • by Anonymous Coward

      そして meson + ninja とかが流行ってるけど…

      もう好きにして状態

  • by Anonymous Coward on 2018年01月05日 16時26分 (#3340220)

    使った事ないけど「400近くのコマンドラインオプション」って所で、ふふっと笑ってしまった。
    頭おかしい(確信

    • by Anonymous Coward

      そんなにはないだろと
      man -P cat gpg | egrep ' {4}\-\-' | wc -l
      したら282しかなかったよ(白目

      • by Anonymous Coward

        うちは303!

        #関係無いけどegrepの正規表現内のエスケープ要らないよね
        #ついでにgrep ' --'の方が簡単だよね

        • by Anonymous Coward

          #なるほどスラドでは SPACE x 4を投稿できないのか…

          • by Anonymous Coward

            <ecode></ecode>で囲んでください。

        • by Anonymous Coward

          正規表現が癖になってるか、正規表現を覚えたくて些細な事にでも使いたいかのどっちかじゃない?

          昔、英語を早いとこ覚えたくて日本語文章の細々とした単語を全部英語で書いてたら
          「お前はルー大柴か」
          とか
          「それ、かっこいいと思ってんの?」
          とか突っ込まれて切ない気持ちになった。そういうんじゃないだけどなぁ。
          普段使いするってのは実際問題すさまじい効果あるんだよ、やっぱり。

          • by Anonymous Coward

            それは普段使いに対してでなく、書かれた内容に対しての突っ込みだったのだと思われるが。

            • by Anonymous Coward

              いや、はっきり
              「一々英語で書いてるけどそれかっこいいと思ってんの?」
              って言われてるよ。
              前の書き込みではそんな部分いらんから省略したけど。
              どうにかして人を馬鹿にしたいの? 暗い性格だなぁ……。

              • by Anonymous Coward
                暗い性格でも、人を馬鹿にしたいわけでもなく、自分勝手な行動に周りはイラッとしてるのだと思われる。

                普段使いしたいなら、英語圏の掲示板にでも入り浸れば?
                英語力次第では、正に半年くらいROMったほうが良いかも知れないが。
              • by Anonymous Coward

                自分が書いてたブログで使ってただけだけど。
                どんだけ人をディスりたいんだ。

          • by Anonymous Coward

            他人宛の文章でやってたんなら言われて当然だな

            • by Anonymous Coward

              ていうか他の奴もそうだけど、他人宛の文章で使うわけないでしょ。
              そんなのは当たり前の前提条件だ。
              そもそも、もしそうしてたんならツッコミは既に書いた様な穏当なものじゃなく、
              「意味わからんからやめろ」
              とかになるでしょ。

              自分の頭が悪いからって、人の頭を勝手に悪く考えるのは良くない。

      • by Anonymous Coward

        353だった。
        debian

    • by Anonymous Coward

      どうせ特定の組み合わせでないと有効にならないオプションがあるんだろ。整理したら半分くらいになるんじゃないの?
      UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている
      400近くのコマンドラインオプションが存在する時点で小さくない。一つのことではなく無数のことをしかもまともにやれるかも怪しい。

      • by Anonymous Coward

        パーサが2つあるとか、HTTPやDNSを抱え込んでるとか好き勝手作ったらこうなりましたってだけでは。
        小さいとか大きいとかじゃなく、作っている側が使い手のことを考えてないだけ。
        よくありがちなGnuプロジェクトじゃん。

  • by Anonymous Coward on 2018年01月05日 17時08分 (#3340235)

    PGPはエンドトゥーエンド暗号化をする時のそれなりに選択できる数少ない選択肢で普及してほしい。
    ただ、やりたい事は単に

    • 信頼できる公開鍵の通知
    • 失効時の速やかな通知
    • ファイルやメール本文の公開鍵暗号
    • 鍵の種類と強度にある程度(SSHくらい)自由がある事

    だけであってそんなに難しい事なのか、と思う。
    PGPは捨ててもっとシンプルなプロトコルにした方が良いのでは。
    なにより世の中ではおおざっぱな共通鍵であふれているくらいだから手軽さが大事だし。

    • by Anonymous Coward

      個人的には、
      > 長生きするデーモンではなく、すぐ終了するヘルパープロセス
      という辺りが特にいいと思う。これがうざくて2に(本格的には)移行できない。
      デーモンが生きてるとunmountができないんだよね。まあスクリプト組めばいいだけとも言えるけど。

  • by Anonymous Coward on 2018年01月05日 17時46分 (#3340249)

    LibreSSLといろいろ似ているよね、と。

    • by Anonymous Coward

      一方 systemd 派閥は systemd-pg の開発を急いだ

    • by Anonymous Coward

      でもC++だからなあ……

  • by Anonymous Coward on 2018年01月05日 20時10分 (#3340302)

    ウェキペディアだったらユーザーページのメモの段階でコピペしてたら削除されるのに

    • by Anonymous Coward

      そりゃコピペだかららだろ。コピペ以外に文書を作る方法を知らないのか?

      • by Anonymous Coward

        forkする意外にプロセスを作る方法をしらないのか? # 唐突なUNIXディス

typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...