How does this change the point that is being made in the article? Your agent is also only taking one of the existing roles that humans today occupy (e.g. the software operator or developer)

If the logs are being read by agents then they should be more detailed and verbose to help the agent understand the root cause. We reduce the volume of information for humans. That doesn’t need to be the case any longer.

I think you are misrepresenting this;

Varlink is based on much more conventional UNIX technology than Dbus, which is decades old: You connect to a named UNIX socket through its socket file in the filesystem (man page: unix(7)).

This is an old mechanism and it is known to work well. It does not require a broker service, it works right at system startup, and it does not require a working user database for permission checks (which would be a circular dependency for systemd in some configurations). If at all, I am surprised that systemd didn't use that earlier.

The main thing that Varlink standardizes on top of that is a JSON-based serialization format for a series of request/response pairs. But that seems like a lightweight addition.

It also does not require kernel support to work, the kernel support is already there. He mentioned in the talk that he'd like to be able to "tag" UNIX sockets that speak varlink as such, with kernel support. But that is not a prerequisite to use this at all. The service discovery -- and he said that in the talk as well -- is simply done by listing socket files in the file system, and by having a convention for where they are created.

What do you connect to, when you connect to varlink, if there is no broker service?

It's kinda weird to present this as a DBus alternative when it doesn't even offer the same facilities, particularly many-to-many communication.

Though I have a pretty good idea of where a Varlink broker would turn up and which init system it would be tied to.

Very typical systemd–developer style.

Those are pathname UNIX domain sockets, so you address them through the socket file, which is conventionally stored somewhere under /run.

You can run "netstat --listening --unix" to list the UNIX domain servers on your system, to get an impression.

See https://man7.org/linux/man-pages/man7/unix.7.html

And what does the socket connect to?

Etoile had its own Smalltalk dialect back in the day, Pragmatic Smalltalk. This was a Smalltalk based on the Objective-C runtime, based on an OMeta implementation and a LLVM backend. David Chisnall, who created it at the time, ended up getting involved more in LLVM in the long run, I believe.

Indeed, still gcc objC has not been updated but D which shares a lot in gcc 15 was upgraded to the latest release.

Pragmatic SmalltaLk can still rely on LLVM since there is LDC.

No objection against objC but on windows it is not the best.

D has 3 compilers with similar or beter ergonomics than ObjC

CDE was open sourced a while back: https://sourceforge.net/projects/cdesktopenv/

CDE is included as one of the options in Sparky Linux:

https://sparkylinux.org/cde-common-desktop-environment/

For me, it's a bit broken, though; I can't get the terminal to launch, and without that, you can't do much.

I wrote a comparison of CDE and modern recreation NotSoCDE:

https://www.theregister.com/2022/07/28/battle_of_the_retro_d...

A chap I know led the campaign to open-source it and I wrote about it at the time:

https://www.theregister.com/2012/08/09/cde_goes_opensource/

First, they should move to GitHub or GitLab (or Codeberg) to attract more contributors and make the process of development easier. Maybe it could also be ported to support Wayland and Unicode properly, and remove some legacy code to ease up the maintenance.

Absolutely, seccomp is also an unprivileged sandboxing mechanism in Linux. It does have the drawback however that the policies are defined in terms of system call numbers and their (register value) arguments, which complicates things, as it is a moving target.

The problem was also recently discussed at https://lssna2025.sched.com/event/1zam9/handling-new-syscall...

Landlock is currently still lacking some wrapper libraries that make it easier to use, in C.

We do have libraries for Go and Rust, and the invocation is much more terse there, e.g.

  err := landlock.V5.BestEffort().RestrictPaths(
      landlock.RODirs("/usr", "/bin"),
      landlock.RWDirs("/tmp"),
  )

FWIW, the additional ceremony in Linux is because Linux guarantees full ABI backwards compatibility (whereas in OpenBSD policy, compiled programs may need recompilation occasionally).

Similarly terse APIs as for Go and Rust are possible in C as well though, as wrapper libraries.

For full disclosure, I am the author of the go-landlock library and contributor to Landlock in the kernel.

The way I interpreted most of these "subclassing" cases in the GoF diagrams was actually as "subtyping", and then it makes more sense.

Regarding no one having a lock on the term "delegation", I think this is spot on. Yes, someone might have used the term differently before GoF, but that does not mean that GoF was wrong. It just meant something else in their context.

(Btw, congratulations, your comment is the first one so far in this comment thread that actually discusses the linked article and not just the GoF book itself.)

It's tracked in https://github.com/landlock-lsm/go-landlock/issues/35 - signals and abstract Unix sockets do unfortunately not interact well with the inherently multithreaded Go runtime. We are working on a fix in https://github.com/landlock-lsm/go-landlock/issues/36 but this needs to be on the kernel side and this is delaying this feature in Go, unfortunately. It is usable from (single threaded) C programs though.

Thanks!

+1

A rough description of upcoming network restriction features in Landlock and how they map to the BSD socket API is in the talk at https://youtu.be/K2onopkMhuM?start=2025 starting around 33:45

I really hope we can get back to these features soon :) I think these would be very useful.

(Author of go-Landlock here)

Awesome! I'm happy to hear that you and others are interested in the configuration language. We should probably coordinate that on the Landlock mailing list when the time comes, so that we don't duplicate that work. We are open to outside contributions :)

Would be cool to see integration of landlock with configuration file in a way that a service launched by systemd can apply the configuration to the executable.

Akin to systemd SystemCallFilter directive for no-code application of seccomp filters to the sandboxed process https://www.freedesktop.org/software/systemd/man/latest/syst...