systemd 250 Is Coming For Christmas With A Boat Load Of New Features

[er888kh]

I am fine with systemd to start daemons/software and a centralized log, even timers to substitute cron.
Everything else I did not use and intend to never use it, especially on servers.

The problem is not with the tools themselves, the fact that they are prefixed with the same name and are maintained in one place is what concerns most people. In fact, I kind of prefer their programs over older alternatives in some situations. They have more similar cli inferfaces and config files, and everything is (or can be) organized rather cleanly in a single directory under /etc .

For example, I use systemd-networkd on my servers, as it uses less time on reboot than NetworkManager (due to having a faster "wait online" service, at least in my case). In addition to that, I use systemd-resolved, because it just works and can be easily configured to do DNSSEC/DNS-over-TLS.

[chuckula]

We are the systemd. Lower your firewalls and surrender your inits. We will add your operational and technological distinctiveness to our own. Your distribution will adapt to service us. Resistance is futile.

No, Resistance is Voltage divided by Current.

[caligula]

I am fine with systemd to start daemons/software and a centralized log, even timers to substitute cron.
Everything else I did not use and intend to never use it, especially on servers.

This will also be bloated on desktop. Imagine having a custom 512 byte mbr bootloader that can boot the kernel from a static disk sector right after fat tables. Booting a custom kernel with no module support, ram support up to 4GB, no bloated crap drivers like virtualization or iommu. Only necessary drivers such as 16 bit Sound blaster built in. No logging at all. Launches busybox sh and runit. Only ext2 support required for disk access. X11 vesa driver and dwm desktop. Busybox shell, suckless terminal. Gnu bloat replaced with bsd heirloom. A paradise.

[arokh]

This will also be bloated on desktop.

No it won't.

Imagine having a custom 512 byte mbr bootloader that can boot the kernel from a static disk sector right after fat tables. Booting a custom kernel with no module support, ram support up to 4GB, no bloated crap drivers like virtualization or iommu. Only necessary drivers such as 16 bit Sound blaster built in. No logging at all. Launches busybox sh and runit. Only ext2 support required for disk access. X11 vesa driver and dwm desktop. Busybox shell, suckless terminal. Gnu bloat replaced with bsd heirloom. A paradise.

What exactly is stopping you from building it, and what does it have to do with this topic?

[abu_shawarib]

systemd-creds seems interesting, will try to check it out.

[bug77]

We are the systemd. Lower your firewalls and surrender your inits. We will add your operational and technological distinctiveness to our own. Your distribution will adapt to service us. Resistance is futile.

That's funny.
However, resistance is not futile. As soon as something better comes along, distros will migrate again. For all its shortcomings, systemd is now everywhere because it actually solves a lot of problems in initv. And there was (and still isn't) anything that solves the OS init problem better than systemd.

That being said:

The default maximum number of inodes has been raised from 64k to 1M for /dev and from 400k to 1M for /tmp.

When did that end up in systemd? I thought inodes were an ext "feature".

[uxmkt]

When did that end up in systemd? I thought inodes were an ext "feature".

It's a mount option. And systemd is in charge of tmpfs mounts like /dev and /tmp.

[arQon]

For example, I use systemd-networkd on my servers, as it uses less time on reboot than NetworkManager (due to having a faster "wait online" service, at least in my case).

Why on earth are you putting a network dependency in your boot at all? That kind of crap is the *last* thing I want on any of my servers (*especially* with systemd's permahanging buggy timeout code).

> In addition to that, I use systemd-resolved, because it just works

That hasn't been my experience, but it's nice to know it's apparently improving. Does it resolve in the correct order now, or is that still broken?

[Anvil]

any chance systemd-boot could replace Grub2 in Fedora 36 as default ?

[ehansin]

any chance systemd-boot could replace Grub2 in Fedora 36 as default ?

Someone shared some links recently regarding this. Sounds like a no-go for now. I cannot remember the links, but off the top of my head I remember some of the issues went like...

* GRUB2 can support both EFI and legacy BIOS (systemd-boot is EFI only.)
* GRUB2 has support of bunch of different filesystem types in can boot off of (systemd-boot can only support FAT32, though there was mention that maybe someone in time could migrate the GRUB2 support drivers over.)
* With Fedora having multiple kernels installed at the same time, it is easier for some reason (I know Fedora stores all that in /boot, and then mounts the EFI partition as /boot/efi, at least that is what I did for my dual-boot, which btw means I have more space for kernels and do not fill up EFI proper.)
* Questioned also was if Fedora could support both, which it was mentioned for now would just be additional possibilities of failure and/or QA complexity (because supporting both GRUB2 and systemd-boot) so not currently being considered.

There could be more and I could be slightly off, just off the top of my head what I read. I have used systemd-boot on a minimal Arch install and liked it. Would love to use in Fedora. In fact, currently running a minimal Fedora install as I wanted to be more "red hat centric" at home given we use some RHEL where I work.