Hacker News

Top stories

Live mirror
30 storiesupdated just nowView source snapshot
  1. F-Droid 2.0 (f-droid.org)
    301comments
  2. Show HN: Make cursed fonts like Times New Bastard (mitpit.com)
    86comments
  3. Show HN: Whiteboard (YC W26) – An open-source IDE for thoughtful software design (github.com/devdotfast)
    109comments
  4. Why is the liver so weirdly regenerative? (dynomight.substack.com)
    188comments
  5. 2DWillNeverDie (2dwillneverdie.com)
    32comments
  6. Fearless SIMD v1.0 (linebender.org)
    34comments
  7. Rails World 2026 Opening Keynote [video] (youtube.com)
    336comments
  8. Toyota is taking the Corolla electric (electrek.co)
    496comments
  9. My weird new hobby: Wandering around Tokyo on Google Maps (ahmedhossamdev.com)
    127comments
  10. Using LLMs to trace alchemical knowledge and decode 17th century letters (resobscura.substack.com)
    20comments
  11. Goodbye Google (ocallahan.org)
    147comments
  12. Google’s Project Suncatcher to put ML infrastructure in space (blog.google)
    303comments
  13. Two-tier encryption in the UK (macanorak.com)
    387comments
  14. Writing Parquet files using Haskell (datahaskell.org)
    5comments
  15. Opus 5.5 is good at explainer videos (launchvideo.io)
    115comments
  16. Book review: Is parallel programming hard, and, if so, what can you do about it? (ahelwer.ca)
    37comments
  17. The Board Game of the Alpha Nerds (2014) (grantland.com)
    28comments
  18. California is chasing wealth that has feet (landeconomics.org)
    585comments
  19. Security auditing in the age of (good enough) AI (trailofbits.com)
    12comments
  20. Show HN: Air-gapped file encryption as self-decrypting HTML page (apeleg.com)
    18comments
  21. Sourcehut account takeover via build logs (XSS in ansi2html) (blog.arusekk.pl)
    19comments
  22. The forgotten battle of East Lansing (eastlansinginfo.news)
    16comments
  23. WaveDigger: Dig into wireless signals to discover their physical locations (github.com/christianrowlands)
    20comments
  24. Nokia Design Archive (2025) (aalto.fi)
    121comments
  25. The Bayeux Tapestry: Woven by the Victors (historytoday.com)
    6comments
  26. Show HN: Koi.rest – watch some fish and regain your balance (koi.rest)
    42comments
  27. Geothermal heat map of US hot springs (soakingsprings.com)
    39comments
  28. Stable (YC W20) Is Hiring Product Engineers (usestable.com)
    —discuss
  29. Forging 1024-bit RSA signatures in nearly SNFS time [pdf] (iacr.org)
    11comments
  30. Motor Characterization for Small Running Robots (2016) (robot-daycare.com)
    3comments

SystemBSD: Custom D-Bus daemons emulating systemd behavior on OpenBSD [pdf]

72 pointsby 11y agodarknedgy.net
64 comments
11y agoHN ↗

Is there a recording of the talk that -I assume- was given with these slides?

11y agoHN ↗

There is no recording, from what Sutton told me. I saw the talk overview on the CDBUG page, knew his IRC handle and said "Give me the slides and the right to freely redistribute, you asshole." So he reluctantly did.

They were in MagicPoint format, so I had to convert them to PDF with a dubious third-party Python script, slightly modifying the MGP manifest in the process. That's probably why the formatting is so iffy.

For those wondering, the systembsd sources are here: https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git...

11y agoHN ↗

From the pdf, "the overwhelmingly common use case for these daemons is for running gnome".

There are native BSD desktop projects being worked on that are quite polished and require none of the Linux based SytemD+Gtk+Gnome dependency stack.

Lumina is worth looking at (Qt based) and also runs on Linux.

https://en.wikipedia.org/wiki/Lumina_Desktop

From what I remember the author started this work before the nuclear meltdown which is commendable. But we are obviously in a post schism age.

11y agoHN ↗

As long as it's optional for Gnome only as they say, that's fine. I just hope other DEs like Xfce don't simply rely on this being available like with Consolekit, HAL, D-bus, etc that I now have to run on FreeBSD as well.

I'm perfectly content ignoring Gnome, but if every full desktop environment starts relying on this because it's available, then it's not really so optional anymore. (and of course, if the alternative is guaranteed to be no major DE running on BSD at all without this, then we similarly have our hand forced. It depends on who would flinch first.)

11y agoHN ↗

You should try Lumina Desktop they are dedicated to a native BSD desktop experience and BSD technology, but it is also portable to Linux.

11y agoHN ↗

I could be very, very, very wrong, but I remember hearing a while back that both Wayland and KDE had plans to become dependant on systemd for its "guaranteed-race-free" startup process.

