Just Use MSYS2 You Say? (opens in new tab)

My solution was to run my own server and have students log in from a browser. It's an order of magnitude easier to do the work of running a server than to take on the burden of supporting student-run Windows installations. Someone that hasn't been in that position is usually thinking in terms of what works for them or maybe the average student. You have to support all of them. The last 20% of students, who may turn out to be stars once things are set up, are going to give up in frustration if they struggle with the setup. Thankfully, these days there are good options where other people run the server for you.

> It uses pacman from ArchLinux, which is easily the worst package manager ever invented. Quick, how do you search for a package that you've installed? Oh? What's that, did you just have to google for one of the weird single letter options? I rest my case.

Rest your case? Is that the only argument? The fact that if someone can't remember specific flags that they rarely use makes a cli program the "worst" is stupid. By the same logic since I don't know how to search for installed packages with apt (it's been years since I used a debian based distro), is it fair for me to say apt is the worst package manager ever invented?

> If you don't think these things happen, you haven't use pacman for long enough.

How long is long enough? I've been using Arch (btw) daily for more than 10 years, maybe close to 15, on my personal PC and I've been using MSYS2 on my work laptop for more than 1 year. Never encountered Pacman-related issues...

I hate developing on windows as much as the average arch user, but if setting up vscode with docker on windows takes you 12 hours it's a you problem. There are lots of reasons why using docker containers is appealing, especially for students.

Mostly because they generally end up installing ten different odd and outdated software packages for each eccentric overly opinionated instructor they have. Each of whom rarely care to spend enough time to help these novice students understand how to resolve the issues they sometimes create on their only computing device they need to use for all of their other classes in the process.

If the student can get docker installed, at least they are more likely to be able to keep a somewhat stable machine.

Thought this article was old or something, but no, it’s from a few days ago.

Docker (for Windows) in WSL2 is the default now - if you wanted to do it a few years ago, then yes, it could be complicated to set up docker within WSL2 manually[0], but Docker has long moved away from being a Slow VM (toolbox) and recently from its own VM in Hyper-V to running inside WSL2, both of which offer near-native performance (depending on where your bind mounts are).

0: https://github.com/drud/ddev/issues/3419

mingw/msys2 are not easy to use

and now WSL2 can use a X server on windows, which is quite nice.

although when I see news about win11 I still think my next laptop will run linux, not windows... but then I remember avidemux, paint.net, foobar2000, and I realize that I will stay on windows

There are lots of programmers who would rather have a Unix-like environment but are compelled to use Windows machines. Almost nobody with the reverse situation.

So they install Cygwin, or MinGW / MSYS2, or Git Bash, or WSL, so they don't get the braindead Microsoft vision of what a shell and userspace should be. They get a comfortable and familiar environment they're productive with, using software that was designed for Unix and written using Unix. They know what they're doing and accept the tradeoffs they've made. They are not the same as the naive user who needs their hand held.

If these programmers build software for naive users, they should be using languages suitable for cross-platform support, and target-specific build solutions, like jlink, electron-builder, PyInstaller... duh! Or write C/C++ linked to cygwin1.dll for Unix semantics (in the same way Windows developers can write C/C++ linked to libwine.so.1 for Windows semantics...)

If that approach isn't a good fit, then sure, go native development in the target platform. Learn PowerShell rather than try to write it in bash and bundle the entire Unix userspace to make it work. But don't say you need to adopt the full Windows native toolchain and spend years becoming adept with them, unless you're actually planning to become a native Windows developer.

---

> First you install VSCode then spend then next 12 hours getting docker to run dev containers inside a WSL2 image (which is just a VM that can't talk to the internet) and TADA!

I refuse to believe that docker takes 12 hours to do anything, even for a complete beginner, and... what on earth are you on about claiming that WSL2 can't talk to the internet?

> Any expectations beyond this are probably not going to work. If you think the above person can install and use Docker you're sadly mistaken.

That might well be fair, although

> I'm a platinum star Linux user who started using Linux after buying a box of 72 floppy disks from Ygraddisil Linux in 1993 and I can't figure out Docker half the time.

... are you? I'll give beginners a pass, but docker isn't hard hard; I really struggle to square the idea of someone managing Ygraddisil but not docker.

Now on to MSYS2:)

> The installation takes forever because it's basically building an entire Linux system from scratch.

That's actually fair.

> It uses pacman from ArchLinux, which is easily the worst package manager ever invented. Quick, how do you search for a package that you've installed? Oh? What's that, did you just have to google for one of the weird single letter options? I rest my case.

What package manager is better? I've used a lot of package managers, and literally the only one where I would know how to check that without searching is apk, and even then I'd be grepping /etc/apk/world which only covers directly-installed packages (not dependencies). (FWIW, the better argument is installation: `apt install foo` is more obvious than `pacman -S foo`)

> Because of pacman it uses GPG to ensure that packages only come from approved people, which is a good thing, but pacman is terrible at maintaining the keys. Right away this first install needed to update the key list, which isn't well documented, and only documented on ArchLinux or random blog posts. Think about this: To use MSYS2 a user would have to know that pacman is from ArchLinux, know that the GPG key errors require a keyring update, and know that they have to go find the docs to do this from the ArchLinux website.

First, let me say that I think pacman is kind of annoying at handling keys, though they've improved over time. The rest of the claim appears to be nonsense.

https://googlethatforyou.com?q=pacman%20gpg%20update

Oh look, the first result is an official wiki page with a troubleshooting section. And the user didn't need to know any of those things.

> After you get through this hurdle you then have to install the right software, and MSYS2 makes the "genius" decision of letting me pick which binary I want to install for every single install. Do you need to install fmpeg? Better spend an hour sifting through clang-amd64-ucrt-mingw32-ffmpeg vs. gcc-x86_64-w32-gnu-ffmpeg and tons of packages.

Huh. Yeah, that does seem odd - is it a result of MSYS2 being oriented at devs who need compatible libraries?

> The GPG Keyring Problem

This section might be fair. It does seem like pacman should be able to automatically manage its list of trusted keys?

---

Now, all that said... if your super cool magic scripts work, and don't have significant downsides, then sure go for it. Being like 10% less antagonistic could have made this a useful list of ways some tools could improve, but as-is it's just lashing out at people in ways that seem to have little concern for reality.