  |
はてなキーワード: posixとは
11月〜12月で炎上、というより「コミュ力の圧倒的足りなさ」から揉め事や騒動を起こしている人たちが軒並み40代だった。
SQLおじさんこと生島勘富は40代（クラウドワークスのページより）
ちょまどの例のスライドを作ったおっさんこと山本康彦は1957年生まれの59歳。
その酒巻裕一を擁護しつつ自身もアドベントカレンダーで特定人物の攻撃記事を上げているRichMikanことシェルショッカーこと松浦智之は1975年生まれの41歳。
職人エンジニアみたいな言葉を使ってエンジニアにコミュ力を求めない風潮を是とする記事を読んだことがあったけど、こんな若気の至りでやるような揉め事をいい年したオッサンたちがやっているのを見ると、コミュ力0のまま一定の年齢を超えたエンジニアは、社会と完全隔離させないと誰かを不幸にするだけの存在になるんじゃないかって気がしてならない。これは社会人全体にも言えるが。
ゲームの現場は平均年齢が30くらいなので、フリーランスで40越えたときには周りがみんな年下で、そこに同対応してゆくかというのはある。というか、対応できずに昔のままの感覚で腫れ物扱いや疎まれていく（もちろん、本人には言われない）というのを最近たくさん見てつらい。
https://twitter.com/obenkyounuma/status/806253887036366849
あとドラえもんの「大人ってかわいそうだね。自分より大きなものがいないもの。よりかかって甘えたり叱ってくれる人がいないんだもの。」っていう台詞を思い出した。もうこんなおっさん達を正しく叱ってくれる人間はいないだろうから、やはりただちに現実からもネット上からも隔離するしかないんじゃないか。
http://qiita.com/mesaka/items/41ec09a4dae3fba6dd6c
Qiitaに登録しているGitHubアカウントを見ると、たしかにGitやGitHubが苦手なんだなあというのを感じる。
それはまあともかく、プロフにあるURLを踏むと合同会社を設立されていることがわかる。
ついでに言うとWantedlyにも企業ページを作っていて、そこのプロフ等にも不穏なことが書かれているのだけれど割愛。
ここまで公開している立場で、あのコメント欄の態度は自分の首を絞めていないか？という疑問はさておき、GitHubの名前を検索したらTwitterアカウントが出てくる。
https://twitter.com/mesaka2009
いろんな人間に裏切られて鬱病になりました。もう人生に疲れています。 PHPは大好き！早く正社員になってもいいです！！ ※このツイートはフィクションが含まれています。検挙件数稼ぎの警察の方の自宅に来襲はご遠慮下さい。
bioの内容が不穏すぎるがさておき、このTwitterアカウントを検索するとDMMの面接で落ちて逆恨みしたり、コロプラの面接で号泣していたことが既に増田でヲチされていたことが分かる。
すでに指摘されているが、妻子持ちでTwitterにはこの時期かなり不穏なこともつぶやいていたらしい。
件のQiita記事に関しては「書いてあることが事実ならチャットワーク社が反省すべきことはあるけど、この人の数年レベルの普段の言動から見ても、書いてある内容をそのまま鵜呑みにして語ることはできない」と思った。
ちなみに去年のカレンダーにはこんなこと書いてたのに、どうしてしまったんだろうなあ。
http://qiita.com/advent-calendar/2015/free-engineer
（追記）該当の記事を見たら、コメントにフリーランスおじさんを焚き付けてるおじさんが新たに登場してた。調べたらこの人も特定人物にケンカ売りたいだけの記事をQiitaに書いてた。
品位が問われるAdvent Calendar -- シェルスクリプトはどこでも動く！ - Qiita
http://qiita.com/richmikan@github/items/5f53a14a79874d56a2ff
http://togetter.com/li/1056218
ちなみにこの人は松浦智之氏で最近『Windows／Mac／UNIX すべてで20年動くプログラムはどう書くべきか』という本を書いている。著作者情報によれば1975年生まれの40代。ついでに言うと、件のフリーランスおじさんはWantedlyに生の職務経歴書のpdfを公開していて、そこから年齢が40歳であることがわかる。なんだ、プログラマーは40超えたらこんな風におかしくなってしまうのか。プログラマー35歳定年説は正しかったのかもしれない。
10年位前、上位のサイトから電文を受け取り下位のサイトに再配信するプログラムを、Linux上にC言語で実装する仕事を引き受け、死ぬ思いで片付けた。
その時にお世話になったのが「UNIXネットワークプログラミング」という本。
この本、POSIX準拠のOS(要するにLinuxなどのUNIX系OS)におけるシステムプログラミングのノウハウに関しては名著、いやバイブルと言っていい。
名著が絶版になる理由は色々あるだろうが、この本に限って言えばもはやそういう時代じゃない、そういう低レベルの実装はトレンドじゃないということなのだろう。
でも、そしたら「決して遅延が許されない再配信プログラム」は、一体何をどう使って作るんだ？
プロセス間通信やスレッド制御、更にはシグナルも使い、それらが高速で動作しないといけない(いやスレッドは難しすぎて結局使わなかったけど)システムで、そんなオーバーヘッドが高い言語は使えないと思うのだが。
それらを解決できる気の利いたライブラリやフレームワークもなさそうだし。
或いは回線とスイッチを高性能にして、サーバリソースも上げられるだけ上げるというように、インフラ側の強化で解決しちゃうとか？
議論元エントリーはこちら。
毎度のことながら、MacとWindowsの論争を見るともんにょりしますね。人類から戦争が途絶えぬ縮図が、ここに。(´ω`)
しかし、最近パソコンをはじめたユーザや、元エントリの増田のような人にとっては、信者の言葉ってワケわかめだと思うんですよ。
そんなわけでMacとWindowsの歴史を、なるべく平易に書いてみました。(´∀｀)
歴史を見返して、WindowsとMacの強み弱みを把握すれば、宗教戦争の理解が深まり、自分にピッタリのパソコンが分かるかもしれません。
たぶん。
元増田のエントリーがWindows寄りの結論になっているので、
だれかWindows寄りや、Linux寄りの視点を加筆して下さいな。当エントリの補足・指摘も歓迎します。
既存のUNIX環境向けに制作された、膨大な数のソフトウェアを扱えるのはプログラマにとっては大きな恩恵です。
たとえばWindowsではCygwinを導入する事でC言語開発環境を手に入れる事ができます。ただし、インストールは非常に煩雑で、動作速度も雲泥の差です。
MacはPOSIX互換であり、プログラミング環境のインストール等が簡単です。
FreeBSDやUNIXを過去に使用していた熟練プログラマは、Macに乗り換える事で、過去の資産を有効活用する事ができます。
シェル環境とは、よく映画で、暗い部屋の中、天才プログラマーが真っ黒な画面に流れる奇っ怪な文字列を眺めてる、アレです。
ひらたくいうと、あの文字列ひとつひとつが、コンピュータ内部で行われる処理や通信を意味しています。
LinuxやMacではターミナル、Windowsではコマンドプロンプトなどと呼ばれます。
Windowsには非搭載だが、Linux/UNIX/Macでは標準サポートされているコマンドが多数ありました。
とはいえ、これは過去の話です。現在はWindowsのシェル環境も、だいぶ充実したので、普通に使うには大きな差はありません。
が、歴史的経緯や文献量を比較すると、どうしてもWindowsのシェル環境はUNIX/Macに劣ると考えられています。
四六時中プログラマが目にするのは、文字です。ですからプログラマーは醜いフォントが許せません。
Windowsのフォントレンダリング環境は2014年3月現在も貧弱です。
WindowsVista登場時にメイリオフォントが登場し、ある程度の改善が図られましたが、Macの画面と比較すると大きな差です。
これはMacとWindowsのフォントレンダリングやアンチエイリアスの技術の違いによるものです。
WindowsでもMacTypeなどのソフトウェアを使用して、強制的にフォントのアンチエイリアスを変更する事が可能ですが、残念ながらMacに遠く及びません。
Anti-Grain Geometry - Texts Rasterization Exposures
Xcodeは、非常に優秀なIDEです。特筆すべき利点は、動作が割と軽快で、初期設定の状態でもある程度使い物になる点です。
インストールもAppStoreからワンクリックな為、簡便です。XcodeはMacのみで使用できるソフトウェアです。以前は有料のソフトウェアでしたが、ここ数年は無料で提供されています。
またiOSのソフトウェア開発では、XcodeとMacは必須です。iOSアプリの開発には、Xcodeとそれに付随するシミュレータソフト、そして開発者用アカウントが必要なのです。
Xcodeの弱点は、バージョンアップ時にインターフェースが突如として大幅変更がされる事。またここ数年は英語のみしかサポートされておらず、日本語話者にとっては使いづらいという2点です。
2014年現在は楽曲制作にMacとWindowsの差はありません。しかし、過去にはDTM=Macという暗黙の了解がありました。
特に1980年代、プロユースの音楽制作ソフトの多くがMacintosh対応でした。理由は複数ありますが、そのひとつがPCM音源の発音問題でした。
Macintosh 128K以降すべての機種でPCM音源をサポートしています。これにより同時発音数が多く、Mac向けのDTMソフトウェアが多く開発されました。
それに対してWindowsは16ビット/48KHzのPCM1チャンネルのみで、性能はCPUの能力に依存します。昔のPCはCPUの実行速度は低かった為、音声出力の機能が貧弱でした。
Mac標準搭載のGarageBandと、有料のDTMツールLogicは有名なDTMソフトウェアです。
この2つのソフトはAppStoreから購入できます。互換性もあるため、GarageBandで作曲を覚えた初心者ユーザが、Logicを購入し上級者になるという、非常にスムーズな導線が構築されています。
またLogicは数あるDTMソフトウェアの中でも安価で高機能です。iPadとの連携機能においても、他のツールより頭一つ秀でています。
MacはCoreAudioという、MIDI入出力環境を搭載しています。大変高速に動作する為、追加投資の必要がなく、DTMクリエイターに重宝されています。
Windowsの場合、オーディオドライバを別途用意する必要がある為、投資が必要です。
主に海外製のプラグインではありますが、明らかにMacよりWindowsの方が充実しています。お金をかけずにエフェクトに凝りたい人にとっては、MacよりWindowsの方が良いと言えます。
MacBookProRetinaモデルは、グラフィックデザインの仕事をする者にとっては、福音でした。
特にAdobeInDesign使用時の効果は凄まじいと感じます。紙とディスプレイの1to1の制作環境が構築可能な時代がやってきたと感じます。
さらに当時、MacはPostScriptというAdobeが開発した印刷用言語をサポートしていました。高解像度の印刷を行うには、Macしか選択肢がなかったのです。
その頃の印刷所やデザイン事務所はおのずとMacを導入しました。その歴史がある為、現在もMacの使用が続いています。
スティーブ・ジョブスが学生時代にカリグラフィーを学んだ逸話は有名です。その経験から彼はMacのフォント環境に心血を注ぎました。
現在でもAppleは高いライセンス料を支払い、各種製品にフォントを多数搭載しています。
オーソドックスで美しいセリフ体のTimes、流麗なZapfino、日本語フォントではヒラギノなど、様々な良質フォントが搭載されています。フォントを買い足さなくても、ある程度のグラフィックデザイン制作が可能です。
反面、2014年3月現在Windowsで安定して使えるフォントは、字游工房の2書体のみです。メイリオは画面表示時に使うフォントなので、DTPでは活用されにくいです。
2005年頃、出版業界はQuarkXPressからAdobeIndesignに乗り換えました。しかし、それ以前は出版用ソフトウェアはQuarkXPressが業界標準でした。
このソフトは、Macでしか対応していませんでした。QuarkXPressは、64bit対応やOSX対応が遅れため急速にシェアを落としました。
現在はAdobeIndesignが業界標準で、これはMacもWindowsも両方で使用可能です。
しかし、QuarkXPress時代から活動しているブックデザイナーやエディトリアルデザイナーにとっては、Macの方が慣れ親しんでいるでしょう。
1980年代のパソコンは、表示できる色数に制限がありました。Macintoshは安価な割に発色の性能に優れた時代がありました。
コンピュータ・グラフィックは数多のPCメーカが多額の資金を費やし研究開発した歴史があります。
一時代だけを抜き取って「Macのグラフィックが優れていた」なんて書くと、多くのツッコミが入ると思います。
とはいえ、Macは早くからキャリブレーションの機能を充実させてきた為、色管理の強さという点において、多くのデザイナーやイラストレータから支持を受けた事は、特筆に値すると思います。
問答無用で、Windows一択。PC改造を続け、最新のグラフィックを追い求めたゲームマニアは、10年前に比べると少なくなりました。
しかし、彼らのPCがMacである事など、ありえません。
最近はAdobeFlashが盛り返しを見せていますが、ブラウザゲーム市場を除けばMacを使用するメリットは薄いと考えられます。
一方、Linuxベースのメディア配信サービスSteamOSの今後の発展に期待したいところです。Steamではアマチュアからプロまで幅広いゲームクリエイターが自作のゲームを販売しています。
Windows圧勝。MicrosoftOfficeをはじめ、Windowsの方が対応ソフトが多いです。
特に会計ソフト類は、Macは壊滅的であります。また、言わずもがなですが、BtoBの業務系ソフトウェアはWindows特化のものが大半です。
とはいえ、LibreOfficeやOpenOffice.orgを使用して業務を進める団体もあります。福島県会津若松市とか、滋賀県甲賀市などがそうです。(LibreOffice採用事例)
そういえばVer4.2でCalcを大手術したLibreOffice。もうそろそろC++完全移管が完了します。
高速化が施され、今以上にチューニングされれば、Windowsの牙城に一矢報いるかもしれません。
ちなみに私は、ChromeOSとGoogleDriveが搭載されたChromeBookが、MicrosoftOffice一強状態を打ち崩すと予測しています。
あとJustSystemの一太郎も頑張ってほしい。Just do it!!
以上、チラ裏でした。
現実問題、iOSとiTunesの同期はWindowsでも可能です。しかし「持ってる携帯電話がiPhoneだから」と言う理由でMac買う人は多いです。
そりゃiTunesとiTunesStoreを使っているなら、Macに毒されてしまいますよね。
そういえばWindowsMediaPlayderが残念だった時代に、シェアを伸ばしたのがiTunesでした。音楽を愛するユーザの支持を集めた時代があった。と言っても過言ではないと思います。
使い勝手に優れます。これが理由でMacを使う人もいます。WindowsやLinux環境で、同様の使い勝手を得られるマウス・ガジェットは、2014年3月現在存在しません。
MacProではThunderboltを大量に備えています。これは今後普及する4K映像制作において活躍すると考えられます。ただ、普通に使うぶんにはThunderboltは恩恵を受けにくいと考えられますが。
これはMacに搭載された自動バックアップ機能です。Windows8にも同様の機能があるが、インターフェースの使いやすさと、設定の簡易さではMacが勝ります。
Macはクリーンインストール後に、自分のAppleIDを認証すると、最新版まで自動アップグレードを行います。
クリーンインストール後、1回の再起動で、ほぼすべてのアップデータが揃った状態になります。
WindowsUpdateの何回も繰り返さざるを得ない面倒アップデート作業に比べると、Macは楽ちんです。
ネットワークにつながった状態でリカバリを行った際、HDDが論理的に破損していても、自動で復元してくれます。というか、いつ切り替わったのか分からないレベルの自然さで勝手に復元を始めます。そう、Macならね!!
Appleの修理は迅速な印象があります。今まで5回修理に出しましたが、いつも4日程度で返送されてきます。あとまぁ、Appleサポートはごねると得をする事が多い……ような感じがします。(一個人の印象です)
Windows8タッチパネル型は画面が揺れるので、使いづらい機種が散見される(2014年3月現在)。画面を固定しながら操作できる補助道具や、ロック式のヒンジが必要だと思うのですが、まだ普及していません。
あと、SurfacePro2が店頭で買えない状況が数ヶ月続いているので、そりゃあMacに流れるのでは。(なんか、今日のニュースで久々にSurfaceが入荷されたらしいです)
スペック対価格を比較すると、CPUやメモリやらのコストパフォーマンスが悪くない、と思います。
10年前は「Macは高くつく」という印象だったものが、ここ5年で「Macって割安」という印象に変換したと記憶しています。
一昔前に比べ、自作PCの価格的メリットが薄れたから、そのように感じるんですかね。
美品なら、「だいたいこの値段で売れる」という土壌が形成されている。大幅な値崩れも少ない。新製品発表ごとに旧機種を売って、新機種に乗り換えても、損した感が少ない。
要するに、値崩れしにくい。ポジティブに受け取ると、欲しいと思った時が買い時。
SurfaceRTのように意味の分からない価格暴落が起きる心配がないですね。人によっては、安心と言えるかもしれません。
何をもって"無駄"と判断するか、非常に難しい論点ではありますが。
へんてこなアザラシのマスコットがデスクトップを泳ぎ出したり、なんとも言えないモッサリ感の明るさ調整ソフトが突如画面に出現したり。なんて事はありません。
ある時期、ある特定の界隈にて、「Macが優れる」とか「いや、Windowsがコスパが高い」なり「Linuxが一番」とか、
マァ、乱暴な言い方をすると、それぞれのムラの中で熱狂と共にコミュニティが形成されて、宗教と信者ができあがると思うんですよ。
しかし進化の早いIT業界では、一昔前の利点が追い抜かされるなんて、日常茶飯事。
だから今から見ると、信者の言葉や、その感動が伝わらない。なんて事、よくあると思います。
ジョブスも、死んだし。
とはいえ、日常生活の中で、目を輝かせてOSのすごさを語る信者とか、逆に必要以上に貶す反信者を目にしたら、
生暖かい目で「ああ、このオジサンが若い頃、こういうのが流行ったんだナァ」とか
「ああ、昔、あのOSに苦労したんだネェ」などと、受け流してあげるのが正解だと思います。
そういう時代が、あったんだ。……と。
しつこい宗教や信者は、裏返せば、その人が感動した記憶なのでしょう。
このエントリを読んだあなたが、何かの道具に感激し、愛すべきツールを誇り、誰かにしつこく薦めるようになるのを、楽しみにしています。
ツッコミ、指摘、Welcome。
だれかWindows寄りや、Linux寄りの視点を加筆して下さいな。
記事執筆時点リリースされている最新のOSバージョンはWindows8.1、Mac10.9Mavericks、LinuxKernel3.13です。
最近、まとまった形式でWindowsとMacの優劣や、歴史を比較したエントリーって少ない印象があります。
だいたいがTwitterやまとめブログで、薄っすい単文コメント……(´・ω・`)
がっつり読み応えのある論評にお目にかかりたいものです。
最後になりますが、ちなみに私はLinuxユーザです。(・∀・)
ではみなさま、どうか、ご安全に。(￣人￣)ノ
【Webサーバを作る】http://d.hatena.ne.jp/kmaebashi/20130804/p1
use Fcntl;
use strict;
use Socket;
use threads;
use POSIX qw(strftime);
use File::Spec::Functions qw(rel2abs);
my $thread = threads-＞new(\＆serverThread, "");
$thread-＞join;
my $ret;
my %hashmap=(
"htm" =＞ "text/html",
"txt" =＞ "text/plain",
);
$ret = $hashmap{$_[0]};
if ($ret eq "") {
return "application/octet-stream";
} else {
return $ret;
}
}
my $documentRoot = rel2abs("D:/var/www/html");
my ($line, $path, @tmp, $ext, $data, $absPath);
socket(SERVER, PF_INET, SOCK_STREAM, getprotobyname('tcp'));
bind(SERVER, sockaddr_in("8001", INADDR_ANY)) || die;
listen(SERVER, SOMAXCONN) || die;
while (accept(CLIENT, SERVER)) {
while (＜CLIENT＞){
$line = $_;
last if ($line eq "" || $line eq "\r\n" || $line eq "\n");
if (index($line, "GET") == 0){
$path = (split(/ /, $line))[1];
@tmp = split(/\./, $path);
$ext = @tmp[$#tmp];
}
}
print CLIENT "HTTP/1.1 200 OK\r\n";
print CLIENT "Date: " .strftime("%a, %d %b %Y %H:%M:%S GMT", gmtime). "\r\n";
print CLIENT "Server: Sever03.java\r\n";
print CLIENT "Connection: close\r\n";
print CLIENT "Content-type: ". getContentType($ext). "\r\n";
$absPath = rel2abs($documentRoot. $path);
if (index($absPath,$documentRoot)==0 ＆＆ sysopen(FH, $absPath, O_RDONLY | O_BINARY)) {
while ($data = ＜FH＞) {
}
close FH;
}
close CLIENT;
}
}
コアモジュールだけ使った。
元ネタのJavaコードはディレクトリトラバーサルになってたんで、一応対策を盛り込んだ。
といっても絶対に外向けに動かさないように。無いと思うけど。
いろいろツッコミくれるとうれしいです。
カーネルコミッターでも、処理系実装者でも無さそうな人達が、「Cは滅びず！」と叫んでいる不思議な光景。
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5545216280/c
http://b.hatena.ne.jp/entry/shyouhei.tumblr.com/post/5603961294/c
Linuxカーネル（せめてPOSIX互換品)を手前が思う言語にさっさと移植すれ。さすればCを滅ぼせん。（ちなみに高機能アセンブラの最適解がCとは俺も思っちゃいない。）
最後のＣの牙城、Linux（ＵＮＩＸ）をＪａｖａなり何なりベターな言語にさくっと移植してくれ。それともgoogleビッグブラザー様がクラウドでＵＮＩX鯖を駆逐してくれるのを祈ってればいいのか？
JavaもC#も，それにPerlもRubyもPythonも，実行環境自体はCで書かれている件。コンピューターが「シリコンを基材としたチューリングマシン」であるかぎり，アセンブラとCは滅びない。
mutexはmutual executionの略で、書籍とかには「ミューテックス」とはあまり書かない。Wikipedia(ja)くらいである。カタカナで書く場合は「ミューテック」と書くことが多い。口語では「ミューテクス」だろうがなんでもいいが「みゅーてっくつ」とか書かれると大丈夫かなと思う。charをたむけんよろしく「ちゃ〜」と読んでないか心配である。「ちゃ〜配列の終端には「なる」をせっていする」とか書いてくれそうでそれは期待。
そしてPOSIX関数の醍醐味であるpthread_createで引数に値を設定しない、呼び先で参照しない。せっかくのvoid*の使い方を覚える機会を捨てている。コンパイル時のエラーを消すためだけにvoid *でキャストしてないか心配である。
pthread_mutex_tは初期化する時にPTHREAD_MUTEX_INITIALIZERを使うかPTHREAD_RECURSIVE_MUTEX_INITIALIZER_NPを使うかPTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NPを使うかでもいいような気もするが、特に触れていない。pthread_mutex_init()の第2引数でNULLを指定するのもpthread_mutexattr_init()で初期化(デフォルト値)するのも複数環境でまったく挙動の違うアプリが出来上がるのでやめた方が自分の身のためなのだが。
排他がかかっているかどうかのチェックならpthread_mutex_trylock()もあるのだが、特に触れていない。
POSIXにはmutexの他に「読み込み中の読み込み」を許可するpthread_rwlock_tもあるのだが、特に触れていない。
プロセス内の排他であるmutexとプロセス間の排他であるセマフォの区別がついていない。これはすごい。
追記
申し訳ない。そんなに煽るようなつもりはなかった。忘れてくれ。自戒のためにこのエントリは残しておくよ。
amachangには頑張ってpthreadを極めてほしい。
システムの機械語レベルの挙動を意識するとどういうところが気になるようになるか、それを現代の環境ではどう教えるか、という点が問題でしょうね。
・メモリやレジスタ幅(桁数)と情報の規模の関係を意識する - まあ、Oracle は 64bit OS で使えとか、xfs を 32bit OS で使うと(atomic な部分の更新が泣き別れになって)クラッシュの危険が高いとか
・API 仕様を意識する - 上の例の続きだけど、パッチのあたってない古い gzip で 2Gbytes 以上のファイルが圧縮できないとか
・コードを展開した結果、関数の出入りやインタフェースでどう膨れ上がるか、リソースの解放がどれだけ無意味になりうるかを知っている - C++ とかの場合。Tomcat もクラスロード(とリソースの確保も -- 追記)で1時間待たされるとかくだらないことが起こるけど、開発効率と運用のトレードオフだからなぁ
・(Ruby, PHP, Java などの)VMに頼るべきでない場合が何かを知っている - 速度もだけど、VMがバグ持ちの場合、デバッグが困難を極めることもある
・ビット操作系のコードを書けないと困る - まあ、ioctl や fnctl で苦労したことがあればどういうものかは判ると思うけど
・(追記)strace とか ldd とかくらい言われる前にやってほしい - 実際 Java と PHP しか知らないと本当にこの辺はできない
・(追記)497(×10^-n)日で落ちた、と言われた瞬間にカーネルのバグを疑ってほしい - lbolt 溢れ系のバグは本当にありふれている
いまどきは障害対応系の運用をやったほうがプログラマとしてコード書くよりもこの辺の問題に詳しくなれる気がします。
追記：「こういうこともわからん子供たち」をうまく使って利益を上げる会社と、「こういうこともわからん子供たち」を教えるのにフラストレーションを感じるハッカーがひとりで回している会社、どっちが上記のようなことを学びやすいかというのは難しいところです。SUSv3 (昔のオライリーの POSIX 本でもいいけど)を面白いと思えない人に正直あまり細かいことを学べるとは思えないし‥
