Getting rid of /usr for F12?

[Lennart Poettering]

Heya,

there's one topic that keeps popping up in various discussions: can't
we get rid of /usr? The seperation of / and /usr doesn't make much
sense anymore. We could make /usr a symlink to / for an interims phase
and everything would be good for conservative folks who think the FHS
is the holy bible.

In the past more and more stuff has been moved from /usr to /. It's
unlikely that it's going to become less. Also, right now I am aware of
quite a few packages that don't get the seperation of / and /usr right
and rely on stuff from /usr during early bootup.

Let's eliminate this source of errors and clean up our file system
layout a bit. Let's drop /usr for F12!

And for the folks who think /usr is awesome because it allows mounting
/usr ro while mounting / rw: it's not. Much more useful it would be if
/ in its entirety could be mounted ro. Debian allows that. It's not
too hard to make that work on fedora as well.

We wouldn't exactly be the first system without /usr as it seems. Hurd
does that too as I was informed. That makes at least one thing they
got right.

Let the flamefest begin!

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Konstantin Ryabitsev]

On Thu, Apr 16, 2009 at 7:58 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  And for the folks who think /usr is awesome because it allows
> mounting
>  /usr ro while mounting / rw: it's not. Much more useful it would be if
>  / in its entirety could be mounted ro. Debian allows that. It's not
>  too hard to make that work on fedora as well. 
I object on the ground that I routinely make a separate /usr partition
in order to avoid encrypting gigabytes of binaries. My partitioning
scheme usually is:

sda1 -> /boot
sda2 -> /usr
sda3 -> encrypted LVM with everything else

This scheme makes a significant difference for things like starting up
eclipse or OO.org on an underpowered laptop (or, really, any laptop
under battery power). Since portables is where FS encryption most
useful, getting rid of /usr will make it significantly more difficult
for me to conserve power and not waste it on needlessly
encrypting/decrypting binaries.

Regards,
-- 
Konstantin Ryabitsev
Montréal, Québec

[Lennart Poettering]

On Thu, 16.04.09 20:11, Konstantin Ryabitsev (icon(a)fedoraproject.org) wrote:

>  
>  On Thu, Apr 16, 2009 at 7:58 PM, Lennart Poettering
>  <mzerqung(a)0pointer.de&gt; wrote:
>  > And for the folks who think /usr is awesome because it allows mounting
>  > /usr ro while mounting / rw: it's not. Much more useful it would be if
>  > / in its entirety could be mounted ro. Debian allows that. It's not
>  > too hard to make that work on fedora as well.
>  
>  I object on the ground that I routinely make a separate /usr partition
>  in order to avoid encrypting gigabytes of binaries. My partitioning
>  scheme usually is:
>  
>  sda1 -> /boot
>  sda2 -> /usr
>  sda3 -> encrypted LVM with everything else
>  
>  This scheme makes a significant difference for things like starting up
>  eclipse or OO.org on an underpowered laptop (or, really, any laptop
>  under battery power). Since portables is where FS encryption most
>  useful, getting rid of /usr will make it significantly more difficult
>  for me to conserve power and not waste it on needlessly
>  encrypting/decrypting binaries. 
It would make more sense to make /home an encrypted partition and
leave / unencrypted.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Konstantin Ryabitsev]

On Thu, Apr 16, 2009 at 8:25 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
> > This scheme makes a significant difference for things like
> starting up
> > eclipse or OO.org on an underpowered laptop (or, really, any laptop
> > under battery power). Since portables is where FS encryption most
> > useful, getting rid of /usr will make it significantly more difficult
> > for me to conserve power and not waste it on needlessly
> > encrypting/decrypting binaries.
>
>  It would make more sense to make /home an encrypted partition and
>  leave / unencrypted. 
Not really -- I want to also encrypt stuff in /etc, /tmp and in /var
(configs, temp files, and app state data).

-- 
Konstantin Ryabitsev
Montréal, Québec

[Lennart Poettering]

On Thu, 16.04.09 20:34, Konstantin Ryabitsev (icon(a)fedoraproject.org) wrote:

>  
>  On Thu, Apr 16, 2009 at 8:25 PM, Lennart Poettering
>  <mzerqung(a)0pointer.de&gt; wrote:
>  >> This scheme makes a significant difference for things like starting up
>  >> eclipse or OO.org on an underpowered laptop (or, really, any laptop
>  >> under battery power). Since portables is where FS encryption most
>  >> useful, getting rid of /usr will make it significantly more difficult
>  >> for me to conserve power and not waste it on needlessly
>  >> encrypting/decrypting binaries.
>  >
>  > It would make more sense to make /home an encrypted partition and
>  > leave / unencrypted.
>  
>  Not really -- I want to also encrypt stuff in /etc, /tmp and in /var
>  (configs, temp files, and app state data). 
Not sure if that makes too much sense.

Either you are paranoid or you are not. Which means either you encrypt
everything. Or you encrypt only /home. Anything in between makes not
much sense. 

Also, while you might not directly notice this, but you silently lose
a lot of functionality by doing this. Quite a few udev rules require
stuff from /usr. If /usr is not available then they will be skipped.

Believe me: having /usr seperate is currently broken on Fedora. How do
I know? I used to run such a setup myself. And instead of trying to
fix that brokeness by moving more and more stuff to / let's just get
rid of this mess completely.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Konstantin Ryabitsev]

On Thu, Apr 16, 2009 at 8:56 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
> > Not really -- I want to also encrypt stuff in /etc, /tmp and in
> /var
> > (configs, temp files, and app state data).
>
>  Not sure if that makes too much sense.
>
>  Either you are paranoid or you are not. Which means either you encrypt
>  everything. Or you encrypt only /home. Anything in between makes not
>  much sense. 
That's not really a good argument -- in fact, it's not an argument at
all. There is absolutely nothing worth encrypting in /usr, while the
rest of the system may contain sensitive data. It has nothing to do
with being "paranoid" -- it's a very sensible trade-off between disk
encryption and performance + battery life, and it makes very good
sense -- I'd like to see a compelling argument for encrypting /usr
(apart from the danger of trojaning, which you're still running as
long as you boot from a /boot partition and not a trusted source, like
a keyfob that you never part with). Perhaps, if you are worried that
someone will come after you for installing proprietary codecs or
pirated software, but that's not something I'm concerned about.

>  Also, while you might not directly notice this, but you silently
> lose
>  a lot of functionality by doing this. Quite a few udev rules require
>  stuff from /usr. If /usr is not available then they will be skipped. 
How does my partitioning scheme make /usr unavailable at any point?
It's an unencrypted partition on sda2 -- considering that the rest is
a LUKS-encrypted LVM volume, the probability of something else failing
before ext3 on sda2 becomes unavailable is orders of magnitude higher.

>  Believe me: having /usr seperate is currently broken on Fedora. How
> do
>  I know? I used to run such a setup myself. And instead of trying to
>  fix that brokeness by moving more and more stuff to / let's just get
>  rid of this mess completely. 
You wanted a reason not to? I gave a reason not to. If we decide that
the benefits of doing away with /usr outweigh drawbacks, then I will
find a way to live with it. I simply wanted to point out that being
able to mount the majority of system binaries on a separate partition
from the rest of the system has a tangible benefit.

Regards,
-- 
Konstantin Ryabitsev
Montréal, Québec

[Caius Carlos CHANCE]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lennart Poettering さんは書きました:
>  Heya,
>  Let's eliminate this source of errors and clean up our file system
>  layout a bit. Let's drop /usr for F12! 
Would this help saving the '--prefix=/usr' ?

- --
Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com
JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iEYEARECAAYFAknnyvsACgkQmo+B7bGj5dIHYgCgoZ6wvTw5YF3G2t3T3ZdjxIFC
> T5IAn3QD6hZ72HL/KHvfF/TodNnPWPtM
> =wrml
> -----END PGP SIGNATURE-----

[Lennart Poettering]

On Fri, 17.04.09 10:19, Caius 'kaio' Chance (cchance(a)redhat.com) wrote:

>  
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  Lennart Poettering さんは書きました:
>  > Heya,
>  > Let's eliminate this source of errors and clean up our file system
>  > layout a bit. Let's drop /usr for F12!
>  
>  Would this help saving the '--prefix=/usr' ? 
Uh?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Patrick W. Barnes]

On Thursday 16 April 2009 19:19:08 Caius 'kaio' Chance wrote:
>  Would this help saving the '--prefix=/usr' ?
>  
Whatever you are doing on a Fedora system that includes "--prefix=/usr", you 
are almost certainly doing it wrong.

-- 
Patrick "The N-Man" Barnes
nman64(a)n-man.com

http://n-man.com/

LinkedIn:
http://linkedin.com/in/nman64

Have I been helpful?  Rate my assistance!
http://rate.affero.net/nman64/

All messages cryptographically signed:
http://en.wikipedia.org/wiki/OpenPGP
--

[Kevin Kofler]

Caius 'kaio' Chance wrote:
>  Would this help saving the '--prefix=/usr' ? 
No, as the default is /usr/local, not /.

        Kevin Kofler

[Toshio Kuratomi]

Lennart Poettering wrote:

>  
>  Let the flamefest begin!
>   
I'm hereby giving notice that I don't have time to read obvious
flamefests anymore.  Once this thread concludes, please summarise
whatever the pros and cons are and send it to the packaging committee to
discuss and vote on.

If you want to get this changed locally in Fedora, as opposed to getting
the FHS changed, I'm going to want to see a lot more Pros than you have
so far before voting for the change.

-Toshio

[Adam Williamson]

On Fri, 2009-04-17 at 01:58 +0200, Lennart Poettering wrote:
>  Heya,
>  
>  there's one topic that keeps popping up in various discussions: can't
>  we get rid of /usr? 
What are these discussions? What's the win exactly? This would no doubt
involve quite a lot of work and cause niggling problems here and there:
what are we winning to offset that loss?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Adam Miller]

