61–70 of 78 posts
Am I the only one who said screw it, I'm getting 64GB of ram? The amount of concern about ram, it's not that much more expensive atm to get double or 4x if your already buying a laptop.
Why not use a linux vm on windows? Using a shared folder mounted on the linux vm gets you file sharing, what else would you want that WSL gets you?
> WSL is nice, but it takes up a lot of RAM on my system. I prefer to use MSYS2. That's why you trash WSL2 and just stick with WSL1. I'm surprised they didn't mention it at all. Keep MSYS2 around for where WSL1 doesn't suffice, but that should be fairly infrequent.
WSL1 just doesn't work well enough. I'd never recommend WSL1 for anything. The extra nines in compatibility matter in development work if you have any dependencies in your projects. WSL2 is also pretty good at giving RAM back to the host Windows. I guess you're really running thin on resources if this doesn't do enough.
Am I the only one who said screw it, I'm getting 64GB of ram? The amount of concern about ram, it's not that much more expensive atm to get double or 4x if your already buying a laptop.
Earlier quoted context omitted.
> so that it will be possible to reuse the same code for both TUI and GUI clients. Why must a generaly good improvement these days always start on HN with "rewrite in rust" like it's the only language which still matters. Leave that up to the developer to what they prefer for the job.
> Why must a generaly good improvement these days always start on HN with "rewrite in rust" like it's the only language which still matters. I'm guessing so that its likely to 1) be safer by default, 2) likely to get more contributors, 3) more likely to work cross-platform, and 4) more likely to get attention and survive as a project.
> WSL is nice, but it takes up a lot of RAM on my system. I prefer to use MSYS2. That's why you trash WSL2 and just stick with WSL1. I'm surprised they didn't mention it at all. Keep MSYS2 around for where WSL1 doesn't suffice, but that should be fairly infrequent.
WSL1 was what made me stick to Windows at the time, when I had a new laptop and didn't want to mess much with it. WSL2 was what convinced me to switch back to Linux, since I felt that WSL1 was going to be abandoned. What is its current situation? Is it still maintained?
My understanding from documentation is that WSL1 is "feature complete" but not "maintenance ended": they think they hit a strong Pareto Principal 80/20 for features in WSL1 and realize it won't support everything but often supports "enough" and any further compatibility issues are out of scope both because the tail is extremely long and the risk/reward of time invested into long tail issues are rarely worth it.
I don't think WSL1 will be "abandoned" any time soon, but the list of "Known Issues" will only continue to grow and a lot of people get pointed to WSL2 simply because the long-tail Kernel compatibility is hard to beat if you are directly running the Linux kernel.
But the many tools that work brilliantly in WSL1 still work brilliantly in WSL1 and there are still benefits to its barer/stranger metal approach.
Chocolatey may also cover more stuff than scoop.
Most developers should also be using Windows 2022 with Desktop. What you trade in one time agitation with i210 drivers you gain forever in zero cruft, and maybe more with file deduplication.
In terms of exciting stuff to program, it would be nice if Triton supported Windows.
Omg scoop looks awesome, how have I not heard of it before?
Earlier quoted context omitted.
WSL1 just doesn't work well enough. I'd never recommend WSL1 for anything. The extra nines in compatibility matter in development work if you have any dependencies in your projects. WSL2 is also pretty good at giving RAM back to the host Windows. I guess you're really running thin on resources if this doesn't do enough.
WSL1 isn't the alternative to WSL2, it's the alternative to MSYS2. Surely you don't get more 9's with MSYS2.
I have fond memories of using msys2 for gcc but I’ve never used it for more than that.
Earlier quoted context omitted.
Have you heard about WinGet? It's the official package manager for Windows: https://github.com/microsoft/winget-cli
I tried WinGet out when it came out, but ended up sticking with scoop. What would you say are the advantages of WinGet over scoop?
A smaller advantage is WinGet's default installed sources use Microsoft CDNs for package metadata which are often whitelisted in firewalls or at least gentler in their MITM attacks, and WinGet's primary source (the "winget" source) uses canonical installer URLs rather than repackaging (pulls the same EXE/MSI installer that you would if you went to a download page manually). That combination of well known URL patterns generally means WinGet has a kinder experience with corporate firewalls and corporate anti-virus tools than scoop can provide.