A systemd appreciation thread

7 replies [Last post]
Kiki_the_Cyber_Squarrel
Offline
Joined: 12/02/2024

Thank you to the libre software systemd-timesyncd (available in Trisquel repositories) for automatically fixing the time on my machine. My computer is an old model where the CMOS battery is already dead so my computer can't reliably store the current time, so it's very sweet that systemd-timesyncd fixes the time on my machine.

In the past I was instead using another program for automatically setting the time, but I've found that systemd-timesyncd seems to work MUCH more reliably for setting the time as it automatically updates the time some time after resuming from hibernation, unlike the other solution where the time would remain incorrect after resuming from hibernation and it wouldn't automatically be fixed. GNOME has systemd-timesyncd integration so I'm not sure if this is my GNOME Flashback desktop using systemd-timesyncd to fix the time after resuming from hibernation or if it's systemd-timesyncd acting on its own.

One of the things I like about systemd is that it's like Emacs, a "does-everything" program.

andyprough
Offline
Joined: 02/12/2015

I appreciate the fact that systemd is now a standard that has allowed a lot of software developers to bring their software to be able to be used with GNU/Linux.

What I do not appreciate is that systemd is currently running 7 different processes on my system, using over 33MB of ram. And that journald is always the biggest offender. Why does a logging process need to be constantly using nearly 20MB of ram? I've tried to reduce journald's functions and to disable it altogether, but like a zombie it always crawls back out of the grave. And my complaint is not aimed at Trisquel - I've noticed that Trisquel has one of the smallest systemd resource footprints among distros. So the Trisquel devs are doing systemd right. It's just that systemd itself is constantly bruising my minimalist sensibilities.

But, other than being a resource hog, it seems to do its job alright. So I appreciate that. Happy holidays systemd.

Kiki_the_Cyber_Squarrel
Offline
Joined: 12/02/2024

I see your concern, but the way I see it even older computers like mine still have more than enough ram to run a Trisquel installation with systemd and other "heavy" utilities: Take me for example, my computer (Dell Latitude E6400, the canoebootable kind with Intel graphics ( https://canoeboot.org/docs/install/latitude.html )) has a bit less than 4 gigabytes of ram, about 3800 MB I guess, and it is an older device, a 2009 model, nowadays available for low prices, it was pretty powerful for its time but nowadays some consumerist people who don't appreciate old freedom-friendly canoebootable devices such as these consider it "obsolete", yet my computer still has more than enough RAM for running many heavy complex programs at once, I'm in GNOME Flashback right now running an Emacs session, and a torified Emacs session being run under this Emacs session, and I have two big web browsers open right now, and I often have many tabs open at once, though with JavaScript disabled. I'm also connected to an IRC server with the IRC client "ERC" for Emacs, connected to two channels and with "dictd" running so that I can access dictionary through Emacs, also with other daemons such as tor, systemd, etc. Yet, despite all of this, I still have generally have over 1 GB of ram to spare. I'm living in a luxury where even having many complex programs (such as Emacs) open at the same time still leaves me with a high amount of RAM to spare, and this on an old 2009 model that can be found for relatively low prices online. I don't think systemd's 33+ megabytes of used RAM are too big of a deal, in my opinion. GNU/Linux seems to be quite friendly to older computers, even on heavier environments such as those using full Desktop Environments and/or GNOME the RAM situation is quite good even on older computers.

andyprough
Offline
Joined: 02/12/2015

As I said, it offends my minimalist sensibilities.

Zoma
Offline
Joined: 11/05/2024

Truthfully, I don't appreciate systemd much either, but I am actually impressed of how well systemd works on my pocket mnt reform device.

I thought it would be a 15 second boot and it would eat cpu power up like a lot.

My device has an unfortunate boot blob needed of some sort, so linux-libre wont run on it.

This being said, I removed all the other blobs including wifi. I likely will only connect it to ethernet. That works without blobs.

My point being, I guess, despite by disdain of systemd, I am surprised it doesn't make ARM64 move excessively slow.

I do wish I could run devuan on my pocket mnt reform or not systemd on debian. This however is no, because systemd is a dependency of mnt reform tools which is needed to use that computer. So... there's that. lol.

Anyways, that is my thoughts.

If I was constantly connected to wifi, I might care more, but nope. That needs a blob lol.

andyprough
Offline
Joined: 02/12/2015

systemd is a small bit slower to boot, but not clearly slower to do most other things in my experience. Unless you compare it to s6, which is freakishly fast. Especially systemd the way the Trisquel devs have set it up seems to have everything running at pretty much normal speed.

Kiki_the_Cyber_Squarrel
Offline
Joined: 12/02/2024

> My device has an unfortunate boot blob needed of some sort, so linux-libre wont run on it.

I have empathy for you and am deeply sorry about your suffering, I apologize for the fact that your device requires a freedom-denying blob.

Zoma
Offline
Joined: 11/05/2024

It least that is the only blob I need no matter what. Thankfully I plan to only connect that device to internet when I actually need something.

Otherwise, just using it for music (if I can get it working 80+% of the time)

Or novelwriter which I will likely use it for whenever I feel like.

:)

Long story short, wifi blob? no. hdmi blob? no.

Just the boot blob which is probably harmless as long as you aren't connected to the internet and maybe it might be harmless in general, I don't know. ARM64 tends to have less backdoor stuff than x86 I hear.