Xsnow "protestware" in Debian [LWN.net]

By Joe Brockmeier
June 29, 2026

The xsnow application, which generates an animated snowfall effect (and other pleasant diversions) for X11 desktops, does not seem like an obvious channel for political statements. Nevertheless, xsnow's maintainer seems to have included a political protest in the program: an Easter egg that is triggered when the program's language is set to Russia ("ru"). One user has complained that this functionality should be removed from the Debian xsnow package, but Debian does not seem to have any rules that forbid such a feature outright.

The complaint

On June 14, Alexander Ivanov sent a message to Debian's development list to complain that if a user's language settings were set to Russian, it would trigger "a disguised visual element (Ukrainian flags labeled as 'EXTRATREE') with a significantly higher probability". The code is found in the src/scenery.c file beginning on line 326 in xsnow 3.8.3, the version packaged for Debian 13 ("trixie") and in 3.8.6, which is in unstable:

    #ifdef USE_EXTRATREE
          if (global.Language && !strcmp(global.Language,"ru") && drand48() < 0.3)
	     tt = MAXTREETYPE;
          if (drand48() < 0.02)
	     tt = MAXTREETYPE;
    #endif

Xsnow is more likely to display Ukrainian flags (src/Pixmaps/extratree.xpm) if the language is set to Russian. Xsnow allows users to pick from one of several languages; when the application was set to English, I did not see any Ukrainian flags but they should pop up about 2% of the time. I did see the expected decorations such as a moon, snow, trees, polar bears, birds, and Santa with his sleigh. After I changed the language setting to Russian, xsnow immediately placed several flags on the desktop along with the other decorations. The screenshot below shows what this looks like on Debian 13.

DFSG violation

Ivanov claimed that the behavior violated the Debian Free Software Guidelines (DFSG) that are part of the project's Social Contract. Specifically, he said that the "targeted behavior" violated the principles of no discrimination against persons or groups (DFSG #5) and no discrimination against fields of endeavor (DFSG #6).

Ivanov had not filed a bug, but was, instead reporting the problem to "the wider Debian development community". He said he took that route because the maintainer of the Debian package, Willem Vermin, is also the maintainer of the xsnow project and had been the one to introduce the change in the first place.

Chris Hofstaedtler replied that Ivanov was mistaken; the DFSG does not require that the software is non-discriminatory, but that the license for the software is. "The licenses in use do not appear to violate the DFSG's points 5 or 6. Please read the DFSG carefully next time." Xsnow is primarily licensed under the GPLv3, though some files carry other Debian-approved licenses.

Russ Allbery agreed that the DFSG was not relevant; he also warned that citing the Social Contract and DFSG "turns the conversation into rules lawyering without addressing the actual issue". However, even though xsnow is DFSG-compliant, he did say that the flag display may be something Debian does not want in its archives:

I would, in general, say that software that behaves in deceptive ways, which includes hidden behavior changes based on usernames, locales, or other local settings or information that no user would reasonably expect to change behavior in this way is probably not something that we want to have in Debian. It's a very slippery slope and also likely to create a lot of drama to very little benefit.

Ivanov said that he understood the point that xsnow did not violate the DFSG. But, he asked, shouldn't its hidden functionality be treated as a bug or behavior that should be patched out "to restore the application's neutral and intended functionality for all users equally?" Bill Allombert suggested that he open a bug report, since the Debian development list was not the correct venue for the complaint.

Forecast calls for no xsnow changes

To date, Ivanov has not opened a bug report, and the conversation seems to have run its course. I have emailed Vermin to ask if he was aware of the complaint, and if he would be willing to roll back the Ukrainian flag display if a bug were filed. So far, I have not received a response.

Even though Vermin may not want to change xsnow's behavior, Debian package maintainers have been required to make changes for technical reasons—or have had packages removed from the archive for offensive content. In August 2025, two "offensive" fortune packages were removed ahead of the trixie release following a lengthy discussion. In October 2025, Debian's Technical Committee decided that an upstream systemd change would need to be reverted because the new behavior broke a number of programs that depended on a world-writable /run/lock directory. In each case, there was a fair bit of discussion and deliberation before the maintainers were overridden.

This is not to argue one way or the other whether xsnow's Easter egg should be removed; it is simply worth pointing out that it is not futile to file a bug against a package even if it's likely that the maintainer will disagree. As a project, Debian gives its developers a wide latitude in how they manage their packages, but a packager's decisions can be overridden on the rare occasions when the project deems it necessary. Convincing the project to do so, however, requires the petitioner to put in the work. Merely complaining on the mailing list is unlikely to achieve any results.

to post comments

I have a very mild protest in a package of mine

