「gcc」を含む日記 RSS

はてなキーワード: gccとは

2019-10-06

コンピュータ人格障害退職エントリ

近年,人格障害者の関係していると思われる事例をネットで見かけることが多くなってきた.例えば

また一見すると分かりにくいが以下の比較的有名なプロジェクトにも人格障害者の関わっている痕跡を読み取ることができる

gentoo linuxの昔のドキュメント(もう残っていないらしくリンクを見つけることはできなかった)には,gentoo linux前身となったFreeBSDベースになっているプロジェクトが,人格問題のある人が開発に関わった結果,頓挫した話が記載されていた.

このドキュメント人格障害という言葉一般に知られるようになる前に書かれていたため,人格障害について明確に記述されてはいないが,どう見ても人格障害者の関わった事例であった.おそらく人格障害について広く知られるようになってから削除されたのではないか想像する.

人格障害とnon-BPDとは?

ここで人格障害について知らない人のために解説をしよう.人格障害という言葉が広く一般に知られるになったのは,この本が原因ではないかと思う

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などの人格障害について解説する本では,人格障害者の多くは自分普通の人と認識していることが述べられている).

検索するのは被害者であるnon-BPDの人達である

SWEではBPDの原因の1つとして幼児期の過剰な甘やかしを挙げている.幼児が泣いて両親がすぐに何かしてしまうと,泣けば自動的に世話してくれる自分の手足の延長として他人認識してしまう,というものである

この状態のまま大人になると他人自分の世話をするのが普通という認識が固定される.大人場合は泣いたりできないので,かわりに嘘や脅しで他人を(手足として)操作するようになる.嘘つきというのは人格障害の肝となっている.

人格障害者の見分け方として嘘を誤魔化すためにさらに嘘をつくのは人格障害である,と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 linuxFreeBSDと同じ「再攻撃」を受けたはずであるが,うまく乗り切っているようだ.non-BPDの多くの人達は「人格障害者と一度かかわるとある種の直感が鋭くなる」と言っている.直感で事前に危険を察知して予防できるようになるそうだ.最初に述べたlibavやsystemdに人格障害の関わりがあるという根拠も実は私の直感であってうまく説明できない.ただ,オープンソース人格障害の両方の知識があるならば,みんな同じ判断を下すだろうと思う.SWEも「良心をもたない人たち 」でも直感重要性について述べている.

BPDやサイコパスなどの人格障害について一般向けに解説する本の多くは事例の紹介が中心になっている.人格障害者本人が普通と思っている状況を維持するためにつく嘘や様々な行動は,工夫が凝らされており完全犯罪に近い.

普通は思いつかない工夫に満ちた方法が使われるため単純に類型化できないのもあり,個別の事例を紹介するしかいからだと思われる.とはいえgoogle trandの傾向からわかるように,BPDについて知っている人は増加傾向にある.

人格障害とみなされない(見破られない)ためにさらに巧妙な手段が近年は必要となってきている.ここでも人格障害を見破るために重要となるのは直感である.ここで直感というのは具体的には「良心をもたない人たち

」では「何かが変」と感じたら騙されている可能性が高いと言っている.

ただ直感でかたずけられてしまっては.なかなか気が付けない人も多いと思うため,ここでは近年巧妙になった人格障害者の手口について自分の気が付いた範囲で述べていこうと思う.

(と思ったけど気力切れ)

先に紹介した有名なオープンソースプロジェクトについて解説しよう

(と思ったけど気力切れ)

SF映画人格障害

ハッカー画家人格障害

日本における人格障害者との対峙方法

2019-04-04

こうすればプログラミング覚えられるよ【随時追記

プログラマじゃないけどプログラミング完全に理解した()おばさんが理解してる基礎知識書くよ。

追記 この文章プログラミング勉強をしたいけどその周辺にある基礎知識になかなか触れる機会がない人向けに書きました。これらの基礎知識があると、困ったときに調べ方すら分からないという状況は回避やすくなるはず)

まずLinuxUnix系OSの使い方。

ターミナル、いわゆる黒い窓からCUIコマンドユーザーインターフェース)でコンピュータを使う方法を覚えよう。これは大学コンピュータリテラシーで習った。MacOSXで復習すると捗った。(追記 すごく間が抜けてたけどMacOSXUnix系OSです)

まずはファイル操作Macターミナルを使って、cd Desktopって打ってからecho ohayou > aisatsu.txtって打ってみて、cat aisatsu.txtってやる。そうすると何が表示されるのか?とりあえずやってみよう。ここで>は増田の都合上大文字全角にしてるけど、ちゃんと半角にしてね。なんで増田の都合上半角がダメなのか、そのうち想像できるようになろう。(追記 ブコメ指摘感謝

そして、実際にデスクトップを見に行ってみると、aisatsu.txtってファイルがあるはずなんで、開いてみよう。これで何が起こったのか7割くらいはわかるはず。

こういうファイル操作の基本をまず覚えよう。これこそ空気みたいなものから

追記 ここも間が抜けてたけど確かにhogeって何かわからいね。直しました)

次に文字コードバックスラッシュの話。

最近は何も考えなければ文字コードはとりあえずUTF-8でなんとでもなるようになってるけど、バックスラッシュとかは環境設定で出てくるように設定しないと出てこないし、その意味合い、つまりエスケープとしての使い方を頭に入れておくと後々困らないと思う。あとEOF(エンドオブファイル)とか改行コードとかもそういうものがあるよ程度には覚えておこう。これ頭の片隅にはいってないと分からん殺し的な罠にはまることがある。