11y agoHN ↗

Wayland is not a program, it's a protocol, so there is no way it could depend on systemd. Some compositors may choose to, some compositors may choose not to.

11y agoHN ↗

Compositors choose to, because they need a part of it, logind, to talk to polkit, to gain the proper access privileges to do what needs to be done.

Basically, with Wayland the compositor/Window Manager/toolkit gets elevated to the same level as X11. Meaning that it has to do pretty much everything that X11 used to do for it.

The alternative to using logind+polkit is to run the DE/WM/compositor as root. Not something often talked about, as wayland is supposed to be the secure choice vs X11.

Frankly it feels like Linux is turning into some kind of marketing mess, where stuff is being presented as one thing but is in essence something quite different for those in the know.

11y agoHN ↗

I would actually be somewhat okay with running the graphical stack as root inside a jail, if it meant bypassing all of the systemd emulation.

Frankly it feels like Linux is turning into some kind of marketing mess

I feel it's just been becoming a mess in general. They're trying too hard to cater to every possible use case, and there's nobody really in charge of the whole end-product to say "NO" to things. So they completely miss the elegance that comes with simplicity and minimalism.

More and more, I feel the long-term solution for BSD is going to have to be a full split on the graphical stack. It's been lovely for transitioning to be able to take all of my Linux apps with me to BSD, and it's a huge hindrance to eg Haiku adoption, but ... with Linux becoming more and more insular with Linux-only dependencies all throughout the stack, it seems inevitable that this Frankenstein of Linux emulation is going to have to collapse at some point. We could still have GTK/Qt ports, so we could still run the truly portable stuff (Audacious, Pidgin, Transmission. etc.)

Or as a nice alternative, dedicate a TTY to running a virtual machine of a full Linux OS for your graphical desktop.

11y agoHN ↗

So they completely miss the elegance that comes with simplicity and minimalism

For anyone following Linux since 2000 at least, this statement is so funny.

X11 was never simple nor minimal. The various init daemons were never simple nor minimal. The mess that is the collection of kernel drivers has never been simple nor minimal. Linux has always been about choice: if you like stripped-down, you go and strip it down; if you like full-featured, you go and pack everything. There is no one-size-fits-all, no single design. Anything else would not be Linux.

The un-linuxness of systemd is exactly that it's becoming less and less optional. We whined for years that X11/Xorg was really a non-optional piece of crap, and when it's finally seeing some competition, we're being saddled with a non-optional daemon that takes over the rest of your system -- and unlike X11, it's not even desktop-only.

11y agoHN ↗

Yes, I agree with this very much as a long time Linux and BSD user. Linux was never like a BSD. The only thing that 'IS' Linux is the kernel everything else is a choice. With BSD you get a kernel + system libraries + userland all in the base system. So linux has always been a mess but extremely flexible.

11y agoHN ↗

Linux has always been about choice

This is wrong. Linux has never been about anything. It's always been only what people have made it; no less, no more.

Viewed like this, systemd is not at all "un-linuxy" (if that made sense in the first place). It is a set of tools written by a bunch of people to solve their problems, and has gained mindshare, users and developers faster than other alternatives, which is exactly what Linux (the kernel) did.

Your only choice is to use it, or not use it, but you don't get to complain if someone else decides to depend on it because they deem superior to alternatives. If you want to keep other software from depending on systemd, the onus is on you to provide a reasonable alternative. It will not work to simply demand that others must spend their effort maintaining code that they have no interest in because you want something.

11y agoHN ↗

We whined for years that X11/Xorg was really a non-optional piece of crap...

Does the fact that sshd's X11 forwarding doesn't require to run an X11 -errm- client(?) to run X11 software on a remote machine make X11/Xorg more optional? (Obviously, you do need to run X11 on the machine that displays the GUI, and you do need X11 libs installed on the remote machine.)

11y agoHN ↗

No, I was referring to the fact that there was basically no alternative graphics system in the mainstream.

You could choose among different windows servers, desktop systems etc, but all of these would only run on top of X11/Xorg. Compatibility with other implementations both at protocol and interface levels was barely even nominal. Whenever X11/Xorg development stalled or hit problems etc, the entire desktop ecosystem was screwed, often for long periods.

Now we're going to see this happen with basically the entire userland. If distributions keep pushing it, systemd is going to become "X11 for userland", regardless of its actual quality.

11y agoHN ↗

The Wayland Protocol is simply a specification that is true. But there also has to be an actual implementation. The only implementation of Wayland Protocol at this point is the reference implementation that heavily uses Linux only system calls and is not practically portable to BSD or any other system. Therefor Compositors that use libwayland such as Weston and Gnome are also not portable. SystemD dependencies add another layer of incompatibility.

So yes Wayland Like X is in theory OS agnostic but in practical terms they are only as portable as there specific implementation.

