Re: [lfs-support] unified usr directory

2015-08-25 Thread Paul Rogers
> That said, there is no good reason to undo the split. OK, I guess it depends on what one thinks "good" means. But I've never done it for one reason I consider good: by having everything in one partition the free space is all in one "pool", and can be used by any branch. When you're out of spa

Re: [lfs-support] unified usr directory

2015-08-25 Thread Bruce Dubbs
Simon Geard wrote: On Mon, 2015-08-24 at 16:40 -0500, Bruce Dubbs wrote: Also, it goes to the philosophy used by most distros that one size fits all. In other words because 0.01% of systems are clustered, lets make it that way for the other 99.99% of users. Which is entirely reasonable, when

Re: [lfs-support] unified usr directory

2015-08-25 Thread Tim Tassonis
On 25.08.2015 11:07, Simon Kitching wrote: On 08/25/2015 10:36 AM, Simon Geard wrote: On Mon, 2015-08-24 at 15:29 -0500, Bruce Dubbs wrote: If distros like RedHat were really looking for consistency, they would use /bin, /lib, and /sbin, and remove them from /usr. What they really are doing is

Re: [lfs-support] unified usr directory

2015-08-25 Thread Simon Kitching
On 08/25/2015 10:36 AM, Simon Geard wrote: On Mon, 2015-08-24 at 15:29 -0500, Bruce Dubbs wrote: If distros like RedHat were really looking for consistency, they would use /bin, /lib, and /sbin, and remove them from /usr. What they really are doing is trying to make things easier for themselves

Re: [lfs-support] unified usr directory

2015-08-25 Thread Simon Geard
On Mon, 2015-08-24 at 16:40 -0500, Bruce Dubbs wrote: > Also, it goes to the philosophy used by most distros that one size > fits all. In other words because 0.01% of systems are clustered, > lets make it that way for the other 99.99% of users. Which is entirely reasonable, when there's a) a lar

Re: [lfs-support] unified usr directory

2015-08-25 Thread Simon Geard
On Mon, 2015-08-24 at 15:29 -0500, Bruce Dubbs wrote: > If distros like RedHat were really looking for consistency, they > would use /bin, /lib, and /sbin, and remove them from /usr. What > they really are doing is trying to make things easier for themselves > by not being concerned where each p