  |
はてなキーワード: gccとは
近年，人格障害者の関係していると思われる事例をネットで見かけることが多くなってきた．例えば
また一見すると分かりにくいが以下の比較的有名なプロジェクトにも人格障害者の関わっている痕跡を読み取ることができる
gentoo linuxの昔のドキュメント（もう残っていないらしくリンクを見つけることはできなかった）には，gentoo linuxの前身となったFreeBSDがベースになっているプロジェクトが，人格に問題のある人が開発に関わった結果，頓挫した話が記載されていた．
このドキュメントは人格障害という言葉が一般に知られるようになる前に書かれていたため，人格障害について明確に記述されてはいないが，どう見ても人格障害者の関わった事例であった．おそらく人格障害について広く知られるようになってから削除されたのではないかと想像する．
ここで人格障害について知らない人のために解説をしよう．人格障害という言葉が広く一般に知られるになったのは，この本が原因ではないかと思う
Stop Walking on Eggshells) Paul T. Mason , Randi
Kreger (2006)]
この本（以下ではSWEと呼ぶ）は医者ではなく人格障害者と日常生活で関わってしまって苦労した著者が，なんとか苦痛に満ちた生活の原因を探すため調べた情報がわかりやすく記述されており，専門知識がなくても豊富な役立つ情報を学ぶことができる名著である．この本が出版される以前に，小さな町の本屋で人格障害に関する本が目立つ場所に平済みされていた記憶はないため，おそらくこの本がブレークスルーであったと自分は想像する．SWEは人格障害について知らない人が最初に学ぶ入門書としてもとても良い本なので，多くの人にぜひ一度読んでみて欲しい本である．
SWEでは（境界性）人格障害(BPD: Borderline Personality Disorder)の様々な定義が紹介されているが，ここでは以下の定義を紹介する．
Borderline Personality Disorder)と呼ぶ
自分の手足は動かしすぎると疲労するが，他人の疲労を自分は感じないので，疲労なく無限に動かし続けられる自分の手足＝他人 となっているので周辺の人間はとても苦痛を感じることとなる．近年話題になる長時間労働問題の原因はこれではないかと自分は考えている．BPDの本人は日常生活に何の苦痛も感じないが，周辺で「手足」となっている人はとても苦痛を感じることとなる．この周辺の人はnon-BPDと呼ばれる．SWEの特に重要な点はnon-BPDという言葉を一般人にわかりやすく解説し紹介した点にあると思う．
non-BPDはBPDについて調べる重要な検索キーワードにもなっている．BPD本人は何の苦痛も感じないためネット上に書き込みをするのはnon-BPDの人達である．
non-BPDで検索するともっと具体的で生々しい事例をいくつも見つけることができる.
BPDよりもよく知られた人格障害でサイコパスというものがあるが，ネット上のサイコパスという単語は本来の意味からかなり外れたある種のバズワードとなっており，サイコパスという単語でネットを検索しても実生活で役立つ情報を見つけることは難しい．
以下のBPDの定義を思いだしてみよう
疲労なく無限に動かすことができる便利な道具として最も良く知られたものはコンピュータ（ロボット）だろう．つまり他人をコンピュータと認識しているのがBPDであると言っても良い．これが多くの長時間労働問題の原因と考えられる．ここで以下の面白い話題を紹介しよう．
人間＝獣と違う論理的なもの から 人間＝コンピュータと違う感情的なもの
への変化は，Windows95が発売された1995年から2010年ぐらいまでに少しずつ起きたように思う．これは，この（長い）時期に放送されていたSF映画であるスタートレックやスターゲイトを見るとわかる．
これについては後で詳しく解説する．とにかくコンピュータは人間の認知にとても大きな変化をもたらした． https://trends.google.com/trends/explore?date=all&geo=US&q=BPD:title=google
trandでBPDを検索してみると] 2004年から2012の間に倍になっている．上昇は緩やかな単調増加で減ることはほぼない．これは他人からコンピュータとして扱われる人が毎年増えてきていることを示している．
BPDの本人がBPDについて検索することはない．本人は自分は普通の常識人と認識しているからである（SWEなどの人格障害について解説する本では，人格障害者の多くは自分を普通の人と認識していることが述べられている）．
SWEではBPDの原因の１つとして幼児期の過剰な甘やかしを挙げている．幼児が泣いて両親がすぐに何かしてしまうと，泣けば自動的に世話してくれる自分の手足の延長として他人を認識してしまう，というものである．
この状態のまま大人になると他人は自分の世話をするのが普通という認識が固定される．大人の場合は泣いたりできないので，かわりに嘘や脅しで他人を（手足として）操作するようになる．嘘つきというのは人格障害の肝となっている．
人格障害者の見分け方として嘘を誤魔化すためにさらに嘘をつくのは人格障害である，とSWEなどの人格障害について解説する多くの本では述べている．ちょっとした嘘なら誰でもつくが，さらに嘘を重ねるのが人格障害の特徴である．
本人は当然と思っている「他人が自分の世話をする」状況を維持するために「普通のこと」＝嘘や脅しを日常的に行うため，周辺の人間は苦痛を感じることとなる．本人にとっては当然の普通のことをしているだけなので普通に日常的に嘘や脅しをするのである．
この時，コンピュータ（ロボット）という本当に自分の手足の延長になってしまう道具という概念が存在していると，さらに悪い状況が生まれると私は考える．エクセルの関数機能やプログラミング言語について少しでも知識があるならば最悪である．
仮にwindows95がなかった（誰でもコンピュータが安く買える）1995年より昔はnon-BPD（コンピュータとして扱われる人）は少なかったとして，しかし，そのはるか昔から存在していた人格障害としてサイコパス（BPDと行動はよく似ているが内的心理状態は違うらしい）がある．サイコパスについて解説している（おそらく一番読まれている）本である
https://www.amazon.co.jp/dp/4794219296:title=- 良心をもたない人たち , Martha Staut
(2012)]
には，エスキモーにはサイコパスを殺してしまう慣習（クンランゲタ）があったことが述べられている．現代に置き換えるなら長時間労働で殺されるぐらいなら殺してしまおうという感じだろうか．そのため昔は，人格障害者は（殺されてしまうので）少なかったと解説されている．しかし現代ではnon-BPD（コンピュータとして扱われる人）は増えている．
BPDやサイコパスなどの人格障害について解説する本のほぼ全てでは，人格障害者からは「逃げろ」というアドバイスをしている．不運にもなんらかの人格障害者が隣に引っ越してきたら，自分も引っ越して逃げるしかないし，
職場にいた場合は辞めるしかない．ただしサイコパスの事例では辞めた後も嘘の責任追及などで追い込まれる事例も紹介されているので，安心はできない．先に紹介したgentoo linuxの事例では，FreeBSDベースのプロジェクトをうまくデコイとして使うことでなんとか逃げ切ったようだ（うまく逃げ切ったから今のgentoo linuxがある）． 自分が想像するにgentoo linuxもFreeBSDと同じ「再攻撃」を受けたはずであるが，うまく乗り切っているようだ．non-BPDの多くの人達は「人格障害者と一度かかわるとある種の直感が鋭くなる」と言っている．直感で事前に危険を察知して予防できるようになるそうだ．最初に述べたlibavやsystemdに人格障害の関わりがあるという根拠も実は私の直感であってうまく説明できない．ただ，オープンソースと人格障害の両方の知識があるならば，みんな同じ判断を下すだろうと思う．SWEも「良心をもたない人たち 」でも直感の重要性について述べている．
BPDやサイコパスなどの人格障害について一般向けに解説する本の多くは事例の紹介が中心になっている．人格障害者本人が普通と思っている状況を維持するためにつく嘘や様々な行動は，工夫が凝らされており完全犯罪に近い．
普通は思いつかない工夫に満ちた方法が使われるため単純に類型化できないのもあり，個別の事例を紹介するしかないからだと思われる．とはいえgoogle trandの傾向からわかるように，BPDについて知っている人は増加傾向にある．
人格障害とみなされない（見破られない）ためにさらに巧妙な手段が近年は必要となってきている．ここでも人格障害を見破るために重要となるのは直感である．ここで直感というのは具体的には「良心をもたない人たち
」では「何かが変」と感じたら騙されている可能性が高いと言っている．
ただ直感でかたずけられてしまっては．なかなか気が付けない人も多いと思うため，ここでは近年巧妙になった人格障害者の手口について自分の気が付いた範囲で述べていこうと思う．
(と思ったけど気力切れ)
先に紹介した有名なオープンソースプロジェクトについて解説しよう
(と思ったけど気力切れ)
プログラマじゃないけどプログラミング完全に理解した（）おばさんが理解してる基礎知識書くよ。
（追記 この文章はプログラミングの勉強をしたいけどその周辺にある基礎知識になかなか触れる機会がない人向けに書きました。これらの基礎知識があると、困ったときに調べ方すら分からないという状況は回避しやすくなるはず）
ターミナル、いわゆる黒い窓からCUI（コマンドユーザーインターフェース）でコンピュータを使う方法を覚えよう。これは大学のコンピュータリテラシーで習った。MacOSXで復習すると捗った。（追記 すごく間が抜けてたけどMacOSXはUnix系OSです）
まずはファイル操作。Macでターミナルを使って、cd Desktopって打ってからecho ohayou ＞ aisatsu.txtって打ってみて、cat aisatsu.txtってやる。そうすると何が表示されるのか？とりあえずやってみよう。ここで＞は増田の都合上大文字全角にしてるけど、ちゃんと半角にしてね。なんで増田の都合上半角がダメなのか、そのうち想像できるようになろう。（追記 ブコメ指摘感謝）
そして、実際にデスクトップを見に行ってみると、aisatsu.txtってファイルがあるはずなんで、開いてみよう。これで何が起こったのか７割くらいはわかるはず。
こういうファイル操作の基本をまず覚えよう。これこそ空気みたいなものだから。
（追記 ここも間が抜けてたけど確かにhogeって何かわからないね。直しました）
最近は何も考えなければ文字コードはとりあえずUTF-8でなんとでもなるようになってるけど、バックスラッシュとかは環境設定で出てくるように設定しないと出てこないし、その意味合い、つまりエスケープとしての使い方を頭に入れておくと後々困らないと思う。あとEOF（エンドオブファイル）とか改行コードとかもそういうものがあるよ程度には覚えておこう。これ頭の片隅にはいってないと分からん殺し的な罠にはまることがある。
これは使いたいプログラミング言語の公式サイトに行くと大抵書いてある。
でもMacだとだいぶ楽。とりあえずターミナルからgccって打ってみるとなんかCUIツールとか書いてあるものをインストールしろって言われるのでインストールする。これだけでCとかC++とかRubyとかPythonとか一通り使えるようになる。もしかしたら最近はこのインストールすらいらないかもしれないけど。
あと、シェルのコマンドとかプログラミング言語を実際に使うときはいろんなライブラリをインストールする必要があるけど、そのライブラリは管理がすごく面倒なので管理をまとめてくれるコマンドがあったりする。aptとかhomebrewとかがそういうのだから、そんなものの使い方も覚えておこう。
（追記 言語の文法を追うだけなら環境構築なんてしなくてCloud9とか使ってもいいかもだけど、プロダクトを作ろうとした時にはまだまだ手元で環境作って必要なライブラリを入れてとやった方が後々応用がきくと思うのですよ。それにそうしていくとDockerの有り難みなんかも理解できるようになっていくのではと思います）
最初に勉強するプログラミング言語は、Javaだけはやめておけ。
なんでかっていうと、Javaはオブジェクト指向言語ってやつなんだけどオブジェクト指向的にしか書けないから。古い人間だと言われそうだけど、最初は手続き型言語から始めるべきだと思ってる。少なくとも、手続き型的に書ける言語から始めるべき。
なぜそう思うのかも含めて、とりあえずおばさんが理解しているプログラミング言語の発展の経緯を軽く解説する。
最初の頃のプログラミング言語は、手続き型と呼ばれるものが多かった。
この〇〇型ってのはプログラミングをするときの考え方によって名前がついているんだけど、手続き型はまず0を作って、0に1を100回足して、最後にその結果を表示してください、みたいな、上から書いた順番通りに動くのが基本のルールである考え方。プログラムは基本的にはこうやってデータをアルゴリズムを使って変化させていって望む結果を得ている。でもこのやり方は問題も多かった。プログラム全体がひとかたまりになってしまっているので、数千行とかになるともう普通の人では手がつけられないし、人間のミスでデータを間違って扱ってしまうことがバグの温床になった。
なので、この手続き型の考えに構造化という考えが加わって、関数というものが生まれた。関数っていうのは料理のレシピに例えるとわかりやすいかも。
5:豚こまを入れて色が変わるまで炒めます。
9:火を消して8をお皿に盛り、野菜炒めの出来上がりです。
B:肉に味付けをします。
2:Bを入れて色が変わるまで炒めます。
3:Aを入れてしんなりするまで炒めます。
4:火を消して3をお皿に盛り、野菜炒めの出来上がりです。
って書ける。ここではAとBが関数。
この程度だとあまり意味を感じないかもしれないけど、これがもっと複雑なものを想像してみると、なんとなくありがたみが分かって来ないだろうか？こうすると、多人数でプログラミングをするときに、Aを書く人、Bを書く人、1〜4にまとめる人って感じで作業分担ができる。それに、バグが起きた時もAの領域でバグったのか、Bの領域でバグったのかとか、全体にまとめると上手くいかないのかとか、原因の切り分けがしやすい。
でも、プログラムがとっても複雑化すると、これでも手に負えなくなる。料理の例えを拡大すると、料理店を運営することを考えるといいかも。
料理店でたくさんの料理をさばくときに、レシピを完全に1から作ることってないと思う。Aさんが野菜の仕込み担当、Bさんがスープの仕込み担当、というように各人に仕事が割り振られているはず。AさんもBさんもそれぞれの仕込みのレシピを持っていて、最終的に出てくる仕込みがちゃんとしてればAさんBさんの仕事の詳細までいちいちシェフが細かくチェックしない体制になっていると思う。大雑把にいうとそういう考え方をプログラムで再現したのがオブジェクト指向型言語。
なので、本気で料理の初心者がいきなり厨房の仕切りを任されて上手くいくのは難しいように、構造化プログラミングのありがたみすらわからない段階でオブジェクト指向型プログラミングに手をつけても意味がわからんだろうと思うのがおばさんの立場です。
（追記 おばさんはRubyを勧めておきます。オブジェクト指向型言語ですが、手続き型的に書き下すことも出来るからです。一つの言語で手続き型構造化オブジェクト指向、全部勉強できます。メソッドも便利なのが一通りあるし、日本語を扱うのにも問題が少ないです）
次に問題を分解できるようになろう。
例えば、クイズゲームを作りたいと考えたときにクイズゲームを作りたいです、って問題は大きすぎる。
クイズゲームに必要な要素は、問題文を表示する、回答を入力してもらう、正誤判定をする、正誤判定の結果を表示する、ということだなぐらいにまず分解する。
これを実際にプログラミングしようとすると、もっと分解できてさらに問題が見えてくると思う。
コンピュータってのは創造的なことはできない代わりに、とても簡単なことをとても階層的に重ね合わせて大きな問題を解けるように作られてる。それを心するといいと思う。
これ超大事。プログラミングって本当に自分で1からものを考えなきゃいけないことってあまりない。大きな問題はあなただけの問題かもしれないけれど、それを構成する小さな問題は大抵他の誰かが解いている問題なので、調べてみれば答えが見つかると思う。
エラーメッセージが出てきたらまずググってみる。翻訳しても初心者には意味がわからないし、ググったら誰かが解説付きで紹介してくれているのでその解説を読んだりしながらエラーメッセージとの付き合い方を覚えていけばいい。
メソッドの使い方がわからなかったら言語の公式サイトに行ってみる。メソッドの使い方で大事なのは呼び出し方、返ってくる値の型とかそういうのだから、こういうところはググるよりも公式サイトに書いてあることをしっかり読んで理解する。
あと、アルゴリズムの勉強もしてみるといいと思う。アルゴリズムとデータ構造と計算量の勉強。大学の学部レベルの教科書をちゃんと読んでみると、例えばデータベースを操作するSQLというものを書くことになった時とかに効いてくる。あとは作ったプログラムが遅すぎてどうしようとかいうのを解決する時とか。
なんか深夜までいろいろ書いてしまったけど、あくまでもプログラマじゃないおばさんが書いたものなので、みんなでツッコミとか入れてくれると大変助かります。
・STL標準講座
・Effective C++
・Modern Effective C++
・Effective STL
15年かけC++を独学した。
ずっと一人で努力し、風呂、トイレ、布団の中でも勉強し、プログラムを書いた。
基本情報処理、ソフトウェア開発者試験、ネットワークスペシャリストとデータベーススペシャリストを取得した。
しかし、正社員はもとより、時給2000円の派遣プログラマも時給1200円のアルバイトもスキル不足で何十社受けても一社も採用されない。
とはいえ、面接官のレベルは「STLなんて初めて聞いた」「gccて何かの会社？」
「C++の企画書(誤字ではない)を書いてる人なんてのがいるの？」
「じょーほーしょりしけんてのがあるの？外国の話？」
独身で、一切を我慢して娯楽を全く体験しないまま40歳になってしまった。IT業界の人間すべてが恨めしい。
貯金100万もなく、素人が書いたプログラムに対して手順書のとおりにマウスを操作してエクセルにテスト結果を書くだけの仕事ばかりしている。
C++じゃなくてCかC#かJavaか、とにかくC++以外だったらこんな事にならなかっただろうに。
プログラミングってこれからの時代必要っぽいし、なんとなくイケてるスキルっぽい。
ゲームとかアプリとか作ってストアで公開とかしたら就職とか転職にめっちゃ有利じゃね？
俺はこういうのが出発点で良いと思う。
でもプログラミングを始めようとすると「何がやりたいの？」と聞かれてソッコー詰まる。
俺は「何をやればいいの？」って思って調べてるつもりなのに「何がやりたいの？」って突き放される。
ここで混乱して立ち止まってしまう。
でも一呼吸おいて、初心者とそれ以外の間に生じる認識の祖語について１つずつ解消しなければ先に進めない。
俺はプログラミングを覚えるということは、何でもできるようになることだと思っている。
でも先人たちはそのようなスキルをすぐに教えてくれない。それどころか「何をやりたいの？」と言って、他につぶしの利かない小さな範囲の知識を与えようとしているように見える。
「アプリ作りたい」と言えば、どんなアプリ？という問いが続くし、特定の具体的なアプリしか作れないような知識しかもらえないだろう。
どういうことか？
試しに「何でも作れるようになりたい」と言ってみると「じゃあC言語やろうぜ」とか言われる。
C？いまさらCで何作れるんだよ。AndoroidアプリはJavaじゃないの？C関係ないでしょ！？Cでスマホアプリもウェブサイトも作れないじゃん！何言ってんの！？
ち・が・う！何でも作れるようになりたいの！あんたみたいに！Visual Studioだろうとgccだろうと、cとかc++とかc#とかjavaとかpythonとかrubyとかphpとかテンサーフローとかhtmlとかjavascriptとかjqueryとかgoとか駆使してたくさんウェブサービスとかアプリとか作りまくってるあんたみたいに！
「じゃあ今挙げたやつ全部やれよ。ちなみに今の俺は１０年以上プログラミング勉強してるから。１０年後今の俺になったところで、俺はさらに１０年積んでるからな。一生追い付かんな」
「じゃあ今、あるいはこれから使えるものを重点的にやっていくしかないな。で、何がやりたいの？」
何がやりたいのってどういうこと？むしろ何ができるの？
「アプリ作るとか」
「どんなアプリ作るの？」
…………どんなアプリ作れるの？
「ストアにあるようなやつ」
じゃあFGOみたいな……
「お前には無理だからｗ」
はぁっ！？ストアにあるようなやつって言ったじゃん！
そこでまた数回やりとりが発生して、プログラムを書くコストとかスキルの問題について再確認することとなり、
現実的に俺個人が支払えるコストの範囲で、何を作れるようなスキルを取捨選択するかという問題になり、
結局は教科書のサンプルをちまちま作っていくしかないのではないかというつまらない結論が脳裏に浮かぶし、
その道筋でさえ結局何年も積む必要があり、そのころには別の言語とか開発環境が主流になってるかも……
「そこだよそこ」
えっ？
「まずさ、日本語の教科書を読むには日本語が必要じゃん？それでも国語辞典とかwikipedia調べながら知らない単語や概念は別途補てんする必要がある」
う、うん。
「プログラミングの教科書とか風潮を読むにはプログラミングの基礎が必要。それに加えて、作りたいものに合わせて新規に開発環境なり言語なりを学習することになる。だから何でも作れるようになりたけりゃ、この世の全てを体得する必要があるけど無理だろそんなの」
え、えー
「でもいくつもの開発環境、言語を使って、ソフトウェアをいくつも実際に作ってると、基礎的な引き出しは大きくなるし、追加で新しい環境とかを学習する要領もつかめてくる。何年も積み重ねがあるとなおさらね。するとより少ない労力で新しい技術に追従できるし、新しい開発環境やアプリの分野でもサクサク作ってるように見える。それが、お前の言うところの『何でも作れる』ように見えるものの正体さ」
なんか夢から覚めた気分。
「FGOを作りたいなら、FGOをかみ砕いて、自分ならどういうアレンジでそれっぽいものを作れるか考えて、その過程で自分の能力とか限界を見極めていく必要がある。でもそれは結果論であって、最初は作りたいものをひたすら作ってみるしかない」
ふーん
「何度も聞くけど、何が作りたいの？FGOならFGOでいいよ。やってみろよ」
どうしよっかな……（頭を抱える）
ソースコードのコンパイルに失敗した場合は例えgccだろうがなんだろうがコードの内容はどうあろうがエラーを出力する。
コードが壊れているかどうかは重要ではなく、それに対して何をどう向き合ったかであって
あの記事の中身のコードがどんなコードであってもコンパイラがなんであっても本質には全く影響を及ぼさない。
たまたま環境がunityだっただけで、unityがその辺エラーを吐かないかというと吐いていたし見えない筈はなく、英語なので読めないということはあったかもしれないがそれはgccとて同じことだ。
何がその文章から読み取れるものの中で本来重要なことなのかで自ら「全く重要でないもの」を把握できておらずともすれば詭弁とも取れるunityをSAGEたいだけに見える駄記事じゃねーか。
いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。
このGPLのコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。
確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェアの著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。
ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。
詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。
https://www.gnu.org/philosophy/free-sw.html
ほとんどの自由ソフトウェアのライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由を尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアのライセンスは、契約を元にするもので、契約はもっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。
わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンスが利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由であると結論づけるかもしれません。
また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフトで保護されたソフトウェアでも、それによって作成された著作物はGPLにならない(つまりコンパイラやパーサーのライセンスを継承しない)ことを根拠に考察しているようだが、実はbisonやGCCのGPLにはライセンスに対する例外が付属していることを考慮すべきである。
GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアのライセンスが影響しないことを確実にするためにこれらの例外を規定しているのではないか。
この二つの理由から、元記事の議論は世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。
加えて言えば、たとえフェアユースの規定が全世界的に利用できて、営利目的でなければ利用できたとしても、
自由.0: どんな目的に対しても、プログラムを望むままに実行する自由
(i.e. オープンソースの定義 6項 利用する分野に対する差別の禁止)
がある限り、そのような制限をディストリビューションは受け入れられないだろう。
またOracle vs GoogleのJavaのAPI訴訟はケースとしてはかなり特例であり、
一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、
これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか。
少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である。
というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである。
Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーがコンピューターの計算のコントロールを
持つべきであるという自由ソフトウェアの思想と明らかに相容れないものである。
このようなサービスを利用することの弊害として、(例えば)Google翻訳に翻訳処理の計算を依存することにより、ユーザーの入力をGoogleが常に把握することが挙げられます。
もちろんこれはあまり良いことではない。
多くのFLOSSシステムディストリビューションは自由なソフトウェアを主に入れるというガイドラインを持っている。
アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、
これは事実上妥協の産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者は異論を挟まないだろう。
また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物に依存する場合、contribというセクションに閉じ込めており、それは公式のシステムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)
Ubuntuコミュニティで新規に作られた著作物がコミュニティの哲学に反する物に依存するというのは、かなり致命的である。
たとえ奇跡が起こり、例外的にGoogle翻訳や一部のプロ用翻訳ツールがBSDライセンス(Launchpad上での翻訳用ライセンス)での出力を許したとしても決して褒められたものではない。
Ubuntuのbug#1に"Ubuntuソフトウェアは自由である。常にそうであったし、今後も常にそうである。自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである。
https://bugs.launchpad.net/ubuntu/+bug/1
この反論を読んだ読者の中にはあまりにGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、
いわゆる"Linuxディストリビューション"の中には数多くの重要なGNUソフトウェアがシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)
またUbuntuの派生元となったDebianの成立経緯にはやはりFSFが関わっている。
さらに言えば、システムの保守を手伝う人の中にはシステムがフリーだからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)
のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。
学問の徒として生きるのは完全に諦めてるし、大学もはや無駄と思ってるけど、無能でない俺ですら無理と思う道であってこんな補助金出してガバガバ教育してる日本金の使い方無駄すぎ……とは思う
もっとちゃんとした就職予備校設置してほしいけどそういう変革は無理なんだろう。
そういう話じゃないのか。今回はそういう話ではないです。
パソコンのご本を読めるようになるのが難しい、という感じのお話。独学？ が難しい。
パソコンのご本、あんまり知識がちゃんとしてない人は読めないようになっているっぽい。
後述するけど、わかりやすいように作られたスクショまみれの本とか。
全体的なビジョンがないわけ。実際の世界がそれで動いてるようなビジョンが。だから読めない。
僕は社会の役に立つことを直接学びたかったよ。社会がどういう風に動いてるかみたいな話をさア
そういうのがあれば、パソコンのご本を読めるようになるんだろうなという感覚がある。
実務の話！！ 実際に「IT系のおしごと」というのがやってるような話で、特にコーディングに直接絡んでくるようなもの。
技術の実態みたいなやつ。そういうのは学校で教わらないんですよね。
優秀な人はバイトとかやって知ってるっぽいけど、それみんなバイトでやるの？ みんなはやらんでしょ。
というかバイトみたいな形で社会参画しないと学べない知識だったら、それはそれでやばくないですか？ という提起でもあります。
はてな民の人IT系で働いてる人多そうだけど、そういうところ、そういうところなんですよね。
そういう知識があれば、大学の図書館に置いてあるような「技術本」っぽいやつ？ の扱い方がわかるんだろうなーと思う。
いや別にやってきたことは何も無駄にはなってないんだけど。ハードよりの話もしたり、基本的な数学とか物理とか電子とか論理学とかシャノンの話とか。
でも、パチョコンは実学も以前に学問というか、実際に使えてナンボな部分が(いまこの想定してる話では)デカすぎるのに、
そんな環境的な、Linuxでサバ建てしましょーねーみたいな話も三年後期になるまでやらなくて、そんなん人が立ててるの見たら一発で覚えられることだし、みたいな。
みたいな。
そう、なんというか本が読めないんですよね。これ人がいたら一発なのに……というようなことだらけで、絶対間違った道に来ちゃってるよという感じがする。
↑
（焦ってるんじゃないのか？一冊だけをしっかりやれよ。と思ったりするし、言われそうだけど、それが一番の正解なのかな…やっぱり）
つーか本読みながらチンタラチンタラ比較するの嫌になるわけですよな。わかる。
スクショがいっぱい貼ってあったからといってわかりやすくなるわけではないし……。
てかスクショ貼ってあると古くなるとすぐ対応できなくなるから本当に困りますわよね、という話もあります。
僕が何を期待しているのかって？それは実務のうちで難しいお話が出てこない、環境の話、という感じ。
プログラミングをやれと言われても、それIDEはなによ？っつー話ですわな。WindowsだとVisual Studioとかになるのかな。
Eclipseはよくわからない。Javaでアプリ作るっていうのそんなに真剣にやったことないし……
っていうかそもそもプログラミングのお仕事？？がよくできる人たちはプログラミングで何をしているの？
アプリを作っているんですか？それだったらヴィジュアルモードのチェックが簡単なやつ必要だよね、という話で。
あるいは別にアプリなんか作ってないのかもしれないよな。とすると何かしらサーバーを使って捌くようなシステム・サービスの細かい調節のお手伝いをしてたりするわけだ。
その具体的なトラフィックがどうだからどうのこうの、というお話をしたり、アクセスの仕方がどうの脆弱性がどうの、新しい技術がどうの、という話だと思うんですけど、
端的に言ってそういう話がぜんぜんわからない。そういう話がわかるとスンナリ進めるはずなんだけどな～と思いながら。
親の金で大学行ってるのに、なんかもっとこううまくできるはずなのに……という感じでつらい。
僕は人の役に立つ仕事のおべんきょおがしたいんですよ。なのに図書館で借りられる本、自分が何を知らないから理解できないのかもよくわからない感じで……
日経Linuxとか読んでみて、去年のやつにプロセスとかスレッドの説明あったけど、僕はまだOSの基本的な話もマトモに理解できていないなので、
そういう人間には難しすぎる (というか抽象的すぎてかなりわからなかった) スケジューリングの話はされたので、プロセスが対象なの？とか、そもそもCPUがアセンブリ命令ADDとか？を実行しつつ、
OSがそのアセンブリ命令をセットにした実行単位を用意して、OSがスケジューリングしてくれる、みたいな話なのかな……？ と思った
(でも明らかにプロセスとスレッドがわからない人間には伝わらないような程度のフワフワ説明しかなくて、これ、誰向けだ？とか思ったけど、やっぱり身近に聞ける人間がいる人のための本なのかもしれないですなあ)。
そういうの、本とか、自分の足りない知識とか、おそらくその辺にあるんだろうな～と思いながら、でもバイトで働くにも微妙にプログラミングの知識が必要で、「これまで何作ってきましたか？」と言われても、
そういう、あんまりしっかりしたものを作ったことないし、C言語、gccで可変引数までやって、でもアセンブリがどう実行されるんですか、という話はよくわからない。
Javaも習って、まあそれっぽいお話はいっぱいされたんですけど、アプリ作るの難しかったし、GUIはクソだね、というか、手打ちでやったんですけど、こんなん絶対手打ちより良いやり方ありますやろと思いながらやっていた。
絶対手打ちより良いやり方あるはずだけど、僕は知らんし、知らない以上何が効率的に作れるのかもよくわからないし、わからないことにはできるだけ手を出さない方がいいな、と思う。
いや～なんつーかこういうことばっか書いてると「甘えんなカス。氏ね」とかコメントされて、2000回くらいは殺されちゃうんですけど、それは甘んじるとして、でも何というか……みんなそうなんですかね。
同年代で「めちゃくちゃプログラミングできちゃいます！(漠然)」みたいな人間いるけど、僕が例えばどういう本読んでどういう道筋を歩んだらそういうカンジになれるか、かなり見えなくてつらいし、
そもそもそういうのを職業にできるスキル高く磨けるような人って、いったいどういう生き方してきたらそうなるんだろう、と思っている。
これで情報系の研究室いって、なんとか乗り切って就活して、プログラムがんばって書きましょうー！というような職場に行ったら、
それはもう「学生じゃないんだから。もう社会人なんだから自分で調べて」となるんですよね。マンガとかでたくさん読みました。それは死ぬほどつらいでしょ。現に人死んでるじゃないですか。
結局周りに聞ける人間がいる環境ってなに？ 今もいないし、大人になってもいないんでしょ？ だからはてブで「プログラマーはやっぱ自分で本読んでスキルアップしなきゃ死ぬぞ！」みたいなやつがホッテントリになったりするわけでしょ？
それはつらい。ご本読んで理解できないの、というか読めてないの、ウチにあるだけで目が上滑りして「全体像がよくわからないからな～ しょうがないよな～～」と言いながらろくに読む気も起きなくて、
「でも本当に役に立つ本って開いた瞬間に読みやすいのでは？」みたいな信念がある。 これが原因なのかな。でも、この信念、少なくともこれまでめちゃくちゃ役に立ってきたものなんだよなあ……。
学生の今、自分が考えてて不安に感じてることが、「追いつけない」みたいな不安が、イマイチわかり切ってないし、
だから具体的な質問として一言で言える話の羅列としてわかってないわけじゃなくて、もっと漠然とわからない。こういうこと感じてるの、僕だけじゃなくてパソコン知りてえ～～となって大学に来た人のうちけっこう多いような気がするんですよね。なんか生半可に甘えた環境だから。
----------------------
とりあえずこれ書いてたら少し気分落ち着いたので、要点をまとめると、
「本で勉強するのつらいよなあ～ そんなんじゃどんな分野行ってもつらいだろうなあ～」
ということです。
そういう有象無象の本をスパッスパッと切って、「この辺のこの本読んどくとこういうことができるようになるだろうな～」というモデルがまだあんまりできてない。
そういうのができるようになるのかと思ってたらあんまり学校でも学べる感じじゃない。全体像とは……となっているけど、こういう悩み、自然に解決したりしなかったりするんだろうな。
とりあえず、これは自分メモの今後の方針です。OSより下の階層、たとえばALUとメモリの組み合わせで、program counterを進めながら動いてるんだよーという感覚はあるので、
それがOSとどういう風につながってるのか、とか、100均で売ってる電卓、あのデジタル表示の部分がどういう仕組みで動いてるの、ということを考えたり、
インターネットプロトコルでパソコンが具体的にどういうパケットを送信しているんだろう、というような話を攻めて、これが全体像とやらが見えるようになる一助になるかはわからないけど、
できるところからできるところだけ勉強していきたいと思います。それが、僕にとって、よくわからない本をじっと読まなきゃいけない義務から抜け出した罰の引き受け方っぽいので。
http://anond.hatelabo.jp/20150210030728
はてななどのブログに限らず、技術書には程度というものがあって、それぞれに用語がある。
ページや文書には必ず限りがあり、専門用語を使わずに記述すると非常に手間で、読むのに時間がかかる。
それらの専門用語を理解するために、初学者用の書籍や記事があるけれど、専門用語を知って学習することは読者のレベルに委ねられていて、読者層を限定していることになる。
リンク先の記事を書いている人は、「皆がMacを持っているわけじゃない」と書いているけれど、WindowsにもUNIXライクな環境を揃える方法はCygwinやGowなどいくらでもあって、gccやmakeのような基礎ツールがあればほとんどのOSで実装できる。
今やプログラミングといえば、Webなどで使われるような高水準スクリプト系言語中心のアプリケーションプログラミングが主流だ。
そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である。
そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。
少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。
大学で初めて触ったC言語しかもポインタ分からないで止まっているような奴に、電文の再配信プログラムを任せたのだから。
客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。
このうちC++は、Java経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。
勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。
あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。
コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなものは絶対に必要である。
その時のルールは「gccのオプションに"-Wall"を入れた状態で、Warningゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。
というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様はコンパクトである以上に原始的と言っていい代物で(だからWarningは基本無視できないのだ)、しかも言語仕様以外の環境依存要素が山積していると来たもんだ。
そんな言語でシステムコールだらけのコードかつ複数のファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかもマルチプロセスでシグナルもあるよ！とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。
仕方なく最初のKRに加えて「UNIXネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。
後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。
そこまで凄い良書なのになんで絶版になったんだか。
いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。
シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか！と途方に暮れたこともあった。
そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。
結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分の仕事ぶりには全く満足していない。
無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッド、malloc()、可変長引数は遂に習得できなかった。
こういうプログラムって、どうやったら正しく動かせるんだろ。
このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が
Cはとても高効率ですし、マシンのリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルのリソース管理（たとえばメモリ管理）を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります。今日のマシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシンの時間を少し非効率に使っても、あなたの時間をずっと効率的に使う言語を使うほうが賢明でしょう。
本物のプログラマはアプリケーションプログラムなど書かず、まっさらな金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。
あと、あれほど苦手だったポインタについても、「ポインタが理解できないと永久にC初心者」というのを嫌でも理解した。
あれはギターのFコードやSEALsのヘルウィークみたいなもので「習得できなかった者にとってはキャリアの終わりを意味するが、習得できた者にとっては始まりですらない」ものなのだ。
・・・で、これだけで終わってしまうと本当にタダの黒歴史だが、これには少しだけ嬉しい後日談がある。
それから数年後、やはり電文転送系のシステムで、かつて自分がCのソロプレイでこなしていた規模の数万倍はあると思しき超大型案件に助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分は
「配列とポインタと構造体しか使わないで済むなんて、なんて楽な仕事なんだ！」と左うちわでのんびり過ごし、しかも高評価をいただいて帰ってこれた。
会社で貸与されたパソコンがVISTAだった。Windows触るの、2000以来なんですけど。 今までマカーだったので。久しぶりに触ります。なかなか新鮮。
でも、ずっとまえから不便だなーと思ってたことがそのままでワロタ。あれわざとなんですかね。仕方ないのでautohotokeyで1日がかりでそこそこ使えるものにしました。。
なんというかWindowsの悪いところ全然なおってねーじゃん。レジストリって今でもあるのね。記憶に間違いがなければあれって確かDOS時代の設定ファイルでファイルがでかくなったから仕方なくDBにしたやつでしょ。あんなのまだ使ってるとか。
OSXはそそもそもUN*X環境なので使いやすいが、WIndowsのCygwinは管理者権限いるのね。最小インストールなら入るけどgccすらインストールできないから段々使わなくなった。rrsyncしたいのに。
地味にフォルダを作るショートカットがない。あるけどALT+w - w- f でしたっけ？ めんどいわ。そういやドザの人がWin+Dがショートカットで一番便利って聞いたので使ってみたけど元に戻せないワロタ。ウインドウをたたむのはいいけど元に一発で戻らないのか、これ。
そんなんより何が驚いたかって日本語入力のIME切り替えるのにALT + 英数が未だに使われてるのね。あれ罰ゲームか何かだろ、日本のGDP下げようとしてるだろ。今どきトグルｗしかもめっちゃキー遠い。
くっそ効率悪いので右ALT＝にIMEオン、左ALT＝IMFオフを割り当ててた。
仮想デスクトップとかもないし。これはVirtuaWinをを入れたら作業効率が倍増しました。設定がちょっと面倒です。
あとF1とかINSとか間違って押したら面倒なんですけど。これもキーバインドで殺した。一番いらないのがCAPSLOCKだよなあ。まあこれはMacにもあるけどAirみたいに隅っこに追放して欲しい。Aの横はCtrlがいい（キーバインドで直した）
え？大文字ばっかり打つ時がある？そういう時は小文字で書いたあとvimでggVG+U押せば全部大文字になるよ。
あと、ウインド閉じる共通のショートカットないのね。これすごくない？ アプリ依存て。イベントはあるのにショートカットはないっていう。仕方ないのでWin+qでウインドウ右上の「ｘ」印を押した時と同じ挙動をするようにしたらすごく便利になった。
マシンがめたくそ重たいので、タイトルバーとかフォントのデザインをXPにい似た感じ（クラシック表示ってやつ？；）にしたらかなり軽くなった。CPU/GPUが追いつかないならそんな機能いらねーよ。なに考えてるんだ。
それから画面ロックがWin+L固定でここれ地味に両手使うのでマウスの中ボダンにバインドしといた。席を立ってからロック忘れに気づいてもマウスをぽちっとするだけでロック状態になる。便利。それからCtrol+Alt+Delをt同時に送信するボタン買った。結構便利。
他にも何か解決してないクソなｼ仕様がある気がするけど、今のろまあまあ快適につかえている。前はmayu使ってたけど、AutoHotKeyいいね。
そうそう、キーボードのNumLockをOFFにしてバーチャウインドウの切り替え（１,３,７,９）に使ってるんだけど、（Shift＋Numキーだとアクティブウインドウだけ対象デスクトップに送る）これがが直感的ですごく便利。おすすめ。テンキーとして使う時はNumLockをONにするだけ。テンキー頻用 する人には向かないかな？俺はほとんどテンキー使わないので。
＝＝トラバうけて追記＝＝
まあ久しぶりに触ると悪いところが目立つって話ですよ。フォルダ作るのとかShit+Ctrl+Nでいい気はするけどねえ。逆にWindowsはCtrl+Alt+Delのようなシステムに割り込みをかけてマルウェア防いでるけど、Macだと「全画面モードです」とかしかでなくてあれで騙される人居そうで他人ごとながらちょっと心配になる。WinからMacに乗り換えても同じようにDisると思うよ。でもUN*X使いとしてはシェルのコマンドがほぼほぼ使えるMacがいいかなあ、やっぱり。
あと今更VISTA？ は俺が一番いいたい。貸与されたものがそうなってて管理者権限ないんだからどうしようにもないだろ。これフォーマッt-して別のOS入れたらそれだけでイントラに繋がらなくなるし。
リチャード・ストールマン（Emacsやgccの開発で知られる著名なプログラマ）
It doesn't take special talents to reproduce -- even plants can do it. On the other hand, contributing to a program like Emacs takes real skill. That is really something to be proud of.
子孫を作るってのには大した才能は要らない。植物でさえできることだ。 それに比べてEmacsのようなプログラムに貢献するのは誇るに足る本当の才能だ。
もっとたくさんの人を助けることになるしね。
そりゃあたかがPCの事だし、悩んでるほどでは無いけど、事有るごとに、よく考えるんだよね。
職業はソフトウェアのエンジニアで、日頃から、Unix(Linux)環境で、仕事でもプライベートでも
似たような環境をいじり倒してるわけなんだけど、結局いつもスルーしちゃうんだよね。
理由は、Mac に できることは Unix(Linux)ででも、できてしまうってゆう理由なんだよね。
もちろん、mac が なきゃ 素直な iphone アプリ作れないとか、objectivec にしても
gcc のとは 多少、違うくらいのことはわかってるよ。
で、また、思い立って、ここにこんなこと書いているのは
増税前ってのもあるから、今回は 日頃から、バリバリ使っている人の率直な意見を聞きたいなと思ってね。
僕の背中を後押しするような、意見でも、躊躇させるような意見でもいいから
もらえたら、ありがたく、参考にさせてもらうよ。
例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。
Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。
Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)
-----
昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。 それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。 その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。 そして現在、俺たちはその誤った情報を正すステージに来ているんだ。 ほらここに、Appleのbugがあるんだ。：
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }(Quoted from Apple's published source code.)
(訳者注：(Quoted from Apple's published source code)→sslKeyExchange.c) 2行のgotoがあるだろ。 2行目のgotoは、見て分かる通り常に発動する。 変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。 それって成功したのと同じなんだよね！ この署名検証処理は(訳者注：SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。 このServerKeyExchangeでは、"the ephemeral key"（通信のための一時的な鍵）を交換するためのDHE や ECDHE という暗号スイートが使われる。 そのサーバーは言うんだ。 「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね！」 今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。 これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った（つまり適当にその辺で作った）鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ！ そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。 これはSecureTransport(というライブラリ)に入っていて、以下に影響する。 ・iOS 7.0.6より前(俺は7.0.4で確認した) ・OS X 10.9.2より前(10.9.1で確認した) (訳者注：つまりiOS 7.0.6、OS X 10.9.2で解決した) これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。 ChromeとFirefoxはSSL/TLSのためにNSSを使っている。 でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね) 超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266 ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ) 443は通常通りに動いているからね。 ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。 君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:) それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。 またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。 攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。 また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。 でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。 (訳者注：サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。) でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。 同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。 (2つのうち、1つ目のほうがだいぶ好ましい。) 俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。 (更新：このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。) こんなような微妙なバグって、悪夢だ。 俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。 ここに、今回の問題を明らかにするコードがある。：
extern int f(); int g() { int ret = 1; goto out; ret = f(); out: return ret; }
もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。 本当にビックリだよ！！！ ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。 (ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない！) if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。 でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。 テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。 TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。 俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも) コードレビューはこの種類のバグについて効果的でありえる。 ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。 Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。 でも、誰もがそんなにいい仲間を持てるわけじゃないよね。 最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、 それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。 Safariはこの問題には関係なかったよ。
