SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Having /usr on different filesystem than / is "not supported"?
You should see how much more difficult it currently is to use a LUKS-protected LVM containing / with systemd compared to SysV init. This may change in the future but right now systemd makes the easy stuff easy (as it was with SysV init) and the difficult stuff VERY difficult (which it wasn't with SysV init).
You should see how much more difficult it currently is to use a LUKS-protected LVM containing / with systemd compared to SysV init. This may change in the future but right now systemd makes the easy stuff easy (as it was with SysV init) and the difficult stuff VERY difficult (which it wasn't with SysV init).
Hi, can you be more specific on LUKS protected LVM in systemd? THanks.
Last edited by Mercury305; 08-25-2012 at 12:32 PM.
Having /usr on different filesystem than / is "not supported"? How can someone who calls himself a developer be that ignorant about the Unix file hierarchy?
He obviously doesn't know why the /usr folder exists, yet considers himself competent to throw away the entire init system (developed over 40+ years) and replace it with a single daemon? He clearly doesn't know the first thing about the Unix philosophy either (or he simply doesn't agree with it).
This cannot possibly end well.
systemd is currently fully compatible with sys v init. Kinda how SLackware is fully BSD and Sys V init compatible.
Actually fedora has put everything into /usr for example /sbin /bin /lib /lib64... and a bunch of other folders are now linked to /usr
In other words, you don't know why /bin and /sbin exist outside the /usr hierarchy either?
because back in the days it was desinged that way?
but honestly when you are in a terminal isnt it more practical? less moving around = time efficiency?
also less clutter in /
you can still keep the same permissions even if it is in /usr
Last edited by Mercury305; 08-25-2012 at 12:57 PM.
Hi, can you be more specific on LUKS protected LVM in systemd? THanks.
1, 2, 3. The LVM recognition in systemd is hacky and of course Lennart blames LVM. I'd like to know how he expects me to produce snapshots (which are the most amazing things since sliced bread) without LVM unless he wants/expects me to use the still-young btrfs.
Quote:
Originally Posted by Mercury305
systemd is currently fully compatible with sys v init. Kinda how SLackware is fully BSD and Sys V init compatible.
Slackware is not BSD-compatible with anything. Slackware uses SysV init -- its init *scripts* are just setup in a BSD 'style'. Slackware's init scripts are not identical to the *BSDs' and you cannot drop a BSD init script into Slackware and expect it to work. Upstream projects can support "BSD-style Slackware init scripts" and/or "SysV-style init scripts", both of which will work in Slackware.
Quote:
Originally Posted by Mercury305
Actually fedora has put everything into /usr for example /sbin /bin /lib /lib64... and a bunch of other folders are now linked to /usr
I kind of like having /usr on a separate partition. All of my third-party packages are self-contained away from my main system. I recently suffered a power outage that caused data corruption of my /usr partition and restoring just that partition from a backup was nice and easy. Slackware is not currently divided properly between / and /usr (there are boot-essential utilities in /usr, which shouldn't be there) but in theory I would still prefer a separate / and /usr. Either way I don't see how a unified /usr is considered 'better'...it may not be worse than the current situation in Slackware but it doesn't make anything easier.
because back in the days it was desinged that way?
Actually, no.
Take a look at the file system hierarchy and the init scripts of any modern (non-systemd) distribution. Or one of the BSDs, for that matter. What you see are the results of over 40 years of evolutionary changes based on real-world experience and user/sysadmin feedback.
Through the years, a lot of different concepts have been tried and tested. Some were discarded in favor of better solutions, some were neither better or worse than what already existed and died away or lived on in niche systems, and some proved superior and gained widespread acceptance.
The file system hierarchy is one of these tried-and-tested concepts. It exists to allow the flexibility needed in a great number of real-world scenarios. For instance, you can put /usr on a network file system and have a number of servers share the same /usr directory. You can lock ordinary users out of the /sbin and /usr/sbin directories, and the system will still work. And I'm just scratching the surface here; there's much more to the Unix file hierarchy than this.
In order to determine what is a good idea and will work for everyone, you need to know a great deal about the different scenarios in which the OS is being used. As it is very difficult for any single person to accumulate all this knowledge, cooperation with the community at large is essential if you want to propose changes.
As someone proposing changes, one has to accept that there may be somebody out there who knows important stuff you don't, and also that your needs and ideas are not more important than everybody else's. In fact, the way you use the OS is not likely to be typical or even particularly common.
When I look at systemd, I see the ghost of the original BSD init. Actually, systemd reintroduces a serious weakness in BSD init (everything hinges on one complex part of the init process), while at the same time shoehorning in compatibility with SysV. My question is simply, why are we doing this?
1, 2, 3. The LVM recognition in systemd is hacky and of course Lennart blames LVM. I'd like to know how he expects me to produce snapshots (which are the most amazing things since sliced bread) without LVM unless he wants/expects me to use the still-young btrfs.
Slackware is not BSD-compatible with anything. Slackware uses SysV init -- its init *scripts* are just setup in a BSD 'style'. Slackware's init scripts are not identical to the *BSDs' and you cannot drop a BSD init script into Slackware and expect it to work. Upstream projects can support "BSD-style Slackware init scripts" and/or "SysV-style init scripts", both of which will work in Slackware.
I kind of like having /usr on a separate partition. All of my third-party packages are self-contained away from my main system. I recently suffered a power outage that caused data corruption of my /usr partition and restoring just that partition from a backup was nice and easy. Slackware is not currently divided properly between / and /usr (there are boot-essential utilities in /usr, which shouldn't be there) but in theory I would still prefer a separate / and /usr. Either way I don't see how a unified /usr is considered 'better'...it may not be worse than the current situation in Slackware but it doesn't make anything easier.
Thanks for your enlightenment on 1 and 2. I also had /usr partition separate on my fedora pc. Before I used to just put /home in seperate partition for all my distros and would have to install everything from scratch. Not any more for my Fedora. But that is just my way of doing things.
1, 2, 3. The LVM recognition in systemd is hacky and of course Lennart blames LVM. I'd like to know how he expects me to produce snapshots (which are the most amazing things since sliced bread) without LVM unless he wants/expects me to use the still-young btrfs.
In other words, this Lennart character is not and has never been a sysadmin. He has never had to provision storage, he's never had to perform a backup of a live file system, and he's obviously never even heard of libvirt or CloudStack.
Why is this man in charge of an important project at RedHat? For heaven's sake, all they do is sell support contracts for servers in large organizations!
Take a look at the file system hierarchy and the init scripts of any modern (non-systemd) distribution. Or one of the BSDs, for that matter. What you see are the results of over 40 years of evolutionary changes based on real-world experience and user/sysadmin feedback.
Through the years, a lot of different concepts have been tried and tested. Some were discarded in favor of better solutions, some were neither better or worse than what already existed and died away or lived on in niche systems, and some proved superior and gained widespread acceptance.
The file system hierarchy is one of these tried-and-tested concepts. It exists to allow the flexibility needed in a great number of real-world scenarios. For instance, you can put /usr on a network file system and have a number of servers share the same /usr directory. You can lock ordinary users out of the /sbin and /usr/sbin directories, and the system will still work. And I'm just scratching the surface here; there's much more to the Unix file hierarchy than this.
In order to determine what is a good idea and will work for everyone, you need to know a great deal about the different scenarios in which the OS is being used. As it is very difficult for any single person to accumulate all this knowledge, cooperation with the community at large is essential if you want to propose changes.
As someone proposing changes, one has to accept that there may be somebody out there who knows important stuff you don't, and also that your needs and ideas are not more important than everybody else's. In fact, the way you use the OS is not likely to be typical or even particularly common.
When I look at systemd, I see the ghost of the original BSD init. Actually, systemd reintroduces a serious weakness in BSD init (everything hinges on one complex part of the init process), while at the same time shoehorning in compatibility with SysV. My question is simply, why are we doing this?
Yes but this file move had been adopted by Solaris before Fedora a good while back. Its not a Poettering invention
Yes but this file move had been adopted by Solaris before Fedora a good while back. Its not a Poettering invention
Does that mean that what works for Solaris can and will be a good idea for everyone?
You do know that Solaris is very different from other unices in a number of ways, and is being used in a very small (but lucurative) segment of the market?
Does that mean that what works for Solaris can and will be a good idea for everyone?
You do know that Solaris is very different from other unices in a number of ways, and is being used in a very small (but lucurative) segment of the market?
Solaris is pretty much on top of the food chain when it comes to UNIX (sys V)... correct me if I am wrong. They (Sun) created ZFS, Java and VB. I would give them at least some credibility.
Solaris is pretty much on top of the food chain when it comes to UNIX (sys V)... correct me if I am wrong. They (Sun) created ZFS, Java and VB. I would give them at least some credibility.
Some years ago, I had the pleasure of working alongside SunOS/Solaris people, and that was my first encounter with the OS. At the time, Solaris was so far ahead of the competition in several key areas that it wasn't even funny.
I was working mainly with Windows servers back then, and could only listen in envy when the Solaris people told me about hotplug support for CPUs and memory, and of an upcoming feature called "containers" or "zones" that would let you partition a single server into several virtual systems. It sure sounded a lot better than "VMWare Server".
None of this has anything to do with the file hierarchy. Perhaps Solaris isn't ever used in environments where a shared /usr partition is useful. Perhaps it doesn't even support such a setup, I honestly don't know. I do believe, however, that generalizing about anything Unix-like based solely on experience with Solaris is not likely to result in a valid conclusion. It's a great Unix variant, no doubt. It is not, and was never meant to be, a generic solution for all your Unix needs.
As mentioned, my question was and is "why are we abandoning SysV for systemd". As first, I got the impression that it had to do with boot time (totally irrelevant on servers), but I see that at least one systemd developer claims this to be of no importance.
If we are to abandon major features of the OS and introduce complexity to everybody's systems, there better be a good reason for it.
Some years ago, I had the pleasure of working alongside SunOS/Solaris people, and that was my first encounter with the OS. At the time, Solaris was so far ahead of the competition in several key areas that it wasn't even funny.
I was working mainly with Windows servers back then, and could only listen in envy when the Solaris people told me about hotplug support for CPUs and memory, and of an upcoming feature called "containers" or "zones" that would let you partition a single server into several virtual systems. It sure sounded a lot better than "VMWare Server".
None of this has anything to do with the file hierarchy. Perhaps Solaris isn't ever used in environments where a shared /usr partition is useful. Perhaps it doesn't even support such a setup, I honestly don't know. I do believe, however, that generalizing about anything Unix-like based solely on experience with Solaris is not likely to result in a valid conclusion. It's a great Unix variant, no doubt. It is not, and was never meant to be, a generic solution for all your Unix needs.
As mentioned, my question was and is "why are we abandoning SysV for systemd". As first, I got the impression that it had to do with boot time (totally irrelevant on servers), but I see that at least one systemd developer claims this to be of no importance.
If we are to abandon major features of the OS and introduce complexity to everybody's systems, there better be a good reason for it.
Yup, if you checked out my last comment to Volkerdi you will see that I stated if systemd is boasting about its speed then why the hell would it start so many services at boot to slow down its speed?
Thats when I was able to understand the underlying reason of "why?"
Hint: White furry animals that run inside a wheel.
Last edited by Mercury305; 08-25-2012 at 02:03 PM.
Actually fedora has put everything into /usr for example /sbin /bin /lib /lib64... and a bunch of other folders are now linked to /usr
Quote:
Originally Posted by Ser Olmy
In other words, you don't know why /bin and /sbin exist outside the /usr hierarchy either?
FWIW, Patrick didn't shut out the possibility of using a similar filesystem layout on Slackware some day when I asked him about it.
Quote:
Originally Posted by jeremy
LQ) What do you think about Fedora and Solaris 'simplifying' the filesystem by doing stuff like merging /usr/bin and /bin? Something you would ever consider? (ruario)
volkerdi) Sure, I could see doing that, but we'll see how it goes elsewhere and to what extent things start to expect it to be that way. On Slackware (and other systems) a lot of the binaries that would otherwise install to /usr/bin have to be moved to /bin because they are needed before /usr is available, if /usr is on a separate partition. Likewise, libraries have also had to move. This has led to a lot of symlinks pointing from /usr/bin to /bin, or from /usr/sbin to /sbin, and elsewhere around the system. Now, I'm not sure that I consider this to be a bad enough situation that it's worth the pain of changing it, but it's certainly under consideration. Really, the most painful requirement about /usr was the rule that it had to be possible to mount it as a network volume. That might have been a good idea at the time when hard drives were expensive and small, but it probably isn't done a whole lot today. If we do make a change like that it would be a major change (and would warrant a major version number bump for sure), and I'm not sure how (or if) upgrading from an earlier version would work. Perhaps with a tool on the installer that would transform the system to the new layout? Dancing that dance on a running machine would be a difficult trick with the package utilities based on shell scripts that are using binaries at the same time that they'd have to be moved around.
On a related note, we're looking into how to best handle a top-level /run directory. This does make sense, if not to merge /var/run with it, at least to have it available in early boot.
As far as these kinds of changes are concerned, we have to be certain that they actually solve important issues and leave us better off than we were before, and without new problems that we didn't previously have. Sure, the way things are now until /usr comes online we may be dealing with a limited set of utilities, but we've been able to make due with them in early boot so far. If, for example, the changes make it a requirement to use an initramfs on every system, I wouldn't necessarily consider that to be simplifying things.
Last edited by ruario; 08-25-2012 at 03:01 PM.
Reason: added Mercury305 quote for context and used a different Ser Olmy quote because it was a response to this
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.