次にプログラミング環境の構築の仕方。

これは使いたいプログラミング言語公式サイトに行くと大抵書いてある。

でもMacだとだいぶ楽。とりあえずターミナルからgccって打ってみるとなんかCUIツールとか書いてあるものインストールしろって言われるのでインストールする。これだけでCとかC++とかRubyとかPythonとか一通り使えるようになる。もしかしたら最近はこのインストールすらいらないかもしれないけど。

あと、シェルコマンドとかプログラミング言語を実際に使うときはいろんなライブラリインストールする必要があるけど、そのライブラリ管理がすごく面倒なので管理をまとめてくれるコマンドがあったりする。aptとかhomebrewとかがそういうのだから、そんなものの使い方も覚えておこう。

追記 言語文法を追うだけなら環境構築なんてしなくてCloud9とか使ってもいいかもだけど、プロダクトを作ろうとした時にはまだまだ手元で環境作って必要ライブラリを入れてとやった方が後々応用がきくと思うのですよ。それにそうしていくとDockerの有り難みなんかも理解できるようになっていくのではと思います

最初勉強するプログラミング言語は、Javaだけはやめておけ。

なんでかっていうと、Javaオブジェクト指向言語ってやつなんだけどオブジェクト指向的にしか書けないから。古い人間だと言われそうだけど、最初手続き型言語から始めるべきだと思ってる。少なくとも、手続き型的に書ける言語から始めるべき。

なぜそう思うのかも含めて、とりあえずおばさんが理解しているプログラミング言語の発展の経緯を軽く解説する。

最初の頃のプログラミング言語は、手続き型と呼ばれるものが多かった。

この〇〇型ってのはプログラミングをするときの考え方によって名前がついているんだけど、手続き型はまず0を作って、0に1を100回足して、最後にその結果を表示してください、みたいな、上から書いた順番通りに動くのが基本のルールである考え方。プログラムは基本的にはこうやってデータアルゴリズムを使って変化させていって望む結果を得ている。でもこのやり方は問題も多かった。プログラム全体がひとかたまりになってしまっているので、数千行とかになるともう普通の人では手がつけられないし、人間ミスデータを間違って扱ってしまうことがバグの温床になった。

なので、この手続き型の考えに構造化という考えが加わって、関数というものが生まれた。関数っていうのは料理レシピに例えるとわかりやすいかも。

関数が無い状態だと、

1:玉ねぎをくし状に切ります

2:キャベツをざく切りにします。

3:豚こまに塩胡椒で味付けをします。

4:フライパンを火にかけ、油を入れて熱します。

5:豚こまを入れて色が変わるまで炒めます

6:玉ねぎを入れます

7:キャベツを入れます

8:野菜がしんなりするまで炒めます

9:火を消して8をお皿に盛り、野菜炒めの出来上がりです。

と書いていたものが、関数がある状態だと、

A:野菜を切ります

Aのやり方1:玉ねぎをくし状に切ります

Aのやり方2:キャベツをざく切りにします。

B:肉に味付けをします。

Bのやり方1:豚こまに塩胡椒を振ります

1:フライパンを火にかけ、油を入れて熱します。

2:Bを入れて色が変わるまで炒めます

3:Aを入れてしんなりするまで炒めます

4:火を消して3をお皿に盛り、野菜炒めの出来上がりです。

って書ける。ここではAとBが関数

この程度だとあまり意味を感じないかもしれないけど、これがもっと複雑なもの想像してみると、なんとなくありがたみが分かって来ないだろうか?こうすると、多人数でプログラミングをするときに、Aを書く人、Bを書く人、1〜4にまとめる人って感じで作業分担ができる。それに、バグが起きた時もAの領域バグったのか、Bの領域バグったのかとか、全体にまとめると上手くいかないのかとか、原因の切り分けがやすい。

でも、プログラムがとっても複雑化すると、これでも手に負えなくなる。料理の例えを拡大すると、料理店を運営することを考えるといいかも。

料理店でたくさんの料理をさばくときに、レシピを完全に1から作ることってないと思う。Aさんが野菜の仕込み担当、Bさんがスープの仕込み担当、というように各人に仕事が割り振られているはず。AさんもBさんもそれぞれの仕込みのレシピを持っていて、最終的に出てくる仕込みがちゃんとしてればAさんBさんの仕事の詳細までいちいちシェフが細かくチェックしない体制になっていると思う。大雑把にいうとそういう考え方をプログラムで再現したのがオブジェクト指向言語

なので、本気で料理初心者がいきなり厨房の仕切りを任されて上手くいくのは難しいように、構造プログラミングのありがたみすらわからない段階でオブジェクト指向プログラミングに手をつけても意味わからんだろうと思うのがおばさんの立場です。

追記 おばさんはRubyを勧めておきますオブジェクト指向言語ですが、手続き型的に書き下すことも出来るからです。一つの言語手続き構造オブジェクト指向、全部勉強できますメソッドも便利なのが一通りあるし、日本語を扱うのにも問題が少ないです)

次に問題を分解できるようになろう。

例えば、クイズゲームを作りたいと考えたときクイズゲームを作りたいです、って問題は大きすぎる。

クイズゲーム必要な要素は、問題文を表示する、回答を入力してもらう、正誤判定をする、正誤判定の結果を表示する、ということだなぐらいにまず分解する。

これを実際にプログラミングしようとすると、もっと分解できてさら問題が見えてくると思う。

