POSIX原理主義「ほれみろまた新しいﾊﾞｰｼﾞｮﾝ管理だ」

**デフォルトの名無しさん** · 2022/11/16(水) 20:15:25.62

予想通り新しいバージョン管理ツールが登場するようだな
gitなんか使っていた奴らはデータが取り出せなくなり
移行作業に苦しむことになるだろう
シェルスクリプトなら何十年後も同じものを使いつけられる
20年前の知識が20年後でも通用するわけだ
シェルスクリプトでバージョン管理せよ。
使う方を覚えるのではなく、自分の頭でシェルスクリプトで
どうやってバージョン管理するのかを考えろ

**デフォルトの名無しさん** · 2022/11/16(水) 20:20:34.81

そだねー

**デフォルトの名無しさん** · 2022/11/16(水) 20:24:25.73

>>1
自分の頭で考えたらお前の私怨につきあってるヒマはないと出ましたｗ

**デフォルトの名無しさん** · 2022/11/16(水) 20:37:28.25

新しいバージョン管理ツールが登場したらGitのデータが取り出せなくなるのはどういう論理展開なの？
よくわかんないな

**デフォルトの名無しさん** · 2022/11/16(水) 20:43:51.21

>>4
gitはデータを訳のわからんバイナリデータで格納してる
バイナリデータの移植性が低いのは誰でも知ってる
効率はバイナリの方がいいだろうが、効率よりも移植性だ
そのせいでお前らは何度もバージョン管理のやり方が変わって
新しい使い方を覚え直さなければならなくなる
今までの知識が全部無駄になる
そんなのはもうたくさんだ

**デフォルトの名無しさん** · 2022/11/16(水) 20:58:38.46

てかバージョン管理なんてGit以外にもあっただろ…
しかも今度はメタ程度のバージョン管理システムだろ？吹いて捨てるわ

**デフォルトの名無しさん** · 2022/11/16(水) 20:59:32.96

Gitが流行ったのはGitHubのおかげや
GitHubで手軽に公開できるから流行ったんや
You Tubeとかティックトックと一緒

**デフォルトの名無しさん** · 2022/11/16(水) 21:02:10.85

ほれ見ろまた新しいクソスレだ
クソスレ立てるやつもそのスレを必死に上げるやつも病院に入っておとなしくしとけよ

**デフォルトの名無しさん** · 2022/11/16(水) 21:12:24.29

>>5
ローカルに持って来てから新しい管理ソフト使えばいいだろ

終了ｗ

**デフォルトの名無しさん** · 2022/11/16(水) 22:16:13.89

ほれみろまたバージョン管理が死ぬ
移行作業が待ってるぞｗ

Metaの大規模ソースコード管理システム「Sapling」がオープンソース化
https://gigazine.net/news/20221116-meta-sapling/

**デフォルトの名無しさん** · 2022/11/16(水) 22:21:18.84

>>10
メタ程度のバージョン管理システムとかいらん

**デフォルトの名無しさん** · 2022/11/17(木) 12:35:18.79

>>5
ソースコード公開されてるよ
https://github.com/git/git

**デフォルトの名無しさん** · 2022/11/17(木) 12:50:30.56

>>5
zipで圧縮してるだけやろ

**デフォルトの名無しさん** · 2022/11/17(木) 18:45:04.01

把握してるだけのPOSIX原理主義者敗北集をまとめてみた

実データでプログラミングすれば単体テストは不要！
https://mevius.5ch.net/test/read.cgi/tech/1654051738/

最長不倒関数■C言語でmain関数に全コードを入れる
https://mevius.5ch.net/test/read.cgi/tech/1653574691/

OSの機能なのにシステムコール呼び出しが遅い理由
https://mevius.5ch.net/test/read.cgi/tech/1652880371/

wsl2ってあまり使う人いなくねwww
https://mevius.5ch.net/test/read.cgi/win/1635677537/

金沢大学「シェルスクリプト言語論」は偽開発技術
https://mevius.5ch.net/test/read.cgi/tech/1632511262/

gitを使わずにディレクトリコピーでバージョン管理
https://mevius.5ch.net/test/read.cgi/tech/1631002816/

