Systemd, 10 years later: a historical and technical retrospective

The problem is that no one, not even those of us who spend excessive time here, sees every thread or even every major thread. HN's front page is a tiny aperture given the firehose that flows through it. We added 'past' to the top bar a few years ago to give people a way to catch up on the biggest threads they missed. Unfortunately relatively few people use it. For example, this month about 4% of logged-in users who've viewed the front page have also used 'past'.

One thing people often don't realize: socket activation wasn't just about simplifying daemons (though it does simplify writing daemons if you don't have to deal with the non-activation case). It was also about simplifying the boot process.

There exist many different system boot configurations that are difficult to express in terms of dependencies between services; for instance, depending on your particular system configuration, you might need to launch two services in different orders, because in one configuration service A will depend on service B, and in another configuration service B will depend on service A. Socket activation means you can launch the two services simultaneously, and they'll have access to each others' sockets.

I think you're off-base on this. Work is being done to get support for cgroupsv2 in all the major container runtimes. Source: https://medium.com/nttlabs/cgroup-v2-596d035be4d7

In any case single-writer was not an explicit goal of systemd, it was an intentional design decision that came from the kernel. TFA even mentions this, although it is somewhat lost within the pages of ranting. You also don't even have to use systemd's D-Bus APIs to deal with this. Container managers can if they want to provide additional integrations. Source: https://systemd.io/CGROUP_DELEGATION/

"Well, it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so.

"Due to that our plan is to enable all this by default in "make install". Packagers may then choose to disable it by doing an "rm" after the "make install", but we want to put the burden on the packagers, so that eventually we end up with the same base system on all distributions, and we put an end to senseless configuration differences between the distros for the really basic stuff.

"If a distro decides that for example the random seed save/restore is not good enough for it, then it's their own job to disable ours and plug in their own instead. Sooner or later they'll hopefully notice that it's not worth it and cross-distro unification is worth more."

[1] https://lists.freedesktop.org/archives/systemd-devel/2010-Se...

And I still have to to run rsyslog to send things off-machine to a centralized logging server.

I would prefer a voting-up only option, else the down-voting option gets abused.

This one did though: https://news.ycombinator.com/item?id=23062072. In such cases we add [dupe] at the top and bury the thread. That's not because we think it's a bad article or a bad thread! It's because front page space is the scarcest resource HN has (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...) and curiosity withers under repetition (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...).

First, the URLs are perfectly identical minus the filename. You could compare paths, minus query string and filename, and that would give you a rough score of likely similarity for further checking. There would be false positives for sites that use the query string as part of their navigation the way HN does.

Then, you could test the social media meta tags (particularly title and author, if it's there), and a hash of the body text (normalized, all lowercase, etc.) for similarity to other possibly similar submissions.

Dupes could be automatically marked as such or flagged for review.