/tmpと/var/tmpの仁義無き戦い - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #課題 /tmpと/var/tmpどっちも大体一緒だからいいんじゃないかと思って/tmpにファイルをつくろうとしたら、プログラムが使用するものは/var/tmpにと叱られた。確かに、基幹系システムのディストリビューションだと何故か/var/tmp派の人が多かった気がする。じゃあ、linux系特有の宗派の問題なのか？と思い調べてみた。 #何が他のディレクトリと違うか 通常のディレクトリは、基本的にはファイルは削除しない限り消えない。 /tmpに関しては再起動するとファイルが綺麗さっぱり無くなる。 /var/tmpは再起動しても消えないがい
Working with Unix ProcessesをPerlで - $shibayu36->blog;
以前 Working with Unix Processesという本を読んだのですが、この本がUnixにおけるプロセスについて非常にわかりやすく解説されていました。それで自分で内容をメモしてみたり、さらにわからないところを調べたり、参考のプログラムをPerlで書いたり(この本ではRubyで書かれています)してみたのですが、ブログにまとめてなかったので、ちょっと書いてみます。 (注意)書いていたらすごく長くなりました。興味のある方は、適当に時間のあるときにでもどうぞ。 Chapter 2 : Introduction プロセスのことを知るとコードを読むだけでは分からないややこしい問題が分かるようになるよ Chapter 3 : Primer Unixはユーザ空間とカーネル空間がある kernelの機能はsystem call経由で利用する ユーザ空間ではプログラムが動く manual man
「UNIXをC++で分散OSに書き直せ」、幻に消えたBill Joyの野望とは - ITジャーナリスト星暁雄の"情報論"ノート
UNIXの歴史にはある大きな転換点があり、そこには「もう一つの未来」の可能性が開けていました。この転換期に起こった出来事は「UNIX戦争」として知られていますが、その背景に「UNIXをC++で分散OSに書き直す」という野心的な計画があったことは、今ではほとんど語られることはありません。 私は、この一連の出来事の時期に、『日経エレクトロニクス』の記者としてUNIXの動向を追っていました。当時の出来事の概要を、取材者の視点から書き記しておきたいと思います。多くの読者にとって初耳の情報も含まれていると思います。 一連の出来事の発端は1987年に発表された、Sun、AT&T、Microsoftによる統合UNIXの発表です。この発表の前夜がどういう時代だったか、という話がまず必要でしょう。 統合前夜 1980年代後半は、コンピュータの歴史でも重要な時期でした。この時期、32ビット・マイクロプロセッサ
初めてのOS source code reading(UNIX 6th source code readingのススメ) - やる気のないブログ(A boring diary)
このエントリはhttp://d.hatena.ne.jp/takahirox/20120131/1328006885を和訳したものです。 はじめに 最近UNIX 6thのソースコードの読書メモを書き終えました。 みさなんにもUNIX 6thのソースコードを読むことをオススメします。 その理由をこのエントリで書いていきます。 まとめ UNIX 6thは初めてOSのソースコードを読む人にうってつけ！ 今すぐ読み始めましょう！ UNIX 6thのソースコードはこちらなどで読むことができます。 http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6 UNIX 6thのソースコードを読むことをオススメする理由 たったの10,000行 最近のLinuxカーネルのソースコードは100万行を超えています。全てを理解するのは至難の業です。 一方、UNIX 6thのカー
man operator - わからん
「デーモン君のソース探検」より。この本はなかなか萌えますね。こういうチートシート、Haskell で欲しいな。自分でつくろう。
タネンバウム教授、MINIXの失敗とLinux普及の理由を語る － Publickey
アンドリュー・タネンバウム教授といえば、「MINIX」というUNIXに似た学習目的のOSの開発者の一人で、このMINIXとタネンバウム教授の著書「オペレーティングシステム 設計と実装」に刺激を受けて、リーナス・トーバルズ氏がLinuxを開発し始めたと言われています。 そのタネンバウム教授へのインタビューが、フランスのWebサイト「LinuxFR.org」に掲載されていました。MINIXの最新動向、なぜLinuxがこれだけ普及したのか、そしてトーバルズ氏と論争になったといわれているマイクロカーネルについて、興味深い答えが引き出されています。一部を訳してみました。 MINIXではNetBSD互換に取り組んでいる MINIXはもともとOSの構造などを学ぶための教育目的に、コンパクトでソースコードがすべて公開されたソフトウェアとして開発されました。コンパクトな作りやマイクロカーネルといった特徴は維
UNIXツールを友にする - Strategic Choice
The Unix Tools Are Your FriendsDiomidis SpinellisUNIXツールを友にするディオミディス・スピネリスどういうこと？IDEかUNIXツールのどちらかを選ぶとしたら、迷うことなくUNIXツールを選びます。どうして？IDEUNIXツール特定の言語をターゲット。テキスト形式になっているものは何でも。新しい言語や表記方法を都度覚える必要があり。新しい言語や表記方法にも、そのままで対応できる。それを開発した人の考えたコマンド以外使えない。コマンドの組み合わせは無限。作業方法はあらかじめ決まってしまう。作業の工夫の余地がある。メモリを大量に消費。1度に1行しか実行せず、データ量は無限に扱える。マルチコア対応は環境次第。パイプライン処理のため、複数コアに負荷が自然に分散される。GUIなので用途が限られる。組み込みなど、リソースが限られた状況でも使用可能。どう
UNIX 6th code reading - ファイルシステム概要その２ - やる気のないブログ(A boring diary)
はじめに 前回のエントリの続きで、今回もUNIX v6のファイルシステムを見ていきます。 前回はブロックデバイスを中心に見ていきました。今回はコアメモリを中心に見ていきます。 コアメモリ中のファイル関係のデータ構造 inode構造体 アクティブなファイルのinodeなどはコアメモリ中のinode[]構造体の配列(5659行目で定義)に格納されます。ブロックディスク上で扱われるinode構造体の定義(5605行目で定義)と中身が少し異なりますので注意してください。 inode構造体はi_countという参照カウントをもっており、このカウントが0だった場合、そのinodeエントリは割りあてられていない空きエントリとみなされます。 file構造体 ファイルをオープンすると、5507行目で宣言されているfile構造体の配列にエントリが追加されます。 file構造体はREAD, WRITE, PIP
UNIX 6th code reading - ファイルシステム概要 - やる気のないブログ(A boring diary)
はじめに 今回からUNIX v6のファイルシステムを見ていきます。 いきなりLions本18章を読み解いていくのは難しいと感じたので、まずはファイルシステムの概要をまとめてみました。 今回はブロックデバイス上での処理を中心にまとめていきます。次回はコアメモリ中での処理をまとめようと思っています。 ブロックデバイス ブロックデバイスの先頭#0はブートプログラムなどに使われます。 次の#1はsuper blockと呼ばれるブロックで、そのデバイスの情報が含まれます。filsys構造体(5561行目)を参考にしてください。 その後の#2〜#n+1まではinodeで占められます。inodeはファイルの情報を持ったデータで、ファイルサイズやパーミッションや更新日時、対応したファイルデータのアドレスなどを持ちます。後述しますが、ファイル名は持っていません。 また、i_numberとして、inode自体
ls(1)の由来とか - Plan9日記
TwitterのTLでもMulticsの話がぽちぽち出るようになったので、今日は関連する小ネタを。 UNIXで無意識で使っているls(1)コマンド。manページには"list directory contents"とか書かれているので、listの短縮形だとばかり思っていたら、Wikipediaによるとlist segmentsの略なんだそうな*1。どうもその名前の由来はMulticsにありそうだ。 セグメントとはMultics用語でファイルのこと。ただしファイルとセグメントは等価ではなく、ファイルが二次記憶を抽象化した概念であるのに対して、セグメントは二次記憶であることを隠蔽する概念である。UNIXのメモリマップドファイルに近いけど、歴史的にワンレベルストアとか呼ばれる。Multicsの世界では、UNIXのopen/closeに対する操作がなくて、セグメント名が動的リンカによって解決される
/dev/random と /dev/urandom の違い
/dev/random は、 Unix 系オペレーティングシステムのスペシャルファイルの１つです。擬似乱数生成機として使われます。 /dev/random をはじめて実装したのは、Linuxのようです。 /dev/random は、エントロピープールにノイズのビット数を保持しています。/dev/randomを読み出すと、エントロピープールからノイズビット数予測から乱数のバイト列を返します。乱数をたくさん読み出すとエントロピープールが空にになります。この状態で/dev/randomを読み出そうとするとブロックされ、ノイズが集まるまで待たされます。 ブロックする目的は、真の乱数生成機として機能することで、暗号鍵の生成などにも安全に利用できることを意図しています。 /dev/random に対して、 /dev/urandom があります。 urandom は unlocked random so
私的メモ：何でUnix環境入門授業を設置しているのか
next49 @next49 MS Wordの対抗馬としてemacsを教えていたりする @zetamatta さんの「vimやEmacsを「使いこなす」なんてやっていいのは20世紀までだろ」をお気に入りにしました。 http://togetter.com/li/130686 next49 @next49 Unix環境の入門授業を担当している身からすると、http://bit.ly/mOqTme で想定されているemacs使い、Unix使いのレベルが高すぎる。うちの学生は計算機科学系の学科への入学生だけどエディタという概念を知らない。 next49 @next49 CUIというインターフェースを存在することを知らない。計算機というのは各種設定をしなければ動かないというのを知らない。計算機＝パソコン＝Windows&Webという認識の学生が多い。そういう学生の認識にゆさぶりをかける方法としてU
UNIXにみる世代間の断絶
(まだまだ調査中) UNIXにみる世代間の断絶をまとめようという試 みです。どちらが良い悪いという比較をするつもりはありません。 両者の良い点を学んでいこう (新旧自在の hybrid type を目指そ う) 、というのがこの文書の目的です。
シグナルの誕生 - Plan9日記
今日はシグナルの歴史を調べてみたいと思う。シグナルというのはUNIXにおけるプロセス間通信の一手段であるが、CPUにおける例外のように、プロセスにとって非同期に発生するものなので、その実装はいろいろ面倒くさい。したがっていろいろ問題もあり、長年の改良の歴史を経て、今のシグナルの仕様に落ち着いた*1。BSDやSVR、そしてPOSIX標準になるまでのシグナルの拡張については文献が多いが、V6/V7以前は知られていないのでは。ということで、私の出番w まぁ、わかったところで喜ぶのは相当な好事家だろうが*2。 いきなりV7以前の話を始めるのも何なので、前提知識として、FreeBSD版悪魔本「4.7.1 シグナルの歴史」からちょっと長いけど引用する。 シグナルは、ユーザが暴走したプログラムを強制終了する場合など、例外的なイベントをモデルとして当初設計された。それは、汎用のプロセス間通信として使われる
Plan9NotDeadYet - ひらメ Plan9 | Plan 9、いまだ死なず。そして、それから何を学ぶことができるか
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
私は如何にして心配するのを止めてUNIXカーネルを愛するようになったか
Most pages here are written in Japanese. Some pages are in English. UNIXカーネル(第6版) ソースコードには 「You are not expected to understand this.」 (これがわからなくてもべつにかまわない)という木で鼻をくくったようなコメントがある。 Jargon Dictionaryの見出し語にもあるように、UNIXに関するきわめつけの逸話である。 Lions本とよばれる後述の注釈本では2238行に位置するこのコメントに対応する部分を理解すると「2238クラブに入れる」との記述がある。 ちょっと注意 このページは UNIXをひととおり使える C言語でプログラムが組める アセンブラも多少は何とかなる 必要とあらば英語の文献を読むこともいとわない をすべてみたす人を読者に想定している。 部分
UNIX vs Microsoft Windows：そのシステム設計におけるセキュリティ理念の相違
文：Chad Perrin （Special to TechRepublic） 翻訳校正：村上雅章・野崎裕子 2010-11-26 08:00 システムセキュリティに対するUNIXのアプローチと、Microsoft Windows（以降、Windows）のアプローチの主な違いに目を向けてみることで、UNIXシステムの特長とも言えるセキュリティの強固さが、その優れたアーキテクチャ設計によってもたらされているという事実を実感することができる。Windowsでも、さまざまな角度からこういった特長を取り込もうという試みがなされてはいるものの、システムアーキテクチャに組み込んだかたちで設計されているのではなく、OSの上に構築した機能として実装されているのが実態である。 例を挙げると、Windowsにおいて権限の分離を実現するために採用されている設計指針は、Windowsのセキュリティに影を投げかけ続
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
USR abbreviation stands for Unix Shared Resources
yebo blog: 日本国際賞をUNIXの父デニス・リッチーとケン・トンプソンが受賞
もう少し詳細が解ればなぁ、とも思う。 - たわごと