
Systemd, 10 years later: a historical and technical retrospective - donmcc
https://blog.darknedgy.net/technology/2020/05/02/0/index.html
======
xwvvvvwx
already posted 12 days ago:
[https://news.ycombinator.com/item?id=23062072](https://news.ycombinator.com/item?id=23062072)

~~~
christoph-heiss
I honestly didn’t see the post before and I’m kinda glad that I have now. Not
every repost is bad, also timezones and such.

~~~
dang
You're absolutely right, but unfortunately we can't customize HN that way; we
need a general approach.

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'.

------
naranha
Well, that's a lot of text to read. My (high-level) thoughts as a systemd user
for 10 years is that it improved some things, made a few things worse, but I
would not want to go back to the init.d days. Having a daemon around to manage
the lifecycle of services is actually a good idea and most of the *ctl
programs are preferable to the manual configuring they replace.

~~~
CameronNemo
I think one of the more interesting takeaways is that Lennart and Kay set out
to accomplish some specific goals:

\- universal IPC-based activation of services

\- kdbus with systemd being the userspace management layer for that

\- single writer group hierarchy with systemd being the single writer

And that these goals have not (yet) been realized. My perspective is that:

\- socket activation was never that useful to begin with and complicates the
build process for lots of services.

\- kdbus could have been something real, but Lennart and Kay were unwilling to
compromise and listen to the kernel devs criticisms. They tried to sidestep
the network maintainer by making it a character device, but forgot they did
not have the clout that Google/Android does that allowed binder to get pushed
through.

\- systemd turned out to be the worst container runtime on the market (systemd
the supervisor is fundamentally that, a container runtime) and having all
cgroup operations flow through its opinionated dbus api was simply
unacceptable for docker, kubernetes, lxc, runc, and everybody else maintaining
quality container runtimes.

So many of these goals will never come to fruition. What systemd excels at is
being a dependency based service supervisor with an opinionated and half
functional logging layer.

~~~
JoshTriplett
> \- socket activation was never that useful to begin with and complicates the
> build process for lots of services.

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.

~~~
CameronNemo
Do you have an example of such cross-dependent services?

------
sumanthvepa
This is an absolutely fantastic review of systemd. The technical section alone
is well worth the effort to read carefully if you use Linux in any significant
capacity. The history and analysis are pure gems.

~~~
JdeBP
You might also enjoy these:

* [https://blog.darknedgy.net/technology/2015/10/11/0/](https://blog.darknedgy.net/technology/2015/10/11/0/)

* [https://blog.darknedgy.net/technology/2015/09/05/0/](https://blog.darknedgy.net/technology/2015/09/05/0/)

* [https://blog.darknedgy.net/technology/2016/01/01/0/](https://blog.darknedgy.net/technology/2016/01/01/0/)

* [https://blog.afoolishmanifesto.com/tags/supervisors/](https://blog.afoolishmanifesto.com/tags/supervisors/)

------
gorgoiler
This contributes nothing to the discussion, but towards the end of this
excellent article I noticed myself reading “welcomed” phonetically as
“welcome-dee”.

~~~
rezonant
Haha. Knowing little about the state of the BPF developments, the line that
BPF will probably supercede everything literally broke my brain

------
beders
Ah, hacker news, the web site that can't detect duplicates or afford a message
preview.

Anybody else amused that we use this bare-bones, no-frills forum to discuss
high-tech? ;)

~~~
dang
Do you know of a way to detect whether an article is the same even if the URL
is different? In this case the URLs were:

repost:
[https://blog.darknedgy.net/technology/2020/05/02/0/index.htm...](https://blog.darknedgy.net/technology/2020/05/02/0/index.html)

original:
[https://blog.darknedgy.net/technology/2020/05/02/0/](https://blog.darknedgy.net/technology/2020/05/02/0/)

~~~
krapp
You would have to scrape the site when it's submitted, store more metadata for
each submission, do some validation then allow it to post afterwards.

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.

~~~
dang
We spent months working on a system to scrape content when it's submitted. It
was utterly impractical. (Side note: I was expecting someone to tell us to
"just" check rel=canonical, and had a reply pre-cached: the OP doesn't include
that.)

The kind of approach you're describing (compare paths, minus this and that,
get a rough score for similarity checking, then a miracle occurs, then you can
detect duplicates properly) is a recipe for sinking in the quicksand of corner
cases, of which the web has an endless supply. Sorry for being ill-tempered! I
don't mean to pick on your response. It's just that we've tried many things in
the past. The people who make belittling comments about duplicate detection
(not you, the GP) appear to have no idea how difficult it is to get it right,
even when you're not dev-resource-constrained as we are.

We also spent months, years ago, working on trying to identify duplicate
content on some fingerprinting basis. There was even the fantasy that you
could identify two articles that weren't duplicates but were about the same
story. This is a research-level problem.

Any real solution here would not be algorithmic, but would rather involve
better support for users to supply human curation, e.g. by reporting
duplicates that the system missed.

Edit: I see that I've reiterated what majewsky already said, just in a
crappier mood.

~~~
krapp
I thought it might work but I guess I can't argue with "we tried and it
didn't," so fair enough.

