For whatever reason, the current zeitgeist is all about enforcing as many things as possible via tooling versus actually learning core principles.
I think this is because all of tech seems to be culturally downstream from FAANGs who have weird problems like "we have 500 devs making multiple commits a day and we can't trust them to do anything more than close tickets." Those are wholly self-inflicted problems, but the rest of the industry laps them up as if they are the secret to being as "great" as FAANGs. Couple that with tons of people who have less than <7 YOE in tech and/or are switching into it and you see there are very real political advantages to "keeping up with best practices."
I don’t see how using tooling prevents you from learning core principles. As in, what _core_ principle am I missing on because I don’t manually indent my braces? Note that this conversation is about _style_.
The zeitgeist re style is very much “don’t fret too much about it, use an automated tool and move on”.
Compared to the flame wars of the past about tabs vs spaces and other inconsequential things we’ve come a long way, and for good.
> talk even less than before about actual engineering and more about the tools
Isn't that just a consequence of how much--or little--context is shared with (or easily-communicable-to) Random Strangers On The Internet?
For example, I've got some architectural issues going on, but it's a lot of work just to summarize it in a way that doesn't require local/domain knowledge. In contrast, talking about the weather or tabs-vs-spaces doesn't need much set-up.
I suspect FAANGs got infected by these idea by hiring from more conservative institutions driven by their financial bottom-line. I've never worked at FAANGs but I've seen that arc at other companies as they scale. Practices that foster speed and innovation are supplanted by ones that favor predictability and safety.
> the current zeitgeist is all about enforcing as many things as possible via tooling versus actually learning core principles.
That argument doesn't make much sense IMHO. By enforcing as many things as possible using some tooling we now do have more time to actually learn "core principles" instead of figuring how to configure/use/... $IDE/$EDITOR/$TOOL/$COMPILER/$OS to get comparable results (or anything to build at all).
Thanks for posting. I’m the author of this post. If you have any questions about Earthly, Earthly Satellites, or Self-Hosted Satellites, I’m happy to answer.
This one is ridiculous. This should already exist. Until GitHub builds it, you can use GitHub Actions to kick your builds off but run them remotely on Earthly Cloud (https://earthly.dev/). Even the free tier includes arm64 remote runners.
Note: I work at Earthly, but I'm not wrong about this being a good, free, arm64-native workflow for GitHub Actions.
You should sit down with the OP and author of this article, Adam. He has a really good podcast called Corecursive, and your story seems right in its wheelhouse.
Did you use nixos for builds or as your daily driver (or both)? Using nixos as a daily driver doesn't make sense to me, but I'm probably missing something.
I used NixOS for a while, but switched back to Debian. My pain point was that unless you also use Docker etc, deploying applications and deploying the system is inseparable. I don’t want to rebuild my system to update an app. This is especially painful on e.g. Raspberry Pi, because full deployments are expensive and you end up needing to set up VMs for building etc. The killer feature for me would be separable roots, so I could use multiple instances of NixOS on 1 system.
The other aspect is that declarative is nice, but often you care about preserving data as well. So you need backups etc. If you have full system backups, then separating config from data is more complex (and less useful). I’d rather spend my time on a rock solid and frequent backup strategy than worry about NixOS + a solid backup strategy.
I only have 1 server though. If I had more, then being declarative might be more useful. I currently use Nix for project dependencies, which is really nice.
> don’t want to rebuild my system to update an app.
You don't have to do that - there's lots of other options. (Although the system shouldn't rebuild if you don't update your channels, so the premise is interesting/suspicious.)
You can build your app independently against a pinned nixpkgs version. You can build the app and export/import that closure on another system. You can build the app itself using nix-build without engaging the nixos switch.
Building the app is not the problem, Nix adds minimal overhead for that. Deploying the app is annoying because changing a systemd service requires a nixos-rebuild, which is pretty slow on a Raspberry Pi.
There’s no good way to have an auto-updating non-NixOS systemd service on NixOS, because it’s not designed to co-exist with other things.
Also, NixOS is pretty much a DSL around systemd for this kind of thing. Systemd is already fairly declarative, so the indirection seems a bit unnecessary.
> Using nixos as a daily driver doesn't make sense to me
Many Nix enthusiasts use NixOS as a daily driver, and are very pleased with it.
I'd say some of the advantages are: the same 'elegance' from being able to declare how a package gets built carries over to being able to configure a system. -- e.g. for niche things like "setup Yubikey with PAM", I don't have to worry about what config settings to manually change, I can just update my config with that. (And my config is in a git repo; whereas "what changes I made" is not).
There are certainly significant drawbacks, sure; but I think the main decider between whether it makes sense is how appealing "take the time to write a config with changes" is vs "just run the command / edit the system file" is.
I had a windows machine that had outlook on and such and then a VM that was nixOS and i did all my dev work in it.
It was super nice to have everything configured in a single file that specified every detail of the OS. But some things were super hard (writing my own packages) and I slowly moved on.
I use it everywhere. Daily driver, VMs, and servers. I think it more than makes sense to use it this way. When I want to try to use some software I can checkout a new branch and try it out. If there are issues I can just revert back and everything is normal.
You've probably heard about this before and didn't realize it. Did you watch Training Day? That whole movie was centered around the leader of a cop gang.
Den of Thieves as well. In that movie they're actually doing their job as police but they're clearly a gang within the police force who routinely break the law and abuse their position for personal gain. They even very clearly describe themselves as a gang in one scene.
Docker on an M1 Mac is inconsistent too. Generally it works fine but not always. It uses qemu and doesn't always surface qemu errors when you're building images (you can see the errors when you're running containers, so less of a problem there). They complete build "successfully" and look like valid images when they aren't. I've had multiple k8s deployments fail locally on minikube and on GKE/EKS because of bad images built by Docker on my M1 Mac. The solution is generally rebuild until it works or use my 10 year old Intel-based Mac, but those are bad solves.
Docker shouldn't be charging anyone for that inconsistent experience.
So they're definitely in the space (I just read a fantastic rust post on there[0] today, thanks to This week in rust[1]) but you can't beat the staying power/massive bags of money/developer goodwill that is already heaped on Github. Github entering this space would be a death sentence for a site like dev.to, unless they massively fuck it up (or dev.to adapts and provides some extra value-add/integration).
imho it looks like dev.to is a cross between twitter and a full blog (seeing it for first time today). Github readme looks more like a magazine where the content is curated.
The difference between user generated content and curated content is a big enough differentiator that I don't think it'd be a death sentence.
