RE: [gentoo-user] Re: Anyone switched to eudev yet?
From: Alan McKinnon [mailto:alan.mckin...@gmail.com] Sent: Thursday, December 27, 2012 6:08 PM On Tue, 25 Dec 2012 10:56:52 +0700 Pandu Poluan pa...@poluan.info wrote: In case you haven't noticed, since Windows 7 (or Vista, forget which) Microsoft has even went the distance of splitting between C: (analogous to /usr) and 'System Partition' (analogous to /). The boot process is actually handled by the 100ish MB 'System Partition' before being handed to C:. This will at least give SysAdmins a fighting chance of recovering a botched maintenance. (Note: Said behavior will only be visible if installing onto a clean hard disk. If there are partitions left over from previous Windows installs, Win7 will not create a separate 'System Partition') So, if Microsoft saw the light, why does Red Hat sunk into darkness instead? I'm not sure about Microsoft's motivations in what you describe. My first reaction is that the Great Circle of IT Life is turning and MS are trying something new for them. Whether it's applicable to us here as an illustration remains to be seen - I know very little about Windows so can't even begin to draw sensible parallels. I know little about the history of UNIX before 1993, and the sum of my experience with Linux is that I have never personally run into any case where I had a single /+/usr and regretted it, but I *have* encountered situations where I could not get /usr mounted and ended up merging it with /. FWIW, YMMV, etc. I can tell you that Pandu's analogy vis a vis Windows is a bit flawed. What Windows has done recently is (by default for clean installs) to split the boot loader and related bootstrap code into a separate partition from the actual operating system. Claiming that this is analogous to / and /usr is quite a stretch. It is much more accurate to make it analogous to / and /boot. The System Partition has no Windows files on it, just the equivalent to grub (and it's also used if you have BitLocker, to decrypt your boot partition). Which, to me, means it has absolutely nothing to do with the current discussion one way or the other :) --Mike
Re: [Bulk] RE: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, 4 Jan 2013 18:22:37 -0500 Mike Edenfield kut...@kutulu.org wrote: I have never personally run into any case where I had a single /+/usr and regretted it, but I *have* encountered situations where I could not get /usr mounted and ended up merging it with /. FWIW, YMMV, etc. And why was that, not udev? What is your point, others have avoided regretting it by having a seperate /usr. I can tell you that Pandu's analogy vis a vis Windows is a bit flawed. What Windows has done recently is (by default for clean installs) to split the boot loader and related bootstrap code into a separate partition from the actual operating system. Claiming that this is analogous to / and /usr is quite a stretch. It is much more accurate to make it analogous to / and /boot. The System Partition has no Windows files on it, just the equivalent to grub (and it's also used if you have BitLocker, to decrypt your boot partition). Which, to me, means it has absolutely nothing to do with the current discussion one way or the other :) He did define the fact that he mentioned it because he claimed the repair tools are stored in a small seperate partition like / or root is defined in the FHS which means he brought more to the discussion than you just have. In any case there are major benefits to having Windows with program files on a seperate partition and you shouldn't be stopped from having a seperate /usr without good reason and which there is not or if there is good reason in a hidden agenda/future plan it has not been brought to any discussion, note though that lies and mystery have. Broken for years indeed, more like tiny issues that few care about and so haven't been fixed by default. I re-assert that eudevs mentioning of moving potentially less stable/audited or even arbitrary code to later in the boot process is also welcomed by me.
Re: Should /usr be merged with /? (Was: Re: [gentoo-user] Re: Anyone switched to eudev yet?)
On Sat, Dec 29, 2012 at 3:00 PM, Paul Colquhoun paul...@andor.dropbear.id.au wrote: I'd certainly be happy fixing FHS to say that tools for mounting and recovering essential system partitions be located in /, and that these essential system partitions contain the tools for mounting and recovering non-essential partitions. The beef with the comment on /home being nonessential is besides the point, /usr, /var, or /opt could have been some special case FUSE filesystem, making it still impossible to predict which files _should_ be in /. The more relevant matter here is that plan FHS, in combination with FUSE, makes that difficult. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: Should /usr be merged with /? (Was: Re: [gentoo-user] Re: Anyone switched to eudev yet?)
On Sun, 30 Dec 2012 20:19:44 +0800 Mark David Dumlao madum...@gmail.com wrote: I'd certainly be happy fixing FHS to say that tools for mounting and recovering essential system partitions be located in /, and that these essential system partitions contain the tools for mounting and recovering non-essential partitions. The beef with the comment on /home being nonessential is besides the point, /usr, /var, or /opt could have been some special case FUSE filesystem, making it still impossible to predict which files _should_ be in /. The more relevant matter here is that plan FHS, in combination with FUSE, makes that difficult. That's not best practice though is it and I completely disagree with the rules you seem to believe the english language has too. It is not a difficult problem, just FUSE is not expected or intended for that, if that changes it is easily fixed immediately by the admin or by the packager preferably in concert with some root management body or project. Many/All of these issues that have come up are actually of 0 effect, we are not talking about preventing users from merging them as most Linux users do because they just hit ok ok ok in ubuntus installation but about a major degradation due to some devs whim and without I might add proper community involvement or commentry ALLOWED. One things for sure real problems will arise directly due to this merge if this merge becomes standard and possibly with won't fixes used leading to pointlessly breaking existing servers and linux becoming even more of an unorganised mess. On windows production machines I arrived at putting c: on it's own smaller partition and program files on a larger partition. It meant I could have many more c: backups and restore much more quickly too resulting in much higher uptime and reduced loss in the cases that registry restore wasn't good enough and system restore is crap. With windows 7 it's not so beneficial as windows 7 is huge but still useful as everything is getting huge on windows these days. You do get the occasional dumb program perhaps fixable with a drive link within c:. Windows 8 should be more reliable but I expect brings new issues in this area due to app restrictions and where sandboxing could have been used for security instead.
Re: Should /usr be merged with /? (Was: Re: [gentoo-user] Re: Anyone switched to eudev yet?)
The latest FHS dates from 2004, the same year as the *earliest* FUSE release I can see on the FUSE web site. I'd say a good working hypothesis is that FHS was simply written *before* any user-space file systems were more than an experimental oddity. IF the system's /home directory is formatted as an OpenBSD partition, then yes, FHS demands that tools for mounting and recovering it be in /. I'd certainly be happy fixing FHS to say that tools for mounting and recovering essential system partitions be located in /, and that these essential system partitions contain the tools for mounting and recovering non-essential partitions. Which would include testdisk (As far as I know the only linux tool able to read an OpenBSD partition) in /usr. Of course the admin is free to move a copy of testdisk to /. No-one is saying the FHS is perfect, I know the BSD crowd would say far from it but we want it to move in the right not wrong direction. If you are wondering where I stand, I currently boot with an initramfs, since I have everything except /boot located on LVM devices. This includes / and a seperate /usr, done mostly from habit after 15 years of habit, and working where that was the corporate standard production practice. As to system recovery, nowdays I ususlly do that by booting from a live CD/DVD so I have access to all the tools when I need them. Which reminds me that I need to update my rescue DVD to the latest version... A rescue CD has the benefit of being on read only media and perhaps including tools and perhaps enabling permissions you don't want on the system or auditing without running anything from the system and as a fallback but in general single user is more appropriate than both cd and ramdisk and atleast is useful as it can be tailored to the system, is the system and is more likely familiar to the user, a system may not have a cd and maybe not usbs or be remote and as shown is less likely to be upto date and so secure and so useful online, especially if you need a host to upload the cd image. Note: This should highlight how wrong Gregs freedesktop.org links are. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
Should perl be in / or /usr? Now that is a good question, if only because Perl traditionally _loathes_ being in /bin, for its own philosophical reasons. Now, as a practical matter? WTF are the scripts written in Perl? Or in anything other than sh? If they're intended for emergency use, they've got some pretty fat dependencies, and should probably be launched from a full rescue environment instead. Or the log files should be copied to some place with more featureful tools available. Can perl be built statically and moved to / by the admin for this corner case? If not you should have all the tools to fix /usr in root and then if anything needs fixing via perl then you should be able to mount /usr or mount -a and have a fully working single user system to run perl from. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 9:10 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Should perl be in / or /usr? Now that is a good question, if only because Perl traditionally _loathes_ being in /bin, for its own philosophical reasons. Now, as a practical matter? WTF are the scripts written in Perl? Or in anything other than sh? If they're intended for emergency use, they've got some pretty fat dependencies, and should probably be launched from a full rescue environment instead. Or the log files should be copied to some place with more featureful tools available. Can perl be built statically and moved to / by the admin for this corner case? Certainly, but you still have modules to consider...but those can of course be bundled. If not you should have all the tools to fix /usr in root and then if anything needs fixing via perl then you should be able to mount /usr or mount -a and have a fully working single user system to run perl from. Indeed. The only reason I can imagine this to not be the case is if the mount for /usr fails. Most of the reasons imaginable also apply equally strongly to initramfs+root-on-special-mount and everything-in-/usr. -- :wq
Re: Should /usr be merged with /? (Was: Re: [gentoo-user] Re: Anyone switched to eudev yet?)
TLDR: FHS is unrealistic about its promises. if we move our binaries / libraries to /usr and work it to make sure /usr is mounted, we will better serve FHS goals and also happen to fix some systemic, but silent bugs. On Fri, Dec 28, 2012 at 12:20 PM, Michael Mol mike...@gmail.com wrote: On Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao madum...@gmail.com wrote: Second, going back to problem solving in general - just because you can put down in words what you think the problem is, doesn't mean you've mapped out an accurate or even consistent statement of the problem. There really are cases where it's not enough to just give general airy abstractions and rules of thumb to map out a problem, where it isn't obvious that you're running into edge cases until you really look at it deeply, and yes, the / and /usr split is one of them. So let's look at it deeply, since nobody else will. I'm game. This is the most detailed technical discussion of the problem anyone's cared to actually have, as far as I've been able to observe. For the purposes of clarity I'm going to compare two competing standards, which I will be identifying as follows: s1) FHS, or plain FHS, based on FHS2.3, as identified in http://www.pathname.com/fhs/pub/fhs-2.3.html s2) merged FHS, or merged standard, based on FHS2.3 as above, but with the caveat that all binaries and libraries are placed in /usr instead of being split between /usr and /, as described by http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge It will be helpful to examine how each system reacts to strange cases that challenge FHS. I think some of the following considerations are helpful in determining which one works better. Whichever one is emphasized conspicuously depends on which systems you're interested in maintaining, how many people are using them, your personal taste, sense of justice, etc. Perhaps you could add some of your own. g1) Primary FHS purpose: software/users can predict location of installed files and directories g2) make distro maintainers' job easier g3) make sysads' job easier g4) it does not directly conflict with general practice It is my contention that in all goals, merged FHS is better than plain FHS. Secondly, it is also my contention that plain FHS with a separate /usr does not give enough information to reliably satisfy its own primary goal (g1). Back to the cases below. = === FUNDAMENTAL PROBLEM: / and /usr desync === = Thesis: FHS promise of /usr being sharable is not really deliverable unless it contains the libraries in /. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. The most fundamental and relevant one for us Gentoo users is this: - how can /usr be sharable among different hosts if it depends on libraries in /? http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY Purpose /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. Many distros place fundamental libraries that many programs in /usr depend on in /lib. Especially bad for Gentoo - libraries in /lib may be recompiled as same-version variants if you want to change the USE flags, resulting in clients that don't synchronously recompile their own libraries in /lib to both silently and noisily fail. In other words, many programs in /usr in practice are functionally inseparable from the libraries in /, conflicting with the notion that they were properly shared in the first place. There are certain implicit assumptions made in the spec that are important. First, it's assumed the binaries are compatible with all the hosts. It's assumed you're not sharing s360 binaries with x86 hosts, or sparc binaries with ppc hosts. From there, it's reasonable to assume that the authors of the spec assume the administrator to be smart enough to not do things like: * Mix compiler versions * Mix program compile options * Place a dependency on a binary that's going to be missing. The spec is very, very much a do what you want within these guidelines; don't shoot yourself in the foot thing, it's very much not a declarative bikeshedding of everything related to it. Unfortunately, FHS actually does explicitly specify the meaning of shareable. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEFILESYSTEM Shareable files are those that can be stored on one host and used on others.
Re: Should /usr be merged with /? (Was: Re: [gentoo-user] Re: Anyone switched to eudev yet?)
On Sat, Dec 29, 2012 at 01:16:34AM +0800, Mark David Dumlao wrote: TLDR: FHS is unrealistic about its promises. if we move our binaries / libraries to /usr and work it to make sure /usr is mounted, we will better serve FHS goals and also happen to fix some systemic, but silent bugs. On Fri, Dec 28, 2012 at 12:20 PM, Michael Mol mike...@gmail.com wrote: On Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao madum...@gmail.com wrote: Second, going back to problem solving in general - just because you can put down in words what you think the problem is, doesn't mean you've mapped out an accurate or even consistent statement of the problem. There really are cases where it's not enough to just give general airy abstractions and rules of thumb to map out a problem, where it isn't obvious that you're running into edge cases until you really look at it deeply, and yes, the / and /usr split is one of them. So let's look at it deeply, since nobody else will. I'm game. This is the most detailed technical discussion of the problem anyone's cared to actually have, as far as I've been able to observe. For the purposes of clarity I'm going to compare two competing standards, which I will be identifying as follows: s1) FHS, or plain FHS, based on FHS2.3, as identified in http://www.pathname.com/fhs/pub/fhs-2.3.html s2) merged FHS, or merged standard, based on FHS2.3 as above, but with the caveat that all binaries and libraries are placed in /usr instead of being split between /usr and /, as described by http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge It will be helpful to examine how each system reacts to strange cases that challenge FHS. I think some of the following considerations are helpful in determining which one works better. Whichever one is emphasized conspicuously depends on which systems you're interested in maintaining, how many people are using them, your personal taste, sense of justice, etc. Perhaps you could add some of your own. g1) Primary FHS purpose: software/users can predict location of installed files and directories g2) make distro maintainers' job easier g3) make sysads' job easier g4) it does not directly conflict with general practice It is my contention that in all goals, merged FHS is better than plain FHS. Secondly, it is also my contention that plain FHS with a separate /usr does not give enough information to reliably satisfy its own primary goal (g1). Back to the cases below. = === FUNDAMENTAL PROBLEM: / and /usr desync === = Thesis: FHS promise of /usr being sharable is not really deliverable unless it contains the libraries in /. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. The most fundamental and relevant one for us Gentoo users is this: - how can /usr be sharable among different hosts if it depends on libraries in /? http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY Purpose /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. Many distros place fundamental libraries that many programs in /usr depend on in /lib. Especially bad for Gentoo - libraries in /lib may be recompiled as same-version variants if you want to change the USE flags, resulting in clients that don't synchronously recompile their own libraries in /lib to both silently and noisily fail. In other words, many programs in /usr in practice are functionally inseparable from the libraries in /, conflicting with the notion that they were properly shared in the first place. There are certain implicit assumptions made in the spec that are important. First, it's assumed the binaries are compatible with all the hosts. It's assumed you're not sharing s360 binaries with x86 hosts, or sparc binaries with ppc hosts. From there, it's reasonable to assume that the authors of the spec assume the administrator to be smart enough to not do things like: * Mix compiler versions * Mix program compile options * Place a dependency on a binary that's going to be missing. The spec is very, very much a do what you want within these guidelines; don't shoot yourself in the foot thing, it's very much not a declarative bikeshedding of everything related to it. Unfortunately, FHS actually does
Re: Should /usr be merged with /? (Was: Re: [gentoo-user] Re: Anyone switched to eudev yet?)
On Sat, Dec 29, 2012 at 1:33 AM, Bruce Hill da...@happypenguincomputers.com wrote: Dang, I got an Excedrin® headache! Heh. Mike said he was game. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: Should /usr be merged with /? (Was: Re: [gentoo-user] Re: Anyone switched to eudev yet?)
On Fri, Dec 28, 2012 at 12:46 PM, Mark David Dumlao madum...@gmail.com wrote: On Sat, Dec 29, 2012 at 1:33 AM, Bruce Hill da...@happypenguincomputers.com wrote: Dang, I got an Excedrin® headache! Heh. Mike said he was game. It's going to have to wait a bit. I'm not going to be able to get to this this weekend, most likely; the level of detail involved is higher. :) But, thank you. Also, I recommend you give a full read of 2.3, as I'm going to be referencing both it and its substance. -- :wq
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 2012-12-28 00:24, Canek Peláez Valdés wrote: Well, yeah, that's the point. I want to install Gentoo in my mother's PC, and never have to go to her house because someting broke. I really don't have the time nor the inclination to continue this but... Why would you in that case install Gentoo and not Fedora? They (Fedora) do the kitchen-and-sink-installation with systemd, which begs the question: Why are you using Gentoo in the first place? I'm asking because I honestly don't see why you would want to use it if you just don't want to care about how the system works... Also, all your technical arguments are not really technical at all; It's merely a differing (from mine) philosophical view on how you think a operating system should work (the details on how to solve that is technical on the other hand). Which is what I was trying to show you with my first reply... although a bit convoluted perhaps. And on another note: https://en.wikipedia.org/wiki/Fanboy#Fanboy.2Ffangirl I don't really care about what init system I use but I do know what I don't want and that's systemd. But I am a fanboy of Unix philosophy[1]: keep it simple, programs do one thing and do it well, clean interfaces, portability etc... (see how systemd doesn't fit that?). So you can call me a fanboy too if you like, I don't care. https://en.wikipedia.org/wiki/Unix_philosophy Best regards Peter K
Re: Should /usr be merged with /? (Was: Re: [gentoo-user] Re: Anyone switched to eudev yet?)
On Sat, 29 Dec 2012 01:16:34 +0800 Mark David Dumlao madum...@gmail.com wrote: whatever filesystem type it is. Following this, for any distro to correctly FHS, there needs to be a package manager switch to copy arbitrary packages (and dependent libraries) from /usr to /. As of yet not implemented. Not at all, FUSE is a userspace flesystem meant to be used after single user. The spec says you have to be able to mount other filesystems not all other filesystems. I'd like to see you mount an OpenBSD ffs partition. So no your point does not stand. As has already been said the cure is worse than the disease many of which have been demonstrated to amount to exactly nothing in all cases and likely why Greg refused to specify what was broken. You've completely ignored the part of FHS about the root filesystem and completely made up your own rules to justify Linux having management problems that some irresponsible devs chose to enforce upon all and now eudev is working to fix and bring the core of linux back into compliance and higher reliability. I'm not surprised Michael can't be bothered to reply. I would use your time more constructively than responding to this thread pollution in any comprehensive manner.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Thu, 27 Dec 2012 17:38:15 -0600 Canek Peláez Valdés can...@gmail.com wrote: In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, Please explain, sure there is the environment that tells a daemon what to do. No shell can tell a c daemon like sshd how to drop priviledges or use systrace but it could do these things for it in a more fine grained manner before it tries and fails itself or if the daemon wishes it to like monit. It's still not telling how but duplicating or removing the need. That's just a bonus that applies to all init systems because shell is so powerful on unix.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 12/28/12 13:15, pk wrote: On 2012-12-28 00:24, Canek Peláez Valdés wrote: Well, yeah, that's the point. I want to install Gentoo in my mother's PC, and never have to go to her house because someting broke. I really don't have the time nor the inclination to continue this but... Why would you in that case install Gentoo and not Fedora? They (Fedora) do the kitchen-and-sink-installation with systemd, which begs the question: Why are you using Gentoo in the first place? I'm asking because I honestly don't see why you would want to use it if you just don't want to care about how the system works... This has nothing to do with (e)udev, but Gentoo is actually easier to keep working than any of the distributions that change everything all at once on a Monday morning. Fedora et al. are only easier to maintain for friends/family if you don't plan on having the machine (or friend) for more than a year.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 12:15 PM, pk pete...@coolmail.se wrote: On 2012-12-28 00:24, Canek Peláez Valdés wrote: Well, yeah, that's the point. I want to install Gentoo in my mother's PC, and never have to go to her house because someting broke. I really don't have the time nor the inclination to continue this but... Why would you in that case install Gentoo and not Fedora? Because I prefer Gentoo? 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-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 27 Dec 2012 17:38:15 -0600 Canek Peláez Valdés can...@gmail.com wrote: In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, Please explain, sure there is the environment that tells a daemon what to do. No shell can tell a c daemon like sshd how to drop priviledges or use systrace but it could do these things for it in a more fine grained manner before it tries and fails itself or if the daemon wishes it to like monit. It's still not telling how but duplicating or removing the need. That's just a bonus that applies to all init systems because shell is so powerful on unix. Stop thinking in sshd. I can write the *whole* daemon in shell, not in another script file, but inside /etc/init.d/mystupiddaemon (or /etc/rc.whatever); shell is Turing-complete, I can write in it anything I can write in C (or in assembler, or machine code). In that sense, the init system (which uses shell for launching daemons) can be used to determine *how* the daemon behaves (because it uses shell for launching daemons). You can't do that with systemd; there is a clear and unavoidable separation between the starting/stoping/monitoring of daemons, and the daemons themselves. Such distinction doesn't really exists in SysV nor OpenRC (since they use shell, a Turing-complete language, for launching daemons), and therefore you can mixup everything. I agree, it doesn't necessarily means that it *will* happen; but even the possibility is frigthning for a system administrator in a production server. With systemd, that possibility *doesn't exist* (because it doesn't uses a Turing-complete language to start/stop/monitor daemons). Like the clear separation between content and presentation in webapps, or between the model and the view in the MVC design patter, having a clear separation between how you start/stop/monitor your daemon, and what the daemon does, is a good thing. If you don't agree with that, well, we must agree to disagree. 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-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Dec 29, 2012 2:18 AM, Canek Peláez Valdés can...@gmail.com wrote: Stop thinking in sshd. I can write the *whole* daemon in shell, not in another script file, but inside /etc/init.d/mystupiddaemon (or /etc/rc.whatever); shell is Turing-complete, I can write in it anything I can write in C (or in assembler, or machine code). In that sense, the init system (which uses shell for launching daemons) can be used to determine *how* the daemon behaves (because it uses shell for launching daemons). You can't do that with systemd; there is a clear and unavoidable separation between the starting/stoping/monitoring of daemons, and the daemons themselves. Such distinction doesn't really exists in SysV nor OpenRC (since they use shell, a Turing-complete language, for launching daemons), and therefore you can mixup everything. I agree, it doesn't necessarily means that it *will* happen; but even the possibility is frigthning for a system administrator in a production server. You got it wrong. SysAdmins, especially Enterprise SysAdmins, will prefer total control of the startup process. If a daemon is extremely important for enterprise operation, any SysAdmin worth his/her salary will fire up vi (or emacs) and pepper the code with asserts and instrumentation. Having a Turing-complete language for starting a script is one of our (= Enterprise SysAdmins) weapon for fixing up glitches due to some changes introduced by the package maintainer. An example: A dev needs a newer version of a package. We upgrade it. It refuses to startup properly, but going back is out of the question because the dev *needs* the features only available in the new version. We check the (extremely) detailed logs. We find out what made the package balked. We do some changes, and all is well. Another example: After a security audit, we are required to upgrade a certain daemon to a new version, despite the current version running well. As we feared, the new version can't start. We use the detailed log to find out what happened. We made changes. It works again. In the two examples I give, having a C program doing all the starting will certainly mean that complex things have to be done, not to mention the headache of compiling them -- and possibly fail. sh scripts are much easier to modify. Like the clear separation between content and presentation in webapps, or between the model and the view in the MVC design patter, having a clear separation between how you start/stop/monitor your daemon, and what the daemon does, is a good thing. That is the Theory. In Practice, things don't work that way. Murphy's Law reigns supreme. Rgds, --
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 2:17 PM, Pandu Poluan pa...@poluan.info wrote: On Dec 29, 2012 2:18 AM, Canek Peláez Valdés can...@gmail.com wrote: Stop thinking in sshd. I can write the *whole* daemon in shell, not in another script file, but inside /etc/init.d/mystupiddaemon (or /etc/rc.whatever); shell is Turing-complete, I can write in it anything I can write in C (or in assembler, or machine code). In that sense, the init system (which uses shell for launching daemons) can be used to determine *how* the daemon behaves (because it uses shell for launching daemons). You can't do that with systemd; there is a clear and unavoidable separation between the starting/stoping/monitoring of daemons, and the daemons themselves. Such distinction doesn't really exists in SysV nor OpenRC (since they use shell, a Turing-complete language, for launching daemons), and therefore you can mixup everything. I agree, it doesn't necessarily means that it *will* happen; but even the possibility is frigthning for a system administrator in a production server. You got it wrong. I don't believe so. SysAdmins, especially Enterprise SysAdmins, will prefer total control of the startup process. If a daemon is extremely important for enterprise operation, any SysAdmin worth his/her salary will fire up vi (or emacs) and pepper the code with asserts and instrumentation. Pandou, I have worked as SysAdmin. Several years. Total control has degrees; if you program in assembly language, you have even more control. And with systemd you can still fire up vi or Emacs (or, if you prefer total control, ed), and fix *your* daemon. If systemd has a bug, you can still look at the code, and fix *that* code. What you say doesn't make any sense: any SysAdmin worth his/her salary will fire up vi (or emacs) and pepper the code with asserts and instrumentation works in SysV, OpenRC, systemd, and anything else as long as you have the source code. The only problem resides in proprietary code. Having a Turing-complete language for starting a script is one of our (= Enterprise SysAdmins) weapon for fixing up glitches due to some changes introduced by the package maintainer. Again, you make no sense: you can fix glitches as long as you have the source code. You can roll your own packages (I maintain my overlay to get rid of OpenRC on my systems). That some SysAdmins can *only* code properly (if at all) in shell is a problem of *those* SysAdmins. A worthy SysAdmin, if encountering a bug with systemd, can easily check out the C code and fix it (it's relatively simple, not kernel-level). And having a separation between the starting/stoping of daemons and the daemons themselves makes it easier to check where the bug lies, and fixing accordingly, instead of patching blindly to workaround the real problem. An example: A dev needs a newer version of a package. We upgrade it. It refuses to startup properly, but going back is out of the question because the dev *needs* the features only available in the new version. We check the (extremely) detailed logs. We find out what made the package balked. We do some changes, and all is well. How that is not possible in systemd? Another example: After a security audit, we are required to upgrade a certain daemon to a new version, despite the current version running well. As we feared, the new version can't start. We use the detailed log to find out what happened. We made changes. It works again. How that is not possible in systemd? Have you ever used it? In the two examples I give, having a C program doing all the starting will certainly mean that complex things have to be done, not to mention the headache of compiling them -- and possibly fail. You are assuming the problem is going to be in systemd's side. First of all, that will not always be the case. Second, if it is the case, you go and fix it. You still have the code. SysAdmin's laziness is not an excuse to do things wrong. It's also more complex to add comments to the code, it's more complex to take notes of the procedures rolling servers, it's more complex to keep a database of the versions running in each machine, and what hardware has and when it was installed. It's always more complex to properly do the job. sh scripts are much easier to modify. Read above. Like the clear separation between content and presentation in webapps, or between the model and the view in the MVC design patter, having a clear separation between how you start/stop/monitor your daemon, and what the daemon does, is a good thing. That is the Theory. In Practice, things don't work that way. Murphy's Law reigns supreme. Then we should agree to disagree in this particular issue. 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-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 2012-12-28 20:01, Canek Peláez Valdés wrote: Because I prefer Gentoo? That's what I really don't understand! You say you don't want to care about the system which implies Fedora or any other install-and-forget distro. I care about the system which is why I run Gentoo. Do you have USE=* in make.conf too? That last part is not to be taken seriously but that's (basically) what the masses are running (and from what I can interpret your emails that's what you want). I'm done, thanks for listening. Best regards Peter K
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, 28 Dec 2012 13:14:46 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 27 Dec 2012 17:38:15 -0600 Canek Peláez Valdés can...@gmail.com wrote: In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, Please explain, sure there is the environment that tells a daemon what to do. No shell can tell a c daemon like sshd how to drop priviledges or use systrace but it could do these things for it in a more fine grained manner before it tries and fails itself or if the daemon wishes it to like monit. It's still not telling how but duplicating or removing the need. That's just a bonus that applies to all init systems because shell is so powerful on unix. Stop thinking in sshd. I can write the *whole* daemon in shell, not in another script file, but inside /etc/init.d/mystupiddaemon (or /etc/rc.whatever); shell is Turing-complete, I can write in it anything I can write in C (or in assembler, or machine code). In that sense, the init system (which uses shell for launching daemons) can be used to determine *how* the daemon behaves (because it uses shell for launching daemons). That's what you meant, how disappointing. Yeah I've knocked up a few very useful ones myself but call them scripts (Such as grepping logs or dns servers and feeding real daemons with info). You can't do that with systemd; there is a clear and unavoidable You can't is better is it? Yet you can exec a daemon written in shell with systemd. separation between the starting/stoping/monitoring of daemons, and the daemons themselves. Such distinction doesn't really exists in SysV nor OpenRC (since they use shell, a Turing-complete language, for With regular expressions to get the exact pid but /usr/sbin/sshd -f /etc/ssh/sshd_config = start /usr/bin/pkill sshd = stop or many other incantations There are many tools that do this job just fine. If systemd just did this and was there by default I would consider replacing monit with it. Like a reliable root filesystem I want a reliable pid 1. launching daemons), and therefore you can mixup everything. I agree, it doesn't necessarily means that it *will* happen; but even the possibility is frigthning for a system administrator in a production server. With systemd, that possibility *doesn't exist* (because it doesn't uses a Turing-complete language to start/stop/monitor daemons). Doesn't frighten me one bit. I know the startup almost inside out of my servers, doesn't take long on OpenBSD. On Linux it would take longer but nowhere near reviewing systemd and knowing C has nothing to do with the immediate control shell can provide under any init system including systemd but the Turing complete argument is simply propaganda as well as all the features to distract from the fundamental flaws in the design of systemd. Like the clear separation between content and presentation in webapps, or between the model and the view in the MVC design patter, having a clear separation between how you start/stop/monitor your daemon, and what the daemon does, is a good thing. If you don't agree with that, well, we must agree to disagree. There is nothing else, you exec or parse a script or daemon just as systemd does. The only difference is systemd tracking double forked processes with cgroups and I have already provided a link that refutes any point to do so. There are corner cases that are easily manageable and it certainly isn't worth the sacrifice of POSIX compatibility and so Linux applicability. Linus has said cgroups are a horrible but necessary evil, which in my opinion means avoid them unless you have no choice. There is a perfectly good and in my opinion superior choice, but I love simplicity, it has served me well.
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, 27 Dec 2012 11:02:54 -0800, Mark Knecht wrote: Again, I don't really care about the pain - in a sick sense I sort of like it (more if it wore high heels...) - but I'm gonna learn this initramfs stuff and make it work because I suspect it's at least a good thing to know. I said the files worked for me, I never said they worked first time :) Like you, I tried it more as a learning exercise when the whole udev/init thingy first came up. -- Neil Bothwick WinErr 018: Unrecoverable error - System has been destroyed. Buy a new one. Old Windows licence is not valid anymore. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 4:40 PM, pk pete...@coolmail.se wrote: On 2012-12-28 20:01, Canek Peláez Valdés wrote: Because I prefer Gentoo? That's what I really don't understand! You say you don't want to care about the system which implies Fedora or any other install-and-forget distro. I care about the system which is why I run Gentoo. Do you have USE=* in make.conf too? That last part is not to be taken seriously but that's (basically) what the masses are running (and from what I can interpret your emails that's what you want). I have USE=-kde -qt4 in my desktop/laptop. Last time I tried that with RedHat and Mandrake (many, *many* years ago), it wasn't easy, and I'm not certain that it is possible. Like everyone here, I use Gentoo for it's flexibility at the moment of configuring it. That doesn't mean I want to keep track of absolutely everything in my machines; I love to set them up. Once. Then I love to forget about them; they should just work. I'm done, thanks for listening. Thanks to you. 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-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 5:23 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Fri, 28 Dec 2012 13:14:46 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 27 Dec 2012 17:38:15 -0600 Canek Peláez Valdés can...@gmail.com wrote: In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, Please explain, sure there is the environment that tells a daemon what to do. No shell can tell a c daemon like sshd how to drop priviledges or use systrace but it could do these things for it in a more fine grained manner before it tries and fails itself or if the daemon wishes it to like monit. It's still not telling how but duplicating or removing the need. That's just a bonus that applies to all init systems because shell is so powerful on unix. Stop thinking in sshd. I can write the *whole* daemon in shell, not in another script file, but inside /etc/init.d/mystupiddaemon (or /etc/rc.whatever); shell is Turing-complete, I can write in it anything I can write in C (or in assembler, or machine code). In that sense, the init system (which uses shell for launching daemons) can be used to determine *how* the daemon behaves (because it uses shell for launching daemons). That's what you meant, how disappointing. Yeah I've knocked up a few very useful ones myself but call them scripts (Such as grepping logs or dns servers and feeding real daemons with info). You can't do that with systemd; there is a clear and unavoidable You can't is better is it? Yet you can exec a daemon written in shell with systemd. separation between the starting/stoping/monitoring of daemons, and the daemons themselves. Such distinction doesn't really exists in SysV nor OpenRC (since they use shell, a Turing-complete language, for With regular expressions to get the exact pid but /usr/sbin/sshd -f /etc/ssh/sshd_config = start /usr/bin/pkill sshd = stop or many other incantations There are many tools that do this job just fine. If systemd just did this and was there by default I would consider replacing monit with it. Like a reliable root filesystem I want a reliable pid 1. launching daemons), and therefore you can mixup everything. I agree, it doesn't necessarily means that it *will* happen; but even the possibility is frigthning for a system administrator in a production server. With systemd, that possibility *doesn't exist* (because it doesn't uses a Turing-complete language to start/stop/monitor daemons). Doesn't frighten me one bit. I know the startup almost inside out of my servers, doesn't take long on OpenBSD. On Linux it would take longer but nowhere near reviewing systemd and knowing C has nothing to do with the immediate control shell can provide under any init system including systemd but the Turing complete argument is simply propaganda as well as all the features to distract from the fundamental flaws in the design of systemd. Like the clear separation between content and presentation in webapps, or between the model and the view in the MVC design patter, having a clear separation between how you start/stop/monitor your daemon, and what the daemon does, is a good thing. If you don't agree with that, well, we must agree to disagree. There is nothing else, you exec or parse a script or daemon just as systemd does. The only difference is systemd tracking double forked processes with cgroups and I have already provided a link that refutes any point to do so. There are corner cases that are easily manageable and it certainly isn't worth the sacrifice of POSIX compatibility and so Linux applicability. Linus has said cgroups are a horrible but necessary evil, which in my opinion means avoid them unless you have no choice. There is a perfectly good and in my opinion superior choice, but I love simplicity, it has served me well. I don't doub it. As I said, the only thing to do is to agree to disagree. 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-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Sat, Dec 29, 2012 at 4:17 AM, Pandu Poluan pa...@poluan.info wrote: An example: A dev needs a newer version of a package. We upgrade it. It refuses to startup properly, but going back is out of the question because the dev *needs* the features only available in the new version. We check the (extremely) detailed logs. We find out what made the package balked. We do some changes, and all is well. Another example: After a security audit, we are required to upgrade a certain daemon to a new version, despite the current version running well. As we feared, the new version can't start. We use the detailed log to find out what happened. We made changes. It works again. In the two examples I give, having a C program doing all the starting will certainly mean that complex things have to be done, not to mention the headache of compiling them -- and possibly fail. You obviously haven't the slightest _clue_ what the hell you're talking about. 1) systemd does not prevent you from checking logs. If anything the systemd journal gives you more fine-grained tools for ensuring that some logs came from some daemon, not so easy to ensure when your log file is being peppered with auth attempts and whatnot. 2) the make some changes part you mentioned has little, if anything, to do with the init script that started it. Any Enterprise SysAdmin worth his salt, to use your term, knows it's 99% something he overlooked in the config settings that are independent of the startup system. 3) Having a C program doing all the starting doesn't imply complex things have to be done, because in most cases your startup script - whatever it's written in - simply calls the program with the right arguments. Ironically, shell scripts only appear simpler because _someone has already done the complex things for you_. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: Should /usr be merged with /? (Was: Re: [gentoo-user] Re: Anyone switched to eudev yet?)
On Sat, Dec 29, 2012 at 2:53 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Sat, 29 Dec 2012 01:16:34 +0800 Mark David Dumlao madum...@gmail.com wrote: whatever filesystem type it is. Following this, for any distro to correctly FHS, there needs to be a package manager switch to copy arbitrary packages (and dependent libraries) from /usr to /. As of yet not implemented. Not at all, FUSE is a userspace flesystem meant to be used after single user. The spec says you have to be able to mount other filesystems not all other filesystems. I'd like to see you mount an OpenBSD ffs partition. If other filesystems is not qualified (and it is not), normal English rules would have it mean all other filesystems which I take to mean all other filesystems on the system. Can you justify a better interpretation? IF the system's /home directory is formatted as an OpenBSD partition, then yes, FHS demands that tools for mounting and recovering it be in /. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: Should /usr be merged with /? (Was: Re: [gentoo-user] Re: Anyone switched to eudev yet?)
On Sat, 29 Dec 2012 12:27:03 Mark David Dumlao wrote: On Sat, Dec 29, 2012 at 2:53 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Sat, 29 Dec 2012 01:16:34 +0800 Mark David Dumlao madum...@gmail.com wrote: whatever filesystem type it is. Following this, for any distro to correctly FHS, there needs to be a package manager switch to copy arbitrary packages (and dependent libraries) from /usr to /. As of yet not implemented. Not at all, FUSE is a userspace flesystem meant to be used after single user. The spec says you have to be able to mount other filesystems not all other filesystems. I'd like to see you mount an OpenBSD ffs partition. If other filesystems is not qualified (and it is not), normal English rules would have it mean all other filesystems which I take to mean all other filesystems on the system. Can you justify a better interpretation? The latest FHS dates from 2004, the same year as the *earliest* FUSE release I can see on the FUSE web site. I'd say a good working hypothesis is that FHS was simply written *before* any user-space file systems were more than an experimental oddity. IF the system's /home directory is formatted as an OpenBSD partition, then yes, FHS demands that tools for mounting and recovering it be in /. I'd certainly be happy fixing FHS to say that tools for mounting and recovering essential system partitions be located in /, and that these essential system partitions contain the tools for mounting and recovering non-essential partitions. If you are wondering where I stand, I currently boot with an initramfs, since I have everything except /boot located on LVM devices. This includes / and a seperate /usr, done mostly from habit after 15 years of habit, and working where that was the corporate standard production practice. As to system recovery, nowdays I ususlly do that by booting from a live CD/DVD so I have access to all the tools when I need them. Which reminds me that I need to update my rescue DVD to the latest version... -- Reverend Paul Colquhoun, ULC.http://andor.dropbear.id.au/~paulcol Asking for technical help in newsgroups? Read this first: http://catb.org/~esr/faqs/smart-questions.html#intro
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 2012-12-27 02:14, Canek Peláez Valdés wrote: I really think that's the crux of the matter Pandou: udev/systemd serves to the wants of the many. The eudev fork serves to the wants of systemd+udev serves the large mass (users of mainly Fedora and other distros using systemd) that doesn't care/know computers. a very few which really don't want an initramfs, when it has a lot of technical advantages. It has some problems, of course, but we can solve those, and solve the problem *in the general case*. Which is the one that it's important ant interesting. It's unimportant and uninteresting on the terms that Poettering/Sievers/Greg KH put forward, for us that wants control and does not want an all singing and dancing system (incl. kitchen sink). In my opinion the init system should be completely independent of the kernel with a well defined, generic, interface so that the user can choose and pick whatever pieces he/she wishes to run his system. Think Lego (as in small, well defined pieces that fit together in any way the user sees fit)... my wishing luck to the eudev fork (which, BTW, Greg also did). The few The way I read Greg's good luck was that it had quite a bit of a sarcastic tone... Was there really any need for him to say anything at all? I've previously had a lot of respect for Greg but this made me think quite a lot less of him... of us who *dare* to praise udev/systemd get an incredible amount of crap for it. We are nothing but fanbois or, in your words, udev has become like the cosmos: everything there is, and ever shall be. Really? I didn't knew that. You really sound like a fanboy... And I don't mean that in a derogatory way; it's just how I see your writing... Maybe we are doing it wrong. But as far as i can see, we are only expressing our opinion on technical grounds. We are not calling names Your opinions (technical or not) doesn't matter to me since (it seems) you have a very different goal than me with your system. I want you to enjoy whatever system you use but you shouldn't try to force that same system on to me. In that regard I see the eudev fork as a saviour. These are the technical grounds that I've seen you state: * fast boot time Irrelevant, BIOS/UEFI/card firmware takes longer time than booting to XDM for me. The few seconds that it takes to boot from grub to login is of no matter (to me). * parallel service startup Nice to have but still irrelevant, see above. Sequential is also preferred from a trouble shooting perspective. Furthermore I like having the ability to stop a particular daemon if there something that needs fixing (pushing I when booting). * simple service unit files Simplicity is fine but to accomplish the same in your simple service file as in the example you brought forward (sshd) you need to hide a lot of stuff elsewhere. Not for me thanks, I'm a control freak. * good documentation I haven't read it so I won't touch this. Not a technical point though, more of an opinion. Although I agree that good documentation is very nice to have. * Really good in-site customization If I choose to upgrade a daemon, I should be interested in what changes, if any, that brings in configuration in order to not have any surprises later. If you think that's a good thing, that really sounds like you would be doing the OpenRC equivalent of: 'etc-update --automode -5' * control groups As I understand it, this depends on someone writing config files for the individual daemons. Noone is stopping Gentoo devs or anyone else from writing such. And I would, again, prefer to go through a good manual or a howto and do it myself so that I can understand the consequences, if I would want it. * unification I've tried quite a few distros over the years (starting with Redhat in the late 90'ies) and Gentoos OpenRC is by far the most sane system I've come across. Never going back to Redhat hell thank you! Standardizing the interfaces is fine but it's not ok to force a whole kitchen and sink solution in order to satisfy as many as possible. This is not the Gentoo way, as I understand it. Gentoo is all about choice. * you tell the daemon *what* to do, not *how* to do it It's good if you don't want to learn about what things you install and understand what the consequences are of different choices, in the config files. I run very few daemons on my desktop machine so it's not so time consuming to read up on/fix things etc. If I ever were to run a full blown server (esp. connected to the net) with lots of daemons I would be very hesitant to use any pre-configurations, seems suicidal to me. The only usage I see here of declarative scripts are when you don't care about what the machine is doing. Best regards Peter K
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Mark David Dumlao wrote: On Thu, Dec 27, 2012 at 4:42 AM, Dale rdalek1...@gmail.com wrote: Mark David Dumlao wrote: On Tue, Dec 25, 2012 at 10:38 AM, Dale rdalek1...@gmail.com wrote: Feel free to set me straight tho. As long as you don't tell me my system is broken and has not been able to boot for the last 9 years without one of those things. ROFL Nobody's telling you _your_ system, as in the collection of programs you use for your productivity, is broken. What we're saying is that _the_ system, as in the general practice as compared to the specification, is broken. Those are two _very_ different things. From what I have read, they are saying what has worked for decades has been broken the whole time. Doesn't matter that it works for millions of users, its broken. Yes, that is exactly what they are saying. What I am pointing out, however, is that there is, informally, a _technical meaning_ for the word broken, which is that the specs don't match the implementation. And in the case of /usr, the specs don't match the implementation. For like, maybe all of the Linuxen. They say it is broken so they can fix it with a init thingy for EVERYONE. Sorry, that's like telling me my car has been broken for the last ten years when I have been driving it to town and it runs just fine. NOBODY is telling you your system or that the systems of millions of users out there aren't booting. You're assigning emotional baggage to technical language. To push your analogy, oh, your car is working just fine. Now anyone with a pair of spark plugs and a few tools may be able to start it without you, but your startup _works_. Now imagine some German engineer caring nothing about you lowly driver, and caring more about the car as a system, and he goes using fancy words like authentication systems and declaring that all cars have a flaw, or more incensingly, car security is fundamentally broken (Cue angry hordes of owners pitchfork and torching his house). Thing is, he's right, and if he worked out some way for software to verify that machine startup was done using the keys rather than spark plugs, he'd be doing future generations a favor in a dramatic reduction of carjackings. And if somehow it became mandated for future cars to have this added in addition to airbags and whatnot, it'd annoy the hell out of car makers but overall still be a good thing. And here the analogy is holding up: NOBODY is breaking into your car and forcefully installing some authentication system in its startup. And NOBODY is breaking into your servers and forcing you to switch to udev/systemd or merged /usr. You can still happily plow along with your system as is. Heck, you can even install current udev without changing your partition setup. Just modify the ebuild and have it install it into / instead of /usr. Or use an early bootup script. Or use an init thingy. The udev/systemd people sound like politicians. If anything, Lennart is the worst possible politician on the planet. He makes unpopular decisions, mucks around in stuff people don't want touched, talks snide and derisively, etc etc etc, because he's a nerd's nerd that knows nothing about PR and goodwill. The software is good, but that's about all he knows how to write. He's like DJB on crack. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none I think your analogy actually proves my point. Instead of just getting in the car and turning the key, they want to reinvent the engine and how it works. It doesn't matter that it is and has been working for decades, Thanks for proving my point tho. LOL Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 8:13 AM, Dale rdalek1...@gmail.com wrote: I think your analogy actually proves my point. Instead of just getting in the car and turning the key, they want to reinvent the engine and how it works. It doesn't matter that it is and has been working for decades, Thanks for proving my point tho. LOL Dale hehe!! I guess you ain't one of those 'Global Warming' loonies that thinks our precious gas guzzling, smog belching cars are melting the glaciers and creatin' lots o' them hurricanes, 'eh? ;-) Sometimes technology just needs to move forward, but that doesn't mean you can't hold on to your musket and shoot them darn carpetbaggers if they trespass on your lawn, right? - Mark
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
Again you don't break the spec unless you have to and you don't change the spec unless it is an improvement or you have no choice. Non of which is the case. Just like you do not mould a mail RFC to a widely used technically inferior hotmail implementation. He's like DJB on crack. Except DJB made every Linux system on this planet more reliable simple and secure through better coding practices and pointing out how buggy sendmail was. Lennart if anything will accomplish the exact opposite where systemd is used. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
* Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then Kevin started to suggest that I know nothing about init systems, and I responded in kind. I did not and apologise if you took offense. I said perhaps badly that based on this posting, you don't have a great deal of experience in init systems. To me, your comment demonstrated that you don't on the vast plethora of init systems which all actually accomplish the same thing daemon wise just with varying reliability and functionality surrounding the process of doing so. No init system can tell a daemon how to do anything. So your comment. What to do, how to do actually has nothing to do with systemd. What does is having to learn a new more restrictive non intuitive and non externally useful or non universal *declarative* language. Like polkit/pkexecs javascript vs sudo. I will take sudoers every time and for good reason. Shell scripts usually spiral out of control is just utter FUD. I do realise you didn't originate this FUD, but it shouldn't be spread. Yes some corner case wants in init that some thought impossible in shell can get complex by scripting them but a small c tool following the unix philosophy simply becomes a shell command potentially useful in even unforeseeable cases. We are dealing with simple options meant for admins here. As I said OpenBSDs scripts are usually rediculously simple and should often really be called commands. As others have said the argument of function being in the scripts rather than the daemon is an irrelevance to using systemd. Systemd may try to become the whole OS but I'm fairly sure it hasn't plagiarised the c code to check and deal with ssh keys yet. That is rightly the job of the aptly named ssh-keygen and IMO some very simple shell code. The arch sshd script is only 44 lines and includes more than that to make the output colourful. The gentoo sshd script is actually simple too and doesn't do anything most of the time and is easily modifiable in absolutely predictable ways. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 12:13 AM, Dale rdalek1...@gmail.com wrote: Mark David Dumlao wrote: On Thu, Dec 27, 2012 at 4:42 AM, Dale rdalek1...@gmail.com wrote: Mark David Dumlao wrote: On Tue, Dec 25, 2012 at 10:38 AM, Dale rdalek1...@gmail.com wrote: Feel free to set me straight tho. As long as you don't tell me my system is broken and has not been able to boot for the last 9 years without one of those things. ROFL Nobody's telling you _your_ system, as in the collection of programs you use for your productivity, is broken. What we're saying is that _the_ system, as in the general practice as compared to the specification, is broken. Those are two _very_ different things. From what I have read, they are saying what has worked for decades has been broken the whole time. Doesn't matter that it works for millions of users, its broken. Yes, that is exactly what they are saying. What I am pointing out, however, is that there is, informally, a _technical meaning_ for the word broken, which is that the specs don't match the implementation. And in the case of /usr, the specs don't match the implementation. For like, maybe all of the Linuxen. They say it is broken so they can fix it with a init thingy for EVERYONE. Sorry, that's like telling me my car has been broken for the last ten years when I have been driving it to town and it runs just fine. NOBODY is telling you your system or that the systems of millions of users out there aren't booting. You're assigning emotional baggage to technical language. To push your analogy, oh, your car is working just fine. Now anyone with a pair of spark plugs and a few tools may be able to start it without you, but your startup _works_. Now imagine some German engineer caring nothing about you lowly driver, and caring more about the car as a system, and he goes using fancy words like authentication systems and declaring that all cars have a flaw, or more incensingly, car security is fundamentally broken (Cue angry hordes of owners pitchfork and torching his house). Thing is, he's right, and if he worked out some way for software to verify that machine startup was done using the keys rather than spark plugs, he'd be doing future generations a favor in a dramatic reduction of carjackings. And if somehow it became mandated for future cars to have this added in addition to airbags and whatnot, it'd annoy the hell out of car makers but overall still be a good thing. I think your analogy actually proves my point. Instead of just getting in the car and turning the key, they want to reinvent the engine and how it works. It doesn't matter that it is and has been working for decades, I think your reaction proves my point about angry mobs torching his home without understanding what's being proposed. Your fine reading comprehension once again failed to catch the notion that in my analogy, all he invented was a mechanism that makes sure it was a key, not a spark plug, that did the starting. i.e., you're asking literally for a turnkey system, and that's literally what he invented, except that the system guarantees that it's a key that was turned. You have not said a THING about your misunderstanding of the use of the word _broken_ and you're continuing to peddle your hate-boner even after it's been shown that you're confused. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Mark David Dumlao wrote: I think your reaction proves my point about angry mobs torching his home without understanding what's being proposed. Your fine reading comprehension once again failed to catch the notion that in my analogy, all he invented was a mechanism that makes sure it was a key, not a spark plug, that did the starting. i.e., you're asking literally for a turnkey system, and that's literally what he invented, except that the system guarantees that it's a key that was turned. You have not said a THING about your misunderstanding of the use of the word _broken_ and you're continuing to peddle your hate-boner even after it's been shown that you're confused. -- This email is: [ ] actionable [ ] fyi [x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate [ ] soon [x] none So I guess Linus is confused to? You think he is just a hate-boner? I would think Linus if anyone knows what he is talking about. Maybe you need to go talk to him about his feeling on the direction of udev/systemd. Good luck with that. Name calling, lost argument. No more facts. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 12:28 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Again you don't break the spec unless you have to and you don't change the spec unless it is an improvement or you have no choice. Non of which is the case. Just like you do not mould a mail RFC to a widely used technically inferior hotmail implementation. The spec - or implementation - of / and /usr separation is broken and has been for quite a while now. Nobody here's even bothered answering how the modern Gentoo distro / sysad would survive /usr being out of sync with /, for instance, or the fact that some udev programs tend to be located in /usr, or even just a solid detailed specification on the precise criteria for inclusion into /. Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. You'd think, for instance, something as clear cut as filesystem manipulation tools, e.g., xfs_admin, would belong in /sbin rather than /usr/sbin. But no it's not. Or - for crying out loud, at least a text editor that isn't ed. Again, the broken state of the / and /usr split is a different thing from the usefulness state of your own already installed distro. TLDR: The spec is broken. He's like DJB on crack. Except DJB made every Linux system on this planet more reliable simple and secure through better coding practices and pointing out how buggy sendmail was. Lennart if anything will accomplish the exact opposite where systemd is used. If you have something more than FUD to back up your technical claims, go ahead. You're directly claiming that wherever systemd is used, the system will be less reliable and secure, and that Lennart isn't pointing out buggy behaviors in - what's the analogue for sendmail? oh yeah - SysVInit scripts. To carry the analogy, DJB's main point was that the size of the code was one of - if not the - most important factors in increasing code quality and security, and worked to make qmail and its configuration about as spartan as you can get. That's kind of the point of systemd unit files, trimming the boilerplate size to reduce gotchas like init scripts failing to detect whether a service is running or not, or if its dependencies have been started. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 2:15 AM, Dale rdalek1...@gmail.com wrote: So I guess Linus is confused to? In your head, and only in your head, you're agreeing with Linus. Linus was talking about a different bug entirely from the one you're talking about. The bug you're talking about: you go on and on about people saying that your personal system is broken when it's been working for years. Again, NOBODY said that. What was said, what you are not able to refute, is that yes, the case for the / and /usr split IS broken, and something needs to be done about that moving forward. Name calling, lost argument. No more facts. I've repeatedly proposed technical solutions to your issues with the fact that udev is doing something about that and you continue to whine all night about the bogey-men breaking into your boxes. In fact, between just you and me, I believe I'm the only one who backed up anything he said with anything even remotely approaching technical merit. 1) initramfs. It's not that hard 2) early mount script. It's not that hard. 3) modify your udev ebuild to install to /. It's not that hard. None of this is being prevented by the vengeful Lennart you're so afraid of. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 1:22 PM, Mark David Dumlao madum...@gmail.comwrote: On Fri, Dec 28, 2012 at 12:28 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Again you don't break the spec unless you have to and you don't change the spec unless it is an improvement or you have no choice. Non of which is the case. Just like you do not mould a mail RFC to a widely used technically inferior hotmail implementation. The spec - or implementation - of / and /usr separation is broken and has been for quite a while now. Nobody here's even bothered answering how the modern Gentoo distro / sysad would survive /usr being out of sync with /, for instance, If the basics are kept in /, with prod-additionals kept in /usr, then you should be able to boot to basics, and restore /usr. or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. So fix it. FHS was a document written to say we have a standard that happened to map almost cleanly to all the implementations of the day. Kinda like how SQL mapped almost cleanly to the existing RDBMSs that existed when it was introduced. Such is how standards documents are born. You'd think, for instance, something as clear cut as filesystem manipulation tools, e.g., xfs_admin, would belong in /sbin rather than /usr/sbin. But no it's not. Or - for crying out loud, at least a text editor that isn't ed. I'd say that warrants bug reports against those programs. Also, isn't busybox under /? I think it has nano built-in. Again, the broken state of the / and /usr split is a different thing from the usefulness state of your own already installed distro. TLDR: The spec is broken. It's not that the spec is broken. It's that the spec doesn't lay out every single detail imaginable, and as a consequence, people assuming that the spec should be able to do their thinking for them assume the spec is broken when it's silent on a given query. -- :wq
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 1:31 PM, Mark David Dumlao madum...@gmail.comwrote: On Fri, Dec 28, 2012 at 2:15 AM, Dale rdalek1...@gmail.com wrote: So I guess Linus is confused to? In your head, and only in your head, you're agreeing with Linus. Linus was talking about a different bug entirely from the one you're talking about. The bug you're talking about: you go on and on about people saying that your personal system is broken when it's been working for years. Again, NOBODY said that. What was said, what you are not able to refute, is that yes, the case for the / and /usr split IS broken, and something needs to be done about that moving forward. Name calling, lost argument. No more facts. I've repeatedly proposed technical solutions to your issues with the fact that udev is doing something about that and you continue to whine all night about the bogey-men breaking into your boxes. In fact, between just you and me, I believe I'm the only one who backed up anything he said with anything even remotely approaching technical merit. 1) initramfs. It's not that hard 2) early mount script. It's not that hard. 3) modify your udev ebuild to install to /. It's not that hard. If you'd read the thread (and/or related ones), you'd know he tried to go the initrd route, and spent a solid week on the project. You're not talking to someone who hasn't tried to tread the path. -- :wq
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 10:41 AM, Michael Mol mike...@gmail.com wrote: SNIP 1) initramfs. It's not that hard 2) early mount script. It's not that hard. 3) modify your udev ebuild to install to /. It's not that hard. If you'd read the thread (and/or related ones), you'd know he tried to go the initrd route, and spent a solid week on the project. You're not talking to someone who hasn't tried to tread the path. hehe! And while I have a initramfs external to 3.2.1 a kernel working on a RAID6 / system, my first attempt at building the initramfs into gentoo-sources-3.6.11 as per Neil's pointers resulted in the RAID6 kicking one drive and not booting, so there is pain out there to be had. ;-) I'll post more in my thread about how I fix it and move forward later. Again, I don't really care about the pain - in a sick sense I sort of like it (more if it wore high heels...) - but I'm gonna learn this initramfs stuff and make it work because I suspect it's at least a good thing to know. It ain't only you Dale. I have (!)fun(!) with this stuff too... ;-) Cheers, Mark
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Am Sonntag, 23. Dezember 2012, 19:03:25 schrieb Nuno J. Silva: Then I suppose you can surely explain in a nutshell why can't init scripts simply do that? because some people decided, that fsck or that dynamic /dev/ populator depends on stuff in /usr? which is the reason for this thread? How do you mount a filesystem if you don't even have a dev node in the first place? -- #163933
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Am Sonntag, 23. Dezember 2012, 19:44:43 schrieb Nuno J. Silva: On 2012-12-23, Alan Mackenzie wrote: On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote: On 2012-12-23, Alan McKinnon wrote: On Sun, 23 Dec 2012 12:22:24 +0200 nunojsi...@ist.utl.pt (Nuno J. Silva) wrote: On 2012-12-18, Alan McKinnon wrote: On Tue, 18 Dec 2012 09:08:53 -0500 Michael Mol mike...@gmail.com wrote: This sentence summarizes my understanding of your post nicely: Now, why is /usr special? It's because it contains executable code the system might require while launching. Now there are only two approaches that could solve that problem: 1. Avoid it entirely 2. Deal with it using any of a variety of bootstrap techniques #1 is handled by policy, whereby any code the system might require while launching is not in /usr. #2 already has a solution, it's called an init*. Other solutions exist but none are as elegant as a throwaway temporary filesystem in RAM. What about just mounting /usr as soon as the system boots? Please read the thread next time. The topic under discussion is solutions to the problem of not being able to do exactly that. Then I suppose you can surely explain in a nutshell why can't init scripts simply do that? Because certain people with influence have rearranged the filesystem so that programs within /usr are absolutely necessary for booting; they are needed _before_ init has a chance to mount /usr. So either /usr has to be in the root partition, or crazy kludges need to be used to mount /usr before the kernel runs init. I surely don't know the udev architecture well enough, but if this is all done by the udev daemon, can't we just mount /usr before the daemon is started? The only needed things should be mount (which is under /bin here) and /etc/fstab. and a device node in /dev - like /dev/sda2. And how do you get that one without udev? oops? -- #163933
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, 27 Dec 2012 20:43:12 +0100, Volker Armin Hemmann wrote: and a device node in /dev - like /dev/sda2. And how do you get that one without udev? CONFIG_DEVTMPFS=y Of course, that only helps if /usr is on a plain old disk block device. -- Neil Bothwick No, you *can't* call 999 now. I'm downloading my mail. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 2:43 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am Sonntag, 23. Dezember 2012, 19:44:43 schrieb Nuno J. Silva: On 2012-12-23, Alan Mackenzie wrote: On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote: On 2012-12-23, Alan McKinnon wrote: On Sun, 23 Dec 2012 12:22:24 +0200 nunojsi...@ist.utl.pt (Nuno J. Silva) wrote: On 2012-12-18, Alan McKinnon wrote: On Tue, 18 Dec 2012 09:08:53 -0500 Michael Mol mike...@gmail.com wrote: This sentence summarizes my understanding of your post nicely: Now, why is /usr special? It's because it contains executable code the system might require while launching. Now there are only two approaches that could solve that problem: 1. Avoid it entirely 2. Deal with it using any of a variety of bootstrap techniques #1 is handled by policy, whereby any code the system might require while launching is not in /usr. #2 already has a solution, it's called an init*. Other solutions exist but none are as elegant as a throwaway temporary filesystem in RAM. What about just mounting /usr as soon as the system boots? Please read the thread next time. The topic under discussion is solutions to the problem of not being able to do exactly that. Then I suppose you can surely explain in a nutshell why can't init scripts simply do that? Because certain people with influence have rearranged the filesystem so that programs within /usr are absolutely necessary for booting; they are needed _before_ init has a chance to mount /usr. So either /usr has to be in the root partition, or crazy kludges need to be used to mount /usr before the kernel runs init. I surely don't know the udev architecture well enough, but if this is all done by the udev daemon, can't we just mount /usr before the daemon is started? The only needed things should be mount (which is under /bin here) and /etc/fstab. and a device node in /dev - like /dev/sda2. And how do you get that one without udev? oops? Yeah, the oops is on the part of the udev team, which decided to put a critical piece of software there. Which is the origin of this whole uproar for the past year or so. -- :wq
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On 2012-12-27, Volker Armin Hemmann wrote: Am Sonntag, 23. Dezember 2012, 19:44:43 schrieb Nuno J. Silva: On 2012-12-23, Alan Mackenzie wrote: On Sun, Dec 23, 2012 at 07:03:25PM +0200, Nuno J. Silva wrote: On 2012-12-23, Alan McKinnon wrote: On Sun, 23 Dec 2012 12:22:24 +0200 nunojsi...@ist.utl.pt (Nuno J. Silva) wrote: On 2012-12-18, Alan McKinnon wrote: On Tue, 18 Dec 2012 09:08:53 -0500 Michael Mol mike...@gmail.com wrote: This sentence summarizes my understanding of your post nicely: Now, why is /usr special? It's because it contains executable code the system might require while launching. Now there are only two approaches that could solve that problem: 1. Avoid it entirely 2. Deal with it using any of a variety of bootstrap techniques #1 is handled by policy, whereby any code the system might require while launching is not in /usr. #2 already has a solution, it's called an init*. Other solutions exist but none are as elegant as a throwaway temporary filesystem in RAM. What about just mounting /usr as soon as the system boots? Please read the thread next time. The topic under discussion is solutions to the problem of not being able to do exactly that. Then I suppose you can surely explain in a nutshell why can't init scripts simply do that? Because certain people with influence have rearranged the filesystem so that programs within /usr are absolutely necessary for booting; they are needed _before_ init has a chance to mount /usr. So either /usr has to be in the root partition, or crazy kludges need to be used to mount /usr before the kernel runs init. I surely don't know the udev architecture well enough, but if this is all done by the udev daemon, can't we just mount /usr before the daemon is started? The only needed things should be mount (which is under /bin here) and /etc/fstab. and a device node in /dev - like /dev/sda2. And how do you get that one without udev? oops? Please try booting your system and getting to a shell before udevd gets started. Then, please do ls /dev. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! However... Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. So fix it. FHS was a document written to say we have a standard that happened to map almost cleanly to all the implementations of the day. Kinda like how SQL mapped almost cleanly to the existing RDBMSs that existed when it was introduced. Such is how standards documents are born. Don't forget that FHS is heavily an after-the-fact descriptive document of what is happening in practice, with heavy rationale sections describing what's going on in the wild. Before you can fix FHS, you first have to fix the practice, then FHS can get amended to reflect what's going on. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Now that doesn't translate to epic disasters of biblical proportion, fire and brimstone, rivers and seas boiling, dogs and cats living together, mass hysteria - because it's just a collection of hard to pin down essential boot programs - but it does translate to an unsustainable practice in distro development / package management. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM Purpose: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. To boot a system, enough must be present on the root partition to mount other filesystems. This includes utilities, configuration, boot loader information, and other essential start-up data. /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. To enable recovery and/or repair of a system, those utilities needed by an experienced maintainer to diagnose and reconstruct a damaged system must be present on the root filesystem. To restore a system, those utilities needed to restore from system backups (on floppy, tape, etc.) must be present on the root filesystem. * some teasers: [1] udev rules themselves being a case in point. I mean, do the requisite binaries belong in /? For example, there's a virtualbox udev rule in /usr that doesn't mount other filesystems or stop udev from starting. However, given the right race conditions, udev will fail to start the requisite script because /usr isn't mounted. [2] fuse-based filesystems allow an administrator the crazy possibility of, for example, demanding that /home be an ssh connection. Should the ssh client belong in /? ftp? substitute any arbitrary client program. [3] a fuse-based filesystem depends on a local network service being started. For example, someone writes a crazy fuse mysql browser that also is coincidentally mounted at boot time. Should the mysqld service belong in /? ldap? substitute any arbitrary server program. [4] /root (which is why it's separated from /home) contains docs and custom utilities used by root user for recovery. Unfortunately, there's a lot of perl scripts there specifically for doing filesystem checks / reports. Should perl be in in /? substitute any scripting language. The point is not whether _you_ can come up with an answer for
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. This came up today on Reddit. I think it's _highly_ relevant. http://www.runswift.ly/solving-bugs.html Moving into a full dependency on initr* for separate /usr is a 'fix', not a solution. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! Does the term overspecification mean anything to you? Specs cannot and should not specify every possible conceivable related thing. However... Even the FHS is mum on all the extra crap we randomly decide between / and /usr to land in. So fix it. FHS was a document written to say we have a standard that happened to map almost cleanly to all the implementations of the day. Kinda like how SQL mapped almost cleanly to the existing RDBMSs that existed when it was introduced. Such is how standards documents are born. Don't forget that FHS is heavily an after-the-fact descriptive document of what is happening in practice, with heavy rationale sections describing what's going on in the wild. Before you can fix FHS, you first have to fix the practice, then FHS can get amended to reflect what's going on. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. Now that doesn't translate to epic disasters of biblical proportion, fire and brimstone, rivers and seas boiling, dogs and cats living together, mass hysteria - because it's just a collection of hard to pin down essential boot programs - but it does translate to an unsustainable practice in distro development / package management. http://www.pathname.com/fhs/pub/fhs-2.3.html#THEROOTFILESYSTEM Purpose: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. To boot a system, enough must be present on the root partition to mount other filesystems. This includes utilities, configuration, boot loader information, and other essential start-up data. /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems. To enable recovery and/or repair of a system, those utilities needed by an experienced maintainer to diagnose and reconstruct a damaged system must be present on the root filesystem. To restore a system, those utilities needed to restore from system backups (on floppy, tape, etc.) must be present on the root filesystem. * some teasers: [1] udev rules themselves being a case in point. I mean, do the requisite binaries belong in /? Udev is a dispatcher. Actually, in substance, it's a piece of the kernel that resides in userland; it exists because it was decided back around the time of devfs that what devfs was doing is something that ought to be outside the kernel. In reality, it's effectively been a userland kernel-support process its entire life. What should probably happen is that udev should be fixed to defer hotplug events until a rules file is able to sucessfully handle it. And rules files should perform sanity checking and
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Mark Knecht wrote: On Thu, Dec 27, 2012 at 10:41 AM, Michael Mol mike...@gmail.com wrote: SNIP 1) initramfs. It's not that hard 2) early mount script. It's not that hard. 3) modify your udev ebuild to install to /. It's not that hard. If you'd read the thread (and/or related ones), you'd know he tried to go the initrd route, and spent a solid week on the project. You're not talking to someone who hasn't tried to tread the path. hehe! And while I have a initramfs external to 3.2.1 a kernel working on a RAID6 / system, my first attempt at building the initramfs into gentoo-sources-3.6.11 as per Neil's pointers resulted in the RAID6 kicking one drive and not booting, so there is pain out there to be had. ;-) I'll post more in my thread about how I fix it and move forward later. Again, I don't really care about the pain - in a sick sense I sort of like it (more if it wore high heels...) - but I'm gonna learn this initramfs stuff and make it work because I suspect it's at least a good thing to know. It ain't only you Dale. I have (!)fun(!) with this stuff too... ;-) Cheers, Mark Well, I have enough pain already. I don't need my computer adding to it. Using something that I shouldn't need and certainly don't want to use is not my first or second option. If I liked pain like that, I'd go break a leg or something. :/ Just saying. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol mike...@gmail.com wrote: On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. This came up today on Reddit. I think it's _highly_ relevant. http://www.runswift.ly/solving-bugs.html Moving into a full dependency on initr* for separate /usr is a 'fix', not a solution. This is where you stumble. It's not a fix. It's a WONTFIX. It's a make a lot of noise so that something else gets fixed because this is outside of our domain and we're not going to be responsible for it as it wasnt our bug in the first place. And that something else happens to be the / and /usr split conflicting with the user programs. If you give the squeaky wheel the grease - as in merge / and /usr - you apply the fix independently of udev, which was simply installed to the /usr prefix. THAT is a solution - one independent of udev and again, does not depend on initr*. You don't have to. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! Does the term overspecification mean anything to you? Specs cannot and should not specify every possible conceivable related thing. Two things. First, I'm not saying that a spec should specify everything. I am saying, however, that there are specific cases that is within its domain to specify and that it should be specifying. And because those cases generate conflicts, the fact that they aren't is a bug. Second, going back to problem solving in general - just because you can put down in words what you think the problem is, doesn't mean you've mapped out an accurate or even consistent statement of the problem. There really are cases where it's not enough to just give general airy abstractions and rules of thumb to map out a problem, where it isn't obvious that you're running into edge cases until you really look at it deeply, and yes, the / and /usr split is one of them. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. The most fundamental and relevant one for us Gentoo users is this: - how can /usr be sharable among different hosts if it depends on libraries in /? http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY Purpose /usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere. Many distros place fundamental libraries that many programs in /usr depend on in /lib. Especially bad for Gentoo - libraries in /lib may be recompiled as same-version variants if you want to change the USE flags, resulting in clients that don't synchronously recompile their own libraries in /lib to both silently and noisily fail. In other words, many programs in /usr in practice are functionally inseparable from the libraries in /, conflicting with the notion that they were properly shared in the first place. Compare this with the
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, 25 Dec 2012 10:56:52 +0700 Pandu Poluan pa...@poluan.info wrote: In case you haven't noticed, since Windows 7 (or Vista, forget which) Microsoft has even went the distance of splitting between C: (analogous to /usr) and 'System Partition' (analogous to /). The boot process is actually handled by the 100ish MB 'System Partition' before being handed to C:. This will at least give SysAdmins a fighting chance of recovering a botched maintenance. (Note: Said behavior will only be visible if installing onto a clean hard disk. If there are partitions left over from previous Windows installs, Win7 will not create a separate 'System Partition') So, if Microsoft saw the light, why does Red Hat sunk into darkness instead? I zone out of work-related stuff for three days to enjoy presents instead, and look what happens to the thread :-) I think I've said all I need to say on this matter, I'm not out to prove any point really and don't have a dog in this fight. I might not agree with how Lennart and RH are proceeding with implementation, but I do agree with the generally stated engineering problem at the core of the debate. I'm not sure about Microsoft's motivations in what you describe. My first reaction is that the Great Circle of IT Life is turning and MS are trying something new for them. Whether it's applicable to us here as an illustration remains to be seen - I know very little about Windows so can't even begin to draw sensible parallels. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Thu, Dec 27, 2012 at 10:00 AM, pk pete...@coolmail.se wrote: On 2012-12-27 02:14, Canek Peláez Valdés wrote: I really think that's the crux of the matter Pandou: udev/systemd serves to the wants of the many. The eudev fork serves to the wants of systemd+udev serves the large mass (users of mainly Fedora and other distros using systemd) that doesn't care/know computers. Well, yeah, that's the point. I want to install Gentoo in my mother's PC, and never have to go to her house because someting broke. a very few which really don't want an initramfs, when it has a lot of technical advantages. It has some problems, of course, but we can solve those, and solve the problem *in the general case*. Which is the one that it's important ant interesting. It's unimportant and uninteresting on the terms that Poettering/Sievers/Greg KH put forward, for us that wants control and does not want an all singing and dancing system (incl. kitchen sink). In my opinion the init system should be completely independent of the kernel with a well defined, generic, interface so that the user can choose and pick whatever pieces he/she wishes to run his system. Think Lego (as in small, well defined pieces that fit together in any way the user sees fit)... And how's that changed? If you want control, you will *always* have control. The source code is out there; what more control do you need? my wishing luck to the eudev fork (which, BTW, Greg also did). The few The way I read Greg's good luck was that it had quite a bit of a sarcastic tone... Was there really any need for him to say anything at all? I've previously had a lot of respect for Greg but this made me think quite a lot less of him... That's how you choose to interpret it, and I'm pretty sure it was not the way Greg said it. of us who *dare* to praise udev/systemd get an incredible amount of crap for it. We are nothing but fanbois or, in your words, udev has become like the cosmos: everything there is, and ever shall be. Really? I didn't knew that. You really sound like a fanboy... And I don't mean that in a derogatory way; it's just how I see your writing... It does sound derogatory... Maybe we are doing it wrong. But as far as i can see, we are only expressing our opinion on technical grounds. We are not calling names Your opinions (technical or not) doesn't matter to me since (it seems) you have a very different goal than me with your system. I want you to enjoy whatever system you use but you shouldn't try to force that same system on to me. In that regard I see the eudev fork as a saviour. What *I* am forcing on *anyone*? How could *I* force *anything* on *anyone*? I'm just stating why I believe udev/systemd is a nice solution to the general problem. That's all: I'm not a developer, I'm not a distro planer; I'm not in any way capable to enforce anything on anyone. And I, if I'm allowed to repeat it, have never called names on anyone. I'm just stating my opinion; how could you twist that into the idea that I'm trying to force that same system on to me? Really? These are the technical grounds that I've seen you state: * fast boot time Irrelevant, BIOS/UEFI/card firmware takes longer time than booting to XDM for me. The few seconds that it takes to boot from grub to login is of no matter (to me). It matters to me. A lot. Specially in my laptop (I follow vanilla-sources unstable, so I reboot relatively often), in my media center (same reasons). In my servers certainly the hardware initialization phase is longer; but (IMO) that makes even more important the speed gains from grub to userspace. Please, understand that my above (↑) reasons doesn't mean I don't care of yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. * parallel service startup Nice to have but still irrelevant, see above. Sequential is also preferred from a trouble shooting perspective. Furthermore I like having the ability to stop a particular daemon if there something that needs fixing (pushing I when booting). Relevant for me, see above. And that's another thing I hate about the shell init scripts; problems get workarounded instead of properly fixed. If there is a problem at boot time *it should be fixed where the problem lives*, not workarounded with shell hackery. Again, please understand that my above (↑) reasons doesn't mean I don't care of yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. * simple service unit files Simplicity is fine but to accomplish the same in your simple service file as in the example you brought forward (sshd) you need to hide a lot of stuff elsewhere. Not for me thanks, I'm a control freak. I'm not; let the machines do the work. The least I have to think about my system, the better; I care only for it to work. Again, please
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Thu, Dec 27, 2012 at 10:29 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then Kevin started to suggest that I know nothing about init systems, and I responded in kind. I did not and apologise if you took offense. Apology accepted, and I also apologise if my response was out of line/with bad tone. I said perhaps badly that based on this posting, you don't have a great deal of experience in init systems. Well, I haven't wrote any, but I used the ones in OpenBSD, Solaris, Linux SysV, OpenRC systemd, and Windows NT. Used as in administering several machines with them. So, I have some experience. To me, your comment demonstrated that you don't on the vast plethora of init systems which all actually accomplish the same thing daemon wise just with varying reliability and functionality surrounding the process of doing so. No init system can tell a daemon how to do anything. You are wrong. In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, and to a lesser degree, it happens when you use a shell to launch daemons. So your comment. What to do, how to do actually has nothing to do with systemd. What does is having to learn a new more restrictive non intuitive and non externally useful or non universal *declarative* language. Like polkit/pkexecs javascript vs sudo. I will take sudoers every time and for good reason. I'm not 100% happy with Polkit use of JS, but having finally understood how it works, I think is kind of nice. I believe role verification and authentication is one of the tasks where a Turing-complete language actually be justified. Shell scripts usually spiral out of control is just utter FUD. I do realise you didn't originate this FUD, but it shouldn't be spread. Yes some corner case wants in init that some thought impossible in shell can get complex by scripting them but a small c tool following the unix philosophy simply becomes a shell command potentially useful in even unforeseeable cases. Funny that you said that; if you are really interested, take a look at /usr/lib/systemd in a systemd machine. Almost all of those are really simple C programs that do one thing, and one thing only. Most of them don't reach the 100 lines of C code. To me, a Turing-complete language for starting and stoping services is overkill. And also there is the Halting Problem; you simply cannot workaround that. We are dealing with simple options meant for admins here. As I said OpenBSDs scripts are usually rediculously simple and should often really be called commands. As others have said the argument of function being in the scripts rather than the daemon is an irrelevance to using systemd. Systemd may try to become the whole OS but I'm fairly sure it hasn't plagiarised the c code to check and deal with ssh keys yet. That is rightly the job of the aptly named ssh-keygen and IMO some very simple shell code. Yeah, running from the install script/Makefile/post-inst-hook/whatever. Not the init system. IMO. The arch sshd script is only 44 lines and includes more than that to make the output colourful. The gentoo sshd script is actually simple too and doesn't do anything most of the time and is easily modifiable in absolutely predictable ways. I'm not arguing that; I'm arguing that it can be done even more simple, and even more easily modifiable. But like a said to Pandou; let's just agree to disagree. 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-user] Re: Anyone switched to eudev yet?
On Mon, 24 Dec 2012 15:14:11 + Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: Are there any other cases, apart from emotional attachment based on inertia, where a separate / and /usr are desirable? As I see it, there is only the system, and it is an atomic unit. You should really read the thread before posting. You quoted a hypothical question I posed[1] which follows directly on from something I described in the previous paragraph. You should really retain context in what you decide to snip, as you have changed the entire meaning and intent of what I said and asked. [1] The question was literally an RFC - a request for people to comment. I have no strict engineering or configuration need for / and /usr to be separate; I know of one setup configuration that requires it, I asked who needs it for different reasons and why - not as a debate point, but as a learning point. Does that sufficiently answer the thought that prompted you to reply? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
Am Donnerstag, 27. Dezember 2012, 07:45:24 schrieb Pandu Poluan: On Dec 26, 2012 1:05 AM, Canek Peláez Valdés can...@gmail.com wrote: Even Linus piped up at one point, sharply reminding Greg KH that even though udev was at one time Greg's 'baby', at this point udev serves only the wants of the few. link? -- #163933
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 02:06:27AM +0100, Volker Armin Hemmann wrote: Am Donnerstag, 27. Dezember 2012, 07:45:24 schrieb Pandu Poluan: On Dec 26, 2012 1:05 AM, Canek Peláez Valdés can...@gmail.com wrote: Even Linus piped up at one point, sharply reminding Greg KH that even though udev was at one time Greg's 'baby', at this point udev serves only the wants of the few. link? Surf around here http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49758/focus%3D55168 -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol mike...@gmail.com wrote: On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao madum...@gmail.com wrote: On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol mike...@gmail.com wrote: or the fact that some udev programs tend to be located in /usr, That's either a bug with those programs, or a need for architectural improvements within udev. Both plausible answers. The most obvious architectural improvement being: simply place udev where all its dependencies are and all those bugs turn to nothing. Which is what the udev guys did. And the part which seems to elude everyone is: it isn't even a limitation of the program. It can still be installed to /. Heck we could probably make a USE=root-prefix flag for udev that installs it to / instead of /usr. This came up today on Reddit. I think it's _highly_ relevant. http://www.runswift.ly/solving-bugs.html Moving into a full dependency on initr* for separate /usr is a 'fix', not a solution. This is where you stumble. It's not a fix. It's a WONTFIX. It's a make a lot of noise so that something else gets fixed because this is outside of our domain and we're not going to be responsible for it as it wasnt our bug in the first place. And that something else happens to be the / and /usr split conflicting with the user programs. I understand that. I made that point myself; that the Gentoo dev moved udev into /usr to reduce the bug passing load on himself. If you give the squeaky wheel the grease - as in merge / and /usr - you apply the fix independently of udev, which was simply installed to the /usr prefix. THAT is a solution - one independent of udev and again, does not depend on initr*. You don't have to. That's one solution, but the cure is worse than the disease. or even just a solid detailed specification on the precise criteria for inclusion into /. For anyone arguing that / and /usr should be separate, the answer to this is that ought to be common sense. Since I'm not someone who knows all there is to know about the software and interactions thereof, the most I can say is: * / ought to contain all binaries, libraries and static data necessary for booting beyond the point where / is mounted, and any machine-specific binaries, libraries and static data. * /usr ought to contain all binaries, libraries and static data not necessary for its own mount. I'm sure you mean well, as did most of the architects of the past, but the reality is, this simplistic take on the problem misses out on some fundamental issues. Yes, you mention later that the spec just doesn't specify what happens in such and such case, and try to trivialize it into saying people think that specs should be able to do their thinking for them. But unfortunately, specifying what happens is exactly what specs are for! Does the term overspecification mean anything to you? Specs cannot and should not specify every possible conceivable related thing. Two things. First, I'm not saying that a spec should specify everything. I am saying, however, that there are specific cases that is within its domain to specify and that it should be specifying. And because those cases generate conflicts, the fact that they aren't is a bug. The spec also doesn't say anything about /usr/lib vs /usr/lib32 vs /usr/lib64, yet decisions about those can also cause conflicts. I suppose you'd argue that that's also a bug. I already gave you a pretty succinct definition of what I thought the treatment of /usr should be. And you quoted FHS on the subject, which was eerily similar to what I described. Now, further down, you actually raise specific issues. Let's focus on those. Second, going back to problem solving in general - just because you can put down in words what you think the problem is, doesn't mean you've mapped out an accurate or even consistent statement of the problem. There really are cases where it's not enough to just give general airy abstractions and rules of thumb to map out a problem, where it isn't obvious that you're running into edge cases until you really look at it deeply, and yes, the / and /usr split is one of them. So let's look at it deeply, since nobody else will. I'm game. This is the most detailed technical discussion of the problem anyone's cared to actually have, as far as I've been able to observe. And the we have a standard part is effectively not true anymore, on the matter of the / and /usr split. That is - what the specification says should happen is not happening, on a massive scale, because it turns out that it's not that trivial to determine which binaries go in / and which go in /usr. Give me an example, and I'll describe a reasonably detailed solution. It would be my pleasure. The most fundamental and relevant one for us Gentoo users is this: - how can /usr be sharable among different
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, 25 Dec 2012 17:26:12 -0600, Bruce Hill wrote: Try reading the kernel Documentation. (e.g., /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.) initramfs is an improvement over initrd. Having read it years ago it still fails to give me a good reason for using it. That's because it's a HOWTO not a WHYTO. If you want or need to use an initramfs that document explains how to use it and how it differs from the old initrd. It is not trying to tell you whether you need it or not, that is your decision. Which I guess shows a difference in attitude between the kernel devs and udev devs. -- Neil Bothwick You are a completely unique individual, just like everybody else. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, 26 Dec 2012 09:54:49 +1100, Paul Colquhoun wrote: Also, if you actually read the linked URL, it does explain it won't fail to boot. You do realize these are two different issues here, right? One is people saying that udev-181 will fail to boot, other is the issue described on the URL linked on the news item, which is about stuff in /usr breaking udev rules, which has been around for a long time and will *silently* fail. I remind you that silently fail implies that your system will still boot, even if it is affected by the issue. So, instead of fixing udev properly, by making the failures visible (as they probably should have been from the start) or even re-queueing the events to be run after the rule files are avaiable, the developers took the easy (for them) way out, and told the rest of the world to do things their way. That all makes sense, although it may well be harder to implement than to suggest. To be fair to the udev developers, we owe them nothing and they are free to take their project in whichever direction they like and spend their time on whatever features they choose to. If we don't like it we can fork it. If eudev works and provides a valid alternative to udev it will simply prove that the open source ecosystem works in a way that all those trying to avoid upgrading from Windows 7 to 8 can't even dream about. There is really no place for the insults and name calling, udev provided us with a great tool that we were happy to use for years, now it is moving in a direction we don't like we can either live with the change or do something about it. Walt chose the latter route and now the eudev guys are following suit - eudev may not be ready for use yet but the devs have already achieved a lot more that all the list complaint and insults ever will. -- Neil Bothwick Quantum leap: (adj.) literally, to move by the smallest amount theoretically possible. In advertising, to move by the largest leap imaginable (in the mind of the advertiser). There is no contradiction. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On 2012-12-26 12:55, Neil Bothwick wrote: That all makes sense, although it may well be harder to implement than to suggest. To be fair to the udev developers, we owe them nothing and they are free to take their project in whichever direction they like and spend their time on whatever features they choose to. If we don't like it we can fork it. If eudev works and provides a valid alternative to udev it will simply prove that the open source ecosystem works in a way that all those trying to avoid upgrading from Windows 7 to 8 can't even dream about. There is really no place for the insults and name calling, udev provided us with a great tool that we were happy to use for years, now it is moving in a direction we don't like we can either live with the change or do something about it. Walt chose the latter route and now the eudev guys are following suit - eudev may not be ready for use yet but the devs have already achieved a lot more that all the list complaint and insults ever will. Very well said! +1 Best regards Peter K
Re: [gentoo-user] Re: Anyone switched to eudev yet?
* Bruce Hill da...@happypenguincomputers.com [121225 18:30]: On Tue, Dec 25, 2012 at 11:51:43AM -0500, Todd Goodman wrote: Same question ... initrd.gz and initramfs are *not* the same thing; and there was a package called mkinitrd in Gentoo that was retired to attic some time ago, before my exodus from Slackware to Gentoo; therefore, I don't know it's history. Most distros still have a mkinitrd script, but not Gentoo. And there are lots of resources online which can guide you in making an initrd or initramfs. I'm an old guy and don't care to learn too much new unless someone very knowledgable in *nix (not just one distro) can give me a good reason for doing so. No one has with initramfs to date. Try reading the kernel Documentation. (e.g., /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.) initramfs is an improvement over initrd. Todd Having read it years ago it still fails to give me a good reason for using it. It gives plenty of good reasons. If they aren't good for you then fine. But if you read it you wouldn't be asking why initrd went away and was replaced by initramfs. Todd
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, Dec 25, 2012 at 9:54 AM, Dale rdalek1...@gmail.com wrote: Mark David Dumlao wrote: On Tue, Dec 25, 2012 at 1:15 AM, Bruce Hill da...@happypenguincomputers.com wrote: On Mon, Dec 24, 2012 at 11:05:25AM -0600, Dale wrote: Bruce Hill wrote: SNIP No initrd... YET!!! ROFL When eudev goes stable, then we can disregard that yet. ;-) Dale devfs still works wonderfully ... for principle, if no other reason, that file server will *NEVER* have an initrd image You shouldn't need to wait for eudev. Technically any early mount system configured and done _before_ udev should do the trick. I mean, it's not like udev is even *essential* for boot - that we happen to depend on it is just a matter of convenience. Shouldn't be hard to write an rc script that does just that for anyone that hates init thingies bad enough. Just hardcode an n-second sleep and plug in the kernel detected device name. Do rc scripts count as init thingies? :) Is that what eudev is going to do? I follow -dev and according to the eudev people they are going to support a separate /usr with no init thingy. So, they have a plan to do this. From what they were posting, they seem pretty sure they can do this. Contrary to all the noise in this topic, udev itself works on /. The thing is this: udev is now being _installed to_ /usr instead of /. This is an upstream decision. See, there's a common bug with a lot of programs using udev. They are also installed to /usr instead of to /. And so those programs will _silently_ fail when /usr isn't mounted. Silent failures are deemed a bad thing by some people, worse so than noisy failures, something to do with the Unix philosophy of failing early and loudly. Now, you can install udev to / if you want - by writing a custom ebuild that does just that. And it should, in theory, work. But if you want it to run without hitches, you _must_ make sure /usr is mounted in time for all the rules to run. That's why an early mount script will fix any issues with udev. One way of getting an early mount script - the most reliable and comprehensively tested one - is to use an init thingy. I haven't used one in a long time, but you generally just run a script, mkinitrd/mkinitramfs/dracut, that generates it for you. The init thingy is a compressed filesystem that contains just enough tools and modules you need to test and mount your filesystems. Which, conspicuously, was supposed to be the reason for the / being separated from the /usr filesystem. But besides the point - it's not the only way. You could just write a mount script yourself, and force your mount script to run before udev does, by editing udev's dependencies in /etc/conf.d/udev. That will also fix any issues udev has with /usr. The eudev team did a different thing. They forked udev and changed some bits around that they didn't like. But the one thing they didn't fix - which by definition they cannot fix - is the fact that programs depending on eudev - and installed to /usr - will _still_ need /usr mounted beforehand to function properly. A lot of us don't have those programs, or invoke those programs late enough in the system uptime that /usr is guaranteed to be mounted. So we just coincidentally happen to not run into any trouble. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, Dec 25, 2012 at 10:38 AM, Dale rdalek1...@gmail.com wrote: Feel free to set me straight tho. As long as you don't tell me my system is broken and has not been able to boot for the last 9 years without one of those things. ROFL Nobody's telling you _your_ system, as in the collection of programs you use for your productivity, is broken. What we're saying is that _the_ system, as in the general practice as compared to the specification, is broken. Those are two _very_ different things. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, Dec 26, 2012 at 09:24:20AM -0500, Todd Goodman wrote: * Bruce Hill da...@happypenguincomputers.com [121225 18:30]: Try reading the kernel Documentation. (e.g., /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.) initramfs is an improvement over initrd. Todd Having read it years ago it still fails to give me a good reason for using it. It gives plenty of good reasons. If they aren't good for you then fine. But if you read it you wouldn't be asking why initrd went away and was replaced by initramfs. Todd Actually I had not read it in quite a number of years, did this morning, and you are entirely correct. Perhaps all those years ago when an initrd was required at times, I'd just held onto my mkinitrd script and didn't want to change; and since there's no need for an initrd now, I didn't actually read it, but clung to incorrect memories. Thanks for the rebuke. ;) -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, Dec 25, 2012 at 09:24:55PM -0600, Canek Peláez Valdés wrote: snip systemd fanboi text And then months later has the nerve of calling my use of the word fuck (in which I wasn't insulting anyone) as offensive: http://article.gmane.org/gmane.linux.gentoo.user/261318 http://article.gmane.org/gmane.linux.gentoo.user/261318 I hope it doesn't offend anyone. That was not (nor is) the intention. Regards. -- Canek Peláez Valdés So you weren't being honest when you wrote that in the first place. -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, Dec 26, 2012 at 9:03 AM, Bruce Hill da...@happypenguincomputers.com wrote: On Wed, Dec 26, 2012 at 09:24:20AM -0500, Todd Goodman wrote: * Bruce Hill da...@happypenguincomputers.com [121225 18:30]: Try reading the kernel Documentation. (e.g., /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.) initramfs is an improvement over initrd. Todd Having read it years ago it still fails to give me a good reason for using it. It gives plenty of good reasons. If they aren't good for you then fine. But if you read it you wouldn't be asking why initrd went away and was replaced by initramfs. Todd Actually I had not read it in quite a number of years, did this morning, and you are entirely correct. Perhaps all those years ago when an initrd was required at times, I'd just held onto my mkinitrd script and didn't want to change; and since there's no need for an initrd now, I didn't actually read it, but clung to incorrect memories. One interesting small point I got out of the docs that Neil pointed me toward: That since linux-2.6 we're all using an initramfs The 2.6 kernel build process always creates a gzipped cpio format initramfs archive and links it into the resulting kernel binary. By default, this archive is empty (consuming 134 bytes on x86). So it's a nit but no one should be saying I don't use an init thingy but rather My init thingy is empty and has no jobs to do on my system. (Or at least that's my understanding...) - Mark
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, Dec 26, 2012 at 11:13 AM, Bruce Hill da...@happypenguincomputers.com wrote: On Tue, Dec 25, 2012 at 09:24:55PM -0600, Canek Peláez Valdés wrote: snip systemd fanboi text And then months later has the nerve of calling my use of the word fuck (in which I wasn't insulting anyone) as offensive: http://article.gmane.org/gmane.linux.gentoo.user/261318 http://article.gmane.org/gmane.linux.gentoo.user/261318 I hope it doesn't offend anyone. That was not (nor is) the intention. Regards. -- Canek Peláez Valdés So you weren't being honest when you wrote that in the first place. I already told you that I didn't wanted to offend anyone when I said fuck, I used the word for emphasis. You keep failing to understand that, or you keep saying that I was dishonest as a diversion. And I will keep using the word that way; not to insult *personally* anyone. My point is that I find highly hypocrite that you took offense to a word written everyday in a lot of Linux mailing lists, when some months ago you used an homophobic rhetorical question directed *personally* against me, in a way that even an eight year old kid would understand it's offensive. Actually, except for you, in recent years I have only heard eight year old kids using the question are you his boyfriend? as an attack. In a technical mailing list, besides. So, keep trying to hide behind the false accusation that I was dishonest when I say that I didn't wanted to offend anyone; the undeniable truth is that you actually tried to offend me *personally*, like an eight year old, when you asked me if I was Lennart's boyfriend. In a technical mailing list. Recheck the March thread, if you must; or all the mailing list archives for what is worth. I try to stick with only technical arguments; sometimes I'm wrong, sometimes I have a different opinion than most on the list. But I stick to the technical arguments. And my who the fuck cares? mail was a call to stick to the technical arguments, BTW, not to some silly thing like who has the most seniority in the list. You, on the other hand in March, when you ran out of technical arguments (if saying his coding is so questionable that Lennartware has become derogatory slang can be called a technical argument), you resorted to ask me if I was Lennart's boyfriend. That's *your* level of discussion. Not mine. You are the one trying to offend. Not me. 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-user] Re: Anyone switched to eudev yet?
Mark Knecht wrote: One interesting small point I got out of the docs that Neil pointed me toward: That since linux-2.6 we're all using an initramfs The 2.6 kernel build process always creates a gzipped cpio format initramfs archive and links it into the resulting kernel binary. By default, this archive is empty (consuming 134 bytes on x86). So it's a nit but no one should be saying I don't use an init thingy but rather My init thingy is empty and has no jobs to do on my system. (Or at least that's my understanding...) - Mark Hence it will not fail, right? Adding another point of failure is my problem with this. As I have said before, when I was using Mandriva, then Mandrake, the init thingy would fail on a regular basis. It is one reason I left Mandriva. I got tired of the breakage and Gentoo didn't need one. So, here I am, good or bad. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Mark David Dumlao wrote: On Tue, Dec 25, 2012 at 10:38 AM, Dale rdalek1...@gmail.com wrote: Feel free to set me straight tho. As long as you don't tell me my system is broken and has not been able to boot for the last 9 years without one of those things. ROFL Nobody's telling you _your_ system, as in the collection of programs you use for your productivity, is broken. What we're saying is that _the_ system, as in the general practice as compared to the specification, is broken. Those are two _very_ different things. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none From what I have read, they are saying what has worked for decades has been broken the whole time. Doesn't matter that it works for millions of users, its broken. They say it is broken so they can fix it with a init thingy for EVERYONE. Sorry, that's like telling me my car has been broken for the last ten years when I have been driving it to town and it runs just fine. The udev/systemd people sound like politicians. We want to change something so something must be broke, let's fix it. They get together, make some new rules and it actually ends up being worse then what it originally was. Do they back up and try to come up with something else, no, they try to fix it some more which leads to more problems. This continues until it falls in on itself OR someone with some sense realizes we need to go back to where it was and make it work like it has for so many years. The eudev folks are planning to continue with what has worked, that's my reading on it anyway. YMMV Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, Dec 26, 2012 at 12:34 PM, Dale rdalek1...@gmail.com wrote: Mark Knecht wrote: One interesting small point I got out of the docs that Neil pointed me toward: That since linux-2.6 we're all using an initramfs The 2.6 kernel build process always creates a gzipped cpio format initramfs archive and links it into the resulting kernel binary. By default, this archive is empty (consuming 134 bytes on x86). So it's a nit but no one should be saying I don't use an init thingy but rather My init thingy is empty and has no jobs to do on my system. (Or at least that's my understanding...) - Mark Hence it will not fail, right? Adding another point of failure is my problem with this. As I have said before, when I was using Mandriva, then Mandrake, the init thingy would fail on a regular basis. It is one reason I left Mandriva. I got tired of the breakage and Gentoo didn't need one. So, here I am, good or bad. ;-) Dale Dale, not enough info: If the init thingy is empty and if your kernel boots then it did not fail. If the init thingy is not empty and your kernel boots it did not fail. If the init thingy is not empty and your kernel does not boot we don't know what failed. Might be your init thingy, might be something else. I hope you understand I understand both your POV as well as your frustration. Maybe the work I'm doing in my thread will allow both of us to be more comfortable with init thingies. I'm going the opposite direction as you. I don't need one (on most of my home machines) but I'm going to add one on all my machines. It will become part of the way I maintain them all and hopefully I'll get more comfortable with the process. Cheers, Mark
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, 25 Dec 2012 02:01:13 -0600 Canek Peláez Valdés can...@gmail.com wrote: To the OP of this OT sub-thread. The main difference for me is OpenRC removes some of the symlink mess and uncertainty compared to for example debians init. I very much like OpenRC but my fav is still OpenBSD that tries to minimise the number of files/folders to be potentially locked down and is very transparent and quick to follow through. On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. (With a solid state hard drive, my laptop now boots even faster). The usual statistic cited is 2 seconds but systemd can increase the time dramatically or be a complete no go on embedded systems with limited cpu and/or ram. Percentages of a section of the bootup is just playing games like often used by annoying marketing departments. You will save more boot time by switching to xfce from KDE/Gnome with stronger arguments for doing so. * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. Some will tell you that for them it works, but just like the guys who have a separate /usr and refuse to use an initramfs, they just haven't been bitten by the inherent problems of it (just ask kernel developer Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just broken with parallel service startup. Not only that but is seen by many to be pointless except to minute speed gains and a cause of various problems such as increased difficulty in determining where a problem occurs. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: But require reading documentation to understand with no other external gain, unlike shell. * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. That explains why I see so many asking for help. The documentation may? be complete but is terrible. Like LVM it is spread out into many illogical files that would require a non existent sitemap to find. OpenBSD is renowned for it's excellent documentation and note that it's openssl pages are consolidated. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. Nothing new, OpenBSD does similar. Completely aside from this discussion. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. The OpenBSD list pointed out the double forking argument to be technically pointless. http://marc.info/?l=openbsd-miscm=135314269712851w=2 * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. So why was /etc/inittab removed for something that takes much more effort to configure. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then you don't have a great deal of experience in init systems. These are the ones off the top of my head; but what I like the most about systemd is that it just works, and that
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, 25 Dec 2012 07:09:49 +0800 William Kenworthy bi...@iinet.net.au wrote: Not all the proposed changes are bad ... a read only /usr would be nice, but I object to being forced into what I regard as an unreliable configuration (or use unreliable, crappy software, eg pulse audio!) because of these changes - and for those who say I have a choice ... thats correct, my choice will be eudev. A read only /usr is perfectly possible in any case too, especially if you choose to do things more correctly like avoiding dhcp and as a bonus it's various security issues of the past.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, 25 Dec 2012 08:56:38 -0500 Joshua Murphy poiso...@gmail.com wrote: It would still be a (notable, at that) drop in size if the shell script was redone to provide exactly the same set of features, then compared, but that size difference wouldn't have the same shock value as the comparison against 80+ lines. If you look at the ssh devs distribution OpenBSD, sshd's rc config is a one liner basically of simply enable or provide command line arguments. Key checking is part of the OS startup script which is beautifully easy to read and follow through to shutdown. The turing complete language as oppose to the increased pid1 of systemd is a theoretical fallacy where bugs can be immediately fixed with a text editor or swapping the constantly tested but admittedly complex shell code. Note though that init does not require a shell or Turing complete language at all or anything else making it appropriate in it's various forms to all cases. Ironically this variation can be seen as unifying unix communities. What would be good is a common agreement on the format or sysadmins equivelent to API of controlling a universally applicable init system.
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, 27 Dec 2012 00:01:58 +0800 Mark David Dumlao madum...@gmail.com wrote: Nobody's telling you _your_ system, as in the collection of programs you use for your productivity, is broken. What we're saying is that _the_ system, as in the general practice as compared to the specification, is broken. Those are two _very_ different things. If the spec and practice are out of sync then if possible as this thread demonstrates most and is perfectly possible then you fix the practice and do not erode the spec.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, Dec 26, 2012 at 4:19 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Tue, 25 Dec 2012 02:01:13 -0600 Canek Peláez Valdés can...@gmail.com wrote: To the OP of this OT sub-thread. The main difference for me is OpenRC removes some of the symlink mess and uncertainty compared to for example debians init. I very much like OpenRC but my fav is still OpenBSD that tries to minimise the number of files/folders to be potentially locked down and is very transparent and quick to follow through. On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. (With a solid state hard drive, my laptop now boots even faster). The usual statistic cited is 2 seconds but systemd can increase the time dramatically or be a complete no go on embedded systems with limited cpu and/or ram. Percentages of a section of the bootup is just playing games like often used by annoying marketing departments. You will save more boot time by switching to xfce from KDE/Gnome with stronger arguments for doing so. * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. Some will tell you that for them it works, but just like the guys who have a separate /usr and refuse to use an initramfs, they just haven't been bitten by the inherent problems of it (just ask kernel developer Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just broken with parallel service startup. Not only that but is seen by many to be pointless except to minute speed gains and a cause of various problems such as increased difficulty in determining where a problem occurs. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: But require reading documentation to understand with no other external gain, unlike shell. * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. That explains why I see so many asking for help. The documentation may? be complete but is terrible. Like LVM it is spread out into many illogical files that would require a non existent sitemap to find. OpenBSD is renowned for it's excellent documentation and note that it's openssl pages are consolidated. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. Nothing new, OpenBSD does similar. Completely aside from this discussion. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. The OpenBSD list pointed out the double forking argument to be technically pointless. http://marc.info/?l=openbsd-miscm=135314269712851w=2 * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. So why was /etc/inittab removed for something that takes much more effort to configure. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then you don't have a great deal of experience in init systems. These are the
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, Dec 26, 2012 at 6:01 PM, Canek Peláez Valdés can...@gmail.com wrote: [snip] I didn't started the thread, Wolfe did. I just answered his question from my point of view. And, what community is being divided? Fedora,OpenSuse, and Arch use systemd by default. Gentoo derivative Exherbo recommends it as init system. It works great on Gentoo and Debian. I understand it even works in Ubuntu. systemd has done more to unify the Linux ecosystem than a lot of other projects in the last 20 years. And, really, I don't care about OpenBSD. I worked with it for three years; it's a nice toy Unix. You do realize you just lost any moral high ground you might have had over saying things that might or might not offend others? Seriously? toy? I'm not an OpenBSD user. But I do know it's one of the longest-lived, most prominent UNIX-like systems in the ecosystem, and it's the home for a huge amount of code that's imported by virtually every other notable operating system. To call it a toy tells me you know next to nothing about the history (or even present) positions and involvement of the major players of the UNIX-like ecosystem over the last twenty years. But for serious work (server, desktop and mobile) I prefer Linux, and in my case (except for my phone, that uses Android) I run Gentoo+systemd in all my machines. You don't have to agree with that, is my personal preference. Canek, I have to ask. Have you ever done _anything_ outside of academia? Up to Masters, academia is learning about what is. Afterward, it's either about teaching or discovering what may be...but a Masters only teaches you theory. A Doctorate is a discovery of a truth under controlled conditions. The real world is nowhere near that clean. Quite frankly, I've found your emails to have to have a far more pomp, ipsie dixit arguments, playbook arguments and appeals to authority than hard, technical defense of arguments against your positions in debate. Generally, I try to ignore you, and when I respond, it's usually because your emails carry with them a tone of authority that could easily mislead the uninformed into assuming he'd just read the One True Way on some subject--something that's terrible when there are real differences and not always clear-cut answers. I try very, very hard to avoid both the use and appearance of use of ad hominem arguments and reasoning. I do my damnedest to give the benefit of the doubt. However, quite frankly, I've read almost everything you've posted to this list over the last year and a half, and you've never consistently exhibited an awareness of pragmatic concerns for the subject, an understanding of the low levels issues in theoretical concerns of the subject, or an ability to stick to technical argument in a non-evasive fashion; that you might be wrong on a technical point never occurs to you, and when pressed, you engage in sophistry. Quite frankly, you act and speak more like a PR spokesman than an engineer. It's this behavior that probably led Bruce to make a crack about your defense of systemd to an irrational degree. You advocate, but you don't respond to criticisms with substance, suggesting your advocacy isn't something based on rational motivation. My purpose in debate isn't to win, it's to understand. I would be positively delighted if you would approach debate the with the same goal; we might be able to learn from each other. -- :wq
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, 26 Dec 2012 17:01:17 -0600 Canek Peláez Valdés can...@gmail.com wrote: And, what community is being divided? Fedora,OpenSuse, and Arch use systemd by default. From debian and hurd to slackware which will not touch systemd ever and ubuntu and also embedded with the kernel working on more and more deeply embedded processors and userland working potentially on less or more difficulties in porting if lennart's dreams ever come to pass, which I hope many won't. So way more than half of linux will not use systemd by default likely ever and it is rather different. Any unification it does bring like /etc/hostname could be easily achieved with a little organisation without systemd and would be way more constructive if it happened because of that single purpose. I didn't even mention POSIX compliance which is a requirement on many projects. Fudging POSIX into Linux only would defeat the whole point of POSIX, though apparently that is a real danger.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Dec 26, 2012 1:05 AM, Canek Peláez Valdés can...@gmail.com wrote:
{supersnip}
So, no, I'm not trying to answer if you could create a /usr service
and make things dependent on /usr come after it's been mounted. I
passed almost this entire thread because it's mostly people still
hitting the same dead horse; really, if someone believe the eudev fork
is the answer, they should go forth and use it. If there are people
who don't want to believe developers like Greg Kroah-Hartman or Diego
Pettenò when they basically say that eudev is a joke, why they would
believe *me*? And, by the way, Diego doesn't like systemd *at all*.
Canek, I distinctly remember, at the very beginning of this brouhaha over
udev requiring /usr to be mounted at boot time, you stated something along
the lines of 'show me the code, then I'll believe that replacing udev is
doable'.
First, Walter Dnes came out with an amazingly complete -- considering it
was all done by just one man -- solution using mdev. You scoffed at him,
saying that mdev solution is incomplete.
Now, some respected Gentoo devs forked udev into eudev, and produced a
working solution, yet you still scoff at them.
In your eyes, udev has become like the cosmos: everything there is, and
ever shall be.
Greg KH and Diego Petteno are similar; they ridiculed a good forking by
spreading FUD, and almost totally unwilling to listen to rational arguments
from the devs about why udev is forked. As a result, they received great
opposition, in turn. Even Linus piped up at one point, sharply reminding
Greg KH that even though udev was at one time Greg's 'baby', at this point
udev serves only the wants of the few.
I'd say that you, Greg KH, and others denigrating eudev are udev fanatics,
preferring to denigrate anything outside the 'party lines' of udev+systemd.
Rgds,
--
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, Dec 26, 2012 at 5:51 PM, Michael Mol mike...@gmail.com wrote: On Wed, Dec 26, 2012 at 6:01 PM, Canek Peláez Valdés can...@gmail.com wrote: [snip] I didn't started the thread, Wolfe did. I just answered his question from my point of view. And, what community is being divided? Fedora,OpenSuse, and Arch use systemd by default. Gentoo derivative Exherbo recommends it as init system. It works great on Gentoo and Debian. I understand it even works in Ubuntu. systemd has done more to unify the Linux ecosystem than a lot of other projects in the last 20 years. And, really, I don't care about OpenBSD. I worked with it for three years; it's a nice toy Unix. You do realize you just lost any moral high ground you might have had over saying things that might or might not offend others? Seriously? toy? Hey, it's my opinion. You don't need to agree with me and, again, I don't pretend to offend anyone. It's jsut what I think. Have you read the name calling against GNOME and udev/systemd projects, developers and/or users? How come you never say anything about those? I'm not an OpenBSD user. But I do know it's one of the longest-lived, most prominent UNIX-like systems in the ecosystem, and it's the home for a huge amount of code that's imported by virtually every other notable operating system. Longest-lived mean nothing. Literally. Minix is older than all the modern *BSDs and Linux, and its author called it (until recently) a toy Unix. To call it a toy tells me you know next to nothing about the history (or even present) positions and involvement of the major players of the UNIX-like ecosystem over the last twenty years. I know my Unix history, thank you very much. Do you? You read LWN, don't you? http://lwn.net/Articles/524606/ I call OpenBSD a toy Unix in the sense of the above article's quote: There will be fewer and fewer settings where BSD-based systems will operate in the way their users want. That, needless to say, is a recipe for irrelevance and, eventually, disappearance. But for serious work (server, desktop and mobile) I prefer Linux, and in my case (except for my phone, that uses Android) I run Gentoo+systemd in all my machines. You don't have to agree with that, is my personal preference. Canek, I have to ask. Have you ever done _anything_ outside of academia? Up to Masters, academia is learning about what is. Afterward, it's either about teaching or discovering what may be...but a Masters only teaches you theory. A Doctorate is a discovery of a truth under controlled conditions. The real world is nowhere near that clean. Again, thank you for teaching me about the real world. I worked for various years between my Bachelor's and Master's degrees, programming and administering Linux, SCO, BSD and Aix systems. I still administer several machines in my university. I think I know the real world, thanks. Quite frankly, I've found your emails to have to have a far more pomp, ipsie dixit arguments, playbook arguments and appeals to authority than hard, technical defense of arguments against your positions in debate. Generally, I try to ignore you, and when I respond, it's usually because your emails carry with them a tone of authority that could easily mislead the uninformed into assuming he'd just read the One True Way on some subject--something that's terrible when there are real differences and not always clear-cut answers. Relax Michael; as I said in other emails: who the fuck cares what I say or who I am? Wolfe made a question, I tried to answer it to the best of my knowledge. That's it: nobody has to agree with me, nobody has to do anything about what I write. Not even read it. By the way, did you read whay Kevin told me? * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then you don't have a great deal of experience in init systems. I understand that in the Gentoo mailing lists (which doens't necessarily reflect the Gentoo community as a whole), us udev/systemd users and supporters look like a (very maligned) minority. I understand a lot of people here doesn't like the direction udev/systemd is taking Linux. But it's really kinda funny how people react when we calmly try to express why do we like said direction. I try very, very hard to avoid both the use and appearance of use of ad hominem arguments and reasoning. I do my damnedest to give the benefit of the doubt. However, quite frankly, I've read almost everything you've posted to this list over the last year and a half, and
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, Dec 26, 2012 at 6:45 PM, Pandu Poluan pa...@poluan.info wrote:
On Dec 26, 2012 1:05 AM, Canek Peláez Valdés can...@gmail.com wrote:
{supersnip}
Canek, I distinctly remember, at the very beginning of this brouhaha over
udev requiring /usr to be mounted at boot time, you stated something along
the lines of 'show me the code, then I'll believe that replacing udev is
doable'.
Yeah, and like I said, check the commits in eudev. They haven't done
nothing but to remove code and a very rational (IMO) dependency, kmod.
First, Walter Dnes came out with an amazingly complete -- considering it was
all done by just one man -- solution using mdev. You scoffed at him, saying
that mdev solution is incomplete.
I'm sorry if sounded like scoffing (certainly I don't remember
scoffing anyone, at least consciously). I remember I praised Walt for
doing the work for mdev. Do you remember that? I can dig the archives,
but I'm pretty sure I said that I greatly admired him.
Now, some respected Gentoo devs forked udev into eudev, and produced a
working solution, yet you still scoff at them.
I'm not the one doing the scoffing; those where Greg and Diego. And
sorry, but I really trust those guys.
In your eyes, udev has become like the cosmos: everything there is, and ever
shall be.
No, of course no. Hell, I hope something even better will be developed
along the way. And I said at some point (to Greg, in the -dev list)
that *perhaps* something good will come from eudev. I hope you
remember, but (again) I can search the archives.
Greg KH and Diego Petteno are similar; they ridiculed a good forking by
spreading FUD, and almost totally unwilling to listen to rational arguments
from the devs about why udev is forked. As a result, they received great
opposition, in turn. Even Linus piped up at one point, sharply reminding
Greg KH that even though udev was at one time Greg's 'baby', at this point
udev serves only the wants of the few.
I really think that's the crux of the matter Pandou: udev/systemd
serves to the wants of the many. The eudev fork serves to the wants of
a very few which really don't want an initramfs, when it has a lot of
technical advantages. It has some problems, of course, but we can
solve those, and solve the problem *in the general case*. Which is the
one that it's important ant interesting.
In my humble opinion (apparently, if I don't say that, it sounds like
it's impossible for me to be wrong).
I'd say that you, Greg KH, and others denigrating eudev are udev fanatics,
preferring to denigrate anything outside the 'party lines' of udev+systemd.
What about Diego? He doesn't like systemd.
Pandou, the party lines and the thought police is the other way
around in this list. You don't seem to remember my praises to Walt or
my wishing luck to the eudev fork (which, BTW, Greg also did). The few
of us who *dare* to praise udev/systemd get an incredible amount of
crap for it. We are nothing but fanbois or, in your words, udev has
become like the cosmos: everything there is, and ever shall be.
Really? I didn't knew that.
Maybe we are doing it wrong. But as far as i can see, we are only
expressing our opinion on technical grounds. We are not calling names
nor doubting their technical backgrounds, nor telling people what they
should or should not use.
It's the other way around.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, Dec 26, 2012 at 7:14 PM, Canek Peláez Valdés can...@gmail.com wrote: [ snip ] I'm sorry if sounded like scoffing (certainly I don't remember scoffing anyone, at least consciously). I remember I praised Walt for doing the work for mdev. Do you remember that? I can dig the archives, but I'm pretty sure I said that I greatly admired him. Found it: http://article.gmane.org/gmane.linux.gentoo.user/254885 As I have said before, I admire a lot what Walter et al. are doing, and as I always will say, this is how our community works: people writing the code (as Walter is doing) are the ones that get things done. This is the correct (and only) way to address a problem (perceived or real) with the current status: write the code that does the thing the way you want it. Complaining and crying that you don't like the direction some part of the stack is taking is at best a waste of time, and at worst idiotic. Actually doing something about it (as Walter is doing) is the smart thing to do. [ snip ] In your eyes, udev has become like the cosmos: everything there is, and ever shall be. No, of course no. Hell, I hope something even better will be developed along the way. And I said at some point (to Greg, in the -dev list) that *perhaps* something good will come from eudev. I hope you remember, but (again) I can search the archives. Found this one also: http://article.gmane.org/gmane.linux.gentoo.devel/81251 Seeing some people comparing udev to XFree86 is one of the more bizarre things coming out from this fork, and that's saying. However, I agree with Doug that anyone should code whatever they want to code. Who knows, maybe something interesting would come off from this fork, and it certainly doesn't affect us happy Gentoo+systemd+udev users. 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-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 4:42 AM, Dale rdalek1...@gmail.com wrote: Mark David Dumlao wrote: On Tue, Dec 25, 2012 at 10:38 AM, Dale rdalek1...@gmail.com wrote: Feel free to set me straight tho. As long as you don't tell me my system is broken and has not been able to boot for the last 9 years without one of those things. ROFL Nobody's telling you _your_ system, as in the collection of programs you use for your productivity, is broken. What we're saying is that _the_ system, as in the general practice as compared to the specification, is broken. Those are two _very_ different things. From what I have read, they are saying what has worked for decades has been broken the whole time. Doesn't matter that it works for millions of users, its broken. Yes, that is exactly what they are saying. What I am pointing out, however, is that there is, informally, a _technical meaning_ for the word broken, which is that the specs don't match the implementation. And in the case of /usr, the specs don't match the implementation. For like, maybe all of the Linuxen. They say it is broken so they can fix it with a init thingy for EVERYONE. Sorry, that's like telling me my car has been broken for the last ten years when I have been driving it to town and it runs just fine. NOBODY is telling you your system or that the systems of millions of users out there aren't booting. You're assigning emotional baggage to technical language. To push your analogy, oh, your car is working just fine. Now anyone with a pair of spark plugs and a few tools may be able to start it without you, but your startup _works_. Now imagine some German engineer caring nothing about you lowly driver, and caring more about the car as a system, and he goes using fancy words like authentication systems and declaring that all cars have a flaw, or more incensingly, car security is fundamentally broken (Cue angry hordes of owners pitchfork and torching his house). Thing is, he's right, and if he worked out some way for software to verify that machine startup was done using the keys rather than spark plugs, he'd be doing future generations a favor in a dramatic reduction of carjackings. And if somehow it became mandated for future cars to have this added in addition to airbags and whatnot, it'd annoy the hell out of car makers but overall still be a good thing. And here the analogy is holding up: NOBODY is breaking into your car and forcefully installing some authentication system in its startup. And NOBODY is breaking into your servers and forcing you to switch to udev/systemd or merged /usr. You can still happily plow along with your system as is. Heck, you can even install current udev without changing your partition setup. Just modify the ebuild and have it install it into / instead of /usr. Or use an early bootup script. Or use an init thingy. The udev/systemd people sound like politicians. If anything, Lennart is the worst possible politician on the planet. He makes unpopular decisions, mucks around in stuff people don't want touched, talks snide and derisively, etc etc etc, because he's a nerd's nerd that knows nothing about PR and goodwill. The software is good, but that's about all he knows how to write. He's like DJB on crack. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. (With a solid state hard drive, my laptop now boots even faster). * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. Some will tell you that for them it works, but just like the guys who have a separate /usr and refuse to use an initramfs, they just haven't been bitten by the inherent problems of it (just ask kernel developer Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just broken with parallel service startup. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). These are the ones off the top of my head; but what I like the most about systemd is that it just works, and that it makes a lot of sense (at least to me). Most of systemd features can be implemented in OpenRC, although the speed difference will never be eliminated if OpenRC keeps using shell files; however, Luca Barbato said that using reentrant busybox the speed difference is greatly reduced (I haven't confirmed this, since I haven't even installed OpenRC in months). Now, this set of (IMO) advantages of systemd over OpenRC pile up over the advantages of OpenRC over SysV: the most important one (I believe) is that OpenRC has dependencies, so a service starts only when another has already started. AFAIK, SysV has lacked this since always. I don't think I have ever heard anyone saying that we should keep using SysV; like a lot of Unix legacies, it should just die. OpenRC is much better, but it still uses a Turing-complete language (and a really slow one) to simply tell services when to start and when to stop, and it doesn't reliably keep track of what services are really still running (anyone who has ever used the zap command in OpenRC knows this). systemd of course has dependencies, a reliable tracking of service status (thanks in part to the use of cgroups), and its service files can't enter in an infinite loop. Hope it helps. 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-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 12/25/2012 03:01 AM, Canek Peláez Valdés wrote: On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Thanks, quite helpful. -- G.Wolfe Woodbury
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Mon, 24 Dec 2012 12:58:57 +0200, Alan McKinnon wrote: Are there any other cases, apart from emotional attachment based on inertia, where a separate / and /usr are desirable? As I see it, there is only the system, and it is an atomic unit. Yes, you need to run an encrypted root but don't want all the overhead of encrypting everything in /usr. Someone recently posted some benchmarks showing how awful an atom's performance can be with encryption, so this makes good sense with a netbook. Of course, running an encrypted root means you need an init thingy[tm] anyway, so there is no problem with mounting /usr from there too. -- Neil Bothwick There's no place like ~ signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, Dec 25, 2012 at 02:10:28PM +0200, Nuno J. Silva wrote: No, actually it doesn't. It just has the same kind of very generic claim that has been repeated several times in this thread (which is why? because it won't work) and links to an article that explains why some udev rules would silently fail for all this time (for *years* now, I'd guess). The article does not describe a change introduced with 181, it describes what already happened with previous versions. I am not using = 181 and I do see the issues the article mentions (it does not break here because I do not have a separate /usr, but I can see some rules that use stuff from /usr). You have such an obvious lack of understanding, and problem comprehending English, we just don't need to post to you anymore. ;) -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Mon, Dec 24, 2012 at 08:38:30PM -0600, Dale wrote: Bruce Hill wrote: On Mon, Dec 24, 2012 at 06:29:07PM -0600, »Q« wrote: On Mon, 24 Dec 2012 17:04:13 -0600 Bruce Hill da...@happypenguincomputers.com wrote: Gentoo had mkinitrd once upon a time, but it's now in attic. Somewhere, sometime, for some reason, initramfs (inital ram filesystem) became vogue for the Gentoo camp, rather than initrd (initial ram disk image), and mkinitrd got retired. Is there Gentoo documentation for creating initramfs without using dracut? I could only find documentation for doing it *with* dracut, and that procedure required using genkernel. Surely Gentoo must have an initramfs guide for non-genkernel users, but I couldn't find one. Do you understand that initrd.gz and initramfs are *not* the same thing? Don't they sort of *do* the same thing? Different method but still a boot up helper thingy. This is why I started calling them init thingy. There are a few init thingys and I just lump them all together since they sort of serve the same function but in a different way. Feel free to set me straight tho. As long as you don't tell me my system is broken and has not been able to boot for the last 9 years without one of those things. ROFL Dale It's explained well here: http://en.wikipedia.org/wiki/Initrd There are many things reported by the Gentoo Community, especially by #gentoo on FreeNode, such that you would think the entire world is governed that way; however, most of it is Just Not True (TM). You will read in that link that initial ramdisk images (initrd) became popular for kitchen sink (distro) kernels, so that make allmodconfig kernel images, with even more modules added on some distros (Slackware, for one example), could boot on virtually anyone's hardware. That's a basic kernel presupposition -- the binary distros ship a kernel that, hopefully, will work on any and all comps. Gentoo, on the other hand, doesn't ship a kernel at all, and expects you to build your own. I wasn't on the Gentoo ship when genkernel came along, but would suspect it was originally written to help those poor souls who were trying Gentoo and could not build a kernel on their own (since that seems to be the audience using it now). This thread has wandered so far off track that it isn't coming back. Wish I could figure out how to /ignore a thread in Mutt. :( -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, Dec 25, 2012 at 10:56:52AM +0700, Pandu Poluan wrote: When you're in charge of over 100 servers as the back-end of a multinational company that has a revenue in excess of 10 million USD per day, even a temporary outage means the CIO, COO, and CEO breathing down your neck. Who is in charge of over 100 servers as the back-end of a multinational company that has a revenue in excess of 10 million USD per day? And what is the name of this company? -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Dec 25, 2012 3:04 AM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. (With a solid state hard drive, my laptop now boots even faster). * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. Some will tell you that for them it works, but just like the guys who have a separate /usr and refuse to use an initramfs, they just haven't been bitten by the inherent problems of it (just ask kernel developer Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just broken with parallel service startup. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). These are the ones off the top of my head; but what I like the most about systemd is that it just works, and that it makes a lot of sense (at least to me). Most of systemd features can be implemented in OpenRC, although the speed difference will never be eliminated if OpenRC keeps using shell files; however, Luca Barbato said that using reentrant busybox the speed difference is greatly reduced (I haven't confirmed this, since I haven't even installed OpenRC in months). Now, this set of (IMO) advantages of systemd over OpenRC pile up over the advantages of OpenRC over SysV: the most important one (I believe) is that OpenRC has dependencies, so a service starts only when another has already started. AFAIK, SysV has lacked this since always. I don't think I have ever heard anyone saying that we should keep using SysV; like a lot of Unix legacies, it should just die. OpenRC is much better, but it still uses a Turing-complete language (and a really slow one) to simply tell services when to start and when to stop, and it doesn't reliably keep track of what services are really still running (anyone who has ever used the zap command in OpenRC knows this). systemd of course has dependencies, a reliable tracking of service status (thanks in part to the use of cgroups), and its service files can't enter in an infinite loop. Hope it helps. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México Thank you. I think that may well be the cleanest set of
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Dec 25, 2012 8:07 AM, Bruce Hill da...@happypenguincomputers.com wrote: On Tue, Dec 25, 2012 at 10:56:52AM +0700, Pandu Poluan wrote: When you're in charge of over 100 servers as the back-end of a multinational company that has a revenue in excess of 10 million USD per day, even a temporary outage means the CIO, COO, and CEO breathing down your neck. Who is in charge of over 100 servers as the back-end of a multinational company that has a revenue in excess of 10 million USD per day? And what is the name of this company? -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting Um. I work at such a company, the the number distribution is a bit different, but Pandu's point stands.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, Dec 25, 2012 at 3:01 AM, Canek Peláez Valdés can...@gmail.com wrote: [ snip ] * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). [snip] Hope it helps. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México I've not yet made the leap, as the benefit of faster boot really doesn't affect me between systems that're always on and laptops that typically spend 75% of their time asleep, rather than ever getting turned off, so I'm in no position to speak for or against the whole of systemd's changes... but one issue I've had with the claimed benefits is the reduction in size compared to startup scripts like /etc/init.d/sshd ... based on that service declaration above, it's a horribly unfair comparison. /etc/init.d/sshd is doing a lot more than simply starting/stopping the service and dropping all of that functionality, then claiming these few lines serve the same purpose isn't an equal comparison. It would still be a (notable, at that) drop in size if the shell script was redone to provide exactly the same set of features, then compared, but that size difference wouldn't have the same shock value as the comparison against 80+ lines. The argument that those functions should be handled by the service rather than the service handler is for another day, 'course. I'll eventually get around to switching to play with systemd, at the very least to learn its quirks enough to work with it, and it's very helpful to have a clearly stated set of _favorable_ comments on it (compared to the majority of less favorable commentary) to look forward to, so don't take my having one issue with the list as anything against either the list as a whole or your effort in putting all that together, as both are very much appreciated. Happy holidays. -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Dec 25, 2012 8:07 PM, Bruce Hill da...@happypenguincomputers.com wrote: On Tue, Dec 25, 2012 at 10:56:52AM +0700, Pandu Poluan wrote: When you're in charge of over 100 servers as the back-end of a multinational company that has a revenue in excess of 10 million USD per day, even a temporary outage means the CIO, COO, and CEO breathing down your neck. Who is in charge of over 100 servers as the back-end of a multinational company that has a revenue in excess of 10 million USD per day? And what is the name of this company? I do. It's one of the world's largest retailers. We sold more than 10 million USD of stuff per day. Of course, the profit margin is very slim, that's why I purposefully use the word 'revenue' instead of 'income' ;-) Rgds, --
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Bruce Hill wrote: On Mon, Dec 24, 2012 at 08:38:30PM -0600, Dale wrote: Bruce Hill wrote: On Mon, Dec 24, 2012 at 06:29:07PM -0600, »Q« wrote: On Mon, 24 Dec 2012 17:04:13 -0600 Bruce Hill da...@happypenguincomputers.com wrote: Gentoo had mkinitrd once upon a time, but it's now in attic. Somewhere, sometime, for some reason, initramfs (inital ram filesystem) became vogue for the Gentoo camp, rather than initrd (initial ram disk image), and mkinitrd got retired. Is there Gentoo documentation for creating initramfs without using dracut? I could only find documentation for doing it *with* dracut, and that procedure required using genkernel. Surely Gentoo must have an initramfs guide for non-genkernel users, but I couldn't find one. Do you understand that initrd.gz and initramfs are *not* the same thing? Don't they sort of *do* the same thing? Different method but still a boot up helper thingy. This is why I started calling them init thingy. There are a few init thingys and I just lump them all together since they sort of serve the same function but in a different way. Feel free to set me straight tho. As long as you don't tell me my system is broken and has not been able to boot for the last 9 years without one of those things. ROFL Dale It's explained well here: http://en.wikipedia.org/wiki/Initrd There are many things reported by the Gentoo Community, especially by #gentoo on FreeNode, such that you would think the entire world is governed that way; however, most of it is Just Not True (TM). You will read in that link that initial ramdisk images (initrd) became popular for kitchen sink (distro) kernels, so that make allmodconfig kernel images, with even more modules added on some distros (Slackware, for one example), could boot on virtually anyone's hardware. That's a basic kernel presupposition -- the binary distros ship a kernel that, hopefully, will work on any and all comps. Gentoo, on the other hand, doesn't ship a kernel at all, and expects you to build your own. I wasn't on the Gentoo ship when genkernel came along, but would suspect it was originally written to help those poor souls who were trying Gentoo and could not build a kernel on their own (since that seems to be the audience using it now). This thread has wandered so far off track that it isn't coming back. Wish I could figure out how to /ignore a thread in Mutt. :( That is what I thought. It even says they are two different things but give the same results. So, me calling them init thingys works fine. In computing, initrd (initial ramdisk) is a scheme for loading a temporary root file system into memory in the boot process of the Linux kernel. initrd and initramfs refer to two different methods of achieving this. Both are commonly used to make preparations before the real root file system can be mounted. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Nuno J. Silva wrote: On 2012-12-25, Bruce Hill wrote: On Tue, Dec 25, 2012 at 02:10:28PM +0200, Nuno J. Silva wrote: No, actually it doesn't. It just has the same kind of very generic claim that has been repeated several times in this thread (which is why? because it won't work) and links to an article that explains why some udev rules would silently fail for all this time (for *years* now, I'd guess). The article does not describe a change introduced with 181, it describes what already happened with previous versions. I am not using = 181 and I do see the issues the article mentions (it does not break here because I do not have a separate /usr, but I can see some rules that use stuff from /usr). You have such an obvious lack of understanding, and problem comprehending English, we just don't need to post to you anymore. ;) Please be my guest and explain me in which part of that article is it said that some behavior *introduced in udev-181* will break systems with a separate /usr. Quoting from Gentoo news item: root@fireball / # eselect news read 2 2012-03-16-udev-181-unmasking Title udev-181 unmasking AuthorWilliam Hubbs willi...@gentoo.org Posted2012-03-16 Revision 1 udev-181 is being unmasked on 2012-03-19. This news item is to inform you that once you upgrade to a version of udev =181, if you have /usr on a separate partition, you must boot your system with an initramfs which pre-mounts /usr. An initramfs which does this is created by =sys-kernel/genkernel-3.4.25.1 or =sys-kernel/dracut-017-r1. If you do not want to use these tools, be sure any initramfs you create pre-mounts /usr. Also, if you are using OpenRC, you must upgrade to = openrc-0.9.9. For more information on why this has been done, see the following URL: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken root@fireball / # Now are you saying the Gentoo devs are lying to us? Careful now. Could end up on a slippery slope and bump your head. That says anything BEFORE 181 boots fine with a separate /usr, 181 or anything after does not. Simple enough for you yet? I might add, I have ALWAYS had a separate /usr. Darn near a decade now. It has never failed to boot because /usr was on a separate partition. NOT ONCE. Now I am told it is going to fail. Go figure. Go try to tell me that it was broken all these years. Yea, right. That's like telling me the Sun comes up in the west when I can see it doesn't with my own two eyes. Good luck with that. Reminds me of thattell it to the hand thing. ROFL Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Anyone switched to eudev yet?
* Bruce Hill da...@happypenguincomputers.com [121224 21:17]: On Mon, Dec 24, 2012 at 04:54:08PM -0800, Mark Knecht wrote: On Mon, Dec 24, 2012 at 4:29 PM, »Q« boxc...@gmx.net wrote: On Mon, 24 Dec 2012 17:04:13 -0600 Bruce Hill da...@happypenguincomputers.com wrote: Gentoo had mkinitrd once upon a time, but it's now in attic. Somewhere, sometime, for some reason, initramfs (inital ram filesystem) became vogue for the Gentoo camp, rather than initrd (initial ram disk image), and mkinitrd got retired. Is there Gentoo documentation for creating initramfs without using dracut? I could only find documentation for doing it *with* dracut, and that procedure required using genkernel. Surely Gentoo must have an initramfs guide for non-genkernel users, but I couldn't find one. I used this one (I think!!!) 6 months or a year ago. It worked first time but it was a bit of work getting there: http://en.gentoo-wiki.com/wiki/Initramfs Same question ... initrd.gz and initramfs are *not* the same thing; and there was a package called mkinitrd in Gentoo that was retired to attic some time ago, before my exodus from Slackware to Gentoo; therefore, I don't know it's history. Most distros still have a mkinitrd script, but not Gentoo. And there are lots of resources online which can guide you in making an initrd or initramfs. I'm an old guy and don't care to learn too much new unless someone very knowledgable in *nix (not just one distro) can give me a good reason for doing so. No one has with initramfs to date. Try reading the kernel Documentation. (e.g., /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.) initramfs is an improvement over initrd. Todd
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Nuno J. Silva wrote:
On 2012-12-25, Dale wrote:
Quoting from Gentoo news item:
Which was exactly the thing I was commenting on above, ok.
[...]
Now are you saying the Gentoo devs are lying to us? Careful now. Could
end up on a slippery slope and bump your head. That says anything BEFORE
181 boots fine with a separate /usr, 181 or anything after does not.
Simple enough for you yet?
It does indeed say that, but fails to provide any explanation on *why*.
And, the exact point I made above is that the URL they give points to an
explanation on something completely unrelated to the issue the news item
is about.
Further, that news item *claims* that booting with a separate /usr will
break with =udev-181. So far, *nobody* was able to explain why that
would happen, not even that news item. The only thing people have been
able to do on this mailing list regarding this news item is here it is,
that's why it will break.
Allow me to exemplify the exchange you and others are making here
10: A: =udev-181 will break boots with separate /usr
20: B: Why?
30: A: Because =udev-181 will break boots with separate /usr
40: B: But why?
50: A: Because we say so
60: GOTO 20
I don't have any reason to believe anyone is lying, and that's why,
instead of accusing people of lying, I decided to simply ask people here
for some explanations.
Now if the answers I've got here make me believe this whole udev mess is
more about someone saying it will break and everybody blindly believing
it does break. Regardless of whether it actually breaks or not.
I might add, I have ALWAYS had a separate /usr. Darn near a decade
now. It has never failed to boot because /usr was on a separate
partition. NOT ONCE. Now I am told it is going to fail. Go figure.
Go try to tell me that it was broken all these years. Yea, right.
Would it be too much trouble to ask you to share the output of
egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
and the version of udev you're running? I'm curious to see. Of course
that, if you don't have some packages installing their udev rules, you
may not have the issue at all. But maybe you have, so why don't we give
it a try?
Also, if you actually read the linked URL, it does explain it won't fail
to boot. You do realize these are two different issues here, right? One
is people saying that udev-181 will fail to boot, other is the issue
described on the URL linked on the news item, which is about stuff in
/usr breaking udev rules, which has been around for a long time and will
*silently* fail. I remind you that silently fail implies that your
system will still boot, even if it is affected by the issue.
root@fireball / # egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
/lib64/udev/rules.d/10-dm.rules:# Set proper sbin path, /sbin has higher
priority than /usr/sbin.
/lib64/udev/rules.d/10-dm.rules:TEST!=$env{DM_SBIN_PATH}/dmsetup,
ENV{DM_SBIN_PATH}=/usr/sbin
/lib64/udev/rules.d/56-hpmud_add_printer.rules:SUBSYSTEM==usb,
ENV{DEVTYPE}==usb_device, ATTRS{idVendor}==03f0,
ATTRS{idProduct}==, PROGRAM=/bin/sh -c 'logger -p user.info
loading HP Device $env{BUSNUM} $env{DEVNUM}', RUN+=/bin/sh -c
'/usr/bin/hp-config_usb_printer $env{BUSNUM}:$env{DEVNUM} '
/lib64/udev/rules.d/56-hpmud_add_printer.rules:SUBSYSTEM==usb_device,
ATTRS{idVendor}==03f0, ATTRS{idProduct}==, PROGRAM=/bin/sh -c
'X=%k; X=$${X#usbdev}; B=$${X.*}; D=$${X#*.}; logger -p user.info
loading HP Device $$B $$D; printf %%03i:%%03i $$B $$D', RUN+=/bin/sh
-c '/usr/bin/hp-config_usb_printer %c '
/lib64/udev/rules.d/56-hpmud_support.rules:ATTRS{idVendor}==03f0,
ATTRS{idProduct}==??17, RUN+=/bin/sh -c 'hp_model=%E{ID_MODEL}
/usr/bin/hp-mkuri -c '
/lib64/udev/rules.d/56-hpmud_support.rules:ATTRS{idVendor}==03f0,
ATTRS{idProduct}==??2a, RUN+=/bin/sh -c 'hp_model=%E{ID_MODEL}
/usr/bin/hp-mkuri -c '
/lib64/udev/rules.d/56-hpmud_support.rules:ENV{hp_test}==yes,
RUN+=/bin/sh -c '/usr/bin/hp-mkuri -c '
/lib64/udev/rules.d/75-net-description.rules:SUBSYSTEMS==usb,
ENV{ID_MODEL_FROM_DATABASE}==, IMPORT{program}=usb-db %p
/lib64/udev/rules.d/75-net-description.rules:SUBSYSTEMS==pci,
ENV{ID_MODEL_FROM_DATABASE}==, IMPORT{program}=pci-db %p
/lib64/udev/rules.d/75-tty-description.rules:SUBSYSTEMS==usb,
ENV{ID_MODEL_FROM_DATABASE}==, IMPORT{program}=usb-db %p
/lib64/udev/rules.d/75-tty-description.rules:SUBSYSTEMS==pci,
ENV{ID_MODEL_FROM_DATABASE}==, IMPORT{program}=pci-db %p
/lib64/udev/rules.d/78-sound-card.rules:SUBSYSTEMS==usb,
ENV{ID_VENDOR_FROM_DATABASE}==, IMPORT{program}=usb-db %p
/lib64/udev/rules.d/78-sound-card.rules:SUBSYSTEMS==pci,
ENV{ID_VENDOR_FROM_DATABASE}==, IMPORT{program}=pci-db %p
/lib64/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}==*[Ss]peaker*,
ENV{SOUND_FORM_FACTOR}=speaker, GOTO=sound_end
/lib64/udev/rules.d/78-sound-card.rules:ENV{ID_MODEL_FROM_DATABASE}==*[Hh]eadphone*,
ENV{SOUND_FORM_FACTOR}=headphone, GOTO=sound_end
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, Dec 25, 2012 at 7:14 AM, Michael Mol mike...@gmail.com wrote: On Dec 25, 2012 3:04 AM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. (With a solid state hard drive, my laptop now boots even faster). * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. Some will tell you that for them it works, but just like the guys who have a separate /usr and refuse to use an initramfs, they just haven't been bitten by the inherent problems of it (just ask kernel developer Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just broken with parallel service startup. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). These are the ones off the top of my head; but what I like the most about systemd is that it just works, and that it makes a lot of sense (at least to me). Most of systemd features can be implemented in OpenRC, although the speed difference will never be eliminated if OpenRC keeps using shell files; however, Luca Barbato said that using reentrant busybox the speed difference is greatly reduced (I haven't confirmed this, since I haven't even installed OpenRC in months). Now, this set of (IMO) advantages of systemd over OpenRC pile up over the advantages of OpenRC over SysV: the most important one (I believe) is that OpenRC has dependencies, so a service starts only when another has already started. AFAIK, SysV has lacked this since always. I don't think I have ever heard anyone saying that we should keep using SysV; like a lot of Unix legacies, it should just die. OpenRC is much better, but it still uses a Turing-complete language (and a really slow one) to simply tell services when to start and when to stop, and it doesn't reliably keep track of what services are really still running (anyone who has ever used the zap command in OpenRC knows this). systemd of course has dependencies, a reliable tracking of service status (thanks in part to the use of cgroups), and its service files can't enter in an infinite loop. Hope it helps. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, Dec 25, 2012 at 7:56 AM, Joshua Murphy poiso...@gmail.com wrote: On Tue, Dec 25, 2012 at 3:01 AM, Canek Peláez Valdés can...@gmail.com wrote: [ snip ] * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). [snip] Hope it helps. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México I've not yet made the leap, as the benefit of faster boot really doesn't affect me between systems that're always on and laptops that typically spend 75% of their time asleep, rather than ever getting turned off, so I'm in no position to speak for or against the whole of systemd's changes... but one issue I've had with the claimed benefits is the reduction in size compared to startup scripts like /etc/init.d/sshd ... based on that service declaration above, it's a horribly unfair comparison. /etc/init.d/sshd is doing a lot more than simply starting/stopping the service and dropping all of that functionality, then claiming these few lines serve the same purpose isn't an equal comparison. It would still be a (notable, at that) drop in size if the shell script was redone to provide exactly the same set of features, then compared, but that size difference wouldn't have the same shock value as the comparison against 80+ lines. The argument that those functions should be handled by the service rather than the service handler is for another day, 'course. No, I think that's the interesting argument. Like you say /etc/init.d/sshd is doing a lot more than simply starting/stopping the service; why it should do that? That's the work of the package manager and/or the administrator. An init system should only start/stop/monitor the services; it should not be checking if the keys are generated or not, or if the config file is there or not. That should happen at install time, and if for some reason they got borked between the last reboot and this one, the system is probably fucked up anyway, and putting checks in the *init script* will not help at all. But *even* if you really want to have those checks, you can do it in systemd in a cleaner way: put the checks in an executable script, and call the script with ExecStartPre: [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStartPre=/usr/local/bin/checksshd ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target There; the unit file is now 10 lines, it *still* doesn't use a Turing-complete language, you got your checks (which I believe they don't belong there, but whatever), and it will timeout if the checksshd goes into an infinite loop (30 seconds is the default timeout, I believe). That's how yo properly do more than start/stop/monitor services; the init system doesn't need to know about it, you clearly move the init system responsibility (start/stop/monitor services) from the service requirements (checking that the config files are there, or that you need to generate keys, which I repeat, I think they belong at install time), and it keeps the unit files nice and simple. 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-user] Re: Anyone switched to eudev yet?
On Tue, 25 Dec 2012 07:09:49 +0800, William Kenworthy wrote: I used initrd's many years ago, and separate /usr and/ until on a redhat system I rebooted with an out of sequence initrd and kernel on a critical server (the sort of thing that puts your employment at risk when there are 20 odd developers using it ...) That's the main reason I build the initramfs into the kernel rather than as a separate file. That way you know that each kernel will always continue to work, you can't screw up the initramfs of a working kernel. -- Neil Bothwick If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Neil Bothwick wrote: On Tue, 25 Dec 2012 07:09:49 +0800, William Kenworthy wrote: I used initrd's many years ago, and separate /usr and/ until on a redhat system I rebooted with an out of sequence initrd and kernel on a critical server (the sort of thing that puts your employment at risk when there are 20 odd developers using it ...) That's the main reason I build the initramfs into the kernel rather than as a separate file. That way you know that each kernel will always continue to work, you can't screw up the initramfs of a working kernel. That was my thinking too. I never got it to work. I went to plan B which was dracut. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Mon, 24 Dec 2012 20:33:34 -0600, Dale wrote: Putting /usr on LVM is not the problem. I have had /usr on LVM for a good long while now. It has booted just fine. The new udev is what is going to break it, whether I use LVM or not from what has been said on this list and elsewhere. I've been running separate /usr on LVM with ~arch udev and no initramfs on a couple of systems with no problems. The news item is taking the easy way out by saying it will break rather than it may break - such breakage is by no means certain - although the future holds no guarantees. -- Neil Bothwick We never really grow up; we only learn how to act in public. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Mon, 24 Dec 2012 13:23:16 -0800, Mark Knecht wrote: I don't like, really don't like, the work that currently goes into making my 'init thingy' work. All the Gentoo docs about creating hierarchies by hand and populating them with files and then compressing it. All that drives me nuts. It should be 100% automatic, and probably is with the right tools which I haven't found. The right tools are included, and documented, with your kernel. Create a plain text config file detailing the contents of the initramfs and set CONFIG_INITRAMFS_SOURCE to the path top this file. That and an init script are all you need to have the initramfs automatically built with the current versions of all files when you compile your kernel. No messing around with copying files from the main filesystem or calling arcane incantations involving cpio, make all takes care of it all. -- Neil Bothwick COBOL: (n.) an old computer language, designed to be read and not run. Unfortunately, it is often run anyway. signature.asc Description: PGP signature
