「UNIX」を含む日記 RSS

はてなキーワード: UNIXとは

2024-07-12

anond:20240712144103

じっくり考えた事はあまりないんだが、もしかしたら

UNIX的ではないOSを広めて金儲けに成功してしまたから」

なのかも知れない

WindowsPhoneが消えた時の心情を少し覚えてて

「やった、これでスマホUNIX的なOSのみになった」

と考えて安心した記憶がある

でもそれが真実理由かどうかは知らん

自分の心なんて自分ではなかなか分からんよね

2024-06-20

anond:20240620135402

> なんだ、単なる妄想か。


「その後、富士通SPARCを使ったUNIXサーバーを作り続けてはいたが、大きくアーキテクチャ改善する開発は行われないまま」

なんてこと書く人が、俺よりも詳しいとは思えないな。

結局発売されなかった次世代SPARC64が、A64FXと同一マイクロアーキテクチャであることは富士通公式発表にあるわけで

その程度の知識があれば「大きくアーキテクチャ改善する開発は行われないまま」なんてことは口が裂けても言えない。


妄想元増田の方でしょう。

2024-06-18

プロジェクトX、出演NGなのでは。あるいは富士通半導体の敗北の歴史

富士通忖度してるとか言ってるけど、あれ、普通に取材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の開発部隊分社化を決定。それが現在のソシオネクストであるPanasonicLSI部隊と合弁した会社で、分離した当時、富士通設立当初40%の株式を保持していたが、現在は完全に売却してしまった。

現在富士通半導体部門はFeRAMや光回路用の超特殊ものを除いて完全売却で撤退している。


なお、その後、ルネサステクノロジ(※富士通は合弁に参加していない)が組込向け半導体でほぼ世界首位と同率2位まで上り詰め、国内半導体必要性が新たに叫ばれTSMC国内半導体工場建設。Rapidusという日米政府が関わる半導体企業ができる流れになっている。もし将来、RapidusがプロジェクトXになるときには、大手電機産業からリストラされた技術者達の奮起という文脈が語られそうな気がする。閑話休題

2012年。京が世界一を取ってその後、富士通半導体の敗北が確定した年

件の方がご退任をされたと言う2012年は、半導体さらなる切り離し、売却などの決断と、次期スパコン(つまり富岳)がSPARCを捨ててARMになるという決断が行われた年であったと考えられる。(発表は後になる)

半導体を専門にされてずっとやってきた方には堪えられないもだったのではないかと拝察する。仮に、思い出したくもないし、宣伝にも使われたくないと判断されても仕方がないことでは無いかと思う。(もちろん 出演NGされたと言うのはワイの妄想なので注意)


その後、富士通SPARCを使ったUNIXサーバーを作り続けてはいたが、大きくアーキテクチャ改善する開発は行われないまま(保守設計は続けられていたが)メインフレームとともに撤退が発表された。これはやむを得ないことだろう。

また、ARM化された富岳は、確かに能面や利用面、汎用性では高い成果を出したが、富士通ビジネス的にはさっぱりだったと思われる。


アーキテクチャARMに切り替えた理由は、ビジネス面でもあった。高性能タイプARMを作ることによって、旺盛なクラウドDC需要などに対して食い込んでARMサーバを大きく拡販していくことだったと思われる。

が。富岳に乗せたARMプロセッサを利用した波及製品はみられなかった。

なぜか。それはAWSMS AzureGoogleなど膨大な需要を持つ企業は、需要が巨大すぎてARMが搭載されたコンピュータを買うのではなく、自社でARMIPを購入し独自開発することを選んだためである

彼ら相手には商売にならなかった。それ以外のクラウドベンダーは無きに等しい。ARMなどアーキテクチャが影響しないのはPaaS以上の象徴度を持つサービスだが、寡占状態にある大手以外まともに提供出来ていないため、市場が無いのだ。


ただし、この時富士通ARMの競業によってARMは成果をあげた。アウトオブオーダー実行など、ARMは高性能コンピュータ必要技術富士通から取り込んで現在に至る。

それ故、富士通商売は上手くいかなかったが、世の中的には良かったとは言えるのではあるのだ。そのIP大手クラウド各社は自社向け半導体を作って商売をしているのだから