Posted Jun 29, 2026 15:26 UTC (Mon) by dskoll (subscriber, #1630) [Link] (4 responses)

I also have protestware in Remind, a calendar program I wrote. However, it's only visible if you run strings against the binary, so it's pretty unlikely to be noticed.

The program does come with a bunch of sample calendar files that mark important LGBTQ community days, and while I don't think these are protestware, they could be viewed as such in some countries. The manual page also has an example that commemorates the 1989 Tienamen Square massacre which, in China, is probably considered a very serious offence.

I don't think protestware is a problem unless it seriously interferes with the normal and intended use of the software, at which point it becomes a bug or even malware. And since it's open-source, people who are very offended by the protestware can remove it.

I have a very mild protest in a package of mine

Posted Jun 29, 2026 15:51 UTC (Mon) by rbtree (subscriber, #129790) [Link] (3 responses)

As a Russian speaker who might very well have the ru locale running on his system, I'm personally fine with this "protestware" (at least it does not rm-rf your filesystem like some of them did back in 2022), but it is because I do not live in Russia.

People in Western countries don't realize how bad the situation on the ground actually is¹; random Ukrainian flags showing up on your work monitor can result in severe problems for you (like losing you job, or worse), especially if you work in the government sector. If they show up on your laptop in a random cafe or an airport, you might very well get a beating from one of many "war heroes" that walk around the cities these days.

No, the government sector doesn't just make missiles and bombs, it also covers schools, hospitals, many other things.

[1]: random example: a former Estonian president recently made a complete ass of himself by going to Xitter and publicly claiming that protesting and speaking against the war in Russia does *not* land you in prison for up to 8 years, so why are they silent and are doing nothing? Even the 1000%-pro-Ukraine Russian opposition was shocked.

I have a very mild protest in a package of mine

Posted Jun 29, 2026 16:44 UTC (Mon) by dskoll (subscriber, #1630) [Link]

I agree that any protestware should not show up by default, but should require some action on the part of the user or be buried in the man page. Putting users at risk is never good.

I have a very mild protest in a package of mine

Posted Jun 29, 2026 16:44 UTC (Mon) by mss (subscriber, #138799) [Link]

It looks like the controversial code block just changes the probability of Ukrainian flags appearing for the ru locale.

In other words, these flags could appear even for other locales, albeit then with much lower probability.

I have a very mild protest in a package of mine

Posted Jul 1, 2026 10:06 UTC (Wed) by mymedia (guest, #184859) [Link]

I do live in Russia, and I believe you are exaggerating. Nobody here cares of random Ukrainian flags on others' monitors, even at work.

In the government sector, ordinary staff do not install software themselves. It usually does a system administrator, like in any medium-to-large company. So it's unlikely someone would lose their job or get beaten because of a color combination that resembles a flag of a foreign country.

Problematic

Posted Jun 29, 2026 15:51 UTC (Mon) by cen (subscriber, #170575) [Link] (13 responses)

The way I see it, this is a slippery slope and should be banned by policy. Any change that is done to the upstream package which has no real technical merit but essentially introduces political messaging sounds problematic. You could then have a Russian maintainer inserting some other changes in some other package and open up maintainer wars reflecting real life conflicts (Iran, Palestine, Israel etc etc). If Debian ships such packages in their official repos it implicitly endorses such changes as a project.

Problematic

Posted Jun 29, 2026 16:03 UTC (Mon) by farnz (subscriber, #17727) [Link] (6 responses)

Note that the code in question is also in the upstream package. It's not a Debian-specific modification.

Problematic

Posted Jun 29, 2026 16:40 UTC (Mon) by jzb (editor, #7867) [Link] (4 responses)

Sorry if that did not come through clearly enough in the article. Yes, it's in upstream xsnow as well. Not sure exactly which version it landed in, but it's not unique to Debian.

Problematic

Posted Jun 29, 2026 21:42 UTC (Mon) by ballombe (subscriber, #9523) [Link] (3 responses)

The Debian maintainer is the upstream author, AFAICS.
However, as I said, as long as nobody is willing to fill a bug report, the issue is moot.
It seems a bit dishonest to complain to debian-devel without ever bothering to fill a bug report, IMHO.

Problematic

Posted Jun 30, 2026 20:45 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (2 responses)

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141182

Problematic

Posted Jun 30, 2026 21:52 UTC (Tue) by ballombe (subscriber, #9523) [Link] (1 responses)

Your bug report is short on technical detail. You do not explain how to reproduce the bug or what exactly happens.
I do not see how Debian can fix it.

Problematic

Posted Jul 1, 2026 17:17 UTC (Wed) by edgewood (subscriber, #1123) [Link]

Apparently, it was enough for the author/maintainer, as he's considered the alternatives and decided to remove the protestware.

Problematic

Posted Jun 29, 2026 16:59 UTC (Mon) by cen (subscriber, #170575) [Link]

I wasn't aware this was an upstream change. That changes things and makes my comment irrelavant. Thanks for the clarification.

Problematic

Posted Jun 29, 2026 17:47 UTC (Mon) by bluca (subscriber, #118303) [Link] (2 responses)

You'll have to take away "ip moo" from my cold, dead hands

Problematic

Posted Jun 29, 2026 23:18 UTC (Mon) by ATLief (subscriber, #166135) [Link]

apt moo

apt moo moo

apt moo moo moo

Problem-apt-ic

Posted Jun 30, 2026 6:03 UTC (Tue) by k3ninho (subscriber, #50375) [Link]

Can i haz sponsor for systemd-moosay?

K3n.

Problematic

Posted Jun 30, 2026 14:03 UTC (Tue) by patrakov (subscriber, #97174) [Link] (2 responses)

Debian already had a case in the past where they removed a package with early protestware - but in that earlier case, it was a protest by upstream against Debian packaging practices. Upstream deliberately broke the package for every Debian user except the maintainer. I am talking about micq.

mICQ

Posted Jun 30, 2026 14:06 UTC (Tue) by corbet (editor, #1) [Link]

That episode was, of course, covered here at the time.

Problematic - article in question

Posted Jun 30, 2026 14:06 UTC (Tue) by jzb (editor, #7867) [Link]

Huh. I had either missed that or have completely forgotten about it... either is entirely possible. Looks like we covered it, though: "The trojaning of mICQ", February 18, 2003. Wish I'd known/remembered it when I was writing the article; that would have been a good thing to include. Thank you much for the comment!

The Russian language is more than just politics..

Posted Jun 29, 2026 19:16 UTC (Mon) by jpeisach (subscriber, #181966) [Link] (4 responses)

A lot of people in my town came from Russia. Some even speak only Russian. (This is in the US)

So because they don't speak English, they may use the Russian keyboard layout.

And even though they may support the cause, it's kind of.. um.. unfair? That they have to deal with this?

The Russian language is more than just politics..

Posted Jun 29, 2026 19:18 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (2 responses)

If they have russian citizenship, they are eligible to vote in russian elections. That's why there are abroad voting stations.

The Russian language is more than just politics..

Posted Jun 30, 2026 17:28 UTC (Tue) by LtWorf (subscriber, #124958) [Link]

By definition, if you can elect someone (meaningfully) different, it was not a dictatorship.

The Russian language is more than just politics..

Posted Jul 2, 2026 4:13 UTC (Thu) by spiral305 (subscriber, #173166) [Link]

There are no elections in Russia. It's just a show.

The Russian language is more than just politics..

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

It's worth being clear that what they "have to deal with" is being shown Ukrainian flags at a higher rate that those of your neighbours with an English locale, and then only if they choose to run xsnow.

It's only a big deal when you're in a region where displaying a Ukrainian flag on your screen makes you a target.

Bug of feature?

Posted Jun 30, 2026 9:03 UTC (Tue) by evgeny (subscriber, #774) [Link] (89 responses)

I believe it's an important topic in general (not just this specific project or even Debian). It appears Debian, and many other Linux distros (probably all) don't even try to regulate the (in)discriminatory behavior of the software they ship. And this is while spelling out in much detail that the *license* must not be discriminatory in any way. BTW, the same strict rules appear in the code of conduct, but limiting the scope to the "developers".

Until today, I was absolutely sure the same applies to the software itself. BTW, any Debian user is either an active or a potential future Debian developer. If one Debian developer knowingly ships a software that intentionally annoys (or even puts at serious legal risk) another developer, isn't it a violation of the code of conduct, even setting aside obvious, IMHO, ethical issues?

I, for one, would stop contributing to a project that tolerates such discriminatory behavior.

Bug of feature?

Posted Jun 30, 2026 9:16 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (61 responses)

It's certainly the case that Debian has had disputes over whether software was suitable based on criteria other than technical correctness - we can go back over 20 years to find the hot-babe argument. But also Debian is somewhat inevitably going to be influenced by the attitudes of its developers, and with those being overwhelmingly (but not exclusively) in favour of it being bad to initiate wars of aggression, I think it's likely that there will not be an entirely consistent approach to this class of problem.

(I should emphasise that I do not believe that all Russian citizens or residents are in favour of the Ukrainian invasion - but at the same time I would, as a US citizen, not fundamentally object to Debian packaging software that in some way penalised me due to the Iran bombings)

Bug of feature?

Posted Jun 30, 2026 9:31 UTC (Tue) by evgeny (subscriber, #774) [Link] (60 responses)

I think there *is* "an entirely consistent approach to this class of problem": a person must not be discriminated against on the basis of their race, sex, nationality, passport color, etc. In this specific case, not on their spoken language.

I might be sympathetic to something like 'if (username == "putin")' or 'user.last_voted_for = "putin"', but given a negligible chance of evaluating as true of the former and unavailability of the relevant API of the latter, it's better to separate political opinions from the software development of public projects.

Bug of feature?

Posted Jun 30, 2026 11:03 UTC (Tue) by alx.manpages (subscriber, #145117) [Link] (55 responses)

I believe the second paragraph contradicts the first one. As a joke it is fine, but in seriousness, we don't want to discriminate people by their name or their political opinions.

Bug of feature?

Posted Jun 30, 2026 11:24 UTC (Tue) by evgeny (subscriber, #774) [Link]

I, of course, fully agree with you. My last comment was to show that I might *understand* (not necessarily agree or encourage) an attempt to punish *specific* person(s) responsible for war crimes - as was the intent (hopefully) of the author of xsnow. But the real consequences are felt not by the Russian fighters in the trenches nor by the politicians in the Kremlin, but by innocent (unless proven otherwise) Debian users in Russia who, by the presence of Ukrainian symbols on their screen, may very realistically be subjected to administrative or criminal laws (or just be physically beaten by "patriotic" passers by).

Bug of feature?

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

> but in seriousness, we don't want to discriminate people by their name or their political opinions.

Not just Nope, but HELL NOPE.

Some folks' "political opinions" hold that others are essentially subhuman, and deserve to be, if not put to death outright, should be made to suffer and excluded from solely because they exist.

In today's hyper-connected world, the distinction between "opinion" and "active advocacy" is pretty much non-existent.

Bug of feature?

Posted Jun 30, 2026 12:31 UTC (Tue) by pizza (subscriber, #46) [Link]

> Some folks' "political opinions" hold that others are essentially subhuman, and deserve to be, if not put to death outright, should be made to suffer and excluded from solely because they exist.

Bah, massive editing fail. Should read:

...and deserve to be, if not put to death outright, made to suffer and excluded from society solely because they exist.

Bug of feature?

Posted Jun 30, 2026 13:28 UTC (Tue) by alx.manpages (subscriber, #145117) [Link] (38 responses)

Let's consider that Debian could somehow distinguish people who voted $EVIL from the rest.

Should Debian packages behave differently for those people?

Do we trust people to be in charge of the decision of which values of $EVIL are bad enough to deserve this, and also to decide how much different the software should behave?

Also, what if someone voted $EVIL because it didn't have an alternative? Maybe they're coerced into voting $EVIL. Would we accept those as colateral damage?

Also, let's say some $GOOD organization attempts to attack $EVIL, and infiltrates in their servers or otherwise impersonates $EVIL. The software that discriminates $EVIL would consider that the infiltrated $GOOD people are evil, and could hinder the attack, ironically, and maybe even put $GOOD at risk.

I don't mean that programmers should not discriminate people by their political opinions. But I think software should not do it blindly.

Bug of feature?

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

> Should Debian packages behave differently for those people?

Only if those behavioral differences are due to an action taken on Debian's part.

But as the behavioral differences are *upstream*, this is a very different conversation.

> I don't mean that programmers should not discriminate people by their political opinions. But I think software should not do it blindly.

Software should do what its authors want it to do. Nothing more, nothing less.

However, as 'xsnow' is Free Software, its users have the right alter the software to do what *they* want, ie becoming authors themselves.

Bug of feature?

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

> Software should do what its authors want it to do. Nothing more, nothing less.

I disagree. A malware does what its authors wanted to do. But is it OK for Debian to knowingly distribute it? In fact, I don't mind, provided it's prominently and very clearly described as such (e.g., "when you install this software, it will silently copy your passwords and send them over to a pirate's account"). But the problem with xsnow, and specifically with this "feature" added, is that it is *not* obvious for a casual user. So it does something not expected, and as such, I see no principal difference between this Easter egg and a password sniffer. In both cases, the software acts without the user's explicit or implicit consent to perform non-obvious actions. And, similar to the password sniffer, this hidden feature may put the user's well-being and health at risk.

Bug of feature?

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

> But the problem with xsnow, and specifically with this "feature" added, is that it is *not* obvious for a casual user. So it does something not expected, and as such, I see no principal difference between this Easter egg and a password sniffer.

That argument equally applies to web browsers.

Come on. Taking any other position than "software should do what its authors want" is effectively dictating what software folks can or can't write (and/or redistribute) Which, I might add, runs completely counter to Free Software (and Open Source) principles.

> In both cases, the software acts without the user's explicit or implicit consent to perform non-obvious actions

"Non-obvious" is, at best, *incredibly* subjective.

Bug of feature?

Posted Jun 30, 2026 15:01 UTC (Tue) by evgeny (subscriber, #774) [Link] (1 responses)

> Taking any other position than "software should do what its authors want" is effectively dictating what software folks can or can't write (and/or redistribute)

I beg your pardon. First, "write" and "distribute" are very different things. BTW, the Free Software/Open Source licensing terms are largely about the latter. And I fully agree that it's the right of any person to write any kind of software they like.

But you seem to miss my point: it is the *hidden* property of this feature that raises the red flag for me. I want to believe that Debian makes every effort to fix security holes as quickly as possible. And I wish to believe that, similarly, Debian makes every possible effort to ensure that I (or any other user) am not adversely affected by the political opinions of an upstream author.

Bug of feature?

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

> But you seem to miss my point: it is the *hidden* property of this feature that raises the red flag for me.

Most software features are "hidden".

> And I wish to believe that, similarly, Debian makes every possible effort to ensure that I (or any other user) am not adversely affected by the political opinions of an upstream author.

You may wish to believe this, but has it *ever* been the case?

...Except insofar as the importance of "free software" (and the DFSG) is a political opinion, making Debian itself an exclusionary political statement.

Bug of feature?

Posted Jun 30, 2026 14:41 UTC (Tue) by bronson (subscriber, #4806) [Link] (32 responses)

This is reminding me of the "baby-mulching" license arguments of the 1990s. People yelling at each other endlessly about "should you be able to prevent your software from being used in a baby mulching machine", creating towering hypotheticals and and attempting to argue them all the way through. It was a lot of discussion and I don't remember anything useful coming from it.

Here, we're talking about a bit of code that increases the likelihood of a Ukrainian flag being displayed in a joke program ... if this somehow puts someone in physical danger, then I'd suggest that the issue is more with persecuting humans over trivial things, and not so much with this bit of code. This isn't worth the hypotheticals.

Bug of feature?

Posted Jun 30, 2026 16:22 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (28 responses)

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.

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.

Bug of feature?

Posted Jun 30, 2026 17:34 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (2 responses)

What if your software is used by a USA army contractor or the army itself?

Bug of feature?

Posted Jun 30, 2026 18:57 UTC (Tue) by evgeny (subscriber, #774) [Link]

> What if your software is used by a USA army contractor or the army itself?

Personally, I'm fine with it. If you don't like *your* software to be used in this context, you're free to use a respective licensing clause. But it won't be compatible with DFSG, I believe.

Bug of feature?

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

BTW, thanks for filing the bug report :).

No discrimination by political opinion is not practically possible.

Posted Jun 30, 2026 12:45 UTC (Tue) by farnz (subscriber, #17727) [Link] (12 responses)

You now have a hard problem to solve; some Russian speaking Ukrainians want their system to display the Ukrainian flag to represent the ru_UA locale, and a refusal to include the Ukrainian flag is discriminating against their political opinions, because (while being Russian-speaking), they believe that Ukraine is separate from Russia.

As evgeny's post makes clear a Russian resident may well have good reason to want their system to never display the Ukrainian flag, because there are Russians who, as a matter of political opinion, consider its very existence a problem, and expect you to show the Russian Federation flag instead (since they consider Ukraine to be a Russian Federation province, currently in active rebellion).

At this point, you have a problem to resolve: how do you ensure that a Russian looking for the "right" Russian locale for their needs does not see the Ukrainian flag, while also ensuring that the Ukrainian looking for the "right" Russian locale for their needs does see it?

More generally, this is Popper's paradox of tolerance; there are limits to what you can include if you're trying to be inclusive, and that area of philosophy gets quite complex.

No discrimination by political opinion is not practically possible.

Posted Jun 30, 2026 14:23 UTC (Tue) by amacater (subscriber, #790) [Link] (11 responses)

And flag wars create their own problems. Debian at one point lost a very capable developer over arguments over appropriate nomenclature/locales/flags for Chinese locales (and the nature/extent of proper sovereignty and naming/political considerations) concerning Taiwan. It's one reason why Debian doesn't normally link locales with flags.

xsnow is strictly an optional package - anyone who doesn't need it can remove it without compromising the other functionality of their system.

Unfortunately too, protest ware is hard to limit: I remember reading of something that was not to be used by S. African police. This with the intention of creating problems for them under the apartheid regime.
Unfortunately, the ban continued into post-apartheid S. Africa where the software was still useful.

No discrimination by political opinion is not practically possible.

Posted Jun 30, 2026 15:27 UTC (Tue) by farnz (subscriber, #17727) [Link]

The added problem here is that whether or not xsnow counts as "protestware" depends on your point of view. The thing that makes it "protestware" is that it displays a certain symbol, and if you're in a specific subset of locales, it displays that symbol much more frequently than if you're not.

It doesn't ban you from using or modifying it (you could, quite legally, replace extratree.xpm with something else, for example), unlike your example of a program not to be used by South African police. As a result, it's not really "protestware" in the same sense as your second example, because a Russian could easily have a package to replace extratree.xpm with (say) a drawing of a larch (or other tree). Further, once we have world peace, and flags stop upsetting people, the xsnow "protest" becomes a non-issue; it's only an issue because of current political views in the Russian Federation.

No discrimination by political opinion is not practically possible.

Posted Jul 1, 2026 8:49 UTC (Wed) by jond (subscriber, #37669) [Link] (9 responses)

> xsnow is strictly an optional package - anyone who doesn't need it can remove it without compromising the other functionality of their system.

Putting myself in the shoes of the hypothetical victim here: After unexpectedly displaying Ukrainian flags and being punched, I likely would remove xsnow. But I would still have been punched.

This is cheap protest by the developer because they are not at risk of harm, but we are potentially putting some of our users at risk of harm by continuing to include the protest. At a bare minimum we should make it unsurprising behaviour: prominently document that xsnow might show the Ukrainian flag in the package description, manpage, etc. But removing the hack would be less work and a better response, IMHO.

No discrimination by political opinion is not practically possible.

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

Similarly, including the English language means that if you display English (instead of Spanish) unexpectedly, you can be punched, and will then likely remove everything that's English, not Spanish.

The standard of "potentially putting some of our users at risk of harm" is a difficult one, because just about anything you can think of as "reasonable" is likely to ban significant chunks of the distribution; for example, anything Internet-connected that doesn't have a permit from the appropriate government authorities can get you into trouble in some places - and it's reasonable to assume that if the OS lets you install it, it has the right permits.

No discrimination by political opinion is not practically possible.

Posted Jul 1, 2026 9:46 UTC (Wed) by jond (subscriber, #37669) [Link] (6 responses)

(Hello Farnz. long time no see!)

Frankly no, I don't think it's a difficult one. There's a reasonable expectation that you will encounter English when using Debian. There is not a reasonable expectation of encountering the Ukrainian flag when using xsnow.

No discrimination by political opinion is not practically possible.

Posted Jul 1, 2026 10:15 UTC (Wed) by farnz (subscriber, #17727) [Link] (5 responses)

Why? If I've set my language to Spanish, why should I expect that it will show English unexpectedly?

That's something that only happens because Debian has deliberately decided that English is the fallback language - just as the xsnow upstream developer has decided that Ukrainian flags would be pretty in his application.

No discrimination by political opinion is not practically possible.

Posted Jul 1, 2026 10:19 UTC (Wed) by evgeny (subscriber, #774) [Link]

No, the xsnow upstream developer has decided that Ukrainian flags would be pretty to *specifically* annoy (I wish to believe he didn't intend them to be punished more seriously) Russian-speaking users.

No discrimination by political opinion is not practically possible.

Posted Jul 1, 2026 11:43 UTC (Wed) by jond (subscriber, #37669) [Link] (3 responses)

> Why? If I've set my language to Spanish, why should I expect that it will show English unexpectedly?

Because that's the long-term, actual experience any non-english user has of any linux distribution, now and always.

> That's something that only happens because Debian has deliberately decided that English is the fallback language

Yes, Debian and everyone else, and always.

It's a false equivalence to compare this to the xsnow situation.

No discrimination by political opinion is not practically possible.

Posted Jul 1, 2026 11:50 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

Why? In both cases, it's a decision that was made by upstream developers, and that Debian has adopted as-is, and that puts people's lives at risk.

One is an older decision, and the other is newer, but that's about it in terms of difference.

Standards

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

English is the de-facto-standard language when local language is not available. That's not something decided by Debian, nor any upstreams. That's not even exclusive of software. If a random person is traveling and doesn't know the local language, they're going to try English, most likely.

Standards

Posted Jul 1, 2026 13:20 UTC (Wed) by farnz (subscriber, #17727) [Link]

But if we're saying that the existence of Russian criminals who will assault you for daring to have a Ukrainian flag on your screen briefly justifies modifying Debian so that this can't happen by mistake, why doesn't the existence of South American criminals who will assault you for daring to have English on your screen briefly justify modifying Debian so that this can't happen by mistake? For example, changing software to say the equivalent of "translation not available - available languages are English, French, …" in whatever your chosen language is if you've chosen to ask for translations

In both cases, the risk is that a criminal will take offence at what you've got on your screen, and assault you for it. In both cases, the decision to put the "wrong" thing on your screen is not being made as a Debian patch - rather, it's something upstream of them.

Oh, and for added fun - why is it OK to upset Ukrainians by removing xsnow's upstream's expression of support for their country, but not OK to upset Russians?

No discrimination by political opinion is not practically possible.

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

> Similarly, including the English language means that if you display English (instead of Spanish) unexpectedly, you can be punched, and will then likely remove everything that's English, not Spanish.

As an aside, my (English) family name, if pronounced correctly, is a slur in Turkish.

Bug of feature?

Posted Jun 30, 2026 19:51 UTC (Tue) by kleptog (subscriber, #1183) [Link] (3 responses)

I think you have to think carefully about the use of the word "discrimination" here. It of course meets the literal definition "change based on attribute" but legally the requirement is actual harm, or some negative impact. Here it's indirect: you see some extra flags which might in some areas be problematic but seeing a flag doesn't hurt anyone. That someone else might hurt you isn't really relevant.

Next people will be complaining that seeing a rainbow flag harms them.

And here we're talking about a package that according to popcon has 305 installs, so really nothing to get worked up about.

Bug of feature?

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

> And here we're talking about a package that according to popcon has 305 installs

No, in the top post of this thread (https://lwn.net/Articles/1080234/), I said: "I believe it's an important topic in general (not just this specific project or even Debian)."

Bug of feature?

Posted Jun 30, 2026 20:14 UTC (Tue) by nhippi (subscriber, #34640) [Link] (1 responses)

> And here we're talking about a package that according to popcon has 305 installs, so really nothing to get worked up about.

Classic streissand effect..

Bug of feature?

Posted Jul 1, 2026 20:51 UTC (Wed) by kleptog (subscriber, #1183) [Link]

Indeed, I think this minor act of protest has been wildly more successful than the author could possibly have imagined. Even if the package vanished from the face of the earth tomorrow, this act has been immortalised for all eternity.

Mission accomplished I'd say.

The question is: how long with it take for people to realise this discussion isn't worth all the electrons and there are more important things to worry about...

Bug of feature?

Posted Jun 30, 2026 21:26 UTC (Tue) by rra (subscriber, #99804) [Link] (25 responses)

> I believe it's an important topic in general (not just this specific project or even Debian). It appears Debian, and many other Linux distros (probably all) don't even try to regulate the (in)discriminatory behavior of the software they ship.

Casting this as an argument about "discriminatory behavior" is, I think, a huge tactical mistake that makes it less likely that your legitimate concerns will be ignored. That is a wildly subjective standard that has been a matter of political controversy for at least 150 years. Just in my own country there have been heated arguments, physical violence, and even mass murder over whether such things as "separate but equal" constitute discriminatory behavior. You will never reach a political consensus on what that means, and most free software projects will be unwilling to touch this argument with a ten-foot pole because the signal to noise ratio is awful.

And you don't have to! Because there's a much more obvious problem here, which I tried to point out in the thread: Deceptive behavior by the software. This is a very mild case of that, to be clear, but it is a case of that, and I think that's a standard for which you would be far more likely to reach consensus.

If the description of xsnow said "this program shows Ukraine flags while it's running," this is still just as discriminatory (or not, depending on what side of that very unresolved and probably unresolvable argument you are on), but it doesn't pose the same concrete problem. If you were in Russia and you saw that in the description, you would just not install it. People who installed it and ran it would not be surprised. Problem solved, without having to resolve one of the trickiest disagreements in political science.

This is a general problem that I see in free software arguments all the time: In order to make an argument more appealing, people attach it to some high-emotion, high-salience political argument of the day, but in so doing they tie their argument into that political fight and pretty much guarantee the resulting discussion will go off-topic and will probably flame out with no effect. But if you look more closely at the concrete problem, often there is a much less controversial and much less emotionally-charged point that could be made. It won't feel as emotionally satisfying and it won't feel like you're taking a brave stance against your political enemies, but it's a lot more likely to cause change in the world.

Bug of feature?

Posted Jul 1, 2026 8:44 UTC (Wed) by evgeny (subscriber, #774) [Link] (24 responses)

> Casting this as an argument about "discriminatory behavior" is, I think, a huge tactical mistake that makes it less likely that your legitimate concerns will be ignored. That is a wildly subjective standard that has been a matter of political controversy for at least 150 years.

I don't understand what is subjective about discrimination. Let's use Wikipedia's definition:

"Discrimination is the process of making unjustified distinctions between people based on the groups, classes, or other categories to which they belong or are perceived to belong, usually in a way that deprives them of their legal or human rights."

So let me stress: discrimination is a *process* of making *unjustified* distinctions between people. The political or other implications are mere consequences that may or may not ("usually") happen as a result.

> If the description of xsnow said "this program shows Ukraine flags while it's running," this is still just as discriminatory (or not, depending on what side of that very unresolved and probably unresolvable argument you are on), but it doesn't pose the same concrete problem. If you were in Russia and you saw that in the description, you would just not install it. People who installed it and ran it would not be surprised. Problem solved, without having to resolve one of the trickiest disagreements in political science.

Not at all. The problem is *not* in displaying the Ukrainian (or any other) flag per se. There could be a zillion reasons why the author might wish to do it. Anything from being born in Ukraine to aesthetically enjoying the combination of blue and yellow. I'm fine with it. Yes, describing this behavior would be helpful for those who might be hurt or offended by it. But I cannot, and don't want to, demand that any software creator consider all possible consequences (including those arising from future political changes in a remote part of the world) of their decision.

The problem lies with the *discriminatory* behavior of xsnow: the probability of showing or not the flag varies strongly (by more than an order of magnitude) with the user's ethnicity. And this decision is *unjustified*. There is no reasonable jurisdiction in the world that would approve it. Even the Constitution of Ukraine (Article 10) explicitly declares "Free development, use, and protection of Russian and other languages".

I don't know how to explain it better. Say, if instead of showing the Ukrainian flag, the author decided to run "rm -rf ~" if the locale is "ru", would you approve it? There is no principal difference here. In fact, for a true Putin antagonist living in Russia, this outcome might be more preferable than the Ukrainian flag popping up unexpectedly in public. Some Westerners don't realize what it means to live under an oppressive regime, and play with other people's lives at ease.

Bug of feature?

Posted Jul 1, 2026 15:02 UTC (Wed) by rra (subscriber, #99804) [Link] (23 responses)

> I don't understand what is subjective about discrimination.

I understand that you (like most people making political arguments about discrimination) think your definition of discrimination is clearly correct and obvious and follows from dictionary definitions. I'm not going to argue with you about that, because that's not my point. My point is that pursuing this line of argument is likely to hurt your ability to get what you want because it creates a bunch of unnecessary controversy that people will disagree with, whether you think they should or not. Regardless of whether you are correct, it is a self-defeating tactic and it is much more likely to lead to people ignoring you.

You can of course decide that I'm wrong and continue down this course anyway, and maybe I am wrong! Free advice is worth what you paid for it.

> Say, if instead of showing the Ukrainian flag, the author decided to run "rm -rf ~" if the locale is "ru", would you approve it?

Suppose that the software just ran "rm -rf ~" unconditionally regardless of the locale. This clearly is not discriminatory in any way whatsoever. So it's okay, then?

Software that deletes the user's home directory unexpectedly and without the user's permission is clearly a bad thing to have in a distribution and you would have very little trouble getting the distribution to remove it. The reason and conditions under which it does that are basically irrelevant.

xsnow is a harder case because the change of behavior is subtle and is not obviously destructive. But I think the same principle applies: one of the core principles of free software is that the user should be in control of the software running on their device, and software that is deceptively coded in a way that is potentially hostile to the interests of the user undermines that principle. It's one thing if the easter egg is intended to amuse or delight when someone stumbles across it and can be seen as a game the author is playing with the user, but I think that's hard to defend here.

But if, instead of pointing out that the software does things deceptively behind the user's back, thus violating a very widely-held consensus in the free software community about how software should behave, you instead decided to make the argument about a contemporary political issue, you might manage to sabotage your argument enough that some people would argue against you. (Probably not for rm -rf ~, since the damage done is so obviously severe, but I am watching it happen right now with the Ukraine flag, because of the grounds on which you chose to fight.)

Bug of feature?

Posted Jul 1, 2026 15:28 UTC (Wed) by evgeny (subscriber, #774) [Link] (5 responses)

> Suppose that the software just ran "rm -rf ~" unconditionally regardless of the locale. This clearly is not discriminatory in any way whatsoever. So it's okay, then?

No, it isn't, but for a different reason. Just as punching an average passerby in the face because you're drunk or consciously choosing for that purpose a representative of a specific race/gender/etc are different criminal offenses, with quite different legal consequences under most jurisdictions.

Bug of feature?

Posted Jul 1, 2026 18:36 UTC (Wed) by rra (subscriber, #99804) [Link] (1 responses)

Thinking that one's motive in punching someone in the face should result in an entirely different criminal offense is certainly a political position that you could hold. It's one I generally disagree with, so I'm not going to take any actions based on that belief because I think that belief is wrong. If you insist that I am required to agree with you on that point, I'm likely to be unwilling to collaborate with you even on unrelated things, and may simply block all your messages.

Now, do you want to turn the whole discussion into arguing about that, or do you want to instead focus on our point of agreement, which is that people shouldn't be punched in the face?

Bug of feature?

Posted Jul 1, 2026 19:14 UTC (Wed) by evgeny (subscriber, #774) [Link]

> Thinking that one's motive in punching someone in the face should result in an entirely different criminal offense is certainly a political position that you could hold.

My political position is rather irrelevant. Hate crime (https://en.wikipedia.org/wiki/Hate_crime) is a concept recognized in the jurisprudence of many countries.

> Now, do you want to turn the whole discussion into arguing about that, or do you want to instead focus on our point of agreement, which is that people shouldn't be punched in the face?

Yes, people shouldn't be punched in the face. We agree on that. I further firmly believe that when certain people are punched in the face only because their face has special ethnic traits (and the rest of the population doesn't see it as a problem), the society is seriously sick.

Bug of feature?

Posted Jul 1, 2026 18:49 UTC (Wed) by malmedal (subscriber, #56172) [Link] (2 responses)

Just to come back to the original disagreement here.

Your point is that in the current situation with an agressor doing an unprovoked and illegal attack. Somebody is doing a non-violent protest against this. And this non-violent protest is immoral because somebody in the aggressor nation might do violence to other people also in the agressor nation?
Do I have this right? Am I missing something?

Bug of feature?

Posted Jul 1, 2026 20:08 UTC (Wed) by evgeny (subscriber, #774) [Link] (1 responses)

Yep, that's a correct description. FYI, it's called collective punishment.

Bug of feature?

Posted Jul 1, 2026 20:54 UTC (Wed) by malmedal (subscriber, #56172) [Link]

Closer to the practice of "human shields" where a combatant deliberately places civilians near military targets(or moves the targets to where the civilans are) with the goal that the other side will be to humanitarian to drop any bombs. Not an exact match though. The equivalent would be for somebody to attack their own people in order to deter the enemy from attacking. Can't think of any instance where this has actually been tried...

Bug of feature?

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

> one of the core principles of free software is that the user should be in control of the software running on their device

You left out "...by having the complete corresponding source code that they can inspect and modify if they so choose"

No "Free Software Principles" say that a given user is entitled to not be surprised by unexpected or even deceptive program behavior; they only get the right to change the behavior they do not want/like.

Bug of feature?

Posted Jul 1, 2026 18:15 UTC (Wed) by rra (subscriber, #99804) [Link] (15 responses)

No, I didn't leave that out. I don't agree. I don't think providing the source is the sole obligation and as long as you provide the source, the program can do anything. And, phrasing aside, I'm sure you don't think that either: If, say, GNU coreutils started shipping malware inside its source code that sends all of your credentials to the FSF (intentionally absurd example), you'd say that was obviously wrong.

So, I think you're disagreeing with me on semantics. You would agree this is wrong, but not necessarily that it's wrong because it's a violation of free software principles, but instead that it's wrong because it's malware. And my point in this entire thread is that this is a distinction without a difference if your goal is to just stop programs from doing unexpected, deceptive things. It doesn't really mater *why* you're opposed to software doing unexpected, deceptive things; there's a general consensus that is bad for any number of different reasons.

I suppose the gap, the place where there could still be some disagreement, is that one can believe programs doing malicious or deceptive things is bad (regardless of whether you would phrase the principle the same way that I would), but what xsnow is doing is not sufficiently bad to warrant any concern. That's fine, I think that's a reasonable point on which people can disagree, and is probably the argument that we should be having. So I think we mostly agree on my point on argument structure.

The point that I'm trying to make is that saying that this is "discrimination" is not going to help. We need to argue about the actual concrete impact; trying to turn that into an emotionally charged political dispute by calling it "discrimination" is just going to cause people to tune it out or even oppose any change for political reasons.

Bug of feature?

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

> I don't think providing the source is the sole obligation and as long as you provide the source, the program can do anything. And, phrasing aside, I'm sure you don't think that either:

Actually, I *do* firmly believe that -- "This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."

Don't get me wrong, I wouldn't intentionally use software I know to be actively malicious. But the difference between "malicious" and merely "very buggy" can be pretty hard to discern, and either way the user assumes all risks as an up-front condition of being able to use the software to begin with. Ultimately the only way to truly know what a given piece of software does is an exhaustive code review.

Bug of feature?

Posted Jul 1, 2026 20:13 UTC (Wed) by rra (subscriber, #99804) [Link] (13 responses)

Oh, okay, yes, that's a fair point, I am also a firm believer that people should actually read the disclaimer in the license and the author doesn't have an obligation to write the software that you want to use.

I think there's a little bit of nuance because the author does have some power that they've gained through trust, and abusing that power while pointing to the license is not really how trust works between humans. But as far as I'd go with that is that I don't think they should trick people intentionally, and I get pretty annoyed with the people who claim that free software authors have some obligation to their users beyond that.

All that said, this was in the context of someone asking Debian, a distribution, to do something, and as much as I support the author's right to release whatever software they want to write, I do think (speaking as a member of the Debian Project) that we should have some shared standards about what software we want to include in the distribution. In general, I think doing things deceptively behind the back of the user should be disqualifying. It doesn't fit what we're trying to accomplish in assembling a distribution. Whether this specific example is serious enough to meet that bar is arguable.

We don't accept very buggy software either. Part of the role of a distribution is to apply some vetting standards, IMO.

> Ultimately the only way to truly know what a given piece of software does is an exhaustive code review.

I do think it's important to not be too flippant about the level of social trust that's required to use software in the modern world (and a whole lot of other things besides software as well). We go through our daily lives implicitly relying on the good will of other people in innumerable ways, and there is absolutely no way that we could personally audit even a tiny fraction of the systems, services, and software that we rely on. We live in a society built on some level of mutual trust. Not all humans are trustworthy, so we do need some mechanism to distribute the verification of that trust and to discourage breaking that trust, or society would fall apart. We can't just have caveat emptor be the entirety of our moral calculus; the resulting libertarian hellscape would be unsurvivable. (And to be clear, I don't think that's what you're arguing for; that's just where my thoughts went when reading the last sentence of your message.)

Bug of feature?

Posted Jul 1, 2026 22:49 UTC (Wed) by pizza (subscriber, #46) [Link] (12 responses)

> All that said, this was in the context of someone asking Debian, a distribution, to do something, and as much as I support the author's right to release whatever software they want to write, I do think (speaking as a member of the Debian Project) that we should have some shared standards about what software we want to include in the distribution.

That's a reasonable attitude to take, but the key is "shared standards" (which don't actually exist yet, at least not in a way that would apply in this context)

> We don't accept very buggy software either. Part of the role of a distribution is to apply some vetting standards, IMO.

Again, what relation do "some vetting standards" have to do with the situation at hand?

>I do think it's important to not be too flippant about the level of social trust that's required to use software in the modern world

Believe me, I wasn't being flippant, just stating a hard truth that we all have to keep in mind.

Debian (and its developers/packagers) doesn't make any general promises about the software it ships, beyond the claim that a binary matches its corresponding ingredients + recipe [1] and integrates reasonably [2] well with the rest of the system. That's it.

There will undoubtedly be bugs, and there could easily be features some users don't expect, even to the point of being offensive/objectionable. Realistically, the only ones that truly know what a given piece of software is _intended_ to do [3] are its actual authors; for any others to have that confidence the software would have to be subjected to an exhaustively comprehensive audit. Vanishingly few packages in Debian qualify on that front.

Debian doesn't promise any particular outcome, just a best effort towards its stated/shared goals, and a process to achieve (and participate in) that.

[1] ie a given source tarball, with an enumerated set of patches applied and compiled in a particular manner
[2] compliance with Debian's various technical and administrative policies.
[3] which isn't necessarily what it _actually_ does, thanks to bugs

Bug of feature?

Posted Jul 1, 2026 22:58 UTC (Wed) by rra (subscriber, #99804) [Link] (11 responses)

> That's a reasonable attitude to take, but the key is "shared standards" (which don't actually exist yet, at least not in a way that would apply in this context)

Agreed. The way that one starts establishing such shared standards is to state what standards one would like to see and see how other members of the project react to them, which is what I did in the post cited all the way back in the original LWN article. Usually this process takes a long time and multiple separate events, and often the consensus is somewhat informal and takes a long time to be written down formally (if it ever is).

My stance is that I don't particularly care about "discrimination" because it means too many different things to different people, some of which I sharply disagree with. But I don't think we should include software that intentionally deceives the user about what it's going to do by, for instance, hiding behavior behind triggers that the user would not expect to have an effect. This is a very minor instance of that general principle, and thus not the greatest test case and probably not the package that will create a lot of consensus, but it's a good opportunity to state the principle and ask people to think about it. I'm sure this will come up again.

> Debian (and its developers/packagers) doesn't make any general promises about the software it ships

And indeed we should not, for a whole bunch of reasons including the obvious legal ones.

> Debian doesn't promise any particular outcome, just a best effort towards its stated/shared goals, and a process to achieve (and participate in) that.

Exactly. We are trying to do a bunch of things that we do not promise we will succeed at. This is, in general, how societies work and how mutual trust is built. Very few of the assumptions of trust are based on formal or enforceable promises. A lot is just good faith effort and attempts to avoid forseeable problems.

Bug of feature?

Posted Jul 2, 2026 10:08 UTC (Thu) by farnz (subscriber, #17727) [Link] (10 responses)

Part of the issue here is that there's no morally neutral shared standards to be found.

If you insist that upstream expressions of support for Ukraine are removed to protect residents of the Russian Federation, you upset one group to protect another. If you allow them to be kept in, as long as they're also upstream, you upset a different group to protect another.

This means that one of the questions Debian needs to be asking itself is "who are we willing to upset?".

Bug of feature?

Posted Jul 2, 2026 10:27 UTC (Thu) by evgeny (subscriber, #774) [Link] (9 responses)

It's not about "upsetting" - unless by upsetting you mean potentially physical violence and/or legal actions. It's quite similar to the issue of free speech - you're free to express your opinion as long as it doesn't hurt (not morally, not!) somebody else.

And, BTW, please explain why an average Ukrainian gets upset by knowing that an average Russian user of Xsnow sees the Ukrainian flag with the same frequency or doesn't see it at all?

The only person who may be upset by reverting this feature is Xsnow's author. And he has already agreed to do it.

Bug of feature?

Posted Jul 2, 2026 10:41 UTC (Thu) by farnz (subscriber, #17727) [Link] (8 responses)

Or, to put it as a Ukrainian friend has: "because Russian criminals are violent, Russians have pressured the xsnow maintainer into removing an expression of support for us - Debian is happy to see Ukrainian civilians killed by Russian military, but not Russians forced to stop using a little desktop toy for fear of their local criminals".

Bug of feature?

Posted Jul 2, 2026 11:00 UTC (Thu) by evgeny (subscriber, #774) [Link] (7 responses)

Do you believe *any* Russian citizen, unconditionally, whether they are a combatant or not, whether they support the war or not, whether they are a child or not, must be punished? I want to hear your opinion, not your hypothetical Ukrainian friend.

Bug of feature?

Posted Jul 2, 2026 11:25 UTC (Thu) by pizza (subscriber, #46) [Link] (4 responses)

> Do you believe *any* Russian citizen, unconditionally, whether they are a combatant or not, whether they support the war or not, whether they are a child or not, must be punished? I want to hear your opinion, not your hypothetical Ukrainian friend.

Do you believe in collectively punishing *everyone else* is an acceptable way to avoid possibly punishing any Russian citizen?

Because that's the other side of your very-much-hypothetical question.

Bug of feature?

Posted Jul 2, 2026 11:38 UTC (Thu) by evgeny (subscriber, #774) [Link]

> Do you believe in collectively punishing *everyone else* is an acceptable way to avoid possibly punishing any Russian citizen?

Who, specifically, will be punished by reverting this Xsnow feature?

> Because that's the other side of your very-much-hypothetical question.

There is nothing hypothetical there. Please try to explain your thoughts more clearly.

Bug of feature?

Posted Jul 2, 2026 12:58 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (2 responses)

> Do you believe in collectively punishing *everyone else* is an acceptable way to avoid possibly punishing any Russian citizen?

To be clear, removing a ukrainian flag from a software that is supposed to show christmas decorations doesn't punish anyone.

I've never heard of anyone that coming December takes out the box with the Ukrainian flags.

Do you know such a person to exist?

Bug of feature?

Posted Jul 2, 2026 13:27 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> To be clear, removing a ukrainian flag from a software that is supposed to show christmas decorations doesn't punish anyone.

What if those folks wanted that feature and are now deprived of the pleasure of using it? Yes, it's a very light punishment, but so what?

At best, this entire conversation is effectively just a watered-down variant of the classic "who is more important" trolley problem. At worst, it treats the aggressor and targets of a brutal war as morally equivalent.

Let's stop here

Posted Jul 2, 2026 14:10 UTC (Thu) by jzb (editor, #7867) [Link]

At this point I think we've reached the point where no minds are being changed and no new information is on offer. Let's move on, please.

Bug of feature?

Posted Jul 2, 2026 14:10 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (1 responses)

Yes. Next question?

Or maybe not. Your username looks russian, so you are probably not impartial.

Stop now

Posted Jul 2, 2026 14:13 UTC (Thu) by jzb (editor, #7867) [Link]

It's obvious that this is no longer a productive conversation. Let's end it here. No further replies to this, please.

Bug of feature?

Posted Jul 2, 2026 12:45 UTC (Thu) by evgeny (subscriber, #774) [Link]

I suggest closing this thread. The bug report has been filed (thanks to Salvo 'LtWorf' Tomaselli!). The author has agreed to revert the misfeature. Moreover, with the well-worded comment of Lev Lamberov, this topic ought to receive proper attention from the relevant Debian teams. Again, the issue is deeper than this specific Xsnow behavior.

As such, I consider my own mission in this case accomplished.

Many thanks to LWN for bringing this to my attention.

Many thanks to LWN readers who participated in the discussion. Everybody is entitled to their own opinion. Frankly, I was astonished that even among LWN subscribers, some people disagree with the Universal Declaration of Human Rights, in particular, its Article 2. Sigh.

Operating systems should avoid unnecessary politics

Posted Jun 30, 2026 21:15 UTC (Tue) by skissane (subscriber, #38675) [Link] (4 responses)

What happens if, hypothetically, an Israeli upstream package maintainer starts adding Israeli flag easter eggs displayed on Yom Ha'atzmaut, and that angers a pro-Palestine user? Keeping stuff politically neutral-including avoiding any country’s national flag (except in contexts when you include all of them)-would help Debian keep those kinds of intractable heated real world disputes out of the project. That implies, if upstream includes them, Debian should aim to patch them out if possible.

Now, including political messaging in the direct interests of the project - e.g. about copyright law reforms, etc - I think should be treated differently. But Debian has no distinctive political interest in the outcome of a war, separable from the general interests of all humanity-and people will interminably disagree about what those general interests are.

Operating systems should avoid unnecessary politics

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

There is no such thing as politically neutral.

Do you include support for e.g. trans or gender neutral, genderfluid,... identities? If not you discriminate against them, if you do Christians will claim you discriminate against them.

Do you include a geoip DB that includes Taiwan in China or one that shows it as a separate country?

Do you include national holidays where one country celebrates the independence from another in calendar programs?

Operating systems should avoid unnecessary politics

Posted Jul 5, 2026 1:05 UTC (Sun) by milesrout (subscriber, #126894) [Link]

The comment you replied to says "avoid unnecessary politics". If you have a field for selecting sex, it is necessary that you decide between either making it binary or not. If you have a geoip database, you need to decide what you're going to say for Taiwan, even if that is dependent on locale or whatever. If you have a database of national holidays, it's necessary to decide what to include.

There is also really nothing political about those things and there are easy solutions. For holidays and geoip, the easy solution is just to make it dependent on the locale. If you have zh_CN you show Chinese Taipei as a region of China, and if you have zh_TW you show the Republic of China as an independent country. If you have en_US you show the 4th of July as Independence Day, while if you have en_GB you don't show it as a holiday.

But this is not one of those situations. It is not necessary to include this "feature" at all. It's a purely political addition that is not necessary in any way.

Operating systems should avoid unnecessary politics

Posted Jul 1, 2026 18:00 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

Does this mean that Debian's packaged vim will be required to remove :help uganda because foreign aid is "political" and not "in the direct interests of the [Debian] project?" Or, if we're going to special-case charityware as allowed, does that extend to software that supports more controversial charities? What if an upstream wants their software to display rainbows in the month of June, ostensibly in support of The Trevor Project or a similar charity, will Debian remove that? Or is it "political" for Debian to spend resources on making such a change when the upstream is unwilling to do so?

The long and short of it is, I don't think these are useful questions for Debian developers to worry about. If software is causing some real, measurable harm to the user, then that is (at least potentially) a problem that can be addressed. But a blanket ban on politics quickly transforms into an intractable quagmire of arbitrary restrictions and contradictory requirements.

Operating systems should avoid unnecessary politics

Posted Jul 1, 2026 18:22 UTC (Wed) by rra (subscriber, #99804) [Link]

Yes. Exactly this.

I flatly refuse the request to avoid politics in my free software work. This is for a lot of reasons, but the most obvious is that politics is the main reason why I'm working on free software in the first place. The idea that there is some narrow set of (conveniently, often capitalist-libertarian and somewhat right-wing) set of politics that are "okay" for free software and all other politics have to be excluded is utter nonsense, and I will not be complying.

But I am still interested in finding ground on other principles that don't require that I adopt other people's political beliefs about such loaded issues as discrimination, such as a principle that authors of software should not use their power to act against the interests of the user. And I will advocate for that as a free software issue, because allowing people to be in control of their own computing is part of my politics. :)

Functionality is not the issue

Posted Jul 1, 2026 3:10 UTC (Wed) by gdt (subscriber, #6284) [Link]

It's the deceptive way the software works which is the issue. Update the man page and debian package description to document that behaviour and the issue is solved. No one is misled, it's now plain that xsnow displays political statements (as flags as a symbol of allegiance or affiliation). Users can install it or not as they prefer. Potential users are also free to fork the software.

Simple solution

Posted Jul 1, 2026 11:33 UTC (Wed) by tao (subscriber, #17563) [Link]

I'd suggest that a simple, non-discriminatory, solution to this is to patch the package to always use the higher probability.

That way users of the Russian locale are not discriminated against, while the upstream's maintainer's intent to bring attention to the Russian invasion of Ukraine is retained.

Everything is political

Posted Jul 5, 2026 1:05 UTC (Sun) by sethkush (subscriber, #107552) [Link]

Debian itself is inherently political. It's a very ideological/principled project.

I don't see how this is meaningfully different from VLC's Santa hat easter-egg.