  |
はてなキーワード: unix系OSとは
ただしスタンドアロンのアプリを書いてる人については特に問題ない。
要はシステム構成がWindowsPC1台orスマホ1台のみで済むとか、組み込みとかね。
それからITゼネコンの末端で、詳細設計をコードに翻訳するライン工もどきみたいな立場の人も別に知らなくていいけど、それもうプログラマーじゃなくて単なるコーダーだよね。
こういうこと書くと
とか言い出すやつが絶対にいるんだけど、今やクラサバモデルのシステムは開発のメインボリュームで、かなりの数の開発者に関係する話じゃねーの？って思うから言ってるわけで。
あと、Linuxというか本当はUNIXなんだけど、現状サーバ用途のUNIX系OSがほぼLinuxで占められているので。
なんでLinuxが使えないと問題かというと、実際にサーバを運用しているエンジニアとまともにコミュニケーションが取れないから。
それが回り回って開発と運用が対立する、あるいは何かあったときに適切に連携できなくなる遠因になる。
本当は開発側がサーバ側の運用設計まで書いて、運用するSEに承認してもらうまでが仕事。
そのためには自分が作るシステムの動作環境の構築は自力でできなきゃダメだし、そのためにはLinuxの基本的な使い方を知っている必要があるわけで。
それにネットワークプログラミングなのだからある程度のネットワークの知識は必須で、Linuxも扱えない人がそういう専門家になれるとは到底思えない。
まあ流石にスイッチ・アプライアンス・ストレージみたいな話になると、カネ払ってベンダーのセミナーを受講しないとわからないと思うので正直厳しい。
その場合でも、Linuxに触れることで身につけたネットワークの知識が不要ではないどころか、
「今こちらのサーバでこういうコマンドを実行した結果がこうで・・・」
みたいな話をインフラエンジニア相手にできるとできないでは大きな差がある。
最近の流れで、そこらへんを全部クラウドにお任せするにしても、サーバとは一体何者か？レベルは体験的に知っておいたほうがよさそうだし。
↑を書いた元増田ですが、VBの話から派生した話で、やたらコマンドライン(以下CLI)を使った開発に否定的な人間がいて閉口した件。
そりゃ一口に開発と言っても色々なので、本当に統合開発環境(以下IDE)だけで開発するケースもあるのは、こっちも知ってるんだよ。
だから学習者の中で「何をやりたいか」が既に決まっているなら、CLIを全く触らずプログラミングを学ぶケースもアリということなのだろう。
1つ目は、そもそも「プログラムって何？」というレベルの人が「何をやりたいか」なんて決まっているわけがないので、最初から「何をやるか」を決めてかかるのはナンセンスという話。
むしろどういう開発に進んでもいいように、「等号は代入を意味する」辺りから始まって、どんなプログラミングでも基礎の基礎になる、データ構造とアルゴリズムを意識させることに集中させたい。
そのためには難易度低めで比較的潰しが効く言語を、できるだけシンプルな手順で作業できる開発環境で学べる方がいい。
そしたらPythonの実行環境とそこそこ以上の機能を持つテキストエディタを入れて、コマンドプロンプトとかPowerShellとかのCLIから"Helllo, world"が取っ掛かりだと思うわけ。
もしLinuxの環境が用意できるなら同じことをLinuxでも試してもらって、プラットフォームに依存しない開発の入り口くらいを知っておければベター。
いずれにせよ何かを実行する方法が1つではないという重要な知見は、できれば基礎のうちに知ってもらいたいことの1つだし、それはWindowsとLinuxとかCLIとIDEという対比がうってつけかなーと。
ちなみにIDEは、Pythonによる手続き型プログラミングに慣れた後のタイミングで学べばいいと思う。
そこまで行ったら変数の型や、クラスとオブジェクトとかの難しい話をGo言語で学んでおくことで、現場で使われているJava、C#、swiftへの移行もスムーズになりそうだし。
ちなみに「初心者コース」の最後、もし可能ならRustでポインタとメモリの話の触りくらいを体験してもらえると、組み込みに進む際のハードルが少しは下がるんじゃないかな。
もう1つは、いくら現場によってはIDEだけで開発する現実があっても、CLIを使った開発がどういうものかくらい、プログラマにとっては知ってて当たり前じゃねーの？という話。
もちろん「プログラマが何を知ってて当たり前なのか」は、時代の移り変わりとともにどんどん変わる。
大昔ならおそらく機械語とかが必須だっただろうけど、今なら機械語よりはHTMLを読めるほうが遥かに重要なわけで。
あと、UNIX系OSをパーティションごとに主要なディレクトリを分割してインストールしていた時代であれば、edエディタの使い方は必須だったと聞く。
(/binに入るエディタがedのみだったため、もし使えないとシステムクラッシュして/以外マウントできなくなったときに詰む)
でも今やそんなの完全に過去の話どころか、viとemacsの論争ですら多分古い方の問題になるだろう。
そういう過去の諸々も踏まえるとCLIが未来永劫、プログラマにとって常識的なナレッジだとは自分も思っていない。
でも今はまだ、プログラマを名乗るならCLIからコンパイルだ実行だくらいの基礎は知ってて当然だと思うんだが。
それも開発したのは俗に言うスーパーハッカーとかスタープログラマとかではなく、当時全く無名だった大学院生。
だから開発の目的だって、勉強のためかお遊びなのかもよくわからない話だったり。
そこに来て、型落ちロースペックPCでも動かせるフリーのUNIXライクOSとなると、今だったら
みたいに冷笑されかねない話だ。
実際リリースされて間もない1990年代後半から2000年前後辺りまでは
「流行の追っかけしか能がない、ワナビーのクソガキ共が使うおもちゃ」
くらいの立ち位置だった。
当時流行っていたネットスラングに類似する煽り方をするなら「アンチMS厨御用達」みたいな感じだろうか。
「そんな事があったんだー」
で終わるくらい、Linuxは誰でも、どこでも使うOSになっているのは御存知の通り。
UNIX系OSで最もメジャーと言うだけではなく、システム開発やサーバ構築でWindowsサーバとともにほぼ必ず選択肢に挙げられるようになって久しい。
更に直近の10年で、気がつけば世界中で使われているスマホの殆どがLinuxベース(Android)になっている。
つまり誕生からの四半世紀で爆発的に発展・普及したというわけだ。
本当にLinuxを使うなんて今どき普通すぎて、特に取り立てて言うことではない。
一方でLinuxよりもずっとフリーUNIXとしての歴史があり、かつては定番だったBSD系なんて、今やAppleのお陰で辛うじて延命している状態なのだから、これまた隔世の感がある。
とはいえ気になるのは、何をどうやったらここまで信じがたい躍進をしたのか？という事情。
ホビー用途とビジネス用途では要求される信頼性のレベルが異なるので、誰かがそこに手を入れないとこのような発展は望めない。
そこでは大企業がきちんと専門家を入れる形で関わるならなお良い。
そうなるとやはり、まずIBMが白羽の矢を立て、次いでGoogleが積極的にコミットするようになった流れが大きいのだろうか。
このうちGoogleは「弊社はオープンソースにフリーライドしているわけではない」アピールや自社サービスのコストダウン、更にはモバイル分野への進出という諸々の目的に好都合だったのだと思う。
何しろ元々IBMはAIXという自社製UNIXを売ってる会社であり、これを用いた各種サーバ構築はお家芸だったわけで。
更にこのAIXにDB2やWebSphereを組み合わせる方式は、2000年代くらいまではエンタープライズアーキテクチャの2大巨頭だった。
(もう1つはSolaris+Oracle+WebLogic)
そんな会社がLinuxに手を出して、一体何の得があるんだ？という話なわけ。
一つ考えられるとすれば、AIXもDB2もWASも買えない貧乏人もとい中小規模の顧客から、せめて構築と運用の手数料だけでも取るためとか？
まあ確かに一時期流行ったLAMP(Linux+Apache+MySQL+PHP)なら、ライセンス料なしでハードも安価なPCサーバになるので、導入のハードルは低い。
というわけでLinuxの草創期を知ってる人間からしたら、今の状況は世の中が変わりすぎなくらい変わったという感覚が強い。
Androidの不具合がスマホのメーカー依存or機種依存だったり、そもそもLinuxのデスクトップ用途が未だに少数派なのは今後も変わらないだろうけど、逆に変わらないのは多分それくらい。
あとUbuntuは嫌い。
リーナスがLinuxを開発したというのは、どれほど「技術的に」すごい偉業だったのでしょうか？
生越 昌己
回答日時: 2022年4月23日 · 執筆者は841件の回答を行い、180.3万回閲覧されています
なんか呼ばれてる気がした。
「技術的に」はどうってことないものです。別の回答で私の書いた記事が引用されているので、その辺の歴史的なことはそっちを読めばわかると思います。「やればできる」範囲のことです。実際、あの記事には書きませんでしたが、そのちょっと前くらいに私の知人(日本人)がフルスクラッチのUNIX互換マイクロカーネルOSを独力で書いてます。これも彼に言わせれば、「教科書通りに実装しただけ」とのことです。なお、UNIX系OSの実装は、いくつか教科書が出ています。また、「NET2」という4.3BSDのフリー(ってことになっていた)な部分のコードも公開された後です。つまり、参考にするものは結構あったんです。
実はOSそのものは、「技術的にすごい」必要はないです。もちろん、いろんな点で「技術的にすごい」ことをする必要性のあるところはありますが、「普通の実装」であれば「教科書通りに実装しただけ」で作れます。「ぼくのかんがえたさいきょうのプロセスモデル」なんてものは必要ありませんし、「マイクロカーネル技術」なんてのも、あればあったでメリットありますが、なければなくても困りません。UNIXのその辺は普通の人達が思っているよりもずっと単純で、実装もそんなに難しいものではありません。ですから、特に「何かの互換品を作る」というのであれば、動かすだけであればそんなに大変ではありません。バランス感覚が要求されて難しい部分は既に他人が実装しているわけですし、「教科書」や「参考コード」はいっぱいありましたから。
Linuxが凄かったのは、一つは「運」です。多くの人が求めているタイミングで、まがりなりにも動くものを出すことができた。これは多分最大最強の「すごいこと」です。
Linuxがリリースするちょっと前に、AST(Andrew Tanenbaum
)はMinixの「次のバージョン」についての「やらないことリスト」を作っていました。野良で作られたMinix386を使っていた人達を始めとする「MinixがもっとUNIXになって欲しいと思っている人達」は、それを見てガッカリしたものです(私も)。Minixを実用品にしようとする流れに完全に背を向けた形で「教材としてのOS」に力点を置いたもので、ASTの立場を考えれば当然とは言え、いろいろ残念な思いをしました。Linuxがリリースされたのは、そのショックから覚めやらぬ時期だったので、それを見た人達は、まさしく
ｷﾀ――(ﾟ∀ﾟ)――!!
その次に凄かったのは、「それを実用品に持って行けた」ことです。「動く」ということと「実用品になる」ことの間には、とんでもなく深い「谷」があります。これを超えるのは、「運」も大事だし「技術」も不要じゃないんですが、それだけでできるものでもありません。そもそもLinus自身が「最初はそんなつもりはなかった」的なことを言ってますからね。それでもどこで気が変わったか、あの「隙だらけのカーネル」でも、なんとなく実用品として使えないことはない程度にはなっていた。
そして、「隙」も凄かった。Ver 0.01のカーネルなんて、本当に隙だらけ。たとえば、システムコールのエントリテーブルがあるのですが、その先の「実装」部分には「未実装」ってコメントが1行書かれているだけなんて状態だったのです。これは結構後の版でもありました。でも、その「隙」ゆえに、多くの人に愛され、「俺が何とかしてやろう」と思わせる。当然意図したものじゃないにせよ、これがなかったら「今」はなかったかも知れない。
等々、いろんな「凄さ」はありますが、それは技術そのものではありません。「凄さ」は別のところにあったのです。
独自に似たものを作ってた人達(私も含まれる)が、一斉に自分の作っているものを投げ出して協力しようと思うくらいには「凄く」また、「隙」があったんですから。「マイクロカーネルこそが」とか、まぁとりあえずマトモに他人の使える自前実装作ってから言ってよね。ちなみに当時の私はMach
をいろいろいじくってました。Ver 3.0になっていろいろいじれるようになってて、MS-DOSの上からbootする版を作った人がいたんで、「これでユーザ空間でOS書けるじゃん」って。
そんなわけで、「ぼくのかんがえたさいきょうのOS」を作らなかったのが、Linusの偉かったところ。愚鈍に「どうにかこうにかUNIXとして使える程度のもの」をちゃんと作っていいタイミングでリリースした。そこが全ての始まり。
「毒にも薬にもならない昔話」とはこのことではないだろうか。
老人ならせめて1行くらいは誰かの役に立つ言葉がにじみ出るものだが・・・
そういう生き方としてきたということだろう。
ご指摘ありがとう。ごめん「GPUに直接」って書き方が悪かった。だったらディスプレイ出力すらできないよねって話になるよね。DirectXの説明しても99.999%の人にはなんのこっちゃだろうから「直接」って表現をしたまでよ。言いたかったのはProtonの発表が2018年で、ごく最近のことだっていうこと。「これは恥ずかしい」っていうタグでわざわざ畳みかけるように指摘されてるのは、それを専門にしている開発者の矜持なんでしょうな。いい仕事してそう。
ValveがWindowsゲームをLinuxで動かす互換レイヤー「Proton」を発表
2018.08.23
PCゲームプラットフォーム「Steam」でおなじみのValve社が8月21日、Codeweavers社と共同開発したWindows専用ゲームを動かせる互換レイヤーを発表した。この互換レイヤー 「Proton （プロトン）」はLinuxユーザなら誰もが知っているWineを改造したもののようだ。
Protonはかなりの改造を施されており、いろんなところからかき集めたプログラムや技術が詰め込まれている。
ProtonにはDirectX APIコールをリアルタイムでVulkanのそれに変換するレイヤー（DXVK）が組み込まれているため、DirectX APIで作られたゲームでも割と軽快に動作する。
もともとVulkanとDirectXには機能的にそこまで大きな違いがないためだろう。相互に移植するのも難しくはないと言われている。
またOpenVRへの対応や ゲームのフルスクリーンモードの取り回しを改善、Steam対応のコントローラのサポートも改善している。
ProtonはオープンソースとしてGitHubに公開されているので誰でも中身を見ることが出来る。ベータの段階でこんなにいろんなプログラムをSteamに統合できたことに驚いたが、2年の開発期間を要したそうだ。
https://slacknotebook.com/valve-releases-compatibility-layer-for-linux-proton/
SteamユーザーがLinuxに切り替えても不自由なくゲームを楽しめるよう開発された「Proton」でプレイできるタイトル数が1万2000本を突破
PCゲームの販売プラットフォームとして絶大な人気を誇るSteamを開発するValveは、Windowsユーザー以外にも幅広くPCゲームを遊んでもらうために、Windows向けのゲームをLinux上でもプレイできるようにするためのオープンソースソフトウェア「Proton」を開発しています。
ProtonDB | Gaming reports for Linux using Proton and Steam Play
2018年8月にリリースされたProtonは、Steamの開発元であるValveとソフトウェア開発企業のCodeWeaversが共同開発しているソフトウェア。ProtonのベースとなっているのはUNIX系OSでWindows向けのソフトウェアをネイティブ動作させるために作成されたWineであるため、ProtonはWineのフォークとも言えます。なお、Protonはオープンソースのソフトウェアであるため、ソースコードはGitHub上で公開されています。
そんなProtonに関するデータをまとめたデータベースがProtonDBで、同サイトでは「Protonでのゲームプレイに関するレポートの総数」「レポートが提出されたタイトル数」「Protonを用いることで何かしらの修正なしにLinux上ですぐにプレイが可能になるゲーム(プラチナゲーム)数」がまとめられています。
2020年4月時点ではProtonで問題なくプレイ可能なプラチナゲームの数は6502本で、Steam上でリリースされているゲームの約50％がプラチナゲームとしてLinuxでプレイ可能でした。
SteamのゲームをLinuxでもプレイ可能にする互換レイヤー「Proton」のこれまでの功績とは？ - GIGAZINE
2020年12月8日時点でのプラチナゲームの数はさらに増えており、その数は何と1万2753本にまで増加しています。なお、「Protonでのゲームプレイに関するレポートの総数」は10万4508件、「レポートが提出されたタイトル数」は1万6232本です。
なお、Protonはバージョン5.13が2020年11月にリリースされたばかり。アップグレードのリリース時には、CodeWeaversのJames Ramey社長がProtonプロジェクトや会社の現状について語っています。
Podcast With James Ramey - Full Transcript - Boiling Steam
https://boilingsteam.com/podcast-with-james-ramey-full-transcript/
Protonのバージョン5.13では、ゲームの互換性に関する問題で大きなネックとなってくるアンチチートソフトウェアを回避するプロセスについて前進を見せているとのこと。ただし、ゲームが搭載するアンチチートソフトウェアとProtonの戦いは、Protonのリリース当初から続いている問題であるため、バージョン5.13で完全決着を見せるというものではなく、今後も戦いが続いていくこととなる模様。なお、次の次のアップグレードもしくはさらに次のアップグレードあたりで「NTDLLによりブロックされているゲームがプレイできるようになる」とRamey社長は言及しているため、Protonでプレイできるタイトルの数がより増えることなりそうです。
また、2020年に猛威を振るった新型コロナウイルスのパンデミックについて、Ramey社長は「幸い我が社はかなり分散した企業です。我々の開発チームの多くは西ヨーロッパ、東ヨーロッパ、アジアに拠点を置いているため、すでに在宅勤務を行っています。ミネアポリスにあるオフィスでは25人の従業員が働いていましたが、これも在宅勤務へと移行しています。通常時、我々は定期的にオフィスへ通っていましたが、2020年3月の第2週以降は1度オフィスに行ったきりです。元々リモートで仕事がこなせるように会社を設立したため、生産性の観点でいえば、新型コロナウイルスによる影響は皆無です。また、新型コロナウイルスの検査で陽性反応が出た従業員が何人かいたので、その従業員たちは必要に応じて休暇を与えました」と語りました。
さらに、Protonの登場によりLinuxをネイティブでサポートするゲームタイトルがSteam上から減少しているという指摘もあります。以下はSteam上で配信されているゲームタイトルのうち、ネイティブでLinuxに対応しているタイトルの数を示したグラフ。Protonがリリースされた2018年8月以降、明らかにLinuxをネイティブでサポートするタイトルの数が減っています。
これについてRamey社長は「Protonが提供するのは『Linuxでのゲームプレイ』という体験だけでなく、ゲーム開発者がLinux市場に簡単にアクセスできるようになるという機会でもあります。すでにリリースされているWindows版のゲームが、Protonを使用することで再開発なしで第二の市場に投入することが可能になるのですから」と語り、Protonの登場によりゲーム開発者がより手軽にLinuxユーザー向けにゲームを提供できるようになった点が関係ないとは言い切れないと主張。
特にゲームエンジンにUnreal Engineを使用していない開発者は、再コンパイルや変更なしで簡単にゲームをWindows市場だけでなくLinux市場にも投入できることをRamey社長は強調しています。また、Linuxにはさまざまなディストリビューションが存在するため、Linux市場で幅広いユーザーを狙ってゲームを販売することは非常に困難であるとRamey社長。その一方で、Protonを使用すればWindows向けにゲームを開発している開発者が、手軽かつ多くのユーザー向けにLinuxで動作するゲームを提供できるとしています。
また、ますます多くのゲーム開発者がProtonに気づき始めているそうで、Ramey社長は「まだ大騒ぎという段階にはありませんが、多くのインディー開発者がProtonに注目し始めているというだけでなく、大規模なゲーム開発者の多くもProtonに興味を示しています。その大きな理由は非常に低コストで別の市場にアクセスできるという点です。そのため、今後より多くのゲームがProtonで不自由なくプレイできるようになると思います。また、開発者が開発プロセスの段階でProton上でテストを行えるようになる可能性もあるでしょう。そのため、どこかのタイミング(転換点)で『ゲームが機能するかについてProtonの開発元であるCodeWeaversに問い合わせる必要性』が大幅に減少することを期待しています。我々が行っている多くの事柄は、そのための基盤を構築することです」と語りました。なお、Ramey社長は転換点が「今後12カ月以内にやってくる」とも主張しています。
iPhoneの話題でAndroidとの比較を、日本のケータイの歴史も絡めた増田がホッテントリしていたけど、
個人的には、むしろAndroidがここまで普及したことのほうがにわかに信じがたい話だったりする。
自分は、大学で覚えたパソコンで2ちゃんどっぷりだったキモオタ系ということもあり、
すでにJK～20代の女性とっては当たり前になっていたガラケーも、仕事するようになって数年後、渋々持ち始めたくらいの代物。
だからそもそも、ガラケーの文字入力からして使いにくかったし、iモードに至ってはなにそれおいしいの？という感じ。
だからW-ZERO3とかBlackBerryといった、液晶画面+qwertyのハードウェアキーボードという当時のスマートフォンは、文字通り垂涎の的だった。
「本物のネットはパソコンの世界にあるもんだ、スマホはそこらへんをよくわかってる」
と胸踊らせたものだった。
しかし自分がいたキャリアはあくまでガラケー一辺倒=そういう機種は一切ラインナップに加えないので、本当に歯がゆかった。
そんな自分がアラサーのとき日本に上陸したiPhoneには、そりゃもう興奮した。
しかしまたしても「スマートフォンはまだ早い」とか言ってたキャリアが…。
さて、そんなiPhoneの後塵を拝す形でひっそり登場したのがAndroidなわけだが、これがモノになるなんて正直思えなかった。
海外ではすでにハードウェアキーボードのスマホが一定のシェアを持っていたことはなんとなく知っていたし、そういう従来のスマホとiPhoneの一騎打ちになると予想していた。
だってBlackBerryもNokiaもめっちゃ強かったから、まさかソイツらがブランドイメージ皆無なAndroidに全て駆逐されるなんて、ありえないと思うじゃん。
何よりAndroidがLinuxのスマホ向けディストリビューション、要は中身がLinuxということが、以下の理由でパっとしない感を更に強めていた。
あと全面液晶の「iPhoneクローン」なスマホだったら、Windowsのモバイル版が伸びるだろうと思ってたこともある。
Windowsはそこそこの値段でそこそこの使い勝手のデスクトップPC向けOSとして、当時はもちろん今もデファクトなわけだし、その実績からLinuxというCLIメインのOSよりも、ずっとスマホに近い場所にいると思ってたし。
それにスタープログラマのカトラーが文字通り人生を賭けて作ったOSなんだから、少なくとも院生のお遊びから始まったLinuxなんかよりは、モバイルでも上手くやるだろうと。
そういう当時を空気感を知っていて、かつ、ほぼXperiaしか触っていないとはいえ5年以上Androidスマホを買い替えつつ過ごした人間として、正直Androidなんて…と思っているわけで。
そして去年ようやく念願のiPhoneに乗り換え1年ちょっと経ち、「別にAndroidでいいじゃん」が「もうAndroidには戻れねえ」となった結果、更にその思いが強くなったと。
だから、AndroidとiPhoneをガチで比較してなお「Androidでいい」とか、ましてや「Androidがいい」という人は、一体何を見てそう思ったのか、心底理解できない。
PixelやGalaxyや中華スマホは触ったことないけど、Xperiaは国産スマホでは最高レベルに優れていると聞くし、そんな高級スマホと比較してもiPhoneのほうが全然使いやすいのだが。
元増田です。
なんか、大人しくUbuntu使っとけば問題ないみたいなブコメがあったけど、Ubuntuだって初心者には普通に難しいからな？
それこそWindowsやmacと比べたら、明らかに高頻度で躓くケースが多いね。
だからサポートする方も大変ってか、Windowsやmacよりも手がかかるのが現実。
「お前、Linux使っててそんなとこまで訊くんだったら帰れよ」
と何回思ったことか。
そんな感情を押し殺して
「(しょうがねえなあ～)○○って知ってる？勉強しとけよーw」
で済ますが、正直言って全く気分は晴れない。
何がモヤモヤするって、Linuxを始めとするOSSに馴染んでいる人間ほど、
「確かに取っ掛かりは難しい。でもそれを乗り越えた後に、素晴らしい『自由な世界』があるんだ」
「どのソフトも時に使いにくいとさえ思うくらい個性的な手触りだけど、それこそが多様性であり、善なんだ」
という主旨の内容を、マントラかよって勢いで唱えるわけだが、まあ正論だけどズレてんなーって感じるんだわ。
アレっすか、一億総ハッカー社会を目指してるんですか？あるいはポール・グレアムの言うようにいっぱしの画家気取り？みたいな。
そりゃ、職業プログラマーとかがここらへんの話を知らないとなると、確かにヤバい。
あと、今のソフトウェア開発はほぼネットワークと不可分だったりするので、Linuxを含むUNIX系OSもろくに扱えないレベルの人間が、ネットワークの専門的知識を得ることは不可能という意味で、開発者ならUNIXくらい使えんだろって話もある。
でもさ、そんなんパソコンを仕方なく使ってるような「普通の人」にはどうでもいい話なわけ。
それこそ多様性云々にしたって、例えばTeXやgnuplotやPerlやsendmailやbindといった、便利である以上に、その複雑怪奇な仕様で長年に亘ってユーザを苦しめ続けてきたことの言い訳にはならなくね？
あと日本語処理が、結局Googleが本気でLinuxに肩入れするまで、UNIX系OSでは(少なくともWindowsと比較して)まともに動作していなかったことも知ってるからな。
それにMS OfficeとAdobe Creativeの代替足りうるOSSは、未だ登場していないし。
鼻につくってそういうとこだぞ？わかる？
一般的に、自由であることと快適であることは全く関係ないけど、これはソフトウェアにもまんま当てはまる話だと思うね。
これまたブコメに「Androidは世界で最も成功したLinuxディストロ」とあったから言うけど、Androidよりも、そのパクリ元かつプロプライエタリでクローズドなiOSのほうが、ごくごく普通にスマホ使ってるぶんには遥かに快適だからな？
そりゃAndroidはスマホというハードウェアを自由にいじり倒すには最適なんだろう。
でも多くの人にとっては電話とメールとWebとLINEとゲームとオーディオと写真や動画の鑑賞・撮影くらいがサクッと使えれば良くて、そういうありふれた用途に限定される反面、それらの使い勝手をパッキパキに洗練させた、iOSのほうが使いやすいわけで。
まあ、AndroidスマホがiPhone買えない貧乏人のイノベーションとして、特にまともな回線の整備がおぼつかない開発途上国の通信環境を、少なからず改善したことは大いに意味があるので、まあ認めて「やるか」って感じだけど。
話を戻すと、ぶっちゃけソフトウェアの場合は、自由になるために要求される水準が高すぎるんだわ。
それに無自覚、あるいは気づかないフリをしているOSS論者の多いこと多いこと。
そんなんだから、お前らの言ってることは
という風にしか聞こえないんだよ。
そこも含めて、OSSは思想そのものからして途方もなく左巻きってことには、もっと自覚的になるべき。
まあでも、なんだかんだ言って世の中は左翼によって良くなってきたことも事実なので、それだけでもOSSの意義は十分にあると思うけどね。
もしこれが同じUNIX系OSでも*BSDであれば、Linuxのディストリビューションに当たるものは事実上3つしか存在しないので、それだけでも敷居は大幅に下がる。
もしこれが同じUNIX系OSでも*BSDであれば、Linuxのディストリビューションに当たるものは事実上3つしか存在しないので、それだけでも敷居は大幅に下がる。
言い換えるなら、多様性が各種設定を難しくし、普及を妨げているってこと。
ディストリビューションの違いはもちろん、同じディストリであってもバージョンの違い、更に同じバージョンであってもインストールするパッケージの違いがあるお陰で、Windowsやmacみたく
みたいなハウツーが成立し得ない。
それどころか、あらゆる手順が
「俺んとこではこれでうまく行ったぜ？」
だからLinuxを扱う者はこれを踏まえた上で、トラブルを基本自力解決できる事が、事実上の最低レベルとして求められる。
「俺は別に、OSの勉強がしたくてLinux触ってるんじゃねえ！」
もしこれが同じUNIX系OSでも*BSDであれば、Linuxのディストリビューションに当たるものは事実上3つしか存在しないので、それだけでも敷居は大幅に下がる。
というか*BSDが本気で普及に乗り出してたら、OSの中では新参な上に、大学院生のお遊びがきっかけで作られたLinuxなんて、一瞬で駆逐されただろう。
プログラマじゃないけどプログラミング完全に理解した（）おばさんが理解してる基礎知識書くよ。
（追記 この文章はプログラミングの勉強をしたいけどその周辺にある基礎知識になかなか触れる機会がない人向けに書きました。これらの基礎知識があると、困ったときに調べ方すら分からないという状況は回避しやすくなるはず）
ターミナル、いわゆる黒い窓から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というものを書くことになった時とかに効いてくる。あとは作ったプログラムが遅すぎてどうしようとかいうのを解決する時とか。
なんか深夜までいろいろ書いてしまったけど、あくまでもプログラマじゃないおばさんが書いたものなので、みんなでツッコミとか入れてくれると大変助かります。
こんなのそこらへんの学生でも持ってるスキルだろ。こういう甘い条件で人を集めてバサバサと不採用にして何がしたいのかわからん。たまにいいのが来ればいいや？みたいな感じ？どうせ内部では経歴や年齢や学歴で差別してるんだろ（と疑われても仕方がない）。
（株）はてな 6.59% 445352200円
毛利 裕二 5.98% 404128400円
梅田 望夫 4.30% 290594000円
伊藤 直也 1.79% 120968200円 ○
田中 慎司 1.30% 87854000円 ○
小林 直樹 1.15% 77717000円
お金の額面はともかくの話なんだけど、
○をつけたのは、はてなのコードを書いたことがあると"思われる人"。「名前 プログラミング」で検索して有意な結果が出た人に○つけた。各株主の詳細知りたい人は適当にググって
で、さらに
はてなの年収は524万円が平均年収です。（有価証券報告書調べ）
http://heikinnenshu.jp/joho/hatena.html
スクリプト言語（主に Perl/PHP/Python/Ruby/JavaScript）によるアプリケーション、ライブラリ開発の経験
ScalaやGoにおけるアプリケーション、ライブラリ開発の経験
iPhoneアプリ、もしくはAndroidアプリの開発経験
UNIX系OS、RDBMS （特に Linux、MySQL）についての基礎知識
コンピュータサイエンス（アルゴリズムとデータ構造、分散技術、自然言語処理技術、機械学習、データマイニング、型理論）に関する基礎知識
ネットワーク技術（HTTP、DNS、TCP/IPなど）についての基礎知識
大学卒／275,000円〜
http://hatenacorp.jp/recruit/fresh/application-engineer-entry
この毛利 裕二という人の持ち株の資産を新卒の給料(計算だるかったから計算からボーナス抜いたけど、手取り分で考えたらボーナス分くらいは消えるだろう)で稼ぐとしたら122年かかるし、梅田 望夫という人は88年かかる。本当にこの人たちにはそれほどの価値(上にあげた新卒に求めるやたらと高いスペック)分の価値があるのか？いや、価値があると思ったから株をあてがったんだろうけど...
まぁなんていうか...、はてなのエンジニアのみなさんお疲れ様です...業務がんばってください
10年位前、上位のサイトから電文を受け取り下位のサイトに再配信するプログラムを、Linux上にC言語で実装する仕事を引き受け、死ぬ思いで片付けた。
その時にお世話になったのが「UNIXネットワークプログラミング」という本。
この本、POSIX準拠のOS(要するにLinuxなどのUNIX系OS)におけるシステムプログラミングのノウハウに関しては名著、いやバイブルと言っていい。
名著が絶版になる理由は色々あるだろうが、この本に限って言えばもはやそういう時代じゃない、そういう低レベルの実装はトレンドじゃないということなのだろう。
でも、そしたら「決して遅延が許されない再配信プログラム」は、一体何をどう使って作るんだ？
プロセス間通信やスレッド制御、更にはシグナルも使い、それらが高速で動作しないといけない(いやスレッドは難しすぎて結局使わなかったけど)システムで、そんなオーバーヘッドが高い言語は使えないと思うのだが。
それらを解決できる気の利いたライブラリやフレームワークもなさそうだし。
或いは回線とスイッチを高性能にして、サーバリソースも上げられるだけ上げるというように、インフラ側の強化で解決しちゃうとか？
いや、officeは普通にmac版officeを入れればいいと思うけど、開発環境は基本的にオープンソースで自分で入れる必要があるということ。
python入れたいとかruby入れたいとかC++のboost入れたいとかそういうの。
windowsだとそもそも謎の依存関係で開発環境自体が上手く入らなかったりするし、
パッケージ管理システムも無いからバージョンアップとかの管理が超めんどくさい。
mac(というかunix系OS)はその辺がかなり綺麗に構造化されてるので便利。
募集要項
・運営ツールの開発
求める経験
【必須経験】
・C/C++、perl、Ruby、Python、PHPなどを用いたプログラム開発経験
【歓迎経験】
C/C++, Perl, Ruby, Python, PHP全部使ったことあるよ！
PythonとPHPは仕事では使ったことないから微妙だけど。あとC++の言語仕様は完璧には把握できてないけど。
でもC/C++は商用のコンパイラを作るプロジェクトに参加してたこともあるしバッチリだよ。
Rubyは1.6の頃にインタプリタのソース全部読んだりしたけど最近の進化にはついていけてないかも。
【歓迎スキル】
・MySQL、PostgreSQL等のRDBMSに関する知識
このへんも全部あるよバッチリ。
そんなものは求められてないだろうけど、
RDBMSも3Dも仮に一から自分で全部作れと言われても簡単なものなら作れるレベルだよ。
しかし…
おおどうもありがとうございます。
社会人暦は数年あるんですが、この業界に入ったのは今年の3月頃です。全く別職種から。
元々理系なんでCとかFORTRANのスパゲティコードくらいは書いたことがあったという感じでした。
自作PCは昔々に1台作りました。SATAの読み方は最近知りましたｗ
ジャンルはweb系ではないです。業務系でも組み込み系でもないですが。
ネットワークとDBはさっぱりです。あとGUIもわかりません。これはまずいと思っています…。
あと地味にUNIX系OSもよくわかってないです。
この前valgrindをインストールしようとしてよくわかんなくて諦めましたorz
今日はmakefileが上手く動かなくて発狂しそうになったりもしました。
emacsのキーバインドにも慣れないし、cygwinの日本語化も結局未だに上手く行かず…。
周りが優秀なので焦るばかりです。これは感謝すべきことですが。
プログラム一本で食べていけるとは思えないし、自分のやりたいこととも少し違うので、
プログラミングに関しては中の上から上の下くらいのレベルを目指そうと思っています。
あと1回は転職すると思いますし、今26なので、30までにはどこにでもいけるようになりたいと思っています。
それにしても憶えること多すぎですね…。全体がわかるようになるのはいつになるのか…orz
