Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

Post reply on HN
Print view View original

401–410 of 458 posts

Re: Systemd, ten years later: a historical and technical retrospective

#401

Post by the_why_of_y »

lmm wrote: post #196
cycloptic wrote: post #177

Earlier quoted context omitted.

This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd. So…

> This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. It's like saying that windows programs work on Linux, you just have to use wine - it's sort of true for now, but it's not something you can rely on. > And, there were valid technical reasons to have gnome depen…

> elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility.

That's because elogind is architecturally all wrong - instead of sticking to the defined stable public DBus interfaces of systemd, and implementing those independently from scratch, what they did was rip the implementation of systemd-logind out of the systemd package and hoping that the intentionally unstable internal interfaces in libsystemd that it relies on will continue to be provided.

> Gnome worked fine long before systemd and systemd has not noticeably improved it (if anything the opposite); there was no technical consensus that the current hard-dependency was necessary

There was a very, very simple reason for why Gnome depends on systemd-logind: nobody volunteered to maintain the ConsoleKit backend, or ConsoleKit itself for that matter, so it bitrotted and was eventually removed.

Re: Systemd, ten years later: a historical and technical retrospective

#402

Post by Supermancho »

Supermancho wrote: post #106
xani wrote: post #23

Earlier quoted context omitted.

Pretty much. If it was just some guys project nobody would give a shit until it was actually well tested and proven. But it was made by guy hired by Red Hat so instead of maturing and having to take actual user feedback before being used in anything significant it was pushed by a guy that vision is limited to "It works fine on my laptop". Who then decided to reinvent everything along the way like log storage that sti…

> you can have fun evening inventing your own shitty binary journal format. I thought the reasoning was to make logs harder (or impossible) to tamper with. Something something about trading freedom for security.

> https://lwn.net/Articles/512895/

the binary logs handled by the systemd journal can be "sealed" at regular time intervals. That seal is a cryptographic operation on the log data such that any tampering prior to the seal can be detected.

This might be news to some people.

Re: Systemd, ten years later: a historical and technical retrospective

#403

Post by SSLy »

AsyncAwait wrote: post #354
nlgza wrote: post #342

Earlier quoted context omitted.

RedHat has several people who take over projects and rewrite everything they see, with little or no benefit other than getting a high commit count.

Any examples?

Don't except a reply from a systemd hater's sockpuppet (nlzga was created just for this thread to shill FUD.)

Re: Systemd, ten years later: a historical and technical retrospective

#404

Post by rurban »

realusername wrote: post #136
theamk wrote: post #129

Earlier quoted context omitted.

You don't want to use sqlite for logs -- it is way too complex, and in particular, it may roll back (=lose log entries) if it is low on space, and permanently damage data when writing onto disks with errors. It also makes wrong performance tradeoffs for logging -- your choices are either sync() all the time, or roll back on unexpected termination. I don't like the that journald goes backwards in space and updates ind…

Sqlite is battle-tested though, it has one of the most comprehensive test suite and is used on billions of devices already. What systemd is doing with this log storage system is reinventing sqlite, because systemd has a fairly new and not battle-tested database implementation, it has shortcomings. I would argue that either they use plain text logs like before or use sqlite but they should not reinvent a new db.

sqlite is a dirty hack. just because people like hacks doesn't mean it's ready for the serious stuff. it is not. https://research.checkpoint.com/2019/select-code_execution-f...

Re: Systemd, ten years later: a historical and technical retrospective

#405

Post by dane-pgp »

theamk wrote: post #347
kelnos wrote: post #205

Earlier quoted context omitted.

GNOME, essentially. If you want to run a fully-functioning GNOME on your distro, you have to be running systemd. Or have the time and patience to maintain a large patch set to work around the systemd dependencies.

This became this way only once systemd has won. At least during Debian systemd debate, both sysvinit and upstart could run Gnome just fine. (also, what were the alternatives? I don't run GNOME myself, but given what GNOME wants do to, it does need a solid session management. I have seen ConsoleKit, it was worse than systemd.)

Debian's tech committee had their infamous vote about the default init system for Jessie in February 2014. Earlier, in October 2013, Josselin Mouette, a GNOME packager for Debian, wrote this:

"GNOME in jessie will need systemd as the init system to work with all its features, just like it needs the network configuration to be handled by NetworkManager."

Re: Systemd, ten years later: a historical and technical retrospective

#406

Post by yawaramin »

hedora wrote: post #62
yawaramin wrote: post #33

Earlier quoted context omitted.

That thread also mentions the solution that will work: https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen

Why should I be forced to prepend all of that to every command I want to survive terminal hang ups? The old mechanism was more user friendly, and better documented. It’s just another example of systemd making everything on the system worse.

You could alias the command. You distro could do it for you. Or your ops person could. There are plenty of points where this could have happened.

Re: Systemd, ten years later: a historical and technical retrospective

#407

Post by yawaramin »

MereInterest wrote: post #61
yawaramin wrote: post #33

Earlier quoted context omitted.

That thread also mentions the solution that will work: https://askubuntu.com/a/904125 I.e., systemd-run --scope --user screen

I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon…

I'm actually very happy they chose to break this particular behaviour, based on their explanations about security and not allowing long-running services to hog up a machine when its user isn't logged in.

Re: Systemd, ten years later: a historical and technical retrospective

#408

Post by wrycoder »

kelnos wrote: post #198
wrycoder wrote: post #85

Earlier quoted context omitted.

Devuan.org

I still don't entirely get the point of Devuan. I put Debian buster on a low-RAM embedded box, and since systemd eats up precious RAM I'd rather keep, I just switched to OpenRC with apt install openrc && apt purge systemd If I needed it, Debian packages elogind as well. Rebooted and it worked perfectly. Now, I get that Debian doesn't really support OpenRC[0] (or sysvinit), and it could break in horrible ways when bul…

Late reply, sorry.

The problem isn't systemd's init. It's probably fine.

The problem is the systemd project is taking over the userspace with mutually cross-linked modules.

Devuan was started by a group of Debian maintainers who disagreed with the direction systemd was taking Debian.

Re: Systemd, ten years later: a historical and technical retrospective

#409

Post by sjwright »

sjwright wrote: post #373
zeveb wrote: post #320

Earlier quoted context omitted.

> And that was one of the sillier holy wars, since text editors have near-zero network effects and it's trivial for distros to ship both. Text editors like vi may have near-zero network effects, but operating systems like emacs and vim have plenty of network effects. If I spend months building an amazing interface to git in Emacs but my colleague uses vim, our organisation is hurt. That's (I think) why people care: t…

I’m mostly kidding about nano, I only use that when I have to. My main editor is HomeSite+ 5.5 running on Windows XP in a virtual machine on my Mac. And I’m not kidding.

Oh and by the way it starts faster and uses less RAM than Eclipse. That's fucked up.

Re: Systemd, ten years later: a historical and technical retrospective

#410

Post by dijit »

BiteCode_dev wrote: post #232
gorgoiler wrote: post #119

When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules. What’s much harder is (1) to expand ones code without coupling everything together (2) present it in a persuasive way that naturally builds a user base. SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to…

> SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell. I've seen this scenario played out, and it always fails. The product never ships, of ships in such a bad shape the users have a terrible user experience. That's not what happened with systemd. It shipped. And after a few iterations, it…

> Well, I don't care for choice in my init system. I want it to work.

We Agree.

> And systemd works fine for me.

But it doesn't for me, and I am left with no choice but to suffer with it.

Post reply on HN