What bash scripts are you writing that you expect to run on both a Mac laptop and a production linux server? You can install the newer bash if that’s what you’re used to, but you’re surely going to run into issues like ls . -lah far quicker than differences in bash since 3.2

Even on a linux desktop you’re going to have differences from a production server, you’d want to be using something like ansible, or replicating production in a local test environment in a container or VM. Exactly like you have done.

How’d you end up being the only one at your workplace to be given a Mac? Even with a linux VM, being on ARM can cause issues with compatibility.

If your script starts with #!/bin/bash, both bash and zsh will run it fine. The bigger problem is the programs, filesystem and libraries being different. Which is why POSIX exists, if you’re looking to write stuff that works across systems.

I couldn’t tell if you were honestly asking for explanations or if all of your complaints sum up to “it’s different and I don’t like that”. Which honestly, fair.

Like, why is bash ancient? (3.2 vs 5)

To avoid GPLv3, zsh is the new default.

Why is there no package manager

Mac App store is the official one, can also install brew, macports, pkgsrc, or nix. Or use language/runtime specific ones like npm, pip, cargo, go.

Why are the utils like ls and friends flag-order-sensitive

They avoid GNU versions of utilities, for similar licencing fears as avoiding modern bash. That said ls . -lah is unhinged, I don’t know any other unix derived ls that supports that.

Why do I have 40 network devices with cryptic names?

Yeah they got some weirdo Apple stuff

Gotta preach for the cult of ZFS. It’s check summing, copy on write, and zraid features are all exactly what you want for data resilience. Plus you get transparent compression, and snapshots that can provide a bit of a stop-gap for your lack of backups.

It will normally soak up any and all memory for buffers and caches, but is meant to quickly free up when it’s needed by an app. Linux already does this on any filesystem with its page cache.

Oh and mounting a ZFS dataset on a new machine is super quick and easy, it stores it’s config on the drives themselves, so you can plug them into a new box and zpool import -af and boom it’s mounted and ready to go.

I’ve always geeked out about fan curves and monitoring, though I readily admit for most PCs leaving the default BIOS curve works fine enough.

I just used the free chat with Claude, it created and tracked the files in its own webchat thingy. Being a kernel module, I was happy to manually check, copy/paste, compile, then run the code for each iteration.

Porting postmarketOS to a phone sounds like it may require some amount of manual running and explaining results back to the chat. Ultimately the output only starts to get functional when it hits reality and needs to keep adapting to feedback.

I wrote a blog on the process that more focuses on the journey and technical details of the controller chip.

I used a very similar method in a similar situation to albb0920. They describe it as vibe coding too.

The exact chip that handles everything is undocumented, but similar ones in the same series have datasheets. A maintained version of the linux driver handily collated all of the available datasheets and configurations used by different motherboards. Between that and my microcontroller/hardware experience, that side of things wasn’t too bad.

What I didn’t know anything about was writing an Illumos driver. I used the chatbot with a free claude account, compiling and running the code manually myself. I was impressed that it was able to build out the boilerplate and get something going at all. Course it took a few tried to get something that compiled and worked somewhat correctly. At some points I needed to look through the generated code and point out exactly what what wrong, but at least it would address it.

Code running in the context of the kernel is definitely not something I would have autonomously executing by a LLM. The end result is absolutely not something I would want put into the official Illumos source.

This from the company that started the netbook trend with the $400 eeePC in 2007…

Maybe you should