I would like to keep /usr because I use /usr/local/ for backups and other
random things... really don't see a reason to nuke it anyways.

-Adam
(From my G1)

On Apr 16, 2009 8:14 PM, "Adam Williamson" <awilliam(a)redhat.com&gt; wrote:

On Fri, 2009-04-17 at 01:58 +0200, Lennart Poettering wrote: > Heya, > >
there's one topic that kee...
What are these discussions? What's the win exactly? This would no doubt
involve quite a lot of work and cause niggling problems here and there:
what are we winning to offset that loss?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- fedora-devel-list mailing list fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/list...

[Juha Tuomala]

On Friday 17 April 2009 07:25:41 Adam Miller wrote:
>  I would like to keep /usr because I use /usr/local/ for backups and
> other
>  random things... really don't see a reason to nuke it anyways. 
Btw, why the local is mounted under /usr anyway? Why not directly
to /local ?

Tuju

-- 
Varo hattupäisiä autoilijoita.

[Lennart Poettering]

On Thu, 16.04.09 23:25, Adam Miller (maxamillion(a)gmail.com) wrote:

>  I would like to keep /usr because I use /usr/local/ for backups and
> other
>  random things... really don't see a reason to nuke it anyways. 
I don't think sticking backups into /usr/local is the right place for
them. But that doesn't even matter given that /usr/local would of
course become /local.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Ralf Corsepius]

Lennart Poettering wrote:
>  Heya,
>  
>  there's one topic that keeps popping up in various discussions: can't
>  we get rid of /usr? The seperation of / and /usr doesn't make much
>  sense anymore. 
This is a very short-sighed view.

>  We could make /usr a symlink to / for an interims phase
>  and everything would be good for conservative folks who think the FHS
>  is the holy bible. 
Religiousity isn't the point - The point is: There are
reasons for why 
the FHS rsp. the GNU standards are setup the way they are.

>  In the past more and more stuff has been moved from /usr to /.
Not quite: Actually, only very few files have been moved from /usr
to /. The overwhelming majority resides in /usr.

>  Let's eliminate this source of errors and clean up our file
> system
>  layout a bit. Let's drop /usr for F12! 
Well, I guess,  I don't have
pronounce what I think about this proposal.

>  And for the folks who think /usr is awesome because it allows
> mounting
>  /usr ro while mounting / rw: it's not.
>  Much more useful it would be if
>  / in its entirety could be mounted ro. Debian allows that. It's not
>  too hard to make that work on fedora as well. 
You are oversimplifying.

Mounting / ro: will never work (/var, /tmp, /etc etc.) , while mounting 
/usr ro: should be pretty simply.

Actually, anything, which prevents mounting /usr ro: qualifies as plain 
and simple "system integration bug".

>  We wouldn't exactly be the first system without /usr as it seems.
>  
Yes, Windows never had it and other crippled *nix variants who aimed at 
imitating Windows IIRC, have tried to avoid it also.

[Lennart Poettering]

On Fri, 17.04.09 06:48, Ralf Corsepius (rc040203(a)freenet.de) wrote:

>  Lennart Poettering wrote:
> > Heya,
> >
> > there's one topic that keeps popping up in various discussions: can't
> > we get rid of /usr? The seperation of / and /usr doesn't make much
> > sense anymore.
>
>  This is a very short-sighed view. 
Oh, is it?

> > We could make /usr a symlink to / for an interims phase
> > and everything would be good for conservative folks who think the FHS
> > is the holy bible.
>
>  Religiousity isn't the point - The point is: There are reasons for why  
>  the FHS rsp. the GNU standards are setup the way they are. 
First of all FHS is not a "GNU standard". 

Secondly, it is of course very convincing if you just nebulously say
'there are rasons' instead of mentioning any.

> > And for the folks who think /usr is awesome because it allows
> mounting
> > /usr ro while mounting / rw: it's not.
> > Much more useful it would be if
> > / in its entirety could be mounted ro. Debian allows that. It's not
> > too hard to make that work on fedora as well.
>  You are oversimplifying.
>
>  Mounting / ro: will never work (/var, /tmp, /etc etc.) , while mounting  
>  /usr ro: should be pretty simply. 
On Debian /etc doesn't need to be rw. And it wouldn't be too difficult
to allow the same on Fedora.

/tmp and /var should of course be mounted writable.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Ralf Corsepius]

Lennart Poettering wrote:
>  On Fri, 17.04.09 06:48, Ralf Corsepius (rc040203(a)freenet.de) wrote:
>  
> > Lennart Poettering wrote:
> >> Heya,
> >>
> >> there's one topic that keeps popping up in various discussions: can't
> >> we get rid of /usr? The seperation of / and /usr doesn't make much
> >> sense anymore.
> > This is a very short-sighed view.
>  
>  Oh, is it? 
Yes.

[Note that this had been the "polite version" of what I actually think 
about your proposal.]

> >> We could make /usr a symlink to / for an interims phase
> >> and everything would be good for conservative folks who think the FHS
> >> is the holy bible.
> > Religiousity isn't the point - The point is: There are reasons for why  
> > the FHS rsp. the GNU standards are setup the way they are.
>  
>  First of all FHS is not a "GNU standard".  
"The GNU standards"
is a standard of its own, predating the FHS.

>  Secondly, it is of course very convincing if you just nebulously say
>  'there are rasons' instead of mentioning any. 
Number #1 reason: /usr is
ment to contains non-essential packages, only, 
and thus is allowed not to be present during certain stages of booting.

> >> And for the folks who think /usr is awesome because it allows
> mounting
> >> /usr ro while mounting / rw: it's not.
> >> Much more useful it would be if
> >> / in its entirety could be mounted ro. Debian allows that. It's not
> >> too hard to make that work on fedora as well.
> > You are oversimplifying.
> >
> > Mounting / ro: will never work (/var, /tmp, /etc etc.) , while mounting  
> > /usr ro: should be pretty simply.
>  
>  On Debian /etc doesn't need to be rw. And it wouldn't be too difficult
>  to allow the same on Fedora. 
In theory, yes. However /etc still needs to be
mountable rw: (To set up 
the system), while /bin, /sbin/, /lib, /usr ... in theory can even not 
be mountable "rw:" (Consider ROMs, CDROMs, etc.)

Ralf

[drago01]

On Fri, Apr 17, 2009 at 3:34 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  On Fri, 17.04.09 06:48, Ralf Corsepius (rc040203(a)freenet.de) wrote:
>
> >
> > Lennart Poettering wrote: 
>  /tmp and /var should of course be mounted writable. 
/tmp and /var/tmp should be tmpfs by default but that's a different topic.

Regarding to getting rid of /usr .. what are the problems that this is
going to solve?

[Andrew Haley]

Lennart Poettering wrote:
>  On Fri, 17.04.09 06:48, Ralf Corsepius (rc040203(a)freenet.de) wrote:
>  
> > Lennart Poettering wrote:
> >> Heya,
> >>
> >> there's one topic that keeps popping up in various discussions: can't
> >> we get rid of /usr? The seperation of / and /usr doesn't make much
> >> sense anymore.
> > This is a very short-sighed view.
>  
>  Oh, is it?
>  
> >> We could make /usr a symlink to / for an interims phase
> >> and everything would be good for conservative folks who think the FHS
> >> is the holy bible.
> > Religiousity isn't the point - The point is: There are reasons for why  
> > the FHS rsp. the GNU standards are setup the way they are.
>  
>  First of all FHS is not a "GNU standard". 
>  
>  Secondly, it is of course very convincing if you just nebulously say
>  'there are rasons' instead of mentioning any. 
Well, sometimes the fact that something *is* standard is far more important
than what the standard is.  And /usr has been around for a very long time,
and lots of software (an people, for that matter) know that it's there.
Much of the GNU configured software by default installs in /usr/local.
There has to be a very high bar for changing common practice.

Andrew.

[Nathanael D. Noblet]

Andrew Haley wrote:

>  Well, sometimes the fact that something *is* standard is far more
> important
>  than what the standard is.  And /usr has been around for a very long time,
>  and lots of software (an people, for that matter) know that it's there.
>  Much of the GNU configured software by default installs in /usr/local.
>  There has to be a very high bar for changing common practice. 
Yeah, I agree. I mean I haven't really seen any *solid* reason for 
removing /usr. What does it improve? What situation does it fix? It 
doesn't save a massive amount of space, it doesn't increase performance, 
it doesn't resolve any long standing bug I can see. A change like that 
for so little gain will find it hard to gain traction I think.

-- 
Nathanael d. Noblet
T: 403.875.4613

[Orcan Ogetbil]

On Fri, Apr 17, 2009 at 1:48 PM, Nathanael D. Noblet wrote:
>  Andrew Haley wrote:
>
> > Well, sometimes the fact that something *is* standard is far more
> > important
> > than what the standard is.  And /usr has been around for a very long time,
> > and lots of software (an people, for that matter) know that it's there.
> > Much of the GNU configured software by default installs in /usr/local.
> > There has to be a very high bar for changing common practice.
>
>  Yeah, I agree. I mean I haven't really seen any *solid* reason for removing
>  /usr. What does it improve? What situation does it fix? It doesn't save a
>  massive amount of space, it doesn't increase performance, it doesn't resolve
>  any long standing bug I can see. A change like that for so little gain will
>  find it hard to gain traction I think.
>  
Not that I support or not support dropping /usr, but let's do this
quick calculation:

Every day I spend 3 seconds in average to type /usr. I am pretty sure
that it is safe to assume that there are at least 100000 people like
me in the world. This makes 300000 seconds to type /usr every day in
the world. 300000 seconds is not easy to ignore, and can be used for
more useful and productive things, like replying to this topic. :p

Cheers,
Orcan

[Nathanael D. Noblet]