エピローグ または今後について

今、富岳の次のHPC予算要求の山場を迎えている。

https://newswitch.jp/p/41595

から今のタイミングプロジェクトXに乗ったのだと思うが、綺麗事では語れない話がたくさんありすぎる。


受注はまず間違い無く富士通だと言われている。と言うのは、開発の一部は既に行われているから。

https://monoist.itmedia.co.jp/mn/articles/2310/12/news074.html

そして、国内にもう国産HPCを作ることの出来る会社NEC富士通ぐらいになってしまったためである

富士通は新しいHPCは1位を目指さないかもしれないという考えから計算効率の方に大きく振った開発を進めおり、国内トップHPC採用されたという実績を背景に売り出そうというつもりではあると思われる。富岳の夢再び、だ。

しかし、富士通は今年1月ハードウエア会社を分離した

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年ほど株価は伸び悩みが続いている。アクセンチュアの真似をしますと言ったときは撥ねたがが、その後は同業他社業界全体の株価上昇率に及ばない状況が続く。
それはそうだ。アクセンチュアの真似をしていてはアクセンチュアには勝てない。まして工場売却を通じ、元々の強みを捨て弱みまでアクセンチュアの真似をしているのだ。富士通この先生きのこるにはどうすればいいのか?


これがプロジェクトXの真のエピローグではないかとワイは思いました。

2024-03-29

anond:20240329225642

Linuxを扱えないやつのほうが断然「旧い」だろ

WindowsMacチンパンジーが扱える形態で作られているからな

FreeBSDなどのUnixなら尚更チンパンジー向けではない

2024-03-10

anond:20240310133758

UNIXというのは、「わかってないバカは使うな」の精神があり、それがLinuxにも残ってるよ

からサーバサイドではLinuxが広く普及してるし、Windowsサーバーなんて情弱しか使わない

2024-03-01

月末日の取得方法

ライブラリにある標準的実装使用する

言語によっては標準的に月末日を取得できる関数が用意されている

それを使うのが一番簡単バグが出ないが

用意されてない場合もそこそこあるし

サードパーティー的なライブラリだとライセンスなどメンテナンス含めて面倒になるので避けることも多い

月末日にせずに28日にする

そもそも仕様を「月末日」などという不確定なものにせずに28日にしてもらう

どの月にも28日はあるので問題無い

ちゃん仕様を決める部門連携が取れていれば多くの場合28日にしてくれるし

28日支払い」が多いのもこのためだと思ってる

翌月マイナス1日で計算する

割とよくある実装がこの「次の月初めから1日(1秒)引く」という実装

2024年2月の月末日を取得する場合2024年3月1日UNIX時間から24*60*60秒を引いて計算する

ただし、実装を間違えると12月31日ときに失敗するので注意が必要

自分実装する

各月の月末日をマップとして保持しておいて取得させる

関数実装するなら if(month==1) return 31 とかを12行書けば実装できる

この場合閏年考慮していないと4年に一度バグが発生する

閏年の判定はライブラリ標準的実装されていることが多いが

自分実装する場合プログラミング教科書にあるぐらい有名なのでコピペでもChatGPTでも使えば良い

ただ仕様をそのまま実装せずに「4で割り切れたら閏年」でも問題無い(やったことはないが)

「それだと2100年でバグる!」

などと騒ぐやつがUNIX時間を使ってるのはなかなか興味深い

ちなみに過去の日付であっても2000年バグらない(そのための400年処理だし)ため

1900年を入れない限りは問題無い

最高齢の人でも1900年からなので基本的には問題無いだろう

たまにプルダウンで1901年からしか入れられないシステムを見るが、「もしかして閏年のせい?」と思ってる

2024-01-31

anond:20240131174453

地方からの声です。

ひとえに、IT云々に関わらず、リモートかどうかに関わらず、発注者と受注者の信頼関係だと思います

 

私は二十数年前まで、メインフレームCOBOLやJCL、UNIX上のCなどを扱うインフラシステムを切り盛りするエンジニアでしたが、脱サラに失敗して非正規を今まで続けて参りました。

