SystemD fundation basement was a Linux implementation of the MacOS LaunchD. It was a step forward over the traditional init managers, but in any case disruptible over something new, because an equivalent design was running on Apple devices time before.
Systemd 252
131–140 of 317 posts
Re: Systemd 252
#132Earlier quoted context omitted.
You do understand how Hacker News voting works?
Yes. Clicks on the voting arrows go to the HN backend, which routes them to systemd-votecount, which then generates article rankings and publishes them over D-Bus, from which the backend picks them up and renders them as HTML.
You, kind person, have won the Internet.
Re: Systemd 252
#133Earlier quoted context omitted.
I've developed a distrust for anyone who hates on systemd in 2022, especially if their rationale is vague dogma like "it does more than 1 thing, it's not Unix-like!" It's usually a signal that the person is not a practioner. Systemd is the most important and well-developed Linux framework, besides the Linux kernel itself.
I mean have you actually used the alternatives? I find most of the people with that opinion are young pups who jumped on the linux train after most of the systemd bugs have been ironed out, but who still have zero experience with the alternatives.
I have used all the alternatives, and written my own init systems from 0.
Systemd is really well designed and makes Linux workstation use predictable and more secure across distros in numerous ways. You can have any service you want now, even xorg/ wayland, as an unprivileged user. It basically removes all need to use root if used correctly.
Systemd however is however not designed for server use, but neither is OpenRC or any of the alternatives. Servers filesystems should contain a kernel, a shim init binary, and a static binary for a target service.
When you want to upgrade your fleet you compile a new bundle of those three things into a new filesystem image and boot servers from the new image.
Re: Systemd 252
#134About removing support for what they call split-usr and unmerged-usr: Why does a init system and daemon manager even need suppport for a certain directory layout, shouldn't it be agnostic? Having a separate usr-space saved my bacon in the past a couple of times. The thing I dislike most about Systemd is that it leads to homogenisation, where to me, running Linux is about choice.
The kernel initramfs only mounts the root partition - parsing fstab and running mount is handled as part of init. This means that an init system needs to support split-usr by ensuring it can go without the contents of /usr at least long enough to bootstrap (which requires special treatment of the mounting scripts/units) or else avoid using /usr at all
Re: Systemd 252
#135Earlier quoted context omitted.
Being able to boot a server with a 'live USB image'; mount root, and inspect the logs to see what happened are not possible when you got a binary blob for a log. When things have really fucked up, you need the 'ease of access that plain-text log files provides.
If your live USB image is from this decade, it will almost certainly come with journald for reading the logs. If it doesn't, why choose such a bad live USB image?
Just nitpicking, but AFAIK it's not journald which is used to read the logs, it's journalctl itself which directly reads the binary logs from the filesystem (and the normal filesystem ACL permissions are used to allow or deny reading the logs).
Re: Systemd 252
#136SystemD fundation basement was a Linux implementation of the MacOS LaunchD. It was a step forward over the traditional init managers, but in any case disruptible over something new, because an equivalent design was running on Apple devices time before. http://0pointer.de/blog/projects/systemd.html
launchd or perhaps, more likely, upstartd.
Re: Systemd 252
#137Earlier quoted context omitted.
I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important. Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.
There are solid technical reasons for systemd's binary logging. The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones. Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can…
For me, the nice things about the systemd journal binary log format are:
- It's immediately compressed (without having to wait for a log rotation);
- It automatically rotates when a size limit is reached (no risk of filling the disk with logs);
- IIRC, it's deduplicated (repeated messages use less disk space).
All of these together means logs can be kept for much longer by default.
Re: Systemd 252
#138Earlier quoted context omitted.
Alpine linux seems to be doing fine without systemd.
alpine linux is a minimalist distro intended for running a single process within a container. I guarantee the base OS the container is running on us running systemD.
No: "Alpine Linux is an independent, non-commercial, general purpose Linux distribution designed for power users who appreciate security, simplicity and resource efficiency."
Re: Systemd 252
#139I love systemd for everything except its cron replacement, somehow it's a real mess. Yet I desperately want something more modern to play with journald well. Any advice?
I think generally people view timers as a net superior alternative to crons: they have better logic for the times, they support dependencies, they support randomized delays, etc. Why do you think they're a real mess?
I guess their UX for a simple cron-like use-case. I remember trying to set it up and it wasn't a great experience. Just trying to see if others agree or not.
Re: Systemd 252
#140I love systemd for deploying Golang, especially the security features, that systemd can own the TCP port for zero downtime deployments of the application and restarts of a fail-fast application. It kind of replaced Docker (dockerd) which I've used with deploying Scala and TS.
Hey, someone rediscovered xinetd
>Hey, someone rediscovered xinetd
With a much better piece of software, exactly.