コンピュータってのは創造的なことはできない代わりに、とても簡単なことをとても階層的に重ね合わせて大きな問題を解けるように作られてる。それを心するといいと思う。

からないことは調べられるようになろう。最後はこれ。

これ超大事プログラミングって本当に自分で1からものを考えなきゃいけないことってあまりない。大きな問題あなただけの問題かもしれないけれど、それを構成する小さな問題は大抵他の誰かが解いている問題なので、調べてみれば答えが見つかると思う。

エラーメッセージが出てきたらまずググってみる。翻訳しても初心者には意味がわからないし、ググったら誰かが解説付きで紹介してくれているのでその解説を読んだりしながらエラーメッセージとの付き合い方を覚えていけばいい。

メソッドの使い方がわからなかったら言語公式サイトに行ってみる。メソッドの使い方で大事なのは呼び出し方、返ってくる値の型とかそういうのだから、こういうところはググるよりも公式サイトに書いてあることをしっかり読んで理解する。

あと、アルゴリズム勉強もしてみるといいと思う。アルゴリズムデータ構造計算量の勉強大学学部レベル教科書ちゃんと読んでみると、例えばデータベースを操作するSQLというものを書くことになった時とかに効いてくる。あとは作ったプログラムが遅すぎてどうしようとかいうのを解決する時とか。

なんか深夜までいろいろ書いてしまったけど、あくまでもプログラマじゃないおばさんが書いたものなので、みんなでツッコミとか入れてくれると大変助かります

増田怖いよツッコミ怖いよ、もちろんおまんじゅうも怖い。

2019-01-20

C++人生台無しにした。

柴田望洋先生明解C++

STL標準講座

テンプレートテクニック

・Effective C++

More Effective C++

・Modern Effective C++

C++ポケットリファレンス

・入門Qtプログラミング

実践Qtプログラミング

・Effective STL

Boost C++ Librariesプログラミング

オブジェクト指向における再利用のためのデザインパターン

C++ テンプレート完全ガイド

OpenCV for C++

・大規模C++ソフトウェアデザイン

MakeGitなどコマンド系の技術書 複数

・Database系の技術書 複数

ネットワーク系の技術書 複数

Linux系の技術書 複数

Windows系の技術書 複数

自作ハード系の技術書 複数

・他の言語技術書 複数

15年かけC++を独学した。

上記書籍を何度も熟読し、

C++実装も規格書も、C++によるライブラリ実装

Boostソースコードも常に読むよう心がけた。

土日も祝日も平日朝も平日のしごと終わった後の夜も、

ずっと一人で努力し、風呂トイレ、布団の中でも勉強し、プログラムを書いた。

基本情報処理ソフトウェア開発者試験ネットワークスペシャリストとデータベーススペシャリストを取得した。

しかし、正社員はもとより、時給2000円の派遣プログラマも時給1200円のアルバイトスキル不足で何十社受けても一社採用されない。

とはいえ面接官のレベルは「STLなんて初めて聞いた」「gccて何かの会社?」

C++企画書(誤字ではない)を書いてる人なんてのがいるの?」

「じょーほーしょりしけんてのがあるの?外国の話?」

といったもので私の実力は全く理解されていなかったのだが。

独身で、一切を我慢して娯楽を全く体験しないまま40歳になってしまった。IT業界人間すべてが恨めしい。

貯金100万もなく、素人が書いたプログラムに対して手順書のとおりにマウス操作してエクセルテスト結果を書くだけの仕事ばかりしている。

C++じゃなくてCかC#Javaか、とにかくC++以外だったらこんな事にならなかっただろうに。

何の意味もない、苦しかっただけの、最悪の人生になってしまった。

2018-10-30

【試した環境2】 Ubuntu 17.10 64bit



1. 作者が用意したスクリプト 01downloads の apt install 部分で修正必要なようです。

 emacs24 はリポジトリになかったので,代わりに emacs25 を入れました

 gcc-4.9, g++-4.9, cpp-4.9 はリポジトリにありません。

2. CASINO の makeエラーが出る

 エラーを見るとFortranで止まっていたので,入ってないのかな?と思って調べたら(Synaptic パッケージインストーラにてgfortran検索した),入っていませんでした。おそらく,gcc4.9が入らなかったからだと思います

 gfortran, gfortran-doc, gfortran-multilibをとりあえず入れてみたら動きました。(ついでにgfortran7類も入ったようです)

2018-10-07

ラズベリーパイgentooprofileを変えてうどんワールドしたら

めっさgccビルド時間かかって数時間止まってる。

このために用意されてる時短用のクロスビルディングとやらもgentoo環境が別で必要なのか?

いつ終わるんだ?

2018-06-24

プログラミングを何から始めればいいのか悩む

プログラミングってこれから時代必要っぽいし、なんとなくイケてるスキルっぽい。

ゲームとかアプリとか作ってストアで公開とかしたら就職とか転職めっちゃ有利じゃね?

俺はこういうのが出発点で良いと思う。

でもプログラミングを始めようとすると「何がやりたいの?」と聞かれてソッコー詰まる。

俺は「何をやればいいの?」って思って調べてるつもりなのに「何がやりたいの?」って突き放される。

ここで混乱して立ち止まってしまう。

でも一呼吸おいて、初心者とそれ以外の間に生じる認識の祖語について1つずつ解消しなければ先に進めない。

俺はプログラミングを覚えるということは、何でもできるようになることだと思っている。

でも先人たちはそのようなスキルをすぐに教えてくれない。それどころか「何をやりたいの?」と言って、他につぶしの利かない小さな範囲知識を与えようとしているように見える。

