Visual Studio Code / VSCode Part8

**デフォルトの名無しさん** · 2020/06/11(木) 12:01:27.72

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/

**デフォルトの名無しさん** · 2020/07/15(水) 15:16:00.68

JavaScriptウゼーからはよWebAssembly実用化して欲しいわ

**デフォルトの名無しさん** · 2020/07/15(水) 15:19:22.69

jsスレはﾜｯﾁｮｲどころかIDすら非表示だから荒らし御用達
このスレはﾜｯﾁｮｲで防衛すべき

**デフォルトの名無しさん** · 2020/07/15(水) 16:00:24.57

すみません、教えてください。よろしくお願いします。
vscodeでjavaを使おうとしたのですが
java:create java project
できません。

vscodeとjdkをインスツールし
jdkはshellで確認できますので、pathも通っています。
vscodeのjava.homeも設定できていると思うのですが
どうすれば、create java projectできるようになるでしょうか？

**デフォルトの名無しさん** · 2020/07/15(水) 16:11:05.50

エラーメッセージは？

**デフォルトの名無しさん** · 2020/07/15(水) 16:13:05.11

「おやじ！メロンパンくれ！」
「うちは果物屋🍈だよ？」

**デフォルトの名無しさん** · 2020/07/15(水) 16:53:30.48

>>386
DOMの制限ってなんだよ？
言った誰がDOMの制限の話をしてるんだよ

**デフォルトの名無しさん** · 2020/07/15(水) 16:55:46.07

>>388
WebAssembly実用化してもDOMの制限は残るぞ

**デフォルトの名無しさん** · 2020/07/15(水) 17:22:15.36

>>394
C#のパーサー使うからどうでもいいです

**デフォルトの名無しさん** · 2020/07/15(水) 19:04:50.32

>>374
ををを　サンクス！

**デフォルトの名無しさん** · 2020/07/15(水) 19:06:02.51

>>382
あの後から取って付けた感ありありのプロトタイプが根本に見えちゃう人はさすがにｗ

**デフォルトの名無しさん** · 2020/07/15(水) 19:33:21.89

>>397
「取って付けた感」を具体的に？

**デフォルトの名無しさん** · 2020/07/15(水) 20:54:46.51

prototypeとか[[prototype]]とか__proto__とか

**デフォルトの名無しさん** · 2020/07/15(水) 21:14:26.34

で、それのどこに「取って付けた感」があんの？
プロトタイプベースでそのプロトタイプ情報をオブジェクトに持たせるなら、表現は簡単だし、実装もたぶん簡単だし、悪くないやろ。

ほとんど見当たらないScheme要素よりもはるかに根本的。

**デフォルトの名無しさん** · 2020/07/15(水) 23:39:14.30

[[prototype]]はともかくprototypeと__proto__は最初からじゃねーか
どこが取って付けてるんだ？文句言いたいだけじゃん
そんなんだったらプロトタイプベース自体に文句言うやつのほうがなんぼかマシだわ

**デフォルトの名無しさん** · 2020/07/16(木) 00:41:37.20

つまりオブジェクトやプロパティというものが実装された言語の上に「特殊なプロパティ」として
プロトタイプチェーンを載っけているところを指してそう言ったわけだが。
Ioのように言語の不可分な要素として実装されていたりあるいはせめてluaのメタメソッドのように
最初から考慮された設計なら違って見えたが。

**デフォルトの名無しさん** · 2020/07/16(木) 01:06:27.07

じゃpythonの__hoge__みたいなのは？
phpにも似たようなのあるよね。

**デフォルトの名無しさん** · 2020/07/16(木) 01:25:34.43

Pythonはきれいな言語じゃないよお
やっつけ感が大きい

**デフォルトの名無しさん** · 2020/07/16(木) 01:40:17.48

1.47とMarkdown Preview Enhancedの組み合わせでMarkdownのファイルリンクが上手く動かなくなってる
これまでに大量に書いてきたメモの蓄積が･･･
MPEのバージョンアップで直るといいんだが

