Linda Walsh said the following on 04/12/2013 10:19 PM:
Anton Aylward wrote:
Linda Walsh said the following on 04/11/2013 09:59 PM:
Also, 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.
and 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.
It 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.
I'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.
The point being that this is not needed until the X server starts up.
But having "X" available @ boot, was used to support the argument that /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".
You 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.
It 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 ...
But 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!
It, like the DNS server; like
Postfix; 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 ...
If 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+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org