アプリ作りたい」と言えば、どんなアプリ?という問いが続くし、特定の具体的なアプリしか作れないような知識しかもらえないだろう。

どういうことか?

試しに「何でも作れるようになりたい」と言ってみると「じゃあC言語やろうぜ」とか言われる。

C?いまさらCで何作れるんだよ。AndoroidアプリJavaじゃないの?C関係ないでしょ!?Cでスマホアプリウェブサイトも作れないじゃん!何言ってんの!?


スマホアプリ作りたいの?じゃあJavaでいいじゃん」

ち・が・う!何でも作れるようになりたいの!あんたみたいに!Visual Studioだろうとgccだろうと、cとかc++とかc#とかjavaとかpythonとかrubyとかphpとかテンサーフローとかhtmlとかjavascriptとかjqueryとかgoとか駆使してたくさんウェブサービスとかアプリとか作りまくってるあんたみたいに!

「じゃあ今挙げたやつ全部やれよ。ちなみに今の俺は10年以上プログラミング勉強してるから。10年後今の俺になったところで、俺はさらに10年積んでるからな。一生追い付かんな」


から今すぐ追いつく方法教えてって言ってるの!


「じゃあ今、あるいはこれから使えるものを重点的にやっていくしかないな。で、何がやりたいの?」


何がやりたいのってどういうこと?むしろ何ができるの?


アプリ作るとか」

わかった!じゃあアプリ作るわ!

「どんなアプリ作るの?」

…………どんなアプリ作れるの?

「ストアにあるようなやつ」

じゃあFGOみたいな……

「お前には無理だからw」


はぁっ!?ストアにあるようなやつって言ったじゃん!






そこでまた数回やりとりが発生して、プログラムを書くコストとかスキル問題について再確認することとなり、

現実的に俺個人が支払えるコスト範囲で、何を作れるようなスキルを取捨選択するかという問題になり、

結局は教科書サンプルをちまちま作っていくしかないのではないかというつまらない結論脳裏に浮かぶし、

その道筋でさえ結局何年も積む必要があり、そのころには別の言語とか開発環境が主流になってるかも……

「そこだよそこ」

えっ?


「まずさ、日本語教科書を読むには日本語必要じゃん?それでも国語辞典とかwikipedia調べながら知らない単語概念は別途補てんする必要がある」

う、うん。

プログラミング教科書とか風潮を読むにはプログラミングの基礎が必要。それに加えて、作りたいものに合わせて新規に開発環境なり言語なりを学習することになる。だから何でも作れるようになりたけりゃ、この世の全てを体得する必要があるけど無理だろそんなの」

え、えー

「でもいくつもの開発環境言語を使って、ソフトウェアをいくつも実際に作ってると、基礎的な引き出しは大きくなるし、追加で新しい環境とかを学習する要領もつかめてくる。何年も積み重ねがあるとなおさらね。するとより少ない労力で新しい技術追従できるし、新しい開発環境アプリの分野でもサクサク作ってるように見える。それが、お前の言うところの『何でも作れる』ように見えるものの正体さ」

なんか夢から覚めた気分。

FGOを作りたいなら、FGOをかみ砕いて、自分ならどういうアレンジでそれっぽいものを作れるか考えて、その過程自分能力とか限界を見極めていく必要がある。でもそれは結果論であって、最初は作りたいものをひたすら作ってみるしかない」

ふーん

「何度も聞くけど、何が作りたいの?FGOならFGOでいいよ。やってみろよ」

どうしよっかな……(頭を抱える)

2018-05-30

anond:20180530060133

問題ありまくりだろう。

ソースコードコンパイルに失敗した場合は例えgccだろうがなんだろうがコードの内容はどうあろうがエラーを出力する。

コードが壊れているかどうかは重要ではなく、それに対して何をどう向き合ったかであって

あの記事の中身のコードがどんなコードであってもコンパイラがなんであっても本質には全く影響を及ぼさない。

たまたま環境unityだっただけで、unityがその辺エラーを吐かないかというと吐いていたし見えない筈はなく、英語なので読めないということはあったかもしれないがそれはgccとて同じことだ。

何がその文章から読み取れるものの中で本来重要ことなのかで自ら「全く重要でないもの」を把握できておらずともすれば詭弁とも取れるunitySAGEたいだけに見える駄記事じゃねーか。

第1、例示されてる部分だけではそもそも動かんのやぞ。書き換え、誤魔化しがあるのはバレバレじゃないか

2018-01-28

会社PCEmacsインストールしたったwwww

ひとまず以下のコマンドを実行して、インストールできたっぽい。

次なにしたらいい?

sudo yum install -y ncurses-devel make gcc
cd /usr/local/src/
sudo git clone https://github.com/vim/vim.git
cd vim/src
sudo make
sudo make install

2017-06-10