**デフォルトの名無しさん** · 2020/07/16(木) 02:14:03.73

>>402
それは、個人的な嗜好であり、ただ潔癖なだけ。
# 気持ちはわかるが。
配列オブジェクトも、プロパティにメチャクチャ感があるけど、つまり、そういうポリシー。
「取って付けた感」では全然ない。

たとえば今から新しくつくる言語だとしても、表現や実装の都合で、特殊なプロパティをほかに混ぜてしまう選択は、ふつうにあり得る。

で、Schemeの話はどこにいったんだよ？

**デフォルトの名無しさん** · 2020/07/16(木) 08:17:23.65

プロトタイプチェーンというものがその配列と同じようなレイヤーで実現されていることを
指して言ったわけなんだが。
それが「根本」に見えちゃうのは主観なんでそれ以上は言わんけど。

**デフォルトの名無しさん** · 2020/07/16(木) 09:07:29.56

スレチ

**デフォルトの名無しさん** · 2020/07/16(木) 09:29:46.00

>>407
日本語能力と言語センスがないことはわかった。

>>408
まあまあ。。。

**デフォルトの名無しさん** · 2020/07/17(金) 21:16:25.00

最初からオブジェクト指向言語として設計していたならあのthisはないよなぁ。

**デフォルトの名無しさん** · 2020/07/17(金) 23:39:54.29

なんで？最初からプロトタイプベースオブジェクト指向言語として設計されてたよ？
おかしくなったのはそのプロトタイプベースオブジェクト指向言語として設計されてたものに後付けでnewやらthisやらのC++/Java系のクラスベースオブジェクト指向用語を無理やり導入してJavaっぽいクラスベースオブジェクト指向言語に見えるよう無理やりガワを被せようとしたため。

**デフォルトの名無しさん** · 2020/07/18(土) 05:17:12.44

TypeScriptでラップすると快適やわ

**デフォルトの名無しさん** · 2020/07/18(土) 11:34:26.80

>>411
その珍説はどこから？
プロトタイプベースだろうがオブジェクト自身へのアクセスにthisは必要だし、
newによるコンストラクタ呼び出しがなければ別の方法でプロトタイプチェーンを構築
していたことになるが、そいつらがプロトタイプ自身より後付けとは考えにくいんだが。
もちろんどっちもクラスベース固有の概念じゃあない。

**デフォルトの名無しさん** · 2020/07/18(土) 12:25:08.69

es2015以降のclass構文はともかく（あれもシンタックスシュガーなのに文法上new使用を強制してるだけだが）、
JSのnewはJavaに見た目を寄せるためのシンタックスシュガー以上の意味はない。
見た目こそ同じnewだが、C++やJavaのnewとは全く異なる。
JavaScript: The Good Parts 133ページ
> new演算子の持つ問題に対するもっとも良い方法は、newをまっまく使わないことである。

使わなくて全く問題ない。
JSのnewはJavaに見た目を寄せるためのシンタックスシュガー以上の意味はない。
見た目に騙されてC++やJavaの知識を転用しようとすると理解を誤る。

**デフォルトの名無しさん** · 2020/07/18(土) 13:48:24.95

> 見た目に騙されてC++やJavaの知識を転用しようとすると理解を誤る。

C++やJavaの知識ってなんのこと？

**デフォルトの名無しさん** · 2020/07/18(土) 14:00:57.09

newとはこういうもの！これ以外のはずがない！という思い込み・囚われている常識、のことかな

**デフォルトの名無しさん** · 2020/07/18(土) 15:08:39.55

プロトタイプ系とクラス系の違いも。

つうか、プロトタイプ系はわかりにくいんだよ！
実装は簡単というか、手っ取り早いと聞くので、当時ブラウザに埋め込むにはちょうどよかったんやろけども。

**デフォルトの名無しさん** · 2020/07/18(土) 16:25:25.54