Orcan Ogetbil wrote:
>  On Fri, Apr 17, 2009 at 1:48 PM, Nathanael D. Noblet wrote:
> > Andrew Haley wrote:
> >
> >> Well, sometimes the fact that something *is* standard is far more
> >> important
> >> than what the standard is.  And /usr has been around for a very long time,
> >> and lots of software (an people, for that matter) know that it's there.
> >> Much of the GNU configured software by default installs in /usr/local.
> >> There has to be a very high bar for changing common practice.
> > Yeah, I agree. I mean I haven't really seen any *solid* reason for removing
> > /usr. What does it improve? What situation does it fix? It doesn't save a
> > massive amount of space, it doesn't increase performance, it doesn't resolve
> > any long standing bug I can see. A change like that for so little gain will
> > find it hard to gain traction I think.
> >
>  
>  Not that I support or not support dropping /usr, but let's do this
>  quick calculation:
>  
>  Every day I spend 3 seconds in average to type /usr. I am pretty sure
>  that it is safe to assume that there are at least 100000 people like
>  me in the world. This makes 300000 seconds to type /usr every day in
>  the world. 300000 seconds is not easy to ignore, and can be used for
>  more useful and productive things, like replying to this topic. :p 
why do you type /usr ? if you are going after a command its in the path 
already, so then maybe /usr/{share,doc,,,?} in which case use man X, or 
spend time improving and consolidating documentation readers for the 
case of /usr/share/doc/program-ver/random... in any case you still have 
to type /share/doc/program-.... or use tab completion. I don't see how 
removing /usr helps solve anything... if you are worried about the 3 
seconds, create a bunch of symlinks. Saves you time, doesn't break 
anything, uses next to no more space...?

I still don't see a *solid* reason to remove /usr. At least solid enough 
to justify the amount of work necessary to port all the packages over to 
new locations *particularly* when you'd probably want to have other 
distros on board as well. Its hard enough to find where something is in 
another distro because of minor naming stuff... Nevermind not following 
a common standard


-- 
Nathanael d. Noblet
T: 403.875.4613

[Adam Williamson]

On Fri, 2009-04-17 at 15:15 -0400, Orcan Ogetbil wrote:

>  Not that I support or not support dropping /usr, but let's do
> this
>  quick calculation:
>  
>  Every day I spend 3 seconds in average to type /usr. I am pretty sure
>  that it is safe to assume that there are at least 100000 people like
>  me in the world. This makes 300000 seconds to type /usr every day in
>  the world. 300000 seconds is not easy to ignore, and can be used for
>  more useful and productive things, like replying to this topic. :p 
You're forgetting to factor in the amount of time people spend doing
"/usr...d'oh...backspace backspace backspace backspace" after the
change ;)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Kevin Kofler]

Adam Williamson wrote:
>  You're forgetting to factor in the amount of time people spend
> doing
>  "/usr...d'oh...backspace backspace backspace backspace" after the
>  change ;) 
Not if /usr is symlinked (or bind-mounted or whatever) to /. Those
environments already not using /usr (HURD, MSYS etc.) all do something like
that. It has to be done for compatibility with existing software anyway.

(That said, I don't see a compelling case for doing that kind of hackery,
there's nothing wrong with having /usr being separate.)

        Kevin Kofler

[Ric Wheeler]

Andrew Haley wrote:
>  Lennart Poettering wrote:
> > On Fri, 17.04.09 06:48, Ralf Corsepius (rc040203(a)freenet.de) wrote:
> >
> >> Lennart Poettering wrote:
> >>> Heya,
> >>>
> >>> there's one topic that keeps popping up in various discussions:
> can't
> >>> we get rid of /usr? The seperation of / and /usr doesn't make much
> >>> sense anymore.
> >> This is a very short-sighed view.
> > Oh, is it?
> >
> >>> We could make /usr a symlink to / for an interims phase
> >>> and everything would be good for conservative folks who think the FHS
> >>> is the holy bible.
> >> Religiousity isn't the point - The point is: There are reasons for why  
> >> the FHS rsp. the GNU standards are setup the way they are.
> > First of all FHS is not a "GNU standard". 
> >
> > Secondly, it is of course very convincing if you just nebulously say
> > 'there are rasons' instead of mentioning any.
>  
>  Well, sometimes the fact that something *is* standard is far more important
>  than what the standard is.  And /usr has been around for a very long time,
>  and lots of software (an people, for that matter) know that it's there.
>  Much of the GNU configured software by default installs in /usr/local.
>  There has to be a very high bar for changing common practice.
>  
>  Andrew.
>   
I can't help chiming in here - as a sys admin back at Brandeis in the early 
eighties, I had a professor with root privileges try to "fix" the spelling of 
"usr" for us on the department Vax running BSD.

Needless to say, not much worked when I got in the next morning to find my 
"/usr" had been renamed "/user".

Not sure how much would break today, but at relative dawn of UNIX time, it was 
painful :-) (And I revoked he lost root access, tenure or not)

ric

[Kevin Kofler]

Lennart Poettering wrote:
>  On Debian /etc doesn't need to be rw. And it wouldn't be too
> difficult
>  to allow the same on Fedora. 
Mounting /etc read-only makes no sense at all, config files are designed to
be writable.

Relatedly, files which are not intended to be reconfigured by the system
administrator belong into /usr/share, not /etc. Unfortunately, quite some
software gets this wrong (basically, any file in /etc not marked %config is
a sign that something is abusing /etc).

        Kevin Kofler

[Lennart Poettering]

On Sat, 18.04.09 01:02, Kevin Kofler (kevin.kofler(a)chello.at) wrote:

>  
>  Lennart Poettering wrote:
>  > On Debian /etc doesn't need to be rw. And it wouldn't be too difficult
>  > to allow the same on Fedora.
>  
>  Mounting /etc read-only makes no sense at all, config files are designed to
>  be writable. 
Oh, it makes a lot of sense. I mean, most config files are only
touched during installation and during package upgrades. Otherwise
they are practically read-only. During package upgrades or if the
admin really wants to change something he can temporarily remount / to
rw without a problem. This is eprfectly well supported by Debian.

Now, the only stumbling block for this is that some files (like
/etc/resolv.conf) are rewritten from time to time. But that's a bad
bad misdesign anyway and we should really get rid of
/etc/resolv.conf. In the meantime one can do what Debian did and make
resolv.conf a symlink to a writable location.

>  Relatedly, files which are not intended to be reconfigured by the
> system
>  administrator belong into /usr/share, not /etc. Unfortunately, quite some
>  software gets this wrong (basically, any file in /etc not marked %config is
>  a sign that something is abusing /etc). 
You are going to have fun with that. Succeeding with moving stuff like
/etc/services to /usr/share is even more unlikely than pushing the
removal of /usr through in Fedora.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Jef Spaleta]

On Fri, Apr 17, 2009 at 3:11 PM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  Oh, it makes a lot of sense. I mean, most config files are only
>  touched during installation and during package upgrades. Otherwise
>  they are practically read-only. During package upgrades or if the
>  admin really wants to change something he can temporarily remount / to
>  rw without a problem. This is eprfectly well supported by Debian. 
Hmm I guess we need to redesign how denyhosts works as a service as
its default operation is to edit /etc/hosts.deny..quite frequently.

Should I file a bug report now?
-jef

[Lennart Poettering]

On Fri, 17.04.09 15:16, Jeff Spaleta (jspaleta(a)gmail.com) wrote:

>  
>  On Fri, Apr 17, 2009 at 3:11 PM, Lennart Poettering
>  <mzerqung(a)0pointer.de&gt; wrote:
>  > Oh, it makes a lot of sense. I mean, most config files are only
>  > touched during installation and during package upgrades. Otherwise
>  > they are practically read-only. During package upgrades or if the
>  > admin really wants to change something he can temporarily remount / to
>  > rw without a problem. This is eprfectly well supported by Debian.
>  
>  Hmm I guess we need to redesign how denyhosts works as a service as
>  its default operation is to edit /etc/hosts.deny..quite frequently.
>  
>  Should I file a bug report now? 
I am not aware that it was an official Fedora goal to make it boot
from a ro /. Would be good if it was, though.

However, no daemon should ever touch files in /etc automatically. That
NM does that is pretty bad style. Instead resolv.conf should be
replaced by a symlink to /var and manipulated there.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Chris Adams]

Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  However, no daemon should ever touch files in /etc automatically.
> That
>  NM does that is pretty bad style. Instead resolv.conf should be
>  replaced by a symlink to /var and manipulated there. 
/etc is by standard for system configuration files.  It is unreasonable
to expect everything that needs to update system configuration to have
to know to remount read-write / (or /etc or whatever).  Making a bunch
of symlinks just to repoint configuration files out of the configuration
directory would be stupid.
-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Lennart Poettering]

On Fri, 17.04.09 18:38, Chris Adams (cmadams(a)hiwaay.net) wrote:

>  
>  Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  > However, no daemon should ever touch files in /etc automatically. That
>  > NM does that is pretty bad style. Instead resolv.conf should be
>  > replaced by a symlink to /var and manipulated there.
>  
>  /etc is by standard for system configuration files.  It is unreasonable
>  to expect everything that needs to update system configuration to have
>  to know to remount read-write / (or /etc or whatever).  Making a bunch
>  of symlinks just to repoint configuration files out of the configuration
>  directory would be stupid. 
You are overerstimating how much software actually touches /etc.

And what you call 'stupid' is pretty common sense everywhere except on
Fedora as it seems.

You can do it on OpenSUSE:

http://en.opensuse.org/How-To_Make_the_root_filesystem_read-only

You can do it on Debian:

http://wiki.debian.org/ReadonlyRoot

You can do it on Gentoo:

http://www.gentoo-wiki.info/HOWTO_Read-only_root_filesystem

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Zack Cerza]

