"While the above attack did use the systemd vsock sshd listener for Escape to Host, the attacker could have just directly listened over the vsock loopback." https://www.openwall.com/lists/oss-security/2026/01/08/7…
Maintaining separate upstream sources and downstream patches does provide value. Maybe not to you, but it does. For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream…
It gracefully falls back if the new option is not available at runtime
No, the graphics stack needs to be native and in sync for obvious reasons, and that includes the mesa libraries. What can be in the runtime is already in the runtime.
> The reality is that no such documentation is provided, so the only way to avoid systemd is to become an expert in its internals. The blog post subject of the thread literally links to the documentation. If you can't…
It's not even that, that whole story's main point was about how an incredibly complex, sophisticated and lengthy social engineering attack was carried out, probably by a nation-state actor, after singleing out an…
> I’m somewhat a fan of systemd and I’m interested in immutable images, but I don’t want to build systemd from source: You don't have to, we build packages and publish repositories from latest main, and the particle…
> So how do I replace any of them with my own, small tool? You write them with an equivalent public interface. > They have no stable interfaces. This is nonsense. All the D-Bus (and now Varlink too) interfaces are…
> The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing. It is not. There are other, very real and very…
> When configuring boot media, like an SD card, for an embedded ssystem that is not the running system where the configuration is occurring, this is an impediment. There is systemd-firstboot, etc, but this is not as…
Debian, Ubuntu and all derivatives thereof use initramfs-tools, which does not use systemd in the initrd, and things work just fine
malloc_info() is not consumed internally but it is only wired up as a debugging utility via systemd-analyze, which is sorely needed when things go bad in strange and weird ways. It would be entirely fine for a libc to…
For the record, it turned out this was just a series of misunderstandings on the part of the OP on how configuring networking works on Linux, and the differences between how the kernel and how userspace manage and…
> Systemd-boot, any boot loader, that aims to replicate the things that the kernel does is ultimately going to run into the same problems as grub. We're going to have the font CVEs, we're going to have filesystem and…
Yes: it's a joke. Here, have some chills, on the house:
The fact that YOU have a particular use case doesn't necessarily mean much either. Just customize your configuration accordingly, and move on.
Or what about, delete it after 10 days it was last accessed (regardless of whether for read or write)? Hint: that's already how tmpfiles.d works
> Why not just have the installer _ask_ me what configuration I prefer? Because nobody bothered to actually put in some work to implement that. As I've said on the ML, if somebody does the work, I'll review it. But it's…
What a genius idea, how bizarre that nobody ever thought about that before! We just need to get the bus dependencies up first and then... oh. Oh wait. Oh no.
> kdbus didn't even make it into staging. Project mainline put in some serious work to get where it got. > > And quite probably part of it going better was not insisting on becoming mandatory solution for everyone. If…
D-Bus will never be removed. Varlink was added because the kernel refused to provide usable IPC primitives, like other OSes have, so a brokered IPC is simply unfeasible in early userspace. So now we have two IPCs that…
> That's my point: Binder got merged before kdbus started development. It didn't, it was merged in 2015, a year after or so. No, staging doesn't count, it's a dumping ground for all sort of things that do not see the…
By "making it available" it doesn't necessarily mean a fully-working, configured broker, but only having enough working primitives that you can bring up userspace without races, with requests that can immediately be…
kdbus/bus1 were about making IPC primitives available race-free to userspace since the very first moment it is started. Perf was icing on the cake. Binder is Google-only, so nobody else can really use it, given they…
No, performance wasn't the main reason (although that was a big part), it was mainly about race conditions. If userspace implements the bus, then only the half of userspace that comes up after the daemon can use it.…
"While the above attack did use the systemd vsock sshd listener for Escape to Host, the attacker could have just directly listened over the vsock loopback." https://www.openwall.com/lists/oss-security/2026/01/08/7…
Maintaining separate upstream sources and downstream patches does provide value. Maybe not to you, but it does. For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream…
It gracefully falls back if the new option is not available at runtime
No, the graphics stack needs to be native and in sync for obvious reasons, and that includes the mesa libraries. What can be in the runtime is already in the runtime.
> The reality is that no such documentation is provided, so the only way to avoid systemd is to become an expert in its internals. The blog post subject of the thread literally links to the documentation. If you can't…
It's not even that, that whole story's main point was about how an incredibly complex, sophisticated and lengthy social engineering attack was carried out, probably by a nation-state actor, after singleing out an…
> I’m somewhat a fan of systemd and I’m interested in immutable images, but I don’t want to build systemd from source: You don't have to, we build packages and publish repositories from latest main, and the particle…
> So how do I replace any of them with my own, small tool? You write them with an equivalent public interface. > They have no stable interfaces. This is nonsense. All the D-Bus (and now Varlink too) interfaces are…
> The fact the initramfs is not signed/verified on any desktop Linux distro means secure boot is completely pointless right now on Linux, and is very dissapointing. It is not. There are other, very real and very…
> When configuring boot media, like an SD card, for an embedded ssystem that is not the running system where the configuration is occurring, this is an impediment. There is systemd-firstboot, etc, but this is not as…
Debian, Ubuntu and all derivatives thereof use initramfs-tools, which does not use systemd in the initrd, and things work just fine
malloc_info() is not consumed internally but it is only wired up as a debugging utility via systemd-analyze, which is sorely needed when things go bad in strange and weird ways. It would be entirely fine for a libc to…
For the record, it turned out this was just a series of misunderstandings on the part of the OP on how configuring networking works on Linux, and the differences between how the kernel and how userspace manage and…
> Systemd-boot, any boot loader, that aims to replicate the things that the kernel does is ultimately going to run into the same problems as grub. We're going to have the font CVEs, we're going to have filesystem and…
Yes: it's a joke. Here, have some chills, on the house:
The fact that YOU have a particular use case doesn't necessarily mean much either. Just customize your configuration accordingly, and move on.
Or what about, delete it after 10 days it was last accessed (regardless of whether for read or write)? Hint: that's already how tmpfiles.d works
> Why not just have the installer _ask_ me what configuration I prefer? Because nobody bothered to actually put in some work to implement that. As I've said on the ML, if somebody does the work, I'll review it. But it's…
What a genius idea, how bizarre that nobody ever thought about that before! We just need to get the bus dependencies up first and then... oh. Oh wait. Oh no.
> kdbus didn't even make it into staging. Project mainline put in some serious work to get where it got. > > And quite probably part of it going better was not insisting on becoming mandatory solution for everyone. If…
D-Bus will never be removed. Varlink was added because the kernel refused to provide usable IPC primitives, like other OSes have, so a brokered IPC is simply unfeasible in early userspace. So now we have two IPCs that…
> That's my point: Binder got merged before kdbus started development. It didn't, it was merged in 2015, a year after or so. No, staging doesn't count, it's a dumping ground for all sort of things that do not see the…
By "making it available" it doesn't necessarily mean a fully-working, configured broker, but only having enough working primitives that you can bring up userspace without races, with requests that can immediately be…
kdbus/bus1 were about making IPC primitives available race-free to userspace since the very first moment it is started. Perf was icing on the cake. Binder is Google-only, so nobody else can really use it, given they…
No, performance wasn't the main reason (although that was a big part), it was mainly about race conditions. If userspace implements the bus, then only the half of userspace that comes up after the daemon can use it.…