GnuPG2のフォーク「NeoPG」、開発中 54
刷新となるか 部門より
PGPやGnuPGには近年いくらかの批判もありますが、開発は情熱的に続いています（過去記事：PGPの32ビット鍵IDが問題に、Linus Torvalds氏などの偽造鍵も確認される、PGPは有害無益？）。
とはいえ、GnuPGは20年以上の開発によって内部構造が複雑になりすぎています。これに伴う種々の問題に取り組むため、NeoPGという新たなプロジェクトが発足しています。
スライドによると、GnuPGは49万行のコードから成り、400近くのコマンドラインオプション、2種類のOpenPGPパーザ、自前のHTTPクライアントやDNSリゾルバ関連コードを持つ、重厚長大なプロジェクトです。NeoPGでは、できるだけレガシーコードを減らし、外部ライブラリを積極的に利用することで、開発を容易にするつもりです。スライドの時点で、すでに行数はほぼ半減し、コマンドラインオプションも120ほど減っているそうです。
ブログでは、そのほかにもautoconfではなくCMake、CPPマクロではなくC++テンプレート、数多くの小さなバイナリではなく単一バイナリ、長生きするデーモンではなく、すぐ終了するヘルパープロセスといった劇的な設計変更の理由について説明しています。（このうちの一部はUNIX哲学からの逸脱と見られかねないことも理解したうえで、使い勝手や開発/メンテナンスのコスト、コンピュータ性能の発達などを考慮した結果とのことです。）
ライセンスについても、GitHubのREADME.mdによれば「今のところGPLやLGPLなど様々なライセンスのコードを含んでいるが、新規コードはSimplified BSDライセンスに限っている」という書き方からして、GPLからの脱却を目指しているようです。
全体的に、ここ10年程度のトレンドを慎重に取捨選択して、そつなくリファクタリングしているように見えますが、皆さまはどう評価されるでしょうか。
CMake (スコア:1)
CMakeホントにいいかなあ。
autoconfの場合、基礎的な仕組みとad hoc なルールが明確に切り分けられてて、
後者はすべてマクロで構築されてるので、足りない部分は既存のマクロを参考に自分で用意するとか容易だけど、
CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
CMakeであらかじめ対応しているプラットフォーム向けは簡単な記述で済むし実行速度も速いけど、
ちょっと想定から外れた使い方しようとすると途端に面倒くさくなって落差が激しい感じ。
よく知らない頃は ad hoc なルールの類は全部組み込みスクリプティング言語で書いてあるかと思ってたら
全然そうじゃないので、なんかコレジャナイ感が。
Re: (スコア:0)
ほんとこれ
さらにつけ加えると互換性問題も以外と酷い
cmake_minimum_required (VERSION 3.10.1) みたいなのがまれに良く出てくる
ArchやGentooなどの、最新版こそ正義みたいなポリシーのディストリ使ってるならともかく
stableって古いことだと勘違いしてるDebianみたいなディストリ使ってると、ただ単純に動かすだけでも一苦労
ついでにいっとくと、cmake_minimum_requiredみたいなイカレたディレクティブ名からお察しできるように
VBAでもリスペクトしてんのかっていうくらい、全てのディレクティブが無駄にバカ長い
include_directories(${CMAKE_CURRENT_SOURCE_DIR}) とか
ad
Re: (スコア:0)
CMakeFile.txt じゃなくて、もっと長い CMakeFiles.txt だよね
Re: (スコア:0)
たぶん同意する人は少数だよ。今時autoconfの暗号めいたキーワードを喜ぶのは独りよがりなオタクだけ。
今は冗長でも覚えやすいキーワードにするのが主流。
UNIXシェル環境でも、最近のCLIツールは比較的長いコマンドが多くなっている（gitのサブコマンドシステムなど）。
その考え方を一貫して適用したのがWindowsのPowerShellという新しいシェル環境で、
すべてのコマンドやオプションが一貫した命名規則に従っている。
実に覚えやすく、ヘルプを見る回数が圧倒的に少ない。
新しいコマンドの習熟もあっという間だし、しばらく使っていなかったコマンドの使い方も忘れにくい。
Re: (スコア:0)
省略名だと、変に寿命長いモノの場合「その名前は既に使われてます」で後半になると被ってハマるから、PowerShell的な規則の方が無難だなとは思ってる。
かと言って古い奴は一文字でも減らして消費量減らそうという面もあったからなぁ。。
Re: (スコア:0)
フルネームで記述するのが最終解なのだろうと信じつつ、
しかしやはりそのルールでコードを書いていると、
識別名が果てしなく長大化することがあって、それはそれで悩む。
(lintツールに関数名が長すぎると怒られて思わず唸った事も...)
directoryとdirの混在にも若干の葛藤が見受けられる。
解読容易なら長い分にはセーフ、という思想は、
10年後にはもう一度再考されたルールが主流になってるかもしれない、とも思う。
(略記の辞書定義記述が標準化される、とか)
Re: (スコア:0)
実に覚えやすく、ヘルプを見る回数が圧倒的に少ない。
新しいコマンドの習熟もあっという間だし、しばらく使っていなかったコマンドの使い方も忘れにくい。
嘘だ、ちっとも覚えられないよ、あれ。
挙句に結果がオブジェクトだから、その仕様まで覚えてないとつらい。
shで書く方がまだ覚えられる。おぼえなければならない量が全然違うもの。
そりゃ日々なにがしかps書いてりゃ覚えられるだろうが、たまにしか書かないならヘルプやエディタの支援がなければ無理。
ありゃエディタの支援有りきだよ。その分強力になってるんだから。
Re: (スコア:0)
菜切包丁で魚捌けないと嘆いてるような感じ？
Re: (スコア:0)
>CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
それはCMakeは関係ない。クロスプラットフォームなコードを書くときに、ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルドというのが嫌われているだけ。
それにVisualStudio の各バージョン対応のようなものをスクリプトで前処理する方が数倍めんどくさいと思うが、そういう事やったことあって言ってる？
Re: (スコア:0)
>>CMakeの場合、VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて、
>
> それはCMakeは関係ない。クロスプラットフォームなコードを書くときに、ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルドというのが嫌われているだけ。
「ビルドするのに特定のツールに依存してヘッダーなりソースコードを生成してそれを参照してビルド」の
「特定のツール」って何のこと？
autoconf の場合、配布されたソースをビルドするのに autoconf を含め特定のツールは必要ないと思うんだけど。
まあ UNIX互
Re: (スコア:0)
え？config.h的なものを生成してビルドすることを言っててるんだと思ったんだが違うのか？
>VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて
というのが何を指してるのかわからん。Generatorの話ならVisual Studioは大抵古いバージョンのを指定してソリューション生成しても新しいバージョンで開いてビルド出来るし、IDE必要ないならMakefile生成して好きなコンパイラ使えばいいし。
Makefileしか生成出来ないautoconfと何を比べてるのか解らん
Re: (スコア:0)
> え？config.h的なものを生成してビルドすることを言っててるんだと思ったんだが違うのか？
違いますね。
config.h は、-DHAVE_機能 というコマンドラインオプションを生成しているようなものなので
全然問題ないでしょう。
>> VisualStudio の各バージョン対応みたいなのが C++ のソースコードとして記述されてて
>
> というのが何を指してるのかわからん。Generatorの話なら...
Generator の話です。
こういう特定のツールに依存した機能を、プラグインとして分離せず CMake 本体に組み込んじゃうセンスがついていけないって話。
Re: (スコア:0)
特定のツール(Make)だけに依存したautoconfを持ち上げてそう言われてもなあ…
Re: (スコア:0)
> 特定のツール(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 が当初の目標を越えて成功しすぎたせい。
Re: (スコア:0)
CMakeがVisualStudioに対応してるんだから
それを本体に組み込もうがプラグインにしようが
それはCMakeの勝手じゃないの？
Re: (スコア:0)
> それを本体に組み込もうがプラグインにしようが
> それはCMakeの勝手じゃないの？
もちろん CMake の勝手なんだけど、そこは最初からプラグインとして外に出しておいた方が設計として筋がいいと思うって話。
VisualStudio じゃなくて別の開発ツールに対して同じような機能つけたくなることもあるのに、
同じようなことするのに CMake 本体側をいじる方が簡単になるような設計方針はちょっと微妙なセンスなんじゃないかってこと。
Re: (スコア:0)
>VisualStudio じゃなくて別の開発ツールに対して同じような機能つけたくなることもあるのに
autoconfに対してmakeじゃなくてじゃなくて「別の開発ツールに対して同じような機能つけたくなること」はないの？なんでCMakeにだけそれを求めるの？
Re: (スコア:0)
> autoconfに対してmakeじゃなくてじゃなくて「別の開発ツールに対して同じような機能つけたくなること」はないの？なんでCMakeにだけそれを求めるの？
autoconf は make 以外のツールに使うこともできます。
autotools は、autoconf と automake と libtool が主な構成要素で、
このうち make を前提しているのは automake だけです。
autoconf を Makefile ではない他のビルドツール生成に使うってのは普通にできます。
こういう機能分割とカスタマイズ・ポイントの提供という意味で、
autotools は良くできてますよ。
CMake の方は VisualStudio だけのためのツ
Re: (スコア:0)
>autoconf を Makefile ではない他のビルドツール生成に使うってのは普通にできます。
そうなんですね。ググってもすぐ見つかりませんでしたが、例えばどのようなものがあるのでしょうか？
Re: (スコア:0)
>そういうカスタマイズしたいようなポイント
いうほどそんなところカスタマイズしたいと思わないと思うんだけど・・・
新規でビルドツールを作る人ってかなり少数派だと思うぞ。一番最近でそれなりに使われてるのNinjaぐらいでしょ。
Re: (スコア:0)
> そうなんですね。ググってもすぐ見つかりませんでしたが、例えばどのようなものがあるのでしょうか？
make は普遍的に存在していて、ニーズが少ないから見つからないでしょうね。
autoconf っていうのは、本質的には m4 マクロを使ってシェルスクリプトを生成するツールに過ぎず、
その m4 マクロとして、システム付属のヘッダファイルやライブラリを参照した結果に応じて
テンプレートをベースにファイルを生成する仕組みが完備しているというものです。
このコアの仕組みには make への依存はまったくありません。
生成するファイルも Makefile とは限らず、configure.ac で逐一指定するようになってます。
デフォルトで用意されているマクロに automake 用のものが沢山用意されていて、
普通は au
Re: (スコア:0)
> いうほどそんなところカスタマイズしたいと思わないと思うんだけど・・・
> 新規でビルドツールを作る人ってかなり少数派だと思うぞ。一番最近でそれなりに使われてるのNinjaぐらいでしょ。
ビルドツールを作りたいって話じゃないです。
CMake がサポートしていないマイナーな IDE やビルドツールを使いたいって話です。
Re: (スコア:0)
>CMake がサポートしていないマイナーな IDE やビルドツールを使いたい
ってことが言うほど無いって言ってるんですが。
それにAutotools使ったらそれらを簡単に使えるんでしょうか？
Re: (スコア:0)
普遍的に存在しているmakeへの出力をcmakeも対応してるんですが、Ninjaなどのビルドツールへの対応もされてますよね。そこには需要があるからです。
なぜautoconfでNinja対応が見つからないのでしょうか？貴方が言うように普通にできてカスタマイズポイントの提供が出来ているというのであれば、そのカスタマイズポイントを使って提供されていると思うんですが。
まさかautotoolsのようなメジャーなツールをNinjaチームが対応可能なのにあえて無視するとは思えません。
https://github.com/ninja-build/ninja/wiki/List-of-generators-producing... [github.com]
Re: (スコア:0)
> ってことが言うほど無いって言ってるんですが。
多い少ないとかいう問題ではなくて、CMake の設計方針が微妙って話をしてます。
> それにAutotools使ったらそれらを簡単に使えるんでしょうか
無理です。
CMake の方が新しいし機能が多いのは明らかです。
で、新しいんだから、設計も優れてると期待して使い始めたら、そこはそうでもなかったなという話です。
Re:CMake (スコア:2)
本当、Autotools を使って make 以外でビルドしてる例って凄いレアケースだと思う。
上で挙げられてる cccl も CL.EXE を cc 互換にする wrapper (つまり make を利用してる)だし、少なくとも自分は make 以外の事例を例を見たことがない。
たいへん興味があるので、もしも知っているプロジェクトがあるなら、後学のために例示して頂けると嬉しい。
uxi
Re: (スコア:0)
そして meson + ninja とかが流行ってるけど…
もう好きにして状態
笑ってしまう (スコア:0)
使った事ないけど「400近くのコマンドラインオプション」って所で、ふふっと笑ってしまった。
頭おかしい(確信
Re: (スコア:0)
そんなにはないだろと
man -P cat gpg | egrep ' {4}\-\-' | wc -l
したら282しかなかったよ（白目
Re: (スコア:0)
うちは303!
#関係無いけどegrepの正規表現内のエスケープ要らないよね
#ついでにgrep ' --'の方が簡単だよね
Re: (スコア:0)
#なるほどスラドでは SPACE x 4を投稿できないのか…
Re: (スコア:0)
<ecode></ecode>で囲んでください。
Re: (スコア:0)
正規表現が癖になってるか、正規表現を覚えたくて些細な事にでも使いたいかのどっちかじゃない？
昔、英語を早いとこ覚えたくて日本語文章の細々とした単語を全部英語で書いてたら
「お前はルー大柴か」
とか
「それ、かっこいいと思ってんの？」
とか突っ込まれて切ない気持ちになった。そういうんじゃないだけどなぁ。
普段使いするってのは実際問題すさまじい効果あるんだよ、やっぱり。
Re: (スコア:0)
それは普段使いに対してでなく、書かれた内容に対しての突っ込みだったのだと思われるが。
Re: (スコア:0)
いや、はっきり
「一々英語で書いてるけどそれかっこいいと思ってんの？」
って言われてるよ。
前の書き込みではそんな部分いらんから省略したけど。
どうにかして人を馬鹿にしたいの？ 暗い性格だなぁ……。
Re: (スコア:0)
普段使いしたいなら、英語圏の掲示板にでも入り浸れば？
英語力次第では、正に半年くらいROMったほうが良いかも知れないが。
Re: (スコア:0)
自分が書いてたブログで使ってただけだけど。
どんだけ人をディスりたいんだ。
Re: (スコア:0)
他人宛の文章でやってたんなら言われて当然だな
Re: (スコア:0)
ていうか他の奴もそうだけど、他人宛の文章で使うわけないでしょ。
そんなのは当たり前の前提条件だ。
そもそも、もしそうしてたんならツッコミは既に書いた様な穏当なものじゃなく、
「意味わからんからやめろ」
とかになるでしょ。
自分の頭が悪いからって、人の頭を勝手に悪く考えるのは良くない。
Re: (スコア:0)
353だった。
debian
Re: (スコア:0)
どうせ特定の組み合わせでないと有効にならないオプションがあるんだろ。整理したら半分くらいになるんじゃないの？
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている
400近くのコマンドラインオプションが存在する時点で小さくない。一つのことではなく無数のことをしかもまともにやれるかも怪しい。
Re: (スコア:0)
パーサが２つあるとか、HTTPやDNSを抱え込んでるとか好き勝手作ったらこうなりましたってだけでは。
小さいとか大きいとかじゃなく、作っている側が使い手のことを考えてないだけ。
よくありがちなGnuプロジェクトじゃん。
素晴らしい (スコア:0)
PGPはエンドトゥーエンド暗号化をする時のそれなりに選択できる数少ない選択肢で普及してほしい。
ただ、やりたい事は単に
だけであってそんなに難しい事なのか、と思う。
PGPは捨ててもっとシンプルなプロトコルにした方が良いのでは。
なにより世の中ではおおざっぱな共通鍵であふれているくらいだから手軽さが大事だし。
Re: (スコア:0)
個人的には、
> 長生きするデーモンではなく、すぐ終了するヘルパープロセス
という辺りが特にいいと思う。これがうざくて2に(本格的には)移行できない。
デーモンが生きてるとunmountができないんだよね。まあスクリプト組めばいいだけとも言えるけど。
OpenBSDプロジェクトが飛びつきそう (スコア:0)
LibreSSLといろいろ似ているよね、と。
Re: (スコア:0)
一方 systemd 派閥は systemd-pg の開発を急いだ
Re: (スコア:0)
でもC++だからなあ……
ライセンス問題ないの？ (スコア:0)
ウェキペディアだったらユーザーページのメモの段階でコピペしてたら削除されるのに
Re: (スコア:0)
そりゃコピペだかららだろ。コピペ以外に文書を作る方法を知らないのか？
Re: (スコア:0)
forkする意外にプロセスを作る方法をしらないのか？ # 唐突なUNIXディス