結局は現役から離れた期間が長くなり、50も過ぎますと、さすがに現場技術者は務まりません。

 

まぁ・・・簡単なCですとか、EXCEL関数を駆使したシートくらいは作れますが、そんなレベルでは通用しませんよね。

受注者は自分能力をどう宣伝できるのか?発注者はどう能力を測るのか?それが難しい。

実際、私も地方の中枢都市在住ですが、なかなか、中央レベル仕事できますよ!って主張するのは不安があります

番手っ取り早いのは、とりあえず出勤してもらって、ある程度レクチャーして、その結果どれだけのレスポンスがあればリモートにしても良いかなぁ・・・って感じなんだろうなぁと思います

2024-01-07

anond:20240107205412

個人的には初心者プログラマUNIX哲学周りの本読んでハマるか、キャリアアップできなかったエンジニアが使うのがシェルスクリプトだと思っているが。

クラウドとかでシェルを大規模に使用したシステムを推奨している公式プラクティスないっしょ

anond:20240107202028

話を取り違えている所が

たこと無いにもかかわらず

論点先取の詭弁というやつですね

 

あなたこそ使っているコマンドコミット履歴を見たことありますか?

UNIXコマンドなんて5年ぐらいcopyright年号しかコミットされていないなんてザラにありますけど

anond:20240107191403

シェルスクリプト使用したコマンドのすべての挙動を把握している?

使用予定のオプションだけでも出力結果のすべてのパターンを把握している?

標準ライブラリのすべての関数のありとあらゆる引数に対する挙動を把握している?

 

人が手て使うことを想定された曖昧さの残るコマンドと、

標準コマンドは標準入出力を通してプログラム同士で連携することを想定して作成されており、

入出力の破壊的変更を気軽にコミットしようとしたら秒でハネられます

 

高級言語インタプリタほど頻繁なセキュリティアップデート必要ない

頻繁なセキュリティアップデート必要ない

「ゾウリムシよりも蟻は大きい」を「蟻は大きい」で切って引用するのはやめましょう

 

そもそもシェルスクリプトが規模が大きくなると信頼できないその場しのぎ的な技術であることを認めているよね

規模が大きくなると信頼できない、その場しのぎ的な技術であるのはpythonなどのスクリプトの実行環境も同様です

すべての処理、すべてのプログラムをRustで書くような行為はきわめて非生産的ですし、シェルスクリプト以上に危険です

 

「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンド高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし

論理的じゃないよね

メンテナの数、レビューする人数、実際に動作している環境etc

 

anond:20240107184931

高級なスクリプト言語でも標準ライブラリインタプリタバグは踏むときは踏むし

バグとかじゃなくて、開発者が把握してない動作の話なんだが、

シェルスクリプト使用したコマンドのすべての挙動を把握している?

使用予定のオプションだけでも出力結果のすべてのパターンを把握している?

人が手て使うことを想定された曖昧さの残るコマンドと、高級言語機械が使うことが前提の曖昧さの少ない機能だと全然違うものだと思うが

頻繁なセキュリティアップデート必要ない

そんな事無いよね。Linuxサーバ保守とかでパッチノートとか読んだこと無い?

インストールし終わったらほとんどアップデートしてない凄まじい運用してるんならあれだけど

「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンド高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし

論理的じゃないよね

肥大化しそうならその時に改めて高級な言語システムを作ったらよろしい

そもそもシェルスクリプトが規模が大きくなると信頼できないその場しのぎ的な技術であることを認めているよね

anond:20240107183726

別に高級なスクリプト言語でも標準ライブラリインタプリタバグは踏むときは踏むし

マイクロタスクな標準コマンド高級言語インタプリタほど頻繁なセキュリティアップデート必要ないので使うバージョンはだいたい決まってるし

「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンド高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし

バッチ処理は大抵2,3の条件分岐と数行のコマンドでできているので検証も難しくはありません

肥大化しそうならその時に改めて高級な言語システムを作ったらよろしい

anond:20240107173919

ワイもや。工学学部情報系が組み込まれている系の環境だったやで……。