構造化プログラミングはまだ必要ではないのか？
https://mevius.5ch.net/test/read.cgi/tech/1534260508/

BigQueryが非構造化データに対応。ユニケージ終焉へ
https://mevius.5ch.net/test/read.cgi/tech/1665630428/

ハッカーが夢中になるPOSIX原理主義（中心主義）
https://mevius.5ch.net/test/read.cgi/tech/1663999431/

すべての行にコードの意味をコメントで書くアホウ
https://mevius.5ch.net/test/read.cgi/tech/1659656921/

**デフォルトの名無しさん** · 2022/11/17(木) 18:45:53.47

しかもこのスレでは新しいバージョン管理ソフトが出ただけでPOSIX原理主義者はなんの貢献もしてないのになぜか手柄のように誇ってる

**デフォルトの名無しさん** · 2022/11/17(木) 19:03:46.18

MetaのSaplingはGitのリポジトリをcloneしてpush/pullできるから何も困らない
もちろんGithubにも接続できる

**デフォルトの名無しさん** · 2022/11/17(木) 19:23:20.79

>>16
そんでGitよりええのん？

**デフォルトの名無しさん** · 2022/11/17(木) 19:30:12.45

>>16
gitリポジトリも扱えるけどgitリポジトリのままクライアントだけslにしても高度な機能は使えないみたいよ

https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/
> 注: スケール機能の多くは、Sapling 固有のサーバーを使用する必要があるため、最初のクライアントリリースでは使用できません。ここでは、今後のプレビューとして説明します。Git リポジトリで Sapling を使用する場合、これらの最適化の一部は適用されません。

**デフォルトの名無しさん** · 2022/11/17(木) 20:40:13.88

>>18
slクライアントだけで使えないのはそのページの後半の Scaling Sapling で説明されてる機能だよね
前半の Sapling's user experience で説明されている機能はクライアントだけで使えて、gitのリポジトリでもいろいろ使いやすくなっているのがウリらしい
ステージが無いとかrebase -iでエディタ開いてコミット履歴編集が goto/prev/next/amend みたいなコマンドでできるとか
他にも https://sapling-scm.com/docs/introduction/git-cheat-sheet/ に git とのコマンドの対応表があるからいろいろ参考になる

**デフォルトの名無しさん** · 2022/11/17(木) 20:40:51.39

>>17
実際に使ってみないとわからないな
自動で動くrebaseの使い勝手とか気になる
あとで試してみる予定
ぱっと見、IDEとかVSCodeに統合して使うならSaplingの方が良さそうに見える

**デフォルトの名無しさん** · 2022/11/17(木) 21:26:30.18

>>15
POSIX原理主義は「交換可能性」という
今までに誰も考えつかなかった完璧な理論を打ち立てだろ

**デフォルトの名無しさん** · 2022/11/17(木) 21:43:45.45

>>1
>シェルスクリプトなら何十年後も同じものを使いつけられる
>20年前の知識が20年後でも通用するわけだ
gitを使い続ければ一緒じゃね?

**デフォルトの名無しさん** · 2022/11/17(木) 21:52:50.37

>>22
POSIXは30年前に規格化されてから何も変わっていない
gitは開発者の都合で勝手に変わるから
アップデートすると動かなくなる
つまり寿命が短いということだ

我らはこのような寿命の長いソフトウェアを、「ソフトウェアの保存食」と呼んでいる。我らの意見はこうだ。

・世にありふれている多くのソフトウェアは「生もの」
美味しいかもしれないが、日もちしない。

・保存食は、そこまで美味しくないが、日もちするという性質で優れるため必要なもの。
毎日の食事には生もの。キャンプや災害時には保存食。→適材適所でどちらも必要。

・しかし今、ソフトウェア界には保存食が不足している。
「今、高性能なこと」、「今、高機能なこと」を追求しているソフトウェアばかり。

POSIX の弱点を補完し、発展させたものがPOSIX 原理主義

**デフォルトの名無しさん** · 2022/11/17(木) 22:24:10.38

gitがアップデートで動かなくなった記憶がない

