Microsoft and Debian

8 réponses [Dernière contribution]
grosbidepoilu
Hors ligne
A rejoint: 10/08/2023

News about “Microsoft Inside Debian is Sabotaging Debian and Its Many Hundreds of Derivatives With SystemD” on site
https://techrights.org/n/2024/06/23/Microsoft_Inside_Debian_is_Sabotaging_Debian_and_Its_Many_Hundr.shtml
Is this true?

Magic Banana

I am a member!

I am a translator!

Hors ligne
A rejoint: 07/24/2010

What is true? That some Microsoft employees contribute to free software? Yes, that is true. And that is good. That the developer who introduced a new option then fixed a bug related to it? Yes, that is true. And very common. Only conspiracy theorists such as Techrights can turn that into an article starting with a press clipping on Nazi purges and writing sentences such that "What is this, another imperialistic Italian-German collaboration?". In my opinion, Techrights is a site to ignore.

Avron

I am a translator!

Hors ligne
A rejoint: 08/18/2020

Why the indicated change is sabotage is not clear to me from this article. Is this because a lot of software may be broken when the change is adopted, if their developpers don't do extra work to adopt systemd? What might be interesting is to have examples.

In general, this may be similar to what Google is doing with Android: they are changing many things so that apps that are not modified will break, and it becomes difficult for free software developpers to keep up with the pace of required changes imposed by Google.

Microsoft may have no interest in making GNU/Linux work, or even have interest in making it not work, but it seems to me that, even though Google developped Android and certainly have interest in making it work, their behaviour may have similar consequences for free software developpers.

EDIT: I agree with Magic Banana that Techrights has a lot of utterly stupid statements, but I am still trying to understand whether there is any relevant technical point somewhere.

Magic Banana

I am a member!

I am a translator!

Hors ligne
A rejoint: 07/24/2010

Why the indicated change is sabotage is not clear to me from this article.

The option in question was added because it is "Useful for purge/factory reset patterns", as the Techrights article quotes. It was not intended for end users. One of them used it, suffered the consequences, and reported issue #33349. Three pull requests (including by Luca Boccassi and Lennart Poettering, that Techrights reduces to their nationalities and call the "imperialistic Italian-German collaboration") were merged to fix the issue in different ways:

There is no sabotage. Just the usual conspiracy theory about systemd.

prospero
Hors ligne
A rejoint: 05/20/2022

"imperialistic Italian-German collaboration"

Typical smokescreen. Everybody knows that all dangerous imperialist conspirators are French emigrants.

> It was not intended for end users.

"Users may use this to create and clean up files under their control..."
https://github.com/systemd/systemd/blob/f27ae592f70ea5f3f85a178dba3b94140cf808ee/man/systemd-tmpfiles.xml#L88

Magic Banana

I am a member!

I am a translator!

Hors ligne
A rejoint: 07/24/2010

In my sentence, "It" does not refer to the systemd-tmpfiles command in general but to its --purge option.

[SAV DES EMISSIONS]Dis donc, tu ne viens plus aux soirées (pour conspirer) ?[/SAV DES EMISSIONS]

prospero
Hors ligne
A rejoint: 05/20/2022

"The primary usecase for this option is to automatically remove files and directories that originally have been created on behalf of an installed package at package removal time."
https://github.com/systemd/systemd/blob/f27ae592f70ea5f3f85a178dba3b94140cf808ee/man/systemd-tmpfiles.xml#L167

This does sound like something I may have wanted to do on my system, at times. In fact, I have been wondering how to achieve exactly this each time I use apt purge, which only purges system configuration files and leaves orphaned config files in ~/.config and other user directories. Since I am getting older, slower and lazier, and seldom get into frantically adding and removing packages these days, I just do a fresh install of Trisquel beta every other year and all is purged.

[SAV DES EMISSIONS]Tu vois, il faut purger le système pour éliminer tous les résidus (et reprendre le contôle du monde).[/SAV DES EMISSIONS]

Magic Banana

I am a member!

I am a translator!

Hors ligne
A rejoint: 07/24/2010

"The primary usecase for this option is to automatically remove files and directories that originally have been created on behalf of an installed package at package removal time."

There are several scary sentences around that quote. They explain that "much of the installed system files might be removed" (well, actually the opposite, thank to one of the merge I listed above), recommend to "verify which files and directories will be deleted" and explicitly warn that "this is usually not the command you want!". Those scary sentences were missing right after the "factory reset" became an option. They were added to "fix the issue", while retaining the feature.

[SAV DES EMISSIONS]Attention ! Ça va (sysdem)déféquer de partout ![/SAV DES EMISSIONS]

prospero
Hors ligne
A rejoint: 05/20/2022

Just look at the 49 thumbs down the dev answer got, maybe there should be a tool to purge that too:
https://github.com/systemd/systemd/issues/33349#issuecomment-2168794281

In the end everybody agreed that allowing that command to run without specifying any target file was a very bad idea, and we even get a clue about why the whole thing was introduced in the first place: "an option to do a full factory reset is something I want to use in the future." This sounds rather careless, but devoid of the element of deliberate destruction implied by "sabotage". Also, note how the two suspected imperialistic collaborators started blaming each other once the deed was uncovered, which indicates poor conspirator coordination skills.