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: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Thu, 27 Dec 2012 17:38:15 -0600 Canek Peláez Valdés can...@gmail.com wrote: In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, Please explain, sure there is the environment that tells a daemon what to do. No shell can tell a c daemon like sshd how to drop priviledges or use systrace but it could do these things for it in a more fine grained manner before it tries and fails itself or if the daemon wishes it to like monit. It's still not telling how but duplicating or removing the need. That's just a bonus that applies to all init systems because shell is so powerful on unix.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 12/28/12 13:15, pk wrote: On 2012-12-28 00:24, Canek Peláez Valdés wrote: Well, yeah, that's the point. I want to install Gentoo in my mother's PC, and never have to go to her house because someting broke. I really don't have the time nor the inclination to continue this but... Why would you in that case install Gentoo and not Fedora? They (Fedora) do the kitchen-and-sink-installation with systemd, which begs the question: Why are you using Gentoo in the first place? I'm asking because I honestly don't see why you would want to use it if you just don't want to care about how the system works... This has nothing to do with (e)udev, but Gentoo is actually easier to keep working than any of the distributions that change everything all at once on a Monday morning. Fedora et al. are only easier to maintain for friends/family if you don't plan on having the machine (or friend) for more than a year.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 12:15 PM, pk pete...@coolmail.se wrote: On 2012-12-28 00:24, Canek Peláez Valdés wrote: Well, yeah, that's the point. I want to install Gentoo in my mother's PC, and never have to go to her house because someting broke. I really don't have the time nor the inclination to continue this but... Why would you in that case install Gentoo and not Fedora? Because I prefer Gentoo? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 27 Dec 2012 17:38:15 -0600 Canek Peláez Valdés can...@gmail.com wrote: In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, Please explain, sure there is the environment that tells a daemon what to do. No shell can tell a c daemon like sshd how to drop priviledges or use systrace but it could do these things for it in a more fine grained manner before it tries and fails itself or if the daemon wishes it to like monit. It's still not telling how but duplicating or removing the need. That's just a bonus that applies to all init systems because shell is so powerful on unix. Stop thinking in sshd. I can write the *whole* daemon in shell, not in another script file, but inside /etc/init.d/mystupiddaemon (or /etc/rc.whatever); shell is Turing-complete, I can write in it anything I can write in C (or in assembler, or machine code). In that sense, the init system (which uses shell for launching daemons) can be used to determine *how* the daemon behaves (because it uses shell for launching daemons). You can't do that with systemd; there is a clear and unavoidable separation between the starting/stoping/monitoring of daemons, and the daemons themselves. Such distinction doesn't really exists in SysV nor OpenRC (since they use shell, a Turing-complete language, for launching daemons), and therefore you can mixup everything. I agree, it doesn't necessarily means that it *will* happen; but even the possibility is frigthning for a system administrator in a production server. With systemd, that possibility *doesn't exist* (because it doesn't uses a Turing-complete language to start/stop/monitor daemons). Like the clear separation between content and presentation in webapps, or between the model and the view in the MVC design patter, having a clear separation between how you start/stop/monitor your daemon, and what the daemon does, is a good thing. If you don't agree with that, well, we must agree to disagree. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Dec 29, 2012 2:18 AM, Canek Peláez Valdés can...@gmail.com wrote: Stop thinking in sshd. I can write the *whole* daemon in shell, not in another script file, but inside /etc/init.d/mystupiddaemon (or /etc/rc.whatever); shell is Turing-complete, I can write in it anything I can write in C (or in assembler, or machine code). In that sense, the init system (which uses shell for launching daemons) can be used to determine *how* the daemon behaves (because it uses shell for launching daemons). You can't do that with systemd; there is a clear and unavoidable separation between the starting/stoping/monitoring of daemons, and the daemons themselves. Such distinction doesn't really exists in SysV nor OpenRC (since they use shell, a Turing-complete language, for launching daemons), and therefore you can mixup everything. I agree, it doesn't necessarily means that it *will* happen; but even the possibility is frigthning for a system administrator in a production server. You got it wrong. SysAdmins, especially Enterprise SysAdmins, will prefer total control of the startup process. If a daemon is extremely important for enterprise operation, any SysAdmin worth his/her salary will fire up vi (or emacs) and pepper the code with asserts and instrumentation. Having a Turing-complete language for starting a script is one of our (= Enterprise SysAdmins) weapon for fixing up glitches due to some changes introduced by the package maintainer. An example: A dev needs a newer version of a package. We upgrade it. It refuses to startup properly, but going back is out of the question because the dev *needs* the features only available in the new version. We check the (extremely) detailed logs. We find out what made the package balked. We do some changes, and all is well. Another example: After a security audit, we are required to upgrade a certain daemon to a new version, despite the current version running well. As we feared, the new version can't start. We use the detailed log to find out what happened. We made changes. It works again. In the two examples I give, having a C program doing all the starting will certainly mean that complex things have to be done, not to mention the headache of compiling them -- and possibly fail. sh scripts are much easier to modify. Like the clear separation between content and presentation in webapps, or between the model and the view in the MVC design patter, having a clear separation between how you start/stop/monitor your daemon, and what the daemon does, is a good thing. That is the Theory. In Practice, things don't work that way. Murphy's Law reigns supreme. Rgds, --
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 2:17 PM, Pandu Poluan pa...@poluan.info wrote: On Dec 29, 2012 2:18 AM, Canek Peláez Valdés can...@gmail.com wrote: Stop thinking in sshd. I can write the *whole* daemon in shell, not in another script file, but inside /etc/init.d/mystupiddaemon (or /etc/rc.whatever); shell is Turing-complete, I can write in it anything I can write in C (or in assembler, or machine code). In that sense, the init system (which uses shell for launching daemons) can be used to determine *how* the daemon behaves (because it uses shell for launching daemons). You can't do that with systemd; there is a clear and unavoidable separation between the starting/stoping/monitoring of daemons, and the daemons themselves. Such distinction doesn't really exists in SysV nor OpenRC (since they use shell, a Turing-complete language, for launching daemons), and therefore you can mixup everything. I agree, it doesn't necessarily means that it *will* happen; but even the possibility is frigthning for a system administrator in a production server. You got it wrong. I don't believe so. SysAdmins, especially Enterprise SysAdmins, will prefer total control of the startup process. If a daemon is extremely important for enterprise operation, any SysAdmin worth his/her salary will fire up vi (or emacs) and pepper the code with asserts and instrumentation. Pandou, I have worked as SysAdmin. Several years. Total control has degrees; if you program in assembly language, you have even more control. And with systemd you can still fire up vi or Emacs (or, if you prefer total control, ed), and fix *your* daemon. If systemd has a bug, you can still look at the code, and fix *that* code. What you say doesn't make any sense: any SysAdmin worth his/her salary will fire up vi (or emacs) and pepper the code with asserts and instrumentation works in SysV, OpenRC, systemd, and anything else as long as you have the source code. The only problem resides in proprietary code. Having a Turing-complete language for starting a script is one of our (= Enterprise SysAdmins) weapon for fixing up glitches due to some changes introduced by the package maintainer. Again, you make no sense: you can fix glitches as long as you have the source code. You can roll your own packages (I maintain my overlay to get rid of OpenRC on my systems). That some SysAdmins can *only* code properly (if at all) in shell is a problem of *those* SysAdmins. A worthy SysAdmin, if encountering a bug with systemd, can easily check out the C code and fix it (it's relatively simple, not kernel-level). And having a separation between the starting/stoping of daemons and the daemons themselves makes it easier to check where the bug lies, and fixing accordingly, instead of patching blindly to workaround the real problem. An example: A dev needs a newer version of a package. We upgrade it. It refuses to startup properly, but going back is out of the question because the dev *needs* the features only available in the new version. We check the (extremely) detailed logs. We find out what made the package balked. We do some changes, and all is well. How that is not possible in systemd? Another example: After a security audit, we are required to upgrade a certain daemon to a new version, despite the current version running well. As we feared, the new version can't start. We use the detailed log to find out what happened. We made changes. It works again. How that is not possible in systemd? Have you ever used it? In the two examples I give, having a C program doing all the starting will certainly mean that complex things have to be done, not to mention the headache of compiling them -- and possibly fail. You are assuming the problem is going to be in systemd's side. First of all, that will not always be the case. Second, if it is the case, you go and fix it. You still have the code. SysAdmin's laziness is not an excuse to do things wrong. It's also more complex to add comments to the code, it's more complex to take notes of the procedures rolling servers, it's more complex to keep a database of the versions running in each machine, and what hardware has and when it was installed. It's always more complex to properly do the job. sh scripts are much easier to modify. Read above. Like the clear separation between content and presentation in webapps, or between the model and the view in the MVC design patter, having a clear separation between how you start/stop/monitor your daemon, and what the daemon does, is a good thing. That is the Theory. In Practice, things don't work that way. Murphy's Law reigns supreme. Then we should agree to disagree in this particular issue. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 2012-12-28 20:01, Canek Peláez Valdés wrote: Because I prefer Gentoo? That's what I really don't understand! You say you don't want to care about the system which implies Fedora or any other install-and-forget distro. I care about the system which is why I run Gentoo. Do you have USE=* in make.conf too? That last part is not to be taken seriously but that's (basically) what the masses are running (and from what I can interpret your emails that's what you want). I'm done, thanks for listening. Best regards Peter K
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, 28 Dec 2012 13:14:46 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 27 Dec 2012 17:38:15 -0600 Canek Peláez Valdés can...@gmail.com wrote: In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, Please explain, sure there is the environment that tells a daemon what to do. No shell can tell a c daemon like sshd how to drop priviledges or use systrace but it could do these things for it in a more fine grained manner before it tries and fails itself or if the daemon wishes it to like monit. It's still not telling how but duplicating or removing the need. That's just a bonus that applies to all init systems because shell is so powerful on unix. Stop thinking in sshd. I can write the *whole* daemon in shell, not in another script file, but inside /etc/init.d/mystupiddaemon (or /etc/rc.whatever); shell is Turing-complete, I can write in it anything I can write in C (or in assembler, or machine code). In that sense, the init system (which uses shell for launching daemons) can be used to determine *how* the daemon behaves (because it uses shell for launching daemons). That's what you meant, how disappointing. Yeah I've knocked up a few very useful ones myself but call them scripts (Such as grepping logs or dns servers and feeding real daemons with info). You can't do that with systemd; there is a clear and unavoidable You can't is better is it? Yet you can exec a daemon written in shell with systemd. separation between the starting/stoping/monitoring of daemons, and the daemons themselves. Such distinction doesn't really exists in SysV nor OpenRC (since they use shell, a Turing-complete language, for With regular expressions to get the exact pid but /usr/sbin/sshd -f /etc/ssh/sshd_config = start /usr/bin/pkill sshd = stop or many other incantations There are many tools that do this job just fine. If systemd just did this and was there by default I would consider replacing monit with it. Like a reliable root filesystem I want a reliable pid 1. launching daemons), and therefore you can mixup everything. I agree, it doesn't necessarily means that it *will* happen; but even the possibility is frigthning for a system administrator in a production server. With systemd, that possibility *doesn't exist* (because it doesn't uses a Turing-complete language to start/stop/monitor daemons). Doesn't frighten me one bit. I know the startup almost inside out of my servers, doesn't take long on OpenBSD. On Linux it would take longer but nowhere near reviewing systemd and knowing C has nothing to do with the immediate control shell can provide under any init system including systemd but the Turing complete argument is simply propaganda as well as all the features to distract from the fundamental flaws in the design of systemd. Like the clear separation between content and presentation in webapps, or between the model and the view in the MVC design patter, having a clear separation between how you start/stop/monitor your daemon, and what the daemon does, is a good thing. If you don't agree with that, well, we must agree to disagree. There is nothing else, you exec or parse a script or daemon just as systemd does. The only difference is systemd tracking double forked processes with cgroups and I have already provided a link that refutes any point to do so. There are corner cases that are easily manageable and it certainly isn't worth the sacrifice of POSIX compatibility and so Linux applicability. Linus has said cgroups are a horrible but necessary evil, which in my opinion means avoid them unless you have no choice. There is a perfectly good and in my opinion superior choice, but I love simplicity, it has served me well.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 4:40 PM, pk pete...@coolmail.se wrote: On 2012-12-28 20:01, Canek Peláez Valdés wrote: Because I prefer Gentoo? That's what I really don't understand! You say you don't want to care about the system which implies Fedora or any other install-and-forget distro. I care about the system which is why I run Gentoo. Do you have USE=* in make.conf too? That last part is not to be taken seriously but that's (basically) what the masses are running (and from what I can interpret your emails that's what you want). I have USE=-kde -qt4 in my desktop/laptop. Last time I tried that with RedHat and Mandrake (many, *many* years ago), it wasn't easy, and I'm not certain that it is possible. Like everyone here, I use Gentoo for it's flexibility at the moment of configuring it. That doesn't mean I want to keep track of absolutely everything in my machines; I love to set them up. Once. Then I love to forget about them; they should just work. I'm done, thanks for listening. Thanks to you. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 5:23 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Fri, 28 Dec 2012 13:14:46 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Fri, Dec 28, 2012 at 12:53 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Thu, 27 Dec 2012 17:38:15 -0600 Canek Peláez Valdés can...@gmail.com wrote: In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, Please explain, sure there is the environment that tells a daemon what to do. No shell can tell a c daemon like sshd how to drop priviledges or use systrace but it could do these things for it in a more fine grained manner before it tries and fails itself or if the daemon wishes it to like monit. It's still not telling how but duplicating or removing the need. That's just a bonus that applies to all init systems because shell is so powerful on unix. Stop thinking in sshd. I can write the *whole* daemon in shell, not in another script file, but inside /etc/init.d/mystupiddaemon (or /etc/rc.whatever); shell is Turing-complete, I can write in it anything I can write in C (or in assembler, or machine code). In that sense, the init system (which uses shell for launching daemons) can be used to determine *how* the daemon behaves (because it uses shell for launching daemons). That's what you meant, how disappointing. Yeah I've knocked up a few very useful ones myself but call them scripts (Such as grepping logs or dns servers and feeding real daemons with info). You can't do that with systemd; there is a clear and unavoidable You can't is better is it? Yet you can exec a daemon written in shell with systemd. separation between the starting/stoping/monitoring of daemons, and the daemons themselves. Such distinction doesn't really exists in SysV nor OpenRC (since they use shell, a Turing-complete language, for With regular expressions to get the exact pid but /usr/sbin/sshd -f /etc/ssh/sshd_config = start /usr/bin/pkill sshd = stop or many other incantations There are many tools that do this job just fine. If systemd just did this and was there by default I would consider replacing monit with it. Like a reliable root filesystem I want a reliable pid 1. launching daemons), and therefore you can mixup everything. I agree, it doesn't necessarily means that it *will* happen; but even the possibility is frigthning for a system administrator in a production server. With systemd, that possibility *doesn't exist* (because it doesn't uses a Turing-complete language to start/stop/monitor daemons). Doesn't frighten me one bit. I know the startup almost inside out of my servers, doesn't take long on OpenBSD. On Linux it would take longer but nowhere near reviewing systemd and knowing C has nothing to do with the immediate control shell can provide under any init system including systemd but the Turing complete argument is simply propaganda as well as all the features to distract from the fundamental flaws in the design of systemd. Like the clear separation between content and presentation in webapps, or between the model and the view in the MVC design patter, having a clear separation between how you start/stop/monitor your daemon, and what the daemon does, is a good thing. If you don't agree with that, well, we must agree to disagree. There is nothing else, you exec or parse a script or daemon just as systemd does. The only difference is systemd tracking double forked processes with cgroups and I have already provided a link that refutes any point to do so. There are corner cases that are easily manageable and it certainly isn't worth the sacrifice of POSIX compatibility and so Linux applicability. Linus has said cgroups are a horrible but necessary evil, which in my opinion means avoid them unless you have no choice. There is a perfectly good and in my opinion superior choice, but I love simplicity, it has served me well. I don't doub it. As I said, the only thing to do is to agree to disagree. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Sat, Dec 29, 2012 at 4:17 AM, Pandu Poluan pa...@poluan.info wrote: An example: A dev needs a newer version of a package. We upgrade it. It refuses to startup properly, but going back is out of the question because the dev *needs* the features only available in the new version. We check the (extremely) detailed logs. We find out what made the package balked. We do some changes, and all is well. Another example: After a security audit, we are required to upgrade a certain daemon to a new version, despite the current version running well. As we feared, the new version can't start. We use the detailed log to find out what happened. We made changes. It works again. In the two examples I give, having a C program doing all the starting will certainly mean that complex things have to be done, not to mention the headache of compiling them -- and possibly fail. You obviously haven't the slightest _clue_ what the hell you're talking about. 1) systemd does not prevent you from checking logs. If anything the systemd journal gives you more fine-grained tools for ensuring that some logs came from some daemon, not so easy to ensure when your log file is being peppered with auth attempts and whatnot. 2) the make some changes part you mentioned has little, if anything, to do with the init script that started it. Any Enterprise SysAdmin worth his salt, to use your term, knows it's 99% something he overlooked in the config settings that are independent of the startup system. 3) Having a C program doing all the starting doesn't imply complex things have to be done, because in most cases your startup script - whatever it's written in - simply calls the program with the right arguments. Ironically, shell scripts only appear simpler because _someone has already done the complex things for you_. -- This email is:[ ] actionable [ ] fyi[x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [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? - what was wron with SysVInit?
* Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then Kevin started to suggest that I know nothing about init systems, and I responded in kind. I did not and apologise if you took offense. I said perhaps badly that based on this posting, you don't have a great deal of experience in init systems. To me, your comment demonstrated that you don't on the vast plethora of init systems which all actually accomplish the same thing daemon wise just with varying reliability and functionality surrounding the process of doing so. No init system can tell a daemon how to do anything. So your comment. What to do, how to do actually has nothing to do with systemd. What does is having to learn a new more restrictive non intuitive and non externally useful or non universal *declarative* language. Like polkit/pkexecs javascript vs sudo. I will take sudoers every time and for good reason. Shell scripts usually spiral out of control is just utter FUD. I do realise you didn't originate this FUD, but it shouldn't be spread. Yes some corner case wants in init that some thought impossible in shell can get complex by scripting them but a small c tool following the unix philosophy simply becomes a shell command potentially useful in even unforeseeable cases. We are dealing with simple options meant for admins here. As I said OpenBSDs scripts are usually rediculously simple and should often really be called commands. As others have said the argument of function being in the scripts rather than the daemon is an irrelevance to using systemd. Systemd may try to become the whole OS but I'm fairly sure it hasn't plagiarised the c code to check and deal with ssh keys yet. That is rightly the job of the aptly named ssh-keygen and IMO some very simple shell code. The arch sshd script is only 44 lines and includes more than that to make the output colourful. The gentoo sshd script is actually simple too and doesn't do anything most of the time and is easily modifiable in absolutely predictable ways. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Thu, Dec 27, 2012 at 10:00 AM, pk pete...@coolmail.se wrote: On 2012-12-27 02:14, Canek Peláez Valdés wrote: I really think that's the crux of the matter Pandou: udev/systemd serves to the wants of the many. The eudev fork serves to the wants of systemd+udev serves the large mass (users of mainly Fedora and other distros using systemd) that doesn't care/know computers. Well, yeah, that's the point. I want to install Gentoo in my mother's PC, and never have to go to her house because someting broke. a very few which really don't want an initramfs, when it has a lot of technical advantages. It has some problems, of course, but we can solve those, and solve the problem *in the general case*. Which is the one that it's important ant interesting. It's unimportant and uninteresting on the terms that Poettering/Sievers/Greg KH put forward, for us that wants control and does not want an all singing and dancing system (incl. kitchen sink). In my opinion the init system should be completely independent of the kernel with a well defined, generic, interface so that the user can choose and pick whatever pieces he/she wishes to run his system. Think Lego (as in small, well defined pieces that fit together in any way the user sees fit)... And how's that changed? If you want control, you will *always* have control. The source code is out there; what more control do you need? my wishing luck to the eudev fork (which, BTW, Greg also did). The few The way I read Greg's good luck was that it had quite a bit of a sarcastic tone... Was there really any need for him to say anything at all? I've previously had a lot of respect for Greg but this made me think quite a lot less of him... That's how you choose to interpret it, and I'm pretty sure it was not the way Greg said it. of us who *dare* to praise udev/systemd get an incredible amount of crap for it. We are nothing but fanbois or, in your words, udev has become like the cosmos: everything there is, and ever shall be. Really? I didn't knew that. You really sound like a fanboy... And I don't mean that in a derogatory way; it's just how I see your writing... It does sound derogatory... Maybe we are doing it wrong. But as far as i can see, we are only expressing our opinion on technical grounds. We are not calling names Your opinions (technical or not) doesn't matter to me since (it seems) you have a very different goal than me with your system. I want you to enjoy whatever system you use but you shouldn't try to force that same system on to me. In that regard I see the eudev fork as a saviour. What *I* am forcing on *anyone*? How could *I* force *anything* on *anyone*? I'm just stating why I believe udev/systemd is a nice solution to the general problem. That's all: I'm not a developer, I'm not a distro planer; I'm not in any way capable to enforce anything on anyone. And I, if I'm allowed to repeat it, have never called names on anyone. I'm just stating my opinion; how could you twist that into the idea that I'm trying to force that same system on to me? Really? These are the technical grounds that I've seen you state: * fast boot time Irrelevant, BIOS/UEFI/card firmware takes longer time than booting to XDM for me. The few seconds that it takes to boot from grub to login is of no matter (to me). It matters to me. A lot. Specially in my laptop (I follow vanilla-sources unstable, so I reboot relatively often), in my media center (same reasons). In my servers certainly the hardware initialization phase is longer; but (IMO) that makes even more important the speed gains from grub to userspace. Please, understand that my above (↑) reasons doesn't mean I don't care of yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. * parallel service startup Nice to have but still irrelevant, see above. Sequential is also preferred from a trouble shooting perspective. Furthermore I like having the ability to stop a particular daemon if there something that needs fixing (pushing I when booting). Relevant for me, see above. And that's another thing I hate about the shell init scripts; problems get workarounded instead of properly fixed. If there is a problem at boot time *it should be fixed where the problem lives*, not workarounded with shell hackery. Again, please understand that my above (↑) reasons doesn't mean I don't care of yours, or that you are wrong. It only means that our reasons are different, and then perhaps the proper thing to do is to agree to disagree. * simple service unit files Simplicity is fine but to accomplish the same in your simple service file as in the example you brought forward (sshd) you need to hide a lot of stuff elsewhere. Not for me thanks, I'm a control freak. I'm not; let the machines do the work. The least I have to think about my system, the better; I care only for it to work. Again, please
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Thu, Dec 27, 2012 at 10:29 AM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then Kevin started to suggest that I know nothing about init systems, and I responded in kind. I did not and apologise if you took offense. Apology accepted, and I also apologise if my response was out of line/with bad tone. I said perhaps badly that based on this posting, you don't have a great deal of experience in init systems. Well, I haven't wrote any, but I used the ones in OpenBSD, Solaris, Linux SysV, OpenRC systemd, and Windows NT. Used as in administering several machines with them. So, I have some experience. To me, your comment demonstrated that you don't on the vast plethora of init systems which all actually accomplish the same thing daemon wise just with varying reliability and functionality surrounding the process of doing so. No init system can tell a daemon how to do anything. You are wrong. In SysV, I can *write* the daemon in the init script. In *that* sense, the init system tells the daemon how to do things, and to a lesser degree, it happens when you use a shell to launch daemons. So your comment. What to do, how to do actually has nothing to do with systemd. What does is having to learn a new more restrictive non intuitive and non externally useful or non universal *declarative* language. Like polkit/pkexecs javascript vs sudo. I will take sudoers every time and for good reason. I'm not 100% happy with Polkit use of JS, but having finally understood how it works, I think is kind of nice. I believe role verification and authentication is one of the tasks where a Turing-complete language actually be justified. Shell scripts usually spiral out of control is just utter FUD. I do realise you didn't originate this FUD, but it shouldn't be spread. Yes some corner case wants in init that some thought impossible in shell can get complex by scripting them but a small c tool following the unix philosophy simply becomes a shell command potentially useful in even unforeseeable cases. Funny that you said that; if you are really interested, take a look at /usr/lib/systemd in a systemd machine. Almost all of those are really simple C programs that do one thing, and one thing only. Most of them don't reach the 100 lines of C code. To me, a Turing-complete language for starting and stoping services is overkill. And also there is the Halting Problem; you simply cannot workaround that. We are dealing with simple options meant for admins here. As I said OpenBSDs scripts are usually rediculously simple and should often really be called commands. As others have said the argument of function being in the scripts rather than the daemon is an irrelevance to using systemd. Systemd may try to become the whole OS but I'm fairly sure it hasn't plagiarised the c code to check and deal with ssh keys yet. That is rightly the job of the aptly named ssh-keygen and IMO some very simple shell code. Yeah, running from the install script/Makefile/post-inst-hook/whatever. Not the init system. IMO. The arch sshd script is only 44 lines and includes more than that to make the output colourful. The gentoo sshd script is actually simple too and doesn't do anything most of the time and is easily modifiable in absolutely predictable ways. I'm not arguing that; I'm arguing that it can be done even more simple, and even more easily modifiable. But like a said to Pandou; let's just agree to disagree. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
Am Donnerstag, 27. Dezember 2012, 07:45:24 schrieb Pandu Poluan: On Dec 26, 2012 1:05 AM, Canek Peláez Valdés can...@gmail.com wrote: Even Linus piped up at one point, sharply reminding Greg KH that even though udev was at one time Greg's 'baby', at this point udev serves only the wants of the few. link? -- #163933
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Fri, Dec 28, 2012 at 02:06:27AM +0100, Volker Armin Hemmann wrote: Am Donnerstag, 27. Dezember 2012, 07:45:24 schrieb Pandu Poluan: On Dec 26, 2012 1:05 AM, Canek Peláez Valdés can...@gmail.com wrote: Even Linus piped up at one point, sharply reminding Greg KH that even though udev was at one time Greg's 'baby', at this point udev serves only the wants of the few. link? Surf around here http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/49758/focus%3D55168 -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, 25 Dec 2012 02:01:13 -0600 Canek Peláez Valdés can...@gmail.com wrote: To the OP of this OT sub-thread. The main difference for me is OpenRC removes some of the symlink mess and uncertainty compared to for example debians init. I very much like OpenRC but my fav is still OpenBSD that tries to minimise the number of files/folders to be potentially locked down and is very transparent and quick to follow through. On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. (With a solid state hard drive, my laptop now boots even faster). The usual statistic cited is 2 seconds but systemd can increase the time dramatically or be a complete no go on embedded systems with limited cpu and/or ram. Percentages of a section of the bootup is just playing games like often used by annoying marketing departments. You will save more boot time by switching to xfce from KDE/Gnome with stronger arguments for doing so. * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. Some will tell you that for them it works, but just like the guys who have a separate /usr and refuse to use an initramfs, they just haven't been bitten by the inherent problems of it (just ask kernel developer Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just broken with parallel service startup. Not only that but is seen by many to be pointless except to minute speed gains and a cause of various problems such as increased difficulty in determining where a problem occurs. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: But require reading documentation to understand with no other external gain, unlike shell. * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. That explains why I see so many asking for help. The documentation may? be complete but is terrible. Like LVM it is spread out into many illogical files that would require a non existent sitemap to find. OpenBSD is renowned for it's excellent documentation and note that it's openssl pages are consolidated. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. Nothing new, OpenBSD does similar. Completely aside from this discussion. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. The OpenBSD list pointed out the double forking argument to be technically pointless. http://marc.info/?l=openbsd-miscm=135314269712851w=2 * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. So why was /etc/inittab removed for something that takes much more effort to configure. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then you don't have a great deal of experience in init systems. These are the ones off the top of my head; but what I like the most about systemd is that it just works, and that
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, 25 Dec 2012 08:56:38 -0500 Joshua Murphy poiso...@gmail.com wrote: It would still be a (notable, at that) drop in size if the shell script was redone to provide exactly the same set of features, then compared, but that size difference wouldn't have the same shock value as the comparison against 80+ lines. If you look at the ssh devs distribution OpenBSD, sshd's rc config is a one liner basically of simply enable or provide command line arguments. Key checking is part of the OS startup script which is beautifully easy to read and follow through to shutdown. The turing complete language as oppose to the increased pid1 of systemd is a theoretical fallacy where bugs can be immediately fixed with a text editor or swapping the constantly tested but admittedly complex shell code. Note though that init does not require a shell or Turing complete language at all or anything else making it appropriate in it's various forms to all cases. Ironically this variation can be seen as unifying unix communities. What would be good is a common agreement on the format or sysadmins equivelent to API of controlling a universally applicable init system.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, Dec 26, 2012 at 4:19 PM, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote: On Tue, 25 Dec 2012 02:01:13 -0600 Canek Peláez Valdés can...@gmail.com wrote: To the OP of this OT sub-thread. The main difference for me is OpenRC removes some of the symlink mess and uncertainty compared to for example debians init. I very much like OpenRC but my fav is still OpenBSD that tries to minimise the number of files/folders to be potentially locked down and is very transparent and quick to follow through. On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. (With a solid state hard drive, my laptop now boots even faster). The usual statistic cited is 2 seconds but systemd can increase the time dramatically or be a complete no go on embedded systems with limited cpu and/or ram. Percentages of a section of the bootup is just playing games like often used by annoying marketing departments. You will save more boot time by switching to xfce from KDE/Gnome with stronger arguments for doing so. * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. Some will tell you that for them it works, but just like the guys who have a separate /usr and refuse to use an initramfs, they just haven't been bitten by the inherent problems of it (just ask kernel developer Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just broken with parallel service startup. Not only that but is seen by many to be pointless except to minute speed gains and a cause of various problems such as increased difficulty in determining where a problem occurs. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: But require reading documentation to understand with no other external gain, unlike shell. * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. That explains why I see so many asking for help. The documentation may? be complete but is terrible. Like LVM it is spread out into many illogical files that would require a non existent sitemap to find. OpenBSD is renowned for it's excellent documentation and note that it's openssl pages are consolidated. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. Nothing new, OpenBSD does similar. Completely aside from this discussion. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. The OpenBSD list pointed out the double forking argument to be technically pointless. http://marc.info/?l=openbsd-miscm=135314269712851w=2 * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. So why was /etc/inittab removed for something that takes much more effort to configure. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then you don't have a great deal of experience in init systems. These are the
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, Dec 26, 2012 at 6:01 PM, Canek Peláez Valdés can...@gmail.com wrote: [snip] I didn't started the thread, Wolfe did. I just answered his question from my point of view. And, what community is being divided? Fedora,OpenSuse, and Arch use systemd by default. Gentoo derivative Exherbo recommends it as init system. It works great on Gentoo and Debian. I understand it even works in Ubuntu. systemd has done more to unify the Linux ecosystem than a lot of other projects in the last 20 years. And, really, I don't care about OpenBSD. I worked with it for three years; it's a nice toy Unix. You do realize you just lost any moral high ground you might have had over saying things that might or might not offend others? Seriously? toy? I'm not an OpenBSD user. But I do know it's one of the longest-lived, most prominent UNIX-like systems in the ecosystem, and it's the home for a huge amount of code that's imported by virtually every other notable operating system. To call it a toy tells me you know next to nothing about the history (or even present) positions and involvement of the major players of the UNIX-like ecosystem over the last twenty years. But for serious work (server, desktop and mobile) I prefer Linux, and in my case (except for my phone, that uses Android) I run Gentoo+systemd in all my machines. You don't have to agree with that, is my personal preference. Canek, I have to ask. Have you ever done _anything_ outside of academia? Up to Masters, academia is learning about what is. Afterward, it's either about teaching or discovering what may be...but a Masters only teaches you theory. A Doctorate is a discovery of a truth under controlled conditions. The real world is nowhere near that clean. Quite frankly, I've found your emails to have to have a far more pomp, ipsie dixit arguments, playbook arguments and appeals to authority than hard, technical defense of arguments against your positions in debate. Generally, I try to ignore you, and when I respond, it's usually because your emails carry with them a tone of authority that could easily mislead the uninformed into assuming he'd just read the One True Way on some subject--something that's terrible when there are real differences and not always clear-cut answers. I try very, very hard to avoid both the use and appearance of use of ad hominem arguments and reasoning. I do my damnedest to give the benefit of the doubt. However, quite frankly, I've read almost everything you've posted to this list over the last year and a half, and you've never consistently exhibited an awareness of pragmatic concerns for the subject, an understanding of the low levels issues in theoretical concerns of the subject, or an ability to stick to technical argument in a non-evasive fashion; that you might be wrong on a technical point never occurs to you, and when pressed, you engage in sophistry. Quite frankly, you act and speak more like a PR spokesman than an engineer. It's this behavior that probably led Bruce to make a crack about your defense of systemd to an irrational degree. You advocate, but you don't respond to criticisms with substance, suggesting your advocacy isn't something based on rational motivation. My purpose in debate isn't to win, it's to understand. I would be positively delighted if you would approach debate the with the same goal; we might be able to learn from each other. -- :wq
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, 26 Dec 2012 17:01:17 -0600 Canek Peláez Valdés can...@gmail.com wrote: And, what community is being divided? Fedora,OpenSuse, and Arch use systemd by default. From debian and hurd to slackware which will not touch systemd ever and ubuntu and also embedded with the kernel working on more and more deeply embedded processors and userland working potentially on less or more difficulties in porting if lennart's dreams ever come to pass, which I hope many won't. So way more than half of linux will not use systemd by default likely ever and it is rather different. Any unification it does bring like /etc/hostname could be easily achieved with a little organisation without systemd and would be way more constructive if it happened because of that single purpose. I didn't even mention POSIX compliance which is a requirement on many projects. Fudging POSIX into Linux only would defeat the whole point of POSIX, though apparently that is a real danger.
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Dec 26, 2012 1:05 AM, Canek Peláez Valdés can...@gmail.com wrote:
{supersnip}
So, no, I'm not trying to answer if you could create a /usr service
and make things dependent on /usr come after it's been mounted. I
passed almost this entire thread because it's mostly people still
hitting the same dead horse; really, if someone believe the eudev fork
is the answer, they should go forth and use it. If there are people
who don't want to believe developers like Greg Kroah-Hartman or Diego
Pettenò when they basically say that eudev is a joke, why they would
believe *me*? And, by the way, Diego doesn't like systemd *at all*.
Canek, I distinctly remember, at the very beginning of this brouhaha over
udev requiring /usr to be mounted at boot time, you stated something along
the lines of 'show me the code, then I'll believe that replacing udev is
doable'.
First, Walter Dnes came out with an amazingly complete -- considering it
was all done by just one man -- solution using mdev. You scoffed at him,
saying that mdev solution is incomplete.
Now, some respected Gentoo devs forked udev into eudev, and produced a
working solution, yet you still scoff at them.
In your eyes, udev has become like the cosmos: everything there is, and
ever shall be.
Greg KH and Diego Petteno are similar; they ridiculed a good forking by
spreading FUD, and almost totally unwilling to listen to rational arguments
from the devs about why udev is forked. As a result, they received great
opposition, in turn. Even Linus piped up at one point, sharply reminding
Greg KH that even though udev was at one time Greg's 'baby', at this point
udev serves only the wants of the few.
I'd say that you, Greg KH, and others denigrating eudev are udev fanatics,
preferring to denigrate anything outside the 'party lines' of udev+systemd.
Rgds,
--
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, Dec 26, 2012 at 5:51 PM, Michael Mol mike...@gmail.com wrote: On Wed, Dec 26, 2012 at 6:01 PM, Canek Peláez Valdés can...@gmail.com wrote: [snip] I didn't started the thread, Wolfe did. I just answered his question from my point of view. And, what community is being divided? Fedora,OpenSuse, and Arch use systemd by default. Gentoo derivative Exherbo recommends it as init system. It works great on Gentoo and Debian. I understand it even works in Ubuntu. systemd has done more to unify the Linux ecosystem than a lot of other projects in the last 20 years. And, really, I don't care about OpenBSD. I worked with it for three years; it's a nice toy Unix. You do realize you just lost any moral high ground you might have had over saying things that might or might not offend others? Seriously? toy? Hey, it's my opinion. You don't need to agree with me and, again, I don't pretend to offend anyone. It's jsut what I think. Have you read the name calling against GNOME and udev/systemd projects, developers and/or users? How come you never say anything about those? I'm not an OpenBSD user. But I do know it's one of the longest-lived, most prominent UNIX-like systems in the ecosystem, and it's the home for a huge amount of code that's imported by virtually every other notable operating system. Longest-lived mean nothing. Literally. Minix is older than all the modern *BSDs and Linux, and its author called it (until recently) a toy Unix. To call it a toy tells me you know next to nothing about the history (or even present) positions and involvement of the major players of the UNIX-like ecosystem over the last twenty years. I know my Unix history, thank you very much. Do you? You read LWN, don't you? http://lwn.net/Articles/524606/ I call OpenBSD a toy Unix in the sense of the above article's quote: There will be fewer and fewer settings where BSD-based systems will operate in the way their users want. That, needless to say, is a recipe for irrelevance and, eventually, disappearance. But for serious work (server, desktop and mobile) I prefer Linux, and in my case (except for my phone, that uses Android) I run Gentoo+systemd in all my machines. You don't have to agree with that, is my personal preference. Canek, I have to ask. Have you ever done _anything_ outside of academia? Up to Masters, academia is learning about what is. Afterward, it's either about teaching or discovering what may be...but a Masters only teaches you theory. A Doctorate is a discovery of a truth under controlled conditions. The real world is nowhere near that clean. Again, thank you for teaching me about the real world. I worked for various years between my Bachelor's and Master's degrees, programming and administering Linux, SCO, BSD and Aix systems. I still administer several machines in my university. I think I know the real world, thanks. Quite frankly, I've found your emails to have to have a far more pomp, ipsie dixit arguments, playbook arguments and appeals to authority than hard, technical defense of arguments against your positions in debate. Generally, I try to ignore you, and when I respond, it's usually because your emails carry with them a tone of authority that could easily mislead the uninformed into assuming he'd just read the One True Way on some subject--something that's terrible when there are real differences and not always clear-cut answers. Relax Michael; as I said in other emails: who the fuck cares what I say or who I am? Wolfe made a question, I tried to answer it to the best of my knowledge. That's it: nobody has to agree with me, nobody has to do anything about what I write. Not even read it. By the way, did you read whay Kevin told me? * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). Then you don't have a great deal of experience in init systems. I understand that in the Gentoo mailing lists (which doens't necessarily reflect the Gentoo community as a whole), us udev/systemd users and supporters look like a (very maligned) minority. I understand a lot of people here doesn't like the direction udev/systemd is taking Linux. But it's really kinda funny how people react when we calmly try to express why do we like said direction. I try very, very hard to avoid both the use and appearance of use of ad hominem arguments and reasoning. I do my damnedest to give the benefit of the doubt. However, quite frankly, I've read almost everything you've posted to this list over the last year and a half, and
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, Dec 26, 2012 at 6:45 PM, Pandu Poluan pa...@poluan.info wrote:
On Dec 26, 2012 1:05 AM, Canek Peláez Valdés can...@gmail.com wrote:
{supersnip}
Canek, I distinctly remember, at the very beginning of this brouhaha over
udev requiring /usr to be mounted at boot time, you stated something along
the lines of 'show me the code, then I'll believe that replacing udev is
doable'.
Yeah, and like I said, check the commits in eudev. They haven't done
nothing but to remove code and a very rational (IMO) dependency, kmod.
First, Walter Dnes came out with an amazingly complete -- considering it was
all done by just one man -- solution using mdev. You scoffed at him, saying
that mdev solution is incomplete.
I'm sorry if sounded like scoffing (certainly I don't remember
scoffing anyone, at least consciously). I remember I praised Walt for
doing the work for mdev. Do you remember that? I can dig the archives,
but I'm pretty sure I said that I greatly admired him.
Now, some respected Gentoo devs forked udev into eudev, and produced a
working solution, yet you still scoff at them.
I'm not the one doing the scoffing; those where Greg and Diego. And
sorry, but I really trust those guys.
In your eyes, udev has become like the cosmos: everything there is, and ever
shall be.
No, of course no. Hell, I hope something even better will be developed
along the way. And I said at some point (to Greg, in the -dev list)
that *perhaps* something good will come from eudev. I hope you
remember, but (again) I can search the archives.
Greg KH and Diego Petteno are similar; they ridiculed a good forking by
spreading FUD, and almost totally unwilling to listen to rational arguments
from the devs about why udev is forked. As a result, they received great
opposition, in turn. Even Linus piped up at one point, sharply reminding
Greg KH that even though udev was at one time Greg's 'baby', at this point
udev serves only the wants of the few.
I really think that's the crux of the matter Pandou: udev/systemd
serves to the wants of the many. The eudev fork serves to the wants of
a very few which really don't want an initramfs, when it has a lot of
technical advantages. It has some problems, of course, but we can
solve those, and solve the problem *in the general case*. Which is the
one that it's important ant interesting.
In my humble opinion (apparently, if I don't say that, it sounds like
it's impossible for me to be wrong).
I'd say that you, Greg KH, and others denigrating eudev are udev fanatics,
preferring to denigrate anything outside the 'party lines' of udev+systemd.
What about Diego? He doesn't like systemd.
Pandou, the party lines and the thought police is the other way
around in this list. You don't seem to remember my praises to Walt or
my wishing luck to the eudev fork (which, BTW, Greg also did). The few
of us who *dare* to praise udev/systemd get an incredible amount of
crap for it. We are nothing but fanbois or, in your words, udev has
become like the cosmos: everything there is, and ever shall be.
Really? I didn't knew that.
Maybe we are doing it wrong. But as far as i can see, we are only
expressing our opinion on technical grounds. We are not calling names
nor doubting their technical backgrounds, nor telling people what they
should or should not use.
It's the other way around.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Wed, Dec 26, 2012 at 7:14 PM, Canek Peláez Valdés can...@gmail.com wrote: [ snip ] I'm sorry if sounded like scoffing (certainly I don't remember scoffing anyone, at least consciously). I remember I praised Walt for doing the work for mdev. Do you remember that? I can dig the archives, but I'm pretty sure I said that I greatly admired him. Found it: http://article.gmane.org/gmane.linux.gentoo.user/254885 As I have said before, I admire a lot what Walter et al. are doing, and as I always will say, this is how our community works: people writing the code (as Walter is doing) are the ones that get things done. This is the correct (and only) way to address a problem (perceived or real) with the current status: write the code that does the thing the way you want it. Complaining and crying that you don't like the direction some part of the stack is taking is at best a waste of time, and at worst idiotic. Actually doing something about it (as Walter is doing) is the smart thing to do. [ snip ] In your eyes, udev has become like the cosmos: everything there is, and ever shall be. No, of course no. Hell, I hope something even better will be developed along the way. And I said at some point (to Greg, in the -dev list) that *perhaps* something good will come from eudev. I hope you remember, but (again) I can search the archives. Found this one also: http://article.gmane.org/gmane.linux.gentoo.devel/81251 Seeing some people comparing udev to XFree86 is one of the more bizarre things coming out from this fork, and that's saying. However, I agree with Doug that anyone should code whatever they want to code. Who knows, maybe something interesting would come off from this fork, and it certainly doesn't affect us happy Gentoo+systemd+udev users. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. (With a solid state hard drive, my laptop now boots even faster). * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. Some will tell you that for them it works, but just like the guys who have a separate /usr and refuse to use an initramfs, they just haven't been bitten by the inherent problems of it (just ask kernel developer Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just broken with parallel service startup. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). These are the ones off the top of my head; but what I like the most about systemd is that it just works, and that it makes a lot of sense (at least to me). Most of systemd features can be implemented in OpenRC, although the speed difference will never be eliminated if OpenRC keeps using shell files; however, Luca Barbato said that using reentrant busybox the speed difference is greatly reduced (I haven't confirmed this, since I haven't even installed OpenRC in months). Now, this set of (IMO) advantages of systemd over OpenRC pile up over the advantages of OpenRC over SysV: the most important one (I believe) is that OpenRC has dependencies, so a service starts only when another has already started. AFAIK, SysV has lacked this since always. I don't think I have ever heard anyone saying that we should keep using SysV; like a lot of Unix legacies, it should just die. OpenRC is much better, but it still uses a Turing-complete language (and a really slow one) to simply tell services when to start and when to stop, and it doesn't reliably keep track of what services are really still running (anyone who has ever used the zap command in OpenRC knows this). systemd of course has dependencies, a reliable tracking of service status (thanks in part to the use of cgroups), and its service files can't enter in an infinite loop. Hope it helps. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 12/25/2012 03:01 AM, Canek Peláez Valdés wrote: On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Thanks, quite helpful. -- G.Wolfe Woodbury
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Dec 25, 2012 3:04 AM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. (With a solid state hard drive, my laptop now boots even faster). * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. Some will tell you that for them it works, but just like the guys who have a separate /usr and refuse to use an initramfs, they just haven't been bitten by the inherent problems of it (just ask kernel developer Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just broken with parallel service startup. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). These are the ones off the top of my head; but what I like the most about systemd is that it just works, and that it makes a lot of sense (at least to me). Most of systemd features can be implemented in OpenRC, although the speed difference will never be eliminated if OpenRC keeps using shell files; however, Luca Barbato said that using reentrant busybox the speed difference is greatly reduced (I haven't confirmed this, since I haven't even installed OpenRC in months). Now, this set of (IMO) advantages of systemd over OpenRC pile up over the advantages of OpenRC over SysV: the most important one (I believe) is that OpenRC has dependencies, so a service starts only when another has already started. AFAIK, SysV has lacked this since always. I don't think I have ever heard anyone saying that we should keep using SysV; like a lot of Unix legacies, it should just die. OpenRC is much better, but it still uses a Turing-complete language (and a really slow one) to simply tell services when to start and when to stop, and it doesn't reliably keep track of what services are really still running (anyone who has ever used the zap command in OpenRC knows this). systemd of course has dependencies, a reliable tracking of service status (thanks in part to the use of cgroups), and its service files can't enter in an infinite loop. Hope it helps. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México Thank you. I think that may well be the cleanest set of
[gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 2012-12-25, Michael Mol wrote: Now, question: could I not create a /usr service and make things dependent on /usr come after it's been mounted? That seems the single, core missing piece. This suffices for /usr on regular partitions. The problem is with more complex stuff which, I assume (assume, because nobody who actually has that setup has actually explained what happens), requires device files which are not present under /dev by default, and, even if /dev is already mounted once init is started, it only has a handful of default files. The additional, non-default files for most of the stuff are nowadays created through udev, and so you need to have udevd running and processing events to populate /dev. Thus: - The already existing rules will silently fail problem will not be solved, as some events will get processed before you have a chance to mount /usr - The udev won't work because it is under /usr issue, which seems to be the case of udev since it got merged with systemd (once again I'm assuming here, from a bug report)), well, this one is not easy to solve unless you copy the udev tools to / or to some initr*, or you install udev to /. But, of course, for /usr on regular partitions, just issuing mount /usr before starting udevd works. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, Dec 25, 2012 at 3:01 AM, Canek Peláez Valdés can...@gmail.com wrote: [ snip ] * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). [snip] Hope it helps. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México I've not yet made the leap, as the benefit of faster boot really doesn't affect me between systems that're always on and laptops that typically spend 75% of their time asleep, rather than ever getting turned off, so I'm in no position to speak for or against the whole of systemd's changes... but one issue I've had with the claimed benefits is the reduction in size compared to startup scripts like /etc/init.d/sshd ... based on that service declaration above, it's a horribly unfair comparison. /etc/init.d/sshd is doing a lot more than simply starting/stopping the service and dropping all of that functionality, then claiming these few lines serve the same purpose isn't an equal comparison. It would still be a (notable, at that) drop in size if the shell script was redone to provide exactly the same set of features, then compared, but that size difference wouldn't have the same shock value as the comparison against 80+ lines. The argument that those functions should be handled by the service rather than the service handler is for another day, 'course. I'll eventually get around to switching to play with systemd, at the very least to learn its quirks enough to work with it, and it's very helpful to have a clearly stated set of _favorable_ comments on it (compared to the majority of less favorable commentary) to look forward to, so don't take my having one issue with the list as anything against either the list as a whole or your effort in putting all that together, as both are very much appreciated. Happy holidays. -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, Dec 25, 2012 at 7:14 AM, Michael Mol mike...@gmail.com wrote: On Dec 25, 2012 3:04 AM, Canek Peláez Valdés can...@gmail.com wrote: On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury redwo...@gmail.com wrote: [ snip ] From what has been happening with the systemd stuff, I do not see what advantages it really offers over the SysV scheme and its successors like OpenRC. Someone enlighten me please? I wrote the following some months ago; I think nothing much has changed since then (I added a couple of comments): Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: * Really fast boot. OpenRC takes at least double the time that systemd does when booting, easily verifiable. In my laptop systemd is twice as fast as OpenRC; in my desktop is three times faster. (With a solid state hard drive, my laptop now boots even faster). * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. Some will tell you that for them it works, but just like the guys who have a separate /usr and refuse to use an initramfs, they just haven't been bitten by the inherent problems of it (just ask kernel developer Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just broken with parallel service startup. * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). * Really good documentation: systemd has one of the best documentations I have ever seen in *any* project. Everything (except really new, experimental features) is documented, with manual pages explaining everything. And besides, there are blog posts by Lennart explaining in a more informal way how to do neat tricks with systemd. * Really good in-site customization: The service unit files are trivially overrided with custom ones for specific installations, without needing to touch the ones installed by systemd or a program. With OpenRC, if I modify a /etc/init.d file, chances are I need to check out my next installation so I can see how the new file differs from the old one, and adapt the changes to my customized version. * All the goodies from Control Groups: You can use kernel cgroups to monitor/control several properties of your daemons, out of the box, almost no admin effort involved. * It tries to unify Linux behaviour among distros (some can argue that this is a bad thing): Using systemd, the same configurations/techniques work the same in every distribution. No more need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by different distros. * Finally, and what I think is the most fundamental difference between systemd and almost any other init system: The service unit files in systemd are *declarative*; you tell the daemon *what* to do, not *how* to do it. If the service files are shell scripts (like in OpenRC/SysV), everything can spiral out of control really easily. And it usually does (again, look at sshd; and that one is actully nicely written, there are all kind of monsters out there abusing the power that shell gives you). These are the ones off the top of my head; but what I like the most about systemd is that it just works, and that it makes a lot of sense (at least to me). Most of systemd features can be implemented in OpenRC, although the speed difference will never be eliminated if OpenRC keeps using shell files; however, Luca Barbato said that using reentrant busybox the speed difference is greatly reduced (I haven't confirmed this, since I haven't even installed OpenRC in months). Now, this set of (IMO) advantages of systemd over OpenRC pile up over the advantages of OpenRC over SysV: the most important one (I believe) is that OpenRC has dependencies, so a service starts only when another has already started. AFAIK, SysV has lacked this since always. I don't think I have ever heard anyone saying that we should keep using SysV; like a lot of Unix legacies, it should just die. OpenRC is much better, but it still uses a Turing-complete language (and a really slow one) to simply tell services when to start and when to stop, and it doesn't reliably keep track of what services are really still running (anyone who has ever used the zap command in OpenRC knows this). systemd of course has dependencies, a reliable tracking of service status (thanks in part to the use of cgroups), and its service files can't enter in an infinite loop. Hope it helps. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On Tue, Dec 25, 2012 at 7:56 AM, Joshua Murphy poiso...@gmail.com wrote: On Tue, Dec 25, 2012 at 3:01 AM, Canek Peláez Valdés can...@gmail.com wrote: [ snip ] * Really simple service unit files: The service unit files are really small, really simple, really easy to understand/modify. Compare the 9 lines of sshd.service: $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target with the 84 of /etc/init.d/sshd (80 without comments). [snip] Hope it helps. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México I've not yet made the leap, as the benefit of faster boot really doesn't affect me between systems that're always on and laptops that typically spend 75% of their time asleep, rather than ever getting turned off, so I'm in no position to speak for or against the whole of systemd's changes... but one issue I've had with the claimed benefits is the reduction in size compared to startup scripts like /etc/init.d/sshd ... based on that service declaration above, it's a horribly unfair comparison. /etc/init.d/sshd is doing a lot more than simply starting/stopping the service and dropping all of that functionality, then claiming these few lines serve the same purpose isn't an equal comparison. It would still be a (notable, at that) drop in size if the shell script was redone to provide exactly the same set of features, then compared, but that size difference wouldn't have the same shock value as the comparison against 80+ lines. The argument that those functions should be handled by the service rather than the service handler is for another day, 'course. No, I think that's the interesting argument. Like you say /etc/init.d/sshd is doing a lot more than simply starting/stopping the service; why it should do that? That's the work of the package manager and/or the administrator. An init system should only start/stop/monitor the services; it should not be checking if the keys are generated or not, or if the config file is there or not. That should happen at install time, and if for some reason they got borked between the last reboot and this one, the system is probably fucked up anyway, and putting checks in the *init script* will not help at all. But *even* if you really want to have those checks, you can do it in systemd in a cleaner way: put the checks in an executable script, and call the script with ExecStartPre: [Unit] Description=SSH Secure Shell Service After=syslog.target [Service] ExecStartPre=/usr/local/bin/checksshd ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target There; the unit file is now 10 lines, it *still* doesn't use a Turing-complete language, you got your checks (which I believe they don't belong there, but whatever), and it will timeout if the checksshd goes into an infinite loop (30 seconds is the default timeout, I believe). That's how yo properly do more than start/stop/monitor services; the init system doesn't need to know about it, you clearly move the init system responsibility (start/stop/monitor services) from the service requirements (checking that the config files are there, or that you need to generate keys, which I repeat, I think they belong at install time), and it keeps the unit files nice and simple. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: Anyone switched to eudev yet? - what was wron with SysVInit?
On 12/24/2012 10:56 PM, Pandu Poluan wrote: Even back when hard disks are a mote in the eyes of today's mammoths, you *can* make /usr part of /, there's no stopping you. Sure, other SysAdmins may scoff and/or question your sanity, but the choice is yours. YOU know what's best for your precious servers, YOU made the call. But with the latest udev, Lennart et al saw it fit to yank that choice out of the hands of SysAdmins, while at the same time trying to enforce a stupidly overbloated init replacement. I may be really out of the loop or old-fashioned, but what went wrong with the old SysV init scheme? SysV inhereited the init scheme practically in toto from what was created for the intermediate SysIV version that was intermal to Bell Labs. SysIV got used for a few projects, and it was a major improvement over the SysIII scheme. Those developing the SysIV/SysV init scheme tried to anticipate future extensions (especially dependency problems) even to the point of ashing Murry Hill to make chenges to the shell to make some magic easier. [Specifically the use of shell exec for input/output file descriptor changes.] [Disclaimer: I was working a Holmdel with a SystemIV based project as a contractor and was involved in some of this work.] 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? -- G.Wolfe Woodbury redwo...@gmail.com