**デフォルトの名無しさん** · 2022/11/18(金) 01:59:41.54

>>21
互換性だなんてもっと前からある概念だわ
初めて作ったと思ってるならPOSIX原理主義者が無知だっただけ

**デフォルトの名無しさん** · 2022/11/18(金) 02:00:28.00

ユニケージは誰も保守できないからただの粗大ごみ

**デフォルトの名無しさん** · 2022/11/18(金) 07:11:10.01

>>25
ソフトウェアの寿命は短い。なぜかわかるか？
それはPOSIXという寿命が長い標準規格に準拠してないからだ
POSIXは30年の長い寿命を持っている
ならばPOSIXに従えはソフトウェアの寿命が長くなるのは明らかだ

POSIXで使える言語はCとシェルスクリプトだけだ
Cは効率がいいが移植性が低いとUNIX哲学で散々言われていることだ
したがってシェルスクリプトで書くしかない

しかしPOSIXは機能が少ないと騒ぐやからが多い
だから我らはシェルスクリプトで何でも出来ることを証明するために
多数のコマンドを作ってみせた。JSONだってXMLだってなんでも処理できる
POSIX原理主義は寿命が長いことが証明された

**デフォルトの名無しさん** · 2022/11/18(金) 09:04:17.02

どうでもいい奴が実在しない奴と本気で戦ってるｗ

**デフォルトの名無しさん** · 2022/11/18(金) 10:01:23.79

>>27
シェルスクリプトはWindowsで動かんのよ
Perlの方がいんじゃないですかね
Perlが誕生して35年ですお

**デフォルトの名無しさん** · 2022/11/18(金) 10:13:13.76

>>23
gitとPOSIX（というか>>1を読むとシェルスクリプト？）を何で比較してるの?
シェルスクリプトと比較すべきはgitを書いているC言語

**デフォルトの名無しさん** · 2022/11/18(金) 10:16:53.53

>>1
gitってPOSIX以外のシステムコールを呼んでたっけ?

**デフォルトの名無しさん** · 2022/11/18(金) 11:12:40.62

>>27
シェルスクリプトしかろくに使えないからシェルスクリプトを使うための理由探ししてる感じかな

可搬性も保守性もないくせによく言うよ

**デフォルトの名無しさん** · 2022/11/18(金) 11:22:03.27

>>31
git 2.34 で追加された core.fsmonitor の機能は Linux なら独自の inotify 関連のシステムコールを使ってるはず
こういう機能は昔のUNIXには無かったからPOSIXにも無いんじゃないかな

**デフォルトの名無しさん** · 2022/11/18(金) 12:04:44.11

>>33
「Linux なら」ってことなので必須じゃないのではないかな?

**デフォルトの名無しさん** · 2022/11/18(金) 14:05:46.08

>>34
inotifyに似た機能が無い場合は自力でファイルシステムを読んで回って変更を探すようなかなり非効率な実装になるので今どきのOSには必須の機能だと思うよ
例えばVSCodeなんかで他のプログラム使ってファイルを修正したのが直ちに反映されるのはこの機能使ってるはず
Windowsにも似たようなのがあるし、MacやBSDはどうかなあ

**デフォルトの名無しさん** · 2022/11/18(金) 15:23:49.85

>>23
君gitのスレで暴れている長文くんでしょ
さっさとゴミ箱アプリ作れよ

**デフォルトの名無しさん** · 2022/11/18(金) 17:39:36.63

Mercurial を使っている俺にスキはなかった。

**デフォルトの名無しさん** · 2022/11/18(金) 20:07:03.40

>>31
我らの聖典にはこう書かれておる

JavaScript ライブラリーは原則使わない
重要なことだが、jQuery やReact など……、JavaScript ライブラリーは原則使わない。
理由は、それらのライブラリーが一部のブラウザーでしかサポートしていない独自機能を
呼び出している恐れがあるからだ。自作のプログラムにそういうライブラリーの混入を許せば、
長寿命という特徴が損なう恐れがでてしまう。

ライブラリーを使わないということは、その部分を自力で1 から書くということだ。
とても大それたことに思えるかもしれないがそうとは限らない。例えば、次の例を見よ。

