Re: [Bulk] RE: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, 4 Jan 2013 18:22:37 -0500 "Mike Edenfield" 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: [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 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: 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 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?)
On Sat, Dec 29, 2012 at 3:00 PM, Paul Colquhoun 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?)
> 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: 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 wrote: > > On Sat, 29 Dec 2012 01:16:34 +0800 > > > > Mark David Dumlao 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: 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 wrote: > On Sat, 29 Dec 2012 01:16:34 +0800 > Mark David Dumlao 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: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?
On Sat, Dec 29, 2012 at 4:17 AM, Pandu Poluan 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: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit?
On Fri, Dec 28, 2012 at 5:23 PM, Kevin Chadwick wrote: > On Fri, 28 Dec 2012 13:14:46 -0600 > Canek Peláez Valdés wrote: > >> On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick >> wrote: >> > On Thu, 27 Dec 2012 17:38:15 -0600 >> > Canek Peláez Valdés 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 Fri, Dec 28, 2012 at 4:40 PM, pk 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?
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, 28 Dec 2012 13:14:46 -0600 Canek Peláez Valdés wrote: > On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick > wrote: > > On Thu, 27 Dec 2012 17:38:15 -0600 > > Canek Peláez Valdés 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? -> 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, Dec 28, 2012 at 2:17 PM, Pandu Poluan wrote: > > On Dec 29, 2012 2:18 AM, "Canek Peláez Valdés" 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 Dec 29, 2012 2:18 AM, "Canek Peláez Valdés" 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 12:53 PM, Kevin Chadwick wrote: > On Thu, 27 Dec 2012 17:38:15 -0600 > Canek Peláez Valdés 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 Fri, Dec 28, 2012 at 12:15 PM, 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? 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 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 Thu, 27 Dec 2012 17:38:15 -0600 Canek Peláez Valdés 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: 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 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 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 Fri, Dec 28, 2012 at 12:46 PM, Mark David Dumlao wrote: > On Sat, Dec 29, 2012 at 1:33 AM, Bruce Hill > 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: 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 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 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 wrote: > > On Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao > > 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
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 wrote: > On Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao > 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.
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 9:10 AM, Kevin Chadwick 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: [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 Thu, Dec 27, 2012 at 5:37 PM, Mark David Dumlao wrote: > On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol wrote: >> On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao wrote: >>> On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol 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 rea
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" 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: [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" 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?
On Mon, 24 Dec 2012 15:14:11 + Kevin Chadwick 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?
On Thu, Dec 27, 2012 at 10:29 AM, Kevin Chadwick 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? -> what was wron with SysVInit?
On Thu, Dec 27, 2012 at 10:00 AM, pk 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 m
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, 25 Dec 2012 10:56:52 +0700 Pandu Poluan 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: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 4:59 AM, Michael Mol wrote: > On Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao wrote: >> On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol 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 /, conflic
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Mark Knecht wrote: > On Thu, Dec 27, 2012 at 10:41 AM, Michael Mol wrote: > >>> 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. >> > > > 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 Thu, Dec 27, 2012 at 3:16 PM, Mark David Dumlao wrote: > On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol 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
Re: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 2:40 AM, Michael Mol 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 whet
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 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: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 2:43 PM, 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 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 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?
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 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?
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?
On Thu, Dec 27, 2012 at 10:41 AM, Michael Mol wrote: >> >> 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. > 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?
On Thu, Dec 27, 2012 at 1:31 PM, Mark David Dumlao wrote: > On Fri, Dec 28, 2012 at 2:15 AM, Dale 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: [Bulk] Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, Dec 27, 2012 at 1:22 PM, Mark David Dumlao wrote: > On Fri, Dec 28, 2012 at 12:28 AM, Kevin Chadwick > 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 Fri, Dec 28, 2012 at 2:15 AM, Dale 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 Fri, Dec 28, 2012 at 12:28 AM, Kevin Chadwick 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?
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: [gentoo-user] Re: Anyone switched to eudev yet?
On Fri, Dec 28, 2012 at 12:13 AM, Dale wrote: > Mark David Dumlao wrote: >> On Thu, Dec 27, 2012 at 4:42 AM, Dale wrote: >>> Mark David Dumlao wrote: On Tue, Dec 25, 2012 at 10:38 AM, Dale 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? -> 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: [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?
On Thu, Dec 27, 2012 at 8:13 AM, Dale 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 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: [gentoo-user] Re: Anyone switched to eudev yet?
Mark David Dumlao wrote: > On Thu, Dec 27, 2012 at 4:42 AM, Dale wrote: >> Mark David Dumlao wrote: >>> On Tue, Dec 25, 2012 at 10:38 AM, Dale 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? -> 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?
On Thu, Dec 27, 2012 at 4:42 AM, Dale wrote: > Mark David Dumlao wrote: >> On Tue, Dec 25, 2012 at 10:38 AM, Dale 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 Wed, Dec 26, 2012 at 7:14 PM, Canek Peláez Valdés 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? -> what was wron with SysVInit?
On Wed, Dec 26, 2012 at 6:45 PM, Pandu Poluan wrote:
>
> On Dec 26, 2012 1:05 AM, "Canek Peláez Valdés" 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 5:51 PM, Michael Mol wrote: > On Wed, Dec 26, 2012 at 6:01 PM, Canek Peláez Valdés 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
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" 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, 26 Dec 2012 17:01:17 -0600 Canek Peláez Valdés 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 Wed, Dec 26, 2012 at 6:01 PM, Canek Peláez Valdés 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, Dec 26, 2012 at 4:19 PM, Kevin Chadwick wrote: > On Tue, 25 Dec 2012 02:01:13 -0600 > Canek Peláez Valdés 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 >> 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-misc&m=135314269712851&w=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 t
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Thu, 27 Dec 2012 00:01:58 +0800 Mark David Dumlao 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 Tue, 25 Dec 2012 08:56:38 -0500 Joshua Murphy 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 Tue, 25 Dec 2012 07:09:49 +0800 William Kenworthy 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 02:01:13 -0600 Canek Peláez Valdés 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 > 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-misc&m=135314269712851&w=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 sys
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Wed, Dec 26, 2012 at 12:34 PM, Dale 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?
Mark David Dumlao wrote: > On Tue, Dec 25, 2012 at 10:38 AM, Dale 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?
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?
On Wed, Dec 26, 2012 at 11:13 AM, Bruce Hill wrote: > On Tue, Dec 25, 2012 at 09:24:55PM -0600, Canek Peláez Valdés wrote: > >> >> 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?
On Wed, Dec 26, 2012 at 9:03 AM, Bruce Hill wrote: > On Wed, Dec 26, 2012 at 09:24:20AM -0500, Todd Goodman wrote: >> * Bruce Hill [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 Tue, Dec 25, 2012 at 09:24:55PM -0600, Canek Peláez Valdés wrote: > > 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 09:24:20AM -0500, Todd Goodman wrote: > * Bruce Hill [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 10:38 AM, Dale 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 Tue, Dec 25, 2012 at 9:54 AM, Dale wrote: > Mark David Dumlao wrote: >> On Tue, Dec 25, 2012 at 1:15 AM, Bruce Hill >> 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?
* Bruce Hill [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 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?
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 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 Tue, Dec 25, 2012 at 8:16 PM, Michael Mol wrote: > On Tue, Dec 25, 2012 at 6:31 PM, Bruce Hill > wrote: >> On Tue, Dec 25, 2012 at 10:01:14PM +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' ;-) >> >> So I am to assume your are named Pandu Poluan and you work for a company >> named >> "one of the world's largest retailers". >> >> Sure... > > This list has the highest signal to noise ratio of any technical > mailing list I've been on. Seriously, you should take most of the > people on this list at their word. Bruce is the kind of person who tries to insult someone with a slightly homophobic comment when he rans out of technical arguments: http://article.gmane.org/gmane.linux.gentoo.user/255258 "Seriously, mate ... are you his boyfriend, on his payroll, related, or what?" 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 You should just ignore him. The signal to noise ratio gets even higher. 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, Dec 25, 2012 at 6:31 PM, Bruce Hill wrote: > On Tue, Dec 25, 2012 at 10:01:14PM +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' ;-) > > So I am to assume your are named Pandu Poluan and you work for a company named > "one of the world's largest retailers". > > Sure... This list has the highest signal to noise ratio of any technical mailing list I've been on. Seriously, you should take most of the people on this list at their word. -- :wq
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Dec 26, 2012 6:35 AM, "Bruce Hill" wrote: > > On Tue, Dec 25, 2012 at 10:01:14PM +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' ;-) > > So I am to assume your are named Pandu Poluan and you work for a company named > "one of the world's largest retailers". > > Sure... > Ever heard of LinkedIn.com? Rgds, --
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Mark Knecht wrote: > On Tue, Dec 25, 2012 at 3:04 PM, Dale wrote: >> Mark Knecht wrote: >>> On Tue, Dec 25, 2012 at 2:13 PM, Neil Bothwick wrote: On Tue, 25 Dec 2012 14:00:36 -0800, Mark Knecht wrote: >> 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. > If you have one handy and it's not something huge (I don't think it is > but I don't really know) maybe you could post an example of what that > file looks like? This is the file I use on a system that has / on a LUKS filesystem on top of LVM. The format is documented in the kernel docs at Documentation/filesystems/ramfs-rootfs-initramfs.txt >>> Thanks for the Xmas present! I've wanted to try it this way but never >>> got up the energy to go do it all from scratch on my own. This should >>> help me (and maybe Dale?) ;-) ;-) alot. >>> >>> Cheers, >>> Mark >>> >>> >> >> I'm waiting on eudev myself. I'm going to enjoy the heck out of typing >> in "rm -rfv /boot/init*". Then I can remove it from grub.conf and it is >> history. Hopefully for a LONG time too. > Sure, if eudev ever really happens. > > In the meantime, if you followed Neil's example here, you'd be doing > > rm -rfv init* > > today. > > Think about it! :-) > > Cheers, > Mark > > How would using a init thingy keep me from using a init thingy anyway? Huh? I don't have to have a init thingy today either. Think about it. LOL If I reboot and the init thingy fails, I just edit grub and bypass the init thingy. Fixed that pretty quick. ^_^ By the way, eudev is already in the tree but a dev on -dev said they had a couple up coming fixes before needing any testing. It is REALLY happening. ;-) 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 Tue, Dec 25, 2012 at 10:01:14PM +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' ;-) So I am to assume your are named Pandu Poluan and you work for a company named "one of the world's largest retailers". Sure... -- 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 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. -- 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?
Paul Colquhoun wrote: > > On Tue, 25 Dec 2012 19:17:24 Nuno J. Silva 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. > > > > Basically, yep. If I see a error while booting, in dmesg or some other logging tool, I can handle it and make changes so that it is fixed. When I mentioned on this list about using LVM, I specifically chose to put / on a normal partition to avoid the init thingy. If I have to use a init thingy anyway, I may as well put everything but /boot on LVM. Putting / on LVM usually means you have to have a init thingy so that it can be mounted, from what I have read anyway. It looked like for a while that I was going to have one whether I wanted it or not. Now, just waiting eudev, which is going to fix it like udev/systemd should to begin with. You pretty much got the idea of it tho. 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 Tue, Dec 25, 2012 at 3:04 PM, Dale wrote: > Mark Knecht wrote: >> On Tue, Dec 25, 2012 at 2:13 PM, Neil Bothwick wrote: >>> On Tue, 25 Dec 2012 14:00:36 -0800, Mark Knecht wrote: >>> > 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. If you have one handy and it's not something huge (I don't think it is but I don't really know) maybe you could post an example of what that file looks like? >>> This is the file I use on a system that has / on a LUKS filesystem on top >>> of LVM. The format is documented in the kernel docs at >>> Documentation/filesystems/ramfs-rootfs-initramfs.txt >>> >> Thanks for the Xmas present! I've wanted to try it this way but never >> got up the energy to go do it all from scratch on my own. This should >> help me (and maybe Dale?) ;-) ;-) alot. >> >> Cheers, >> Mark >> >> > > > I'm waiting on eudev myself. I'm going to enjoy the heck out of typing > in "rm -rfv /boot/init*". Then I can remove it from grub.conf and it is > history. Hopefully for a LONG time too. Sure, if eudev ever really happens. In the meantime, if you followed Neil's example here, you'd be doing rm -rfv init* today. Think about it! :-) Cheers, Mark
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Mark Knecht wrote: > On Tue, Dec 25, 2012 at 2:13 PM, Neil Bothwick wrote: >> On Tue, 25 Dec 2012 14:00:36 -0800, Mark Knecht wrote: >> 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. >>> If you have one handy and it's not something huge (I don't think it is >>> but I don't really know) maybe you could post an example of what that >>> file looks like? >> This is the file I use on a system that has / on a LUKS filesystem on top >> of LVM. The format is documented in the kernel docs at >> Documentation/filesystems/ramfs-rootfs-initramfs.txt >> > Thanks for the Xmas present! I've wanted to try it this way but never > got up the energy to go do it all from scratch on my own. This should > help me (and maybe Dale?) ;-) ;-) alot. > > Cheers, > Mark > > I'm waiting on eudev myself. I'm going to enjoy the heck out of typing in "rm -rfv /boot/init*". Then I can remove it from grub.conf and it is history. Hopefully for a LONG time too. 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 Tue, 25 Dec 2012 19:17:24 Nuno J. Silva 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. -- 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?
Nuno J. Silva wrote:
> On 2012-12-25, Dale wrote:
>
>
> root@fireball / # egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/*
> [...]
>> $$D; printf %%03i:%%03i $$B $$D'", RUN+="/bin/sh -c '/usr/bin/python
>> /usr/bin/hp-check-plugin -m %c &'"
>> /lib/udev/rules.d/86-hpmud_plugin.rules:SUBSYSTEM=="usb",
>> ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="03f0",
>> ATTRS{idProduct}=="??2a", 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/python
>> /usr/bin/hp-check-plugin -m %c &'"
>> /lib/udev/rules.d/90-alsa-restore.rules:RUN+="/usr/sbin/alsactl
>> restore $attr{number}"
>> root@fireball / #
>>
>>
>> Yikes, almost enough for a attachment.
>>
>> root@fireball / # equery list udev
>> * Searching for udev ...
>> [IP-] [ ] sys-fs/udev-171-r9:0
>> root@fireball / #
> Thanks. So you don't have udev-181, but you already need stuff under
> /udev for these rules to work. Which is what that URL is about.
Actually, NO. I only built a init thingy to GET READY for the change.
I can still boot WITHOUT the init thingy as it is now. I went through
this early instead of waiting for the upgrade that leaves me with a
machine that may NOT boot or me running around like a chicken with my
head cut off to figure out how to fix it. As it was, it took me a
couple weeks at least to find a init thingy that works. That is one
reason I hate the things. ;-) I suspect you were not around when hal
hit the scene. As bad as I hate hal, I think the init thingy has it
beat. Trust me, ask anyone on this list, I HATE hal!! If it was
physical instead of code, I would use it for target practice. Be nice
for my new .44 magnum rifle. :-)
>
>> I will not allow my system to upgrade to anything listed in the new
>> item. I'm not going to chance it.
>>
>> As to a silent fail. I watch my system really close when booting. If I
>> see any error message, I hit Scroll lock and make a note of it. I have
>> one now about rc.conf. I have the file in the new place but have not
>> rebooted yet to test. So far, I have not seen any error except for
>> sound card stuff when booting. Since a sound card is not needed when
>> booting, I'm not worried about it.
> You happen to understand that the "silent" part in "silent fail" implies
> that you won't see any error message? If it wasn't silent, it would not
> be called silent fail.
>
> In fact, I'd say that the article the URL points to was written exactly
> because this has been this way for some time, but as the fail is silent,
> many people simply don't notice that it fails, and assume that, as far
> as the system reachs the login prompt with no visible errors, then
> everything is OK.
Read above. I can boot withOUT an init thingy still. Also, I check for
errors after about every reboot, especially if I have not rebooted in a
while. I go through dmesg and other logs looking for anything that is
out of place or new. If anything has a issue, I'll find it. That's how
I already know about the sound card issue. It doesn't affect me booting
and never should.
>> Again, this comes to this that has been around for decades. Anything
>> needed for booting, should be on the / file system, /bin, /sbin, /lib or
>> /etc. Nothing needed for booting should be placed in /usr or /var since
>> a lot of people put those on separate file systems, including me. What
>> I don't get is this, that has been working for decades so why change
>> it?
> Then perhaps you should do, for example,
>equery belongs '/usr/bin/hp-check-plugin'
>equery belongs '/usr/bin/python'
>equery belongs '/usr/bin/hp-mkuri'
>equery belongs '/usr/sbin/alsactl'
>
>[and so on, for executables and scripts used in the udev rules the
>command found on your system]
I already know about them and they do NOT affect me booting. The hp is
my printer. The alsactl is my sound card. Again, nothing that affects
me booting. My system can boot if my printer is turned off and it also
boots without a sound card too. I do want to get me a better card tho.
;-)
> And file bugs on these packages (ALSA, python and perhaps some CUPS
> drivers?), as these commands are needed for booting (they're called by
> udev as soon as there is a device matching the rule) and, so, they
> should live under /, not under /usr.
>
Thing is, upstream is not going to fix it. Lennart, and others, has
made it clear, it is their way or go away. This has been discussed a
lot over the past year or two. Some have even posted links to postings
by the udev/systemd folks. They are not interested in it. It gets
marked as 'won't fix' or whatever and that is the end of it.
Again, the point is, what has been working for ages is being claimed
that it is broken for basically everybody because it suites the ones
that want to change it. They use a init thingy to boot their systems,
binary based ones I m
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, Dec 25, 2012 at 2:13 PM, Neil Bothwick wrote: > On Tue, 25 Dec 2012 14:00:36 -0800, Mark Knecht wrote: > >> > 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. > >> If you have one handy and it's not something huge (I don't think it is >> but I don't really know) maybe you could post an example of what that >> file looks like? > > This is the file I use on a system that has / on a LUKS filesystem on top > of LVM. The format is documented in the kernel docs at > Documentation/filesystems/ramfs-rootfs-initramfs.txt > Thanks for the Xmas present! I've wanted to try it this way but never got up the energy to go do it all from scratch on my own. This should help me (and maybe Dale?) ;-) ;-) alot. Cheers, Mark
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, 25 Dec 2012 14:00:36 -0800, Mark Knecht wrote: > > 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. > If you have one handy and it's not something huge (I don't think it is > but I don't really know) maybe you could post an example of what that > file looks like? This is the file I use on a system that has / on a LUKS filesystem on top of LVM. The format is documented in the kernel docs at Documentation/filesystems/ramfs-rootfs-initramfs.txt dir /bin 755 0 0 file /bin/busybox /bin/busybox 755 0 0 slink /bin/sh busybox 777 0 0 dir /realroot 755 0 0 dir /etc 755 0 0 dir /proc 755 0 0 dir /sys 755 0 0 dir /sbin 755 0 0 file /sbin/lvm.static /sbin/lvm.static 755 0 0 #file /sbin/mdadm /sbin/mdadm 755 0 0 file /sbin/cryptsetup /sbin/cryptsetup 755 0 0 file /sbin/e2fsck /sbin/e2fsck 755 0 0 dir /lib 755 0 0 file /lib/libext2fs.so /usr/lib64/libext2fs.so 755 0 0 dir /dev 755 0 0 nod /dev/console 600 0 0 c 5 1 nod /dev/null 666 0 0 c 1 3 nod /dev/tty 666 0 0 c 5 0 nod /dev/urandom 666 0 0 c 1 9 file /init /usr/src/init.sh 755 0 0 -- Neil Bothwick Don't take life too seriously, you won't get out alive. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, 25 Dec 2012 15:42:22 -0600, Dale wrote: > > 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. > Then there is my luck. Right? Ah yes, I forgot you "Have Awful Luck" :P -- Neil Bothwick DCE seeks DTE for mutual exchange of data. signature.asc Description: PGP signature
Re: [gentoo-user] Re: Anyone switched to eudev yet?
On Tue, Dec 25, 2012 at 1:19 PM, Neil Bothwick wrote: > 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 If you have one handy and it's not something huge (I don't think it is but I don't really know) maybe you could post an example of what that file looks like? Thanks, Mark
Re: [gentoo-user] Re: Anyone switched to eudev yet?
Neil Bothwick wrote: > 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. > > Then there is my luck. Right? 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 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
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?
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 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
