> systemd is a monstrous codebase and there lies shitload of exploits in it. Either intentional or accidental.
And yet...
1. practically all hyperscalers use it
2. desktops
3. container images, that power everything from docker to kubernetes use it
It helps that it's actively maintained, battle-tested as hell, and widely audited.
Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack.
> It helps that it's actively maintained, battle-tested as hell, and widely audited.
Is it actually audited? Or is it like OpenSSL... everybody uses it, but nobody looks under the hood cause it's gross in there? (Or well, nobody looked before Heartbleed anyway)
And it runs as PID1 on many distros and these are folks like RHEL, who have a huge interest in keeping it secure.
Pypi has an almost daily exploit announced in common and popular libraries, simply because the dependency graph is so huge. And this is in things that are almost certainly deliberately and by design exposed to insecure user input.
Again, it’s fun to hate on systemd, but in reality you are much more likely to be exploited by something else.
> Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack.
Can you even imagine pypi or npm compromising ssh this way?
> Can you even imagine pypi or npm compromising ssh this way?
Is ssh somehow sacrosanct in a way that any other RCE or credential stealing attack is different?
I don’t even know the last time I exposed ssh to the open internet.
But the fact with npm or pypi you can be exploited just by running the software you’ve already installed because the dependencies are everywhere on your system?
> Is ssh somehow sacrosanct in a way that any other RCE or credential stealing attack is different?
I see ssh as a very fundamental part of the system - in BSD terms it's in base not ports. Random packages from npm or pypi, sure, if you installed some slop off the internet and got exploited that's not so surprising. (Even those package managers themselves are not part of the base system, much less anything you install with them). But ssh should be safe!
I’ve never understood the gatekeeping people wrap around kubernetes.
Even with small 3 node cluster of of raspberry pis, you can run anything you can run in simple docker, and have it survive outages/reboots/etc.
At home, I have a few raspberry pis, orangepi RV (riscv nodes), and my main nodes are large high core and RAM VMs running on Proxmox.
Each one has different capabilities. Some have lots of fast storage attached for longhorn, some have 10Gb/25Gb networking, etc.
And the great part is if I wanted to collapse down to just the SBCs? I would just need to scale down some replicas of high men or high cpu stuff I’m testing.
Of course at job, I just pick the node shape and capabilities I need and don’t think about it.
Yeah, I’m probably the exception for running kubernetes at home, but I would argue if you are running more than a handful of docker containers, you should probably be using kubernetes anyway.
Especially if you care about things being up, or want to be able to seamlessly shuffle stuff around for maintenance. Not to mention my entire infrastructure is repeatable with just a small git repo of fluxcd stuff
I'm not personally trying to gatekeep kubernetes, everyone should do what works for them. However, if I'm putting my professional credibility and/or my sleep schedule on the line, I would not advise anyone to do this.
Even at home, I run stuff that needs to be highly available enough that I wouldn't go this route when there are better options.
Okay, well you’ve still not highlighted was is the preferred method here, since even with a 42u rack and a cluster in GCP, you still wouldn’t run kubernetes
At least for SBCs, I’ve bought a few orange pi rv2s and r2s to use as builder nodes, and in some cases they are slower than the same thing running in qemu w/buildx or just qemu
There’s more to Docker Desktop than just “oh it’s just docker underneath”
1. Unified experience across Windows, Mac, Linux
2. The security posture is much stronger by default. Many people, who would probably be considered the “target audience” for Docker Desktop, don’t bother to make docker-ce rootless, or don’t use podman, so running it in a VM is better, though admittedly often annoying.
3. Not everybody is a CLI warrior. Docker Desktop gives a decent GUI, ways to monitor and control containers visually, and even deploy kubernetes with a single click.
“Inferior technology stack”. Didn’t I just read a few days ago about pf queues just now breaking 4Gbps? Look me up, I’ve written a lot about high speed networking.
How are those containers working out for you? Have you heard about these things called VMs? Which I moved on from like 8 years ago?
Not to mention ole Theo likes to alienate you folks at every possible opportunity, even when it doesn’t matter to the core philosophy of openbsd.
I mean, you do you, but at least demonstrate an ounce of intellectual integrity about it.
Containers are a joke compared to Plan9 namespaces, and docker just solves a GNU/Linux problem with itself and the zillions of incompatible distros.
FreeBSD has jails and Docker it's something laugable because with FBSD you just install the compatNx libraries and everything from version 4 and up will run as is.
And in any case you set a jail with these libraries and everything would run in a much secure way than docker defaults.
Seriously, can't even you see that Docker it's a problem written as a solution to another problem?
Kinda like NPM+Yarn+$package-package-manager of the day to solve the problems the whole ecosystem and the so-called solutions creates twice. Wake up.
Not GP, but I'm running OpenBSD on a laptop, not in a datacenter. I have a small Alpine VM that I often forget about. I also have Debian 12 on a Mac Mini and while it's systemd, it could be OpenRC for all that I care about it.
I can see a case for systemd on a server, but have never seen the point on user-facing distro.
And yet...
1. practically all hyperscalers use it
2. desktops
3. container images, that power everything from docker to kubernetes use it
It helps that it's actively maintained, battle-tested as hell, and widely audited.
Point being, it's fun to hate on systemd, and maybe even hipster-like, and systemd is hardly perfect... but you are probably more likely to be exploited by a pypi or npm supply-chain attack.
reply