Bug of feature? [LWN.net]

Bug of feature?

Posted Jun 30, 2026 16:22 UTC (Tue) by rgmoore (✭ supporter ✭, #75)
In reply to: Bug of feature? by bronson
Parent article: Xsnow "protestware" in Debian

There's a critical difference: baby mulching machines were a deliberately absurd hypothetical, but the behavior of xsnow is real. The easter egg was discovered because it showed up on a real world computer. Even if you accept that the danger to people's well being is a result of Russian government persecution, there's still a real question about whether this general kind of behavior ought to be accepted.

to post comments

Bug of feature?

Posted Jun 30, 2026 16:56 UTC (Tue) by farnz (subscriber, #17727) [Link] (8 responses)

The challenge is deciding where the line is - if, for example, my country passes a law that says that putting the work "gnome" on a screen is offensive, and punishable by death, should Debian then remove GNOME from the repositories?

When a ban on the possession of "hacking tools" was proposed (which later got watered down sensibly to "possession with intent to commit an offence"), should Debian have removed tcpdump, aircrack-ng, nmap and other packages that could reasonably have been deemed "hacking tools"?

Remember that the easter egg is not "display a Ukrainian flag"; it's "display it more frequently". So, if you're saying that Debian should not have software that could endanger someone in the Russian Federation's safety, you're implicitly saying that no Debian software should display the Ukrainian flag, since that's the problem action; should Debian include censoring software to prevent web browsers displaying a "bad" flag (such as the Ukrainian or Taiwanese flags) by default, that you need to configure off if you're OK with those flags being shown?

Bug of feature?

Posted Jun 30, 2026 17:25 UTC (Tue) by evgeny (subscriber, #774) [Link] (7 responses)

> The challenge is deciding where the line is - if, for example, my country passes a law that says that putting the work "gnome" on a screen is offensive, and punishable by death, should Debian then remove GNOME from the repositories?

I'm not sure your hypothetical example is any better than the aforementioned "baby-mulching" machine. But let's take this for granted. OK, there is such a country, obviously run by a demonic government. And now I create software (which doesn't have this in its description) that randomly displays this forbidden word on the screen. Moreover, out of my hatred of this government, I decided to show this problematic word much more frequently if the user happens to live in that country, thereby increasing the chances that the user ends their days sooner. Now, I want to hear your opinion: do you believe this is ethical?

> So, if you're saying that Debian should not have software that could endanger someone in the Russian Federation

No, I say that Debian should not have software that *specifically*, *intentially*, and *knowingly* could endanger someone in *any* place in the world.

Bug of feature?

Posted Jun 30, 2026 18:40 UTC (Tue) by pizza (subscriber, #46) [Link] (6 responses)

> No, I say that Debian should not have software that *specifically*, *intentially*, and *knowingly* could endanger someone in *any* place in the world.

Under this standard, most of Debian will have to be removed.

(remember, "intentionally" covers things that are _not_ implemented, such as age verification)

Bug of feature?

Posted Jun 30, 2026 19:00 UTC (Tue) by evgeny (subscriber, #774) [Link] (5 responses)

Really? Does Debian disable age verification specifically in regions that require it?

Bug of feature?

Posted Jun 30, 2026 19:50 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> Does Debian disable age verification specifically in regions that require it?

By _not implementing_ age verification in regions that require it (including by distributing software that does not, ie effectively everything in the archive), they are "endangering users" in those jurisdictions.

At this point, that "not implementing" is both *intentional* and *knowing*.

Another example, more concrete -- Debian includes 'torbrowser', use of which is criminal in many jurisdictions. Debian is therefore endangering those users, and by your logic, torbrowser should be yanked from the archive for everyone else.

Bug of feature?

Posted Jun 30, 2026 20:10 UTC (Tue) by evgeny (subscriber, #774) [Link] (3 responses)

Whether to use the Tor browser is at the user's discretion. Debian doesn't install it by default, nor makes it the default browser. And it certainly doesn't do it on purpose, specifically in the places where its use is forbidden. If you don't see the principal difference with the behavior of xsnow, I give up explaining my point. Let's close this thread.

Bug of feature?

Posted Jun 30, 2026 23:36 UTC (Tue) by pizza (subscriber, #46) [Link] (2 responses)

> Whether to use the Tor browser is at the user's discretion. Debian doesn't install it by default, nor makes it the default browser.

So what? By providing it, Debian knowingly endangers its users in some jursidictions. That's your standard, not mine.

Your standard would effectively reduce Debian to a tiny subset containing only what is allowed in the most restrictive jurisdictions.

> If you don't see the principal difference with the behavior of xsnow, I give up explaining my point. Let's close this thread.

The folks enforcing those laws don't care about nuance; your guilt is established by mere possession of that unacceptable (==illegal) software. Therefore even making them available is endangering those users, and as such should be excluded from Debian.

Welcome to the real world.

Bug of feature?

Posted Jul 1, 2026 0:42 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (1 responses)

I see some difference between someone researching into what is the Tor browser and later installing it, versus trying some funny game, which is described as

```
Description-en: brings Christmas to your desktop
Xsnow is a X Window application that will snow on the desktop background.
Santa and his reindeer will complete your festive-season feeling.
Xsnow runs in GNOME, KDE, FVWM and desktops that are derived from those.
```

If one installs Tor, they might be endangered, but they are most likely aware that they are or at least might be endangered.

If one installs xsnow or xpenguins, one wouldn't expect to be endangered in any way (other than maybe being fired for installing games at work, if your work fires people for that).

It is the awareness and expectation that is important.

Bug of feature?

Posted Jul 1, 2026 14:17 UTC (Wed) by bronson (subscriber, #4806) [Link]

If you're living in a situation where blue-over-yellow will land you in jail, then no general-purpose distribution is safe for you to run. None of them. Arguing over individual packages seems unproductive.

Bug of feature?

Posted Jun 30, 2026 17:08 UTC (Tue) by bronson (subscriber, #4806) [Link] (18 responses)

And the real answer is generally "this sort of behavior should be frowned upon." I think you won't find much disagreement among any group of developers.

Great. Now, how would you use that? Can you extrapolate from it to determine what to do about this particular xsnow feature? I can't.

The behavior of xsnow is real, yes... and inconsequential. Using it to strong-arm rules into place and force other people to do things doesn't seem like a reasonable response.

Bug or feature?

Posted Jun 30, 2026 21:50 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (17 responses)

I think the correct initial response is for the higher ups at Debian to have a polite talk with the Debian packager and ask them to remove the misfeature from the Debian version. If they refuse, they should be ordered to do so. If they continue to refuse, xsnow should be removed from the distribution. I also think this should be seen as a warning about the general class of problem, and Debian should write some kind of general rule/guideline for what to do the next time it comes up.

It's a little bit more complicated because the Debian packager is also the upstream maintainer, but I think Debian only has the right to control what's in their distribution. If the packager really wants to keep this upstream, they should have the option to keep it as long as it's removed from the version distributed by Debian. Other distributions can make their own decisions about what to do with the packages they distribute.

That said, I have some confidence Debian will eventually come up with a satisfactory decision. The democratic processes used by Debian can be very slow to play out, but they do a remarkably good job of making the right decision time after time.

Bug or feature?

Posted Jun 30, 2026 22:28 UTC (Tue) by bronson (subscriber, #4806) [Link]

Ah, well if the steering committee or whoever truly has nothing better to work on, then sure I guess? How wonderful would that be! Everything is in such good shape that they could justify turning thus silly little kerfuffle into such a big time-wasting deal.

Bug or feature?

Posted Jun 30, 2026 23:46 UTC (Tue) by pizza (subscriber, #46) [Link] (15 responses)

> I think the correct initial response is for the higher ups at Debian to have a polite talk with the Debian packager and ask them to remove the misfeature from the Debian version. If they refuse, they should be ordered to do so. If they continue to refuse, xsnow should be removed from the distribution. I also think this should be seen as a warning about the general class of problem, and Debian should write some kind of general rule/guideline for what to do the next time it comes up.

You have this backwards; the rule/guideline has to come first, before any arbitrary "enforcement" occurs.

> The democratic processes used by Debian can be very slow to play out, but they do a remarkably good job of making the right decision time after time.

The decision would only be "right" insofar as _any_ decision makes the course of action clear, putting an end to the issue. [1]

Relatedly, I can think of many [1] who would disagree as to the "correctness" of various GRs when the vote didn't go the way they wanted.

[1] Not counting the many times where the answer is (e) all of the above or (f) no decision
[2] eg so-called "Veteran Unix Admins". Granted, Debian was probably far better off after said VUAs angrily stomped off.

About the Devuan excision

Posted Jul 1, 2026 0:33 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (14 responses)

[off-topic]

I have both Debian and Devuan systems (both Sid), and the Devuan systems are significantly and consistently more stable. Every now and then (to be fair, not more than once a year, but that's way more than I'm used to) I get systemd bugs that prevent me from booting. I am planning to stop using vanilla Debian rather soon (whenever I find time to do it).

I didn't like how Debian acted back then, and wish it had kept better support for non-systemd. To some degree, I think the way the VUAs acted was warranted by the context. I think an option in pkgsel similar to the choice of desktop environment would be good; that's more or less what Devuan does.

And from my experience, I've seen the systemd maintainers be consistently hard to deal with and offensive. I also understand them, due to the attacks they've received in the many years they've been doing that, but they aren't much different from what they criticize, or at least that's what I observed. Having been bullied should not be a reason to treat others badly.

About the Devuan excision

Posted Jul 1, 2026 1:11 UTC (Wed) by pizza (subscriber, #46) [Link] (13 responses)

> I get systemd bugs that prevent me from booting.

In the ...15 years since Fedora switched to systemd by default, I can't ever recall ending up in a situation where a *systemd* issue prevented a system from booting. (As opposed to massive filesystem corruption, hardware flakiness, buggy distro scripts/units, etc) Meanwhile, let's not pretend that plenty of bugs didn't exist prior to systemd's adoption and/or in non-systemd boot flows.

All I can say is that overall things are *vastly* more robust and reliable than they used to be.

> I didn't like how Debian acted back then, and wish it had kept better support for non-systemd.

....That would have required folks to Show Up And Do The Work(tm), which hadn't been happening for quite some time.

The Devuan proponents could have accomplished everything they claim to have wanted from within the Debian umbrella [1] but chose to leave instead of working cooperatively to maintain or develop alternatives. [2]

[1] ie by actively maintaining the non-systemd infrastructure and dealing with the reality that various user-facing upstreams were choosing to depend on systemd features.
[2] IIUC Gentoo continues to lead the way on that front.

About the Devuan excision

Posted Jul 1, 2026 1:34 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

> I can't ever recall ending up in a situation where a *systemd* issue prevented a system from booting.

I have. At this point, systemd is a freaking mess with its tons of options and services.

In particular, my breakage was caused by a unit (systemd-update-done.service) that starts _once_ on boot after a system upgrade (I bet you didn't know it exists?). It's a fine idea, except that it has DIFFERENT dependencies compared with a normal boot.

And in my case it caused a lockup because it started before the network, and was depending on all the local devices being up. How does it define "local"? By checking the source device. If it's a regular SCSI device, then it's local.

Eeeexcept that iSCSI devices are also detected as "local" but they actually do need network.

Yes, there's a bug in the systemd bug tracker. It's been there for years.

About the Devuan excision

Posted Jul 1, 2026 3:08 UTC (Wed) by pizza (subscriber, #46) [Link] (10 responses)

> In particular, my breakage was caused by a unit (systemd-update-done.service) that starts _once_ on boot after a system upgrade (I bet you didn't know it exists?). It's a fine idea, except that it has DIFFERENT dependencies compared with a normal boot.

Is that a "systemd" bug, or that your particular distro's "system upgrade" flow/tooling doesn't correctly declare its dependencies ? Either way it appears to be trivially fixable by adding a local drop-in that that overrides the "After=local-fs.target" with "After=network.target" .

(I mean, an init script that a distro upgrade sets up to run only once after a system upgrade would break the same way for similar dependency issues. Or more likely, fail silently leaving things in a [not-so-]subtly incorrect state afterwards)

About the Devuan excision

Posted Jul 1, 2026 4:05 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

It's a systemd bug, as it's a part of the default systemd installation. The distro is Fedora, btw.

> (I mean, an init script that a distro upgrade sets up to run only once after a system upgrade would break the same way for similar dependency issues. Or more likely, fail silently leaving things in a [not-so-]subtly incorrect state afterwards)

Probably. Or maybe not. The issue here is that systemd is a huge mess at the moment. It seems to do _everything_, but it does almost nothing completely right.

The core process supervision and journaling are OK. Everything around it is not. Mount units are a particular disaster area. I dare anyone to say that THIS is acceptable: https://github.com/systemd/systemd/blob/ee9a70ccc7a35b224...

About the Devuan excision

Posted Jul 1, 2026 14:32 UTC (Wed) by pizza (subscriber, #46) [Link]

> Mount units are a particular disaster area.

If mount units are a "disaster area" then the previous status quo mudball (static /etc/fstab + autofs + bespoke distro scripts that keeled over when you stray off the beaten path and/or something inevitably went wrong, no meaningful dependency tracking vs the filesystem(s) being online/accessible, etc) was an extinction-level-event asteroid impact.

Is it perfect? far from it. But it's still a *huge* net improvement.

About the Devuan excision

Posted Jul 2, 2026 8:17 UTC (Thu) by intelfx (subscriber, #130118) [Link] (1 responses)

> The issue here is that systemd is a huge mess at the moment. It seems to do _everything_, but it does almost nothing completely right.

It does most of the things pretty much right. People used to split hairs over "completely" since computing happened, and will do so for the foreseeable future.

> The core process supervision and journaling are OK. Everything around it is not. Mount units are a particular disaster area. Mount units are a particular disaster area. I dare anyone to say that THIS is acceptable: https://github.com/systemd/systemd/blob/ee9a70ccc7a35b224...

You are sensationalizing. If that's the worst you have, I'd say we are in pretty damn good place.

This is not an article about systemd

Posted Jul 2, 2026 18:49 UTC (Thu) by corbet (editor, #1) [Link]

I think that the systemd wars, beyond having been mostly settled years ago, are somewhat off-topic here. Let's not relitigate that one yet again.

About the Devuan excision

Posted Jul 1, 2026 4:06 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Either way it appears to be trivially fixable by adding a local drop-in that that overrides the "After=local-fs.target" with "After=network.target" .

Well, yeah. I fixed it this way. After struggling to debug the issue that happened once in a while for an unknown reason.

About the Devuan excision

Posted Jul 1, 2026 5:31 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (4 responses)

Easier to put "_netdev" in the fstab where the iSCSI volumes are mounted. Either way, a configuration bug, not a systemd one. And not Xsnow related.

About the Devuan excision

Posted Jul 1, 2026 5:39 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

fstab? Are you a caveman? You're supposed to use mount units: https://www.freedesktop.org/software/systemd/man/latest/s... And I don't believe that they support _netdev override.

Which is ironic, because /etc/fstab generator supports them.

About the Devuan excision

Posted Jul 1, 2026 6:24 UTC (Wed) by mb (subscriber, #50428) [Link]

>In general, configuring mount points through /etc/fstab is the preferred approach to manage mounts for humans.

About the Devuan excision

Posted Jul 1, 2026 9:23 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

If you're writing a mount unit, you can add the appropriate dependencies yourself; systemd-fstab-generator uses _netdev to choose a different set of After and WantedBy directives, nothing more.

About the Devuan excision

Posted Jul 1, 2026 20:18 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Not quite. systemd also has special treatment of mount units for shutdown and for containers. It's a minor thing, true, but it also reinforces my point. There are too many moving pieces in systemd that can have unexpected side-effects.

I'm not a systemd hater, and I absolutely LOVE not having to cargo-cult /etc/init.d scripts.

But I'm not at all positive about systemd's ability to carry out its stated goal: building a coherent low-level infrastructure layer. The same pattern keeps repeating again and again: systemd adds some component in an MVP fashion and then gives up on making it fit with the rest of the system before moving on to the next shiny thing. And/or takes shortcuts that shouldn't be taken.

About the Devuan excision

Posted Jul 1, 2026 12:20 UTC (Wed) by alx.manpages (subscriber, #145117) [Link]

Oh, that might have been the cause of one of my recent (last month or so) boot problems. It failed to boot right after an upgrade, and I was worried that I might have one of those week-long no-boot bugs, but then I tried booting again the day after, and it worked. I could never reproduce it again. I didn't understand what happened, but if the first boot after upgrade is different, that could explain it.