  |
はてなキーワード: ファイルシステムとは
最初のプログラミング言語として最もおすすめなのは、Bourne (Again) Shell。通称sh(bash)です。shはUNIXの標準的なシェルであり、bashはその拡張です。現在、多くのLinuxディストリビューションでは、bashが標準のシェルです。以下、これらのシェルの上で動作するコマンド言語およびそれによって作られたプログラムを指して「シェルスクリプト」と呼ぶことにします。
シェルスクリプトを最初のプログラミング言語におすすめする理由は、主にその実用性にあります。ほとんどのプログラミング学習者にとって、プログラミングで実現したいことは、「10000以下の素数を求める」などの教科書の課題のようなものではなく、大量のファイルから情報を検索するとか、インターネットから定期的にコンテンツを取得する、などの具体的なタスクのはずです。シェルスクリプトを使えば、後者のような実用的なプログラムを手軽に作成できます。一方、多くのプログラミング入門書には、制御構文などの細かい説明はあっても、後者のようなトピックはあまり載っていません。というのも、そのような機能は汎用的なプログラミング言語（C、Java、Python、Rubyなど）のコアの機能ではないからです。それらの機能は通常、ライブラリによって提供されます。したがって、汎用的なプログラミング言語で実用的なことをしようと思えば、外部モジュールの読み込みや、場合によってはパッケージ管理ツールを使ったライブラリのインストール方法などを学ばなければいけません。これらは、初学者にはいささかハードルが高いです（たとえば、Webフロントエンドのツール群を初学者が独学でインストールするなどは、ほぼ不可能でしょう）。一方、シェルスクリプトでは、grep、sed、awkのようなシェル上のユーティリティは全て、他の言語における組み込みの関数と同様です。つまり、モジュールのインポートや初期化処理などを行わずに使用することができます。
また、シェルスクリプトは、より本格的な言語やフレームワークへステップアップする過程としても非常に適しています。プログラミング入門書ではほとんど語られないことですが、プログラミングにおいては「プログラミング言語以外の技術」がプログラミング言語自体と同様に重要です。たとえば、ファイルやディレクトリを操作するには、OSのファイルシステムにアクセスしなければいけませんし、インターネットからコンテンツを取得するには、HTTPというネットワークプロトコルを知らなければいけません。シェルスクリプトを使う場合、それら「プログラミング言語以外の技術」を自然に利用します。それらは、プロのエンジニアを目指す上でも欠かせない知識です。また、多くのプログラミング言語では、制御構文を用いて変数の値を更新していくプログラミングスタイルが取られます。一方、シェルスクリプトでは、コマンドの出力を他のコマンドの入力に渡してデータを変換するプログラミングスタイルが取られます。後者のスタイルは、現代のソフトウェア開発では多くの場合、良いスタイルだと認識されています。シェルスクリプトを最初に学ぶことで、そのような良いプログラミングスタイルが身につきます。
シェルスクリプトを体系的に学ぶならば、次の文献が信頼できます。
プログラミングで食っていくためには、他の職業と同様に様々なスキルが必要になる。単に技術的な面だけに絞っても、以下のようなことが出来なければ話にならない。
プログラミングスクールなどを卒業したゴミには、(1)〜(2)もしくは(1)だけを以て「自分はプログラミングが出来る」と勘違いしている奴が多い印象がある。
マジレスすると元増田みたいに知識と技術が足りない人が使うのにはハードルがあまりに高すぎること
その１ 安定性が悪い
ディストリビューション選択とIDEとカスタマイズ・チューニングによる
Windowsエクスプローラはなんだかんだで万人がそれなりに使えるソフトだし
その２ （正規の終了法を使わず稼働中のPCのコードをいきなり引き抜く）強制的な電源オフに対応していない。Linuxでこれをやると高確率で次回の起動ができなくなる
サーバー用途で入れた奴は停電で切れてもそんな事態に陥ったことが無いから、たぶんシステム構築とかファイルシステムの選択に問題あり
具体的に何で困るかが分からん
初期のパッケージが古くて、何かソフト入れようとするとパッケージアップデート要求されるからネットワーク必須とか？
そもそもLinuxmintとやらは今年7月にもリリースされてるっぽいけど何の話？
その３ デバイスドライバがそろっていない。致命的な弱点
そうだね
エロ動画ではない。エロ画像である。なにせこれは20年以上前の話だからだ。
当時、Windows ユーザの間でもモデムとテレホーダイの併用でネット接続が普及しつつあった頃だった。俺は貧乏学生だったけど、常時接続された環境でのうのうとネットワークを使っていて（誤解を避けるために最初に書いておくが、俺は工学系だが情報系の専攻ではない）、Linux で独立したサーバを組んで研究室に設置し、テレホーダイタイムに家の PC98 で hterm を走らせてターミナル接続し、emacs でメールの読み書き、kermit で小さいファイルのやりとりをしているような、そんな感じの日々だった。テキストターミナルだけ、って、今の人には信じられないかもしれないけれど、メールとネットニュースの読み書き、あとはサーバの管理を行う上では、これで何の不自由もなかった。まあそういう時代だったのだと思っていただきたい。
おそらくここを読んでいる方の多くは ネットニュースという言葉を聞いてもピンとこないと思う。誤解を恐れず簡単に言うと、オープンかつ分散的なネットワークで構成された5ちゃんねる、みたいなもの……かな。5ちゃんねるはオープンでも（ネットニュース程に）分散的でもない（いや内部では分散されているんだろうけどね）し、投稿は匿名で行われるわけだけど、ネットニュースは個々のサーバが独立して運営されていて、上流のサーバとの間で NNTP によるバケツリレー方式でニュース記事のファイルが転送される。ネット上を流れているニュースグループとその記事の数は膨大なもので、そこではほとんどの場合所属や名前をオープンにしたやりとりが行われていた。日本では fj.* ってのがあって…… void 氏とか lala 氏とか、何かまあ色々有名人物がいたわけだ。何か投稿する際にびくびくしながらやっていたのを今でも思い出す。
いや、まあ fj の話はよろしい。あくまでここではエロ画像の話だった。先のネットニュースのニュースグループには comp.*, news.*, sci.* 等があったわけだけど、これらの枠組みに入らない、もしくは入れたくないような話題に関して収納する目的で alt.* というのが作られていた。この alt.* はある意味無法状態に近くて、alt（言うまでもなくこれは alternative の略である）は実は "Anarchists, Lunatics and Terrorists" の略である、などと言われた位だった。そしてこの alt.* 内には alt.binaries.* というサブグループが形成され、そこに様々なバイナリデータが流されていた。ただし、ネットニュースはテキストしか流すことはできないので、バイナリデータは uuencode（この頃まだ Base64 なんてなかったので）でテキスト文字列に変換され、分割されて投稿されていたわけだ。
で……長いな前置きが。要するに、alt.binaries.erotica.* というサブグループがあって、ここにエロ画像が大量に流れていたわけだ。勿論、大学や企業のニュースサーバはこんなグループを購読したりはしないわけなのだが、あるときに噂が流れたのだ。＊＊大学のこのサーバで、どうやら購読しているらしいぞ、と。アクセスのあからさまな制限がされておらず、見てみると……うわー、あらかた購読してるじゃん。まさに宝の山であった。ちょっと考えて、俺は自分のサーバ上でスクリプトを書き始めた。
alt.binaries.erotica.* には、様々な性的嗜好に合わせた画像のサブグループがある。ガチムチホモの絡みなんてのはお呼びじゃないので、見目麗しそうな女性の画像がありそうなグループをまず選び、そこの記事を一定時間間隔（traffic を徒に増やすのはさすがに気がひけたので）で自動的に採取、結合し、uudecode でバイナリに変換して HDD にストアする……そういうスクリプトを書いてみた。たまたまある目的で、データストア専用の HDD をサーバに付けたところだったので、そこにバイナリを溜めるようにして、ちょっとわくわくしながら眠りについた。
翌日、早めに研究室に行き、他の学生がいないのを確認して HDD の中身を見ると……おー、溜まっとる溜まっとる。中には外れもあってスカトロやら妊婦やらエラいものも混じっているわけだが、さすがにこれは人力で弾くしかない（今ならそこも自動化するかもしれないが）。数日で HDD 一杯にファイルが蓄積されたのだった。さあ、めくるめくエロライフの始まり始まり……と思ったのだが、そうはならなかった。結論から言うと、俺は1、2週間でそれをやめてしまったのだ。
まず俺は洋ピンマニアではなかった。そして、エロ画像ってのは飽きる。最初は、今風に言うと「これは俺の嫁」みたいなのを選んで、精選版画像アーカイブみたいなのを作ろうかとも思ったのだが、そういうところにそういう食指をそそられる画像ってまぁ流れてこないんだな。圧倒的に多いのは「ノイズ」。人力ノイズリダクションに嫌気がさしてしまったのだった。おまけに HDD は逼迫してくるし、結局あるところで意を決して、HDD を unmount してファイルシステムの再構築。すかーっと容量が空いたそのときが、実は一番快楽を感じた瞬間だったかもしれない。
1900年を1年目と内的処理していた場合、年数が2桁から3桁になる。また、年号を下2桁だけで処理していたシステムの一部で年のエントリで99をエラーコードや例外値として扱っている物があったとされ、そのようなシステムでは1999年になった途端に正当な1999年とエラーとを識別できず不具合をおこすことが懸念された。又、9が5つ並ぶ1999年9月9日にエラーが発生することも懸念された。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から1024週後にあふれて0に戻る。
年数を下2桁だけで処理していたシステムや、2000年を平年(閏年ではない)と誤解したシステムに問題が起こる。
1970年1月1日0時からの秒数が十進法で9桁から10桁になる。経過秒数を文字列表現に直してソートしたことで、「1,000,000,000 < 999,999,999」と判断してしまい、項目の新旧が正しく処理されない問題が実際に幾つかのシステムで発生した。
2000年以降も年数を下2桁だけで処理していたシステムで、かつ年を文字列で格納していた場合に、先頭が0の場合には八進数として扱われる処理系があり、その場合2008年の時点で年の処理が不正となる場合がある。ごく一部のperlで作成されたネットゲームで誤作動が発生した事例がある。
潜在的なバグが発覚した。シチズン電波時計やソニーのゲーム機「プレイステーション3」(閏年処理)、オーストラリアのクイーンズランド銀行でのシステム誤動作、ドイツジェムアルト社のICカード使用不能など。シチズンのケースでは、年の内部表現に西暦下2桁のBCDを使っていた。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から2048週後にあふれて0に戻る。(10ビットでは2回目)
1930年 - 2029年を下2桁で表現しているシステムに問題が起こる。同様のものに2050年問題や2070年問題などがある。
1900年1月1日0時からの秒数が32ビットからあふれ、NTPに問題が起こる。
Unixなど。1970年1月1日0時(Unix epoch)からの秒数が31ビットからあふれ、32ビット符号付きで処理しているシステムに問題が起こる。
GPSは内部処理で週数を10ビットで管理しており、起点である1980年1月6日から3072週後にあふれて0に戻る。(10ビットでは3回目)
HFSのタイムスタンプは2040年2月6日までしか取り扱えない。
System zのSTCK命令で取得する64ビットのTODクロックは2042年9月17日中にオーバーフローする。
2038年問題の1980年起点版。FATファイルシステムのタイムスタンプなどが1980年起点である。
1950年 - 2049年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2070年問題などがある。
1970年 - 2069年を下2桁で表現しているシステムに問題が起こる。同様のものに2030年問題や2050年問題などがある。
FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後(2079年12月31日)までしか正常動作しない。
2000年以降に作られた年数を2桁で表すシステムや、2100年を閏年と誤解したシステムに問題が起こる。
FATファイルシステムのタイムスタンプは2107年12月31日までしか取り扱えない。
更新されたGPSは内部処理で週数を13ビットで管理しており、この頃にあふれて0に戻る(正確な日時は未定)。
2286年問題-2286年11月20日17時46分40秒に起こる。原因は、2001年問題と同じ。
Visual C++において、3000年1月1日以降の日付処理に不具合が生じる。
Peopleはタランティーノ監督が歌手のダニエラ・ピックさんと結婚式を行ったという記事に3ブクマ。
Natureは福島県の原発事故が影響する地域にいた野生のニホンザルの血液調査に4ブクマ
IEEE SpectrumはMetal-Air Transistorの記事に2ブクマ。日本語ではGIGAZINEで紹介されているみたいだ。
Quantamagazineは2016年に書かれたファインマン・ダイアグラムの凄さを解説した記事に4ブクマ。
The VergeはTumblrがアダルトコンテンツをブロックする予定だという記事に4ブクマ。
TechCrunchはFlutter UIツールキットがバージョン1.0をリリースしたという記事に9ブクマ。
PhoronixはLinuxカーネル4.19で原因不明のEXT4ファイルシステム破損が起きるという記事に2ブクマ。ファイルシステムのコードではなくBLK-MQまわりが怪しのではないかと見られはじめたみたい。
ペースは週2回、1回1〜2時間くらい。
PowerPointはよく分からないのであんまり教えてない、てかアニメーションとか要る？
換算一問一答とか、今使われてるのはSI単位が多いけど例外もあるよ、とか、トレーサビリティってのがあって世界中の計測器は〜、とか。
緯度と経度とか、大陸の名前とか、国当てクイズとか、大航海時代とか、メルカトル図法とか。
現状Hello Worldだけ。
ファイルシステムの使い方とか、巷でよくあるメモリを机上にたとえたり補助記憶を本棚にたとえるやつとか、Windowsのタスクマネージャーの起動方法と見方とトラブル対処法とか。
射出成形とかプレス機とかNC旋盤とかファクトリーオートメーションとか。
成果物として、毎日つけているOneDrive上のExcel家計簿がある。
普段はスマホで日付と金額と勘定科目？を入力してもらって、別シートにsumifs関数で期間と勘定科目の一致した金額を集計する。
大したものじゃないけど、自分で作ったから仕組みを全部理解しているというのが大きい。地方ならこれを提出するだけでも仕事もらえるんじゃないか。言い過ぎか。
この勉強が早速功を奏したかは分からないけど、今月の頭に某中堅製造業の契約社員になれることが決まった。
優秀なら学歴関係なく正社員になれるとのことで、本人のやる気があれば今の勉強を続けていこうと思っている。
たぶんしばらくは反復練習に充てることになるかな。
俺も勉強しなきゃ…
そういうわけなので今日は公開資料を中心にリリース失敗の技術的な要因を分析してみたいと思います。
ドワンゴアカウントシステムはScalaのコードだけで22万行を越え、ドワンゴ社内で最大のScalaリポジトリとして知られています。
ドワンゴのユーザーアカウント基盤は明らかに破綻しています。 10 年以上にわたり、ガラケー時代から今に至るまで多くの業務をコードに落としていくことは極めて難しい作業であったと思います。そうはいってもやってるうちに一回なんとか出来なかったのかとは思うわけです。やっている当人たちがテンションを上げているほどには開発効率が出ていない、むしろ足を引っ張っているという可能性はかなり高いと思います。
ニコニコ生放送(以下「生放送」)ではバックエンド・フロントエンドのサーバーを建てる環境として、2016年からDocker Swarmを採用し始めています。
Docker Swarm Mode については私も検証をしたことがあり、非常に優れた思想をもった将来性のあるプロダクトであると感じていました。個人的な検証はずっと続けています。まず swarm mode の何が優れているかと言えば、コマンド体系の分かりやすさです。開発者は何のストレスを感じることもなくクラスタを扱うことができます。さらに、サービスディスカバリ層を極めて扱いやすい形(サービス作ると公開することを指定したポートがクラスタ内の全マシンで公開されるので、あとはクラスタ全台に向けてロードバランシングするだけでいい事実上のゼロコンフィグレーション)で実装したことは素晴らしいと思います。しかし、残念ながらこの素晴らしい思想を持ったプロダクトは砂上の楼閣でした。その肝心なサービスディスカバリは安定しておらず信頼できません。またマスターがコケてそのままクラスタ全部が機能を停止するだとか、ノードが気づいたら行方不明だとかはざらです。こうした問題は 2016 年末から現在に至るまで残念ながらあまり改善されていません。
私は kubernetes が嫌いです。 Google 製品は開発者の UX を考慮しないからです。しかし、 2016 年においても、 2017 年の今においても彼のプロダクトが商用環境における事実上唯一の選択肢でした(ついでに言うならば docker service コマンドで kubernetes いじれるようになるので UX 問題も解決する)。正直、 2016 年から swarm mode を仕事で使おうとしたのは、深刻なソフトウェア検証能力の欠如を感じます。
実は分散ファイルシステムも独自に開発しました。もともと既存のオープンソースのファイルシステムを使っていたのですが,それだと期待する性能が出ないことがわかり,独自に調査開発を進めることにしました。
こちらの記事を読んでいただければわかりますが、配信基盤の再構築を行うにあたって
ということが分かります。
触れない話: 事実上全然稼働しなかった CTO 、北の将軍様
パブリッククラウド、特に CDN を採用することは開発負担の軽減に多いに貢献するように考えられます。実際「 akamai 使えよ」みたいなこと言ってるユーザーは結構いるわけです。ではなぜ彼らがそうしないのか、その意思決定の理由をここでは探ってみます。
動画ストリーミングサービスとして遅れているというのは恥ずかしいことではありますが、ハードウェアや使っている回線の影響もありますので、どのサービスも最終的には同じになると思っています。その差をつけられることはこの先はなくなると思っています。
ようするに CDN 屋だろうが自前だろうが最終的に同じようなところに落ち着くだろうという予測を彼らは立てているということです。しかし現実問題として現在競合他社との差は大きく、新配信基盤のリリースの目途は立っていません(半年以上の遅れというのは通常そういうことでしょう)。ではなぜ彼らは最終的に差は無くなると予測するのか。私はこの点において彼らが空元気をふりまわしているとは思いません。
CDNのトラフィックエンジニアリング:CDNの現状とSDNの可能性
要するに CDN 各社は現在逆ザヤで出血を続けながら戦闘しており、 DDoS 対処を中心としたセキュリティサービスにより最終的な帳尻を合わせている状態です。自前で動画配信インフラを構築した経験のあるドワンゴは CDN 大流行の早い段階から「成立するビジネスではない」という見通しを立てていたであろうと思います。
ただしこの点において今後もビジネス環境、技術環境が現在のように推移するのかは、私にはよく分かりません(誰にも分かってないでしょう)。結局同じようなところに落ち着くならありもの使っとけよとは思わなくはない。
まあもう無理でしょいろいろ
