...which is exactly what you're meant to do.

This is not an example of how bad Bash it, it shows that you didn't understand what Bash is. It's expected to use various languages to write code on Linux, nobody wants you to do things in a language that wasn't made for the task.

Imagine you had to use Python on the shell and, any time you open a terminal, needed to import os and do something like print(os.path.glob("*")) instead of just opening a terminal and typing "ls" to get your directory listing. Different tools for different jobs.

Also the point they try to make about bash looking like a foreign language and having weird syntax. Yes, that's the thing: it's a very specific thing called a shell, not just any old programming language that you're meant to use for things that are not shell scripts. If Python feels more natural to you, that's probably what you should be using. Don't feel like you need to use Bash for bigger tasks than a few lines of code for no reason other than because you're on a system that has it.

Yes … well …

We brought on via acquisition a bunch of Windows devs. It turns out we can't even clone the repository onto their laptops: some files in the repo have ":" in the filename, which is forbidden. There's a "aux.rs", also a verboten filename in Windows. And then there were some that differed only in case, which honestly I don't know how we manage that, as the non-Windows side is macOS, and yet roughly once per year someone introduces two files, same name, differing case into the repo.

> that "CRT" shader

Okay … that's not what CRTs looked like. Like, the curve seems way overdone compared to my memory, and IIRC the "lines" affect was really only visible on TV/camera. I have no memory of noticing it IRL, and I spent plenty of time at a command prompt.

(E.g., this random example — https://i.redd.it/1s3ny22b2va51.jpg — matches my memory pretty closely.)

(Also there were flat screen CRTs, but those were relatively late to the game and were rapidly obsoleted by actual flat screens.)

Edit: but also I want to play a round of Hack¹ with that shader.

¹i.e., quest for The Amulet of Yendor; you might know the newer incarnation, NetHack, but I didn't play that until flat screens, I think; the CRT time would have been on Hack.

More relevant in my view is how well the workstation you use supports interacting with your build system. In many organizations, the actual build environment is only ever going to be Debian or alpine in a container, in which case, it doesn’t really matter which computer you have on your desk. If all your building happens remotely on a cloud instance, it hardly matters at all.

So by all means, use whatever computer you want. The great thing about the current era of computing is how little depends on the computer for getting work done. The author’s Chromebook story makes this point perfectly. Use what you have or what you like or what you can get, and get on with life, I say.

Also, regarding this example

    {
        $Env:MYSQL_HOST = "MyHost.com";
        $Env:MYSQL_USER = "MyUser";
        java -jar myprogram.jar;
    }

    (
        export MYSQL_HOST="MyHost.com";
        export MYSQL_USER="MyUser";
        sh -c 'echo "using $MYSQL_USER@$MYSQL_HOST"'
    )
    sh -c 'echo "using $MYSQL_USER@$MYSQL_HOST"'

    using MyUser@MyHost.com
    using @

You can use PowerShell on Linux. You can use vcpkg on Linux (very well, even). You can learn C++ and you wont need the `_In_` and whatnot. If you use WSL2 for your development, are you even developing (fully) on Windows?

What you can't do is really own a copy of windows (any recent one), and have the freedom to decide what tools you will use. There is nothing protecting your system from locking you out of any setting, at any point, and requiring you to buy a different key, subscribing, giving them your data, or whatever else.

Two thing I can say for any naysayers who use a Mac and do devops, backend development etc.:

1. Are you sure your environment that matches your deployment environment? Do you have confidence your server code runs the same on an Apple Silicon Mac as the (very likely) x86-64 and Linux environment your users use?

2. Have you ever noticed how shell scripts on Mac often... don't work the same on Linux? The way to fix that is of course use Homebrew, and, while brew has gotten leagues better, the quality pales in comparison to even Debian testing, Ubuntu main, or Arch and others.

As a devops engineer for many years, #2 was death by a thousand cuts. If I could, I'd have replaced every Mac user's userland with GNU coreutils from brew without their permission.

To square the circle of preferring Linux systems and Windows' UI, I've done just about every approach you can imagine to make that work, from syncing folders via rsync, to ssh or nfs mounted filesystems. I've used Virtualbox and VMWare and Hyper-V to locally run the Linux environment. There have been a few different X window managers and remote desktop tools, but none of them have been great.

WSL1 is where things really began to turn around - what an interesting project to make the NT kernel work as a Linux kernel. It didn't quite pan out, but that was OK.

WSL2 made major changes to how WSL worked, and now I can now run Kubernetes, Docker, 3d applications, machine learning (stable diffusion), have a real Linux shell and userland.

WSL2 is a true game changer for quality of Linux development on Windows. Being able to `docker run` Stable Diffusion or Llama or what-have-you is incredible.

I can imagine a PopOS - or another vendor-backed Linux OS - might persuade me eventually to shed Windows. In the meantime, I don't feel like I'm making any compromises.