On Sat, 2009-04-18 at 01:48 +0200, Lennart Poettering wrote:
>  On Fri, 17.04.09 18:38, Chris Adams (cmadams(a)hiwaay.net) wrote:
>  
>  > 
>  > Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  > > However, no daemon should ever touch files in /etc automatically. That
>  > > NM does that is pretty bad style. Instead resolv.conf should be
>  > > replaced by a symlink to /var and manipulated there.
>  > 
>  > /etc is by standard for system configuration files.  It is unreasonable
>  > to expect everything that needs to update system configuration to have
>  > to know to remount read-write / (or /etc or whatever).  Making a bunch
>  > of symlinks just to repoint configuration files out of the configuration
>  > directory would be stupid.
>  
>  You are overerstimating how much software actually touches /etc.
>  
>  And what you call 'stupid' is pretty common sense everywhere except on
>  Fedora as it seems.
>  
>  You can do it on OpenSUSE:
>  
>  http://en.opensuse.org/How-To_Make_the_root_filesystem_read-only 
Above page contains lots of manual steps, like the following:

* move /etc/resolv.conf to /dev/shm/resolv.conf
# mv /etc/resolv.conf /dev/shm
* link /dev/shm/resolv.conf to /etc/resolv.conf
# ln -s /dev/shm/resolv.conf /etc/resolv.conf

So, if that's how "you can do it on OpenSUSE", I bet you could do it
similarly on Fedora today. If the OpenSUSE way is good enough for you,
then perhaps you could just write up a doc similar to theirs for Fedora.

That said, I don't personally care if /usr continues to exist. I also
didn't check the two links below.

>  You can do it on Debian:
>  
>  http://wiki.debian.org/ReadonlyRoot
>  
>  You can do it on Gentoo:
>  
>  http://www.gentoo-wiki.info/HOWTO_Read-only_root_filesystem
>  
>  Lennart
>  
>  -- 
>  Lennart Poettering                        Red Hat, Inc.
>  lennart [at] poettering [dot] net         ICQ# 11060553
>  http://0pointer.net/lennart/           GnuPG 0x1A015CC4
>

[Callum Lerwick]

On Sat, 2009-04-18 at 01:28 +0200, Lennart Poettering wrote:
>  On Fri, 17.04.09 15:16, Jeff Spaleta (jspaleta(a)gmail.com) wrote:
>  
>  > 
>  > On Fri, Apr 17, 2009 at 3:11 PM, Lennart Poettering
>  > <mzerqung(a)0pointer.de&gt; wrote:
>  > > Oh, it makes a lot of sense. I mean, most config files are only
>  > > touched during installation and during package upgrades. Otherwise
>  > > they are practically read-only. During package upgrades or if the
>  > > admin really wants to change something he can temporarily remount / to
>  > > rw without a problem. This is eprfectly well supported by Debian.
>  > 
>  > Hmm I guess we need to redesign how denyhosts works as a service as
>  > its default operation is to edit /etc/hosts.deny..quite frequently.
>  > 
>  > Should I file a bug report now?
>  
>  I am not aware that it was an official Fedora goal to make it boot
>  from a ro /. Would be good if it was, though. 
Think about LiveCDs. No writes are going to be permanent, so why bother
writing at all?

Think about the proliferation of solid state storage. We can no longer
take for granted that writes are free, with flash storage writes come
with a cost. Read only root would guarantee preservation of operating
lifetime.

Read only also makes filesystem corruption much less likely.

Read only also allows the possibility of mastering a "perfect"
filesystem. No fragmentation, and you can compress it to hell and back.

Read only, if it's ensured in hardware, ensures security. Cleanup only
takes a reboot.

Is it weird of me to pine for the the days of floppy disks? Things were
so much easier then. Just put in the disk you want and go. I've got a
whole long blog post about this I should write some day. I'd like to see
a clear, hard line separation between the operating system, and user
data. The operating system should be self-contained, and uniform. The OS
should be able to be easily replaced, upgraded or downgraded, free of
state to muck things up. Hence, write only root. Once mastered, it stays
the same.

Remember write protect tabs?

>  However, no daemon should ever touch files in /etc automatically.
> That
>  NM does that is pretty bad style. Instead resolv.conf should be
>  replaced by a symlink to /var and manipulated there. 
In my wireless firmware:

http://www.haxxed.com/belkin/

resolve.conf is hardwired to localhost and dnsmasq is used for all DNS
configuration.

# ls -l /etc/
lrwxrwxrwx    1 0        0              11 shadow -> /tmp/shadow
-rw-r--r--    1 0        0              21 resolv.conf
-rw-r--r--    1 0        0             458 radvd.split.conf
-rw-r--r--    1 0        0             228 radvd.conf
-rw-r--r--    1 0        0              23 profile
-rw-r--r--    1 0        0              84 passwd
drwxrwxr-x    1 0        0              76 init.d
lrwxrwxrwx    1 0        0              10 hosts -> /tmp/hosts
-rw-------    1 0        0               0 gshadow
-rw-r--r--    1 0        0              30 group
lrwxrwxrwx    1 0        0              11 ethers -> /tmp/ethers
lrwxrwxrwx    1 0        0              13 dropbear -> /tmp/dropbear

# cat /etc/resolv.conf 
nameserver 127.0.0.1

Though various other things have to be redirected to /tmp, a ramfs
populated on boot by the init scripts from nvram settings. 2mb flash
just doesn't provide enough space for JFFS2.


dnsmasq ftw

[Chris Adams]

Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; said:
>  Mounting /etc read-only makes no sense at all, config files are
> designed to
>  be writable. 
Now, if initrd could handle /etc being on a separate filesystem, that
would be cool.  I might would leave /usr on / (mounted ro) if that were
the case (although that wouldn't help with the case I recently had where
/usr was corrupted but I still booted "emergency" mode to restore from
tape).

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Lennart Poettering]

On Fri, 17.04.09 18:16, Chris Adams (cmadams(a)hiwaay.net) wrote:

>  
>  Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; said:
>  > Mounting /etc read-only makes no sense at all, config files are designed to
>  > be writable.
>  
>  Now, if initrd could handle /etc being on a separate filesystem, that
>  would be cool.  I might would leave /usr on / (mounted ro) if that were
>  the case (although that wouldn't help with the case I recently had where
>  /usr was corrupted but I still booted "emergency" mode to restore from
>  tape). 
It doesn't make sense to have /etc/ a seperate parition from /.

A sensible design would be to have / as a whole should be ro. And then
/home, /var, /tmp mounted rw.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Jeffrey A Law]

Lennart Poettering wrote:
>  On Fri, 17.04.09 18:16, Chris Adams (cmadams(a)hiwaay.net) wrote:
>
>    
> > Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; said:
> >     
> >> Mounting /etc read-only makes no sense at all, config files are designed to
> >> be writable.
> >>       
> > Now, if initrd could handle /etc being on a separate filesystem, that
> > would be cool.  I might would leave /usr on / (mounted ro) if that were
> > the case (although that wouldn't help with the case I recently had where
> > /usr was corrupted but I still booted "emergency" mode to restore from
> > tape).
> >     
>
>  It doesn't make sense to have /etc/ a seperate parition from /.
>
>  A sensible design would be to have / as a whole should be ro. And then
>  /home, /var, /tmp mounted rw.
>     
Then you need to deal with the variety of utilities that want to 
scribble in /etc.   I've successfully run systems where root was 
readonly and /etc was r/w via a union fs (/var, /tmp, /home were 
obviously different r/w filesystems).

jeff

[Ralf Corsepius]

Lennart Poettering wrote:
>  On Fri, 17.04.09 18:16, Chris Adams (cmadams(a)hiwaay.net) wrote:
>  
> > Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at&gt; said:
> >> Mounting /etc read-only makes no sense at all, config files are designed to
> >> be writable.
> > Now, if initrd could handle /etc being on a separate filesystem, that
> > would be cool.  I might would leave /usr on / (mounted ro) if that were
> > the case (although that wouldn't help with the case I recently had where
> > /usr was corrupted but I still booted "emergency" mode to restore from
> > tape).
>  
>  It doesn't make sense to have /etc/ a seperate parition from /. 
It does. Files below /etc carry machine-dependent configuration info.

=> Sharing /etc between several machines will only work if all machines 
are very similar (almost identical).

Ralf

[Pete Zaitcev]

On Fri, 17 Apr 2009 01:58:06 +0200, Lennart Poettering <mzerqung(a)0pointer.de&gt;
wrote:

>  Let's eliminate this source of errors and clean up our file
> system
>  layout a bit. Let's drop /usr for F12! 
A poorly specified "cleanup" is not a good reason to introduce
a change so radical, with disadvantages so severe.

>  And for the folks who think /usr is awesome because it allows
> mounting
>  /usr ro while mounting / rw: it's not. 
That's purely your opinion, presented without any arguments.

-- Pete

[Jan Zelený]

Hi,
>  The seperation of / and /usr doesn't make much
>  sense anymore. 
I don't think that's true. How about one /usr ro mounted via network to 
several machines?

--
Jan

[Hans de Goede]

On 04/17/2009 09:08 AM, Jan Zelený wrote:
>  Hi,
> > The seperation of / and /usr doesn't make much
> > sense anymore.
>
>  I don't think that's true. How about one /usr ro mounted via network to
>  several machines?
>  
This has not worked for the last X Fedora releases, due to us using Network
Manager to bring up the Network, and NM living in /usr, see my other reply in
this thread.

Regards,

Hans

[Chuck Anderson]

On Fri, Apr 17, 2009 at 10:20:29AM +0200, Hans de Goede wrote:
>  On 04/17/2009 09:08 AM, Jan Zelený wrote:
> > Hi,
> >> The seperation of / and /usr doesn't make much
> >> sense anymore.
> >
> > I don't think that's true. How about one /usr ro mounted via network to
> > several machines?
> >
>
>  This has not worked for the last X Fedora releases, due to us using Network
>  Manager to bring up the Network, and NM living in /usr, see my other reply in
>  this thread. 
Except that it makes little sense to use NetworkManager on a system 
that mounts NFS /usr.  You can still use the old network script.