日本リベサヨが終わってる理由(ホシュウヨが安心してていい理由

1

2017英総選挙:コービン労働党まさかの躍進。その背後には地べたの人々の運動(ブレイディみかこ) - 個人 - Yahoo!ニュース

http://b.hatena.ne.jp/entry/s/news.yahoo.co.jp/byline/bradymikako/20170609-00071923/


ブレイディみかこはバーニーサダースやコービンにずっと注目して来た人で

「右と左ではなく上と下の時代になってきてる」という視座も前から繰り返し言ってきてる。

海外での左派の躍進成功例や、成功まで行かなくとも希望の芽と見られる事例の紹介をずっとしている。

本当に下に信頼される知性と政策努力があれば左派は勝ち、しか継続的に世の中をよく出来るはずだと。

これは説得力がある。

日本でコツコツと正攻法自民党を倒す努力方向性があるとすればこれだろう。



けどブックマークコメントを見ればわかる。

日本リベサヨは終わってるし、

からみかこが紹介するような何かが日本に伝播することはないし、

日本のホシュウヨは何も心配しなくていい。



はてサコメント

nabeteru1Q78 非常に良い記事だと思う。サンダース。コービン。日本左派が見習うべき政策も、運動のあり方も、恐らくそこにある。 606 clicks

リンク2017/06/10 Add

星4つ、人気7位

Gl17 『高齢者冷遇する政策を取れば、「自分たちは損をしている世代」と感じている若者たちが満足すると思った』老人ムシれとか、

正社員厚遇過ぎとか言ってばかりな、どっかの国のネット俗論ぽい。我慢大会が続く訳だ。

リンク2017/06/10

星15、人気2位(はてサ1位)


わかるだろうか。

とりあえず口でだけでも「我々も見習わねば!」と言うはてサはてサ人気すらいまいちで、

なんとかかんとか「ネトウヨガー」「日本人ガー」を安定出力するはてサはてサには圧倒的人気。

今回nabeteru1Q78の発言特別知的だとか殊勝だというよりは、

左派の勝ち筋紹介」という記事の本旨を一切迂回して日本の俗論叩きに話を持っていき終わらせるGl17の強い方向性と技巧が光る。


2

この記事に限らず、

nabeteru1Q78とGl17で圧倒的にGl17の方が人気なのがはてサ(引いてはネット左派)の限界の全てだと思う。

nabeteru1Q78も感情的で先鋭的な発言はちらほらあるけど、全体的には知的であったり現実的アクションに繋がる話をする。

Gl17はまさに「ネトウヨガー日本人ガー!」みたいな当てこすりと癇癪爆発の発言だけをする。

そこから自分達の取るアクションみたいなものが一切見えないのがGl17ブコメの特徴だ。


安倍晋三を降霊して眺めるならば、

手強いのは圧倒的にnabeteru1Q78であって、Gl17はむしろ小遣いやって支援したいぐらいだ。

nabeteru1Q78は仕事が出来そう。Gl17はまともに仕事に取り組んでなさそう。

でも人気が出るのは後者


要するに過半数はてサリベサヨが望んでいることは

現実を変えていくこと、自分理想に沿って世の中をよくしていくこと」ではなく、

実は「とにかくアベシンゾーを倒して民進か共産政権を持たせること」ですらなく、

まりは「自分の思い通りにならないと決定してる現実に拗ねながら恨みごとや当てこすりを言い続けること」なのだ


ブレイディみかこのように「左派希望」を見せてくれる記事は、

nabeteru1Q78には喜びであり検討すべきロールモデルかもしれないが、

Gl17にはい迷惑であり、なんならちょっとウザいのだ。

だって、そんな記事左派希望も見せてくれるが、左派自身努力改革を求めるではないか



それじゃ困るのだ。

Gl17ら主流派はてサは、現実での勝利の為に自己批判自己改革なんか1ミリもしたくないのだから

彼等にとって最重要なのは「常に説教する立場にいること」それが無理なら次点被害者として恨みごとを叫べる立場に居ること」だ。

仕事の出来そうなnabeteru1Q78より仕事の出来なさそうなGl17が圧倒的人気なのはそういうことだ。

Gl17の最大唯一の長所は、どんなニュースでもなんとかして「ネトウヨ」や「日本人」を侮蔑説教するコメントをひねり出すノウハウと執念だが、

要するにnabeteru1Q78は自分主体として取り組む意思を持ってニュースを読んでいる行動者であり、

Gl17はどこまでも自分主体性責任を透明化しながら侮蔑的評論を加えるためだけにニュースを読んでいる評論家だ。



3

たとえば何かのイシューがあったとして、

それが上手く伝わっておらず支持や協力を得られないときに、

nabeteru1Q78型は伝え方をチェックして省察改善をして、自分努力未来を変えていく大人の楽しみを夢見るのだろう。

しかしGl17型が望むのは、「これを支持しない奴等は良心が無い!こんな世の中はクソだ!」と泣き喚いて地面をゴロゴロする幼児快感なのだ

Gl17型が夢見る希望は、「不届きな奴等」が自主的に改心して詫びを入れに来ることで、自分達は座ったままふんぞり返ってその詫びを受ける身分なのだ



別にnabeteru1Q78個人をヨイショする気はないし

はてサの中にも主体性のある評価されるべき人間が他にも居るのはわかっている。

しかしGl17型が一番人気と言うのが結局ははてサリベサヨの明白な限界だろう。

左派主体性があり過ぎるほどある人達に御老人やそれに連なる人が多く、

逆に入れ込みすぎてて素人がついていけないとか、ウン十年前の成功体験フレームに囚われてるとかいうのも辛みだが。


追記

記事ブコメhttp://b.hatena.ne.jp/entry/tenfa.wnp.jp/1520/

Gl17 現地直の情報はいいんだが、この人も単に不満言って意味もなく左派への嫌味くらいしか結論がない辺り、すごい浮世離れ感ある。今回の件は米同盟国同士、GCC内の争いで、融和の建前を軽視した結果だと思うけど。

うへっ

常に不満言って意味もなく日本人への嫌味くらいしか結論がないブコメを延々と書く人がこれを言うのか

つかその記事カタール在住の人が取り急ぎ物資の欠乏状況を書いてるだけのエントリなんだから

大きな視野建設的な結論なんかあるわけないだろ

ほんまアホちゃう…(そしてこのコメントがまたはてサ人気一位)

2017-02-26

anond:20170225195916

"Google翻訳オープンソースプロジェクトに使うのはダメなのか? " についての反論

いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。

GPLコンパイラの例

このGPLコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。

確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェア著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。

ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。

詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。

https://www.gnu.org/philosophy/free-sw.html

ほとんどの自由ソフトウェアライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアライセンスは、契約を元にするもので、契約もっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。

わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンス利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由である結論づけるかもしれません。

また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフト保護されたソフトウェアでも、それによって作成された著作物GPLにならない(つまりコンパイラやパーサーのライセンス継承しない)ことを根拠考察しているようだが、実はbisonやGCCGPLにはライセンスに対する例外付属していることを考慮すべきである

GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアライセンスが影響しないことを確実にするためにこれらの例外規定しているのではないか

この二つの理由から、元記事議論世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。

フェアユースについて

フェアユース規定は例えば日本では存在しない、

加えて言えば、たとえフェアユース規定が全世界的に利用できて、営利目的でなければ利用できたとしても、

フリーソフトウェア/オープンソース定義の中に

自由.0: どんな目的に対しても、プログラムを望むままに実行する自由

(i.e. オープンソース定義 6項 利用する分野に対する差別禁止)

がある限り、そのような制限ディストリビューションは受け入れられないだろう。

またOracle vs GoogleJavaAPI訴訟はケースとしてはかなり特例であり、

一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、

これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか

Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか

少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である

というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである

Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーコンピューター計算コントロール

つべであるという自由ソフトウェア思想と明らかに相容れないものである

このようなサービスを利用することの弊害として、(例えば)Google翻訳翻訳処理の計算依存することにより、ユーザー入力Googleが常に把握することが挙げられます

もちろんこれはあまり良いことではない。

多くのFLOSSシステムディストリビューション自由ソフトウェアを主に入れるというガイドラインを持っている。

アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、

これは事実上妥協産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者異論を挟まないだろう。

また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物依存する場合、contribというセクションに閉じ込めており、それは公式システムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)