もともとネスケのためだけのマクロに過ぎなかったしねえ
20数年後にこれを使ってアプリを書く人たちが現れるとは想定してなかったんじゃなかろうか

**デフォルトの名無しさん** · 2020/07/18(土) 16:33:34.40

>>4124
ああ、プロトタイププロトタイプ言いながら自分でプロトタイプベースで書いたことはないのね。
newをまったく使わないというのは自分で__proto__を操作するかあるいはプロトタイプ継承を
使わないってことになるんだが。
当然、前者を推奨しているわけがない。

**デフォルトの名無しさん** · 2020/07/18(土) 17:07:44.12

>>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は重要な機能が欠けた
不便なプロトタイプベースオブジェクト指向だった

**デフォルトの名無しさん** · 2020/07/18(土) 17:36:07.70

>>420
そういう話じゃない。
そもそも継承なんかしないユーザーレベルでも、なんかわかりにくいんだから。

JavaScriptが不出来だからとかドキュメント不足とか、理由はいろいろあったと思うけど、それだけでもない。

**デフォルトの名無しさん** · 2020/07/18(土) 17:53:27.03

それはライブラリが不足していただけ
どんな言語でもライブラリがなければ使いづらい
JavaScriptはjQueryが登場してから世界が変わっただろ

**デフォルトの名無しさん** · 2020/07/18(土) 18:19:52.24

スレチ

**デフォルトの名無しさん** · 2020/07/18(土) 21:26:08.79

>>422
だから、そういう話じゃない。
JavaScriptの使いやすさのことではない。
言語としてのわかりやすさについて言っている。

むしろ、prototype.jsとかjQueryとか出てきてから、JavaScript自体はわかりにくくなった気さえする。
こなれたコードを見る機会が増えて、慣れてもいいはずなのに。なんかわかりにくくて、あやしいからか？

>>423
まあ、VSCodeの話題も出てこないことだし。。。

**デフォルトの名無しさん** · 2020/07/18(土) 21:47:03.20

とりあえずお前らのおすすめの拡張
説明付きで教えろください

**デフォルトの名無しさん** · 2020/07/19(日) 00:25:37.44

最近使うようになったやつ
Draw.io Integration - 作図に便利
Code Spell Checker - typo が減った

**デフォルトの名無しさん** · 2020/07/19(日) 05:09:46.41

>>424
JavaScriptのどこがわかりにくいのか全くわからん

日本人が日本語は簡単だが英語はわかりにくいって
言ってるようなもんだろ

言語としてのわかりやすさじゃなくて
お前の知識の問題

でないと俺みたいにJavaScriptが分かる人がいることが説明できない

**デフォルトの名無しさん** · 2020/07/19(日) 07:36:22.70

>>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

**デフォルトの名無しさん** · 2020/07/19(日) 11:32:11.41

>>428
一番下便利そうだな。
どうせDockerで開発するならこれありゃWSL2なんかいらんかったなｗ

**デフォルトの名無しさん** · 2020/07/19(日) 11:38:21.65

>>429
ホストとコンテナのボリュームをマウントするときに、ホストがWindowsだといろいろめんどいのでWSL2も使うのがオススメ

Windowsで使う場合、WSL2で立てたlinuxマシンにRemote WSLで繋いで、そこからRemote Containersを使うのが良い

**デフォルトの名無しさん** · 2020/07/19(日) 11:59:48.19

>>429
そのDockerはWSL2上で動いてるんだぞ？

**デフォルトの名無しさん** · 2020/07/19(日) 12:00:08.13

ややこしいな…

**デフォルトの名無しさん** · 2020/07/19(日) 12:06:59.74

WSL2のDockerはメモリ消費しすぎで使い物にならない

**デフォルトの名無しさん** · 2020/07/19(日) 12:11:35.65

WSL2とかじゃなくて時代はDockerなんですよ！

**デフォルトの名無しさん** · 2020/07/19(日) 12:17:50.75

>>431
違う。別物。

**デフォルトの名無しさん** · 2020/07/19(日) 12:22:25.01