[Rudolf Kastl]

2009/4/17 Hans de Goede <j.w.r.degoede(a)hhs.nl&gt;:
>  On 04/17/2009 09:08 AM, Jan Zelenı wrote:
> >
> > Hi,
> >>
> >> The seperation of / and /usr doesn't make much
> >> sense anymore.
> >
> > I don't think that's true. How about one /usr ro mounted via network to
> > several machines?
> >
>
>  This has not worked for the last X Fedora releases, due to us using Network
>  Manager to bring up the Network, and NM living in /usr, see my other reply
>  in
>  this thread. 
Well network still works without nm... even in todays rawhide. Alot of
stuff doesent work with only the default setup. ;)

kind regards,
Rudolf Kastl

>  Regards,
>
>  Hans
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Pete Zaitcev]

On Fri, 17 Apr 2009 10:20:29 +0200, Hans de Goede <j.w.r.degoede(a)hhs.nl&gt; wrote:
>  On 04/17/2009 09:08 AM, Jan Zelený wrote: 
>  >> The seperation of / and /usr doesn't make much sense
> anymore.
>  >
>  > I don't think that's true. How about one /usr ro mounted via network to
>  > several machines?
>  
>  This has not worked for the last X Fedora releases, due to us using Network
>  Manager to bring up the Network, and NM living in /usr, see my other reply in
>  this thread. 
F11 without NM is perfectly functional. I don't even have it installed
on my laptop or any other Rawhide system.

-- Pete

[Bill Nottingham]

Jan Zelený (jzeleny(a)redhat.com) said: 
>  Hi,
>  > The seperation of / and /usr doesn't make much
>  > sense anymore.
>  
>  I don't think that's true. How about one /usr ro mounted via network to 
>  several machines? 
Given that you'd then need to:

- install each client machine separately, and then nuke /usr
- install server separately
- update server with --netsharedpath
- update client with --netsharedpath
- update all clients in sync with any server updates

it seems simpler to me, by far, to just have a shared / partition on the
network. (Which is supported.)

Bill

[Kevin Verma]

On Fri, Apr 17, 2009 at 5:28 AM, Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  Heya,
>
>  there's one topic that keeps popping up in various discussions: can't
>  we get rid of /usr? The seperation of / and /usr doesn't make much
>  sense anymore. We could make /usr a symlink to / for an interims phase
>  and everything would be good for conservative folks who think the FHS
>  is the holy bible.
>  
By practice separate "/" provides a minimal system that sysadmins
trusts will work when anything in "/usr" breaks. Also a minimal
filesystem that is quick & easy to repair/restore and can even remote
mount a "/usr" if needed.

You are asking to clutter "/" , What are you really trying to solve ?
maybe you should work to settle standards for $HOME first that is the
major pain area for a non-conservative user.

~conservatives

>  In the past more and more stuff has been moved from /usr to /.
> It's
>  unlikely that it's going to become less. Also, right now I am aware of
>  quite a few packages that don't get the seperation of / and /usr right
>  and rely on stuff from /usr during early bootup.
>
>  Let's eliminate this source of errors and clean up our file system
>  layout a bit. Let's drop /usr for F12!
>
>  And for the folks who think /usr is awesome because it allows mounting
>  /usr ro while mounting / rw: it's not. Much more useful it would be if
>  / in its entirety could be mounted ro. Debian allows that. It's not
>  too hard to make that work on fedora as well.
>
>  We wouldn't exactly be the first system without /usr as it seems. Hurd
>  does that too as I was informed. That makes at least one thing they
>  got right.
>
>  Let the flamefest begin!
>
>  Lennart

[Hans de Goede]

On 04/17/2009 01:58 AM, Lennart Poettering wrote:
>  Heya,
>
>  there's one topic that keeps popping up in various discussions: can't
>  we get rid of /usr? The seperation of / and /usr doesn't make much
>  sense anymore. We could make /usr a symlink to / for an interims phase
>  and everything would be good for conservative folks who think the FHS
>  is the holy bible.
>
>  In the past more and more stuff has been moved from /usr to /. It's
>  unlikely that it's going to become less. Also, right now I am aware of
>  quite a few packages that don't get the seperation of / and /usr right
>  and rely on stuff from /usr during early bootup.
>
>  Let's eliminate this source of errors and clean up our file system
>  layout a bit. Let's drop /usr for F12!
>
>  And for the folks who think /usr is awesome because it allows mounting
>  /usr ro while mounting / rw: it's not. Much more useful it would be if
>  / in its entirety could be mounted ro. Debian allows that. It's not
>  too hard to make that work on fedora as well.
>
>  We wouldn't exactly be the first system without /usr as it seems. Hurd
>  does that too as I was informed. That makes at least one thing they
>  got right.
>
>  Let the flamefest begin!
>  
I think that getting rid of /usr is a pretty pointless excercise in moving
things around. What we do need todo is better document in which scenarios
having /usr on a separate partition then / is supported and in which not.

That would seriously limit the amount of stuff which would need to be
moved to / , for example having a separate /usr on a network based
filesystem (or blockdevice such as iscsi) will not work, as netfs now
a days get mounted after NetworkManager and NM itself lives in /usr.

So what we need is a good document describing which combo's of separate
/ and /usr we do support and which we do not, more in general a document
which describes which dirs may be on separate partitions from / would be
good as I've for example seen bug reports that having /var on a separate
partitions has issues (to which my reply then is, well don't do that you
silly).

Regards,

Hans

[Kostas Georgiou]

On Fri, Apr 17, 2009 at 10:19:19AM +0200, Hans de Goede wrote:

>  That would seriously limit the amount of stuff which would need to
> be
>  moved to / , for example having a separate /usr on a network based
>  filesystem (or blockdevice such as iscsi) will not work, as netfs now
>  a days get mounted after NetworkManager and NM itself lives in /usr. 
I'll be very surprised if anyone that mounts /usr from the network
has NM enabled. I at least keep NM only in laptop installs for anything
else it is disabled as early as possible.

Kostas

[Hans de Goede]

On 04/17/2009 11:47 AM, Kostas Georgiou wrote:
>  On Fri, Apr 17, 2009 at 10:19:19AM +0200, Hans de Goede wrote:
>
> > That would seriously limit the amount of stuff which would need to be
> > moved to / , for example having a separate /usr on a network based
> > filesystem (or blockdevice such as iscsi) will not work, as netfs now
> > a days get mounted after NetworkManager and NM itself lives in /usr.
>
>  I'll be very surprised if anyone that mounts /usr from the network
>  has NM enabled. I at least keep NM only in laptop installs for anything
>  else it is disabled as early as possible.
>  
Ack, then we could put that in the doc, that /usr on a network based
filesystem (or blockdevice such as iscsi) is not supported with NM, or
whatever. I'm not trying to say what we should put in such a doc, this
is just an example. I'm merely trying to argue we need a Document
describing what we do and do not support wrt to having a separate /usr

Think for example something weird like /usr on fuse, do we want to support
that? Note that given the infinite amount of possibilities it is probably
the best to only describe what we do support.

Regards,

Hans

[Bill Nottingham]

Hans de Goede (j.w.r.degoede(a)hhs.nl) said: 
>  Think for example something weird like /usr on fuse, do we want to
> support
>  that? Note that given the infinite amount of possibilities it is probably
>  the best to only describe what we do support. 
IMO, no. (Nor root on fuse, which could I'm sure conceivably be hacked in.)

Bill

[Till Maas]

On Fr April 17 2009, Bill Nottingham wrote:
>  Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
>  > Think for example something weird like /usr on fuse, do we want to
>  > support that? Note that given the infinite amount of possibilities it is
>  > probably the best to only describe what we do support.
>
>  IMO, no. (Nor root on fuse, which could I'm sure conceivably be hacked in.) 
Allowing root on fuse might be useful for live images, that then maybe could 
use funionfs instead of the lvm snapshot.

Regards,
Till

[Jeremy Katz]

On Friday, April 17 2009, Till Maas said:
>  On Fr April 17 2009, Bill Nottingham wrote:
>  > Hans de Goede (j.w.r.degoede(a)hhs.nl) said:
>  > > Think for example something weird like /usr on fuse, do we want to
>  > > support that? Note that given the infinite amount of possibilities it is
>  > > probably the best to only describe what we do support.
>  >
>  > IMO, no. (Nor root on fuse, which could I'm sure conceivably be hacked in.)
>  
>  Allowing root on fuse might be useful for live images, that then maybe could 
>  use funionfs instead of the lvm snapshot. 
1) The live images are a pretty special beast and thus wouldn't be
influenced by any decision of fuse vs no fuse for /usr
2) fuse based unionfs suffers from a lot of the same problems as
non-fuse based.  Luckily, Val's work on union mounts seems to be
progressing pretty well although I'm not 100% sure what the time frame
on that is right now

Jeremy

[Christoph Wickert]

Am Freitag, den 17.04.2009, 01:58 +0200 schrieb Lennart Poettering:

>  And for the folks who think /usr is awesome because it allows
> mounting
>  /usr ro while mounting / rw: it's not. Much more useful it would be if
>  / in its entirety could be mounted ro. 
How about /.autofsck and /.autorelabel?

Regards,
Christoph

[Lennart Poettering]

On Fri, 17.04.09 11:02, Christoph Wickert (christoph.wickert(a)googlemail.com) wrote:

>  
>  Am Freitag, den 17.04.2009, 01:58 +0200 schrieb Lennart Poettering:
>  
>  > And for the folks who think /usr is awesome because it allows mounting
>  > /usr ro while mounting / rw: it's not. Much more useful it would be if
>  > / in its entirety could be mounted ro.
>  
>  How about /.autofsck and /.autorelabel? 
What about it?

You can always remount things temporarily:

  mount / -o rw,remount
  touch /.autofsck
  mount / -o ro,remount

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Christoph Wickert]