gitが一部のOSでしか動かない独自機能を呼び出している恐れある以上
そういったものを使ってはならぬというのがPOSIX原理主義だ

**デフォルトの名無しさん** · 2022/11/18(金) 20:33:30.60

>>38
へーgitはMacでビルドできないんだー

**デフォルトの名無しさん** · 2022/11/18(金) 21:44:56.74

>>39
もしMacがなくなったら他に代替先がなくなるということ
POSIXに準拠していればどこでも動く

**デフォルトの名無しさん** · 2022/11/18(金) 22:51:51.69

しかしユニケージはPOSIZに準拠してないという矛盾
ガチガチにベンダーロックインしてる上に、契約で、USPに不利なこと発信すると訴えるとか脅してんじゃねえの

**デフォルトの名無しさん** · 2022/11/18(金) 23:11:25.72

>>40
そこで autconf なんですよ
登場したのは30年以上前の話なんですがね

**デフォルトの名無しさん** · 2022/11/18(金) 23:12:05.18

>>42
autoconfはPOSIXで規定されてない
そんなのもの使うと寿命が短くなるというておろうが

**デフォルトの名無しさん** · 2022/11/18(金) 23:12:51.67

>>41
そこの人はシェルスクリプトでリアルタイム制御とかアホなスレたててたな

**デフォルトの名無しさん** · 2022/11/18(金) 23:14:16.61

>>43
30年以上も続いてるのに?w

**デフォルトの名無しさん** · 2022/11/18(金) 23:17:05.52

>>43
単一のOSからなる世界をお望みなのかな?w

POSIXにのみ留まってたら進化はしないよ
POSIXがバンバン改定されるならともかくね

**デフォルトの名無しさん** · 2022/11/18(金) 23:20:51.45

ちゃうねん。
POSIXの範囲で作っとけば。
地球人全員が使えんねん。

**デフォルトの名無しさん** · 2022/11/18(金) 23:21:10.37

な？
ええやろ？

**デフォルトの名無しさん** · 2022/11/18(金) 23:30:38.43

POSIXってのはOSの最大公約数
そんな狭いものに留まるのに賛成はしない
POSIXを逸脱した高機能な部分は
autoconf で管理すりゃ良いだけ
30年前に解決した話だよ

**デフォルトの名無しさん** · 2022/11/18(金) 23:31:44.02

シェルスクリプトでリアルタイム制御とか
頓珍漢なこと言ってる人達だからな

**デフォルトの名無しさん** · 2022/11/18(金) 23:37:01.81

>>45
POSIXは34年続いてるし
autoconfを作ってるのはあのGNUだ
独占してるGNUが勝手に仕様を変えると動かなくなる
POSIXは誰も独占してないから使用は勝手に変わらない
長寿命な標準規格だ

**デフォルトの名無しさん** · 2022/11/18(金) 23:38:02.02

>>46
逆だろ。POSIXに準拠したOSは無数にある
POSIXに準拠していれば無数のOSで動く
その証拠にWindowsでも動くようになっただろ

**デフォルトの名無しさん** · 2022/11/18(金) 23:40:08.63

>>46
POSIXがバンバン改定されたら互換性が保てなくなる
次から次へと新しいバージョン管理ソフトの使い方を覚え
次から次へと動かなくなるライブラリを使い続けるとか愚か者がやることだ

POSIXに準拠していれば、30年以上の前の知識のまま
どこでも動くソフトウェアが作れる
我々はそれを実践してみせた

**デフォルトの名無しさん** · 2022/11/18(金) 23:42:06.86

>>48
うわきっしょ
正面から反論できなくなるとエセ関西弁でおちゃらけて批判をそらす
死ねよ

**デフォルトの名無しさん** · 2022/11/18(金) 23:43:12.17

>>53
POSIX原理主義者はなんの貢献もしてないよ
まともなソフト作れるようになってから物言えよカス

**デフォルトの名無しさん** · 2022/11/18(金) 23:45:31.64

>>51
>autoconfを作ってるのはあのGNUだ
>独占してるGNUが勝手に仕様を変えると動かなくなる
GNUは独占していない
気に入らなればいつでもフォークする自由がある

