Scoop VS WSL

Scoop is a command-line installer for Windows, aimed at making it easier for users to manage software installations and maintain a clean system. It's designed with developers and power users in mind but can be beneficial for any Windows user looking for an efficient way to manage software. Basically it makes our life easier when it comes to software installation of any sort. Scoop support installation for large number of software. Check it out here Scoop.

Use a package manager! Assuming Windows (since it's the odd one out), get yourself some scoop then just scoop install openjdk. No need to navigate to a website, download bundleware, click next-next-next and accidentally install a virus like some caveman from 1997. This has been a solved problem since ancient times!

Should be easy enough, I installed neovim on my windows machine with scoop (you can even get nightly if you want), it's basically a one line install. You can also do a manual install if you want, but you don't have to. It took a little fiddling for me because I wanted to install scoop as well as all applications onto my D drive rather than my C drive, but nothing too crazy. I never got NvChad on my windows machine, but I do have it on linux, and siduck (the creator of nvchad) has given good instructions for installing even on windows, so i don't think it should be a problem. Also, there's a discord for nvchad, and siduck is pretty active on there if you want to ask questions. Good luck!

I update it with Brew on macOS and Scoop [1] on Windows (but I guess it is included in other package managers such as chocolatey).

Of course, a built-in auto-updater would be good, but a packaged version is a nice workaround for me.

[1]: https://scoop.sh/

So I tried installing scoop the "normal" way for both users then ran scoop install {app} --global as per https://github.com/ScoopInstaller/Scoop/wiki/Global-Installs and got:Cannot find path 'C:\ProgramData\scoop\buckets' because it does not exist

There are a number of ways that you can install the Snyk CLI on your machine, ranging from using the available stand-alone executables to using package managers such as Homebrew for macOS and Scoop for Windows.

Scoop provides a wonderful foundation for creating a portable developer's toolkit on Windows systems.

It absolutely 100% can be true.

As an example: Windows Services for Linux 2 used a special init daemon to interact with the host OS.

That meant no systemd. That meant that the `systemctl` program wasn't there.

This baffled legions, armies, of wannabe sysadmins.

https://stackoverflow.com/questions/55579342/why-systemd-is-...

https://superuser.com/questions/1785697/systemd-in-wsl-on-wi...

https://github.com/microsoft/WSL/issues/9477

https://askubuntu.com/questions/1132230/unable-to-run-any-sy...

People on the whole have no idea how this stuff works, and they just copy magic incantations from StackOverflow to get stuff to happen. If that doesn't work, then this OS is broken. The end.

For these guys, WSL was broken.

Result:

MS hired Lennart Poettering.

https://www.theregister.com/2022/07/07/lennart_poettering_re...

He "fixed" it. Systemd now works in WSL2. All those guides for noobs now work. Everyone is happy.

In a world where tools like Flatpak and Snap are proliferating and it's driving deep divisions between Linux distros, if you think the average person struggling with Linux is going to use `ldd` to work out where the dependencies for something live, I'm afraid you are a deep guru who lives on a different plane of existence.

We now have widely-used packaging systems which simply embed an apps entire dependency tree into a package to avoid people having to work out the difference between `apt` and `rpm`. Thousands of terabytes of disk are being burned to make this stuff go away.

Yes, this is too hard. Way too hard.

Better source: https://github.com/Microsoft/WSL/issues/873#issuecomment-425...

One of the bugs where on the Docker side. As I have said, there have been several since release with a lot of impact period overlap. The latest and greatest is not resolved.

It's the issue of abysmal I/O performance in communication between the mounted WSL2 virtual hard disk and Windows mounts inside the WSL2 distro.

I found this github page and I was able to reproduce this from the answer

* Docker engine and not Docker Desktop in a VM. WSL2 works well after some configuration: https://github.com/microsoft/WSL/issues/6655#issuecomment-11...

Seems to more of a Defender issue than a WSL one, see https://github.com/microsoft/WSL/issues/8995

After adding exclusions for the fsnotifier-wsl process and and both variants of the WSL distro path my disk performance was improved.

Adding the idea64.exe process also helped since I was trying to run IntelliJ against projects inside WSL.