11y agoHN ↗

Hnnh. I see that the Wayland folks have -perhaps inadvertently- subjected us to another round of "Do you mean Java-the-language, Java-the-VM, or Java-the-Runtime-Environment?" style confusion.

I've always heard things like "Wayland is going to be the replacement for X.org." and "Work on Wayland compositors is proceeding at pace.". Pardon my confusion.

To address my claim, do you know if there is currently a functional, non-toy Wayland compositor that doesn't plan to add a dependency on systemd?

11y agoHN ↗

Perhaps it would clarify things if you knew that Weston is the reference implementation of Wayland that is presumably going to depend on logind.

11y agoHN ↗

Best i can tell, the reason Xfce seems to assume it is there is because the developers are short on time and thus make use of low level Gnome libs to get things out the door.

Essentially Gnome seem able to throw a whole lot more man hours at various topic than can the rest of the DEs, KDE included. This in turn seem to lever Freedesktop towards them (though Freedesktop may have overly favored Gnome from the get-go).

11y agoHN ↗

Xfce already depends on it? :(

I was under the impression they had FreeBSD users on their dev team, and kept it alive, just with some limited features (like automounting not really working) and only relying on a few Linuxisms like Consolekit.

Still on 4.10 though, so perhaps that's no longer the case on the newer versions.

11y agoHN ↗

The author mentions using OpenBSD in production. Do any of you also use it in production? I have no doubt that it is used with good results, but I have enjoyed it as a desktop OS and would love if more people could share their experience with it on a job.

11y agoHN ↗

I use it for servers except for home directories (FreeBSD with ZFS for that) and required applications (Red Hat, Windows, OS X, and an AS/400 (iSeries)). It works fine on bare metal and in VM on VSphere. Management is quite easy and the 6 months between major upgrades has been ok. Patching is build a set (I am all amd64) and deploy.

11y agoHN ↗

I work for an ISP. We use it (CARP and relayd) heavily for HTTP and DNS load balancing in an IPv6-laden environment. Performance is better than that we saw a few years ago under Linux.

11y agoHN ↗

Did you also evaluate FreeBSD? If you did, I'm curious what the pros and cons were that ultimately affected your decision.

11y agoHN ↗

I did not. I was more familiar with OpenBSD to begin with, and like its slant toward security. Although we do use FreeBSD for a few other servers used as NAS controllers. HAST + ZFS + CARP is great.

11y agoHN ↗

Fair enough, thanks. I was curious since I've heard that FreeBSD generally has the best performance for network-heavy architectures.

11y agoHN ↗

I use it as a firewall/router/network appliance OS.

The neat thing is that most of the things you need for that role are in the base install, which is quite minimal.

11y agoHN ↗

Given its reputation, I was surprised at how little I needed to do to have a suitable working environment.

11y agoHN ↗

That it is more suitable for a firewall or router than desktop. To be clear, I didn't actually expect it to be bad at that. I was just surprised at how quick and easy it was to install it and to have a setup that I enjoy.

11y agoHN ↗

We used OpenBSD with carp and pf as our external firewall for quite a while - worked great.

11y agoHN ↗

The systemd folks have been saying all along that it's just a standardized and stable interface and anyone else can implement that interface. I'm glad to see this, because it's testing the claim: if it's true, that means wonderful things for OpenBSD portability, and if it's not true, we should be more cautious about coding to systemd's APIs.

11y agoHN ↗

Read the slides he had a multitude of issues trying to copy the interfaces due to the tight integration of components.

11y agoHN ↗

What's more, I expect that his will forever be an incomplete implementation due to to undocumented or poorly-documented behaviors, edge-case or otherwise.

11y agoHN ↗

It was never even considered that this would be a complete implementation. The goal was always to just implement the minimum requirements to get Gnome working. And as far as I know they never even completed that work. They implemented some small subset of there original daemons because the project quickly blew up into a major amount of work.

11y agoHN ↗

Of course the implementation is going to be incomplete in some way, since OpenBSD kernel doesn't have the APIs necessary to actually implement multiple seats, so the implementation won't allow creating more than 1 seat.

11y agoHN ↗

The argument that XYZ has a portable interface therefor XYZ is portable is a bit of a head fake argument. OpenGL 4.5 is also a supposedly portable interface, so is the X Server protocol. To implement these takes years of work with large teams of full time engineers. Mesa has over 1.5 million lines of code and has been in constant development for over 10 years.

At last count SystemD has over 40 "Interfaces". These are not publicly versioned standards. So there is no stable interface to even implement and there is no commitment that these "interfaces" will not change at any point in time.

If the project estimate to actually implement XYZ interface takes years of full time engineers and millions of dollars to complete its basically out of the reach of any volunteer open source operating system project.

I just find the argument disingenuous. Everyone making these claims knows that there is practically 0 chance that anyone but RedHat or another big Corporation like Google or Samsung has the resources to Implement something like this.

11y agoHN ↗

I am aware of the pages you linked to and have on a few occasions tried to look over things. Having read quite a few rather large standers and APIs my impression the "Portable Interfaces" is rather dim. They are disjoint and unversioned notes not presentable portable interface standards. There are also various internal protocols and interfaces which are not documented from what I have gathered.

In short SystemD is an implementation. And as they say in there own documents there implementation is and never will be a portable implementation.

The "Interface Stability Promise" is referring to the unit configuration file format and the command line interface. This is not stability of the implementation c interfaces.

If you want to see a proper portable specification take a look at the Wayland Protocol Specification. There or perhaps POSIX.

11y agoHN ↗

The "Interface Stability Promise" is referring to the unit configuration file format and the command line interface. This is not stability of the implementation c interfaces.

This is not true.

11y agoHN ↗

That documentation / list is interesting. They say that logind is fully documented for example. But if you follow the link, you get things like:

    CreateSession(in  u arg_0,
                    in  u arg_1,
                    in  s arg_2,
                    in  s arg_3,
                    in  s arg_4,
                    in  s arg_5,
                    ...

With no further explanation, apart from one paragraph summary of who shouldn't call it.

I remember someone complaining about that years ago already. Apparently nothing changed.

11y agoHN ↗

With no further explanation, apart from one paragraph summary of who shouldn't call it.

The CreateSession description states that it should never be called from the clients, but instead be handled through PAM, so assume this is why they don't describe the arguments for this one call, while all the other method arguments and return values are described under 'Methods'.

11y agoHN ↗

That's hardly "fully documented" though, isn't it?

What I mean specifically is that they document the client interface only, not the full interface needed for a complete replacement.

11y agoHN ↗

Well since it's one single method that's not documented, and they say you should not call it from a client, I assume they want to make it clear by not exposing the arguments in the client api documentation.

If you want to re-implement logind you will invariably read the logind source code anyway, where the call arguments are described.

You said there been a complaint about this, was there a discussion you can point me to ?

11y agoHN ↗

If you want to re-implement logind you will invariably read the logind source code anyway...

1) Does this mean that you consider software's source code to be adequate documentation of an API and its behavioral contracts?

2) There's this saying that goes something like "You never know that you have a good API until you've created three independent implementations of it.". It's very difficult to create an independent implementation of an API if the primary documentation of important parts of that API's behavior is the source code that implements that API.