Am Samstag, den 18.04.2009, 01:55 +0200 schrieb Lennart Poettering:
>  On Fri, 17.04.09 11:02, Christoph Wickert
> (christoph.wickert(a)googlemail.com) wrote:
>  
>  > 
>  > Am Freitag, den 17.04.2009, 01:58 +0200 schrieb Lennart Poettering:
>  > 
>  > > And for the folks who think /usr is awesome because it allows mounting
>  > > /usr ro while mounting / rw: it's not. Much more useful it would be if
>  > > / in its entirety could be mounted ro.
>  > 
>  > How about /.autofsck and /.autorelabel?
>  
>  What about it?
>  
>  You can always remount things temporarily: 
Yes, but as long as system-config-selinux and the initscripts don't do
this automatically, there is no such thing as an entirely ro /.

Regards,
Christoph

[Benny Amorsen]

Lennart Poettering <mzerqung(a)0pointer.de&gt; writes:

>  Let's eliminate this source of errors and clean up our file
> system
>  layout a bit. Let's drop /usr for F12! 
Fedora is traditionally very conservative when it comes to anything that
involves file paths. Witness the "/sbin in the default PATH" flamewar,
which would probably have been solved best by turning /sbin into an
empty directory except for a bunch of symlinks. Instead Fedora (finally)
went with what others do: add /sbin to the default PATH.

If we can't get rid of /sbin, what are the chances that we can get rid
of /usr?


/Benny

[Ville Skyttä]

On Friday 17 April 2009, Benny Amorsen wrote:

>  Instead Fedora (finally)
>  went with what others do: add /sbin to the default PATH. 
What "others"?  None of the non-Fedora systems I have access to do that.  ISTR 
hearing that Ubuntu does, but the 8.04.2 box I have access to doesn't.  I have 
no idea whether these are the distro defaults though.

[Ralf Corsepius]

Benny Amorsen wrote:
>  Lennart Poettering <mzerqung(a)0pointer.de&gt; writes:
>  
> > Let's eliminate this source of errors and clean up our file system
> > layout a bit. Let's drop /usr for F12!
>  
>  Fedora is traditionally very conservative when it comes to anything that
>  involves file paths. Witness the "/sbin in the default PATH" flamewar,
>  which would probably have been solved best by turning /sbin into an
>  empty directory except for a bunch of symlinks. Instead Fedora (finally)
>  went with what others do: add /sbin to the default PATH. 
IMO, this decision is one
these @RH decisions, where RH has demonstrated 
their willingness to run down Fedora.

[Chris Adams]

Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  In the past more and more stuff has been moved from /usr to /.
Only things needed for boot have been moved to /.

>  And for the folks who think /usr is awesome because it allows
> mounting
>  /usr ro while mounting / rw: it's not. 
You're wrong.  On my servers, I make a small / and bigger /usr (mounted
ro).  The small / has a big advantage: less likely to fail.

Real-world example: I recently had a drive failure (actually multiple
drive failure in a RAID), and /usr was corrupted beyond repair.  I was
still able to boot in "emergency" mode, mounting only /, and restore
/usr from tape.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Lennart Poettering]

On Fri, 17.04.09 07:52, Chris Adams (cmadams(a)hiwaay.net) wrote:

>  
>  Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  > In the past more and more stuff has been moved from /usr to /.
>  
>  Only things needed for boot have been moved to /.
>  
>  > And for the folks who think /usr is awesome because it allows mounting
>  > /usr ro while mounting / rw: it's not.
>  
>  You're wrong.  On my servers, I make a small / and bigger /usr (mounted
>  ro).  The small / has a big advantage: less likely to fail.
>  
>  Real-world example: I recently had a drive failure (actually multiple
>  drive failure in a RAID), and /usr was corrupted beyond repair.  I was
>  still able to boot in "emergency" mode, mounting only /, and restore
>  /usr from tape. 
That sounds like a pretty arbitrary reason. I mean, if that's how you want
to create fail-safety then why don't you advocate splitting up the
whole mess even further? Why just three levels of hierarchies, why not
15? 

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Chris Adams]

Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  We could make /usr a symlink to / for an interims phase
>  and everything would be good for conservative folks who think the FHS
>  is the holy bible. 
Aside from any "religious" debate, there's a practical problem: last
time anything like this was tried, rpm couldn't handle moving
directories to symlinks.  That's why init.d is still under /etc/rc.d
instead of just /etc (and /etc/init.d is a symlink).

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Kevin Kofler]

Chris Adams wrote:
>  Aside from any "religious" debate, there's a practical
> problem: last
>  time anything like this was tried, rpm couldn't handle moving
>  directories to symlinks.  That's why init.d is still under /etc/rc.d
>  instead of just /etc (and /etc/init.d is a symlink). 
This can be hacked around with some fragile %pretrans hackery. That said, I
don't think that'd be feasible for such a radical change (affecting nearly
all packages), it'd have to be done by some special-case code (which is a
strong argument not to do it).

        Kevin Kofler

[Lennart Poettering]

On Sat, 18.04.09 01:15, Kevin Kofler (kevin.kofler(a)chello.at) wrote:

>  
>  Chris Adams wrote:
>  > Aside from any "religious" debate, there's a practical problem: last
>  > time anything like this was tried, rpm couldn't handle moving
>  > directories to symlinks.  That's why init.d is still under /etc/rc.d
>  > instead of just /etc (and /etc/init.d is a symlink).
>  
>  This can be hacked around with some fragile %pretrans hackery. That said, I
>  don't think that'd be feasible for such a radical change (affecting nearly
>  all packages), it'd have to be done by some special-case code (which is a
>  strong argument not to do it). 
I don't think the switch would be that complicated. The packagers
could change --prefix=/usr to --prefix=/ in the spec files whenever
they want. And when the last package is updated accordingly and a bit
of time passed and /usr is empty it could be replaced by a symlink.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Adam Williamson]

On Sat, 2009-04-18 at 01:24 +0200, Lennart Poettering wrote:

>  I don't think the switch would be that complicated. The
> packagers
>  could change --prefix=/usr to --prefix=/ in the spec files whenever
>  they want. And when the last package is updated accordingly and a bit
>  of time passed and /usr is empty it could be replaced by a symlink. 
oh, yes, because EVERYTHING builds with autotools. *sigh*
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Callum Lerwick]

On Fri, 2009-04-17 at 21:41 -0700, Adam Williamson wrote:
>  On Sat, 2009-04-18 at 01:24 +0200, Lennart Poettering wrote:
>  
>  > I don't think the switch would be that complicated. The packagers
>  > could change --prefix=/usr to --prefix=/ in the spec files whenever
>  > they want. And when the last package is updated accordingly and a bit
>  > of time passed and /usr is empty it could be replaced by a symlink.
>  
>  oh, yes, because EVERYTHING builds with autotools. *sigh* 
Any build system that doesn't provide the same configurability as
autotools is braindead and broken. And is likely already having to be
patched to hell and back to build into an RPM anyway.

[Adam Williamson]

On Sun, 2009-04-19 at 19:50 -0500, Callum Lerwick wrote:
>  On Fri, 2009-04-17 at 21:41 -0700, Adam Williamson wrote:
>  > On Sat, 2009-04-18 at 01:24 +0200, Lennart Poettering wrote:
>  > 
>  > > I don't think the switch would be that complicated. The packagers
>  > > could change --prefix=/usr to --prefix=/ in the spec files whenever
>  > > they want. And when the last package is updated accordingly and a bit
>  > > of time passed and /usr is empty it could be replaced by a symlink.
>  > 
>  > oh, yes, because EVERYTHING builds with autotools. *sigh*
>  
>  Any build system that doesn't provide the same configurability as
>  autotools is braindead and broken. And is likely already having to be
>  patched to hell and back to build into an RPM anyway. 
The point is it's not as simple as Lennart claims. There'd be dozens of
subtle changes in dozens of packages.

(Of course, nothing should be hardcoding /usr anyway. Everything should
be using macros which could be easily changed, which is the point of
macros. But I'm sure stuff is.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

[Matej Cepl]

On 2009-04-18, 04:41 GMT, Adam Williamson wrote:
>  oh, yes, because EVERYTHING builds with autotools. *sigh* 
Of course, or at least it SHOULD ;-)

Matěj

[Matej Cepl]

On 2009-04-16, 23:58 GMT, Lennart Poettering wrote:
>  In the past more and more stuff has been moved from /usr to /. 
I have this in /:

bin         The Right Thing to have
dev         The Right Thing to have
home        The Right Thing to have
lib64       Oh well, multilib junk
media       mostly empty, somehow good to have
opt         empty, could be useful for some weirdos
root        hmm, why don't we have /home/root ?
selinux     shouldn't it be /sys/selinux ?
sys         hopeless effort to eliminate /proc
usr
boot        necessary for many booting scenarios
etc         The Right Thing to have
lib         probably as well
lost+found  FS related
mnt         historical reasons, conflicts with /media
proc        The Right Thing to have
sbin        probably good to have
srv         good for servers, we should suppport it more IMHO
tmp         The Right Thing to have
var         The Right Thing to have

I see only /selinux and /sys as strange (and probably needless), 
/opt questionable, and /mnt and /media as conflicting; otherwise, 
I don't see big push to root.

What are you talking about?

Matěj

[Mat Booth]

On Mon, Apr 20, 2009 at 12:36 PM, Matej Cepl <mcepl(a)redhat.com&gt; wrote:
>  opt         empty, could be useful for some weirdos
>
>  I see only /selinux and /sys as strange (and probably needless),
>  /opt questionable, and /mnt and /media as conflicting; otherwise,
>  I don't see big push to root.
>  
All of our commercial products install into /opt. We may indeed be
wierdos, but I thought we doing the Right Thing... Aren't we?