でも、実績も金も学生も金を持ってる大学が次々とWIndowsが動くUnixとしてMacを推奨しててて、きらきらやなあ、と指をくわえて見取ったんや……。

その後、ドロドロインフラ系IT仕事に入って、学生時代Linuxで通した事を感謝してるんや。

自分語りすまんの。

ちょっと前は「プログラミングするならMac」という風潮が確かにあった

今でこそWindowsでも全く問題なく開発できるけど、ちょっと前は「Macのが開発体験が良い」と言われていた。

具体的には2011~2015年あたり。

2013年のころ、俺はWindowsで開発していた。WSL2なんてものは当たり前に存在しない時代だ。

たとえばC言語を使いたい場合MinGWとMSYSを使ってこんなかんじ必要ものチェックマークをしてインストールしていた。

まちがえた。俺が使っていたのはCygwinだ。こんなかんじインストールする。

パスを通す」とか言われていた時代だ。今ではインストーラほとんどやってくれる。

Windowsコマンドプロンプトがアホほど役に立たないので、msysCygwinコンソールを使うのだ。

Pythonインストールにもパスを通していた時代だった。当時はまだ2系が主流で、卒論を書く際、大学教授から「3系は使ってもいいけど、俺は知らないかサポートできない」と言われた。

Scipyはインストールしなければ使えなかったので、「python scipy インストール」検索して出てきた記事を参考にしてインストールしていた。これがまたエラー連続だった。

プログラムを開発するエディタも、vimemacsがまず候補に上がった。どちらも癖のあるエディタなので、そういうのが嫌な人はサクラエディタが推奨されていた。そして少しして登場するAtomに感動したのだ。今ではあたりまえのようにVSCodeがある。

ちなみに俺はPythonの開発ではIDLEというのを使っていた。知ってる?こんなの

そんなWindowsユーザーを少し煽るような(Winユーザ自虐するような)、「プログラミングするならMac」という風潮があったと記憶している。そこから「どうやらMacUnix系で、コンソール操作簡単らしい」「文字がきれい」「Windowsでは定期実行するためのcronすらないが、Macにはある」「xcodeというのがあるからめちゃくちゃプログラミングラクらしい」みたいなイメージがあった。

今ではWindowsも随分便利になったし、IDEインストーラがなんでもしてくれるようになった。今では結論、「どっちでも好きなほうを使えばいい」という良い環境になった。

2023-12-14

プログラマーのワイが読んだ中で良かった本ベスト10

1. UNIXという考え方 Mike

2. プログラミング作法 Brian and Rob

3. テスト駆動開発 Kent

4. 達人プログラマー Andy

5. リファクタリング Martin

6. プログラマーが知るべき97のこと

7. ソフトウェアアーキテクトが知るべき97のこと

8. レガシーコードからの脱却

9. Design It!

10. 少年メイドクーロ君

2023-11-30

anond:20231130215916

CLIやりません

分かる

Linuxには興味はありません

Unixが分かればいい

C言語は学ぶつもり無いです

今はRustがあるから重要度下がってきてる

2023-11-22

anond:20231122161014

2chVIPみたいなただ騒いでるだけの板はともかく、UNIX板とか当時そこでしか手に入らなかった情報もあってふつうに便利だったよ。

まあ、多少ノイズは入るけどいろいろ勉強になった。

2023-11-02

anond:20231102111751

困らないというかサーバー側はWindowsはできるだけ使いたくなくてUNIXが標準だから

ネイティブなら対象の機種依存だよ

anond:20231102110645

MacはOS7からWinは3.1からUNIXは数千万商業を全種類に加えてIBMオフコンまで弄ってるけどガチでやる?

2023-10-29

anond:20231029155904

普通にGAFAでもしとるで

GUIがいいUNIXとか便利にきまっとるやろ

CS新卒でも書けるシェルとか出来なそう

anond:20231029155124

感想個人的なもんだけど

昔はともかく今のMacBookOS含めて開発者的には相当コスパ良いと思う

Windowsの3.1とかから始まっていろんなバージョン、数千万円のUNIXいろいろとか使ってきた上での感想

ログイン ユーザー登録
ようこそ ゲスト さん