Ubuntuコミュニティ新規に作られた著作物コミュニティ哲学に反する物に依存するというのは、かなり致命的である

たとえ奇跡が起こり、例外的Google翻訳や一部のプロ翻訳ツールBSDライセンス(Launchpad上での翻訳ライセンス)での出力を許したとしても決して褒められたものではない。

Ubuntubug#1に"Ubuntuソフトウェア自由である。常にそうであったし、今後も常にそうである自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである

https://bugs.launchpad.net/ubuntu/+bug/1

この反論を読んだ読者の中にはあまりGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、

いわゆる"Linuxディストリビューション"の中には数多くの重要GNUソフトウェアシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)

またUbuntu派生元となったDebianの成立経緯にはやはりFSFが関わっている。

さらに言えば、システム保守を手伝う人の中にはシステムフリーからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)

のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。

追記

Ubuntu Japanse Teamの関係者に読まれたようなので満足しました。(2017/2/27 22時)

2017-02-25

http://anond.hatelabo.jp/20170225195916

AをBに変換するというルールを作るにあたって、

そのルールとはつまり英和辞書を見てることに他ならない。

英和辞書を見ながら人力翻訳するのは普通だろうが、

英和辞書表現をそのままパクれば無害とは言い切れない。

良い英和辞書は長文の使用例を載せていたりする。

gccの出力結果がGPLのものを含まないかと言えば、100%含んでるだろ当然。

GPL辞書を使ってるわけなんだから

でもその辞書に特例を設けることによって、

gccアウトプットにはGPL適用されないような配慮がされてる。

法ではなく、製作者の配慮によって自由担保されている。

OSS文書Google翻訳で生成する件について、

Google自体著作権問題が無いかもしれないが、

WIndowsMSゴシックのように第三者プロダクトを利用していた場合

例えば、辞書出版社から訴えられる可能性はある。

2016-10-09

http://anond.hatelabo.jp/20161009190010

どうでもいいけど

bool a = nanka();
if ( a && !a ) {
    ....
}

というコードコンパイルしたら「comparison is always true」的な警告が出るはずだと思って試してみたら意外にもgccでは出なかった(最適化時は黙って消える)

「if ( (unsigned int)a >= 0 ) 」だったら警告出るのにね

2016-09-02

情報系の学科に通っています

学問の徒として生きるのは完全に諦めてるし、大学もはや無駄と思ってるけど、無能でない俺ですら無理と思う道であってこんな補助金出してガバガバ教育してる日本金の使い方無駄すぎ……とは思う 

もっとちゃんとした就職予備校設置してほしいけどそういう変革は無理なんだろう。

そういう話じゃないのか。今回はそういう話ではないです。

パソコンのご本を読めるようになるのが難しい、という感じのお話。独学? が難しい。

パソコンのご本、あんまり知識がちゃんとしてない人は読めないようになっているっぽい。

後述するけど、わかりやすいように作られたスクショまみれの本とか。

全体的なビジョンがないわけ。実際の世界がそれで動いてるようなビジョンが。だから読めない。

僕は社会の役に立つことを直接学びたかったよ。社会がどういう風に動いてるかみたいな話をさア

そういうのがあれば、パソコンのご本を読めるようになるんだろうなという感覚がある。