-- 
Mat Booth
www.matbooth.co.uk

[Lennart Poettering]

On Mon, 20.04.09 13:36, Matej Cepl (mcepl(a)redhat.com) wrote:

>  
>  On 2009-04-16, 23:58 GMT, Lennart Poettering wrote:
>  > In the past more and more stuff has been moved from /usr to /. 
>  
>  I have this in /:
>  
>  bin         The Right Thing to have
>  dev         The Right Thing to have
>  home        The Right Thing to have
>  lib64       Oh well, multilib junk
>  media       mostly empty, somehow good to have
>  opt         empty, could be useful for some weirdos
>  root        hmm, why don't we have /home/root ?
>  selinux     shouldn't it be /sys/selinux ?
>  sys         hopeless effort to eliminate /proc
>  usr
>  boot        necessary for many booting scenarios
>  etc         The Right Thing to have
>  lib         probably as well
>  lost+found  FS related
>  mnt         historical reasons, conflicts with /media
>  proc        The Right Thing to have
>  sbin        probably good to have
>  srv         good for servers, we should suppport it more IMHO
>  tmp         The Right Thing to have
>  var         The Right Thing to have
>  
>  I see only /selinux and /sys as strange (and probably needless), 
>  /opt questionable, and /mnt and /media as conflicting; otherwise, 
>  I don't see big push to root.
>  
>  What are you talking about? 
Nowadays stuff like dbus, glib, libpng, the ALSA libs, ... install in
/. That's what I mean.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Frank Schmitt]

Lennart Poettering <mzerqung(a)0pointer.de&gt; writes:

>  Nowadays stuff like dbus, glib, libpng, the ALSA libs, ... install
> in
>  /. That's what I mean. 
No, they don't. They install in /usr.

-- 
Have you ever considered how much text can fit in eighty columns?  Given that a
signature typically contains up to four lines of text, this space allows you to
attach a tremendous amount of valuable information to your messages.  Seize the
opportunity and don't waste your signature on bullshit that nobody cares about.

[Lennart Poettering]

On Mon, 20.04.09 17:03, Frank Schmitt (ich(a)frank-schmitt.net) wrote:

>  
>  Lennart Poettering <mzerqung(a)0pointer.de&gt; writes:
>  
>  > Nowadays stuff like dbus, glib, libpng, the ALSA libs, ... install in
>  > /. That's what I mean.
>  
>  No, they don't. They install in /usr. 
They do:

395 [lennart@omega] ~$ ls /lib64/libdbus* /lib64/libpng* /lib64/libglib* /lib64/libasound*
| cat
/lib64/libasound.so.2@
/lib64/libasound.so.2.0.0*
/lib64/libdbus-1.so@
/lib64/libdbus-1.so.3@
/lib64/libdbus-1.so.3.4.0*
/lib64/libglib-2.0.so.0@
/lib64/libglib-2.0.so.0.2000.1*
/lib64/libpng12.so@
/lib64/libpng12.so.0@
/lib64/libpng12.so.0.31.0*
/lib64/libpng.so@
/lib64/libpng.so.3@
/lib64/libpng.so.3.31.0*

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Ralf Corsepius]

Lennart Poettering wrote:
>  On Mon, 20.04.09 17:03, Frank Schmitt (ich(a)frank-schmitt.net) wrote:
>  
> > Lennart Poettering <mzerqung(a)0pointer.de&gt; writes:
> >
> >> Nowadays stuff like dbus, glib, libpng, the ALSA libs, ... install in
> >> /. That's what I mean.
> > No, they don't. They install in /usr.
>  
>  They do:
>  
>  395 [lennart@omega] ~$ ls /lib64/libdbus* /lib64/libpng* /lib64/libglib*
> /lib64/libasound* | cat
>  /lib64/libasound.so.2@
>  /lib64/libasound.so.2.0.0*
>  /lib64/libdbus-1.so@
>  /lib64/libdbus-1.so.3@
>  /lib64/libdbus-1.so.3.4.0*
>  /lib64/libglib-2.0.so.0@
>  /lib64/libglib-2.0.so.0.2000.1*
>  /lib64/libpng12.so@
>  /lib64/libpng12.so.0@
>  /lib64/libpng12.so.0.31.0*
>  /lib64/libpng.so@
>  /lib64/libpng.so.3@
>  /lib64/libpng.so.3.31.0* 
They install their "essential run-time libraries" to / but install to 
/usr otherwise.

The libpng stuff contained in your listing, however, looks pretty much 
as a mispackaged package to me.

Ralf

[Lennart Poettering]

On Mon, 20.04.09 17:27, Ralf Corsepius (rc040203(a)freenet.de) wrote:

>  They install their "essential run-time libraries" to / but
> install to  
>  /usr otherwise.
>
>  The libpng stuff contained in your listing, however, looks pretty much  
>  as a mispackaged package to me. 
No, they are not mispackaged. They all are needed during early bootup.

It's all due to the pointless separation of / and /usr.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Ralf Corsepius]

Lennart Poettering wrote:
>  On Mon, 20.04.09 17:27, Ralf Corsepius (rc040203(a)freenet.de) wrote:
>  
> > They install their "essential run-time libraries" to / but install to  
> > /usr otherwise.
> >
> > The libpng stuff contained in your listing, however, looks pretty much  
> > as a mispackaged package to me.
>  
>  No, they are not mispackaged. They all are needed during early bootup. 
These are bugs:
...
/lib64/libpng12.so@
...
/lib64/libpng.so@


These are develfiles and belong into /usr/lib64 as well as they must not 
be required at bootup.

>  It's all due to the pointless separation of / and /usr. 
No,
these are packaging bugs, likely being introduced by 
under-experienced packages.

Ralf

[Seth Vidal]

On Mon, 20 Apr 2009, Ralf Corsepius wrote:

>  Lennart Poettering wrote:
> > On Mon, 20.04.09 17:27, Ralf Corsepius (rc040203(a)freenet.de) wrote:
> > 
> >> They install their "essential run-time libraries" to / but install to 
> >> /usr otherwise.
> >> 
> >> The libpng stuff contained in your listing, however, looks pretty much  as 
> >> a mispackaged package to me.
> > 
> > No, they are not mispackaged. They all are needed during early bootup.
>
>  These are bugs:
>  ...
>  /lib64/libpng12.so@
>  ...
>  /lib64/libpng.so@
>
>  

so I just ran:
# repoquery --repoid=rawhide -ql libpng
libpng-1.2.35-1.fc11.i586
/usr/lib/libpng.so.3
/usr/lib/libpng.so.3.35.0
/usr/lib/libpng12.so.0
/usr/lib/libpng12.so.0.35.0
/usr/share/doc/libpng-1.2.35
/usr/share/doc/libpng-1.2.35/CHANGES
/usr/share/doc/libpng-1.2.35/LICENSE
/usr/share/doc/libpng-1.2.35/README
/usr/share/doc/libpng-1.2.35/TODO
/usr/share/doc/libpng-1.2.35/example.c
/usr/share/doc/libpng-1.2.35/libpng-1.2.35.txt
/usr/share/man/man5/png.5.gz


looks like all the files are in /usr to me.

-sv

[Chris Adams]

Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  Nowadays stuff like dbus, glib, libpng, the ALSA libs, ... install
> in
>  /. That's what I mean. 
dbus is meant to be a system bus, so the library is in / because it may
be needed early.

libpng is installed in /usr.

The bsae ALSA shared library is installed in /lib (or /lib64).
Everything else (tools, card data, plugins, etc.) is in /usr.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Lennart Poettering]

On Mon, 20.04.09 10:28, Chris Adams (cmadams(a)hiwaay.net) wrote:

>  
>  Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  > Nowadays stuff like dbus, glib, libpng, the ALSA libs, ... install in
>  > /. That's what I mean.
>  
>  dbus is meant to be a system bus, so the library is in / because it may
>  be needed early.
>  
>  libpng is installed in /usr. 
Is that so? It's not on my machine.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

[Chris Adams]

Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de&gt; said:
>  On Mon, 20.04.09 10:28, Chris Adams (cmadams(a)hiwaay.net) wrote:
>  > libpng is installed in /usr.
>  
>  Is that so? It's not on my machine. 
What does "rpm -qif /lib*/libpng*" say?

I just checked Fedora 9 (release and updates), Fedora 10 (release and
updates), 11-Alpha, 11-Beta, and rawhide, and none have a libpng in /lib
or /lib64.

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Matthew Woehlke]

Matej Cepl wrote:
>  On 2009-04-16, 23:58 GMT, Lennart Poettering wrote:
> > In the past more and more stuff has been moved from /usr to /. 
>  
>  I have this in /:
>  [...]
>  root        hmm, why don't we have /home/root ? 
...because /home might be NFS, and ~root should be local (sharing a 
~root is not likely a good idea, besides that the permissions would be 
messed up).

-- 
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
-- 
Here endeth the rant... which I realize is not likely to Win Friends or 
Influence People, especially the person to whom it was directed.
   -- Charles Wilson (generalized)

[Ralf Corsepius]

Matthew Woehlke wrote:
>  Matej Cepl wrote:
> > On 2009-04-16, 23:58 GMT, Lennart Poettering wrote:
> >> In the past more and more stuff has been moved from /usr to /. 
> >
> > I have this in /:
> > [...]
> > root        hmm, why don't we have /home/root ?
>  
>  ...because /home might be NFS, 
Fedora's gnome doesn't support NFS mounted homes ;)
c.f. https://bugzilla.redhat.com/show_bug.cgi?id=436160

{Another case where @RH refuses to fix an apparent bug]

>  and ~root should be local (sharing a 
>  ~root is not likely a good idea, besides that the permissions would be 
>  messed up). 
ACK.

Ralf

[drago01]

