Visual Studio Code / VSCode Part8

1 名前：デフォルトの名無しさん mailto:sage [2020/06/11(木) 12:01:27.72 ID:zrBfgML9.net] Microsoft発のエディタVisual Studio Codeのスレ 公式 https://code.visualstudio.com/ https://github.com/Microsoft/vscode/ 開発状況 https://github.com/Microsoft/vscode/wiki/Iteration-Plans 更新内容(日本語訳) https://vscode-doc-jp.github.io/updates/ 前スレ Visual Studio Code / VSCode Part7 https://mevius.5ch.net/test/read.cgi/tech/1576059976/ 411 名前：デフォルトの名無しさん mailto:sage [2020/07/16(木) 02:14:03.73 ID:6G5cK3Pi.net] >>402 それは、個人的な嗜好であり、ただ潔癖なだけ。 # 気持ちはわかるが。 配列オブジェクトも、プロパティにメチャクチャ感があるけど、つまり、そういうポリシー。 「取って付けた感」では全然ない。 たとえば今から新しくつくる言語だとしても、表現や実装の都合で、特殊なプロパティをほかに混ぜてしまう選択は、ふつうにあり得る。 で、Schemeの話はどこにいったんだよ？ 412 名前：デフォルトの名無しさん mailto:sage [2020/07/16(木) 08:17:23.65 ID:4le5mWZs.net] プロトタイプチェーンというものがその配列と同じようなレイヤーで実現されていることを 指して言ったわけなんだが。 それが「根本」に見えちゃうのは主観なんでそれ以上は言わんけど。 413 名前：デフォルトの名無しさん mailto:sage [2020/07/16(木) 09:07:29.56 ID:yJ975u67.net] スレチ 414 名前：デフォルトの名無しさん mailto:sage [2020/07/16(木) 09:29:46.00 ID:6G5cK3Pi.net] >>407 日本語能力と言語センスがないことはわかった。 >>408 まあまあ。。。 415 名前：デフォルトの名無しさん mailto:sage [2020/07/17(金) 21:16:25 ID:O51Ni2cF.net] 最初からオブジェクト指向言語として設計していたならあのthisはないよなぁ。 416 名前：デフォルトの名無しさん mailto:sage [2020/07/17(金) 23:39:54.29 ID:S1GMEh9P.net] なんで？最初からプロトタイプベースオブジェクト指向言語として設計されてたよ？ おかしくなったのはそのプロトタイプベースオブジェクト指向言語として設計されてたものに後付けでnewやらthisやらのC++/Java系のクラス 417 名前：ベースオブジェクト指向用語を無理やり導入してJavaっぽいクラスベースオブジェクト指向言語に見えるよう無理やりガワを被せようとしたため。 [] [ここ壊れてます] 418 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 05:17:12.44 ID:gM32+Vtw.net] TypeScriptでラップすると快適やわ 419 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 11:34:26 ID:zDePOjuW.net] >>411 その珍説はどこから？ プロトタイプベースだろうがオブジェクト自身へのアクセスにthisは必要だし、 newによるコンストラクタ呼び出しがなければ別の方法でプロトタイプチェーンを構築 していたことになるが、そいつらがプロトタイプ自身より後付けとは考えにくいんだが。 もちろんどっちもクラスベース固有の概念じゃあない。 420 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 12:25:08.69 ID:cNrPu/ON.net] es2015以降のclass構文はともかく（あれもシンタックスシュガーなのに文法上new使用を強制してるだけだが）、 JSのnewはJavaに見た目を寄せるためのシンタックスシュガー以上の意味はない。 見た目こそ同じnewだが、C++やJavaのnewとは全く異なる。 JavaScript: The Good Parts 133ページ > new演算子の持つ問題に対するもっとも良い方法は、newをまっまく使わないことである。 使わなくて全く問題ない。 JSのnewはJavaに見た目を寄せるためのシンタックスシュガー以上の意味はない。 見た目に騙されてC++やJavaの知識を転用しようとすると理解を誤る。 421 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 13:48:24.95 ID:fwbEJCvA.net] > 見た目に騙されてC++やJavaの知識を転用しようとすると理解を誤る。 C++やJavaの知識ってなんのこと？ 422 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 14:00:57.09 ID:N4WthBbf.net] newとはこういうもの！これ以外のはずがない！という思い込み・囚われている常識、のことかな 423 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 15:08:39.55 ID:7WBm5sdR.net] プロトタイプ系とクラス系の違いも。 つうか、プロトタイプ系はわかりにくいんだよ！ 実装は簡単というか、手っ取り早いと聞くので、当時ブラウザに埋め込むにはちょうどよかったんやろけども。 424 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 16:25:25.54 ID:DrPRguB/.net] もともとネスケのためだけのマクロに過ぎなかったしねえ 20数年後にこれを使ってアプリを書く人たちが現れるとは想定してなかったんじゃなかろうか 425 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 16:33:34.40 ID:zDePOjuW.net] >>4124 ああ、プロトタイププロトタイプ言いながら自分でプロトタイプベースで書いたことはないのね。 newをまったく使わないというのは自分で__proto__を操作するかあるいはプロトタイプ継承を 使わないってことになるんだが。 当然、前者を推奨しているわけがない。 426 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 17:07:44.12 ID:fwbEJCvA.net] >>417 プロトタイプが分かりづらいんじゃなくて 昔のJavaScriptが面倒だっただけ プロトタイプベースでの継承の仕方っていうのは Object.createを使ってB.prototype = Object.create(A.prototype) ってするだけの簡単なものなんだが、昔のJavaScriptは肝心のObject.createがなかった。 JavaScriptは最初（1995年ぐらい）からプロトタイプベースのオブジェクト指向だったが Object.createができたのはECMAScript 5からChromeだと2010年の5から IEだと2011年のIE9から、つまり15年もの間、JavaScriptは重要な機能が欠けた 不便なプロトタイプベースオブジェクト指向だった 427 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 17:36:07.70 ID:7WBm5sdR.net] >>420 そういう話じゃない。 そもそも継承なんかしないユーザーレベルでも、なんかわかりにくいんだから。 JavaScriptが不出来だからとかドキュメント不足とか、理由はいろいろあったと思うけど、それだけでもない。 428 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 17:53:27.03 ID:vfrpqE6H.net] それはライブラリが不足していただけ どんな言語でもライブラリがなければ使いづらい JavaScriptはjQueryが登場してから世界が変わっただろ 429 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 18:19:52.24 ID:pq9oSxH0.net] スレチ 430 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 21:26:08.79 ID:7WBm5sdR.net] >>422 だから、そういう話じゃない。 JavaScriptの使いやすさのことではない。 言語としてのわかりやすさについて言っている。 むしろ、prototype.jsとかjQueryとか出てきてから、JavaScript自体はわかりにくくなった気さえする。 こなれたコードを見る機会が増えて、慣れてもいいはずなのに。なんかわかりにくくて、あやしいからか？ >>423 まあ、VSCodeの話題も出てこないことだし。。。 431 名前：デフォルトの名無しさん mailto:sage [2020/07/18(土) 21:47:03.20 ID:Iib9EfYg.net] とりあえずお前らのおすすめの拡張 説明付きで教えろください 432 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 00:25:37.44 ID:KyV15c0l.net] 最近使うようになったやつ Draw.io Integration - 作図に便利 Code Spell Checker - typo が減った 433 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 05:09:46.41 ID:W3hSYpRn.net] >>424 JavaScriptのどこがわかりにくいのか全くわからん 日本人が日本語は簡単だが英語はわかりにくいって 言ってるようなもんだろ 言語としてのわかりやすさじゃなくて お前の知識の問題 でないと俺みたいにJavaScriptが分かる人がいることが説明できない 434 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 07:36:22.70 ID:m5eV0pvm.net] >>425 ■SynthWave '84 ネオン調に光るテーマ。 （説明にもある通り、別途Custom CSS and JS拡張を入れてCSSの設定が必要） https://i.imgur.com/hmvfda3.jpg https://marketplace.visualstudio.com/items?itemName=RobbOwen.synthwave-vscode ■GlassIt-VSC VSCodeを透過できる。 https://i.imgur.com/yvH2LSA.jpg https://marketplace.visualstudio.com/items?itemName=s-nlf-fh.glassit ■Remote Containers 革命。Dockerコンテナ内でVSCodeを開いて開発ができる。 これのせいでもうVSCode以外で開発する気起きない。 https://microsoft.github.io/vscode-remote-release/images/remote-containers-readme.gif https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers 435 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 11:32:11 ID:xggXZiaY.net] >>428 一番下便利そうだな。 どうせDockerで開発するならこれありゃWSL2なんかいらんかったなｗ 436 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 11:38:21.65 ID:m5eV0pvm.net] >>429 ホストとコンテナのボリュームをマウントするときに、ホストがWindowsだといろいろめんどいのでWSL2も使うのがオススメ Windowsで使う場合、WSL2で立てたlinuxマシンにRemote WSLで繋いで、そこからRemote Containersを使うのが良い 437 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 11:59:48.19 ID:W3hSYpRn.net] >>429 そのDockerはWSL2上で動いてるんだぞ？ 438 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 12:00:08.13 ID:xggXZiaY.net] ややこしいな… 439 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 12:06:59.74 ID:jXwWFSFG.net] WSL2のDockerはメモリ消費しすぎで使い物にならない 440 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 12:11:35.65 ID:Jl4hgH9c.net] WSL2とかじゃなくて時代はDockerなんですよ！ 441 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 12:17:50.75 ID:4P1FEtjj.net] >>431 違う。別物。 442 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 12:22:25.01 ID:kmbJyWa5.net] コンテナにせよエミュレーションにせよ仮想化テクノロジが最重要であることは言うまでもない ということは開発機は仮想化に強いMacかLinuxということになる Linuxはデバイスサポート保障があるマシンのラインナップが魅力的とは言い難い なので開発者はMacを買うべきという正解が導かれる 443 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 12:23:49.61 ID:rDt79pjx.net] >>133 またObsidian.mdやRoamResearchに触発されたのが出てきた https://github.com/svsool/vscode-memo 444 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 12:31:10.24 ID:ZFRvNo6R.net] デファクトスタンダードが決まったらまた連絡してくれ 445 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 12:44:55.36 ID:n0f5aqSv.net] >>433 具体的には？ 446 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 12:59:28.71 ID:W3hSYpRn.net] >>436 > ということは開発機は仮想化に強いMacかLinuxということになる Macが仮想化に強いって何のこと？ MacはLinuxじゃないからDockerはそのまま動かないのに 447 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:02:09.25 ID:W3hSYpRn.net] >>435 別物じゃないよ 448 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:02:29.46 ID:8D9pzTQx.net] >>440 結論ありきで途中の過程がやる気無さすぎなんだろう 449 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:06:54.86 ID:W3hSYpRn.net] Dockerの重要な点として手元で作ったDockerイメージを そのまま本番環境でつかえるというのがある しかしMacのCPUがARMになるからこれが難しくなった 本場環境の多くはIntelなのでCPUが違う そうなると実機はIntel版LinuxのDockerイメージを使って 手元ではARM版LinuxのDockerイメージを使うか パフォーマンスの低下を諦めて手元でIntel版LinuxのDockerイメージを エミュレータを使って動かすしかなくなる Macは開発に向かなくなってきている 450 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:09:27.60 ID:4tyOlEBs.net] >>440 Macが強いというよりWindowsが弱いので相対的に良いってだけ 451 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:10:01.14 ID:W3hSYpRn.net] Macの仮想化機能は限定的で、 Hypervisorフレームワークは用意しているが それを使うためのインターフェースも持っていない つまりサードパーティのソフトに頼らざるを得ないわけだ HyperVとそれを扱うHyperVマネージャーを OS標準で用意しているWindowsとは対照的 452 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:11:14.96 ID:7Q5fXF4C.net] >>443 現時点で軽量VM使ってるから大きな変化はないのでは？ 453 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:12:31.66 ID:W3hSYpRn.net] >>444 Windowsの仮想化機能はMacを超えてるぞ 仮想マシン機能は当然備えているし Macにはない仮想マシン管理アプリも付属 さらにWindows独自のコンテナ機能もある Windows ServerコンテナというLinuxコンテナに近い機能と Hyper-Vコンテナの二種類が用意されてる。 そしてDockerもWindowsコンテナに対応している 454 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:13:17.94 ID:Vqf8sefQ.net] >>445 そのHyperVの完成度がお粗末 455 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:14:06.16 ID:W3hSYpRn.net] >>446 軽量VMが何の関係があるのか知らんが、 MacのCPUがARMに変わったら Linuxと同じDockerイメージが使えなくなるか CPUエミュレーションで遅くなるという話をしてる 同じCPU上での仮想マシンとは違って CPUが異なると大きなパフォーマンス低下が発生する。 456 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:14:28.08 ID:W3hSYpRn.net] >>448 > HyperVの完成度がお粗末 どこがおそまつなの？ それを言えないんじゃ説得力ゼロなんですよ。 457 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:15:13.17 ID:W3hSYpRn.net] HyperVの完成度の高さはDockerが実用的に動いていることからも明らか WSL2だけではなくWSL1もHyperVを使っている 458 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:21:12.09 ID:Vqf8sefQ.net] >>447 標準の管理ｱﾌﾟﾘは別に要らないと思う 実用性を考えるとDockerやVagrantのようなｻーﾄﾞﾊﾟーﾃｨﾂーﾙと合わせて使うから Windowsｺﾝﾃﾅは使ったことないからわからないけどLinuxｺﾝﾃﾅと比べると需要少なそう ﾊﾞｯｸｴﾝﾄﾞがなにか気にせずｺﾝﾃﾅを管理できるから便利なのであって ﾊﾞｯｸｴﾝﾄﾞの種類が豊富でもあまり嬉しくないような？ 2種類あるとなにが便利なの？ あなたが列挙した機能はもっともらしいﾒﾘｯﾄには思えないな それよりもVirtualBoxとの共存で不具合が出やすいなどのﾃﾞﾒﾘｯﾄのほうがより目立つ 459 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:22:18.06 ID:W3hSYpRn.net] > 標準の管理ｱﾌﾟﾘは別に要らないと思う いるだろ。Macはユーザーインターフェースが不便なOSだって言いたいのか？ 460 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:22:42.26 ID:W3hSYpRn.net] VirtualBoxはいらんよ なんで複数の仮想マシンが必要なんだｗ 461 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:23:12.78 ID:W3hSYpRn.net] > ﾊﾞｯｸｴﾝﾄﾞの種類が豊富でもあまり嬉しくないような？ > 2種類あるとなにが便利なの？ だからVirtualBoxはいらんよねｗ 462 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:24:33.64 ID:W3hSYpRn.net] >>452 俺が話をしているのはWindowsの方が仮想化機能が充実しているという話 MacはHypervisorフレームワークしかない 463 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:24:38.44 ID:m5eV0pvm.net] スレタイ関係なくなっちゃったじゃん 464 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:25:44.28 ID:W3hSYpRn.net] macOSはOS標準のコンテナ機能も搭載してないからな 465 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:25:56.58 ID:KyV15c0l.net] ID真っ赤な人はちょっと落ち着いて 466 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:26:13.67 ID:Vqf8sefQ.net] >>449 動かなくなることはないと思う ただﾊﾟﾌｫーﾏﾝｽのﾍﾟﾅﾙﾃｨはあるかもしれない でもｲﾝﾃﾙがｱｯﾌﾟﾙを追従せざるを得なくなるという話もあるしどちらが良いかは時間をかけて評価しないとならないだろうね >>450 VirtualBoxとの共存で不具合が出やすい ﾈｯﾄﾜーｸ関連のﾊﾞｸﾞが出やすい VagrantでHyperVﾌﾟﾛﾊﾞｲﾀﾞを使うと顕著 467 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:27:50.96 ID:W3hSYpRn.net] >>460 > VirtualBoxとの共存で不具合が出やすい Windows標準の仮想マシン機能を使えばいいじゃんｗ 468 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:28:24.28 ID:Vqf8sefQ.net] >>451 Dockerが動くだけで完成度が高いと言えるならどんな仮想化ﾌﾟﾗｯﾄﾌｫーﾑでも高品質になってしまう WSL2でDockerを使うとすぐにわかるけどvmmemがﾒﾓﾘを食いつぶして使い物にならない これがﾊﾞｸﾞ扱いじゃなくﾃﾞﾌｫﾙﾄの挙動というのがすごい 469 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:29:21.18 ID:n0f5aqSv.net] >>462 どんな糞スペ使ってるんだ？ 470 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:32:18.35 ID:W3hSYpRn.net] >>462 一方macOSは仮想マシンに常に一定量のメモリを取られるんだが？ 最大値を指定しなければ、Linuxの挙動との兼ね合いでそうなると言うだけの話 それはもう修正パッチができていたはず そして最大値を指定した場合は、macOSの挙動と同じ 重要なことを忘れてないか？ Windowsの場合、使用しなくなったメモリを開放するようになった。 つまりmacOSのように常に一定量のメモリを取られるんじゃなくて 使用しなくなったメモリが開放されるようになった。 Build 19013」の「WSL 2」ではメモリーの使用効率が改善され、「WSL 2」の使い勝手が向上しています。 https://kledgeb.blogspot.com/2019/11/wsl-191.html 471 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:33:54.95 ID:Vqf8sefQ.net] >>453 いや必須ではないでしょう ｻーﾄﾞﾊﾟーﾃｨの仮想化ﾌﾟﾗｯﾄﾌｫーﾑを入れればUIはついてくるから標準に頼らなくてもいい >>454 Virtualboxをﾒｲﾝに使うなら複数は必要ないけどDockerがHyperVを選ぶという愚行を犯してしまったから仕方なく複数つかうしかない状況 HyperVだけではVagrantのようなｴｺｼｽﾃﾑを活かしきれない HyperV(docker)とVirtualBoxを共存させると不具合が出やすい このあたりがWindowsの仮想化は弱いという所以 472 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:35:41.27 ID:W3hSYpRn.net] >>465 UIもOSの機能の一つだから、それがないのは劣ってると言わざるを得ない MacでVirtualBoxが必須なのは↓こういう話ですか？ｗ Virtualboxをﾒｲﾝに使うなら複数は必要ないけどDockerがHypervisorフレームワークを選ぶ という愚行を犯してしまったから仕方なく複数つかうしかない状況 473 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:35:46.96 ID:Vqf8sefQ.net] >>456 ﾊｲﾊﾟーﾊﾞｲｻﾞーﾌﾚーﾑﾜーｸだけで十分だった Windowsはむしろ余計なものを追加しやがってといった印象 474 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:36:10.01 ID:Vqf8sefQ.net] >>458 余計な機能だからな 475 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:36:19.27 ID:W3hSYpRn.net] とことんブーメランになってるよなｗ HypervisorフレームワークだけではVagrantというエコシステムを活かしきれない（笑） 476 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:37:14.61 ID:W3hSYpRn.net] >>468 「なんでMacにはOSの基本機能が搭載されてないの？」 「Macはサーバーじゃないんだからそんな機能は不要！」 477 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:38:40.46 ID:W3hSYpRn.net] >>467 Hypervisorフレームワークだけで仮想マシンにLinuxをインストールする方法を教えて下さい あ、Macはフリーソフトを使えば出来る！が自慢でしたっけ？ｗ 478 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:39:32.30 ID:Vqf8sefQ.net] >>461 HyperVだけじゃVagrantなど蓄積された 479 名前：仮想化ｴｺｼｽﾃﾑを活かせないんだよ HyperVだけでは物足りない なのにVirtualBoxを共存させると不具合が出やすい かと言ってHyperVをｵﾐｯﾄしたらDockerｴｺｼｽﾃﾑが弱体化する Windowsでは仮想化を活かしきれないんだ 完全にDockerだけを使う分にはWindowsでも許容範囲内なんだけどね [] [ここ壊れてます] 480 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:39:42.41 ID:yDaMs/Xo.net] Dockerはどっか行けよ 481 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:42:18.90 ID:W3hSYpRn.net] macOSはCLI環境が弱いですからね。 ターミナルもみんなiTerm2とか入れるし パッケージ管理は、サードパーティのHomebrewをインストール そしてろくに動作検証もされてない ただ収録しただけのパッケージを使うしか無い CLI環境っていうか開発全般が弱いのかｗ 482 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:42:34.51 ID:Vqf8sefQ.net] >>463 ﾒﾓﾘは32G詰んでる でもどんなにﾊｲｽﾍﾟでも簡単にﾒﾓﾘを食いつぶすように作られてるから意味ないよ 設定を変更すれば食いつぶすﾒﾓﾘ上限を設けることができるけど設定値まで食いつぶすのは相変わらず ﾘｿーｽ効率がいいのがｺﾝﾃﾅのﾒﾘｯﾄなのにこれじゃあ意味が無い 483 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:44:19.79 ID:W3hSYpRn.net] >>472 はぁ？VagrantはOSの機能じゃないし、もはや必要とされてない。 重い仮想マシン上のLinuxにログインして開発する時代は終わってるんだよ OS標準のCLI環境とDockerを使った実行環境を使って開発する時代に変わった いつまで旧式のエコシステムを使ってるの？ Dockerを使ったエコシステムに乗り換えろよ 484 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:48:10.81 ID:PIkW4oBq.net] >>464 キャッシュに大量のメモリを食われるのは相変わらずと読めるね キャッシュクリアのためにWSLログインしてコマンドうつの面倒でしょ 485 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:52:07.56 ID:PIkW4oBq.net] >>466 いやいやUIなんてｵﾌﾟｼｮﾝですよ なんならｺﾝｿーﾙで済む MacでもWindowsでもVirtualBoxが必須とは言っていない DockerをやりたいだけならDocker for Desktopでどちらも問題ない しかしDocker以外の目的で仮想マシンを使いたくなった場合Macは非常にうまく動作するがWindowsはそうではない そう言ってるんで早く理解してください 486 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:52:48.57 ID:PIkW4oBq.net] >>469 VirtualBoxを入れるだけ 487 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:53:14.29 ID:PIkW4oBq.net] >>470 意味不明 488 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:54:27.48 ID:PIkW4oBq.net] >>471 そのとおり Macには選択肢がある 489 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:56:20.43 ID:PIkW4oBq.net] >>474 とはいえWindowsよりは幾分ﾏｼでしょうな ｺﾏﾝﾄﾞﾌﾟﾛﾝﾌﾟﾄでしたっけ？ あとはやけに動作が遅いPowerShell 490 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:58:43.45 ID:PIkW4oBq.net] >>476 それはあなたがｱﾌﾟﾘ開発者だからでしょうね 確かにｱﾌﾟﾘ開発という狭い世界ではDockerがあれば十分かもしれない でも世の中はｱﾌﾟﾘだけでは回らないので仮想ﾏｼﾝも必要になってくる ｲﾝﾌﾗのお勉強もしてみると視野が広がるのでｵｽｽﾒ 491 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 13:59:37.74 ID:W3hSYpRn.net] >>482 あとはWSL用のターミナル（コマンドプロンプトと同じだがbashが動いてる） そしてWindows Terminalもリリースされたね もう完全に逆転されてるよｗ 492 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:00:23.21 ID:W3hSYpRn.net] >>483 Macってインフラ弱いよね Linuxのコマンドがことごとく使えないｗ 493 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:03:13.26 ID:PIkW4oBq.net] >>484 逆に衰退してるように思える どっちつかずの半端なｼｪﾙしかないからｱﾚｺﾚ併用せざるを得なくなって しょうがないからWindows Terminalでﾀﾌﾞ管理できるようにしました これって完全に根本解決を諦めた人達の答えだよね 494 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:03:30.42 ID:PIkW4oBq.net] >>485 Windowsもね 495 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:05:23.74 ID:W3hSYpRn.net] >>486 > どっちつかずの半端なｼｪﾙしかないからｱﾚｺﾚ併用せざるを得なくなって どっちつかずの半端なｼｪﾙとは？ その理由を言えないから説得力ゼロなんですよ 496 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:05:54.28 ID:W3hSYpRn.net] あぁ、半端なシェルってタブがないだけと� 497 名前：｢う意味だったか。程度が低いな [] [ここ壊れてます] 498 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:06:15.33 ID:wDwMFBJk.net] そういえばMac板にこんなスレがあった macOSは同一Macの仮想マシン上のLinuxよりも遅い https://egg.5ch.net/test/read.cgi/mac/1582504945/ ＞macOS上のDocker（OS標準仮想マシン）上のLinuxでbash（5.0.16）を動かした場合 ＞$ docker run -it bash /usr/bin/time -p bash -c 'for i in $(seq 10000); do (:); done' ＞real 5.20 ＞user 2.47 ＞sys 2.46 ＞ ＞macOS上ネイティブでbash（Homebrewの5.0.16）を動かした場合 ＞$ /usr/bin/time -p bash -c 'for i in $(seq 10000); do (:); done' ＞real 8.26 ＞user 3.07 ＞sys 5.08 ＞ ＞ ＞「仮想マシン上のLinux」よりも「macOS上ネイティブ」の方が遅い 499 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:07:54.46 ID:W3hSYpRn.net] >>490 Macは半端なUnixだからそういうこともあるでしょうね 500 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:08:23.92 ID:hbOZVAas.net] >>488 ﾚｶﾞｼーなｺﾏﾝﾄﾞﾌﾟﾛﾝﾌﾟﾄ 重いPowerShell HyperVに依存した仰々しいWSL 等々 これが正解だってｼｪﾙが無い 501 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:09:34.07 ID:W3hSYpRn.net] WSL1はHyperVに依存してないんだが？ｗ 502 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:09:52.72 ID:hbOZVAas.net] >>490 Macの仮想化が優秀ということですね 503 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:11:06.36 ID:hbOZVAas.net] >>493 2の話をしてるからね つうかWSL1なんて更に中途半端でしょ 504 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:11:15.80 ID:W3hSYpRn.net] Windowsはbashもつかえるよ bashだけじゃなくて全てのLinux用シェルがつかえる macOSにとって正解だってシェルはzshのようだが Windowsには選択肢がある（ドンッ！） 505 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:12:34.66 ID:hbOZVAas.net] >>496 ろくなbash処理系なかったと思うが何を使ってんの 506 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:13:41.57 ID:W3hSYpRn.net] >>495 Macのターミナルなんてフリーソフトを使わないと 中途半端過ぎでパッケージないじゃんｗ 標準のパッケージ管理ソフトもないんだっけな 507 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:14:21.94 ID:W3hSYpRn.net] >>497 > ろくなbash処理系 bash処理系なんていい方初めて聞いたわｗ bash処理系がいくつかあるとか思ってんの？ 間抜けやなぁ 508 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:16:28.10 ID:hbOZVAas.net] >>498 zshだけでもWindowsよりﾏｼよ ﾊﾟｯｹーｼﾞ管理もbrewとかいろいろ選択肢あるし そもそも標準である必要が全くないんだが 509 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:17:34.21 ID:hbOZVAas.net] >>499 幾つもあるよ まさか全てのbashが同じﾊﾞｲﾅﾘで動いてるわけでもあるまい 510 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:22:15.69 ID:W3hSYpRn.net] ああ、処理系ってバイナリの違いを言ってたのか。間抜けやなぁｗ 511 名前：デフォルトの名無しさん mailto:sage [2020/07/19(日) 14:23:09.52 ID:W3hSYpRn.net] >>500 Windowsはzshをつかえるようになりました。 パッケージ管理はmacOSよりも多くの選択肢を持っています。 さらにOS標準で持っていることが何より強いです

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef