[arch-general] change in mount behaviour?

[Heiko Baums]

Am Sat, 28 Jan 2012 11:24:47 +0100
schrieb Tom Gundersen <teg at jklm.no>:

> Maybe I (or others) were unclear in our explanations, but at least you
> should have had a look at the software you are claiming to be buggy
> (you would quickly see that there is no problem).

Again, PulseAudio which Lennart Poettering likes to have as a standard
completely doesn't work with (semi-)professional audio cards with an
ice1712 chip. Yes, I had a look at PulseAudio.

And as I already asked previously, why should I believe that his other
software really works if he's not able to get that one software working.

And, yes, there are incompatibilities in systemd. As far as I read
there are a lot of initscripts which don't work with systemd and
therefore have/had to be rewritten to get them working with systemd.

Where's the bug? In the scripts or in systemd?

> This is what all DEs I'm aware of have been doing for a long time.
> They create mountpoints and mount removable media under /media, which
> is perfectly in line with the FHS.

If they create a subdirectory under /media it's indeed corresponding to
the FHS.

> "Whatever the difference [...] may be", this should give you a hint
> that there is something you are missing...

Then explain it to me. An optical drive is also only mounted
temporarily. I don't see a difference between mounting a harddisk
temporarily or mounting a dvd temporarily.

Maybe you can explain the difference.

> Please stop this nonsense. First of all, the way in which /media is
> (and has been) used has nothing to do with Lennart. Secondly, the FHS
> has not been breached in this instance. Thirdly, anyone who knows
> anything about these matters agree that the FHS is outdated and needs
> to be rewritten (and that until it is, we should not care too much
> about it).

So let everybody invent their own directory scheme, because FHS is so
called outdated so that every Linux distribution and every Unix
derivate is totally incompatible with each other? Right, great idea!

What about first rewriting the FHS first to make it up-to-date again
and only then using this new FHS?

Until then the FHS should be fully respected.

And why doesn't have "anyone who knows anything about these matters"
updated this FHS, yet? Because "anyone who knows anything about these
matters agrees that the FHS is outdated and needs to be rewritten"?

Come on, if this was really true then the FHS would have already been
rewritten by those guys. So this is nonesense. And, btw., I don't see
any point in which the FHS doesn't work anymore.

But maybe you can explain this, too.

> This is a waste of time. The upstream developers are well aware of the
> FHS. If their apps violate it, it is intentional.

Wrong again, it's not intentional, it's buggy.

It was intentional if the FHS would first be rewritten and the upstream
developers would then follow the new FHS.

Heiko