Post by Linda WalshPost by Anton AylwardPost by Linda WalshAlso, it's not just about / and /usr, but also /usr/share --- at least a few
current booting progs make use of it,
Would you care to be more specific - tell us exactly what those are and
where they occur in the boot sequence, please.
---
They are in areas that were used as reasons to move files from
'/' to '/usr/... what I would mostly call 'services'...
Again that's a bit vague. Can you be specific.
I can't see any services that move files that way.
Services like DNS, Apache aren't part of the boot.
Are you talking about what are symlinks between /bin and /usr/bin?
I suppose that gets back to your question about PATH.
Personally I think you're asking the question the wrong way round.
I think you need to ask "what binaries are needed by the shell to get
the system booted". Of course that means different things to different
people. Some people think 'booted' means "all the way to the graphical
login prompt". I don't. I think it means "to a state where it can
begin to execute and run programs in user space".
If we look at it like that, then being able to run the shell, being able
to run all those goodies in /usr/bin, isn't part of booting.
The whole point of the initrd is that it should contain all that is
needed to boot, all the binaries and libraries, before they become
available in the file system hierarchy.
And that's where we differ; I boot from initrd.
If you don't then this whole thread of discussion is pointless since the
implicit assumptions are so fundamentally different.
Perhaps it dates me, but I recall the fuss when what we now call the
sysvinit approach was introduced; when /home was introduced and when
/usr was used for things other than users home directories.
Why did we do that separation in the first lace?
Basically, / was getting overloaded. In the old V7 days directories go
searched linearly and there was no name caching. Big directories were a
problem. Splitting /bin and /lib and offloading some stuff to /usr/bin
and /usr/lib meant for smaller directories and hence faster operation.
What was it with linear searches? O(N)?
Now we have binary indexing it doesn't matter.
One thing many of us don't face is a Read Only Root.
We have living systems, adding and removing users and the like, altering
configuration. But in an embedded system we want the 'system' to be
fixed, probably on flash memory. Having a unified / and /usr makes that
a lot easier.
Post by Linda WalshPost by Anton AylwardPost by Linda Walshand the same arguments used for /usr can be
used for /usr/share (where do you load your fonts from?)
I happily have my /usr/share as a NFS supplied by a 'headless server'.
Of course your mileage may vary; you may have your fonts supplied by the
font server - xfs.
----
That's disabled in some recent X due to some security bug or another.
That was back in 2007.
Post by Linda WalshIt is assumed all fonts are local.
What? It assumed all the fonts were local to the machine XFS was
running on, not local to the machine that X was running on. You only
needed the one font server for your network.
Post by Linda WalshI've been struggling to keep xfs-font server
available. I've been told by suse that it's outdated and should be dropped.
Who told you that?
Yes its a heavy process and it makes no sense for most people who are
running Linux as a windows desktop replacement and have just that
machine. Simple to have the X server access the files locally.
But again you've missed my point.
You were going on about fonts being needed for boot.
I'm saying that's not so; that they can be supplied by a NFS mount or by
a font server. the issue is CAN BE. The issue is that this is nt
necessary for boot. It is only necessary for running X, and X is a
graphical mode user space application.
Its optional. You can boot without it.
Post by Linda WalshPost by Anton AylwardThe point being that this is not needed until the X server starts up.
---
/usr files needed to be on "/", so that booting to a full desktop
could be parallelized.
Where did you get from 'parallelised' to that being an argument for /usr
files on / ?? That seems a non sequitor.
We're back to you playing around with the definition of 'boot'.
You seem to be saying that a machine isn't booted until the graphical
login is presented on the screen. I think that's not so. If it were
the headless server under my desk that does DNS, my local web server,
some dhcp stuff and more "never boots".
Post by Linda WalshPost by Anton AylwardYou may term that part of the boot sequence, but its not part of what
the initrd does for the rest of us.
----
That's the flip side of my point. The stuff in initrd is
stuff that isn't able to be done in systemd and needs to be
done before systemd launches. My question was why does the stuff that is
done in initrd have to live in /usr? It was on root, why not leave it
on root?
See above.
Once upon a time all the stuff you thin of as being in /usr WAS in /.
The reasons for moving it to /usr are no longer valid.
Post by Linda WalshIt was systemd that needed things on /usr,
That's a bit of an over simplification and over generalization.
I can write a target that needs /srv in order to start up Apache with
Tomcat and a web enabled application, but that doesn't mean systemd
needs things on /srv.
In fact you've got it backwards.
Given that / and /usr are the same file system it doesn't matter where
some stuff is so long as its where its expected to be. That is what the
symlinks you're complaining about are for. Some stuff really really
really lives in /usr/bin so the links from /bin to there are for the
stuff that isn't smart, that just does an exec for whatever reason.
Yes there are people who code 'exec' rather than than 'execlpv'. Yes
there are people who want light-weight chunks of code so try not to use
certain libraries or dynamic linking. They are trying to be "optimal"
for various values of 'optimal'. Just as you are with the way you've
modified your system ...
Post by Linda WalshBut now initrd needs things
on /usr -- or rather the things that initrd does needs things on /usr -- but
that isn't "systemd", right?
No, initrd doesn't need. Its all a matter of how initrd is configured
whether it HAS or doesn't HAVE various things that it needs to do things
that are asked of it. If it is asked to mount /usr since /usr is a
separate FS before proceeding then it need to have that capability.
Heck, of you wanted you could include any or all of /usr/bin and
/usr/lib in initrd. Its easy to do. I know, I did it once by mistake!
Post by Linda WalshIt, like the DNS server; like
Post by Anton AylwardPostfix; like the cron, ssh, and cups daemons, are all user space and
all come later.
---
Agreed... This was the traditional model.
What I want to know is why has 'S' and '1' equivalent functional
run levels been crippled to need booting from a ram disk when in other
distros (RH/Fedora, at least), this is not the case?
Why does my my GM car have 5 nuts/lugs to hold each wheel on whereas my
father's old Ford (and it seems the Fords of today) have only 4? Was it
just that old man Ford back in the opening years of the 20th century was
a cheapskate? Are the Fords less safe or are the GMs over-engineered?
Why do different car manufactures use screws and bolts of different
threads? BS, Whitworth, metric?
Design decisions, opinions of engineers, product differentiations ...
Post by Linda WalshIf you accept that services are separate from boot, that there is
no compelling reason why the boot-related files cannot remain (be moved back)
to /root and create a compatible boot case...(like booting from HD).
This is what I mean when I say you're missing the point.
If / and /usr (please! /root is the home directory of the user that
logs in under the id 'root'; its the only home directory no on /home)
are the same FS then the boot realted files are on the same FS as /.
They aren't on the same FS as /boot - that's interesting.
You need to read the above and think hard why we had a separate /usr in
the first place and why it was eventually put on a separate file system.
Logically we can split things up further. On one machine thetI have
control over I decreed that no file system could contain more that 5G so
they could be backed up to DVD. That meant on one developer's machine
we had to put /usr/lib/perl5 on a separate FS.
We could, logically, put /bin and /lib on their own file systems, along
with /usr/bin and /usr/lib. The we'd have the argument about moving
them each back to where we have had them on one FS.
Because that's the argument you're having.
I repeat, once upon a time there was only /bin and /lib - no /usr/bin or
/usr/lib. Splitting them was a performance modification. All we're
doing is going back to where we had it.
Well Ok, not quite absolutely. We still have /sbin, but that's another
story, another piece of optimization that led to something different.
--
Those who wish to seek out the cause of miracles, and to understand the
things of nature as philosophers, and not to stare at them in
astonishment like fools, are soon considered heretical and impious,and
proclaimed as such by those whom the mob adores as the interpreters of
nature and the gods. For these men know that once ignorance is put aside
that wonderment would be taken away which is the only means by which
their authority is preserved.
--Spinoza
--
To unsubscribe, e-mail: opensuse+***@opensuse.org
To contact the owner, e-mail: opensuse+***@opensuse.org