**デフォルトの名無しさん** · 2022/11/18(金) 23:47:59.41

>>53
進化の否定以外の何物でもない
自分がついていけないものを否定するのではなく学んだ方が良いよ

まともな環境でプログラミングを学べていないのではないかな?
不幸なことです

**デフォルトの名無しさん** · 2022/11/19(土) 00:02:14.64

>>56
お前の独占の定義が間違ってるだけ。聖典を読め。

一個人や一企業の所有物が抱える問題

ではなぜ、一つの個人や企業の所有物か、それとも誰も独占しない公有物であるかに拘るのか。
それは所有物には次のような問題があるからだ。

その人の意向で、使い方のルールが変わってしまう恐れがある。
⇒ ルールが変われば話者（ユーザー）が翻弄される。
いざという時の代替品がない。
⇒ サポート終了や欠陥発覚で、話者（ユーザー）の逃げ道がなくなる。

6.1.3 ソフトウェアの方言・標準語の具体例

ソフトウェアにおける方言と標準語の違いに対する理解を深めるため、もう少し具体例を見てみるとしよう。
まず最初の表は、標準語ではない（つまり方言と見なされる）例である。

表6.1: ソフトウェアにおける「方言」の例

ソフトウェア名方言である理由
Linux｜「優しい終身の独裁者」（Linus 氏）がカーネルの仕様を最終決定しているから。
ほとんどのUNIX｜系OS それを作っている（実装している）のが一企業・一団体だけだから。
Perl, PHP, Ruby,Python, Java などの言語｜〃
ash, bash, dash, ksh, zsh などのUNIX シェル｜〃
GNU AWK, sed など (GNU 版コマンド群)｜それを作っている（実装している）のがFSF という組織だけだから。

**デフォルトの名無しさん** · 2022/11/19(土) 00:05:48.28

>>55
では、お前は何を貢献したというのか？

**デフォルトの名無しさん** · 2022/11/19(土) 01:08:37.70

>>58
>お前の独占の定義が間違ってるだけ。聖典を読め。
>
>一個人や一企業の所有物が抱える問題
>
>ではなぜ、一つの個人や企業の所有物か、それとも誰も独占しない公有物であるかに拘るのか。
>それは所有物には次のような問題があるからだ。
>
> その人の意向で、使い方のルールが変わってしまう恐れがある。
>⇒ ルールが変われば話者（ユーザー）が翻弄される。
> いざという時の代替品がない。
>⇒ サポート終了や欠陥発覚で、話者（ユーザー）の逃げ道がなくなる。
RMSが1989年に既に解決法を提示した
気に入らなければフォークする自由がある

**デフォルトの名無しさん** · 2022/11/19(土) 08:10:39.76

>>59
反論になってないね

**デフォルトの名無しさん** · 2022/11/19(土) 11:09:34.44

>>60
フォークするってことは動作が変わるってことだろ
代わりにならないから意味がない
POSIX原理主義はどれか一つの製品が廃盤になったとしても
代わりの製品があるから長寿命が実現できる

**デフォルトの名無しさん** · 2022/11/19(土) 11:19:02.67

Twitterがいま大変なことになっているが
POSIX原理主義で作っていれば
Twitterがなくなっても問題なかった

**デフォルトの名無しさん** · 2022/11/19(土) 11:25:33.60

でもユニケージってUSPがガチガチにベンダーロックインしてるからUSPが潰れたらそこまでだよね

まあユニケージより優れてかつ保守性のある製品なんて山ほどあるが

**デフォルトの名無しさん** · 2022/11/19(土) 11:28:06.21

>>62
>フォークするってことは動作が変わるってことだろ
オリジナルの動作が変わるのを嫌ってフォークするって話なのだから
自分でフォークしてオリジナルの動作を維持すれば?

**デフォルトの名無しさん** · 2022/11/19(土) 11:30:10.98

>>63
要するにソフトウェアに著作権を認めるなって主張なんだな
「ソフトウェアは全てパブリックドメインであるべき」と読める

**デフォルトの名無しさん** · 2022/11/19(土) 12:01:17.06

