Not in my experience. I've run both Windows and Linux for the last decade and Windows is the only OS that I ever have problems with updates wasting my time and breaking things. I've been running image-based Linux for the last two years and the worst case is rebooting to rollback to the last deployment. Before that it was booting a different btrfs snapshot.
Fun aside: I had a hardware failure a few years ago on my old workstation where the first few sectors of every disk got erased. I had Linux up and running in 10 minutes. I just had to recreate the efi partition and regenerate a UKI after mounting my OS from a live USB. Didn't even miss a meeting I had 15 minutes later. I spent hours trying to recover my Windows install. I'm rather familiar with the (largely undocumented) Windows boot process but I just couldn't get it to boot after hours of work. I just gave up and reinstalled windows from scratch and recovered from a restic backup.
My servers are pets not cattle. They are heterogeneous and collected over the years. If I used k8s I'd end up having to mostly pin services to a specific machine anyway. I don't even have a rack: it's just a variety of box shapes stacked on a wire shelf.
At some point I do want to create a purpose built rack for my network equipment and maybe setup some homogenous servers for running k8s or whatever, but it's not a high priority.
I like the idea of podman-systemd being an impl detail of some higher level orchestration. Recent versions of podman support template units now, so in theory you wouldn't even need to create duplicate units to run more than one service.
It works pretty well. I've also found that some AI models are pretty decent at it too. Obviously need to fix up some of the output but the tooling for conversion is much better than when I started.
I've run my homelab with podman-systemd (quadlet) for awhile and every time I investigate a new k8s variant it just isn't worth the extra hassle. As part of my ancient Ansible playbook I just pre-pull images and drop unit files in the right place.
I even run my entire Voron 3D printer stack with podman-systemd so I can update and rollback all the components at once, although I'm looking at switching to mkosi and systemd-sysupdate and just update/rollback the entire disk image at once.
The main issues are:
1. A lot of people just distribute docker-compose files, so you have to convert it to systemd units.
2. A lot of docker images have a variety of complexities around user/privilege setup that you don't need with podman. Sometimes you need to do annoying userns idmapping, especially if a container refuses to run as root and/or switches to another user.
Overall, though, it's way less complicated than any k8s (or k8s variant) setup. It's also nice to have everything integrated into systemd and journald instead of being split in two places.
Oh yeah I agree. There's a lot of fun problems to solve with Minecraft servers. I didn't mean to imply that there are no reasons for good chunk gen. I'm primarily into technical survival so my personal priorities wouldn't be chunk gen.
Chunk gen makes sense to implement last or never. If you want a performant Minecraft server you need to pregen all the chunks anyway. You can still later regen chunks that have never been visited to get new chunkgen on updates since chunks store the inhabited time.
I think Minecraft server re-implementations are pretty neat and I like to see when a new one comes out. There are also specific purpose server impls like MCHPRS for doing fast redstone compilation for technical minecraft.
Another advantage of printed parts is it's easy to use alternative part designs. There are lots of variants on the standard parts that you most likely will start replacing stock parts with as soon as you get addicted.
I really like Silverblue and run it on a couple of secondary machines (like in my workshop), but it’s still rough for anything off the beaten path.
The largest pain points for me:
- Any kernel modules. I know Ublue has images but I wish Red Hat would just have an official solution that doesn’t require hacky RPMs and such.
- Kernel cmdline args or any initramfs changes: can’t package in image and need to be applied manually. Maybe it’s possible to build a custom initramfs to distribute?
- Secure boot and enrolling moks is very annoying. My current workstation just uses sbctl to sign a UKI against custom keys and everything “just works”. This is part of why kernel modules are a pain in Silverblue too.
If you don’t care about kernel modules with secure boot it’s quite nice though. Practically zero maintenance.
1 Gbps is nice when downloading games and updates. Since everything is digital it can be the difference between waiting 30 minutes or 3 hours. IE: You play a game the night it's released/updated or wait until after work the next day.
Upload speed probably makes more sense for more use cases though. I used to have symmetric 1Gbps fiber and never bothered to setup QOS as my upload was never saturated.
I moved and am stuck with "1Gbps" Comcast. Which really means 25Mbps upload. I had to setup qdiscs on my gateway and split my network into tiers to get acceptable upload speeds and latency for the workstations in my home. I maybe have more uploads than 'normal' people, as I have automated backups that store data off-site, but normal people have "backups" in the form of cloud storage I think.
Uploading videos (to YouTube, for example) is painfully slow. I'm simulating living in Australia when I upload a video.
Linux is about as consistent as Windows these days. /etc isn’t really a “dumping ground” for everything and is quite static now. Just diffed a snapshot of /etc on my workstation from a month ago and there aren’t really any changes I didn’t put there myself. It’s reasonable to make /etc immutable on a lot of systems; something impossible with the registry.
Home is a bit more chaotic but most applications follow the XDG specs. Mostly. Less so with cache and state files (vscode, for example, dumps tons of cache/state files in .config instead of .cache and .local/state). And weird things like Flatpak shoving everything in .var.
I’d say things generally behave about as well as windows apps which often treat documents as a dumping ground for all kinds of files. I always have to go to pcgamingwiki to find game data locations without having to check half a dozen places.
For administration I really like the /usr and /etc divide. Vendor files go on /usr, and overrides for the running system in /etc. It’s useful to be able to peek in /usr to see defaults.You don’t really get that ability with the registry. With some more modern setups /etc is bootstrapped from /usr (for example, with systemd-tmpfiles) and you can “factory reset” a system by clearing out /etc (with some asterisks around restoring state for a few of the legacy state files still kept in /etc if the system is has manually created users/groups).
The article title is very misleading. This isn't bypassing FDE in any way. It's just getting a root shell on a machine you have physical access to with a particular boot configuration.
Clever? Yes. But no encryption is bypassed.
Most systems will only be listening to PCR 7 anyway, so a similar attack could be done by loading your own custom bootloader, or possibly reading messages on the SPI bus when booting. This is just a nice trick that's easier/faster.
There is a balance of convenience versus security and this could be prevented easily by disabling recovery shell or registering more PCRS (with correct boot setup), but would be much more annoying to remotely administer since you could get failure states where the TPM won't release the keys in a variety of situations.
Ultimately TPM-only unlock is a significant increase in security vs unsophisticated attackers and probably fine for 99% of people, but isn't something to rely on if you are concerned about sophisticated attackers.
Even with perfect PCR setup and enrolling only custom keys in UEFI, a running machine is still vulnerable. Cold boot or DMA attacks (Thunderbolt or PCI) are just a few that come to mind. These sound extremely sophisticated but are easily done even with hobbyist equipment. Any running machine with currently unlocked disks should be assumed to be possible to compromise with physical access.
Most people don't realize how dangerous automobiles really are. Accidents are one of the leading causes of death in the US until people get to be 45+ and cancer starts overtaking it. Even in 2020-2021 CDC data that probably has less people driving than usual: https://wisqars.cdc.gov/data/lcd/home. One thing I liked about living in a city was being able to walk to work. I'm reluctant to work anywhere I have to commute because the last few years have likely significantly reduced my chance of accidental death purely due to remote work.
In some ranges it's the leading cause, although overdose deaths sometimes win out. It's kind of absurd that this isn't brought up in articles about remote work. Newspapers run articles about gun violence every day despite it being wwaaaayyyy less likely than dying in an automobile accident, but the far greater danger of commuting is almost never discussed.
They're often used in Entity Component System architectures since you have O(1) add/remove/find, & O(n) iteration. Iterations are also packed, which is a bonus for cache efficiency.
Can be difficult to implement well, but the concept is simple and a neat example of a useful specialty data structure. Take a look at https://github.com/skypjack/entt
Fun aside: I had a hardware failure a few years ago on my old workstation where the first few sectors of every disk got erased. I had Linux up and running in 10 minutes. I just had to recreate the efi partition and regenerate a UKI after mounting my OS from a live USB. Didn't even miss a meeting I had 15 minutes later. I spent hours trying to recover my Windows install. I'm rather familiar with the (largely undocumented) Windows boot process but I just couldn't get it to boot after hours of work. I just gave up and reinstalled windows from scratch and recovered from a restic backup.