On 14.06.24 10:28, Martin Steigerwald wrote:

Hi,

> I argued that it indeed is a policy change for one thing and secondly *no
> one* is really telling beginner Linux users who use Linux through a
> desktop (environment).

Yes, but then we're in the field of beginner training. I don't have the
feeling that Debian's mission is being explicitly beginner-friendly.
There're lots of other distros focused on that. Maybe we should just
point beginners to them.

Personally, I'm trying to keep myself out of that field, it's just not
my area of expertise. (I do help newbies, if they ask politely, but also
expect them to be willing of learning new / different ways)

> And yes… while back then I could not resist
> laughing over it, I still remember someone in debian-user-german
> complaining that data they moved from $HOME to /tmp or /var/tmp, not sure
> which one it was, but I think as /var/tmp does not usually get cleaned by
> standard in Debian / Devuan, it might have been /tmp, data they moved
> there in order to make space in /home had been gone after the next reboot.

Yes, newbies can do such dumb things. The actual problem here isn't how
the OS works, but those folks having no idea of how it works - and often
unfortunately aren't even interested in learning that. It's an
educational and psychologic problem, not a technical one.

> The desktop file manager did not tell them. Of course I thought back then:
> You should have known. But really, should they?

For those people there should be a customized file manager that issues
a big warning. But who's gonna write/maintain it ? Certainly not me,
since I don't have any incentive to even care about those users (except
somebody inserting lots of coints for that). Maybe I'm just getting old
and lazy, but I've really given up trying to make everybody happy.

> It is implicit policy and as I argued before "/tmp" means temporary but it
> does not detail on who is responsible for the temporary bit.

My interpretation always been: "it can go away anytime - don't put
anything in here that needs to be kept". The very definition of
"temporary" - the opposite of "persistent".

But there's one valid point in criticism here: /tmp is a catch-all for
any kind of things with very different lifetime and purpose. In the long
run we IMHO should split it in various ways, eg. each user should have
it's own one, as well as each service. And applications and services
should provide some machine-readable description of what it might put
in there and which policies to apply.

Or even better: let the supervisor (whatever this might be) just take
control over this and provide various locations (with different
policies) to the application.

That's one of the things I've already sketched for my mobile OS design
study "flyingtux". Since it's entirely based on application containers,
that's an obvious move. For example, there's a /cache directory (private
to the application) with the policy: put anything in here that you wanna
cache, but expect it *might* be cleared on application restart (but
*may* be kept longer), but nothing that can't be rebuilt fully-
automatically (ie. there's no backup and no redundancy)
For /tmp the policy is even harder: it *will* be cleared on application
shutdown/restart (when the container died) and *will* be in /tmpfs - use
this for anything that should semantically behave as a file (eg. has a
path name and you can create fd's on it), but doesn't need any
persistance ever. Could continue this list much longer ...

In short, it's a bit more finer granulated than how android does things.
(it only differenciates between temporary and application data). By the
way, FlyingTux is also capable of cleaning container images while
leaving the application deployed (will be rebuilt on next restart) as
well as moving applications to other hosts or into cold storage.
(the term "mobile" here isn't so much referring to mobile device, like
handhelds, but mobile applications)

> Was it? How was it handled in early UNIX variants? Has it even been there?

I can only speak for early GNU/Linux distros (slakware, LFS, debian,
suse, ...). No idea how early Unix'es have been back then.

>> a) much lower load on disk/ssd (gets written out *only* when necessary)
>>      and no extra write load for metadata (that a disk fs *must* do)

>
> On good SSDs this is so completely irrelevant.

On good ones. As somebody coming from industrial/embedded field, I'd
rather not rely too much on HW resilence.

> And for regular desktop use /tmp traffic it also is not "much lower" IMHO. A
> bit lower yes, but not much lower. Especially with delayed allocation in
> modern Linux filesystems that basically make created and quickly deleted
> files stay in RAM anyway.

Okay, that's indeed not a bad argument. BUT: I wouldn't like to have
delayed write out on my any FS with worthy data. So I'd end up with the
write out traffic (including metadata update) anyways - exactly what I
don't wanna have with stuff that shouldn't survive a powercycle in the
first place. And yes, I actually *want* /tmp to be clean after reboot.

> But I wanted to point out, once more, that for me this discussion is not
> as black and white or as binary as it appears to be.

True. And again, it something where there isn't any ultimately perfect
way for everybody. That's why those things should be clearly
communicated, so people with different needs have time to fix up their
systems. IMHO, Debian folks communicated this early enough, so I don't
see why this is getting such an outrage in certain "social media".

> That said, I do not really care enough about this to make a bigger fuss
> about it than writing down my thoughts here.

Indeed.


--mtx


--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@??? -- +49-151-27565287