Re: [gentoo-user] systemd installation location
On 01/10/2013 00:14, pk wrote: On 2013-09-30 08:45, Alan McKinnon wrote: That is over-simplifying the problem and trivializing it. No-one ever said the *everythign* in /usr is criticial for boot. Is it really over-simplyfying it? How am I supposed to know whatever comes next? Someone (upstream) *may* find it boot-critical to have 'Space Invaders' operational during boot. Yes, I say that somewhat *tounge-in-cheek* but the way things are going I'm not so sure anymore... There are many examples in /usr you could have used to illustrate your point, such as many fuse modules. And yet you chose an imaginary space invader game. Let's rather stick within the bounds of what is feasible, OK? This is the problem: a. There exists code used at boot and early-user space time. It is critical that this code is available when needed. I fully understand this and *if* I ever were to install code that I *knew* had this dependency I would take a serious look if I really *need* it and only then install it. But it would be up to me to make that decision and take the necessary steps. But it's not just you. You are not running LFS, you are running Gentoo. It has ebuilds and ebuilds put the generated files somewhere, and that destination is the same for every user of that ebuild. Unix, by design and unlike a traditional mainframe OS, does not distinguish between different types of files and does limit where you can put files. This has two consequences - you can do virtually anything you like with it as everything is a file, and filesystem files and structure have been moved out to human space in the hands of the sysadmin/packager/maintainer/user or whatever. Some sanity must prevail. The Linux boot process can conceivably run any arbitrary code it needs to run to get userspace into a runnable state. This can easily be code that we haven't conceived of yet and becuase it is Unix, it could reside anywhere. Also because it's Unix and because sysadmins have learned over the years we constrain ourselves to putting the code in the bin, sbin and lib directories in / and in /usr. Clearly, there is a massive distinction between code there and in say /opt or /var/lib, that is why you won't find boot-critical code there. But there is no such clear distinction between / and /usr. What *you* think is not boot critical may be criticial for someone else. And here's the kicker: You don't get to decide for the other guy. But the packager gets to support him, and has to edit ebuilds to install all the necessary code not in /usr but in /. And they have to do this over and over and over, and while they are doing that they have to answer users like you who are complinaing about unneccessary rebuilds just to change the desitnation of a few files. This is a no-win-ever situation for devs and they have decided they are not doing it anymore and have made a decision to not support separate /usr without initramfs. that is their right as you do not pay them a salary. This is the correct decision for Gentoo to have made, as the problem is open ended and is never completed, plus there is no clear distinction between what is boot critical in the general case and what is not. if you can't see or understand that, then we have nothing more to discuss. If you don't like what Gentoo has done then I recommend you take it like a man and fork. Assume the maintenanceburden yourself. b. One cannot predict with absolute certainty 100% of the time what exactly that critical code is. In a general manner, no, you are correct... Also, see above (Invaders)... (And if you don't understand what I'm trying to say, I'm saying this is as *arbitrary* as it gets - which you, like me, seem to be opposed to[arbitrariness]) c. many reasonable setups turn out to have such critical code in /usr, and this cannot be reliably predicted in advance So I avoid things like Gnome, pulseaudio, systemd and similar stuff like the plague but I *still* shall be forced to use whatever is dictated by these things[1]? Don't get me wrong, if anyone wants to install Gnome or whatever then they should have the restrictions required by it. Your second paragraph reveals that you beleive you already know everything you need to have to boot your system. Now do the same for every possible Gentoo user out there and have it work 100% of the time in ALL valid cases. I *do* know everything I need to have to boot my system. I carefully select my hardware and I take particular care of how I set up my system thank you very much. But apparently my system is no longer deemed a valid case... so I'm obviously not a possible Gentoo user anymore. Do you now see the problem and the fulls cope and impact of it? I've seen it since *long* before this thread started. The main problem is lack of resources (because of stupid decisions upstream which puts a burden on Gentoo devs) and I can't (currently) help much with that other than through monetary means
Re: [gentoo-user] systemd installation location
On 2013-10-01 08:16, Alan McKinnon wrote: There are many examples in /usr you could have used to illustrate your point, such as many fuse modules. And yet you chose an imaginary space invader game. Let's rather stick within the bounds of what is feasible, OK? What can I say, I like to exaggerate... :-) But it seems you got my point. Although I would not rule out Space Invaders as either imaginary (it came out in 1978) nor infeasible (at boot). But it's not just you. You are not running LFS, you are running Gentoo. It has ebuilds and ebuilds put the generated files somewhere, and that destination is the same for every user of that ebuild. Which is why I said what I said further down in the mail you replied to... Unix, by design and unlike a traditional mainframe OS, does not distinguish between different types of files and does limit where you can put files. This has two consequences - you can do virtually anything you like with it as everything is a file, and filesystem files and structure have been moved out to human space in the hands of the sysadmin/packager/maintainer/user or whatever. Some sanity must prevail. Yes, sanity is what I'm after but it seems I'm in the minority... The Linux boot process can conceivably run any arbitrary code it needs to run to get userspace into a runnable state. This can easily be code that we haven't conceived of yet and becuase it is Unix, it could reside anywhere. Also because it's Unix and because sysadmins have learned over the years we constrain ourselves to putting the code in the bin, sbin and lib directories in / and in /usr. Clearly, there is a massive distinction between code there and in say /opt or /var/lib, that is why you won't find boot-critical code there. But there is no such clear distinction between / and /usr. What *you* think is not boot critical may be criticial for someone else. I couldn't agree more. However, since some devs (and I don't mean anyone in particular) have started to expect /usr to always be available for boot-critical software then what is to say that the next one *will* require /opt and/or /var/lib at boot time? And where do we make a distinction between a boot-critical thing and a non-boot-critical thing. For all I know there may actually be someone out there seriously considering adding Space Invaders as a boot thing for, say sysops that want to reboot a really big server and want to play while booting... I'm only kidding of course and hope noone takes this seriously!? ;-) And here's the kicker: You don't get to decide for the other guy. But the packager gets to support him, and has to edit ebuilds to install all the necessary code not in /usr but in /. And they have to do this over and over and over, and while they are doing that they have to answer users like you who are complinaing about unneccessary rebuilds just to change the desitnation of a few files. This is a no-win-ever situation for devs and they have decided they are not doing it anymore and have made a decision to not support separate /usr without initramfs. that is their right as you do not pay them a salary. This is the correct decision for Gentoo to have made, as the problem is open ended and is never completed, plus there is no clear distinction between what is boot critical in the general case and what is not. if you can't see or understand that, then we have nothing more to discuss. If you don't like what Gentoo has done then I recommend you take it like a man and fork. Assume the maintenanceburden yourself. I've already come to that conclusion myself (as, again, I mentioned in my mail further down). Bye, so long and thanks for the f*sh! Best regards Peter K
Re: [gentoo-user] systemd installation location
On 2013-09-30 04:05, Mark David Dumlao wrote: It's true that it's nice to have a semblance of order where different parts go. But all libraries and binaries in /usr is also a semblance of order. You don't separate stuff for the sake of separating stuff. You separate them because you have a good reason to separate them. It turns out that there isn't a good reason to separate them, and that there's no way to predictably separate them. Mushing them together isn't just a stop-gap or good-enough solution. The idea of keeping system-critical separate from non-critical was not maintainable in the long run to begin with. So what you're saying is that everything in /usr is system-critical? I have gimp installed in /usr... I don't see a need to start gimp at boot time. Maybe we should classify frozen-bubble as system-critical as well (it's also in /usr)? Seriously, boot-critical would be something that the system cannot *boot without*, which belongs in /. Everything else should be in /usr, i.e. non-boot-critical. How hard is it to start *non-boot* (system) critical *after* boot (things like sshd)? I do that today... are the same. Distro packagers, however, have to decide for 100% of the cases. So they're going to end up making weird decisions that are easy for you to second-guess but are actually tough. That's only true for binary distros. If you want to solve the hard problem, you want to create a tool that will automate / and /usr migrations. Portage has to be aware of the tool What's wrong with using autotools? I really don't see why you need it to be dynamic. In Gentoo you install stuff once for every version (or if you change use flag). Why invent stuff/complicate matters when you don't need to? Best regards Peter K
Re: [gentoo-user] systemd installation location
On 30/09/2013 08:24, pk wrote: So what you're saying is that everything in /usr is system-critical? I have gimp installed in /usr... I don't see a need to start gimp at boot time. Maybe we should classify frozen-bubble as system-critical as well (it's also in /usr)? Seriously, boot-critical would be something that the system cannot *boot without*, which belongs in /. Everything else should be in /usr, i.e. non-boot-critical. How hard is it to start *non-boot* (system) critical *after* boot (things like sshd)? I do that today... That is over-simplifying the problem and trivializing it. No-one ever said the *everythign* in /usr is criticial for boot. This is the problem: a. There exists code used at boot and early-user space time. It is critical that this code is available when needed. b. One cannot predict with absolute certainty 100% of the time what exactly that critical code is. c. many reasonable setups turn out to have such critical code in /usr, and this cannot be reliably predicted in advance Your second paragraph reveals that you beleive you already know everything you need to have to boot your system. Now do the same for every possible Gentoo user out there and have it work 100% of the time in ALL valid cases. Do you now see the problem and the fulls cope and impact of it? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] systemd installation location
On Mon, 30 Sep 2013 10:42:37 +0800, Mark David Dumlao wrote: What was /usr's original purpose? /usr was originally the home directory. Programs were moved there because Unix didn't fit into a single disk. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html Thanks for that link, it does a good job of explaining how we got in this mess. -- Neil Bothwick I spilled Spot remover on my dog. Now he's gone. signature.asc Description: PGP signature
Re: [gentoo-user] systemd installation location
On Mon, Sep 30, 2013 at 2:24 PM, pk pete...@coolmail.se wrote: On 2013-09-30 04:05, Mark David Dumlao wrote: are the same. Distro packagers, however, have to decide for 100% of the cases. So they're going to end up making weird decisions that are easy for you to second-guess but are actually tough. That's only true for binary distros. That is not true. Even in source-based distros like gentoo, distro packagers decide where the files go. So far, it's only in a completely from scratch *nix environment where the end user gets to decide where files go. And where do the files go is pretty much what made this problem be apparent. Many packages with udev rules depend on programs, resources, libraries in /usr. It is _not_ trivial to fix those packages. If _you_ think it is, I recommend you replace the entire gentoo bugzilla community because you are clearly a rockstar bugfixer. If you want to solve the hard problem, you want to create a tool that will automate / and /usr migrations. Portage has to be aware of the tool What's wrong with using autotools? I really don't see why you need it to be dynamic. In Gentoo you install stuff once for every version (or if you change use flag). Why invent stuff/complicate matters when you don't need to? You do not really understand the scope of the problem. The problem is that boot critical is subjective to the system. A program that is boot critical for one system may not be boot critical for another. But where software gets installed is generally hard coded into packages (defaulting to /usr). That is the status quo. Because of this, the package manager simply does not have enough information on whether a package is boot critical or not. It is not part of the ebuild. It is not part of the emerge switches. Not only that, whether a package is boot critical or not could change at any time. nfs-utils are only boot critical if you use nfs. ssh is only boot critical if you use sshfs. Perl is only boot critical if you have a startup script that counts the number of virgins you've sacrificed to the goat god. Making a filesystem boot-critical is something that the package manager does not and cannot track. Autotools also cannot track it as it happens outside of compile time. If you want the / and /usr separation nonsense solved, you should write a program that can mark a binary as boot-critical. It will then copy the binary and all of its libraries to /, and copy and rebuild any dependencies into / as well. It must be a full copy, otherwise the promise that /usr can be shared will be violated. Everytime that package is rebuilt, it must be built and copied into _both_ / and /usr. Your program should also be able to unmark a binary as boot critical and thus delete any copies in / Your program should be understood by portage, or at least run as a portage hook. Copy paste that to all package managers as well. What's more, any program depending on a boot critical program must be rewritten so that it looks for the program in the correct path. For backwards compatibility, a boot critical program should generate\ symlinks in the / filesystem's /usr tree (the normally empty directory shadowed by the /usr filesystem), so that if the /usr filesystem is not available any programs depending on that program would still work. That program is writable in theory. It's VERY tedious to write it, much less test that it works. -- This email is:[ ] actionable [x] fyi[ ] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] systemd installation location
On 2013-09-30 08:45, Alan McKinnon wrote: That is over-simplifying the problem and trivializing it. No-one ever said the *everythign* in /usr is criticial for boot. Is it really over-simplyfying it? How am I supposed to know whatever comes next? Someone (upstream) *may* find it boot-critical to have 'Space Invaders' operational during boot. Yes, I say that somewhat *tounge-in-cheek* but the way things are going I'm not so sure anymore... This is the problem: a. There exists code used at boot and early-user space time. It is critical that this code is available when needed. I fully understand this and *if* I ever were to install code that I *knew* had this dependency I would take a serious look if I really *need* it and only then install it. But it would be up to me to make that decision and take the necessary steps. b. One cannot predict with absolute certainty 100% of the time what exactly that critical code is. In a general manner, no, you are correct... Also, see above (Invaders)... (And if you don't understand what I'm trying to say, I'm saying this is as *arbitrary* as it gets - which you, like me, seem to be opposed to[arbitrariness]) c. many reasonable setups turn out to have such critical code in /usr, and this cannot be reliably predicted in advance So I avoid things like Gnome, pulseaudio, systemd and similar stuff like the plague but I *still* shall be forced to use whatever is dictated by these things[1]? Don't get me wrong, if anyone wants to install Gnome or whatever then they should have the restrictions required by it. Your second paragraph reveals that you beleive you already know everything you need to have to boot your system. Now do the same for every possible Gentoo user out there and have it work 100% of the time in ALL valid cases. I *do* know everything I need to have to boot my system. I carefully select my hardware and I take particular care of how I set up my system thank you very much. But apparently my system is no longer deemed a valid case... so I'm obviously not a possible Gentoo user anymore. Do you now see the problem and the fulls cope and impact of it? I've seen it since *long* before this thread started. The main problem is lack of resources (because of stupid decisions upstream which puts a burden on Gentoo devs) and I can't (currently) help much with that other than through monetary means (donations) but since Gentoo seems to go the way of the dodo for me (or assimilated if you will) then I will take my leave. For a while now it has only been inertia keeping me here. Or maybe a hope that things will get better... [1] And no, I'm not blaming systemd, Gnome or any of the other pests in particular for this... Best regards Peter K
Re: [gentoo-user] systemd installation location
On Tue, 01 Oct 2013 00:14:55 +0200, pk wrote: Your second paragraph reveals that you beleive you already know everything you need to have to boot your system. Now do the same for every possible Gentoo user out there and have it work 100% of the time in ALL valid cases. I *do* know everything I need to have to boot my system. I carefully select my hardware and I take particular care of how I set up my system thank you very much. But apparently my system is no longer deemed a valid case... so I'm obviously not a possible Gentoo user anymore. Actually you are. No one said that your setup would no longer work, only that it would no longer be supported by the devs. Since you know exactly what you want and how to get it, that shouldn't be a problem as you support it yourself. Come November you will be running an unsupported setup, just like I am now and have been for most of this year. But my system hasn't stopped working. Well it did once and I had to fix it myself, that's all. -- Neil Bothwick A computer is like an Old Testament god, with a lot of rules and no mercy. -- Joseph Campbell signature.asc Description: PGP signature
Re: [gentoo-user] systemd installation location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2013 02:52 PM, William Hubbs wrote: All, I can clarify one part of the systemd issue, because I have been involved in this part of the issue for months. Again, I am not trying to start a dispute here, just providing a clarification. The choice to install all of the systemd binaries in /usr is not an upstream choice. It was a choice made a year ago when our systemd team was one person [1], and now the team doesn't want to change it because it would require users to go through a migration, and the rest of the team doesn't see a benefit in changing it since it still links to libraries in /usr/lib. I joined the team, primarily to take responsibility for this change and to try to make it go as smoothly as possible, but I was overruled even though upstream gave us a pretty strong warning about it. William [1] http://blogs.gentoo.org/mgorny/2012/01/04/moving-systemd-into-usr-the-technical-side/ Ouch. So systemd upstream doesn't suggest putting binaries in /usr? That shows at least a little respect for /bin, et al. Based on the blog post, I'm getting the feeling that -- for systemd anyway -- the issues with /usr are caused by its dependencies rather than systemd itself. If dbus and whatnot were in /bin where they belong, the need for an initramfs (for separate /usr) and/or dealing with things in a non-standard place wouldn't need to happen. I'm not affected by anything regarding the /usr switch, but I'd like to have a good talk with the first person who decided a system-critical binary belonged in /usr instead of /bin or /sbin. They've created a mess for every distro and any project that depends on their work. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSSMu5AAoJEJUrb08JgYgHFz4H/iyZt6MlTeW702KOlIy2Ydse mzsfiyPfPz8Rbz0Mqp5/17R8aQzOUG4l6dZS7d9HFKuMCG7t+kNZCSvxD69XeTVO tZY6YjHCGQaE6WaAMbiasXfRTeRt4ZDtP5l/lCUsYcTCWN13PyIcHCb5rGNHnHqq J/OcSeF5EoS+G/uSAuzDVaQ5wa0Z0qkqVSqQGjJ5NUHYIA5ZrtYpMNDR+MkFYYAB 7I4JE5kDXRYoBSiLLDb7tI7F1nGogHXxzECmMYW4ZneU0AJwhUAK0kU+oTHY2Z9Q 8TcjpdaG1BH4gA2NT+i+ZJz4XNqkMPa2vbvhcfGFs9Dg7IwabiuunOzh0GQM1S4= =jgci -END PGP SIGNATURE-
Re: [gentoo-user] systemd installation location
On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell li...@sporkbox.us wrote: I'm not affected by anything regarding the /usr switch, but I'd like to have a good talk with the first person who decided a system-critical binary belonged in /usr instead of /bin or /sbin. They've created a mess for every distro and any project that depends on their work. As I've pointed out before: - system-critical is actually dependent on the system. A system dependent on an smb share will find smbmount system critical. One dependent on zfs-fuse will find fuse system critical. With the advent of fuse, arbitrary -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSSMu5AAoJEJUrb08JgYgHFz4H/iyZt6MlTeW702KOlIy2Ydse mzsfiyPfPz8Rbz0Mqp5/17R8aQzOUG4l6dZS7d9HFKuMCG7t+kNZCSvxD69XeTVO tZY6YjHCGQaE6WaAMbiasXfRTeRt4ZDtP5l/lCUsYcTCWN13PyIcHCb5rGNHnHqq J/OcSeF5EoS+G/uSAuzDVaQ5wa0Z0qkqVSqQGjJ5NUHYIA5ZrtYpMNDR+MkFYYAB 7I4JE5kDXRYoBSiLLDb7tI7F1nGogHXxzECmMYW4ZneU0AJwhUAK0kU+oTHY2Z9Q 8TcjpdaG1BH4gA2NT+i+ZJz4XNqkMPa2vbvhcfGFs9Dg7IwabiuunOzh0GQM1S4= =jgci -END PGP SIGNATURE- -- This email is:[ ] actionable [ ] fyi[ ] social Response needed: [ ] yes [ ] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [ ] none
Re: [gentoo-user] systemd installation location
On 09/29/2013 08:17 PM, Mark David Dumlao wrote: On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell li...@sporkbox.us wrote: I'm not affected by anything regarding the /usr switch, but I'd like to have a good talk with the first person who decided a system-critical binary belonged in /usr instead of /bin or /sbin. They've created a mess for every distro and any project that depends on their work. As I've pointed out before: - system-critical is actually dependent on the system. A system dependent on an smb share will find smbmount system critical. One dependent on zfs-fuse will find fuse system critical. With the advent of fuse, arbitrary -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSSMu5AAoJEJUrb08JgYgHFz4H/iyZt6MlTeW702KOlIy2Ydse mzsfiyPfPz8Rbz0Mqp5/17R8aQzOUG4l6dZS7d9HFKuMCG7t+kNZCSvxD69XeTVO tZY6YjHCGQaE6WaAMbiasXfRTeRt4ZDtP5l/lCUsYcTCWN13PyIcHCb5rGNHnHqq J/OcSeF5EoS+G/uSAuzDVaQ5wa0Z0qkqVSqQGjJ5NUHYIA5ZrtYpMNDR+MkFYYAB 7I4JE5kDXRYoBSiLLDb7tI7F1nGogHXxzECmMYW4ZneU0AJwhUAK0kU+oTHY2Z9Q 8TcjpdaG1BH4gA2NT+i+ZJz4XNqkMPa2vbvhcfGFs9Dg7IwabiuunOzh0GQM1S4= =jgci -END PGP SIGNATURE- It's fairly obvious (to me, anyway) that anything mounting a filesystem and making it available is system-critical. I run samba and don't need it for boot, but like you said, someone may need that. I wouldn't see a problem with smbmount being in /bin. FUSE deserves similar treatment. LVM's another that probably deserves special treatment.
Re: [gentoo-user] systemd installation location
On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell li...@sporkbox.us wrote: I'm not affected by anything regarding the /usr switch, but I'd like to have a good talk with the first person who decided a system-critical binary belonged in /usr instead of /bin or /sbin. They've created a mess for every distro and any project that depends on their work. (sorry for the previous post, accidentally clicked somewhere onscreen) As I've pointed out before: 1) system-critical is actually dependent on the system. A system dependent on an smb share will find smbmount system critical. One dependent on zfs-fuse will find fuse system critical. With the advent of fuse, some filesystem that depends on an arbitrary user program will find that system-critical. While this works for for 99.(99?)% of user systems out there, FHS is supposed to be targetting all of them, and so it fails in principle in that respect. I remember making a lengthy thread on this mailing list challenging how FHS defined this and it appeared that nobody could make a defense. 2) the reality is, it's not just binaries even. There are some things that binaries depend on, that in theory should be in /. For example, the hwid database, or libraries. Libraries make for a complex problem, because /usr is supposed to be network-sharable. Any libraries your programs depend on can't simply just be pushed to /, because then there'd be the chance that the programs and their libraries were not in sync. I made a handful of criticisms to FHS in that thread before, and nobody was able to mount a suitable defense. The point being, even in principle, separating / and /usr is flaky design at best. That we just so happened to accumulate a number of packages that are historically installed to /usr is a consequence of that. It's not even necessarily the fault of the upstream developer, who's not supposed to care so much which PREFIX they install to, or the distro packager, who can't yet predict how the user will tailor their system. If you were in the shoes of the ebuild packagers, you would be hard-pressed to predict which packages belong in the / PREFIX and which ones in /usr PREFIX, 100 times out of 100. But you need 100 times out of 100 or you'll get people whining that they can't boot or whining that they need to do some migration. That's why / and /usr separation is broken. -- This email is:[ ] actionable [x] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] systemd installation location
On 09/29/2013 08:40 PM, Mark David Dumlao wrote: On Mon, Sep 30, 2013 at 8:54 AM, Daniel Campbell li...@sporkbox.us wrote: I'm not affected by anything regarding the /usr switch, but I'd like to have a good talk with the first person who decided a system-critical binary belonged in /usr instead of /bin or /sbin. They've created a mess for every distro and any project that depends on their work. (sorry for the previous post, accidentally clicked somewhere onscreen) As I've pointed out before: 1) system-critical is actually dependent on the system. A system dependent on an smb share will find smbmount system critical. One dependent on zfs-fuse will find fuse system critical. With the advent of fuse, some filesystem that depends on an arbitrary user program will find that system-critical. While this works for for 99.(99?)% of user systems out there, FHS is supposed to be targetting all of them, and so it fails in principle in that respect. I remember making a lengthy thread on this mailing list challenging how FHS defined this and it appeared that nobody could make a defense. 2) the reality is, it's not just binaries even. There are some things that binaries depend on, that in theory should be in /. For example, the hwid database, or libraries. Libraries make for a complex problem, because /usr is supposed to be network-sharable. Any libraries your programs depend on can't simply just be pushed to /, because then there'd be the chance that the programs and their libraries were not in sync. Libraries were one of my concerns when I was replying. I thought to myself, Well damn, won't shared libraries make this even more difficult? Perhaps it's a case for static-linked core binaries. :) Anyway, I'm not in favor of FHS _per se_, but it sounds pretty reasonable to have some semblance of order among where different parts of a system go. Shoving everything into /usr and symlinking everything else seems like a stop-gap or good-enough solution that came about due to ignoring the existing standard (FHS) and refusing to try to change it. I could be wrong, though. My point is I'm not dogmatic about it; I just think that if the FOSS community were willing, a better solution could be crafted. I made a handful of criticisms to FHS in that thread before, and nobody was able to mount a suitable defense. The point being, even in principle, separating / and /usr is flaky design at best. That we just so happened to accumulate a number of packages that are historically installed to /usr is a consequence of that. It's not even necessarily the fault of the upstream developer, who's not supposed to care so much which PREFIX they install to, or the distro packager, who can't yet predict how the user will tailor their system. If you were in the shoes of the ebuild packagers, you would be hard-pressed to predict which packages belong in the / PREFIX and which ones in /usr PREFIX, 100 times out of 100. But you need 100 times out of 100 or you'll get people whining that they can't boot or whining that they need to do some migration. That's why / and /usr separation is broken. I agree, but perhaps the / and /usr separation is a symptom of a greater problem instead of being the problem in and of itself. Like Inception, maybe we need to go further. :P
Re: [gentoo-user] systemd installation location
On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell li...@sporkbox.us wrote: It's fairly obvious (to me, anyway) that anything mounting a filesystem and making it available is system-critical. I run samba and don't need it for boot, but like you said, someone may need that. I wouldn't see a problem with smbmount being in /bin. FUSE deserves similar treatment. LVM's another that probably deserves special treatment. If you allow FUSE you've already failed, because arbitrary programs can be required by FUSE filesystems. Suddenly your ssh client should be pushed to /, or your telnet, or rsync, or ftp. -- This email is:[ ] actionable [x] fyi[ ] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] systemd installation location
On 09/29/2013 08:51 PM, Mark David Dumlao wrote: On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell li...@sporkbox.us wrote: It's fairly obvious (to me, anyway) that anything mounting a filesystem and making it available is system-critical. I run samba and don't need it for boot, but like you said, someone may need that. I wouldn't see a problem with smbmount being in /bin. FUSE deserves similar treatment. LVM's another that probably deserves special treatment. If you allow FUSE you've already failed, because arbitrary programs can be required by FUSE filesystems. Suddenly your ssh client should be pushed to /, or your telnet, or rsync, or ftp. FUSE is that lenient with what it can use to mount with? o_O
Re: [gentoo-user] systemd installation location
On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell li...@sporkbox.us wrote: Anyway, I'm not in favor of FHS _per se_, but it sounds pretty reasonable to have some semblance of order among where different parts of a system go. Shoving everything into /usr and symlinking everything else seems like a stop-gap or good-enough solution that came about due to ignoring the existing standard (FHS) and refusing to try to change it. I could be wrong, though. My point is I'm not dogmatic about it; I just think that if the FOSS community were willing, a better solution could be crafted. It's true that it's nice to have a semblance of order where different parts go. But all libraries and binaries in /usr is also a semblance of order. You don't separate stuff for the sake of separating stuff. You separate them because you have a good reason to separate them. It turns out that there isn't a good reason to separate them, and that there's no way to predictably separate them. Mushing them together isn't just a stop-gap or good-enough solution. The idea of keeping system-critical separate from non-critical was not maintainable in the long run to begin with. If you were in the shoes of the ebuild packagers, you would be hard-pressed to predict which packages belong in the / PREFIX and which ones in /usr PREFIX, 100 times out of 100. But you need 100 times out of 100 or you'll get people whining that they can't boot or whining that they need to do some migration. That's why / and /usr separation is broken. I agree, but perhaps the / and /usr separation is a symptom of a greater problem instead of being the problem in and of itself. Like Inception, maybe we need to go further. :P The greater problem is what I'm pointing out already. Even in principle, you just can't predict which files belong in /. It's always been a case-by-case, system-by-system thing, and it just so happens that 99.9xxx% of the cases are the same. Distro packagers, however, have to decide for 100% of the cases. So they're going to end up making weird decisions that are easy for you to second-guess but are actually tough. If you want to solve the hard problem, you want to create a tool that will automate / and /usr migrations. Portage has to be aware of the tool and maybe 100% of ebuilds will have to be rewritten to take advantage of the dynamic prefixes set by the tool. That solves it for good, and you can have your / and /usr separate. But only for gentoo. Every package manager needs to have a similar tool and similar intelligence for that to work. -- This email is:[ ] actionable [x] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] systemd installation location
On 09/29/2013 09:05 PM, Mark David Dumlao wrote: On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell li...@sporkbox.us wrote: Anyway, I'm not in favor of FHS _per se_, but it sounds pretty reasonable to have some semblance of order among where different parts of a system go. Shoving everything into /usr and symlinking everything else seems like a stop-gap or good-enough solution that came about due to ignoring the existing standard (FHS) and refusing to try to change it. I could be wrong, though. My point is I'm not dogmatic about it; I just think that if the FOSS community were willing, a better solution could be crafted. It's true that it's nice to have a semblance of order where different parts go. But all libraries and binaries in /usr is also a semblance of order. You don't separate stuff for the sake of separating stuff. You separate them because you have a good reason to separate them. It turns out that there isn't a good reason to separate them, and that there's no way to predictably separate them. Mushing them together isn't just a stop-gap or good-enough solution. The idea of keeping system-critical separate from non-critical was not maintainable in the long run to begin with. If separating them was unmaintainable, why bother with /bin and /sbin at all, then? If /usr is essentially replacing what / was originally, it's hard to take any filesystem standard seriously and we return to chaos. What was /usr's original purpose? I'm not really in favor of the separation or the merging; I'm in favor of what makes sense. For now, shoving things into /usr is practical because most other software does it. But that's following a trend. It's become *de facto* standard instead of a well-designed, well-reasoned standard. If the change to /usr was brought about because the FHS has holes in it, why not draft a new FHS completely from the ground up? Sometimes a vast rewrite is necessary in a standard, and the new standard could address modern challenges. If you were in the shoes of the ebuild packagers, you would be hard-pressed to predict which packages belong in the / PREFIX and which ones in /usr PREFIX, 100 times out of 100. But you need 100 times out of 100 or you'll get people whining that they can't boot or whining that they need to do some migration. That's why / and /usr separation is broken. I agree, but perhaps the / and /usr separation is a symptom of a greater problem instead of being the problem in and of itself. Like Inception, maybe we need to go further. :P The greater problem is what I'm pointing out already. Even in principle, you just can't predict which files belong in /. It's always been a case-by-case, system-by-system thing, and it just so happens that 99.9xxx% of the cases are the same. Distro packagers, however, have to decide for 100% of the cases. So they're going to end up making weird decisions that are easy for you to second-guess but are actually tough. If you want to solve the hard problem, you want to create a tool that will automate / and /usr migrations. Portage has to be aware of the tool and maybe 100% of ebuilds will have to be rewritten to take advantage of the dynamic prefixes set by the tool. That solves it for good, and you can have your / and /usr separate. But only for gentoo. Every package manager needs to have a similar tool and similar intelligence for that to work. I agree, but I don't see a tool like that coming up. Enforcing a /usr merge and in edge cases forcing initramfs is the right *practical* solution, but I don't think it solves the greater problem, which is social and organizational. It may not even be a solvable problem, given how vast and diverse the FOSS world is. But maybe discussion on it can still be insightful, even if it can't be fruitful.
Re: [gentoo-user] systemd installation location
On Mon, Sep 30, 2013 at 10:01 AM, Daniel Campbell li...@sporkbox.us wrote: On 09/29/2013 08:51 PM, Mark David Dumlao wrote: On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell li...@sporkbox.us wrote: It's fairly obvious (to me, anyway) that anything mounting a filesystem and making it available is system-critical. I run samba and don't need it for boot, but like you said, someone may need that. I wouldn't see a problem with smbmount being in /bin. FUSE deserves similar treatment. LVM's another that probably deserves special treatment. If you allow FUSE you've already failed, because arbitrary programs can be required by FUSE filesystems. Suddenly your ssh client should be pushed to /, or your telnet, or rsync, or ftp. FUSE is that lenient with what it can use to mount with? o_O Fuse is filesystems in userspace. The hard problem that isn't obvious here, is that anybody can come up with a userspace filesystem, and there is ZERO intelligence in the package manager that some filesystem is dependent on some userspace logic. for example, there's a filesystem called sshfs. It allows you to view an ssh connection as a directory. sshfs itself could be in /, but it depends on ssh and its libraries, which are normally in /usr. Now what do you do? Just to support sshfs, you have to move or copy all those programs to /. Portage doesn't know this. Ebuilds don't know this. Manual compiles don't know this. What should the ssh packagers do? What should the fuse-sshfs packagers do? What should users who are manually rolling out sshfs do? How about when you develop the next revolutionary crazy filesystem that allows you to view emacs sessions as directories? What should the emacs packagers do? What should the fuse-emacsfs packagers do? What should users manually rolling out that do? You want to automatically version /etc using some filesystem that uses a git backend (I'll call it gitfs). What should git packagers do? What should fuse-gitfs packagers do? etc How about svnfs? hgfs? bzrfs? scpfs? ... -- This email is:[ ] actionable [x] fyi[ ] social Response needed: [ ] yes [ ] up to you [x] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] systemd installation location
On 09/29/2013 09:25 PM, Mark David Dumlao wrote: On Mon, Sep 30, 2013 at 10:01 AM, Daniel Campbell li...@sporkbox.us wrote: On 09/29/2013 08:51 PM, Mark David Dumlao wrote: On Mon, Sep 30, 2013 at 9:22 AM, Daniel Campbell li...@sporkbox.us wrote: It's fairly obvious (to me, anyway) that anything mounting a filesystem and making it available is system-critical. I run samba and don't need it for boot, but like you said, someone may need that. I wouldn't see a problem with smbmount being in /bin. FUSE deserves similar treatment. LVM's another that probably deserves special treatment. If you allow FUSE you've already failed, because arbitrary programs can be required by FUSE filesystems. Suddenly your ssh client should be pushed to /, or your telnet, or rsync, or ftp. FUSE is that lenient with what it can use to mount with? o_O Fuse is filesystems in userspace. The hard problem that isn't obvious here, is that anybody can come up with a userspace filesystem, and there is ZERO intelligence in the package manager that some filesystem is dependent on some userspace logic. for example, there's a filesystem called sshfs. It allows you to view an ssh connection as a directory. sshfs itself could be in /, but it depends on ssh and its libraries, which are normally in /usr. Now what do you do? Just to support sshfs, you have to move or copy all those programs to /. Portage doesn't know this. Ebuilds don't know this. Manual compiles don't know this. What should the ssh packagers do? What should the fuse-sshfs packagers do? What should users who are manually rolling out sshfs do? How about when you develop the next revolutionary crazy filesystem that allows you to view emacs sessions as directories? What should the emacs packagers do? What should the fuse-emacsfs packagers do? What should users manually rolling out that do? You want to automatically version /etc using some filesystem that uses a git backend (I'll call it gitfs). What should git packagers do? What should fuse-gitfs packagers do? etc How about svnfs? hgfs? bzrfs? scpfs? ... Ah, I wasn't aware of how flexible and arbitrary fuse could be. In that case I'd probably keep it out of /bin for the reasons you outlined. But that doesn't solve the problem of what if people want to boot with fuse?. At least, not without an initramfs. And then we've created a similar problem. If the proposed solution is all binaries and libraries in the same root/prefix directory, then why call it /usr? It has little to do with users if it's nothing but binaries, libraries, etc. In addition, would a local directory still be under this, for user-compiled programs not maintained by the PM? Or does that deserve a different top level directory? Then there's /opt, whose purpose I'm still not sure of. This is strengthening the idea that something new should be thought up and drafted. Not necessarily by us at Gentoo, but *somebody*. If I was crazy and knowledgeable enough I'd volunteer myself.
Re: [gentoo-user] systemd installation location
On Mon, Sep 30, 2013 at 10:15 AM, Daniel Campbell li...@sporkbox.us wrote: On 09/29/2013 09:05 PM, Mark David Dumlao wrote: On Mon, Sep 30, 2013 at 9:50 AM, Daniel Campbell li...@sporkbox.us wrote: Anyway, I'm not in favor of FHS _per se_, but it sounds pretty reasonable to have some semblance of order among where different parts of a system go. Shoving everything into /usr and symlinking everything else seems like a stop-gap or good-enough solution that came about due to ignoring the existing standard (FHS) and refusing to try to change it. I could be wrong, though. My point is I'm not dogmatic about it; I just think that if the FOSS community were willing, a better solution could be crafted. It's true that it's nice to have a semblance of order where different parts go. But all libraries and binaries in /usr is also a semblance of order. You don't separate stuff for the sake of separating stuff. You separate them because you have a good reason to separate them. It turns out that there isn't a good reason to separate them, and that there's no way to predictably separate them. Mushing them together isn't just a stop-gap or good-enough solution. The idea of keeping system-critical separate from non-critical was not maintainable in the long run to begin with. If separating them was unmaintainable, why bother with /bin and /sbin at all, then? If /usr is essentially replacing what / was originally, it's hard to take any filesystem standard seriously and we return to chaos. The people that write software and systems and standards, etc are human. Give them a break. They did the best they could. What was /usr's original purpose? /usr was originally the home directory. Programs were moved there because Unix didn't fit into a single disk. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html If the change to /usr was brought about because the FHS has holes in it, why not draft a new FHS completely from the ground up? At the end of the day, a standard is just a doc that people don't read. Part of the reason why FHS was successful was because it was more than just a prescriptive standard. Most of the rules in it had rationales written based on existing practices. In other words, writing a new FHS isn't going to do a damned thing to fix the problems people have had so far, and there's the likelihood that people won't follow it anyways. Heck, just look at /usr/portage. Portage, or at least the distfiles, in no way, shape, or form, belongs in /usr. It's just there because that's how it was done before. THE way to rewrite FHS is to change existing practice. And if the big distros agree on it, the existing practice gets codified into a standard. -- This email is:[ ] actionable [x] fyi[ ] social Response needed: [ ] yes [ ] up to you [x] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] systemd installation location
On Sep 30, 2013 9:31 AM, Daniel Campbell li...@sporkbox.us wrote: --- le snip --- If the proposed solution is all binaries and libraries in the same root/prefix directory, then why call it /usr? My question exactly. Why install to /usr at all, leaving /bin and /sbin a practically empty directory containing symlinks only? I mean, I have no quarrel with / and /usr separation, having had them in the same partition for ages... but why not do it the other way around, i.e., put everything in / and have /usr be a container for symlinks? It has little to do with users if it's nothing but binaries, libraries, etc. In addition, would a local directory still be under this, for user-compiled programs not maintained by the PM? Or does that deserve a different top level directory? Then there's /opt, whose purpose I'm still not sure of. This is strengthening the idea that something new should be thought up and drafted. IIRC, it was supposed to contain third-party binaries, i.e., things not available in a distro's package repo. Thus, when one's tired of a third-party binary package, he/she can just delete the relevant directory under /opt, because the third-party package might not be uninstallable using the distro's package management system (if any). Of course, he/she might have to clean up the leftover crud in /etc, but those are usually small and can safely be ignored. Except perhaps startup initscripts. Not necessarily by us at Gentoo, but *somebody*. If I was crazy and knowledgeable enough I'd volunteer myself. Rgds, --
Re: [gentoo-user] systemd installation location
On Mon, Sep 30, 2013 at 12:13 PM, Pandu Poluan pa...@poluan.info wrote: On Sep 30, 2013 9:31 AM, Daniel Campbell li...@sporkbox.us wrote: --- le snip --- If the proposed solution is all binaries and libraries in the same root/prefix directory, then why call it /usr? My question exactly. Why install to /usr at all, leaving /bin and /sbin a practically empty directory containing symlinks only? I mean, I have no quarrel with / and /usr separation, having had them in the same partition for ages... but why not do it the other way around, i.e., put everything in / and have /usr be a container for symlinks? If the binaries and libraries are kept together, /usr can actually be made reliably sharable, independent of local settings in /etc. It can also be made properly readonly, or otherwise use different mount options than /. Most of the things in /usr have the same read-write characteristics. They're mostly chunks of 1-20mb in size that are read very often and written very rarely. You can pick a filesystem with options that optimized for that. They're also non-data, so the root of that tree has an entirely different backup priority than /etc or /home. And then there are directories in /usr that don't exist in /. Are you gonna link them too? So we have /share now? Or /src? Seems to me that it makes less mess to move / to /usr than vice versa. -- This email is:[ ] actionable [x] fyi[ ] social Response needed: [ ] yes [ ] up to you [x] no Time-sensitive: [ ] immediate[ ] soon [x] none