On Mon, Apr 20, 2009 at 6:30 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  Matthew Woehlke wrote:
> >
> > Matej Cepl wrote:
> >>
> >> On 2009-04-16, 23:58 GMT, Lennart Poettering wrote:
> >>>
> >>> In the past more and more stuff has been moved from /usr to /.
> >>
> >> I have this in /:
> >> [...]
> >> root        hmm, why don't we have /home/root ?
> >
> > ...because /home might be NFS,
>
>  Fedora's gnome doesn't support NFS mounted homes ;)
>  c.f. https://bugzilla.redhat.com/show_bug.cgi?id=436160 
Err what? How is this related to "_Fedora's_" gnome rather to just gnome?
Also its not gnome does not support NFS mounted homes, but the trash
does not work in such a case.

But well that's a different topic.

[Ralf Corsepius]

drago01 wrote:
>  On Mon, Apr 20, 2009 at 6:30 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
> > Matthew Woehlke wrote:
> >> Matej Cepl wrote:
> >>> On 2009-04-16, 23:58 GMT, Lennart Poettering wrote:
> >>>> In the past more and more stuff has been moved from /usr to /.
> >>> I have this in /:
> >>> [...]
> >>> root        hmm, why don't we have /home/root ?
> >> ...because /home might be NFS,
> > Fedora's gnome doesn't support NFS mounted homes ;)
> > c.f. https://bugzilla.redhat.com/show_bug.cgi?id=436160
>  
>  Err what? How is this related to "_Fedora's_" gnome rather to just gnome?
It's the same issue as with Xorg - Upstream and Fedora are identical, 
with upstream abusing Fedora as Guinea pigs.

>  Also its not gnome does not support NFS mounted homes, but the trash
>  does not work in such a case. 
Right, like other GNOME key components (e.g.
gnome-session), it's trash 
handling is broken.

>  But well that's a different topic. 
Correct - (Lack of ) QA
in Fedora is off-topic, here.

Ralf

[Jesse Keating]

On Mon, 2009-04-20 at 13:36 +0200, Matej Cepl wrote:
>  srv         good for servers, we should suppport it more IMHO 
How are we supposed to "support it more" when we're explicitly supposed
to keep our hands off of it?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Juha Tuomala]

On Monday 20 April 2009 21:10:46 Jesse Keating wrote:
>  On Mon, 2009-04-20 at 13:36 +0200, Matej Cepl wrote:
>  > srv         good for servers, we should suppport it more IMHO
>  
>  How are we supposed to "support it more" when we're explicitly supposed
>  to keep our hands off of it? 
...by searching configuration files under /srv/etc for example and letting 
them to override the system ones? I guess looking and reading doesn't qualify
as "hands on" something, does it? :-)

I could imagine less pain when having all configurations in one filesystem,
pulling those disks out and reinstalling the whole system and putting
disks back. 

Apache conf.d is a small step to the right direction but not really a giant 
leap for mankind.


Tuju

-- 
Varo hattupäisiä autoilijoita.

[Jesse Keating]

On Mon, 2009-04-20 at 21:21 +0300, Juha Tuomala wrote:
>  
>  ...by searching configuration files under /srv/etc for example and letting 
>  them to override the system ones? I guess looking and reading doesn't qualify
>  as "hands on" something, does it? :-) 
Search where though, and in what order, and how deep?  And where do you
define where in /srv/ to look for the config file, in
the /etc/rc.d/init.d/<foo> file?  (which is back in etc again...)

/srv/ is hands off, undefined layout to be managed by the local admin,
period.  We can't make any assumptions about what is in there, nor how
it is being used.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Juha Tuomala]

On Monday 20 April 2009 21:37:35 Jesse Keating wrote:
>  On Mon, 2009-04-20 at 21:21 +0300, Juha Tuomala wrote:
>  > 
>  > ...by searching configuration files under /srv/etc for example and letting 
>  > them to override the system ones? I guess looking and reading doesn't qualify
>  > as "hands on" something, does it? :-)
>  
>  Search where though, and in what order, and how deep?   
I guess it doesn't matter where if you can somehow have the configs
there and keep them safe, like apache's case in /srv/etc/httpd/*
would be enough. It would be on the same filesystem. Everyone can 
find those dir names from scripts.


>  And where do you
>  define where in /srv/ to look for the config file, in
>  the /etc/rc.d/init.d/<foo> file?  (which is back in etc again...) 
It sounds like there should first be a specification and
then we should implement it. That would be nice, but unfortunately
there isn't. This industry has plenty of examples from de-facto
implementations until they are formally standardized.

>  /srv/ is hands off, undefined layout to be managed by the local
> admin,
>  period.  We can't make any assumptions about what is in there, nor how
>  it is being used. 
If shell looks under /srv in addition to /etc/profile.d it would allow
local admins use it. If they choose not to, they should do nothing. Such
improvement could even be switched off in some /etc/sysconfig file easily.
I don't see how it would intrude their autonomous area if it wont 
force them into anything.

The whole point of /srv is to have your server's role data in single 
location for obvious reasons. I can imagine that people running Fedora 
as server would appreciate such option due more frequent upgrades.


Tuju

-- 
Varo hattupäisiä autoilijoita.

[Jesse Keating]

On Mon, 2009-04-20 at 22:02 +0300, Juha Tuomala wrote:
>  It sounds like there should first be a specification and
>  then we should implement it. That would be nice, but unfortunately
>  there isn't. This industry has plenty of examples from de-facto
>  implementations until they are formally standardized. 
There is a specification, which is that the site admin gets to decide
how that path is used.  That is it.  Period.

>  
>  > /srv/ is hands off, undefined layout to be managed by the local admin,
>  > period.  We can't make any assumptions about what is in there, nor how
>  > it is being used.
>  
>  If shell looks under /srv in addition to /etc/profile.d it would allow
>  local admins use it.  
Look where though?  We can't pre-create directories, nor can we assume
any layout as that may have adverse effects based on how the admin is
using /srv/.

>  If they choose not to, they should do nothing. Such
>  improvement could even be switched off in some /etc/sysconfig file easily.
>  I don't see how it would intrude their autonomous area if it wont 
>  force them into anything.
>  
>  The whole point of /srv is to have your server's role data in single 
>  location for obvious reasons. I can imagine that people running Fedora 
>  as server would appreciate such option due more frequent upgrades.
>   
/srv exists as a place admins can put things without worry of the
operating system interfering.  Once you start interfering, /srv/ looses
it's usefulness, and admins will start making /data or /web or other
such things again.

-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)

[Juha Tuomala]

On Monday 20 April 2009 22:12:29 Jesse Keating wrote:
>  /srv exists as a place admins can put things without worry of the
>  operating system interfering.  Once you start interfering, /srv/ looses
>  it's usefulness, and admins will start making /data or /web or other
>  such things again. 
Having such feature off by default would add one more step (enabling it)
and putting disks back into reinstalled system. Nobody would have to
worry anything.

Tuju

-- 
Varo hattupäisiä autoilijoita.

[Toshio Kuratomi]

Juha Tuomala wrote:
>  
>  On Monday 20 April 2009 22:12:29 Jesse Keating wrote:
> > /srv exists as a place admins can put things without worry of the
> > operating system interfering.  Once you start interfering, /srv/ looses
> > it's usefulness, and admins will start making /data or /web or other
> > such things again.
>  
>  Having such feature off by default would add one more step (enabling it)
>  and putting disks back into reinstalled system. Nobody would have to
>  worry anything.
>   
What Jesse is saying is that the FHS standard for /srv is that
distributions are not to touch it (other than creating the directory).
Site admins can then do whatever they want there.  This may involve
creating a separate hierarchy like:

  /srv/etc/Daemon.conf
  /srv/sbin/Daemon
  /srv/share/Daemon/data.file

But it's equally valid for the site admin to instal a package named
"etc" in there like this:

  /srv/etc/etc-daemon
  /srv/etc/etc-daemon.conf
  /srv/etc/etc-daemon-data.file

Or the information in there could be totally different.  This
information is entirely up to the site admin.  If we try to read any
information in there, we take away this freedom of the site admin to
modify things to their hearts content within that hierarchy.

-Toshio

[Juha Tuomala]

On Monday 20 April 2009 23:07:18 Toshio Kuratomi wrote:
>  > Having such feature off by default... Nobody would have to
>  > worry anything. 
>  If we try to read any
>  information in there, we take away this freedom of the site admin to
>  modify things to their hearts content within that hierarchy. 
I missed the part where the freedom got lost.


Tuju

-- 
Varo hattupäisiä autoilijoita.

[Callum Lerwick]

On Mon, 2009-04-20 at 13:36 +0200, Matej Cepl wrote:
>  root        hmm, why don't we have /home/root ? 
Because splitting /home makes sense and you want to be able to log in as
root if your /home filesystem or NFS mount or whatever gets screwed.

[Peter Jones]

On 04/16/2009 07:58 PM, Lennart Poettering wrote:
>  Heya,
>  
>  there's one topic that keeps popping up in various discussions: can't
>  we get rid of /usr? The seperation of / and /usr doesn't make much
>  sense anymore. We could make /usr a symlink to / for an interims phase
>  and everything would be good for conservative folks who think the FHS
>  is the holy bible. 
This seems like a solution looking for a problem.  What problem is it that
you're trying to solve?

-- 
        Peter

Power corrupts.  Absolute power is kind of neat.
		-- John Lehman, Secretary of the Navy, 1981-1987

[Jesse Keating]

On Mon, 2009-04-20 at 16:17 -0400, Peter Jones wrote:
>  What problem is it that
>  you're trying to solve? 
People complaining about c-a-bs and /sbin in path.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Kevin Kofler]

Jesse Keating wrote:

>  On Mon, 2009-04-20 at 16:17 -0400, Peter Jones wrote:
> > What problem is it that
> > you're trying to solve?
>  
>  People complaining about c-a-bs and /sbin in path. 
By giving them something else to complain about? Interesting strategy... ;-)

        Kevin Kofler