コンテナにせよエミュレーションにせよ仮想化テクノロジが最重要であることは言うまでもない
ということは開発機は仮想化に強いMacかLinuxということになる
Linuxはデバイスサポート保障があるマシンのラインナップが魅力的とは言い難い
なので開発者はMacを買うべきという正解が導かれる

**デフォルトの名無しさん** · 2020/07/19(日) 12:23:49.61

>>133
またObsidian.mdやRoamResearchに触発されたのが出てきた
https://github.com/svsool/vscode-memo

**デフォルトの名無しさん** · 2020/07/19(日) 12:31:10.24

デファクトスタンダードが決まったらまた連絡してくれ

**デフォルトの名無しさん** · 2020/07/19(日) 12:44:55.36

>>433
具体的には？

**デフォルトの名無しさん** · 2020/07/19(日) 12:59:28.71

>>436
> ということは開発機は仮想化に強いMacかLinuxということになる
Macが仮想化に強いって何のこと？
MacはLinuxじゃないからDockerはそのまま動かないのに

**デフォルトの名無しさん** · 2020/07/19(日) 13:02:09.25

>>435
別物じゃないよ

**デフォルトの名無しさん** · 2020/07/19(日) 13:02:29.46

>>440
結論ありきで途中の過程がやる気無さすぎなんだろう

**デフォルトの名無しさん** · 2020/07/19(日) 13:06:54.86

Dockerの重要な点として手元で作ったDockerイメージを
そのまま本番環境でつかえるというのがある

しかしMacのCPUがARMになるからこれが難しくなった
本場環境の多くはIntelなのでCPUが違う

そうなると実機はIntel版LinuxのDockerイメージを使って
手元ではARM版LinuxのDockerイメージを使うか
パフォーマンスの低下を諦めて手元でIntel版LinuxのDockerイメージを
エミュレータを使って動かすしかなくなる

Macは開発に向かなくなってきている

**デフォルトの名無しさん** · 2020/07/19(日) 13:09:27.60

>>440
Macが強いというよりWindowsが弱いので相対的に良いってだけ

**デフォルトの名無しさん** · 2020/07/19(日) 13:10:01.14

Macの仮想化機能は限定的で、
Hypervisorフレームワークは用意しているが
それを使うためのインターフェースも持っていない
つまりサードパーティのソフトに頼らざるを得ないわけだ

HyperVとそれを扱うHyperVマネージャーを
OS標準で用意しているWindowsとは対照的

**デフォルトの名無しさん** · 2020/07/19(日) 13:11:14.96

>>443
現時点で軽量VM使ってるから大きな変化はないのでは？

**デフォルトの名無しさん** · 2020/07/19(日) 13:12:31.66

>>444
Windowsの仮想化機能はMacを超えてるぞ
仮想マシン機能は当然備えているし
Macにはない仮想マシン管理アプリも付属

さらにWindows独自のコンテナ機能もある
Windows ServerコンテナというLinuxコンテナに近い機能と
Hyper-Vコンテナの二種類が用意されてる。
そしてDockerもWindowsコンテナに対応している

**デフォルトの名無しさん** · 2020/07/19(日) 13:13:17.94

>>445
そのHyperVの完成度がお粗末

**デフォルトの名無しさん** · 2020/07/19(日) 13:14:06.16

>>446
軽量VMが何の関係があるのか知らんが、
MacのCPUがARMに変わったら
Linuxと同じDockerイメージが使えなくなるか
CPUエミュレーションで遅くなるという話をしてる

同じCPU上での仮想マシンとは違って
CPUが異なると大きなパフォーマンス低下が発生する。

**デフォルトの名無しさん** · 2020/07/19(日) 13:14:28.08

>>448
> HyperVの完成度がお粗末
どこがおそまつなの？
それを言えないんじゃ説得力ゼロなんですよ。

**デフォルトの名無しさん** · 2020/07/19(日) 13:15:13.17