これからはPOSIXの時代。

**デフォルトの名無しさん** · 2022/11/19(土) 14:13:36.75

>>63
TwitterはPOSIX原理主義で作れるんかね
ユニケージみたいにファイルでDBを代替するとしても
同時アクセスでプロセスが大量に作られて破綻する気がするけどどうやるんだろ

**デフォルトの名無しさん** · 2022/11/19(土) 14:44:40.33

ユニケージのDBMS（笑）なんてトランザクション処理してないだろう
いちいちファイルに書き込むからオンメモリDBに比べてパフォーマンスで劣る

**デフォルトの名無しさん** · 2022/11/19(土) 18:15:05.51

>>65
C言語で作られているというのがセンスが悪い
C言語は効率がいいが移植性が低い。それらを維持するのは専門技術がいる。
だからといって他の言語はPOSIXで禁止されているから
シェルスクリプトを使うしかない

**デフォルトの名無しさん** · 2022/11/19(土) 18:16:52.18

>>68
Twitterなんぞただのウェブアプリにすぎない
POSIX原理主義でJSONのパースぐらいできる
base64だってシェルスクリプトで実装してみせた
ネットワークは困りどころだが交換可能性を満たせば
curlだってwgetだって使える

**デフォルトの名無しさん** · 2022/11/19(土) 18:18:00.47

>>69

トランザクションはulockを使うだけで実現できる

https://www.usp-lab.com/qa.html#exclusiveProcessing

ulock コマンドを使用します。ulock コマンドはロックファイルを排他的に作成します。また、そのロックファイルが存在する間は、待ち続けます。

例）ulock コマンドの実際の記述例
if ulock lockfile; then

###############################
# 排他的に行いたい処理を記述
###############################

# 最後にロックファイルを消去する
　rm lockfile
fi

**デフォルトの名無しさん** · 2022/11/19(土) 18:19:22.99

>>68
> 同時アクセスでプロセスが大量に作られて破綻する気がするけどどうやるんだろ
すでにFAQだな

https://www.usp-lab.com/qa.html#CGIAndProcess

Ⅲ-７. ウエブアプリケーションをCGIで記述するとプロセス過多にならないですか？

プロセス数が数千程度だと今の標準的なサーバーだと問題はありません。
万オーダーになってとるべき対策は、CGI 内部で次のような処理順番待ちを行う仕組みを入れます。

semwait --less_than 10 "semaphore.*"
touch semaphore.$$
##############
# 実際の処理
##############
rm semaphore.$$

これで解決しないようなオーダーのアクセスに対しては FastCGI 設定してウエブアプリケーション自体をサーバー化してプロセス数を増やさないようにします。

**デフォルトの名無しさん** · 2022/11/19(土) 19:22:45.72

>>73
> FastCGI 設定してウエブアプリケーション自体をサーバー化してプロセス数を増やさないようにします
よくわかんないけど、これはシェルスクリプトでできるの？

**デフォルトの名無しさん** · 2022/11/19(土) 19:25:35.74

>>72
ulockでできるのはロックだけのようだよ
コミット、ロールバックはまた別で作らないといけないよね

**デフォルトの名無しさん** · 2022/11/19(土) 19:28:54.32

> プロセス数が数千程度だと今の標準的なサーバーだと問題はありません。
それはそうだろうけど
ハンズラボのブログを見るとユニケージではプロセス数が数万～10万のオーダで作られて
システムがまともに動かない状態になったってあるよ

**デフォルトの名無しさん** · 2022/11/19(土) 19:45:20.11

5chがPOSIXで作れないわけない。

**デフォルトの名無しさん** · 2022/11/19(土) 19:46:35.99

>>70
レベル低っ

**デフォルトの名無しさん** · 2022/11/19(土) 20:08:06.41

結局POSIX原理主義者ってシェルが得意なんじゃなくてシェルしか使えないからこんなくだらないことやってるんだよな
そもそもユニケージは可搬性ないしPOSIXにそぐわない

**デフォルトの名無しさん** · 2022/11/19(土) 20:17:24.68

中古98の価格を見てもそんなこと言えるかな？

