  |
はてなキーワード: UNIXとは
TakamoriTarou ここでWindowsを選んだことで、娘の人生の可能性が広がった。もしこれがMacでは、可能性を狭められ未来の選択肢が大幅に減っただろう。信者商売のMacは普通にプロの道具として使えないしな。普通のUnixではもはやないし
ustam ここでMacを選ばなかったことで、娘のIT人生は終わった。初めて扱うコンピューター端末がWindowsでは、苦手意識を持って積極的に触ろうとしないだろう。UIとかデザインとか、普通にダサいしな。UNIX系じゃないのも辛い。
https://b.hatena.ne.jp/entry/s/edu.watch.impress.co.jp/docs/report/1609983.html
富士通に忖度してるとか言ってるけど、あれ、普通に取材NGだったんじゃないかな。
当時の経緯を知ってると「私の名前は出さないでください」ってなったとしても不思議じゃないと思う。そうなれば当然NHKも富士通も触れないし、本人が拒否したんですなんて発表するわけもないし（例え親族が声を上げたとしても）
京コンピュータって、富士通半導体の最後の打ち上げ花火だったんだよ。
京の開発が進み、実際に生産されるころは、経営方針として富士通は半導体撤退をするかどうかで揉めていたころだった。
京コンピュータは、富士通が自社工場で作った最後のスパコンであると同時に、国のトップ開発のHPCにおいて、富士通が単体で作り上げた初めてのHPCでもあった。
これは、富士通が優れている、というよりも、逃げ遅れたと表現してもよいかもしれない。HPCのプロジェクトからは、NECと東芝が次々と撤退していたのだ。
当時半導体の重い投資に堪えられなくなった電機各社とその銀行団は、自社から半導体部門、少なくとも工場を切り離したがっていた。まさに、それどころではなかったのだ。
しかし富士通はまだ撤退を決断せず、他社とは一線と画した対応をしていた。
ようにみえた。
京コンピュータのCPUは、45nmのプロセスで作ると言うことで言っていたためか、富士通はなんとか自社で開発した。けれど、京に乗せたプロセッサで最後になった。次のプロセスは開発されていない。
https://news.mynavi.jp/techplus/article/architecture-467/
さらに、当時、45nmのプロセスは安定して無い状況で無理矢理作ったと言う話もあったはずだ。これは京コンピュータ以降はTSMCに委託することが決まっていたため、既に投資が絞られていたためでもある。
（後にTSMC版の進んだプロセスで製造されたSPARCを使ったミニ京コンピュータが何個か作られたのだが、ノード辺りの性能が30％以上アップしたと言う。これはプロセスが細分化された以上の性能向上であった）
富士通が、自社の半導体部門を富士通セミコンとして切り離したのが2008年。京コンピュータ用のプロセッサを生産したのが2010年の三重工場であった。
その三重工場は2013年にさらに別会社として切り離され、現在は完全に売却されて富士通に残ってない。
また、同じく半導体工場としては福島県の會津富士通があったんだが、その時の工場撤退のエピソードは、今でも大企業は黒字でも簡単に工場を撤退させる事例として有名になった。かなり悲惨な事態だったと言える。
そうして重荷になっていたとされる工場を切り離しファブレスに近い業態にしたのは、富士通半導体を残すためだったと思われる。
しかし、そうした建前などなかったかのように2014年にはシステムLSI/SoCの開発部隊の分社化を決定。それが現在のソシオネクストである。PanasonicのLSI部隊と合弁した会社で、分離した当時、富士通は設立当初40％の株式を保持していたが、現在は完全に売却してしまった。
現在、富士通の半導体部門はFeRAMや光回路用の超特殊なものを除いて完全売却で撤退している。
なお、その後、ルネサステクノロジ（※富士通は合弁に参加していない）が組込向け半導体でほぼ世界首位と同率2位まで上り詰め、国内半導体の必要性が新たに叫ばれTSMCが国内に半導体工場を建設。Rapidusという日米政府が関わる半導体企業ができる流れになっている。もし将来、RapidusがプロジェクトXになるときには、大手電機産業からリストラされた技術者達の奮起という文脈が語られそうな気がする。閑話休題。
件の方がご退任をされたと言う2012年は、半導体のさらなる切り離し、売却などの決断と、次期スパコン（つまり富岳）がSPARCを捨ててARMになるという決断が行われた年であったと考えられる。（発表は後になる）
半導体を専門にされてずっとやってきた方には堪えられないもだったのではないかと拝察する。仮に、思い出したくもないし、宣伝にも使われたくないと判断されても仕方がないことでは無いかと思う。（もちろん 出演NGされたと言うのはワイの妄想なので注意)
その後、富士通はSPARCを使ったUNIXサーバーを作り続けてはいたが、大きくアーキテクチャを改善する開発は行われないまま（保守設計は続けられていたが）メインフレームとともに撤退が発表された。これはやむを得ないことだろう。
また、ARM化された富岳は、確かに性能面や利用面、汎用性では高い成果を出したが、富士通のビジネス的にはさっぱりだったと思われる。
アーキテクチャをARMに切り替えた理由は、ビジネス面でもあった。高性能タイプのARMを作ることによって、旺盛なクラウドDC需要などに対して食い込んでARMサーバを大きく拡販していくことだったと思われる。
が。富岳に乗せたARMプロセッサを利用した波及製品はみられなかった。
なぜか。それはAWS、MS Azure、Googleなど膨大な需要を持つ企業は、需要が巨大すぎてARMが搭載されたコンピュータを買うのではなく、自社でARMのIPを購入し独自開発することを選んだためである。
彼ら相手には商売にならなかった。それ以外のクラウドベンダーは無きに等しい。ARMなどアーキテクチャが影響しないのはPaaS以上の象徴度を持つサービスだが、寡占状態にある大手以外まともに提供出来ていないため、市場が無いのだ。
ただし、この時富士通とARMの競業によってARMは成果をあげた。アウトオブオーダー実行など、ARMは高性能コンピュータで必要な技術を富士通から取り込んで現在に至る。
それ故、富士通の商売は上手くいかなかったが、世の中的には良かったとは言えるのではあるのだ。そのIPで大手クラウド各社は自社向け半導体を作って商売をしているのだから。
だから今のタイミングでプロジェクトXに乗ったのだと思うが、綺麗事では語れない話がたくさんありすぎる。
受注はまず間違い無く富士通だと言われている。と言うのは、開発の一部は既に行われているから。
https://monoist.itmedia.co.jp/mn/articles/2310/12/news074.html
そして、国内にもう国産でHPCを作ることの出来る会社はNECと富士通ぐらいになってしまったためである。
富士通は新しいHPCは1位を目指さないかもしれないという考えから、計算効率の方に大きく振った開発を進めおり、国内トップのHPCに採用されたという実績を背景に売り出そうというつもりではあると思われる。富岳の夢再び、だ。
https://cloud.watch.impress.co.jp/docs/special/1560540.html
https://www.fsastech.com/about/
ご覧の通り、富士通のブランドを一切使っていないのだ。既存の商品からも富士通マークを取り払っている。さらに、会社概要に株主欄がなく、富士通の名前が出てこない。（他の関連会社はそういった記載がある）
半導体がどうなったかの流れを知っていると、暗い予感しかしない。
そして、HPCはレイヤーの低い、ハードウエアに近い部分、さらにメカニカルな設計や冷却など物理的な部分のノウハウが多く必要とされる。それを富士通が分社化して製造能力を失っていく中で、果たしてまともにHPCが作れるのだろうか？
さらに、確かに2010年代半ばのころはワークロード不足に陥ってコンピュータは安売りに陥っていたが、現在AIと言う巨大な需要が生み出され、価格も回復、ハードウエアが再び重要と考えられ始めている。ハードウエアと同時に提案できる能力が強みになりつつある。
しかし、既に富士通はそれらに対応するための強みを、はした金と決算の数字をよくするためだけに売り払った後である。案の定、粉飾紛いの異様に高い目標に対して、結果が出ないと言う発表を繰り返している。
富士通はアクセンチュアを真似ていると言われる。以下の記事にはこうある
https://xtech.nikkei.com/atcl/nxt/column/18/00848/00049/
目指す先はアクセンチュア、富士通が主力工場を総務に移管する理由
時田社長は2019年9月に開いた初の記者会見で「開発製造拠点をどう整理するのか」という質問に「既に方向は定まっている。後は状況判断と時期の問題。富士通はサービスに集中する企業になる」と応じていた。
そこまでやったのに、ここ3年ほど株価は伸び悩みが続いている。アクセンチュアの真似をしますと言ったときは撥ねたがが、その後は同業他社や業界全体の株価上昇率に及ばない状況が続く。
それはそうだ。アクセンチュアの真似をしていてはアクセンチュアには勝てない。まして工場売却を通じ、元々の強みを捨て弱みまでアクセンチュアの真似をしているのだ。富士通がこの先生きのこるにはどうすればいいのか？
言語によっては標準的に月末日を取得できる関数が用意されている
用意されてない場合もそこそこあるし
サードパーティー的なライブラリだとライセンスなどメンテナンス含めて面倒になるので避けることも多い
そもそも仕様を「月末日」などという不確定なものにせずに28日にしてもらう
ちゃんと仕様を決める部門と連携が取れていれば多くの場合で28日にしてくれるし
「28日支払い」が多いのもこのためだと思ってる
割とよくある実装がこの「次の月初めから1日（1秒）引く」という実装
2024年2月の月末日を取得する場合は2024年3月1日のUNIX時間から24*60*60秒を引いて計算する
ただし、実装を間違えると12月31日のときに失敗するので注意が必要
各月の月末日をマップとして保持しておいて取得させる
関数実装するなら if(month==1) return 31 とかを12行書けば実装できる
自分で実装する場合はプログラミングの教科書にあるぐらい有名なのでコピペでもChatGPTでも使えば良い
ただ仕様をそのまま実装せずに「4で割り切れたら閏年」でも問題無い（やったことはないが）
「それだと2100年でバグる！」
ちなみに過去の日付であっても2000年はバグらない（そのための400年処理だし）ため
最高齢の人でも1900年代からなので基本的には問題無いだろう
ひとえに、IT云々に関わらず、リモートかどうかに関わらず、発注者と受注者の信頼関係だと思います。
私は二十数年前まで、メインフレームのCOBOLやJCL、UNIX上のCなどを扱うインフラ系システムを切り盛りするエンジニアでしたが、脱サラに失敗して非正規を今まで続けて参りました。
結局は現役から離れた期間が長くなり、50も過ぎますと、さすがに現場の技術者は務まりません。
まぁ・・・簡単なCですとか、EXCELの関数を駆使したシートくらいは作れますが、そんなレベルでは通用しませんよね。
受注者は自分の能力をどう宣伝できるのか？発注者はどう能力を測るのか？それが難しい。
実際、私も地方の中枢都市在住ですが、なかなか、中央のレベルで仕事できますよ！って主張するのは不安があります。
一番手っ取り早いのは、とりあえず出勤してもらって、ある程度レクチャーして、その結果どれだけのレスポンスがあればリモートにしても良いかなぁ・・・って感じなんだろうなぁと思います。
個人的には初心者プログラマがUNIX哲学周りの本読んでハマるか、キャリアアップできなかったエンジニアが使うのがシェルスクリプトだと思っているが。
話を取り違えている所が
見たこと無いにもかかわらず
あなたこそ使っているコマンドのコミット履歴を見たことありますか？
標準ライブラリのすべての関数のありとあらゆる引数に対する挙動を把握している？
標準コマンドは標準入出力を通してプログラム同士で連携することを想定して作成されており、
入出力の破壊的変更を気軽にコミットしようとしたら秒でハネられます
「ゾウリムシよりも蟻は大きい」を「蟻は大きい」で切って引用するのはやめましょう
規模が大きくなると信頼できない、その場しのぎ的な技術であるのはpythonなどのスクリプトの実行環境も同様です
すべての処理、すべてのプログラムをRustで書くような行為はきわめて非生産的ですし、シェルスクリプト以上に危険です
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
論理的じゃないよね
メンテナの数、レビューする人数、実際に動作している環境etc
シェルスクリプトに使用したコマンドのすべての挙動を把握している？
使用予定のオプションだけでも出力結果のすべてのパターンを把握している？
人が手て使うことを想定された曖昧さの残るコマンドと、高級言語の機械が使うことが前提の曖昧さの少ない機能だと全然違うものだと思うが
そんな事無いよね。Linuxサーバの保守とかでパッチノートとか読んだこと無い？
インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
論理的じゃないよね
別に高級なスクリプト言語でも標準ライブラリやインタプリタのバグは踏むときは踏むし
マイクロタスクな標準コマンドは高級言語のインタプリタほど頻繁なセキュリティアップデートは必要ないので使うバージョンはだいたい決まってるし
「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンドと高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし
バッチ処理は大抵2,3の条件分岐と数行のコマンドでできているので検証も難しくはありません
ワイもや。工学系学部に情報系が組み込まれている系の環境だったやで……。
でも、実績も金も、学生も金を持ってる大学が次々とWIndowsが動くUnixとしてMacを推奨しててて、きらきらやなあ、と指をくわえて見取ったんや……。
その後、ドロドロインフラ系ITの仕事に入って、学生時代Linuxで通した事を感謝してるんや。
自分語りすまんの。
今でこそWindowsでも全く問題なく開発できるけど、ちょっと前は「Macのが開発体験が良い」と言われていた。
具体的には2011~2015年あたり。
2013年のころ、俺はWindowsで開発していた。WSL2なんてものは当たり前に存在しない時代だ。
たとえばC言語を使いたい場合、MinGWとMSYSを使ってこんなかんじで必要なものにチェックマークをしてインストールしていた。
まちがえた。俺が使っていたのはCygwinだ。こんなかんじでインストールする。
「パスを通す」とか言われていた時代だ。今ではインストーラがほとんどやってくれる。
Windowsのコマンドプロンプトがアホほど役に立たないので、msysCygwinのコンソールを使うのだ。
Pythonのインストールにもパスを通していた時代だった。当時はまだ2系が主流で、卒論を書く際、大学の教授から「3系は使ってもいいけど、俺は知らないからサポートできない」と言われた。
Scipyはインストールしなければ使えなかったので、「python scipy インストール」で検索して出てきた記事を参考にしてインストールしていた。これがまたエラーの連続だった。
プログラムを開発するエディタも、vim、emacsがまず候補に上がった。どちらも癖のあるエディタなので、そういうのが嫌な人はサクラエディタが推奨されていた。そして少しして登場するAtomに感動したのだ。今ではあたりまえのようにVSCodeがある。
ちなみに俺はPythonの開発ではIDLEというのを使っていた。知ってる？こんなの。
そんなWindowsユーザーを少し煽るような（Winユーザが自虐するような）、「プログラミングするならMac」という風潮があったと記憶している。そこから「どうやらMacはUnix系で、コンソール操作が簡単らしい」「文字がきれい」「Windowsでは定期実行するためのcronすらないが、Macにはある」「xcodeというのがあるからめちゃくちゃプログラミングがラクらしい」みたいなイメージがあった。
今ではWindowsも随分便利になったし、IDEやインストーラがなんでもしてくれるようになった。今では結論、「どっちでも好きなほうを使えばいい」という良い環境になった。