HyperVの完成度の高さはDockerが実用的に動いていることからも明らか
WSL2だけではなくWSL1もHyperVを使っている

**デフォルトの名無しさん** · 2020/07/19(日) 13:21:12.09

>>447
標準の管理ｱﾌﾟﾘは別に要らないと思う
実用性を考えるとDockerやVagrantのようなｻーﾄﾞﾊﾟーﾃｨﾂーﾙと合わせて使うから

Windowsｺﾝﾃﾅは使ったことないからわからないけどLinuxｺﾝﾃﾅと比べると需要少なそう

ﾊﾞｯｸｴﾝﾄﾞがなにか気にせずｺﾝﾃﾅを管理できるから便利なのであって
ﾊﾞｯｸｴﾝﾄﾞの種類が豊富でもあまり嬉しくないような？
2種類あるとなにが便利なの？

あなたが列挙した機能はもっともらしいﾒﾘｯﾄには思えないな
それよりもVirtualBoxとの共存で不具合が出やすいなどのﾃﾞﾒﾘｯﾄのほうがより目立つ

**デフォルトの名無しさん** · 2020/07/19(日) 13:22:18.06

> 標準の管理ｱﾌﾟﾘは別に要らないと思う
いるだろ。Macはユーザーインターフェースが不便なOSだって言いたいのか？

**デフォルトの名無しさん** · 2020/07/19(日) 13:22:42.26

VirtualBoxはいらんよ
なんで複数の仮想マシンが必要なんだｗ

**デフォルトの名無しさん** · 2020/07/19(日) 13:23:12.78

> ﾊﾞｯｸｴﾝﾄﾞの種類が豊富でもあまり嬉しくないような？
> 2種類あるとなにが便利なの？
だからVirtualBoxはいらんよねｗ

**デフォルトの名無しさん** · 2020/07/19(日) 13:24:33.64

>>452
俺が話をしているのはWindowsの方が仮想化機能が充実しているという話
MacはHypervisorフレームワークしかない

**デフォルトの名無しさん** · 2020/07/19(日) 13:24:38.44

スレタイ関係なくなっちゃったじゃん

**デフォルトの名無しさん** · 2020/07/19(日) 13:25:44.28

macOSはOS標準のコンテナ機能も搭載してないからな

**デフォルトの名無しさん** · 2020/07/19(日) 13:25:56.58

ID真っ赤な人はちょっと落ち着いて

**デフォルトの名無しさん** · 2020/07/19(日) 13:26:13.67

>>449
動かなくなることはないと思う
ただﾊﾟﾌｫーﾏﾝｽのﾍﾟﾅﾙﾃｨはあるかもしれない
でもｲﾝﾃﾙがｱｯﾌﾟﾙを追従せざるを得なくなるという話もあるしどちらが良いかは時間をかけて評価しないとならないだろうね

>>450
VirtualBoxとの共存で不具合が出やすい
ﾈｯﾄﾜーｸ関連のﾊﾞｸﾞが出やすい
VagrantでHyperVﾌﾟﾛﾊﾞｲﾀﾞを使うと顕著

**デフォルトの名無しさん** · 2020/07/19(日) 13:27:50.96

>>460
> VirtualBoxとの共存で不具合が出やすい

Windows標準の仮想マシン機能を使えばいいじゃんｗ

**デフォルトの名無しさん** · 2020/07/19(日) 13:28:24.28

>>451
Dockerが動くだけで完成度が高いと言えるならどんな仮想化ﾌﾟﾗｯﾄﾌｫーﾑでも高品質になってしまう
WSL2でDockerを使うとすぐにわかるけどvmmemがﾒﾓﾘを食いつぶして使い物にならない
これがﾊﾞｸﾞ扱いじゃなくﾃﾞﾌｫﾙﾄの挙動というのがすごい

**デフォルトの名無しさん** · 2020/07/19(日) 13:29:21.18

>>462
どんな糞スペ使ってるんだ？

**デフォルトの名無しさん** · 2020/07/19(日) 13:32:18.35

