Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Sat, Mar 17, 2012 at 03:12:11AM -0400, Walter Dnes wrote TOOT!!! (blowing my own horn). See http://www.waltdnes.org/mdev/ for instructions on replacing udev with mdev for simple Gentoo systems. Hopefully more info will start arriving, allowing more complex systems to work with mdev. With more people getting interested, the project has been moved to wiki format https://wiki.gentoo.org/wiki/Mdev to allow more people to contribute. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 04:44:11PM -0400, Richard Yao wrote Busybox is installed as part of the system profile on amd64. You can install mdev by doing this: ln -s /bin/busybox /sbin/mdev The official method is to build busybox with the mdev USE flag. That is the only way that virtual/dev-manager recognizes it, and doesn't try to pull in udev, instead. From the ebuild... RDEPEND=|| ( sys-fs/udev sys-apps/busybox[mdev] sys-fs/devfsd sys-fs/static-dev sys-freebsd/freebsd-sbin ) There is documentation in the busybox GIT for how to use it: http://git.busybox.net/busybox/plain/docs/mdev.txt TOOT!!! (blowing my own horn). See http://www.waltdnes.org/mdev/ for instructions on replacing udev with mdev for simple Gentoo systems. Hopefully more info will start arriving, allowing more complex systems to work with mdev. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 11:01:19PM -0400, Richard Yao wrote: On 03/15/12 22:43, Greg KH wrote: On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote: On 03/15/2012 10:41, Greg KH wrote: There's always mudev if you don't want to run udev, good luck with that. Got a link? We don't have anything matching in the tree, and Google turns up nothing relevant in the first few pages. Sorry, I think it's called 'mdev' and is part of busybox. greg no one asked me to adopt a package, amazing k-h How about app-editors/bvi? A whole separate package for a tool that reimplements 'vim -b' mode? That seems pointless, sorry. At least find a package that people use :) greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/16/12 11:18, Greg KH wrote: At least find a package that people use :) www-client/httrack?
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
Take your pick: http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml On Fri, Mar 16, 2012 at 11:18 AM, Greg KH gre...@gentoo.org wrote: On Thu, Mar 15, 2012 at 11:01:19PM -0400, Richard Yao wrote: On 03/15/12 22:43, Greg KH wrote: On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote: On 03/15/2012 10:41, Greg KH wrote: There's always mudev if you don't want to run udev, good luck with that. Got a link? We don't have anything matching in the tree, and Google turns up nothing relevant in the first few pages. Sorry, I think it's called 'mdev' and is part of busybox. greg no one asked me to adopt a package, amazing k-h How about app-editors/bvi? A whole separate package for a tool that reimplements 'vim -b' mode? That seems pointless, sorry. At least find a package that people use :) greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 06:49 PM, Richard Yao wrote: On 03/14/12 21:06, Zac Medico wrote: On 03/14/2012 05:58 PM, Richard Yao wrote: On 03/14/12 20:36, David Leverton wrote: On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org wrote: It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself. I suggest that you file a bug report regarding this for the Gentoo udev maintainer. RESOLVED:UPSTREAM Lets permit the udev maintainer to do that. :) Bug 398049 can serve well enough. The maintainer said, This should no longer be an issue once we have everyone with separate /usr using an initramfs. [1] [1] https://bugs.gentoo.org/show_bug.cgi?id=398049#c2 -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 06:49 PM, Richard Yao wrote: On 03/14/12 21:06, Zac Medico wrote: On 03/14/2012 05:58 PM, Richard Yao wrote: On 03/14/12 20:36, David Leverton wrote: On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org wrote: It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself. I suggest that you file a bug report regarding this for the Gentoo udev maintainer. RESOLVED:UPSTREAM Lets permit the udev maintainer to do that. :) Bug 398049 can serve well enough. The maintainer said, This should no longer be an issue once we have everyone with separate /usr using an initramfs. [1] [1] https://bugs.gentoo.org/show_bug.cgi?id=398049#c2 -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
Am 15.03.2012 00:37, schrieb Greg KH: Not really, I don't think we support systems without udev anymore, right? And we get away with a lot of these different options at compile time, which makes it easier than what Debian has to handle, so perhaps it's not a fair comparison. Sure Gentoo does support such systems... # equery g virtual/dev-manager * Searching for dev-manager in virtual ... * dependency graph for virtual/dev-manager-0 `-- virtual/dev-manager-0 amd64 `-- sys-fs/udev-171-r5 (sys-fs/udev) amd64 `-- sys-apps/busybox-1.19.3-r1 (sys-apps/busybox) amd64 [mdev] `-- sys-fs/devfsd-1.3.25-r9 (sys-fs/devfsd) [missing keyword] `-- sys-fs/static-dev-0.1 (sys-fs/static-dev) amd64 `-- sys-freebsd/freebsd-sbin-9.0 (sys-freebsd/freebsd-sbin) [missing keyword] [ virtual/dev-manager-0 stats: packages (6), max depth (1) ] /martin
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 11:04, Greg KH wrote: Not always, no, it isn't obvious that something didn't start up correctly, or that it didn't fully load properly. Some programs later on recover and handle things better. I'm well aware of what I run on my own box, and when something isn't running, I figure it out pretty quickly. I tested udev-181 in a Gentoo VM that I put together recently, giving it a separate /usr, and made sure that CONFIG_DEVTMPFS was enbaled. The only service that failed to load properly at startup was udev, specifically because udevadm couldn't locate libkmod (likely because kmod installs into /usr/lib*, which wasn't available yet because I also don't use an initramfs in my kernel). Everything else worked fine, and udev later started properly once localmount was complete. I even tried, out of curiosity, to tweak things and moved udev from sysinit to boot and then to default runlevel. In 'boot', udevadm still fails to load, so no change. In 'default', only net.lo failed because the 'lo' device didn't yet exist until after udev was running. udev itself loaded fine, and the networking scripts restarted themselves. So with the one exception of networking, which in Linux, has never created /dev nodes (has to be some historical piece on why), one almost doesn't need udev at boot to even get things working on a very simple setup like mine. And since udev is the one service that didn't load correctly, one COULD put forth the hypothesis that it is udev that is broken. But I doubt that will get much traction, right? This does lead me to wonder if a light-weight udev could exist that lacks half or more of the functionality of the current udev. I'll be honest, I've only edited my udev rules file once, and that was only when I installed a Sun Happy Meal quad ethernet card in which all four ports utilize the same MAC address and udev doesn't handle this very gracefully (if I had Solaris, I could edit the card's firmware and change this setting). Devtmpfs quite literally handles 98% of my particular usage scenario. Does that apply to everyone? Nope. Just an interesting observation. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, 2012-03-15 at 00:29 +, David Leverton wrote: On 14 March 2012 23:44, Greg KH gre...@gentoo.org wrote: Oh, and somehow consensus will work? No, sorry, it will not. No, logical analysis will, as I said in the rest of my post which you conveniently ignored - either we conclude with evidence that there are no issues, which should settle the matter for reasonable people, or we discover that there are, in which case they have to be dealt with one way or another. I really don't see how anyone can object to that, unless they're worried they won't like the result How about the basic FACT that today, such systems do not work This is debatable at best. You can keep screaming but bluetooth won't work! until you're blue in the face, but that's not relevant at all to people who don't use bluetooth. That's true, but given the need to have a one size fits all boot system(for obvious practical reasons), such boot system needs to work with bluetooth input devices -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 18:14, David Leverton wrote: On 14 March 2012 21:04, Greg KH gre...@gentoo.org wrote: Haveing a separate /usr is wonderful, and once we finish moving /sbin/ and /bin/ into /usr/ it makes even more sense. See the /usr page at fedora for all of the great reasons why this is good. My point was examine, in detail, whether separate-/usr-with-initramfs has any disadvantages compared to separate-/usr-without-initramfs. Either it has, in which case we have a concrete argument against requiring initramfs (albeit possibly one that can be fixed), or it hasn't, which should hopefully convince at least some people to accept it. I went with a split filesystem design when I built my first Gentoo install back in mid 2003 because at the time, both the Gentoo and Debian security guides referenced it as being an option for a more secure system. Specifically so that you could apply mount options to each partition. For example, on /home, you would usually want to do nodev and nosuid, because rarely does a user need the ability to create device nodes and SUID binaries. On /var, nodev, nosuid, and noexec, with the one exception if you ran qmail or a few other packages known to stick executables into /var. For /usr, the guides suggested just nodev, because you rarely, if ever need to create device nodes in /usr. Optionally, you could mount /usr ro and only make it rw if updating packages. You won't find A separate /usr mentioned specifically anymore in either security guide, but I'm sure if you dig on the Wayback Machine (once it comes back online), you can probably find these references. Search from 2003 to 2007. I'm not certain when they were removed. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 18:51, Greg KH wrote: On Wed, Mar 14, 2012 at 10:14:54PM +, David Leverton wrote: On 14 March 2012 21:04, Greg KH gre...@gentoo.org wrote: Haveing a separate /usr is wonderful, and once we finish moving /sbin/ and /bin/ into /usr/ it makes even more sense. See the /usr page at fedora for all of the great reasons why this is good. My point was examine, in detail, whether separate-/usr-with-initramfs has any disadvantages compared to separate-/usr-without-initramfs. Oh, that's simple, separate-/usr-without-initramfs will not work and will not be supported :) Not supported by whom? udev? Or Gentoo? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/2012 07:20, Stelian Ionescu wrote: On Thu, 2012-03-15 at 00:29 +, David Leverton wrote: On 14 March 2012 23:44, Greg KH gre...@gentoo.org wrote: Oh, and somehow consensus will work? No, sorry, it will not. No, logical analysis will, as I said in the rest of my post which you conveniently ignored - either we conclude with evidence that there are no issues, which should settle the matter for reasonable people, or we discover that there are, in which case they have to be dealt with one way or another. I really don't see how anyone can object to that, unless they're worried they won't like the result How about the basic FACT that today, such systems do not work This is debatable at best. You can keep screaming but bluetooth won't work! until you're blue in the face, but that's not relevant at all to people who don't use bluetooth. That's true, but given the need to have a one size fits all boot system(for obvious practical reasons), such boot system needs to work with bluetooth input devices With Gentoo, that's really only for the preliminary installation. Once you get the system up and running, you're free to modify it in whatever way pleases you. For binary distributions, especially those that deal in the enterprise sector, the one-size-fits-all approach is damn near mandatory because most admins run with the distro-provided kernel and typically are not custom compiling them. But we're not a binary distro. We're a source-based distro, although it's possible to run Gentoo in a binary fashion. As such, we're not necessarily beholden to the one-size-fits-all approach. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 20:45, Zac Medico wrote: On 03/14/2012 05:36 PM, David Leverton wrote: On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org wrote: It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself. You're pointing your finger at udev, but the udev change is just a symptom of a more general shift away from supporting the / is a self-contained boot disk that is independent of /usr use case. I think it's better to say that udev is one of the more important components of your average Linux system that's decided to support a unified root + /usr filesystem. If we were looking at some non-critical, non-boot service that made this decision, then we wouldn't be having this discussion. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 7:04 AM, Joshua Kinard ku...@gentoo.org wrote: This does lead me to wonder if a light-weight udev could exist that lacks half or more of the functionality of the current udev. I'll be honest, I've only edited my udev rules file once, and that was only when I installed a Sun Happy Meal quad ethernet card in which all four ports utilize the same MAC address and udev doesn't handle this very gracefully (if I had Solaris, I could edit the card's firmware and change this setting). You know - I had a similar issue, but with a pair of PL2303 USB RS232 interfaces. That makes me wonder if there is a possible way to enhance udev to better handle situations where devices have no unique ID and thus tend to be difficult to access consistently across reboots. In my case I had to hack a rule so that I got a symlink if the device was in a specific USB slot. Use case is controlling tuners for mythtv. No doubt a simpler 80% solution could be created for udev, and likely it would be easier to cut down on its dependencies as a result. However, the other 20% of users will still need the more complete solution. Big distros that want to support lots of hardware with a one-size-fits-all configuration will just deploy that complete solution everywhere, which means that the only people maintaining the simple solution would be people who like to tailor each system. For most of the more enterprise-y OS providers (ie the ones with money to pay devs), one-size-fits-all is a lot more sustainable. You won't find an edition of MS Windows that works only on PCs without scanners and sound but uses 50MB less RAM, for example. Sure, we don't have the same constraints as the enterprise-y distros, but we do have the constraint that if we want to do things differently we will spend a lot of time patching what we could otherwise simply reuse as-is. I don't think that split filesystem installs are going away anytime soon. In fact, when btrfs is finally mature we might see them blossum. Using subvolumes you could have more granular snapshotting and mount options, while still maintaining a shared disk space pool (with granular quotas). If everything the distro is likely to mangle is in a few subvolumes you can reverts snapshots on those without losing changes in other subvolumes if you ran in production before deciding to revert. That gets you a lot more flexibility than a single snapshot on root - especially in terms of recovery time (you can still copy files between snapshots if you only snapshotted root - in fact with reflinks this is very fast). Rich
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 19:27, Richard Yao wrote: On 03/14/12 18:49, Greg KH wrote: On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote: With that said, I have a few questions: 1. Why does no one mention the enterprise use case at all? It has been pointed out before, why constantly repeat ourselves. Simple. No one has documented it. A webpage that makes a few vague references to enterprise use does not count as documentation. I happened to figure it out when trying to rationalize why anyone would want this, but this is hardly obvious to those that imagine a computer as a self-sufficient single disk system. You'll also find a lot of enterprise-specific decisions went into IPv6, without necessarily stating them as being enterprise-specific. I.e., the requirement for Unique Local Addresses, which are IPv6's idea of RFC1918, required to be globally-unique. When I quizzed someone about this one (I think it was on ServerFault somewhere), I was basically told that IPv6 is not for home use. 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device? unionfs is still a work in progress, some systems can't do that yet. That sounds like something that needs to be fixed. I thought UnionFS died? Or was better handled by other tricks involving filesystem overlays? 3. Why not let the users choose where these directories go and support both locations? Because a plethera of options is a sure way to make sure that half of them don't work over the long run. We aren't Debian here people, we don't support everything :) Gentoo provides far more options than Debian does, so this seems somewhat contradictory to me. Agreed. Debian is focused on an entirely different model of building a Linux system, thus they have a narrower dependency chain and you sometimes have to include packages that you don't necessarily care for because they're required by a package that you do want to use. We have USE flags to resolve that issue. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 19:37, Greg KH wrote: On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote: 3. Why not let the users choose where these directories go and support both locations? Because a plethera of options is a sure way to make sure that half of them don't work over the long run. We aren't Debian here people, we don't support everything :) Gentoo provides far more options than Debian does, so this seems somewhat contradictory to me. Not really, I don't think we support systems without udev anymore, right? And we get away with a lot of these different options at compile time, which makes it easier than what Debian has to handle, so perhaps it's not a fair comparison. I already looked in the tree and nothing really stands out as a suitable replacement for /dev management. mdev might, but it's part of busybox and not standalone as far as I know (at least, we don't have an independent package for it). For my simplistic setups, I apparently only need udev just to setup the networking interfaces, because Linux has never created /dev/lo or /dev/ethX (nor does it even support them). Thus, CONFIG_DEVTMPFS can't set those up at all. If I could find a small utility that was like udev and which took care of that one little element, I think I'd be able to boot my systems up just fine. Is it futureproof? Not really. I imagine plugging USB mass storage devices into a udevless system might be problematic. Food for thought. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 16:55, Zac Medico wrote: Deprecation of this practice would mean that people could type /bin/command instead of /usr/bin/command in situations where absolute paths are necessary. We could symlink things in /usr to rootfs for compatibility with legacy software. In a more extreme case, we could symlink /usr to /, which would make plenty of sense given that we do not need a separate /usr at all. I'm not seeing any compelling benefits here that would justify a lack of conformity with other *nix distros. It seems almost as though it's an attempt to be different for the sake of being different, perhaps a symptom of something like NIH syndrome. Gentoo, by its very nature, has always been regarded as somewhat non-conformist. When Gentoo first popped onto the scene, most other distros didn't do colors in the terminal. We did. And it all branches out from there. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 13:59, Rich Freeman wrote: On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico zmed...@gentoo.org wrote: On 03/14/2012 10:11 AM, Maxim Kammerer wrote: What's wrong with: * having an early mounts list file * having an early modules list file * init system in early boot (e.g., OpenRC in init.sh) loading early modules and mounting early mounts from /etc/fstab You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init. Other that that, it sounds like a perfect solution if you're in the I'd rather die than use an initramfs camp. Well, anybody is welcome to create any replacement/addition for (/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it good enough, perhaps others will even use it. Beyond that, anything else is just a suggestion. In the end the folks writing udev and systemd are writing code, which gets them a lot further than emails do... :) Debian has a small, yet fairly unique little package called file-rc that replaces their more traditional init system with a single text file, /etc/runlevels, to manage system services. A small utility runs that parses the text file and sets up the /etc/rc.x symlinks for you, based on that file. Fairly novel little package. Wholly-incompatible with Gentoo's system, without fully replacing OpenRC, but I would actually be interested in seeing something like this on Gentoo (such as something that simply parses and executes rc-update to change things). http://packages.debian.org/squeeze/file-rc -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/2012 08:30, Rich Freeman wrote: You know - I had a similar issue, but with a pair of PL2303 USB RS232 interfaces. That makes me wonder if there is a possible way to enhance udev to better handle situations where devices have no unique ID and thus tend to be difficult to access consistently across reboots. In my case I had to hack a rule so that I got a symlink if the device was in a specific USB slot. Use case is controlling tuners for mythtv. I use a ton of the pl2303-based devices, too. Except I'm usually in Windows with them, so I just have to deal with Window's oddball way of renumbering them sometimes when I unplug one and plug it right back into the same USB slot (i.e., I lost COM11, and it's now COM14, which, ironically, is outside the range of TeraTerm) No doubt a simpler 80% solution could be created for udev, and likely it would be easier to cut down on its dependencies as a result. However, the other 20% of users will still need the more complete solution. Big distros that want to support lots of hardware with a one-size-fits-all configuration will just deploy that complete solution everywhere, which means that the only people maintaining the simple solution would be people who like to tailor each system. That, or udev making more of its functionality optional via its build system (does it use autotools and configure, I never looked, to be honest?). This would allow additional USE flags to be added to enable or disable additional functionality as needed. For most of the more enterprise-y OS providers (ie the ones with money to pay devs), one-size-fits-all is a lot more sustainable. You won't find an edition of MS Windows that works only on PCs without scanners and sound but uses 50MB less RAM, for example. Funny, but as much as I am against Windows on a server, Windows Server is easier to turn off unneeded stuff than RHEL5 is. Windows Server comes with audio and TWAIN/IMAPI components disabled (or out right missing -- you have to add them back in through server manager). But try to remove features like sound, CD burning, various media players, text-to-speech, etc, from a fresh RHEL5 install, and you're in for a fight. It's not necessarily RHEL's fault, but more Gnome's fault because of the massive about of interdependency that you get with Gnome, and the fact RH chose to just not bother with it and build in a ton of stuff by default. Ditto for an install of OpenSolaris that I did. I don't think that split filesystem installs are going away anytime soon. In fact, when btrfs is finally mature we might see them blossum. Using subvolumes you could have more granular snapshotting and mount options, while still maintaining a shared disk space pool (with granular quotas). If everything the distro is likely to mangle is in a few subvolumes you can reverts snapshots on those without losing changes in other subvolumes if you ran in production before deciding to revert. That gets you a lot more flexibility than a single snapshot on root - especially in terms of recovery time (you can still copy files between snapshots if you only snapshotted root - in fact with reflinks this is very fast). ZFS encourages creating volumes and filesystems en masse. Right down to a separate ZFS mount for each user's home directory under /home, and /home itself is a mount point. So yeah, Btrfs, ZFS, etc...get an FS like those two which not only encourage dozens of mount points, but which seamlessly hide all the dirty details from you (and the users), and issues like this will simply vanish into thin air. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 03/14/2012 16:10, Kent Fredric wrote: Considering this pretty much eliminates using / for anything useful, we might as well rename /usr /c Even if it /is/ just to confuse the windows crowd =) Unless you're one of those that installs Windows into D:\ :) I'd say call it /sys for NetWare's old SYS:\ volume, but that's already taken by sysfs. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 12:28, Matthew Summers wrote: Gentoo provides a solution with genkernel, dracut provides a solution, even the linux kernel itself provides a solution (in my view the easiest solution at that). The kernel doesn't appear to create the networking interfaces, though. CONFIG_DEVTMPFS is only going to handle things that physically exist within /dev, of which, ethernet devices have always been excluded. If that can get fixed in some fashion, then devtmpfs pretty much does make this a non-issue. I just wanted to drop this simple fact in there. This has been coming for several years now AND the linux kernel has been using an initramfs for every boot, every time for a long time now, all 2.6 and up as I understand it. If the initramfs is empty, well the kernel is smart enough to fall back on legacy boot process. initramfs was introduced in 2.6.10, and prior to that, only a handful of architectures even supported a built-in initrd (MIPS was one, and it wasn't very pretty or functional). I believe other distros required the bootloader to pass the initrd to them somehow, but having never used an initrd in that fashion, I don't know for certain. But yes, if you enable CONFIG_IKCONFIG_PROC, you're essentially turning on (or utilizing) an initramfs accessible via /proc. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 14:56, Zac Medico wrote: On 03/14/2012 11:36 AM, Maxim Kammerer wrote: On Wed, Mar 14, 2012 at 19:58, Matthew Summers quantumsumm...@gentoo.org wrote: Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. There is nothing bad about initramfs. I think that you are misreading the arguments above. Whatever the arguments may be, the whole discussion boils down to the fact that the only people who seem to have a problem are those that have a separate /usr partition and simultaneously refuse to use an initramfs. I refuse to use an initramfs as this point in time because I haven't had to use one in the past 10 years to get my Gentoo installs to boot. Right now, all three active Gentoo installs that I have (x86_64, Vbox, MIPS) boot *fine* with a separate /usr and no initramfs. That, in my opinion, is not broke, despite statements made to the contrary. It only became broke when individuals not involved with Gentoo declared it to be broke, and then back it up with use-case scenarios that are really only applicable to their distribution of choice. I'm not saying that I'll continue to not use an initramfs, but I would like for some Gentoo-specific reasoning to be offered as to why we have to follow along with this change. Constantly referring to Fedora or Freedesktop websites for their reasoning doesn't matter to me. I don't use Fedora nor do I use X11 (at least the server. I tunnel 2-5 X11 apps over SSH, however). -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 19:44, Greg KH wrote: Oh, and somehow consensus will work? No, sorry, it will not. If compelling arguments were used, yes, you can sometimes trigger people to change their minds and arrive at a consensus. But outright dismissing them as if that will make them disappear is what won't work. So it's not a we know best, it's a it will not properly work otherwise. Udev is the only package I have installed in my VM setup that fails at boot with a separate /usr and no initramfs. And that isn't even a fatal failure, but it is a failure none the less, at least by virtue of OpenRC flagging the fact that udev returned an error code. Everything else works fine. But it's not udev that is broke, is it? It's my setup, right? I've been wrong for the last 10 years? Why was this ever referenced then in the Security Handbook? See Code Listing 1.1: http://www.gentoo.org/doc/en/security/security-handbook.xml?part=1chap=4 It is strange to watch people somehow think that if they complain enough, or feel strongly enough, something is going to change here to make this basic fact go away. It's human nature to complain or otherwise voice dissent, especially when someone or something comes along and declares that what used to JustWork(TM) now NoLongerWorks(TM). Does that mean my dissent matters? Probably not. But that's not going to stop me from trying. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 07:04:52AM -0400, Joshua Kinard wrote: Devtmpfs quite literally handles 98% of my particular usage scenario. Does that apply to everyone? Nope. Just an interesting observation. devtmpfs does not handle device permissions. As for a smaller udev, feel free to try, please realize that this that is what udev used to be, before it was fixed to work properly. udev is very small and compact, but patches to make it smaller are always welcome. There's always mudev if you don't want to run udev, good luck with that. greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 08:30:49AM -0400, Rich Freeman wrote: You know - I had a similar issue, but with a pair of PL2303 USB RS232 interfaces. That makes me wonder if there is a possible way to enhance udev to better handle situations where devices have no unique ID and thus tend to be difficult to access consistently across reboots. In my case I had to hack a rule so that I got a symlink if the device was in a specific USB slot. Use case is controlling tuners for mythtv. Why not use the links in /dev/serial/ which are there for this specific reason? greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/2012 05:27 AM, Joshua Kinard wrote: On 03/14/2012 20:45, Zac Medico wrote: On 03/14/2012 05:36 PM, David Leverton wrote: On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org wrote: It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself. You're pointing your finger at udev, but the udev change is just a symptom of a more general shift away from supporting the / is a self-contained boot disk that is independent of /usr use case. I think it's better to say that udev is one of the more important components of your average Linux system that's decided to support a unified root + /usr filesystem. If we were looking at some non-critical, non-boot service that made this decision, then we wouldn't be having this discussion. They're intertwined though, since having a unified root implies that there is no support for the / is a self-contained boot disk that is independent of /usr use case, and the bulk of people's opposition to having a unified root seems to stem from their dependence on the / is a self-contained boot disk that is independent of /usr use case. So, the question at the heart of the whole discussion is: Should we support the / is a self-contained boot disk that is independent of /usr use case? -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 10:42 AM, Greg KH gre...@gentoo.org wrote: Why not use the links in /dev/serial/ which are there for this specific reason? # ls -l /dev/serial ls: cannot access /dev/serial: No such file or directory Something in a newer version of udev perhaps? Or would my defining my own symlinks end up overriding some rule elsewhere. I just added these lines to /etc/udev/rules.d: SUBSYSTEM==tty, DRIVERS==pl2303, KERNELS==4-1:1.0, KERNEL==ttyUSB*, SYMLINK=mythser/rca1 SUBSYSTEM==tty, DRIVERS==pl2303, KERNELS==3-3:1.0, KERNEL==ttyUSB*, SYMLINK=mythser/rca2 Rich
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/12 08:40, Joshua Kinard wrote: I already looked in the tree and nothing really stands out as a suitable replacement for /dev management. mdev might, but it's part of busybox and not standalone as far as I know (at least, we don't have an independent package for it). Busybox is installed as part of the system profile on amd64. You can install mdev by doing this: ln -s /bin/busybox /sbin/mdev There is documentation in the busybox GIT for how to use it: http://git.busybox.net/busybox/plain/docs/mdev.txt signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/12 08:34, Joshua Kinard wrote: On 03/14/2012 19:27, Richard Yao wrote: On 03/14/12 18:49, Greg KH wrote: 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device? unionfs is still a work in progress, some systems can't do that yet. That sounds like something that needs to be fixed. I thought UnionFS died? Or was better handled by other tricks involving filesystem overlays? I know the UnionFS developer offline. I will ask him what the status of unionFS is the next time I see him. :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 22:45, Richard Yao r...@cs.stonybrook.edu wrote: I know the UnionFS developer offline. I will ask him what the status of unionFS is the next time I see him. :) Unionfs patchset is regularly released for new kernels, and bugs are fixed. I wouldn't call the project dead, I would call it mature and stable. I am not aware of the current state of affairs wrt. Unionfs vs. aufs, and whether the propaganda at unionfs.org still holds water, though. Too bad that there is no stacking filesystem in the mainline kernel. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/2012 10:41, Greg KH wrote: There's always mudev if you don't want to run udev, good luck with that. Got a link? We don't have anything matching in the tree, and Google turns up nothing relevant in the first few pages. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 7:07 PM, Rich Freeman ri...@gentoo.org wrote: On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao r...@cs.stonybrook.edu wrote: I proposed a way that this could work with no effort on the part of the Gentoo developers in one of my earlier emails: Then go ahead and make it happen. If as you say no dev participation is needed there is nothing Gentoo needs to do to support this. On Wed, Mar 14, 2012 at 6:49 PM, Greg KH gre...@gentoo.org wrote: We aren't Debian here people, we don't support everything :) If you want to support both, great, feel free to step up and do the work. Gentoo is about choice, but it is largely about the choices that people are willing to step up and maintain. A few months ago there was a big thread and lots of devs said that systemd isn't supported on Gentoo. Some devs stepped up and decided to maintain it and now I'd say systemd is about as supported on Gentoo as Prefix, FreeBSD, Sparc, or MIPS. That didn't happen because of mailing list persuasion - it happened because a few people interested in making it happen wrote a bunch of ebuilds. How do systemd units end up in various packages? The people interested in seeing them write good-quality patches and submit bugs, or otherwise work with the maintainers to commit them. For those who don't like the current direction, by all means create an overlay called udev-root, mdev-boot, noinitramfs, or whatever. You don't need anybody's permission to do it - just go on github and make it happen. Write some good code. There are several devs here who might even help you out with it, and nobody here is going to object to packages going into the main tree as long as they're maintained in accordance with Gentoo QA. Create some USE flags where you need tie-ins to other system packages and as long as everything behaves nicely and patches are good and maintained, I'm sure the package maintainers will accept them. In that vein... just to let you guys know that I have set up an overlay that has allowed me to run my Gentoo machines with only systemd: no OpenRC, no baselayout, no sysvinit: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ The changes are rather minimal (less than ten lines (usually a cople) per ebuild changed from the original ebuilds in the tree), and almost all will go away when the following bugs get fixed: https://bugs.gentoo.org/show_bug.cgi?id=366173 https://bugs.gentoo.org/show_bug.cgi?id=373219 https://bugs.gentoo.org/show_bug.cgi?id=373219 https://bugs.gentoo.org/show_bug.cgi?id=373219 https://bugs.gentoo.org/show_bug.cgi?id=399615 https://bugs.gentoo.org/show_bug.cgi?id=399615 https://bugs.gentoo.org/show_bug.cgi?id=399615 https://bugs.gentoo.org/show_bug.cgi?id=405703 https://bugs.gentoo.org/show_bug.cgi?id=408379 Bug 373219 is specially problematic, since several scripts in packages on the tree source /etc/init.d/functions.sh, (which lives in OpenRC), and don't depend on OpenRC explicitly. I wrote a little script that replaces the einfo, ewarn, etc. functions of OpenRC, and it seems to be working. I also wrote alternative versions of the packages on the tree that implicitly depend on OpenRC, so they now explicitly depend on a little package that only installs my script. It seems to be working. If you guys want to try it, I would love to hear some comments about it. (Usual disclaimer; if it breaks, you get to keep all the pieces). Oh, and obviously the only supported setups are those with /usr in the same partition as /; or, if /usr is in a separated partition, systems that use an initramfs to mount it. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 7:17 PM, Canek Peláez Valdés can...@gmail.com wrote: [...] https://bugs.gentoo.org/show_bug.cgi?id=366173 https://bugs.gentoo.org/show_bug.cgi?id=373219 https://bugs.gentoo.org/show_bug.cgi?id=399615 https://bugs.gentoo.org/show_bug.cgi?id=405703 https://bugs.gentoo.org/show_bug.cgi?id=408379 Oops, sorry, fogot to use uniq. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote: On 03/15/2012 10:41, Greg KH wrote: There's always mudev if you don't want to run udev, good luck with that. Got a link? We don't have anything matching in the tree, and Google turns up nothing relevant in the first few pages. Sorry, I think it's called 'mdev' and is part of busybox. greg no one asked me to adopt a package, amazing k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/15/12 22:43, Greg KH wrote: On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote: On 03/15/2012 10:41, Greg KH wrote: There's always mudev if you don't want to run udev, good luck with that. Got a link? We don't have anything matching in the tree, and Google turns up nothing relevant in the first few pages. Sorry, I think it's called 'mdev' and is part of busybox. greg no one asked me to adopt a package, amazing k-h How about app-editors/bvi? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 04:39, Duncan wrote: THAT is why they're moving /bin, /sbin and /lib to /usr rather than the other direction. rootfs will be ONLY a mountpoint, with even /etc/ being bind-mounted from /usr/etc, and all system data unified on /usr, including /etc. Viewed from that perspective, the direction of the unification, everything formerly on rootfs moving to /usr, so rootfs' only function is providing the mountpoints for everything else, has a certain logic to it... From one perspective, this makes sense. It actually is a kinda of holy grail for administrators, because it's one less filesystem to worry about backing up. And they don't care about non-initr* based systems any more than they care about non-Linux systems or for that matter, non-systemd Linux systems. That's outside their operational universe. Other people are welcome to continue working with legacy systems if they want, but Linux- only, systemd-based, initr*-based systems are the only thing they're interested in supporting, themselves. You know, I would have no problem with this if it wasn't a decision made by a single Linux distro with a huge amount of clout in the Linux world. This isn't like Debian forking Firefox into Ice Weasel, an issue that largely remains Debian-specific to this day. This is a change that will fundamentally alter the way every distro does things, and none of us (as far as I know) were given a choice in the matter. The /usr move is going to happen. I, along with a lot of other people, are going to have to fix all my installed systems over this. Not because of a choice made by all distros, but because one distro thinks that its way is the RightWay() and the OnlyWay(). That's what I disagree with. We shouldn't be affected by this change. Only Fedora users should have to deal with it. But other upstream projects are going to follow in Fedora's lead, and this brings us up to a decision point: adapt, or become irrelevant. I chose to stick with Gentoo as my distro of choice because I didn't like the way Red Hat did things years ago. As well as a few other nitpicks I have. It bugs me to no end that, despite running a fairly vanilla setup on a source-based distro whose original inspiration came from BSD ports, I am still affected by a decision made by RH. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 08:40:46AM -0400, Joshua Kinard wrote: I chose to stick with Gentoo as my distro of choice because I didn't like the way Red Hat did things years ago. As well as a few other nitpicks I have. It bugs me to no end that, despite running a fairly vanilla setup on a source-based distro whose original inspiration came from BSD ports, I am still affected by a decision made by RH. It is not a decision made by RH, some of the developers involved just happen to work for that distro. Others of us do not. Please don't get this confused with distro specific politics, it's not that at all. And again, if you have /usr on a different filesystem today, with no initrd, your machine could be broken and you don't even know it. greg why is this thread still alive k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
120314 Greg KH wrote: if you have /usr on a different filesystem today, with no initrd, your machine could be broken and you don't even know it. Whatever do you mean ? -- if it were truly broken, it wouldn't perform in some important obvious respect. Do you mean insecure ? -- if so, what is the threat ? greg why is this thread still alive k-h Your dismissive response is perhaps one reason ... -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote: 120314 Greg KH wrote: if you have /usr on a different filesystem today, with no initrd, your machine could be broken and you don't even know it. Whatever do you mean ? -- if it were truly broken, it wouldn't perform in some important obvious respect. Not always, no, it isn't obvious that something didn't start up correctly, or that it didn't fully load properly. Some programs later on recover and handle things better. Do you mean insecure ? -- if so, what is the threat ? No threat. greg why is this thread still alive k-h Your dismissive response is perhaps one reason ... Given that this is the first time I've responded to this thread in weeks, I doubt it. People like to complain, that's nothing new, I should be used to it by now, so perhaps it is all my fault... greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, 14 Mar 2012 08:04:31 -0700 Greg KH gre...@gentoo.org wrote: Not always, no, it isn't obvious that something didn't start up correctly, or that it didn't fully load properly. Some programs later on recover and handle things better. So why not work on fixing those things, since they're clearly symptoms of a larger oops, we have too much coupling problem, instead of forcing a workaround onto large numbers of users? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 03:08:27PM +, Ciaran McCreesh wrote: On Wed, 14 Mar 2012 08:04:31 -0700 Greg KH gre...@gentoo.org wrote: Not always, no, it isn't obvious that something didn't start up correctly, or that it didn't fully load properly. Some programs later on recover and handle things better. So why not work on fixing those things, since they're clearly symptoms of a larger oops, we have too much coupling problem, instead of forcing a workaround onto large numbers of users? I seriously doubt there are a large number of users here that have this issue. And even if there is, again, there is a simple solution that Gentoo provides for this issue, see the earlier initrd solution that we support today. As for fixing this, see the oft-linked webpage as to why it can't be fixed easily, if at all, and honestly, I don't think it needs to be fixed. Especially as NO ONE has ever stepped up to fix these issues, which proves that no one is really invested in it. As for too much coupling, you are talking to the wrong person. Personally, I feel we are too lightly coupled, and need to have stronger links happening here in order to properly solve the problems that we have in this area. If you disagree with the coupling issue, fine, but again, you need to do the work, and properly understand the issues involved. The people doing the work today do understand them, by virtue of doing the work involved, which gives them the say in how it is done. That's how open source works, why is this ever a surprise to people? I'll go back to lurking now, and getting stuff done, like everyone else on this thread should be doing, instead of complaining (this is -dev, not -users...) greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, 14 Mar 2012 08:22:09 -0700 Greg KH gre...@gentoo.org wrote: The people doing the work today do understand them, by virtue of doing the work involved, which gives them the say in how it is done. That's how open source works, why is this ever a surprise to people? The problem is that when a small number of people who have commit access to core projects screw everything up and don't fix the mess they're inflicting upon everyone, the only option left with how open source works is for someone to fork the code from the point where it all worked. That isn't something that should be done lightly. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 10:22 AM, Greg KH gre...@gentoo.org wrote: On Wed, Mar 14, 2012 at 03:08:27PM +, Ciaran McCreesh wrote: On Wed, 14 Mar 2012 08:04:31 -0700 Greg KH gre...@gentoo.org wrote: Not always, no, it isn't obvious that something didn't start up correctly, or that it didn't fully load properly. Some programs later on recover and handle things better. So why not work on fixing those things, since they're clearly symptoms of a larger oops, we have too much coupling problem, instead of forcing a workaround onto large numbers of users? I seriously doubt there are a large number of users here that have this issue. The majority of users should not encounter any difficulty due to this issue. Those that are doing special things that require careful mounting, etc should be sufficiently competent to deal with this issue without any trouble at all, especially given the various solution paths. And even if there is, again, there is a simple solution that Gentoo provides for this issue, see the earlier initrd solution that we support today. Gentoo provides a solution with genkernel, dracut provides a solution, even the linux kernel itself provides a solution (in my view the easiest solution at that). I'll go back to lurking now, and getting stuff done, like everyone else on this thread should be doing, instead of complaining (this is -dev, not -users...) greg k-h Oh, please Greg, do continue to stay engaged, I enjoy your perspective very much. I just wanted to drop this simple fact in there. This has been coming for several years now AND the linux kernel has been using an initramfs for every boot, every time for a long time now, all 2.6 and up as I understand it. If the initramfs is empty, well the kernel is smart enough to fall back on legacy boot process. If you care to read about it, its all contained locally if your kernel source in the file linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt Its a great read, sure to entertain and enlighten. It saved my bacon a few times when mdadm switched to the new metadata format. Once I began to learn about what the initramfs made possible, entire new worlds of possibility appeared (and I was not even on drugs!). It's actually something of a surprise to me that there are people upset about this change, since it cleans things up a bit while also giving people that want and/or need it, a great deal of power and control over the boot process that was not nearly as easy before. I do believe Gentoo, as a community/volunteer-run and super-power-user distribution, should be careful, a bit wary, and seriously consider the decisions made by our corporate colleagues (we do have the mandate to maintain our independence). However, simply because RHEL, SUSE, etc are corporation controlled distributions does not mean they are bad or trying to control/ruin the rest of the distros. Anyway, I merely thought I would place my commentary on this situation here for posterity. Since I have an opinion, I thought I would share it for better or worse. -- Matthew W. Summers Gentoo Foundation Inc.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 17:22, Greg KH gre...@gentoo.org wrote: As for fixing this, see the oft-linked webpage as to why it can't be fixed easily, if at all, and honestly, I don't think it needs to be fixed. What's wrong with: * having an early mounts list file * having an early modules list file * init system in early boot (e.g., OpenRC in init.sh) loading early modules and mounting early mounts from /etc/fstab This will solve the issue with most non-complex (i.e., no raid or encryption) initramfs-less setups, without requiring that users migrate to initramfs (e.g., after dealing with genkernel-generated scripts for a long time, I wouldn't touch it with a pointed stick anymore). The relevant files can be also generated automatically during an upgrade (empty early modules and empty or /usr-only early mounts, depending on /etc/fstab contents). -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 10:11 AM, Maxim Kammerer wrote: What's wrong with: * having an early mounts list file * having an early modules list file * init system in early boot (e.g., OpenRC in init.sh) loading early modules and mounting early mounts from /etc/fstab You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init. Other that that, it sounds like a perfect solution if you're in the I'd rather die than use an initramfs camp. -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico zmed...@gentoo.org wrote: On 03/14/2012 10:11 AM, Maxim Kammerer wrote: What's wrong with: * having an early mounts list file * having an early modules list file * init system in early boot (e.g., OpenRC in init.sh) loading early modules and mounting early mounts from /etc/fstab You're assuming that the /sbin/init hasn't migrated to /usr/sbin/init. Other that that, it sounds like a perfect solution if you're in the I'd rather die than use an initramfs camp. Well, anybody is welcome to create any replacement/addition for (/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it good enough, perhaps others will even use it. Beyond that, anything else is just a suggestion. In the end the folks writing udev and systemd are writing code, which gets them a lot further than emails do... :) Rich
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, 14 Mar 2012 12:58:26 -0500 Matthew Summers quantumsumm...@gentoo.org wrote: Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. Because the initramfs is just replacing what / used to be, and it's even less well handled than stuff not in /usr is just now. All using an initramfs does is move the dependencies problem from somewhere where we have a solution that used to work and that still mostly works to somewhere where we don't have anything at all. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 19:58, Matthew Summers quantumsumm...@gentoo.org wrote: __Everyone__ is already using an initramfs, therefore there are no initramfs-less systems anymore (it may just be empty). I suggest that you take a look at CONFIG_BLK_DEV_INITRD. Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. There is nothing bad about initramfs. I think that you are misreading the arguments above. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 11:36 AM, Maxim Kammerer wrote: On Wed, Mar 14, 2012 at 19:58, Matthew Summers quantumsumm...@gentoo.org wrote: Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. There is nothing bad about initramfs. I think that you are misreading the arguments above. Whatever the arguments may be, the whole discussion boils down to the fact that the only people who seem to have a problem are those that have a separate /usr partition and simultaneously refuse to use an initramfs. -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 12:14 PM, Michael Orlitzky wrote: On 03/14/12 14:56, Zac Medico wrote: On 03/14/2012 11:36 AM, Maxim Kammerer wrote: On Wed, Mar 14, 2012 at 19:58, Matthew Summers quantumsumm...@gentoo.org wrote: Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. There is nothing bad about initramfs. I think that you are misreading the arguments above. Whatever the arguments may be, the whole discussion boils down to the fact that the only people who seem to have a problem are those that have a separate /usr partition and simultaneously refuse to use an initramfs. People just don't like change for the sake of change, and haven't been shown any benefits yet. I don't have a separate /usr anywhere, but if I did, I would have to rebuild and test a good number of custom kernels that would eventually need to wind up on production servers. It would take a least a day's worth of work, not to mention staying late to make the switch overnight. If you can offer me something cool for it, great; but at the moment people are being offered it will work the same as it did yesterday, which sucks, because it works that way now. Sure, there will be improvements in the future, but it can feel a lot like treading water sometimes. Well, for most people, the most practical course of action is to suck it up [1] and move on. Dwelling on it certainly won't help, and the redesign the entire filesystem approach probably isn't very practical for most people either. [1] http://en.wiktionary.org/wiki/suck_it_up -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, 14 Mar 2012 12:58:26 -0500 Matthew Summers quantumsumm...@gentoo.org wrote: __Everyone__ is already using an initramfs, therefore there are no initramfs-less systems anymore (it may just be empty). I happen to understand you're not attempting to start a flame war here, but it may not obvious to everyone. jer (no initrds)
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 18:56, Zac Medico zmed...@gentoo.org wrote: Whatever the arguments may be, the whole discussion boils down to the fact that the only people who seem to have a problem are those that have a separate /usr partition and simultaneously refuse to use an initramfs. I wonder if it might help to go through the benefits of having a separate /usr, and see whether they still work when /usr is mounted by initramfs. Hopefully that would either demonstrate that the initramfs approach is fine, or reveal a concrete problem with it so we can start talking about solutions. (For the record, I don't have a separate /usr, but mainly because when I've been setting up machines I've been too lazy to either 1) figure out how much space to allocate to each partition, or 2) learn how to use lvm so I don't have to worry so much about getting it right the first time. I'd prefer for the option to stay available, but not as strongly as some people do.) To start us off, the benefit that I'm mainly interested in (for potential future use, as stated above), and I realise this is probably pretty far down the list overall, is that OpenRC can run fsck at shutdown instead of boot for non-/ filesystems, so as long as / is small there won't be huge boot delays. I imagine using initramfs wouldn't affect this, as by the time the system's shutting down it shouldn't matter how /usr got mounted originally. It might be affected if fsck etc got moved to /usr as has been mentioned, but if that happened OpenRC would probably have to be modified to remount it readonly at shutdown rather than unmount it, and presumably that would allow the fsck to occur. Would anyone else like to continue with their own favourite separate-/usr reason?
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 14:56, Zac Medico wrote: On 03/14/2012 11:36 AM, Maxim Kammerer wrote: On Wed, Mar 14, 2012 at 19:58, Matthew Summers quantumsumm...@gentoo.org wrote: Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. There is nothing bad about initramfs. I think that you are misreading the arguments above. Whatever the arguments may be, the whole discussion boils down to the fact that the only people who seem to have a problem are those that have a separate /usr partition and simultaneously refuse to use an initramfs. I do not have a separate /usr partition, however I agree with Joshua Kinard's stance regarding the /usr move. The point of having a separate /usr was to enable UNIX to exceed the space constraints that a 1.5MB hard disk placed on rootfs. As far as I know, we do not support a 1.5MB rootfs so it would make sense to deprecate the practice of having things that belong in / in /usr directory, as opposed to making /usr into a new /. Deprecation of this practice would mean that people could type /bin/command instead of /usr/bin/command in situations where absolute paths are necessary. We could symlink things in /usr to rootfs for compatibility with legacy software. In a more extreme case, we could symlink /usr to /, which would make plenty of sense given that we do not need a separate /usr at all. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]
On 15 March 2012 07:48, Duncan 1i5t5.dun...@cox.net wrote: It does, especially when it's literally the case, including a /usr/etc bind-mounted on a tmpfs-based rootfs, that by login time, all that's visible of rootfs is mountpoints, nothing else, and /usr literally IS the unified system resource filesystem. Considering this pretty much eliminates using / for anything useful, we might as well rename /usr /c Even if it /is/ just to confuse the windows crowd =) -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 08:04:31AM -0700, Greg KH wrote On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote: 120314 Greg KH wrote: if you have /usr on a different filesystem today, with no initrd, your machine could be broken and you don't even know it. Whatever do you mean ? -- if it were truly broken, it wouldn't perform in some important obvious respect. Not always, no, it isn't obvious that something didn't start up correctly, or that it didn't fully load properly. Some programs later on recover and handle things better. Throwing that one right back at you, if you have /usr on the same file system, plus you boot with systemd, your machine could be broken and you don't even know it. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 01:03 PM, Richard Yao wrote: On 03/14/12 14:56, Zac Medico wrote: On 03/14/2012 11:36 AM, Maxim Kammerer wrote: On Wed, Mar 14, 2012 at 19:58, Matthew Summers quantumsumm...@gentoo.org wrote: Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. There is nothing bad about initramfs. I think that you are misreading the arguments above. Whatever the arguments may be, the whole discussion boils down to the fact that the only people who seem to have a problem are those that have a separate /usr partition and simultaneously refuse to use an initramfs. I do not have a separate /usr partition, however I agree with Joshua Kinard's stance regarding the /usr move. The point of having a separate /usr was to enable UNIX to exceed the space constraints that a 1.5MB hard disk placed on rootfs. As far as I know, we do not support a 1.5MB rootfs so it would make sense to deprecate the practice of having things that belong in / in /usr directory, as opposed to making /usr into a new /. Deprecation of this practice would mean that people could type /bin/command instead of /usr/bin/command in situations where absolute paths are necessary. We could symlink things in /usr to rootfs for compatibility with legacy software. In a more extreme case, we could symlink /usr to /, which would make plenty of sense given that we do not need a separate /usr at all. I'm not seeing any compelling benefits here that would justify a lack of conformity with other *nix distros. It seems almost as though it's an attempt to be different for the sake of being different, perhaps a symptom of something like NIH syndrome. -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 03:59:56PM +, Ciaran McCreesh wrote: On Wed, 14 Mar 2012 08:22:09 -0700 Greg KH gre...@gentoo.org wrote: The people doing the work today do understand them, by virtue of doing the work involved, which gives them the say in how it is done. That's how open source works, why is this ever a surprise to people? The problem is that when a small number of people who have commit access to core projects screw everything up and don't fix the mess they're inflicting upon everyone, Again, there is a simple solution for this problem, already provided, and supported, so no mess talking here please, that's just trying to be dramatic. the only option left with how open source works is for someone to fork the code from the point where it all worked. That isn't something that should be done lightly. Forking should ALWAYS be done lightly and often, I highly recommend it. If you think you know how to do something better, it's best to fork, work it out, and if you come up with something, then work to merge it back, if at all possible. If merging doesn't work, and it turns out that your stuff works better, people will migrate to it, keeping it alive. Odds are, the fork will turn out to be a dead-end, and it will die off. But you will then know the reasons why, and not be so upset when others do things you disagree with. That's the way evolution works, and it works quite well, it's why open soure works as well as it does. So please, fork away, I can't recommend it enough. Remember, it's what got us Gentoo :) greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 07:57:52PM +, David Leverton wrote: Would anyone else like to continue with their own favourite separate-/usr reason? Haveing a separate /usr is wonderful, and once we finish moving /sbin/ and /bin/ into /usr/ it makes even more sense. See the /usr page at fedora for all of the great reasons why this is good. What doesn't make sense is people who do that, refusing to use an initrd or initramfs to make the whole thing work properly. It's as if people want the benefits, yet fail to want to actually use the tools required to get those benefits. It makes no sense, and if anyone continues to complain, it shows a lack of understanding. greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 16:55, Zac Medico wrote:
On 03/14/2012 01:03 PM, Richard Yao wrote:
I do not have a separate /usr partition, however I agree with Joshua
Kinard's stance regarding the /usr move. The point of having a separate
/usr was to enable UNIX to exceed the space constraints that a 1.5MB
hard disk placed on rootfs. As far as I know, we do not support a 1.5MB
rootfs so it would make sense to deprecate the practice of having things
that belong in / in /usr directory, as opposed to making /usr into a new /.
Deprecation of this practice would mean that people could type
/bin/command instead of /usr/bin/command in situations where absolute
paths are necessary. We could symlink things in /usr to rootfs for
compatibility with legacy software. In a more extreme case, we could
symlink /usr to /, which would make plenty of sense given that we do not
need a separate /usr at all.
I'm not seeing any compelling benefits here that would justify a lack of
conformity with other *nix distros. It seems almost as though it's an
attempt to be different for the sake of being different, perhaps a
symptom of something like NIH syndrome.
How did RedHat justify that lack of conformity that resulted from moving
everything into /usr in the first place? The original UNIX did not have
anything in /usr. The /usr split was caused by Bell Labs having to grow
UNIX past the constraints of a 1.5MB hard drive. Since we are no longer
limited by such space constraints, I fail to see why we should not
deprecate /usr.
In the meantime, it should be possible to create a global usr USE flag
that enables/disables gen_usr_ldscript. It would then be possible to
delete all of the usr ldscripts, dump /usr into / and symlink /usr to /.
The dynamic linker would go to / before /usr and it would be trivial to
modify $PATH to ignore /usr entirely. Legacy software that requires
/usr/{bin,sbin} would still work while those that want a separate /usr
mount could symlink /usr/{bin,include,libexec,sbin} into their rootfs
counterparts.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 21:04, Greg KH gre...@gentoo.org wrote: Haveing a separate /usr is wonderful, and once we finish moving /sbin/ and /bin/ into /usr/ it makes even more sense. See the /usr page at fedora for all of the great reasons why this is good. My point was examine, in detail, whether separate-/usr-with-initramfs has any disadvantages compared to separate-/usr-without-initramfs. Either it has, in which case we have a concrete argument against requiring initramfs (albeit possibly one that can be fixed), or it hasn't, which should hopefully convince at least some people to accept it.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 17:04, Greg KH wrote: On Wed, Mar 14, 2012 at 07:57:52PM +, David Leverton wrote: Would anyone else like to continue with their own favourite separate-/usr reason? Haveing a separate /usr is wonderful, and once we finish moving /sbin/ and /bin/ into /usr/ it makes even more sense. See the /usr page at fedora for all of the great reasons why this is good. What doesn't make sense is people who do that, refusing to use an initrd or initramfs to make the whole thing work properly. It's as if people want the benefits, yet fail to want to actually use the tools required to get those benefits. It makes no sense, and if anyone continues to complain, it shows a lack of understanding. greg k-h Is this that page? http://fedoraproject.org/wiki/Features/UsrMove That refers to the systemd website on freedesktop.org. http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge Reading that, it seems to me that this /usr move was caused by a systemd-specific decision that rootfs should be both system-specific and located on the particular system while /usr should be network mountable. However, I see no argument for why that should be the case. Thinking about it, I suppose this would make sense in an enterprise setting where everything is diskless. If you PXE boot, put rootfs on iSCSI and have /usr on a NFS mount, this would work very well. Claiming that people show a lack of understanding when you never explain this, however, is definitely the wrong thing to do. With that said, I have a few questions: 1. Why does no one mention the enterprise use case at all? 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device? 3. Why not let the users choose where these directories go and support both locations? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote: Is this that page? http://fedoraproject.org/wiki/Features/UsrMove That refers to the systemd website on freedesktop.org. http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge Yes. With that said, I have a few questions: 1. Why does no one mention the enterprise use case at all? It has been pointed out before, why constantly repeat ourselves. 2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device? unionfs is still a work in progress, some systems can't do that yet. 3. Why not let the users choose where these directories go and support both locations? Because a plethera of options is a sure way to make sure that half of them don't work over the long run. We aren't Debian here people, we don't support everything :) If you want to support both, great, feel free to step up and do the work. greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 10:14:54PM +, David Leverton wrote: On 14 March 2012 21:04, Greg KH gre...@gentoo.org wrote: Haveing a separate /usr is wonderful, and once we finish moving /sbin/ and /bin/ into /usr/ it makes even more sense. See the /usr page at fedora for all of the great reasons why this is good. My point was examine, in detail, whether separate-/usr-with-initramfs has any disadvantages compared to separate-/usr-without-initramfs. Oh, that's simple, separate-/usr-without-initramfs will not work and will not be supported :) Again, the fact that it works for some people today is pure luck, and odds are, it really isn't, but it's really hard to determine this given that the init system they are using doesn't provide a good feedback loop for this type of thing. Hence, it is not supported. thanks, greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 22:51, Greg KH gre...@gentoo.org wrote: Oh, that's simple, separate-/usr-without-initramfs will not work and will not be supported :) See, it's this we're doing it this way because we know best and we say so that upsets people. I'm trying to encourage everyone to get to the core reasons for having a separate /usr in the first place (not all of which are guaranteed to be mentioned on any specific wiki page), and logically analyse the potential disadvantages of using an initramfs in each situation. It may turn out that there are no disadvantages after all, but the analysis is still important, not only to make sure that we're making the right decision, but also to persuade everyone else that it's the right decision. Again, the fact that it works for some people today is pure luck, and odds are, it really isn't, but it's really hard to determine this given that the init system they are using doesn't provide a good feedback loop for this type of thing. Maybe it would be worth improving the init system to do so? Or maybe it wouldn't because using an initramfs is easier and has no drawbacks, but see above.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 18:49, Greg KH wrote:
On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
With that said, I have a few questions:
1. Why does no one mention the enterprise use case at all?
It has been pointed out before, why constantly repeat ourselves.
Simple. No one has documented it. A webpage that makes a few vague
references to enterprise use does not count as documentation.
I happened to figure it out when trying to rationalize why anyone would
want this, but this is hardly obvious to those that imagine a computer
as a self-sufficient single disk system.
2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
unionfs is still a work in progress, some systems can't do that yet.
That sounds like something that needs to be fixed.
3. Why not let the users choose where these directories go and support
both locations?
Because a plethera of options is a sure way to make sure that half of
them don't work over the long run.
We aren't Debian here people, we don't support everything :)
Gentoo provides far more options than Debian does, so this seems
somewhat contradictory to me.
If you want to support both, great, feel free to step up and do the
work.
Fair enough, however, I should remind you that not much will happen
without a decision from the Gentoo Council. I am willing to accept
whatever decision they make, but I think that exposing this decision to
users is something that is within our ability to do.
Portage provides use with the ability to do abstractions that other
distributions cannot do, such as permitting people to merge
/usr{bin,lib{32,64,},sbin} into /.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote:
3. Why not let the users choose where these directories go and support
both locations?
Because a plethera of options is a sure way to make sure that half of
them don't work over the long run.
We aren't Debian here people, we don't support everything :)
Gentoo provides far more options than Debian does, so this seems
somewhat contradictory to me.
Not really, I don't think we support systems without udev anymore,
right? And we get away with a lot of these different options at
compile time, which makes it easier than what Debian has to handle, so
perhaps it's not a fair comparison.
If you want to support both, great, feel free to step up and do the
work.
Fair enough, however, I should remind you that not much will happen
without a decision from the Gentoo Council. I am willing to accept
whatever decision they make, but I think that exposing this decision to
users is something that is within our ability to do.
I didn't think the Council ruled on technical questions.
In fact, how is this relevant at all anyway? It's quite simple in that
we don't support systems today with a separate /usr/ without a
initramfs/initrd. If it happens to work, wonderful, but don't expect
Gentoo developers to rewrite the upstream packages to work for this type
of unsupported systems, it's not going to happen.
Or are you referring to the no more /bin and /sbin thing? That's just
going to happen naturally, one day in a few months or years, your
system will have moved to this without you even realizing it :)
Portage provides use with the ability to do abstractions that other
distributions cannot do, such as permitting people to merge
/usr{bin,lib{32,64,},sbin} into /.
Sure, but that doesn't mean that the packages that are being merged will
actually work :)
greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 11:21:44PM +, David Leverton wrote: On 14 March 2012 22:51, Greg KH gre...@gentoo.org wrote: Oh, that's simple, separate-/usr-without-initramfs will not work and will not be supported :) See, it's this we're doing it this way because we know best and we say so that upsets people. Oh, and somehow consensus will work? No, sorry, it will not. How about the basic FACT that today, such systems do not work, and are not supported by a wide range of packages we support today. Yes, some people are lucky in that their systems don't have those packages, but others are not. The simple I use a bluetooth keyboard is one such example. So it's not a we know best, it's a it will not properly work otherwise. It is strange to watch people somehow think that if they complain enough, or feel strongly enough, something is going to change here to make this basic fact go away. Now, to get back to what I said before, I'm done with this thread, it's going nowhere, and it seems I'm just making it worse, my apologies. For penance, I'll adopt the next abandoned package someone throws at me, any suggestions? greg k-h
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 04:21 PM, David Leverton wrote: On 14 March 2012 22:51, Greg KH gre...@gentoo.org wrote: Oh, that's simple, separate-/usr-without-initramfs will not work and will not be supported :) See, it's this we're doing it this way because we know best and we say so that upsets people. It's more about what we're _not_ doing that what we're doing. What we're not doing is supporting the / is a self-contained boot disk that is independent of /usr use case, simply because it's a huge maintenance burden and it doesn't make much sense in the post-initramfs world. The people who have a problem with this don't understand the burden and have no intention of taking on the burden themselves. Even if they wanted to take on the burden, they wouldn't be capable of it. If they were capable of taking on this burden then they would have already understood that the initramfs is the most reasonable solution to their perceived problem. -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 19:37, Greg KH wrote:
Portage provides use with the ability to do abstractions that other
distributions cannot do, such as permitting people to merge
/usr{bin,lib{32,64,},sbin} into /.
Sure, but that doesn't mean that the packages that are being merged will
actually work :)
greg k-h
I proposed a way that this could work with no effort on the part of the
Gentoo developers in one of my earlier emails:
On 03/14/12 17:05, Richard Yao wrote:
In the meantime, it should be possible to create a global usr USE flag
that enables/disables gen_usr_ldscript. It would then be possible to
delete all of the usr ldscripts, dump /usr into / and symlink /usr to /.
The dynamic linker would go to / before /usr and it would be trivial to
modify $PATH to ignore /usr entirely. Legacy software that requires
/usr/{bin,sbin} would still work while those that want a separate /usr
mount could symlink /usr/{bin,include,libexec,sbin} into their rootfs
counterparts.
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 19:44, Greg KH wrote: Now, to get back to what I said before, I'm done with this thread, it's going nowhere, and it seems I'm just making it worse, my apologies. For penance, I'll adopt the next abandoned package someone throws at me, any suggestions? Bug #360513 needs work. Something in sys-boot/grub-0.97-r* is triggering a bug in the GNU toolchain. Few of us have time to deal with it, so it would be much appreciated if you would take care of it. ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 07:58:23PM -0400, Richard Yao wrote: On 03/14/12 19:44, Greg KH wrote: Now, to get back to what I said before, I'm done with this thread, it's going nowhere, and it seems I'm just making it worse, my apologies. For penance, I'll adopt the next abandoned package someone throws at me, any suggestions? Bug #360513 needs work. Something in sys-boot/grub-0.97-r* is triggering a bug in the GNU toolchain. Few of us have time to deal with it, so it would be much appreciated if you would take care of it. ;) grub is not an abandoned package, it's as if people don't read what I write...
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 23:44, Greg KH gre...@gentoo.org wrote: Oh, and somehow consensus will work? No, sorry, it will not. No, logical analysis will, as I said in the rest of my post which you conveniently ignored - either we conclude with evidence that there are no issues, which should settle the matter for reasonable people, or we discover that there are, in which case they have to be dealt with one way or another. I really don't see how anyone can object to that, unless they're worried they won't like the result How about the basic FACT that today, such systems do not work This is debatable at best. You can keep screaming but bluetooth won't work! until you're blue in the face, but that's not relevant at all to people who don't use bluetooth. and are not supported by a wide range of packages we support today. Isn't such support being removed by the same people who keep arguing that it's already not supported? That's like cutting half your employees' pay, and then insisting that you have to choice but to cut the other half's pay as well, in order to be fair. Yes, some people are lucky in that their systems don't have those packages, but others are not. The simple I use a bluetooth keyboard is one such example. People who only have a bluetooth keyboard can set their systems up in such a way that it works, just like how people who have / on lvm can set their systems up in such a way that that works. That's not in itself a reason to force it on everyone. It is strange to watch people somehow think that if they complain enough, or feel strongly enough, something is going to change here to make this basic fact go away. If by the basic fact you mean that plenty of people are quite happy doing what's worked just fine for years, then yes.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org wrote: It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 05:36 PM, David Leverton wrote: On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org wrote: It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself. You're pointing your finger at udev, but the udev change is just a symptom of a more general shift away from supporting the / is a self-contained boot disk that is independent of /usr use case. -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 15 March 2012 00:45, Zac Medico zmed...@gentoo.org wrote: You're pointing your finger at udev, but the udev change is just a symptom of a more general shift away from supporting the / is a self-contained boot disk that is independent of /usr use case. OK, so there are multiple instances of people not not doing anything rather than just one. I think that supports my point more than it refutes it.
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 20:36, David Leverton wrote: On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org wrote: It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself. I suggest that you file a bug report regarding this for the Gentoo udev maintainer. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 05:58 PM, Richard Yao wrote: On 03/14/12 20:36, David Leverton wrote: On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org wrote: It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself. I suggest that you file a bug report regarding this for the Gentoo udev maintainer. RESOLVED:UPSTREAM -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao r...@cs.stonybrook.edu wrote: I proposed a way that this could work with no effort on the part of the Gentoo developers in one of my earlier emails: Then go ahead and make it happen. If as you say no dev participation is needed there is nothing Gentoo needs to do to support this. On Wed, Mar 14, 2012 at 6:49 PM, Greg KH gre...@gentoo.org wrote: We aren't Debian here people, we don't support everything :) If you want to support both, great, feel free to step up and do the work. Gentoo is about choice, but it is largely about the choices that people are willing to step up and maintain. A few months ago there was a big thread and lots of devs said that systemd isn't supported on Gentoo. Some devs stepped up and decided to maintain it and now I'd say systemd is about as supported on Gentoo as Prefix, FreeBSD, Sparc, or MIPS. That didn't happen because of mailing list persuasion - it happened because a few people interested in making it happen wrote a bunch of ebuilds. How do systemd units end up in various packages? The people interested in seeing them write good-quality patches and submit bugs, or otherwise work with the maintainers to commit them. For those who don't like the current direction, by all means create an overlay called udev-root, mdev-boot, noinitramfs, or whatever. You don't need anybody's permission to do it - just go on github and make it happen. Write some good code. There are several devs here who might even help you out with it, and nobody here is going to object to packages going into the main tree as long as they're maintained in accordance with Gentoo QA. Create some USE flags where you need tie-ins to other system packages and as long as everything behaves nicely and patches are good and maintained, I'm sure the package maintainers will accept them. Gentoo already gives its users a lot of choice, but it can only offer the choices that people are willing to maintain. Right now I see a lot of complaining and not a lot of maintaining. When I see a package lastrited I don't moan about it - I either sigh or sign up to maintain it. By all means make suggestions to improve the transition or write docs, but simply posting on this list isn't likely to change the direction the linux winds are blowing. The forces involved are much larger than Gentoo. Rich
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 06:07 PM, Rich Freeman wrote: For those who don't like the current direction, by all means create an overlay called udev-root, mdev-boot, noinitramfs, or whatever. The simplest alternative to an initramfs that I can think of would be an init wrapper like the one that I suggested a while back [1]. [1] http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 21:07, Rich Freeman wrote: On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao r...@cs.stonybrook.edu wrote: I proposed a way that this could work with no effort on the part of the Gentoo developers in one of my earlier emails: Then go ahead and make it happen. If as you say no dev participation is needed there is nothing Gentoo needs to do to support this. That proposal was something that I had intended to abstract ebuild maintainers such as myself out of the picture. I am do not have a separate /usr filesystem, yet as an ebuild maintainer, I receive bug reports from those that do. If people want to guarentee that they can boot without an initramfs, they can implement my suggestion. If they don't, then it is no problem for me. I have already fixed things for the separate /usr crowd in my ebuilds. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/12 21:06, Zac Medico wrote: On 03/14/2012 05:58 PM, Richard Yao wrote: On 03/14/12 20:36, David Leverton wrote: On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org wrote: It's more about what we're _not_ doing that what we're doing. Clearly something must have changed in udev 181 to make /usr-without-initramfs not work anymore, and someone must have done something to make that change happen, unless udev has aquired the ability to evolve by itself. I suggest that you file a bug report regarding this for the Gentoo udev maintainer. RESOLVED:UPSTREAM Lets permit the udev maintainer to do that. :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 03/14/2012 02:05 PM, Richard Yao wrote: How did RedHat justify that lack of conformity that resulted from moving everything into /usr in the first place? Does it really matter? What people in the separate-/usr-without-initramfs camp really want is continued support for the / is a self-contained boot disk that is independent of /usr use case, because without such support, the separate-/usr-without-initramfs approach that they're accustomed to becomes impossible. The /usr merge [1] can be viewed as just one of many signs of a widespread shift away from supporting the heavy burden of the / is a self-contained boot disk that is independent of /usr use case. [1] http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge -- Thanks, Zac
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 3/14/12 10:58 AM, Matthew Summers wrote: __Everyone__ is already using an initramfs, therefore there are no initramfs-less systems anymore (it may just be empty). Every single person reading this thread that has not already done so needs to immediately go read the relevant documentation located in /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt, then and only then can a real discourse be had. Yawn, I don't and I won't since I don't need it. Why should I? Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite nice to have a minimal recovery env in case mounting fails, etc, etc, etc. Because at least for me is *totally* pointless. My main system is with a single partition so I shouldn't care much, I have a system that has a separate /usr so probably I'll have *some* pain once I'll upgrade it if I don't merge /usr and / partitions before. Still the whole idea brings us back to the freebsd everything in /usr while would make more sense go the hurd way everything in / if there is a sound reason to merge those. Beside the whole /usr/share/id-data-du-jour-my-udev-rule-might-need and the I-want-glib and I-want-dbus bandwagon I hadn't seen any compelling reason. Having anything as complex as dbus for early boot sounds dangerous or frail. lu
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 3/14/12 4:37 PM, Greg KH wrote: Not really, I don't think we support systems without udev anymore, right? And we get away with a lot of these different options at compile time, which makes it easier than what Debian has to handle, so perhaps it's not a fair comparison. I think we support systems with launchd and devd quite well and we'd love to support even some more. Sure, but that doesn't mean that the packages that are being merged will actually work :) Only if upstream really wants to break them... And that is the perceived situation, exacerbated by the past experience with a certain audio daemon trying to do too much at the same time. lu
Re: [gentoo-dev] Re: Let's redesign the entire filesystem!
On 3/14/12 10:59 AM, Rich Freeman wrote: Well, anybody is welcome to create any replacement/addition for (/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it good enough, perhaps others will even use it. There is a SoC out there for that. Beyond that, anything else is just a suggestion. In the end the folks writing udev and systemd are writing code, which gets them a lot further than emails do... :) People might be happy with what they have and might feel a bit threatened when they have to switch away from the DE they like because it forces on them an init system that they hate. lu
