An unstable Debian stable update
A bug in a recent release of systemd's network manager caused headaches for people managing systems that have a virtual LAN (VLAN) interface on a bridge; something one might want to do, for example, when configuring network interfaces for virtual machines. The bug affected several Debian users when upgrading the systemd package from v257.7-1 to v257.8-1. The updated package is part of the Debian 13.1 release, and the bug has snared enough users to cause a minor stir—due in no small part to the maintainer's response as much as the bug itself.
The bug in systemd-networkd was first reported to the systemd project on August 7 by Kenneth J. Miller, who encountered it in an Arch Linux package. The problem is a regression in the systemd 257.8 release; systemd-networkd will crash with a segmentation fault if a system has a bridge interface configured with a VLAN. This is not a common configuration, but it is supported by systemd-networkd and explained in its documentation. Certainly, users who have this configuration working would expect it to continue doing so when updating their system.
The regression found its way into the systemd package version 257.8-1~deb13u1 and was uploaded to the proposed updates repository for testing. Timo Weingärtner filed a bug reporting this problem against the Debian systemd package on August 30, before version 257.8-1 had moved into Debian's stable updates repository.
He explained his setup, offered to provide more detailed configuration information in private, and noted that the upgraded systemd-networkd worked fine on systems without a VLAN configured on a bridge. He added that he was reporting the bug in the hopes of stopping the new package from reaching the stable archive. Luca Boccassi, a systemd developer and one of the maintainers for the Debian package, as well as the most active uploader for it, responded on September 1 and asked Weingärtner to provide more information.
Move to stable
The systemd 257.8-1 package did, unfortunately, move to
the stable updates repository, and it was included in the
Debian 13.1 release on September 6. That led to several
people chiming in on the bug report to confirm that it was an issue
and urging Boccassi to increase the severity of the bug. Tim Small asked
if there was a way to pull the package from the archive. He also expressed
surprise that it had been included in the update since it had
been reported "a good week before Debian 13.1 went out
".
Adam D. Barratt said that a new updated package was needed; it could be released to the stable-updates repository if the release managers agreed. He noted that the release team had no way of knowing that the 257.8 package should not have been included in 13.1:
It was reported at a non release critical severity, tagged "moreinfo" and neither the submitter nor the maintainer (nor anyone else) raised it to the Release Team's attention
Boccassi set the bug's priority to "minor" and replied that there was no need to disturb the release managers. He also added a somewhat dismissive comment about the impact of the bug itself:
This is just a minor issue with a particular corner case of a custom config of an optional component. Anybody who is unable to deal with that should just stick to the default Debian components. The next stable update in ~2 months will contain a fix.
What Boccassi is referring to is Debian's default method of configuring networking; there are four recommended ways to configure networking for Debian systems. The default for servers is to use /etc/network/interfaces, and NetworkManager is the default for desktop configurations. LWN covered a discussion about those defaults in September 2024.
Response
Kevin Otte called
the response insulting and said that "my network failing out
from under me during a routine 'apt upgrade'
" was hardly a minor
issue. He added that the configuration is a normal feature that was
introduced with Linux 3.8 and well-documented in the
systemd-networkd man page. "This is hardly a corner case nor a
custom configuration.
" Otte also objected to the idea that
systemd-networkd is an optional component, since it is part
of systemd and included in Debian's base package set.
Any package maintainer that can't adequately maintain their package, especially one as critical as systemd, and essentially tells the user "sucks to be you" should step down.
Others voiced similar sentiments; Jonathan Wiltshire, one of
Debian's stable release managers (SRMs), disagreed
with Boccassi's position. He pointed out that
systemd-networkd is called out in the Debian networking
reference, and the configuration that triggers the bug is explicitly
included in systemd's documentation. Whether Boccassi intended it or
not, maintaining systemd-networkd makes him responsible for a
critical component for many people using Debian in a production
scenario. "A reasonable user would expect this to work without
issue.
" He also said that this kind of bug was absolutely
something the SRMs would want to know about. "We would rather know
and disregard than not know at all.
"
Daniel Baumann sent a message
to the debian-devel mailing list about the bug, saying that it had
taken several servers offline at his work, "seriously harming the
reputation of Debian
" and causing his management to question further
contributions to Debian during working hours. He said that the fix for
the bug was trivial and should be applied as soon as possible, he also
asked Boccassi if he had reconsidered the priority of the bug.
On September 8, Boccassi doubled
down on his assertion that the configuration in question was a
"niche corner case
":
Regardless of what one's opinions may be, the fact is that the default in Debian is network-manager for desktops and ifupdown for the rest, so anybody demanding nothing less than perfection would do well to stick to those defaults instead of being adventurous and then throwing abuse when experimental things don't work.
He said that he had already prepared an update with a fix for the
bug to go into Debian's proposed updates queue but had not uploaded it
due to "incredibly demotivating
" comments from other members of
the Debian project. He would upload the update when "things calm
down to a sensible level
". If Wiltshire wanted to push the new
package as an update before the 13.2 release, Boccassi said, then he
could do so.
Fix uploaded
Philipp Kern—a former Debian SRM—responded on September 9; he reported that a non-maintainer upload with a fix for the bug was due to be installed in Debian's archive. That package is now available in Debian's stable updates repository and has been accepted for 13.2.
It is understandable that users would be upset by such a bug impacting their systems; having to recover a remote system that has lost networking is, after all, not much fun for most people. It might, in fact, ruin one's whole day. However, some of the responses and accusations were out of line—even taking into account the dismissive nature of some of Boccassi's replies.
This is not to say that there is no room for improvement or that it would be a bad idea for other Debian developers to be more active in maintaining such a critical package. There are five other people listed as maintainers of the systemd package aside from Boccassi. He, however, appears to be the only person making regular maintainer uploads for the package in recent times, though the changelog does note a number of contributions from others.
The Debian project strives to provide a stable, high-quality operating system; it succeeds in this the majority of the time. Its distribution is developed by volunteers who typically have day jobs and many competing responsibilities outside of their work on the distribution. Ideally, Debian's maintainers would always respond to bugs effectively, and users could assume that stable updates will, in fact, be stable. It is not reasonable to expect the same level of response from volunteers that one gets from a commercial Linux, though. Negative feedback does not encourage open-source contributors to do better; it puts them on the defensive and creates a hostile atmosphere that too often leads to developer burnout.
Posted Sep 23, 2025 17:02 UTC (Tue)
by ju3Ceemi (subscriber, #102464)
[Link] (14 responses)
On one hand, I feel sorry for these users. On the other hand, "we told you so" 😂
Posted Sep 23, 2025 17:11 UTC (Tue)
by archaic (subscriber, #111970)
[Link] (2 responses)
Posted Sep 23, 2025 18:42 UTC (Tue)
by MortenSickel (subscriber, #3238)
[Link] (6 responses)
Posted Sep 23, 2025 18:50 UTC (Tue)
by ju3Ceemi (subscriber, #102464)
[Link] (5 responses)
"Regardless of what one's opinions may be, the fact is that the default
As he said, everybody demending nothing less than a working network system would do well to stick to the default: network-managed for destkops and ifupdown for the rest;
Posted Sep 23, 2025 19:02 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Sep 24, 2025 18:24 UTC (Wed)
by MortenSickel (subscriber, #3238)
[Link]
Posted Sep 25, 2025 2:34 UTC (Thu)
by mirabilos (subscriber, #84359)
[Link] (2 responses)
Posted Sep 25, 2025 12:27 UTC (Thu)
by pizza (subscriber, #46)
[Link]
You are confusing "systemd" with "Debian"
Meanwhile, Debian obsoletes/removes features with every single release.
Posted Sep 26, 2025 3:37 UTC (Fri)
by ATLief (subscriber, #166135)
[Link]
Posted Sep 25, 2025 2:33 UTC (Thu)
by mirabilos (subscriber, #84359)
[Link]
But independent of that… if there’s a regression in a documented functionality, especially a segfault (something that, other due to user-caused stack exhaustion in things that do allow user-controlled recursion like generic programming languages, is always a hard bug in the software itself), then that ought to be fixed before it spreads. *sigh…*
That handling… sure is skirting the lines of the SC.
Posted Sep 25, 2025 7:30 UTC (Thu)
by parametricpoly (subscriber, #143903)
[Link] (2 responses)
Posted Sep 25, 2025 8:09 UTC (Thu)
by em (subscriber, #91304)
[Link] (1 responses)
Posted Sep 25, 2025 20:56 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
When you're as dismissive and abrasive as bluca to people who happen to hold different opinions, sorry but I call that incompetence. Plain and simple. Not in coding but in relating to people, and in understanding their concerns.
Also, let's be brutally plain here: regardless of *any* nonsense in your config files, it is *never* OK to segfault, and by extension it's also never OK to dismiss a segfault-inducing bug as unimportant.
Not if you're a core system component.
Posted Sep 23, 2025 17:10 UTC (Tue)
by mb (subscriber, #50428)
[Link] (1 responses)
Really? Come on...
Posted Sep 24, 2025 0:03 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link]
I've been thinking a lot about what the old days of LKML were like, before the corporate world jumped on. I started using Linux with a Slackware 3.1 CD, and my education in engineering was reading LKML, Alan Cox's blog, things of that nature.
The current landscape is just nutty, and it's pretty clear basic professionalism and understanding of our responsibilities has declined.
Posted Sep 23, 2025 18:15 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (49 responses)
The good parts include the core service supervision, journald, timers, home directory management. The bad parts include things like mount units, network configuration, DNS.
Systemd at this point needs to seriously think about its governance and prioritization. Their backlog is 2.5k issues, and quite a lot of them are serious, and they should really work on reducing it rather than adding new stuff. I got bitten by them more than once (e.g. https://github.com/systemd/systemd/issues/34164 ).
Posted Sep 23, 2025 23:55 UTC (Tue)
by WolfWings (subscriber, #56790)
[Link] (25 responses)
It's usually the first thing I do when setting up a new machine is switching to networkd and switching whatever wireless SSID management it wanted to use to IWD instead.
DNS yeah, it's waaay too complicated and makes DNS feel like I'm setting up sendmail again for some reason, but the networking being wildcard-template based makes is super simple for the vast majority of configurations, even bonded links where you're bonding up an entire PCIe card or the same slots across multiple separate PCIe cards.
Posted Sep 24, 2025 12:50 UTC (Wed)
by linuxrocks123 (subscriber, #34648)
[Link] (8 responses)
Posted Sep 24, 2025 17:26 UTC (Wed)
by jem (subscriber, #24231)
[Link] (1 responses)
Posted Sep 26, 2025 3:44 UTC (Fri)
by ATLief (subscriber, #166135)
[Link]
Posted Sep 25, 2025 4:42 UTC (Thu)
by cclifforgg (subscriber, #88919)
[Link]
Posted Sep 25, 2025 9:12 UTC (Thu)
by WolfWings (subscriber, #56790)
[Link] (3 responses)
LILO and ELILO haven't been updated or supported in over a decade at this point, and LILO wasn't included since Debian Bullseye with ELILO removed back in 2014 before Jessie was released. Your counter-option really isn't. If you enjoy manually compiling everything there's always Gentoo, but if you're using Debian you want to just install binary packages and get on with your day. The Linux kernel most distros publish is already a UEFI binary since a LOT of bootloaders want that for signing reasons, etc, and updating it is a lot easier with fallbacks using a bootloader with a menu interface and relying on distro signing keys than having to do all that yourself.
Posted Sep 26, 2025 2:33 UTC (Fri)
by linuxrocks123 (subscriber, #34648)
[Link] (2 responses)
I also didn't say ELILO was updated or supported. But, since you mentioned it, I'll just say that I generally don't whether software is updated or supported, and I generally do care if it works.
Regarding boot menus, I've found the UEFI boot menu available with F12 to be sufficient, so I don't see a need for a separate program to provide that feature. Given all of the over-engineered nonsense built into UEFI, I'm pleased that the resulting mega-kludge can at least display a better boot menu than its predecessor.
But I'm still looking forward to CSMWrap being developed to completion.
Posted Sep 26, 2025 2:55 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (1 responses)
This comments section as a whole is about "Debian in particular", though. The commenter you were replying to is also, presumably, a user of Debian in particular.
So when you post a comment on an article (about Debian) replying to another commenter (a user of Debian) saying "Why would someone need [systemd's] bootloader? <...> ELILO still works" and then claim that it does not matter that ELILO is not, in fact, available in Deban, then you are simply being obtuse. HTHs.
Posted Sep 26, 2025 7:47 UTC (Fri)
by linuxrocks123 (subscriber, #34648)
[Link]
In that case, I expect compiling ELILO on Debian would be straightforward, and I also expect the old .deb file from whatever the last release to include ELILO was would probably still work. However, I don't use Debian and so have not tested that.
Posted Sep 26, 2025 4:01 UTC (Fri)
by ATLief (subscriber, #166135)
[Link]
Posted Sep 24, 2025 18:22 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
It's the implementation that is problematic. There are weird little "features" like missing routing metrics. So if you have a 10Gb wired network and a 2.4GHz wireless connection, networkd will assign both of them the same metric. With no way to fix it, because it's not exposed in the config.
I also had problems with DHCP and VPN interactions where systemd's "interface online" probes misfired.
Network Manager at least gives preference to wired connections.
Posted Sep 24, 2025 19:45 UTC (Wed)
by TomH (subscriber, #56149)
[Link]
About the only route you can't set a metric for I think is ones added by an Address or Gateway directive in a Network section but just use an Address or Route section instead if you need to customise the metric.
Posted Sep 25, 2025 8:53 UTC (Thu)
by WolfWings (subscriber, #56790)
[Link] (1 responses)
You're trying to fix what is really a failover issue with routing metrics if the ethernet and wifi share overall connectivity on the back-end. That requires a bond, and it's a standard thing to do on laptops. Setup an active-backup bond between the two links with PrimaryReselectPolicy=always and PrimarySlave=true on the ethernet device.
Posted Sep 25, 2025 19:57 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 25, 2025 10:10 UTC (Thu)
by intelfx (subscriber, #130118)
[Link] (1 responses)
Huh? What am I missing?
https://www.freedesktop.org/software/systemd/man/latest/s...
Posted Sep 25, 2025 19:55 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> Added in version 246.
I guess I can try it again...
Posted Sep 25, 2025 2:55 UTC (Thu)
by sionescu (subscriber, #59410)
[Link] (9 responses)
Posted Sep 25, 2025 5:59 UTC (Thu)
by intelfx (subscriber, #130118)
[Link] (8 responses)
Split DNS is basically the entire reason systemd-resolved exists. And it does in fact work very well — in my experience, this is the *first* time split DNS on Linux actually worked well, and I use it daily.
> mDNS is broken
Ditto, excepting the "first time" part (but I still use it daily).
> dns-over-https is not implemented
DNS-over-TLS is.
Posted Sep 25, 2025 14:09 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (7 responses)
I have to reconfigure resolved (via `/etc/nsswitch.conf`) because it causes network namespace leakage. If I have a network namespace jailed to a VPN, systemd-resolved needs to live *in* that namespace to reliably do DNS for it (but then it cannot service non-VPN requests…). But because it leaks through `nss` plugins, I have to at least remove the `[!UNAVAIL=return]` behavior. So instead, I remove that and put it behind `dns` to avoid the latency involved when it fails to service VPN-destined requests.
Is there some configuration magic around to handle this that you know of?
Posted Sep 25, 2025 23:53 UTC (Thu)
by ebiederm (subscriber, #35028)
[Link] (3 responses)
ip netns allows for that. I don't know about systemd-networkd
Posted Sep 26, 2025 3:15 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Which reminds me that I need to also fix `resolv.conf` so that things are happy too. If it is a symlink, the `ip netns exec` mount namespace is broken when the target `resolv.conf` is rewritten with a "write then rename into place"; `cat newresolv.conf > /etc/resolv.conf` works though.
Posted Sep 28, 2025 1:49 UTC (Sun)
by ebiederm (subscriber, #35028)
[Link] (1 responses)
If my memory serves the code just walks through the configuration directory and bind mounts every thing in it, into /etc.
Posted Sep 28, 2025 2:55 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Sep 26, 2025 0:19 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (2 responses)
I don't think systemd-resolved is network namespace aware, and I'm not familiar with any tricks in that area. But that's a hugely niche use-case, and not what I was defending. Normal "split DNS" is when you have multiple network interfaces with disjoint sets of routes in a single network namespace.
Posted Sep 26, 2025 3:17 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Sep 26, 2025 8:38 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
Posted Sep 24, 2025 9:44 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link] (8 responses)
So, choose your poison, good easy to maintain config files, or solid networking system with less fortunate config files
Good easy to maintain config files are really attractive in a headless server environment, people want to provision reference config files via ansible & co instead of toiling at the cli like in the bad old Cisco-centric 2000’s networking days. NetworkManager’s emphasis on nmcli is really unfortunate, a NetworkManager with a networkd config backend would make a killing.
Posted Sep 24, 2025 10:09 UTC (Wed)
by paulj (subscriber, #341)
[Link] (6 responses)
https://www.networkmanager.dev/docs/api/latest/nm-setting...
Posted Sep 24, 2025 10:56 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link] (5 responses)
Posted Sep 24, 2025 13:20 UTC (Wed)
by joib (subscriber, #8541)
[Link] (4 responses)
The support for old-school Redhat ifcfg- files has AFAIU been removed.
Posted Sep 24, 2025 13:22 UTC (Wed)
by joib (subscriber, #8541)
[Link] (3 responses)
Per that document, the keyfiles should support the full featureset of NetworkManager.
Posted Sep 24, 2025 14:11 UTC (Wed)
by nim-nim (subscriber, #34454)
[Link] (2 responses)
Instead of all uppercase ifcfg variables you get all lowercase variables (with is arguably nicer but short of the tasteful capitalization networkd-side that improves legibility).
The keyfiles are structured but the doc is still unstructured registry-style.
Some properties use - as separator, others _
Networkmanager still writes optional properties with default values instead of limiting itself to things where a specific value has been set (the meaningful part of the configuration).
It very unfortunately names all wired connexions “Wired connexion X” with X some non deterministic value (à la Windows) instead of using something reliable such as the interface name (when in fact each “Wired connexion X” is locked to a specific interface). Even worse the naming is not in fact “Wired connexion X” but a localized string that will wreak havoc with automation (reminds me of all the awful XDG variables that most everyone ignores to hardcode simple consistent .config/.cache/etc everywhere)
And so on, I won’t even get into the advanced wildcard tricks networkd configuration inherits from systemd
Nothing is completely awful but it falls very short of the syntaxic care and maturity exhibited networkd-side.
Posted Sep 24, 2025 16:25 UTC (Wed)
by anselm (subscriber, #2796)
[Link] (1 responses)
This, plus configuration files work the same across all of systemd. That level of consistency alone is worth the price of admission, compared to the traditional setup where every single component had its own unique configuration file format.
Posted Sep 25, 2025 11:12 UTC (Thu)
by kpfleming (subscriber, #23250)
[Link]
Posted Sep 26, 2025 16:04 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
For software I choose the one which is "as simple as possible, but not simpler".
That means systemd-networkd in simple, static network configurations and NetworkManager on laptops with wifi, VPNs and what not.
Posted Sep 25, 2025 22:15 UTC (Thu)
by intgr (subscriber, #39733)
[Link] (7 responses)
I'm not sure, that part might be abandonware. You would think that if it was maintained, not corrupting user data world be high on the list of priorities.
A year ago I had an incident where during a regular system shutdown, the systemd-homed resize operation took too long and got killed due to timeout. Result was a corrupted partition table inside the user home image and I could no longer access my data.
OK, bugs happen, but what baffled me was that to this day, no systemd developers have acknowledged or reacted the bug report, despite reports from other users also being affected.
Thankfully after a few hours of struggling, I managed to mount the image and could recover my data. But to this day, I still hold my breath every time I restart my system that this bug doesn't hit again.
Posted Sep 25, 2025 23:39 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (6 responses)
Thus, whichever freaky bug you encountered is not reproducible. So what should the maintainers actually do, other than say "yeah it's a strange case of data corruption but if we don't see a pattern, much less a reproducer …" and leave it open?
Posted Sep 25, 2025 23:57 UTC (Thu)
by koverstreet (✭ supporter ✭, #4296)
[Link]
To start, you look at all the information you have available; in this case that'd mean looking at the corrupted partition table - hexdump if necessary - to see if you can spot any patterns or deduce anything about what happened.
Sometimes that can tell you all you need to know; I once saw a guy deduce just from a hexdump of some memory corruption that it was an errant memmove that shot past the address it was supposed to stop at - he spotted that everything had been shifted by 8 bytes - and then from that, found the exact line of code that caused it (an open coded memmove).
If that fails to identify the bug, you take what you do know and look for places where your code is weak and could be hardened; you look for ways to make entire classes of bugs impossible. This is on-disk data structures we're talking about; we don't have practical techniques for making entire codebases in systems languages bug free, but we absolutely can identify ways to limit damage and make sure that on disk data structures aren't corrupted.
Posted Sep 26, 2025 0:15 UTC (Fri)
by intgr (subscriber, #39733)
[Link] (4 responses)
Incorrect assumption. Systemd-homed regularly resizes images/partitions to rebalance the disk space available between multiple users.
Particularly, btrfs can only be shrunk when unmounted, but obviously needs to be done when encryption keys are still available, so it frequently happens during system shut down.
> something that merely hangs,
It's not a "hang". The resizing can take a few minutes even on fast SSD if lots of data needs to be relocated.
Posted Sep 26, 2025 0:44 UTC (Fri)
by intelfx (subscriber, #130118)
[Link] (1 responses)
Without commenting on the rest of the analysis, that's not true.
Posted Sep 26, 2025 7:08 UTC (Fri)
by intgr (subscriber, #39733)
[Link]
Posted Sep 27, 2025 10:55 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (1 responses)
Ah. Thanks for the correction.
One might assume that it was an SSD that was powered down during writing. In this case all bets are off. Don't Do That.
Thus there needs to be an "work in progress, do NOT shut down" dialog/message/whatever. (Assuming that systemd doesn't time out the resize.)
Posted Sep 28, 2025 1:18 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Sep 26, 2025 17:17 UTC (Fri)
by kreijack (guest, #43513)
[Link] (5 responses)
I agree. Is a too big project with a too wide scope. Am not saying that it there are "bad" parts; the problem is that all the parts are coupled, and this is source of scalability problem:
I think that dividing systemd in different sub-projects separated by a clean/clear interface, would speed up the development, and open the cooperation with different projects that may provide more specialized tool for vertical case.
Posted Sep 26, 2025 19:33 UTC (Fri)
by NAR (subscriber, #1313)
[Link] (3 responses)
Not necessarily. Currently if they want to change such an interface, they can do it "in house", update both (all) sides at the same time (maybe even in the same commit? - I'm not familiar with the systemd codebase). If there are (more or less) independent (sub)projects, then it will take inter-project coordination which is always slower. And possibly keeping around technical debt for backwards compatibility.
Posted Sep 28, 2025 23:35 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
But is this "as simple as possible, but no simpler"? If it isn't then you have a problem full stop.
If you have to do it "in house", you need to ask the question "why". And if you don't have an answer, you need to fix it.
Cheers,
Posted Sep 29, 2025 1:41 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
Presumably because it's easier and more convenient to do it that way.
Having said that, the systemd developers do document a number of their internal interfaces,
so it should be possible, at least in principle, to come up with alternative implementations of some of its components
(but again, we would want to ask the question “why”, especially when improving systemd itself is also an option).
Some people may argue that the specific interfaces that they are interested in are not (yet?) documented,
but the reasons for that are probably best discussed with the systemd developers themselves.
Posted Oct 2, 2025 16:57 UTC (Thu)
by kreijack (guest, #43513)
[Link]
Having small module simplify (==less time) the code comprehension and the check of the change impact. Because the code to inspect is smaller.
If you need to issue an urgent change (a bug, a security fix), it is enough to audit only the involved portion of the code.
NB: despite what I wrote above, I think that systemd code has a very quality with an extensive use of modern technique to simplify the development (e.g. the __cleanup__ macro).
Posted Sep 27, 2025 18:11 UTC (Sat)
by mbunkus (subscriber, #87248)
[Link]
I disagree. Splitting in such a way would require more effort (for coordinating releases, for implementing/testing/documenting/maintaining the interfaces you're talking about etc). If the same developers are interested in working on the various split components that're currently working on the umbrella project, the speed of development of new features will go down.
Your statement assumes that after splitting there will be a net inflow of developers providing more work, just to offset the aforementioned new overhead, never mind speed up development. "Net inflow" because there might also be developers who prefer to work on a big umbrella as it is now & will reduce their work as a result.
I would really be interested in actual studies of development speeds in more monolithic vs split-up projects (and where the difference is due to project size and not due to factors such as the monolithic project having too many a**holes on its team), though I doubt it due to how incredibly difficult it would be to have comparable data. Is there even anecdotal evidence from past/ongoing situations? Really curious.
Posted Sep 23, 2025 18:33 UTC (Tue)
by lunaryorn (subscriber, #111088)
[Link] (51 responses)
> I VIOLENTLY disagree with that.
A message like this would be borderline unacceptable within any "professional" setting, but directed at an unpaid volunteer it's just gross, no matter what one things about the quality of the volunteer's work. You just don't talk people like that, and you don't demand free labour in all caps.
If you live on that level of entitlement and want that level of support buy an enterprise distribution, and yell at their support if things go wrong; they at least get paid to read shit like that.
Posted Sep 23, 2025 18:45 UTC (Tue)
by Trou.fr (subscriber, #26289)
[Link] (5 responses)
Posted Sep 23, 2025 20:51 UTC (Tue)
by lunaryorn (subscriber, #111088)
[Link] (3 responses)
I just clicked the link to the bug report in the article, as an outsider, and more or less immediately stumbled over really bad messages. While frustration can explain some of these to some degree, I believe it's no excuse for most of these messages and the behaviour exhibited by them.
On second thought, I guess what sort of shocked me really is that this tone and this way of communicating appears to be absolutely normal to all participants (except for the maintainer). There's no opposition, let alone moderation, and even the worst messages go absolutely unchallenged.
I wouldn't want to work in an environment as toxic as what I've seen in that bug thread, and I'm sort of in awe that there are actually people who volunteer their time to deal with that. And I can't help but believe that a certain amount of dismissive behaviour on the side of the maintainer is simply an acquired defence against such an environment. What goes around comes around as they say.
Posted Sep 24, 2025 11:54 UTC (Wed)
by jhe (subscriber, #164815)
[Link] (2 responses)
The systemd developer got Baratt's mail wrong, wrote an inflammatory dismissal and set the precedent for the toxic tone themselves. The thread was fine before that.
Posted Sep 24, 2025 17:08 UTC (Wed)
by lunaryorn (subscriber, #111088)
[Link] (1 responses)
I can only guess that it's not the first time the package maintainer had to deal with stuff like this, so I totally understand (understand, not excuse, mind you) a certain dismissive attitude acquired from having gone through many such unpleasant interactions.
Posted Sep 25, 2025 13:09 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Sep 24, 2025 0:05 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link]
When you see things as heated as this, there's always a backstory, and it's often well worth it to follow that backstory and ask why things got to that point.
When people in a position of responsibility are checked out, heedless of the consequences of poor decisionmaking, and ignoring all feedback - things deteriorate fast.
Posted Sep 23, 2025 19:02 UTC (Tue)
by mb (subscriber, #50428)
[Link] (37 responses)
Correct.
Just revert the breaking voluntary free labour change that broke stable.
Saying that
is an obviously incorrect thing to do during a stable release.
Free labour doesn't mean that you get to break something without handling the consequences.
Posted Sep 23, 2025 20:07 UTC (Tue)
by lunaryorn (subscriber, #111088)
[Link] (35 responses)
You'll find that my comment was concerned not with the quality of maintenance or the overall handling of this bug, but exclusively with the user's behaviour. I'm not interested in a discussion about whether the maintainer handled the bug appropriately or not, which is precisely why I did not comment on it, and which is why I'd appreciate if you'd either reply on the actual point of my comment, or just not at all.
If you have nothing to say about the behaviour of the users in that thread, silence is an option.
Posted Sep 23, 2025 20:16 UTC (Tue)
by mb (subscriber, #50428)
[Link] (5 responses)
I replied to all of your comment. I just don't quoted all of it for netiquette reasons.
Posted Sep 23, 2025 20:34 UTC (Tue)
by lunaryorn (subscriber, #111088)
[Link] (4 responses)
All I was commenting on was the reaction of the users, and how I find it in appropriate, gross really, "no matter what one thinks about the quality of the volunteer's work" (to quote one of the more relevant parts of my original comment).
Yet, you commented on the quality of the volunteer's work and the "correct answer" and how none "get(s) to break something without handling the consequences".
From my standpoint, there's not much of a connection between my comment and your reply. I tried to clarify that but that clarification was apparently lost on you. Do forgive me for believing that you didn't read what I wrote; it's just the only explanation I have for the disconnect between my comment and your reply to it.
Posted Sep 24, 2025 6:30 UTC (Wed)
by mb (subscriber, #50428)
[Link] (3 responses)
Yes, that's what you wrote in the first comment.
>I don't think you did. Twice. [..]
This is a rude reply, btw.
Posted Sep 24, 2025 6:33 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link]
Posted Sep 24, 2025 7:06 UTC (Wed)
by lunaryorn (subscriber, #111088)
[Link]
I'm sorry for having come across rude, please do accept my apology. I guess this shows how hard it is to live up to one’s ideals. In my defence at least I didn't use all caps :) Again, sorry for those parts of my comment, I hope we're good again. No hard feelings?
Posted Sep 24, 2025 11:20 UTC (Wed)
by bluca (subscriber, #118303)
[Link]
This never happened, fixes were ready and waiting before anyone even noticed or knew about it. Timeline with receipts: https://lwn.net/Articles/1039157/
Posted Sep 24, 2025 0:08 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link] (26 responses)
I think a lot of us have seen it and are quite a bit more concerned with the maintainer's behaviour.
If a maintainer is going to ignore bug reports and play the victim when people get angry, we need a new maintainer.
Posted Sep 24, 2025 3:47 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
...I hear Jia Tan is looking for another gig.
Posted Sep 25, 2025 2:41 UTC (Thu)
by mirabilos (subscriber, #84359)
[Link] (1 responses)
Posted Sep 25, 2025 7:23 UTC (Thu)
by chris_se (subscriber, #99706)
[Link]
You are using humor to do nothing else than insult someone. That's not a strongly worded disagreement, that's a personal attack, and in my opinion that IS crossing a line.
The other message criticized a specific action (or set of actions), here you are disparaging the totality of all contributions someone ever made. Messages such as this make the life of those who want to express their disagreement without personal attacks so much harder. In my opinion your statement here is much, much worse than the dismissiveness to the impact and severity of the bug shown from the other side.
Posted Sep 24, 2025 4:42 UTC (Wed)
by lunaryorn (subscriber, #111088)
[Link] (22 responses)
That's fine, but why reply to me with that concern when I did not comment on that at all?
> If a maintainer is going to ignore bug reports and play the victim when people get angry, we need a new maintainer.
If that had evidently happened, I might agree with you, but things are not that clear (they seldom ever are) and I interpret that situation quite differently.
But I believe we have very different ideas of "clear basic professionalism and understanding of our responsibilities" (your words), and whom we expect it from, which probably makes us see this situation from very different standpoints, and personally I must admit that I'm very happy to work in environments and communities where your standpoint is not prevalent.
Posted Sep 24, 2025 5:11 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link] (21 responses)
I hope nobody has to rely on your work for anything critical!
In my community, I take a firm stance that responsibilities and clear and accurate communication come first; the point of what we do is to deliver code that people can trust and rely on, and if there's a screwup we need to know about it - and that generally means it'd be my screwup, the buck stops with me.
I've explicitly stated on quite a few occasions if my code screws up and ruins someone's day, I don't care if the bug report comes with swearing; or if someone working on my code has a good frustration filled rant - I want to hear it, and I'm going to bake and mail a plate of cookies to the first person that has a good (i.e. actual information content) rant about my code.
Strangely enough, this builds an atmosphere of trust, and I find things tend to stay pretty calm and relaxed among those of us who actually work together.
You have to accept that mistakes _will_ happen, and those mistakes can ruin people's days - or weeks - and if you're prioritizing your own work environment and safety cocoon to the point you don't want to hear about that, you're just pushing the problem elsewhere and eventually it's going to come back to bite you.
Like this poor guy.
Posted Sep 24, 2025 7:18 UTC (Wed)
by lunaryorn (subscriber, #111088)
[Link] (20 responses)
I certainly don't do and wouldn't want to do critical work unpaid in my own free time. I wouldn't like to be on the receiving end of messages such as the one I quoted, after having volunteered my time to build something people can use for no charge.
Professionally, I do work on critical systems, and strangely enough, I find that we can build a culture of responsibility and mutual trust without swearing, by being nice and kind to reach other, and treating or peers as we'd like to be treated ourselves. Perhaps that's the corporate world you were talking about elsewhere, but when the alternative is this, I rather take corporate culture any day.
Posted Sep 24, 2025 11:59 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (5 responses)
> I certainly don't do and wouldn't want to do critical work unpaid in my own free time. I wouldn't like to be on the receiving end of messages such as the one I quoted, after having volunteered my time to build something people can use for no charge.
That's fine. We have a 2x2 grid here. People who do and don't work on mission critical stuff. People who do and don't do it in their own time. You say you're quite happy NOT to be in the quadrant "Mission Critical, Own Time". I'd hate to be in it, too.
The problem is people who (a) ARE in that quadrant, and (b) throw a hissy fit when notified about a bug.
My personal attitude is if you're working on Mission Critical, then Own Time should not enter the equation. Equally, while professionalism comes into it, provided the reporter doesn't abuse *me*, I don't care about language. People get frustrated, people have to vent, let them get over it and then you can fix the problem, which is the most important thing.
Thing is, if the people on *both* sides of bug report get heated, that's when things go wrong. My real bugbear is when people are so busy shouting "fix it", they are completely unable to hear me saying "fix what!?". And when I do nothing they just scream even louder. If someone is screaming, you both need to shut up and take a step backwards.
Cheers,
Posted Sep 25, 2025 19:53 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (4 responses)
I have *never* seen anyone speak to me, or any of my colleagues, in such a disrespectful tone as the message quoted upthread, no matter how bad things were. From where I sit, it is a matter of simple observation: You do not need to be rude in order to work on mission-critical systems, and that fact does not change just because the fecal matter made contact with the Aperture Science Rotational Airflow Enhancing Device.
Of course, the difference is that Google can and does fire people who make a habit of being rude (and fail to respond to lesser interventions). Internet communities, as a rule, are significantly worse at doing that.
(Disclaimer because there will otherwise be a slew of replies claiming that I'm trying to justify how bluca handled this bug: I am doing no such thing. It is entirely possible for both parties to be in the wrong here. If you want to argue over bluca's handling of the bug, take it to a different sub-thread, because I frankly do not care.)
Posted Sep 25, 2025 20:23 UTC (Thu)
by koverstreet (✭ supporter ✭, #4296)
[Link] (2 responses)
It's wonderful for the people who get to work there.
But you, like a lot of people, are focusing on rudeness as the issue, when a lot of us are going "uh, machines going down on update, intransigent maintainer with a pattern of not acknowledging or fixing his own mistakes, blame shifting, and forcing other people to cover - yeah, I'd be pissed too".
Do you think people at Google would maintain their calm demeanor if you had to keep everything running while dealing with that?
I think you might have cause and effect a bit backwards :)
Posted Sep 27, 2025 19:56 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Yes, because if you care about any success metric, then communication is the most important thing by far. Building something exceptional _alone_ never goes anywhere. I mean it can be fun and beautiful but that's all. If it's really exceptional _and_ re-usable, then it's sometimes rescued by other people who can work together. And then the "inventor" complains he was misunderstood. He was. Often it stays unused on the shelf. Everyone can admire it but that's all.
No maintainer is perfect, very far from it. But any widely distributed component is direct evidence that the maintainer has at least the most basic communication skills. If not, then either the maintainer or the component gets forked or replaced sooner or later. Simple as that. The same cannot be said about entitled users shouting on the Internet, there's just no evidence on their side.
> Do you think people at Google would maintain their calm demeanor if you had to keep everything running while dealing with that?
They would stay professional long enough for the problematic person to be demoted or transferred to another place better suited for them. If that does not happen or takes too long, then professional people try to find a another job in a proper workplace.
Posted Sep 28, 2025 12:37 UTC (Sun)
by smurf (subscriber, #17840)
[Link]
Two sides of the same coin, effectively.
The point is that you need to get rid of the whole coin, i.e. "fix" both sides (for whatever value of "fix"), if you want to get a handle on the problem.
Posted Sep 25, 2025 21:14 UTC (Thu)
by madscientist (subscriber, #16861)
[Link]
I try to follow the old internet protocol advice "be strict in what you send and lenient in what you receive", when dealing with other people. You never know what is happening in someone's life. The question is not whether this particular comment is abrasive. The question is, is this a pattern of behavior or is it an aberrant, in the moment reaction? If it's a one-off, give grace and look the other way. If it's a pattern of behavior then something should be said. If it keeps happening after that, then something needs to be done.
But that goes for the maintainer, too, not just the commenter. I think it's disingenuous to concentrate only on one side of the conversation. It's idealistic, not realistic, to say "it doesn't matter what one side does, there's no excuse for the other side to behave in anything less than a fully professional manner".
Posted Sep 24, 2025 14:27 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link] (10 responses)
You're missing the cause and effect here.
In the open source world, where no one can get fired for screwing up, having a culture based on responsibility is even more important than in the corporate world (though still important there, I'd say!).
If you build your culture on "I'm only going to interact with people who are nice to me" - that's not the culture of responsibility you want, and you'll find lack of accountability leads to lack of trust, which leads to exactly the sort of drama this LWN article is talking about.
If you build your culture on "taking responsibility for our work comes first", then you'll find people are a whole lot nicer to you.
Posted Sep 24, 2025 15:34 UTC (Wed)
by pizza (subscriber, #46)
[Link] (6 responses)
....This goes both ways, because the *user* also shoulders a burden of responsibility too.
> If you build your culture on "taking responsibility for our work comes first", then you'll find people are a whole lot nicer to you.
That may work amongst "peers" (ie other developers) but end-users don't care about that.
I absolutely "take responsibility" for my work. But that is going to happen on *my* schedule/availability, completely detached from your sense of urgency. You don't like that? <taps on the "PROVIDED AS-IS, NO WARRANTY WHATSOEVER" sign>. You are not buying from a supplier, you are a raccoon digging through dumpsters for free code. [1]
Posted Sep 24, 2025 15:46 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link] (2 responses)
Because code doesn't get to be truly bulletproof without testing and QA, and that's done by users. Meaning, I need them, and I need them to be willing to go to the effort of filing good bug reports, and on complex bugs I need them to be willing to spend the time to work with me on chasing things down. Which means I have to be willing to send the time to work with them, it has to go both ways.
A "take it or leave it attitude" only works if you really don't need someone, otherwise it's a great way to make people not want to work with you.
Posted Sep 24, 2025 16:07 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
...Please keep in mind that you are among the very few that are paid to work on "your code"
The overwhelming majority of us are not, and that changes the equation considerably.
Posted Sep 24, 2025 16:22 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link]
A lot of people want to be a part of something like that.
Posted Sep 25, 2025 2:44 UTC (Thu)
by mirabilos (subscriber, #84359)
[Link] (2 responses)
And precisely that is what allowed it to reach such a well-accepted status in commercial environments.
Posted Sep 25, 2025 11:19 UTC (Thu)
by kpfleming (subscriber, #23250)
[Link]
Posted Sep 25, 2025 12:38 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Pray tell, where can this "guarantee" be found? Because Debian's "social contract" [1] provides nothing of the sort.. and isn't legally binding anyway.
Posted Sep 24, 2025 17:16 UTC (Wed)
by lunaryorn (subscriber, #111088)
[Link] (2 responses)
I guess I understand what you're trying to say, but no amount of arguing is going to convince me that swearing and being yelled at is essential to building a culture of responsibility in open source.
Or, to put it another way, if it is really necessary to build a culture of responsibility, as I believe you're trying to argue, then I firmly believe something's seriously wrong in open source, and, pardon me for saying that, I'm all the more happy that I'm not part of this open source thing.
Posted Sep 24, 2025 17:51 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link] (1 responses)
Well, good for you then?
Posted Sep 24, 2025 18:02 UTC (Wed)
by jzb (editor, #7867)
[Link]
Posted Sep 24, 2025 14:48 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link] (2 responses)
"Being nice" means doing our work well, so that other people can rely on it instead of having to spend a bunch of time recovering from our mistakes, and taking responsibility for our mistakes when they do happen.
If you want to talk about "being nice", you have to include that. Otherwise you're saying - "I can do whatever quality of work I feel like and you guys just have to put up with it, neener-neener!". No thank you :)
Posted Sep 25, 2025 13:24 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
While I am more-than-typical to harp on code quality and maintainability, there is a definite difference between the level of quality one can expect from a back-burner project to one that has a salary-like funding behind it. For example, I have have a number of projects on Github that have external users. But I do not have the time to *support* these users beyond things that also scratch my itch or answering questions in issues. This is where the NO WARRANTY clause really comes into play. You're running bcachefs as a project that you *want* to be used far-and-wide and are, appropriately, taking things as seriously as one should when it comes to code quality (nb. I have not actually looked at bcachefs code to vet it on my own scale, but will take your word for it). But for a tool I publish the source for (because I believe in publishing such code) that I use to help with task juggling? Patches welcome, but if it interferes with my workflow, feel free to fork.
Posted Sep 25, 2025 13:51 UTC (Thu)
by koverstreet (✭ supporter ✭, #4296)
[Link]
Only some open source software is critical infrastructure, and it's of course a very broad spectrum. Some little library might turn out to be useful and start getting used all over the place, and if you were never expecting or planning for that... well, that's a whole 'nother topic on things we haven't yet learned how to deal with :)
We really do need better funding and support structures in place, assuming businesses will fund the stuff they need doesn't work because businesses are always focused on their quarterly bottom line. Europe's making baby steps in this direction, but we have a long way to go.
But if you're explicitly writing code for a domain that has a prior history of being critical infrastructure, the expectations are high. There are real consequences - for other people - for going in and claiming a job as yours, and then doing it badly. If you're not up to the job, that's ok! let it wait for someone else to tackle it!
Posted Sep 24, 2025 2:55 UTC (Wed)
by interalia (subscriber, #26615)
[Link] (1 responses)
That seems overly aggressive, tone-wise, which is broadly the criticism you yourself were making about that email.
Whether or not they misread your comment, is the above really justified?
Posted Sep 24, 2025 4:44 UTC (Wed)
by lunaryorn (subscriber, #111088)
[Link]
Posted Sep 25, 2025 2:40 UTC (Thu)
by mirabilos (subscriber, #84359)
[Link]
Posted Sep 23, 2025 19:03 UTC (Tue)
by npws (subscriber, #168248)
[Link] (1 responses)
Posted Sep 23, 2025 20:13 UTC (Tue)
by lunaryorn (subscriber, #111088)
[Link]
What I'm saying is that the quoted message in particular, but also quite a few others, are entirely inappropriate in and by themselves, regardless of any valid criticism.
Is that what you disagree with? Do you believe that the quoted message is an appropriate way of talking to someone?
Posted Sep 24, 2025 15:21 UTC (Wed)
by chris_se (subscriber, #99706)
[Link] (2 responses)
I only see one thing in that message that I could consider objectionable, and that would be the word "VIOLENTLY" - I would have preferred if that had been "vehemently" or something similar. And if your only objection is to that word: fair, that shouldn't have been there in my opinion.
But the rest of the message you quoted?
The second paragraph you quote is completely neutral and I can't see what you could even remotely find objectionable about that.
And the final paragraph is definitely very strongly worded, no doubt, but even here I don't see how that is over the line.
You are of course completely right that nobody can demand free labor. And if Luca had just said: "hey, I don't have the time for this right now", or "systemd-networkd is too much outside of my wheelhouse", or even "I really need help with this", I don't think people would have been up in arms about that. Rather it's the dismissiveness over both the severity of the issue and the amount of users affected that caused the strong reactions.
Posted Sep 24, 2025 17:02 UTC (Wed)
by lunaryorn (subscriber, #111088)
[Link]
The all caps yelling, the wording ("violently disagree", "insultingly", ...), and the overall entitlement in that quote are pretty far over my line when it comes to talking to an unpaid volunteer, especially since I presume that specific user is using Debian in a commercial setting (judging from their talk about "professional environments"). And judging by the article the maintainer also felt that some comments were over their line.
As said elsewhere in my opinion you can probably talk like that to someone you pay (a lot), but just not to someone you're not the least way compensating for their work, regardless of what you think about the quality of that work.
But I already learned from other responses that my line is quite different from other people's lines here, so we probably don't need to continue here, as we likely end up agreeing to disagree anyway. I'm still slightly shocked at that, but then again it doesn't really concern me. I don't do much open source beyond personal pet projects anymore, and where I work we luckily communicate quite differently.
But if that's what you're expected to deal with when volunteering your time to maintain things, I'm not surprised that it's hard to find maintainers these days.
Posted Sep 25, 2025 2:47 UTC (Thu)
by mirabilos (subscriber, #84359)
[Link]
Posted Sep 25, 2025 2:39 UTC (Thu)
by mirabilos (subscriber, #84359)
[Link]
Posted Sep 29, 2025 16:09 UTC (Mon)
by jubal (subscriber, #67202)
[Link]
Posted Sep 23, 2025 19:55 UTC (Tue)
by bluca (subscriber, #118303)
[Link] (4 responses)
- the issue was fixed by the networkd maintainer and merged by me on Aug 8th https://github.com/systemd/systemd/pull/38519
As of today, the update is of course _not_ available in stable yet (https://ftp.debian.org/debian/dists/trixie/main/binary-am...). That's because the debian stable releases have a fixed cadency, which is pre-announced: https://release.debian.org/ so as I explained in the bug to much uproar, the next release 13.2 on November 15th (Sep 8th + 2 months == November) will contain the fix. That still holds true. Playing games with the severity of a ticket does not change this, it does not make things happen faster or better, and basically has no real practical implications. It is however a well-known and well-abused way to bash volunteers who work for free, but never enough of course.
The only practical implication of the stream of private, semi-public and public abuse is that... the 13.2 point release will have fewer bug fixes that it would otherwise have had, and the upload was available in proposed-updates a day later than it could have otherwise been.
Posted Sep 23, 2025 21:25 UTC (Tue)
by SLi (subscriber, #53131)
[Link]
That's why the "minor issue" framing is hard to defend. Losing networking is a serious impact for those affected, even if the configuration is uncommon, and communication shaped how people judged the project's responsiveness. The NMU was a proximate consequence of that perception, not an arbitrary attack.
In other words: the regression and the process were understandable, but the tone was the one preventable factor that turned a routine regression into a reputational storm.
Posted Sep 23, 2025 22:56 UTC (Tue)
by pkern (subscriber, #32883)
[Link] (2 responses)
As the person who opened up stable to more fixes years back, it was always done with an assumption that there is a minimal risk of regressions. This has always been the stable policy. So we need to own up when we do cause one - and any security update that causes a regression is also followed up on. I think here there is a question what the policy should be wrt such a central component - and a lack of a pre-point release testing regime that we hoped could at least be saved by the manual calls for testing. Here the breakage was missed, attributed to the wrong version, and no escalation happened to pull the update or to fix it before the point release.
Relatedly we now noticed that a lot of people (including Debian Developers) don't seem to know about -updates. So there is a gap that we need to address. It has been configured by default by automated installation processes, but there is surprisingly little to no user documentation about it. It replaced the archive volatile at the time and that's how we communicated it.
But a lot of these decisions are for the current release team - I'm not actually an SRM anymore even if the article claims that.
Posted Sep 24, 2025 2:19 UTC (Wed)
by jzb (editor, #7867)
[Link] (1 responses)
I'm not actually an SRM anymore even if the article claims that Apologies for the error, I tried to find an updated list of SRMs. I did find an article/interview with you as an SRM, my bad for assuming you were still in that role.
Posted Sep 24, 2025 8:47 UTC (Wed)
by ganneff (subscriber, #7069)
[Link]
Posted Sep 24, 2025 7:34 UTC (Wed)
by taladar (subscriber, #68407)
[Link] (2 responses)
On the one hand a component which is not used as the default for that type of component and which has a breaking bug that needs a fix to be usable by the affected users.
On the other hand someone from the stable camp who argues that bug fixes should only be released at a point in the relatively far future, one that will essentially force these users to switch to something else in the meantime justifying the position that priority bug fixes aren't necessary here with the non-default (or in bcachefs case experimental) status of the affected component.
And the main discussion also seems about tone in both cases rather than talking about ways to reconcile these different requirements.
Posted Sep 24, 2025 9:25 UTC (Wed)
by ballombe (subscriber, #9523)
[Link] (1 responses)
I do not see how the Debian stable team delayed the bug fix against the opinion of the package maintainer in this instance. It seems more to be the opposite.
Posted Sep 24, 2025 15:33 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link]
Posted Sep 24, 2025 15:44 UTC (Wed)
by shemminger (subscriber, #5739)
[Link] (9 responses)
Yes, I am biased (as iproute maintainer) but having so many overlapping packages is just madness.
Posted Sep 24, 2025 15:53 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link] (8 responses)
they're not hard if you don't overengineer them. 10-20 lines of bash per test (bash is gross for anything that needs proper error handling, but that's what I'm still using), bring up a configuration, do some basic network connections/write some data in fio verify mode, verify that nothing explodes and there's no errors.
I don't subscribe test driven development, and I barely ever write unit tests. But having a decently comprehensive set of functional tests just makes life so much easier.
Posted Sep 24, 2025 16:08 UTC (Wed)
by pizza (subscriber, #46)
[Link] (7 responses)
They're a lot harder when you're talking about non-trivial network configurations that necessarily involve external kit that also needs to be properly configured.
Posted Sep 24, 2025 16:24 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link] (6 responses)
Posted Sep 24, 2025 16:46 UTC (Wed)
by pizza (subscriber, #46)
[Link] (5 responses)
Then it's no longer "10-20 lines of bash code"
Posted Sep 24, 2025 18:57 UTC (Wed)
by koverstreet (✭ supporter ✭, #4296)
[Link] (4 responses)
Posted Sep 25, 2025 23:32 UTC (Thu)
by smurf (subscriber, #17840)
[Link] (3 responses)
Posted Sep 25, 2025 23:50 UTC (Thu)
by koverstreet (✭ supporter ✭, #4296)
[Link] (2 responses)
so until we get anubis going, there's a github mirror: https://github.com/koverstreet/ktest/
Posted Sep 27, 2025 11:18 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (1 responses)
I do wonder how long it'll take these *censored* to notice that each request now results in an identical 12-kByte result (1.2 on the wire, it's compressed) … in the meantime I bet we're going to get a veritable ton of random search hits (and AI chat replies) for basically anything that smells like Anubis' challenge page.
What was that curse again … "may you live in interesting times".
NB my log shows a marked increase in the number of AI bot requests since yesterday, which is not at all surprising: Anubis replies a whole lot faster than cgit.
Posted Sep 27, 2025 18:11 UTC (Sat)
by koverstreet (✭ supporter ✭, #4296)
[Link]
Now, they're all coming from different IPs - it's only a few accesses per IP - and the load was so bad the git fetches for the CI workers were unable to run. It ground my test infrastructure to a halt!
They're a bloody menace.
Although I'd also really like to know why git is so ridiculously memory hungry.
Posted Oct 2, 2025 15:31 UTC (Thu)
by wpeckham (guest, #179663)
[Link]
Since then Debian Stable has been seen as LESS stable increasingly with time.
The important question is not who to blame, or if users should or should not avoid DOCUMENTED AND SUPPORTED CONFIGURATIONS, it is "How do we avoid this kind of event in the future?".
Because we absolutely should be focused on that!
Hehe
Hehe
Hehe
1) From where is the quote? I'm not able to find it in the text above.
2) What should be the alternative to systemd?
Hehe
in Debian is network-manager for desktops and ifupdown for the rest,
so anybody demanding nothing less than perfection would do well to
stick to those defaults instead of being adventurous and then throwing
abuse when experimental things don't work."
Hehe
Hehe
Hehe
Hehe
Hehe
Hehe
Hehe
Hehe
(In)competence
Negative feedback = hostile atmosphere?
Negative feedback = hostile atmosphere?
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
(E)LILO was discontinued a decade ago and removed from Debian.
(E)LILO was discontinued a decade ago and removed from Debian.
(E)LILO was discontinued a decade ago and removed from Debian.
(E)LILO was discontinued a decade ago and removed from Debian.
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
https://www.freedesktop.org/software/systemd/man/latest/s...
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
>
> Is there some configuration magic around to handle this that you know of?
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Nothing is completely awful but it falls very short of the syntaxic care and maturity exhibited networkd-side.
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
Do not use non-core systemd
- if you have an issue with a component solved in a newer version you need to update all the components (even the one that works flawless)
- all the components can't rely on a defined interface but can access to any interface that they want. This prevent to replace a component with a more specialized component. For example I suspect that the binary format of the journal is inefficient, but it is complex to replace only this part because journald is integrated in systemd.
- I can understand that all the parts that can manage "events" should be integrated in systemd. But why (e.g.) sd-boot and homed should be integrated in the main project ?
I think that dividing systemd in different sub-projects separated by a clean/clear interface, would speed up the development
Do not use non-core systemd
Do not use non-core systemd
Wol
Do not use non-core systemd
If you have to do it "in house", you need to ask the question "why".
Do not use non-core systemd
Do not use non-core systemd
Some comments are just… beyond comment
>
> systemd-networkd is WIDELY used in professional environments, especially
> where VLANs and Bridges are in use, BECAUSE it can handle those
> configuration cases and does it in a way that is VERY convenient to
> configure with configuration management methods.
>
> […]
>
> I find your attitude to just shrug this away with "optional component"
> and "wait for the next point release" insultingly unacceptable.
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
This (or fixing the bug) is the only correct answer to this kind of breakage.
>this is just a minor issue with a particular corner case of a custom config
If your free labour broke something and you don't have the time to fix it, revert it.
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
And I find it appropriate to reply with clear words to clear breakage and to clear unwillingness to fix the breakage caused.
That was my reply to you. And I explained why.
>that clarification was apparently lost on you [..]
>you didn't read what I wrote [..]
>it's just the only explanation
They very thing you are complaining about.
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
I'm obviously not interested in coming after the maintainer and tried to put focus on an another aspect of the situation.
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Wol
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
> And precisely that is what allowed it to reach such a well-accepted status in commercial environments.
Some comments are just… beyond comment
Some comments are just… beyond comment
Let's stop here
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
Some comments are just… beyond comment
the actual problem is that boccassi is unpleasant to deal with in most public communication settings because of his communication style (abrasive, dismissive, frequently insulting). this is not the first time this behaviour created or increased friction, and made a simple, fixable issue into a flamefest.
and it doesn't matter if he's privately the loveliest of the nice people around; the image he projects publicly will overshadow that, and adds to the bad reputation of systemd maintainers' social skills.
Some comments are just… beyond comment
A few missing tidbits
- the downstream bug report was opened on Aug 30th but it did not contain useful triaging information, and it was not provided upon request, so it was not associated with the upstream issue (https://github.com/systemd/systemd/issues/38515) in time, and even the metadata was wrong
- the downstream proposed-updates pocket was locked by the release team as per the usual rules on August 30th https://lists.debian.org/debian-release/2025/08/msg00565....
- the upstream backport was prepared upstream by me on Sep 2nd https://github.com/systemd/systemd/pull/38793
- the downstream backport was prepared by me on Sep 3rd https://salsa.debian.org/systemd-team/systemd/-/commits/d... waiting for the pocket to reopen as per the rules
- on Sep 6th _after_ the 13.1 point release was done, the nature of the bug became clearer and could be associated with the upstream one https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1112535#25
- on Sep 8th the proposed-updates pocket reopened
- on Sep 9th at 10:05 AM I uploaded the previously prepared fixes https://alioth-lists.debian.net/pipermail/pkg-systemd-mai... https://bugs.debian.org/1114755
- on Sep 9th at 10:38 AM the uncoordinated, unscheduled, zero-communication non-maintainer-upload overwrote my upload, _reintroducing_ several bugs such as https://bugs.debian.org/1114787 https://alioth-lists.debian.net/pipermail/pkg-systemd-mai...
A few missing tidbits
A few missing tidbits
A few missing tidbits
A few missing tidbits
Same conflict as bcachefs?
Same conflict as bcachefs?
Same conflict as bcachefs?
Too many ways to configure networking
Having so many ways to do this leads to lots and lots of ways to configure things that never get tested.
Too many ways to configure networking
Too many ways to configure networking
Too many ways to configure networking
Too many ways to configure networking
Too many ways to configure networking
Too many ways to configure networking
Too many ways to configure networking
Too many ways to configure networking
Too many ways to configure networking
Stability
That was before SystemD was adopted.
This may be more perception than reality, or not, but events like this one do NOT help!