>>462
一方macOSは仮想マシンに常に一定量のメモリを取られるんだが？
最大値を指定しなければ、Linuxの挙動との兼ね合いでそうなると言うだけの話
それはもう修正パッチができていたはず
そして最大値を指定した場合は、macOSの挙動と同じ

重要なことを忘れてないか？
Windowsの場合、使用しなくなったメモリを開放するようになった。
つまりmacOSのように常に一定量のメモリを取られるんじゃなくて
使用しなくなったメモリが開放されるようになった。

Build 19013」の「WSL 2」ではメモリーの使用効率が改善され、「WSL 2」の使い勝手が向上しています。
https://kledgeb.blogspot.com/2019/11/wsl-191.html

**デフォルトの名無しさん** · 2020/07/19(日) 13:33:54.95

>>453
いや必須ではないでしょう
ｻーﾄﾞﾊﾟーﾃｨの仮想化ﾌﾟﾗｯﾄﾌｫーﾑを入れればUIはついてくるから標準に頼らなくてもいい

>>454
Virtualboxをﾒｲﾝに使うなら複数は必要ないけどDockerがHyperVを選ぶという愚行を犯してしまったから仕方なく複数つかうしかない状況
HyperVだけではVagrantのようなｴｺｼｽﾃﾑを活かしきれない
HyperV(docker)とVirtualBoxを共存させると不具合が出やすい
このあたりがWindowsの仮想化は弱いという所以

**デフォルトの名無しさん** · 2020/07/19(日) 13:35:41.27

>>465
UIもOSの機能の一つだから、それがないのは劣ってると言わざるを得ない

MacでVirtualBoxが必須なのは↓こういう話ですか？ｗ

Virtualboxをﾒｲﾝに使うなら複数は必要ないけどDockerがHypervisorフレームワークを選ぶ
という愚行を犯してしまったから仕方なく複数つかうしかない状況

**デフォルトの名無しさん** · 2020/07/19(日) 13:35:46.96

>>456
ﾊｲﾊﾟーﾊﾞｲｻﾞーﾌﾚーﾑﾜーｸだけで十分だった
Windowsはむしろ余計なものを追加しやがってといった印象

**デフォルトの名無しさん** · 2020/07/19(日) 13:36:10.01

>>458
余計な機能だからな

**デフォルトの名無しさん** · 2020/07/19(日) 13:36:19.27

とことんブーメランになってるよなｗ

HypervisorフレームワークだけではVagrantというエコシステムを活かしきれない（笑）

**デフォルトの名無しさん** · 2020/07/19(日) 13:37:14.61

>>468
「なんでMacにはOSの基本機能が搭載されてないの？」
「Macはサーバーじゃないんだからそんな機能は不要！」

**デフォルトの名無しさん** · 2020/07/19(日) 13:38:40.46

>>467
Hypervisorフレームワークだけで仮想マシンにLinuxをインストールする方法を教えて下さい

あ、Macはフリーソフトを使えば出来る！が自慢でしたっけ？ｗ

**デフォルトの名無しさん** · 2020/07/19(日) 13:39:32.30

>>461
HyperVだけじゃVagrantなど蓄積された仮想化ｴｺｼｽﾃﾑを活かせないんだよ
HyperVだけでは物足りない
なのにVirtualBoxを共存させると不具合が出やすい
かと言ってHyperVをｵﾐｯﾄしたらDockerｴｺｼｽﾃﾑが弱体化する
Windowsでは仮想化を活かしきれないんだ
完全にDockerだけを使う分にはWindowsでも許容範囲内なんだけどね

**デフォルトの名無しさん** · 2020/07/19(日) 13:39:42.41

Dockerはどっか行けよ

**デフォルトの名無しさん** · 2020/07/19(日) 13:42:18.90

macOSはCLI環境が弱いですからね。
ターミナルもみんなiTerm2とか入れるし
パッケージ管理は、サードパーティのHomebrewをインストール
そしてろくに動作検証もされてない
ただ収録しただけのパッケージを使うしか無い
CLI環境っていうか開発全般が弱いのかｗ