実務の話!! 実際に「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均で売ってる電卓、あのデジタル表示の部分がどういう仕組みで動いてるの、ということを考えたり、

インターネットプロトコルパソコンが具体的にどういうパケット送信しているんだろう、というような話を攻めて、これが全体像とやらが見えるようになる一助になるかはわからないけど、

できるところからできるところだけ勉強していきたいと思います。それが、僕にとって、よくわからない本をじっと読まなきゃいけない義務から抜け出した罰の引き受け方っぽいので。

2016-05-02

C言語


Gnu pack

Develop版 インストール

C直下gnu pack のユーザーガイドHTML

ダウンロードする gnu pack devel-11.0 exe

三万から五万に素数がいくつあるか

gccmeadowを使う

ホームディレクトリにCというのを作る

mkdir と打つ

その後Prog1 というのを作る

CD で移動

Prog1をカレントディレクトリに。

home/c/plog1/01

emacs & と打つ

#include <stdio.h>

main() {

Printif("hello.");

}

と打つ

実行画面に $ gcc -o hello hello.c. ドルマークは一つだけ。

$ ./hello

hello

演習1

学籍番号と氏名を表示させるプログラムensyu1をつくる。

実行形式→Ensyu1cをつくる 文字化けがあるので シフトJIS

エスケープシーケンスに注意 使う文字の前に入れるらしい

プログラム

演習2

プログラムensyu2c.を作成

Ensyu2という実行形式ファイルコンパイルせよ

エスケープシーケンス. ¥n を利用して

アスキーアートを作れ

-----------

中間テストまではメイン関数のみ その後は自分関数をつくる

2015-12-28

Vimclangコンパイルする方法誰か知らない?

gccclangコンパイルした違いがあるのか初心者の俺的には知りたいだけなんだよ

2015-02-10

技術系の記事というものは省略が基本

http://anond.hatelabo.jp/20150210030728

はてななどのブログに限らず、技術書には程度というものがあって、それぞれに用語がある。

ページや文書には必ず限りがあり、専門用語を使わず記述すると非常に手間で、読むのに時間がかかる。

それらの専門用語理解するために、初学者用の書籍記事があるけれど、専門用語を知って学習することは読者のレベルに委ねられていて、読者層を限定していることになる。

リンク先の記事を書いている人は、「皆がMacを持っているわけじゃない」と書いているけれど、WindowsにもUNIXライクな環境を揃える方法CygwinGowなどいくらでもあって、gccmakeのような基礎ツールがあればほとんどのOS実装できる。

それでもわからないということは、そういった基礎知識がないということで、要するにもっと勉強しろということ。

2015-01-29

初めてじゃなかったCの思い出

今やプログラミングといえば、Webなどで使われるような高水スクリプト言語中心のアプリケーションプログラミングが主流だ。

そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である

そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。


今も昔も、基本的に難しい仕事無茶振りから始まるものだ。

少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。

大学で初めて触ったC言語しかポインタからないで止まっているような奴に、電文の再配信プログラムを任せたのだから


客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。

そうなるとC/C++くらいしか事実上選択肢がない。

このうちC++は、Java経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。

勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。

あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。

その時点で相当ヤバいである


コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなもの絶対必要である

その時のルールは「gccオプションに"-Wall"を入れた状態で、Warningゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。

というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様コンパクトである以上に原始的と言っていい代物で(だからWarningは基本無視できないのだ)、しか言語仕様以外の環境依存要素が山積していると来たもんだ。

そんな言語システムコールだらけのコードかつ複数ファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかマルチプロセスシグナルもあるよ!とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。

仕方なく最初のKRに加えて「UNIXネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。

後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。

そこまで凄い良書なのになんで絶版になったんだか。


いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。

シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか!と途方に暮れたこともあった。

そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。

結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分仕事ぶりには全く満足していない。

無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッドmalloc()、可変長引数は遂に習得できなかった。

こういうプログラムって、どうやったら正しく動かせるんだろ。


このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が

Cはとても高効率ですし、マシンリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルリソース管理(たとえばメモリ管理)を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります今日マシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシン時間を少し非効率に使っても、あなた時間をずっと効率的に使う言語を使うほうが賢明でしょう。

本物のプログラマアプリケーションプログラムなど書かず、まっさら金属板にゼロから書き込んでいく。アプリケーションプログラミングなど、システムプログラミングのできない弱虫のすることだ。

と言っていたことは正真正銘の事実であると痛感した。

あと、あれほど苦手だったポインタについても、「ポインタ理解できないと永久にC初心者」というのを嫌でも理解した。

あれはギターのFコードやSEALsのヘルウィークみたいなもので「習得できなかった者にとってはキャリアの終わりを意味するが、習得できた者にとっては始まりですらない」ものなのだ


・・・で、これだけで終わってしまうと本当にタダの黒歴史だが、これには少しだけ嬉しい後日談がある。

それから数年後、やはり電文転送系のシステムで、かつて自分がCのソロプレイでこなしていた規模の数万倍はあると思しき超大型案件助っ人の「兵卒」として参加したのだが、そこはインプラとアプリでチームが分かれており、アプリ側だった自分

配列ポインタ構造しか使わないで済むなんて、なんて楽な仕事なんだ!」と左うちわのんびり過ごし、しかも高評価をいただいて帰ってこれた。

実は今までの案件で一番幸福感が最高だったのは内緒である

2014-07-12

昔々、ずっとWindowsで不便だと思ってたことが20年近くそのままでわろた