**デフォルトの名無しさん** · 2022/11/19(土) 20:18:38.88

POSIX原理主義は顧客の要求に応えたものであることを知るべき。

**デフォルトの名無しさん** · 2022/11/19(土) 21:06:54.52

POSIXとか顧客にダイレクトに影響のある規格じゃないし顧客が要求するものじゃないでしょ
POSIX原理主義者はそんなこともわからないのか

**デフォルトの名無しさん** · 2022/11/19(土) 21:19:52.08

>>82
顧客は新しいものを求めていない。
安定して使い続けられるものを求めてる。

**デフォルトの名無しさん** · 2022/11/19(土) 21:21:38.72

POSIXにこだわり抜くことで50年使えるシステムを目指してる。

**デフォルトの名無しさん** · 2022/11/19(土) 21:22:39.85

98上に組まれたシステムだってすでに30年動いているんだ。
顧客はそういうものを求めてるんだ。
特に日本の製品にはな。

**デフォルトの名無しさん** · 2022/11/19(土) 21:32:38.80

>>85
そういうものを求めてる場面もあるってだけ
俺はやだよ
30年前っていうと1992年
Windowsなら3.1を未だに使い続けることを求める顧客が居る！
って言われてもナンセンス

**デフォルトの名無しさん** · 2022/11/19(土) 21:34:01.01

>>86
DOSだろうが。
ほんと何も知らないんだな。

**デフォルトの名無しさん** · 2022/11/19(土) 21:36:48.79

>>87
俺は更に10年くらい古参だよ

**デフォルトの名無しさん** · 2022/11/19(土) 21:39:32.47

長く使ってるからコンピュータは進化するものだ
身を持って理解している

**デフォルトの名無しさん** · 2022/11/19(土) 21:46:17.16

>>83
そこでクラウドですよ
ハンズラボではユニケージを使ってたころサーバの性能が逼迫すると
手動でサーバを追加してたんだがAWSに変えてからはオートスケールするようになった
システムの動作も運用も安定した

**デフォルトの名無しさん** · 2022/11/19(土) 22:02:46.05

>>83
顧客の要求は顧客が決めるんだよ、間抜け

**デフォルトの名無しさん** · 2022/11/19(土) 22:03:14.18

>>90
検索したら、雲のジュウザと出てきたのだが？

**デフォルトの名無しさん** · 2022/11/19(土) 23:30:40.38

>>92
検索もまともにできねえのか
死ねよ

**デフォルトの名無しさん** · 2022/11/19(土) 23:40:56.73

>>93
笑

**デフォルトの名無しさん** · 2022/11/20(日) 01:23:36.19

反論なし、と

**デフォルトの名無しさん** · 2022/11/20(日) 10:06:13.11

>>90
クラウドに頼るやつはマシンの性能をフルに使い切れない愚か者

https://type.jp/et/feature/14070/

後藤「Web アプリ開発を例に挙げると、最近はクラウド上に立てたコンテナの中で
プログラムを書き、もし性能が足りなければコンテナ数を増やして対処することが一般的です。
ただこのやり方だとスケールアップする度に膨大な予算がいるし、
OSごと仮想化するのでどうしても動作が遅い。一言で言えば無駄が多いんです。

ユニケージ開発手法なら１台のマシンをフルに使い切れますし、
uspBOAが証明したようにマシンを並列につなげば安価で強力な実行環境を構築できます。
大量の電力を消費するデータセンターなどよりはるかに環境に優しいのは言うまでもありません。
今後ますますユニケージ開発手法のメリットが理解されやすい時代になってくるんじゃないかと思っています」

當仲「人間がちょっとだけ努力して歩み寄るだけで、コンピュータのリソースを100％使い切れるわけです。
その方が合理的で経済的だし、後藤さんの言うように環境に優しいのは間違いありません。
ただ漫然と楽な方へと流れていると、課題解決の道具に過ぎない開発環境に使われてしまうことになりかねない。
もしそれが嫌ならレイヤードされた階層の上部で開発する便利さに安住せず、
エンジニアはCPUやOS、アセンブラなど、低レイヤーに属する知識をもっと積極的に学ぶべき。それが私の持論です」