**デフォルトの名無しさん** · 2020/07/19(日) 13:42:34.51

>>463
ﾒﾓﾘは32G詰んでる
でもどんなにﾊｲｽﾍﾟでも簡単にﾒﾓﾘを食いつぶすように作られてるから意味ないよ
設定を変更すれば食いつぶすﾒﾓﾘ上限を設けることができるけど設定値まで食いつぶすのは相変わらず
ﾘｿーｽ効率がいいのがｺﾝﾃﾅのﾒﾘｯﾄなのにこれじゃあ意味が無い

**デフォルトの名無しさん** · 2020/07/19(日) 13:44:19.79

>>472
はぁ？VagrantはOSの機能じゃないし、もはや必要とされてない。
重い仮想マシン上のLinuxにログインして開発する時代は終わってるんだよ
OS標準のCLI環境とDockerを使った実行環境を使って開発する時代に変わった
いつまで旧式のエコシステムを使ってるの？
Dockerを使ったエコシステムに乗り換えろよ

**デフォルトの名無しさん** · 2020/07/19(日) 13:48:10.81

>>464
キャッシュに大量のメモリを食われるのは相変わらずと読めるね
キャッシュクリアのためにWSLログインしてコマンドうつの面倒でしょ

**デフォルトの名無しさん** · 2020/07/19(日) 13:52:07.56

>>466
いやいやUIなんてｵﾌﾟｼｮﾝですよ
なんならｺﾝｿーﾙで済む

MacでもWindowsでもVirtualBoxが必須とは言っていない
DockerをやりたいだけならDocker for Desktopでどちらも問題ない
しかしDocker以外の目的で仮想マシンを使いたくなった場合Macは非常にうまく動作するがWindowsはそうではない
そう言ってるんで早く理解してください

**デフォルトの名無しさん** · 2020/07/19(日) 13:52:48.57

>>469
VirtualBoxを入れるだけ

**デフォルトの名無しさん** · 2020/07/19(日) 13:53:14.29

>>470
意味不明

**デフォルトの名無しさん** · 2020/07/19(日) 13:54:27.48

>>471
そのとおり
Macには選択肢がある

**デフォルトの名無しさん** · 2020/07/19(日) 13:56:20.43

>>474
とはいえWindowsよりは幾分ﾏｼでしょうな
ｺﾏﾝﾄﾞﾌﾟﾛﾝﾌﾟﾄでしたっけ？
あとはやけに動作が遅いPowerShell

**デフォルトの名無しさん** · 2020/07/19(日) 13:58:43.45

>>476
それはあなたがｱﾌﾟﾘ開発者だからでしょうね
確かにｱﾌﾟﾘ開発という狭い世界ではDockerがあれば十分かもしれない
でも世の中はｱﾌﾟﾘだけでは回らないので仮想ﾏｼﾝも必要になってくる
ｲﾝﾌﾗのお勉強もしてみると視野が広がるのでｵｽｽﾒ

**デフォルトの名無しさん** · 2020/07/19(日) 13:59:37.74

>>482
あとはWSL用のターミナル（コマンドプロンプトと同じだがbashが動いてる）
そしてWindows Terminalもリリースされたね
もう完全に逆転されてるよｗ

**デフォルトの名無しさん** · 2020/07/19(日) 14:00:23.21

>>483
Macってインフラ弱いよね
Linuxのコマンドがことごとく使えないｗ

**デフォルトの名無しさん** · 2020/07/19(日) 14:03:13.26

>>484
逆に衰退してるように思える
どっちつかずの半端なｼｪﾙしかないからｱﾚｺﾚ併用せざるを得なくなって
しょうがないからWindows Terminalでﾀﾌﾞ管理できるようにしました
これって完全に根本解決を諦めた人達の答えだよね

**デフォルトの名無しさん** · 2020/07/19(日) 14:03:30.42

>>485
Windowsもね