11y agoHN ↗

They have very well defined documentation for all the stable parts of the API, their code is modern and quite readable. In addition to this Lennart is good at publishing lengthy explanatory blogposts aimed at system administrators. Finally they have done a truly admirable job building a community and explaining the why's and how's of their project. This is evident in the fact that there is now a systemd conference coming up.

If this fails the test, I suggest that it is a marvelous failure which every project should strive to emulate. To suggest that systemd is poorly documented indicates an insufficient exposure to the sad reality of most Open Source projects where "our unmaintained, outdated, bug riddled code base is the documentation" is the best case answer to the question of documentation.

11y agoHN ↗

Your first sentence seems to contradict the docs... which still don't describe "all the stable parts".

11y agoHN ↗

Having done distro-maintenance work that needed to be compatible with both systemd and upstart, I've read the explanatory blog posts and found them wonderful, and I've also found the detailed API documentation lacking in spots.

There are a lot of praiseworthy things about systemd and its approach to documentation. The blog posts are definitely one of them. That doesn't mean everything is praiseworthy, that there's no room for improvement, or that complaints about things not being documented are illegitimate or inappropriate.

11y agoHN ↗

Proper capitalization goes a long way in making a text readable. I had the impression that this presentation was written by a 10 year old script kiddie. Also: punctuation, consistent font sizing. Add a few colors to highlight the code blocks. Headings. Graphical bullet points. Those would make the presentation mch more trustworthy. If you are going to talk shit about somebody or something (without substantiating the points nonetheless) then at least do it with style.

11y agoHN ↗

As vezzy-fnord points out in this thread, at https://news.ycombinator.com/item?id=10176412 , the author did not post the slides, nor had final say on the presentation format. Instead, quoting vezzy-fnord:

They were in MagicPoint format, so I had to convert them to PDF with a dubious third-party Python script, slightly modifying the MGP manifest in the process. That's probably why the formatting is so iffy.

You'll also note that the author "reluctantly" gave permission. For all we know, it was precisely because the author knew that people would criticize the paper over superficial format conversion issues than actual substance.

11y agoHN ↗

I enjoyed the research you did for the followup. I must be another one of those old folks. :)

For what it's worth, I was a horrible writer when I was an undergraduate, and this was a GSOC project, so I'm willing to cut some slack. Might be because I'm a slacker.