Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I was really impressed how Boccassi "project managed" this change, gathering feedback, addressing feedback where necessary, and continued to push the ball forward even under lots of objection. Many people would have just given up and the status quo would have remained for another couple years.


According got the article Boccassi wanted concrete scenarios where things might break, but his justification for making the change was “upstream and other dists”.

Systemd now essentially control Debian both the OS itself, and though Boccassi, the development.


And when he got concrete scenarios he dismissed each and every one of them as "this is just you doing this".


Excepting a General Resolution or a Policy violation, every accredited Debian Developer can do whatever the heck they feel like in their own packages.

This can pose problems. Boccasi steamrollered, but relatively politely.


Beyond "relatively politely."

People were more interested in bitching about edge cases where maintainers / projects / authors were doing things they should not have been doing in the first place than they were about addressing those issues, so he addressed them himself.

The man literally put up when others would not shut up.


The fact that YOU don't have a particular use case doesn't necessarily mean much. Billions of people don't use linux and this all doesn't matter to them.

But perhaps 30% could be in what you call "edge case", since your statistics is entirely based on yourself.


The fact that YOU have a particular use case doesn't necessarily mean much either. Just customize your configuration accordingly, and move on.


But according to you, anyone who isn't "bluca" is an edge case :D


Yeah so much naysaying. Especially the people storing important files in `/var/tmp`! It's like complaining to the council for collecting bins because you like to keep your keys in them. Wtf.

Good work pushing through it Boccassi!


It's my bin. I paid a lot of money for it. I can keep my keys in it if I want and if it's convenient for me. I don't work for the council and I don't care what their agenda is.

Why not just have the installer _ask_ me what configuration I prefer? Is there some reason you have to force the change, announce a victory, then make me to go mucking with "defaults" after the fact?


You can already change the configuration in the installer, it's called manual partition setup. The installer doesn't need a clicky screen for every setting that may have changed over the last 30 years.


So if I do the manual partition setup it's not going to run the daemon that automatically deletes files off those partitions during runtime for me? It sounded from the article like this change is more comprehensive than just the partition.


It’s a systemd service: https://www.freedesktop.org/software/systemd/man/latest/tmpf...

You will have to disable it separately. From the article:

“To stop periodic cleanups of /tmp and /var/tmp users can run touch /etc/tmpfiles.d/tmp.conf.”


I doubt it'll change the auto-cleanup. It probably is configurable with dpkg-reconfigure, or maybe it's just a service that needs to be disabled. Post-installation configuration is still a thing, and it changes every version. That's what versions are for.


> Why not just have the installer _ask_ me what configuration I prefer?

Because nobody bothered to actually put in some work to implement that. As I've said on the ML, if somebody does the work, I'll review it. But it's one of hundreds of different settings, and it's obviously not worth anybody's time to do this work, as it's largely inconsequential and trivial to configure via the supported config files. Complaining on social media is of course cheap enough that we get plenty of it.


Here the council* provides the bins that they collect on rubbish day. If you want to provide your own bin they'll leave it alone, if you leave the council bin there on rubbish day they'll take the contents away.

Likewise if you make /akirastmp, the OS will leave it alone, but using the directories the OS clearly makes temporary for things that aren't should be the configuration to require manual setup since it's the unusual one.

(* Council's licensed private operators)


> Why not just have the installer _ask_ me what configuration I prefer? Is there some reason you have to force the change, announce a victory, then make me to go mucking with "defaults" after the fact?

It's the Poettering way. And GNOME, for some reason.


It's a recent part of our culture to look down on the "uninitiated" and treat them with extreme infantilizing pity almost bordering on actual bullying. I call it the "temporarily embarrassed future nobel prize winner mindset."

I put it down to the level of monopolization of industry and to a certain extent our culture. These people mean well and they're mostly just reacting to a really baffling labor market in the face of a failed and entirely captured internet revolution.

With the right pair of eyes you can look across the dunes of github into the early 2000s and see where open source culture peaked, crashed, and rolled back.


I had the chance to speak with a GNOME developer about this. Apparently GNOME is trying to be the little old lady desktop that's intuitive for grandma. Which is fine - if it's marketed as that, and not put on the same level as KDE or even tiling WMs, and not trying to influence the entire ecosystem.


My retired mother uses KDE.


Eh I've lost files because I was working in a ramdisked /tmp when the computer lost power. That's what one gets when working in a dir called "tmp".

Some people will see their stuff vanish from /var/tmp and that will be their day of learning. I guess they won't have a backup of files in there either. They were one misfire away from loss anyway.

Sure it feels different when the distro just ran over your misconceptions. On the other hand, when I encounter a stray tmp dir, I assume everything in it can be deleted with negligible consequences. So I tend to rm them without even a glance inside.


Because that increases complexity, and introduces new ways the installer can do something unexpected or fail. There's overhead to code; it has maintenance costs.

If half a dozen people in your town of 10,000 use bins for storing soup, but one year the council procures bins with holes in the bottom to keep rain from collecting in them (making them hard to move, and also providing stagnant water for mosquitoes, ie something that benefits nearly everyone)...

...what would be your opinion of a blitzkrieg of online and media criticism of the council for not considering the needs of soup binners...by people who do not store soup in their bins but are screeching about the needs of the people who do and they say will be affected by the change?

And then someone on the council has said "alright, fine, look...I doubt there's that many of these people. I'll go talk to them, who are they?" and the screechers admit they don't actually know any soup binners, so the councilmember looks them up and goes to the house of every soup binner and either plug the holes in their bin for them, gives them proper soup pots, or prints out a list of soup pots they can find on amazon...or finds out that they say "well gosh I had a soup pot in the attic but I never got around to using it, I'll just switch. Thank you for the heads up that the new bins will have holes in the bottom."


yeah but if that's the case, it's on you not to take the bin out on trash day.


I mean, there was that period of time where amazon and other delivery companies would consider a bin a 'secure' place to put parcels while the recipient was out, even on bin days...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: