A friend of mine joked when this came to light the other day that we should start the timer to see how long it would be before some SystemD person crawled out of the woodwork to say that was expected behavior and you're an idiot for using it wrong. And we laughed to ourselves, wouldn't that would be funny, that really is the reputation they have now isn't it.
Well, jokes on us, because that's the first fucking comment on the bug.
systemd version the issue has been seen with 256 Used distribution Debian Unstable Linux kernel version used 6.8.12-amd64 CPU architectures issue was seen on x86_64 Component systemd-tmpfiles Expec...
ugh, that's one nasty footgun and "RTFM" is a really shitty response when the reporter politely and extensively explained that the description in the fine manual is quite confusing.
"/home is a tempfile" isn't just a footgun, it's an explicit ideological attack on the whole idea of Linux.
I am dead serious when I say that.
SystemD has replaced a human-legible init system with a project whose constituency is large scale SAAS deployments, and if the only people who matter to Linux are the people using an Linux as an invisible, unexaminable underpinning of a service platform then there is _no point to Linux at all_. It's just free labor for infracorps.
I can relate to that. The old joke of the year of "Linux on the desktop" has devolved into how long until Linux on the desktop is gone because all the paid-for development is for enterprise-centric use-cases.
@gabrielesvelto We used to joke that the Year Of Linux On The Desktop would happen when desktops were obsolete, but I would not have guessed that people would just abdicate the idea entirely before that day came about.
@gabrielesvelto At least on Fedora, it looks as if tmpfilesd is being used purely to make sure quotas are applied. So there are multiple layers of stupid here:
- Using a temporary file management daemon to handle quotas for non-temporary files. - Making quota-management part of a temporary files daemon rather than keeping it as a separate composable utility. - Making --purge purge things that aren't set up to have any cleanup applied.
Fun feature for trolls though. "To clean up temporary files and clear space, just run sudo systemd-tmpfiles --purge."
Look, "/home is a tempfile" isn't just a footgun, or a bug.
It's an explicit ideological attack on the whole idea of what Linux is and who Linux is for.
If /home is just a tempfile to be purged when drivespace pressure hits some arbitrary threshold then Linux is a corporate-owned SAAS shim, and that's all it is. It's not just "breaking userspace", it's abandoning the idea that the people using that space and the stuff they've made there matter at all.
The whole system makes sense when your realize that SystemD's only constituency is people who want to rent out computers. Not for people who want to live under a their own roof, maybe in a community, to maybe build something together.
tmpfiles just needs to be renamed. It hasn't been just for temporary files for a very long time. Yes this is a foot gun
/home is not a temporary file. And it has never been seen as one by systemd. In fact, systemd has tools like homed that are designed explicitly to give more control of your home dir to you, the user, with more flexibility over it than with traditional home dirs. I think that's as clear as it gets.
So no, systemd is not only for landlords. Quite the opposite.
@AdrianVovk There absolutely should not be functionality to rm -rf /home in systemd or anything that would ever be installed on non-landlord systems. There is no plausible reason for someone ever to want that done as some sort of automatic management process to their own personal system.
@dalias Nothing happens automatically here... It's a command you have to run. Yeah it was poorly documented that it's essentially a factory reset and that has since been corrected.
By your own argument, the presence of rm makes your system exclusive to landlords, whatever that means. Which is silly.
tmpfiles is not a conspiracy to secretly run rm -rf /home on your system when you're not looking. It's a tool that creates /home on first boot, told by user to delete everything it created
Something _absolutely does_ happen "automatically" here. The Systemd team has created a program _named for managing temp files_ that automatically and invisibly started including homedirs, a "feature" that was in turn invisibly included in an update, nowhere in which the words "tmpctl" and "/home" appear in the same sentence.
I have no idea what train of thought makes you believe this kind of user-hostile nonsense is reasonable, justifiable or excusable.
I admin a single server that I own — it sits here on the table next to me. systemd's cohesive design and existant docs have been a real boon to me but go off i guess
I remember the discussions about whether Debian should adopt systemd.
My argument was: no, that would be dumb for distributions on many levels (top 5 strategic problems systemd causes for distributions): draketo.de/light/english/top-5…
I use Guix these days, and that it does not use systemd is one of the reasons. guix.gnu.org/
I trust neither systemd nor its developers.
Linux once promised not to break userspace. Sounds like that should also mean to advise against using systemd.
Mi, 11/20/2013 - 18:42 — Draketo systemd is a new way to start a Linux-system with the expressed goal of rethinking all of init. These are my top 5 gripes with it. (»skip the updates«) Update (2019): I now use GNU Guix with shepherd.
@ArneBab I haven't tried scaling the Guix cliff face yet, but I'm pretty sure I'm going to have to pretty soon. Is there something like an "Ubuntu but Guix" initiative anywhere?
I’m not sure. One word of warning: Guix requires quite a lot of diskspace, because it can freely mix and match versions of dependencies, and quickly getting a program just for one shell (as I do regularly) causes high disk usage on the long run.
⇒ don’t use it for small devices. I have 500 GB for / and 500GB for /home to shield myself from that. guix gc cleans up, but then packages added in the running shell need to be re-installed.
@ArneBab I'd recommend beginning with Guix, the package manager, on your distro. Try out guix shell/container. Then, let Guix System gobble up your distro completely. I use guix home to manage my home environment as well, I don't think anything else comes even close to the flexibility, control, and power which guix delivers.
Only thing here, you should've put "GNU" in several of the places you put "Linux".
Strictly speaking, Linux is just one of the pieces of software that comprise the majority of GNU releases.
I do not ever give this lecture when people just use Linux as shorthand for the OS, but the cognitive dissonance is kinda high with this one cause what we're really talking about is the Unix philosophy, which is from the old times, but informs the ethics of GNU/Linux.
it's interesting you say this because NixOS, in practice, also sorta believes that /home shouldn't contain anything other than generated outputs and purely transient state.
@rotopenguin I enjoyed how it took me 6 hours of research, 3 incorrect tutorials, multiple shrugs from local nix experts here and I still couldn't get a straight answer on how to use local files in a nix flake.
But more directly: you're supposed to be able to completely reproduce any process and produce an immutable output. So is this "I put my family photos in a repo and then the flake copies them locally and I sync by hand?"
@Elucidating @rotopenguin so, that was basically true for Linuxes pre-knoppix and later Ubuntu. I don’t think it’s necessarily an indication of bad tech, just early tech.
@Elucidating @rotopenguin Linux was never* that hostile to longstanding, intuitive core behavior. “Where I put my stuff” was never temporary by default.
Even Solaris-isms like /export/home were completely predictable.
*And my first Linux was kernel 0.99.3 on 5.25” floppies.
i feel like the actual issue here isn't "/home is a tempfile" (it isn't, by basically any useful definition), it's "systemd-tmpfiles is poorly named and documented for what it's used for in practice but renaming it would be a large breaking change" and "systemd-tmpfiles --purge with no additional flags sounds like something useful (removes unused temporary files?) but it's not actually an operation that makes any sense to do" (it'll be disallowed in the next release)
It's hilarious that everyone is still ranting about this (with a questionable spin on things) while upstream already implemented and backported a restriction of the usage of the parameter in question to prevent this (deleting home) from happening and clarification for the intended use-case. Which is not at all freeing up space by deleting tempfiles. Yes the tool's name is misleading, but if you ever maintained a sizeable project you should be able to relate to not wanting to rename.
The bug got fixed after public outcry, but the working culture that allowed that bug to exist in the first place hasn't changed at all and that's the problem.
If you've ever maintained a sizeable project, you know that long term, discoverability and legibility outweigh literally everything else, and when you find a problem with supportability you can solve with grep you take that win every single time.
You may chose to believe that, the convo in the bug report and actions beg to differ. Sure the original state was bad, but it's clear there was nothing intentional or systematic about it. Like actually considering /home as temporary and wanting to purge it, as it widely insinuated. Anyway, I doubt there are any open minds in this discussions, si bit much point having them (yeah I realise that's inconsistent with me answering, I can't help it and don't claim to be fully rational (or close to) :) ).
@imsodin "Nothing intentional?" Guy, _read the bug_.
bluca's opening comment is quite literally "this is working as intended and you are stupid".
The second comment says explicitly "the tool itself is nothing wrong."
It's not until you're 2/3rds of the way down the page that someone says "We need to rethink how --purge works. The principle of not ever destroying user data is paramount" and the next 2 comments from Poettering and Bluca are repeating that No Actually It's Right Actually.
Yeah it is "right", as that's always in the eye of the beholder: You do want to purge user files if there user really wants to, e.g. application data when purge uninstalling that application. And it's super unlikely that anyone ever wants to do that with everything on their system, i.e. using it without a config file like the original reporter did. And now doing that is disallowed. I don't defend the original state as being good or anything, it's just ridiculous how people conflate nit being aware of/ignoring a problematic possible (mis)use of a tool with a conspiracy of systematic intention of harming userspace. Oh and yes, Luca's communication here (not dating it's the only time) is not conductive of a constructive discussion (to put it mildly) - if that was what you all were complaining about, that would make a lot more sense.
@Simon Frei @mhoye So you agree 1) the tool was improperly designed 2) the tool was improperly documented 3) the bug were improperly triaged 4) the bug improperly managed
So what is your issue with being annoyed about being annoyed that things were put in a state where you could destroy your system using a tool where the documentation implies that it does something that *isn't* destroy the system?
1) not ideal maybe 2) yes 3) 4) no - there was one contributor reacting not very helpfully, but overall the reaction to the report went into the right direction and quickly so. Also I wasn't poking at "being annoyed", I was poking at all the conjecture about intent and outrage, ask the huge noise being made over this (at least many outraged and well populated toots made it into my timeline, a perfectly objective measure of scale of outrage of course).
@Simon Frei I see - so you don't understand how these things point to a core problem in the project and are not concern about the project nor its future, and think we should be less worried? I think you'll find most of the people making the noise disagree.
@silverwizard Oh I know they do, and a minority is also doing something about it (e.g. devuan and guix people), not just because of this but because of more reasonable concerns instead of just making a ruckuss like a majority (I suspect). I did read some issues with systemd I agree with (ok a few even), but nothing related to the issue here. Expect maybe the comm style exemplified by Luca here, but that's an unfortunately quite widespread issue not restricted to systemd only.
@phillmv Upstart was genuinely great. Readable, understandable and discoverable, a great process babysitter. Abandoning that in favor of SystemD wasn't recognized as a genuine ideological schism at the time, but it was.
@markusmunch It's somewhat blunt, but there is a kernel (heh) of truth in there, however bluntly brought: if you're not quite sure what a command does, don't run it, read up first. In this instance one could have simply used a `rm` invocation
@markusmunch True, but systemd-tmpfiles hasn't only done tmpfiles in quite a long time, thoough that does reflect one other point: (re)naming of tools to match their task/intent, which is pointed out in the github bug as well.
@mhoye Look, it's plainly in the documentation that when you press this button, the computer will shoot you in the face. It's your fault for not reading the docs.
Do not question why there exists a button that shoots you in the face without warning
@argv minus one You say that like it's a good thing. I also acknowledged the difference between / and *. My point, which remains unchanged, was that there is an effort underway to reduce the number of foot guns, and that's a good thing.
@nyankat @Polychrome The responses were not reasonable at all. No apology, no admission of error in the bug or that terrible opening comment, or even a nod towards the idea that a tempfile tool handling or deleting home might be a bad idea. The whole thing is a mess.
@rootwyrm This was my conclusion just from the few receipts I found a number of years back, but good to know my assessment was accurate.
I was just a pup when the big Debian controversy went down, but once Debian failed to explode and perish I decided to try to be open-minded about it and use it on its own terms and such, but the conclusion I reached after a while is that the dev team is kind of a cult. Not quite one, but definitely holders of articles of faith, like "concurrency".
I get the deeply hostile attitude towards users inherent in this approach. I’m not 100% opposed, though, because I prefer a system where my user files are persisted on a different volume that is synthesized into the local file hierarchy. When her it’s the approach used by the Andrew project in the 1980s, the NeXT systems proposal to use the removable drives as your portable home storage, or a cloud storage system, there are many options.
rm -rf / requires you to use --no-preserve-root. I'm not sure about using * from within the root directory and I'm not about to spin up a VM to test it, but this at least acknowledges that there's a problem.
If you don't already know what it does, it at least isn't a command that gives the impression of doing something different.
Given that they've fixed the submitted bug in 256.1, it seems that the maintainers of systemd disagree with you as well.
@WillA763 It's not fair to call him an MS employee, as a means of putting down systemd, because he was a Red Hat employee the whole time he developed it until he recently left to be employed by Microsoft.
I forget where but someone just said that one day systemd will become mundane and then someone will replace it with something non-monolithic, API compatible, and equally mundane. This has happened with Pulseaudio -> pipewire, systemd-udev, etc etc.
My sibling in Sheogorath, if you blindly run a command with an option named “purge” and simply *assume* what it does, then I'm very glad you don't have root on any system I'm responsible for.
mhoye
in reply to mhoye • • •Tired: ignoring usability problems.
Wired: ignoring that words mean things.
jollyrogue reshared this.
Gabriele Svelto
in reply to mhoye • • •mhoye
in reply to Gabriele Svelto • • •@gabrielesvelto
"/home is a tempfile" isn't just a footgun, it's an explicit ideological attack on the whole idea of Linux.
I am dead serious when I say that.
SystemD has replaced a human-legible init system with a project whose constituency is large scale SAAS deployments, and if the only people who matter to Linux are the people using an Linux as an invisible, unexaminable underpinning of a service platform then there is _no point to Linux at all_. It's just free labor for infracorps.
Gabriele Svelto
in reply to mhoye • • •mhoye
in reply to Gabriele Svelto • • •Hubert Figuière
in reply to mhoye • • •JimmyChezPants 🇨🇦
in reply to mhoye • • •@gabrielesvelto
"Goddamit Lennart. I said /home is a *temple*, not a tempfile. You idiot!"
mathew
in reply to mhoye • • •@gabrielesvelto At least on Fedora, it looks as if tmpfilesd is being used purely to make sure quotas are applied. So there are multiple layers of stupid here:
- Using a temporary file management daemon to handle quotas for non-temporary files.
- Making quota-management part of a temporary files daemon rather than keeping it as a separate composable utility.
- Making --purge purge things that aren't set up to have any cleanup applied.
Fun feature for trolls though. "To clean up temporary files and clear space, just run sudo systemd-tmpfiles --purge."
mhoye
in reply to mhoye • • •Look, "/home is a tempfile" isn't just a footgun, or a bug.
It's an explicit ideological attack on the whole idea of what Linux is and who Linux is for.
If /home is just a tempfile to be purged when drivespace pressure hits some arbitrary threshold then Linux is a corporate-owned SAAS shim, and that's all it is. It's not just "breaking userspace", it's abandoning the idea that the people using that space and the stuff they've made there matter at all.
reshared this
Chris Siebenmann, MrCopilot and Charlie Stross reshared this.
Esther Payne
in reply to mhoye • • •I've been worried about this sort of thing happening ever since I heard systemD was aiming at userspace.
I knew /home would be in their sights.
neoluddite
in reply to mhoye • • •mhoye
in reply to mhoye • • •SystemD is for landlords.
The whole system makes sense when your realize that SystemD's only constituency is people who want to rent out computers. Not for people who want to live under a their own roof, maybe in a community, to maybe build something together.
SystemD is software for landlords.
reshared this
M. The Crystalline Entity and Charlie Stross reshared this.
Fly-paper-love-maker
in reply to mhoye • • •Adrian Vovk
in reply to mhoye • • •tmpfiles just needs to be renamed. It hasn't been just for temporary files for a very long time. Yes this is a foot gun
/home is not a temporary file. And it has never been seen as one by systemd. In fact, systemd has tools like homed that are designed explicitly to give more control of your home dir to you, the user, with more flexibility over it than with traditional home dirs. I think that's as clear as it gets.
So no, systemd is not only for landlords. Quite the opposite.
Cassandrich
in reply to Adrian Vovk • • •Adrian Vovk
in reply to Cassandrich • • •@dalias
Nothing happens automatically here... It's a command you have to run. Yeah it was poorly documented that it's essentially a factory reset and that has since been corrected.
By your own argument, the presence of rm makes your system exclusive to landlords, whatever that means. Which is silly.
tmpfiles is not a conspiracy to secretly run rm -rf /home on your system when you're not looking. It's a tool that creates /home on first boot, told by user to delete everything it created
mhoye
in reply to Adrian Vovk • • •Something _absolutely does_ happen "automatically" here. The Systemd team has created a program _named for managing temp files_ that automatically and invisibly started including homedirs, a "feature" that was in turn invisibly included in an update, nowhere in which the words "tmpctl" and "/home" appear in the same sentence.
I have no idea what train of thought makes you believe this kind of user-hostile nonsense is reasonable, justifiable or excusable.
wants to befriend a capybara
in reply to mhoye • • •Héctor The One And Only
in reply to mhoye • • •Why does every piece of software in the FOSS world have to become a religious crusade?
If you don’t want to use it, don’t!
mhoye
in reply to Héctor The One And Only • • •Philip J. Hollenback
in reply to mhoye • • •Jules 🍺
in reply to mhoye • • •Arne Babenhauserheide
in reply to mhoye • • •I remember the discussions about whether Debian should adopt systemd.
My argument was: no, that would be dumb for distributions on many levels (top 5 strategic problems systemd causes for distributions):
draketo.de/light/english/top-5…
I use Guix these days, and that it does not use systemd is one of the reasons.
guix.gnu.org/
I trust neither systemd nor its developers.
Linux once promised not to break userspace. Sounds like that should also mean to advise against using systemd.
Top 5 systemd troubles - a strategic view for distros | Zwillingssterns Weltenwald | 1w6
www.draketo.demhoye
in reply to Arne Babenhauserheide • • •Arne Babenhauserheide
in reply to mhoye • • •I’m not sure. One word of warning: Guix requires quite a lot of diskspace, because it can freely mix and match versions of dependencies, and quickly getting a program just for one shell (as I do regularly) causes high disk usage on the long run.
⇒ don’t use it for small devices. I have 500 GB for / and 500GB for /home to shield myself from that.
guix gc cleans up, but then packages added in the running shell need to be re-installed.
That said: it’s really nice to be able to do that
prasoon
in reply to mhoye • • •JimmyChezPants 🇨🇦
in reply to mhoye • • •Only thing here, you should've put "GNU" in several of the places you put "Linux".
Strictly speaking, Linux is just one of the pieces of software that comprise the majority of GNU releases.
I do not ever give this lecture when people just use Linux as shorthand for the OS, but the cognitive dissonance is kinda high with this one cause what we're really talking about is the Unix philosophy, which is from the old times, but informs the ethics of GNU/Linux.
Chris Combs (he/him)
in reply to JimmyChezPants 🇨🇦 • • •JimmyChezPants 🇨🇦
in reply to Chris Combs (he/him) • • •Don't you have a class on macaroni art to teach or something?
mhoye
in reply to JimmyChezPants 🇨🇦 • • •JimmyChezPants 🇨🇦
in reply to mhoye • • •@combs
Oh sorry, I thought we were talking about some deep history and fundamental philosophies of the thing, not being promo guys.
Someone ad homs, I might ad hom back, it's just how it goes.
mhoye
in reply to JimmyChezPants 🇨🇦 • • •Jamie McCarthy
in reply to mhoye • • •JP
in reply to mhoye • • •mhoye
in reply to JP • • •Sheogorath
in reply to mhoye • • •> It's an explicit ideological attack on the whole idea of what Linux is and who Linux is for.
May I ask, because I honestly don't know: Who is Linux for?
mhoye
in reply to Sheogorath • • •railmeat
in reply to mhoye • • •@sheogorath
I don’t think that is the complete answer.
⛈️ Information ⛈️
in reply to mhoye • • •it's interesting you say this because NixOS, in practice, also sorta believes that /home shouldn't contain anything other than generated outputs and purely transient state.
Lord help you if you have browser bookmarks.
ROTOPE~1
in reply to ⛈️ Information ⛈️ • • •⛈️ Information ⛈️
in reply to ROTOPE~1 • • •@rotopenguin I enjoyed how it took me 6 hours of research, 3 incorrect tutorials, multiple shrugs from local nix experts here and I still couldn't get a straight answer on how to use local files in a nix flake.
But more directly: you're supposed to be able to completely reproduce any process and produce an immutable output. So is this "I put my family photos in a repo and then the flake copies them locally and I sync by hand?"
mhoye
in reply to ⛈️ Information ⛈️ • • •⛈️ Information ⛈️
in reply to mhoye • • •mhoye
in reply to ⛈️ Information ⛈️ • • •⛈️ Information ⛈️
in reply to mhoye • • •curtosis
in reply to mhoye • • •@Elucidating @rotopenguin Linux was never* that hostile to longstanding, intuitive core behavior. “Where I put my stuff” was never temporary by default.
Even Solaris-isms like /export/home were completely predictable.
*And my first Linux was kernel 0.99.3 on 5.25” floppies.
Empathic Qubit (Old)
in reply to mhoye • • •@gsuberland
leo vriska
in reply to mhoye • • •systemd-tmpfiles --purgewith no additional flags sounds like something useful (removes unused temporary files?) but it's not actually an operation that makes any sense to do" (it'll be disallowed in the next release)Simon Frei
in reply to mhoye • • •mhoye
in reply to Simon Frei • • •Everything you've just said is wrong.
The bug got fixed after public outcry, but the working culture that allowed that bug to exist in the first place hasn't changed at all and that's the problem.
If you've ever maintained a sizeable project, you know that long term, discoverability and legibility outweigh literally everything else, and when you find a problem with supportability you can solve with grep you take that win every single time.
Also, this shit's not funny in the least.
Simon Frei
in reply to mhoye • • •mhoye
in reply to Simon Frei • • •@imsodin "Nothing intentional?" Guy, _read the bug_.
bluca's opening comment is quite literally "this is working as intended and you are stupid".
The second comment says explicitly "the tool itself is nothing wrong."
It's not until you're 2/3rds of the way down the page that someone says "We need to rethink how --purge works. The principle of not ever destroying user data is paramount" and the next 2 comments from Poettering and Bluca are repeating that No Actually It's Right Actually.
Simon Frei
in reply to mhoye • • •Oh and yes, Luca's communication here (not dating it's the only time) is not conductive of a constructive discussion (to put it mildly) - if that was what you all were complaining about, that would make a lot more sense.
silverwizard
in reply to Simon Frei • •@Simon Frei @mhoye So you agree
1) the tool was improperly designed
2) the tool was improperly documented
3) the bug were improperly triaged
4) the bug improperly managed
So what is your issue with being annoyed about being annoyed that things were put in a state where you could destroy your system using a tool where the documentation implies that it does something that *isn't* destroy the system?
Simon Frei
in reply to silverwizard • • •Also I wasn't poking at "being annoyed", I was poking at all the conjecture about intent and outrage, ask the huge noise being made over this (at least many outraged and well populated toots made it into my timeline, a perfectly objective measure of scale of outrage of course).
silverwizard
in reply to Simon Frei • •Simon Frei
in reply to silverwizard • • •jollyrogue
in reply to mhoye • • •There really needs to be a split. The corps can have LINUX(tm), and people can get the personal *nix Linux was supposed to be.
I have no idea how this would be accomplished, but out needs to happen. From some who runs Linux on servers and my laptop.
phillmv
in reply to mhoye • • •i feel like maybe we get around some of this stuff by like,
having a folder with some shell scripts that represent each service being booted
mhoye
in reply to phillmv • • •JimmyChezPants 🇨🇦
in reply to mhoye • • •@phillmv
I seem to recall it being recognized lol
On all sides, as a telling foible of their ideological opponents. It felt like old BBS flame wars round here for a while. :>
markusmunch
in reply to mhoye • • •Sebastiaan
in reply to markusmunch • • •mhoye
in reply to Sebastiaan • • •@sebastiaanfranken @markusmunch
There is no world in "I should see if this command thinks /home is a temp file" is a reasonable question to believe a human might ask. None.
Sebastiaan
in reply to mhoye • • •KasTas
in reply to mhoye • • •well, in general, pointing out that "something is in the documentation" is just missing half of the problem :|
Too many times it's been misleading, out-dated, trumped by some defaults or just... not there.
Also, talking about (missing) ways and means to actually test shit before deploying to actual machine :|
mhoye
in reply to KasTas • • •Jonathan Lamothe
in reply to mhoye • • •@mhoye Look, it's plainly in the documentation that when you press this button, the computer will shoot you in the face. It's your fault for not reading the docs.
Do not question why there exists a button that shoots you in the face without warning
argv minus one
in reply to Jonathan Lamothe • • •Jonathan Lamothe
in reply to argv minus one • • •/and*. My point, which remains unchanged, was that there is an effort underway to reduce the number of foot guns, and that's a good thing.mhoye
Unknown parent • • •JimmyChezPants 🇨🇦
Unknown parent • • •@rootwyrm
This was my conclusion just from the few receipts I found a number of years back, but good to know my assessment was accurate.
I was just a pup when the big Debian controversy went down, but once Debian failed to explode and perish I decided to try to be open-minded about it and use it on its own terms and such, but the conclusion I reached after a while is that the dev team is kind of a cult. Not quite one, but definitely holders of articles of faith, like "concurrency".
nutilius@SDF
in reply to mhoye • • •Charlie Stross
Unknown parent • • •Juan Luis
Unknown parent • • •Awesome New Year Robot
in reply to mhoye • • •Maybe the fix is to rename the option "--purge-all-including-home"
Human factors do matter, and human factors bugs are also bugs...
gim
in reply to mhoye • • •i keep repeating this, but there's only one cure... #nosystemd
nosystemd.org/
No systemd
nosystemd.orgTeknique is my middle name
in reply to Charlie Stross • • •IPmonger
in reply to mhoye • • •Jonathan Lamothe
Unknown parent • • •@Krangled Failstate
This is nonsense for at least three reasons:
rm -rf /requires you to use--no-preserve-root. I'm not sure about using*from within the root directory and I'm not about to spin up a VM to test it, but this at least acknowledges that there's a problem.It was bad UX, plain and simple.
Jonathan Lamothe
Unknown parent • • •Jonathan Lamothe
in reply to Jonathan Lamothe • • •@Krangled Failstate As for your remaining points, watch this video:
youtube.com/watch?v=LZM9YdO_QK…
If you still don't understand, watch it again.
Jonathan Lamothe
Unknown parent • • •@Krangled Failstate
"Oh no, we found an unexploded land mine from the second world war."
"Pfft. It hasn't been a problem in all this time. It's fine."
This is basically the same argument.
Seriously. Just stop.
mhoye
Unknown parent • • •BardMoss the Linux Guy
Unknown parent • • •It's not fair to call him an MS employee, as a means of putting down systemd, because he was a Red Hat employee the whole time he developed it until he recently left to be employed by Microsoft.
Bakunin Boys
in reply to mhoye • • •argv minus one
Unknown parent • • •@SecurityWriter
My sibling in Sheogorath, if you blindly run a command with an option named “purge” and simply *assume* what it does, then I'm very glad you don't have root on any system I'm responsible for.
@mhoye
dr_barnowl
in reply to mhoye • • •At first I was all
"Well clearly the problem lies with the idiot who used `systemd-tmpfiles` to create their /home folder"
Then I found the idiot
mhoye
in reply to dr_barnowl • • •