会社で貸与されたパソコンVISTAだった。Windows触るの、2000以来なんですけど。 今までマカーだったので。久しぶりに触ります。なかなか新鮮。

でも、ずっとまえから不便だなーと思ってたことがそのままでワロタ。あれわざとなんですかね。仕方ないのでautohotokeyで1日がかりでそこそこ使えるものしました。。

なんというかWindowsの悪いところ全然なおってねーじゃん。レジストリって今でもあるのね。記憶に間違いがなければあれって確かDOS時代設定ファイルファイルがでかくなったから仕方なくDBにしたやつでしょ。あんなのまだ使ってるとか。

OSXはそそもそもUN*X環境なので使いやすいが、WIndowsCygwin管理者権限いるのね。最小インストールなら入るけど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でウインドウ右上の「x」印を押した時と同じ挙動をするようにしたらすごく便利になった。

マシンがめたくそ重たいので、タイトルバーとかフォントデザインXPにい似た感じ(クラシック表示ってやつ?;)にしたらかなり軽くなった。CPU/GPUが追いつかないならそんな機能いらねーよ。なに考えてるんだ。

それから画面ロックWin+L固定でここれ地味に両手使うのでマウスの中ボダンにバインドしといた。席を立ってからロック忘れに気づいてもマウスぽちっとするだけでロック状態になる。便利。それからCtrol+Alt+Delをt同時に送信するボタン買った。結構便利。

他にも何か解決してないクソなシ仕様がある気がするけど、今のろまあまあ快適につかえている。前はmayu使ってたけど、AutoHotKeyいね

うそう、キーボードのNumLockをOFFにしてバーチャウインドウの切り替え(1,3,7,9)に使ってるんだけど、(Shift+Numキーだとアクティブウインドウだけ対象デスクトップに送る)これがが直感的ですごく便利。おすすめテンキーとして使う時はNumLockをONにするだけ。テンキー頻用 する人には向かないかな?俺はほとんどテンキー使わないので。

==トラバうけて追記==

まあ久しぶりに触ると悪いところが目立つって話ですよ。フォルダ作るのとかShit+Ctrl+Nでいい気はするけどねえ。逆にWindowsはCtrl+Alt+Delのようなシステム割り込みをかけてマルウェア防いでるけど、Macだと「全画面モードです」とかしかでなくてあれで騙される人居そうで他人ごとながらちょっと心配になる。WinからMacに乗り換えても同じようにDisると思うよ。でもUN*X使いとしてはシェルコマンドほぼほぼ使えるMacがいいかなあ、やっぱり。

あと今更VISTA? は俺が一番いいたい。貸与されたものがそうなってて管理者権限ないんだからどうしようにもないだろ。これフォーマッt-して別のOS入れたらそれだけでイントラに繋がらなくなるし。

2014-06-11

http://anond.hatelabo.jp/20140610001452

リチャード・ストールマンEmacsgccの開発で知られる著名なプログラマ

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.

It helps more people, too.

子孫を作るってのには大した才能は要らない。植物でさえできることだ。 それに比べてEmacsのようなプログラムに貢献するのは誇るに足る本当の才能だ。

もっとたくさんの人を助けることになるしね。

2014-03-25

http://anond.hatelabo.jp/20140325222709

きっと30年前のアセンブラマスター

「これからgccが全ての機械語を書くようになる」

と言ったときに同じように鼻で笑ったことだろうよ。

2014-03-24

そろそろ、環境Macにしようか考えてるんだけどさ

そりゃあたかPCの事だし、悩んでるほどでは無いけど、事有るごとに、よく考えるんだよね。

職業ソフトウェアエンジニアで、日頃からUnix(Linux)環境で、仕事でもプライベートでも

似たような環境をいじり倒してるわけなんだけど、結局いつもスルーちゃうんだよね。

理由は、Mac に できることは Unix(Linux)ででも、できてしまうってゆう理由なんだよね。

もちろん、mac が なきゃ 素直な iphone アプリ作れないとか、objectivec にしても

gcc のとは 多少、違うくらいのことはわかってるよ。

で、また、思い立って、ここにこんなこと書いているのは

増税前ってのもあるから、今回は 日頃からバリバリ使っている人の率直な意見を聞きたいなと思ってね。

僕の背中を後押しするような、意見でも、躊躇させるような意見でもいいから

もらえたら、ありがたく、参考にさせてもらうよ。

何度もゆうけど、たかが、PC なんだけどさ。

2014-02-27

Apple's SSL/TLS bug (22 Feb 2014)の意訳

例のAppleSSL/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)し、アップルが隠したい秘密はもうバレてしまっていると思う。
そして現在、俺たちはその誤った情報を正すステージに来ているんだ。

ほらここに、Applebugがあるんだ。:
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を使っているすべてに影響するけど、ChromeFirefoxはそうじゃない。
ChromeFirefoxSSL/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 "を付けてコンパイルしたとしても、XcodeGCC 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じゃない証明書でもIPHTTPSにつながっちゃうってだけだったよ。変だけど。
Safariはこの問題には関係なかったよ。

2014-02-25

http://anond.hatelabo.jp/20140225111921

いいえちがいますGCCなどのツールには特例事項が含まれているので

GCCコンパイルしたソースコードはそれ自身がGNU出ない限りGNUにはなりません。別物として扱われるように歴史的経緯でちゃんとなっています

言い方を変えると、増田GNUについて詳しいことを知らずにGNUについて語ってるって事ですね。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん