Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Thu, March 22, 2012 12:55 am, Walter Dnes wrote: On Wed, Mar 21, 2012 at 12:02:32PM -0400, Michael Mol wrote I said this before, but it sounds useful to try to reiterate: * It's probable that service-specific files should not be included in the init system package. * Service-specific init files should probably be part of the distro-localized version of a service-providing package. This doesn't mean modifying binaries, this is part of bootstrapping a service's environment. Call it deferred installation stages, if you like; things which need to be done for the service to be configured and properly operate. My point is that the startup, sanity-checking, and initialization code has to go *SOMEWHERE*. Where do you propose moving it to? This discussion reminds me of an ethnic joke. A bunch of workers had dug out a hole for the basement and foundations where a new house was to be built. The workers ask their foreman what they should do with the pile of dirt they had from digging out the hole for the new house. Their foreman, who is tells them to go dig another hole in the ground and throw the dirt in there. G ... After pushing the foreman in ;) -- Joost
RE: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
From: Walter Dnes [mailto:waltd...@waltdnes.org] Sent: Thursday, March 22, 2012 5:14 PM On Wed, Mar 21, 2012 at 09:35:55PM -0400, Michael Mol wrote What we're talking about with systemd vs openrc, and things like ssh'd first-time initialization is all within the realm of responsibility of the packager. It's a shift in the way the distribution itself works. We're not talking about a scenario where you shunt things upstream, so the whole your position would have rejected Linux angle is a red herring. This is a frustrating game of whack-a-mole. Person A comes up with a position, I rebut it, and then person B comes up with a different position, and I have to rebut it.. There have been people in this thread who have said that the program best knows what it needs, and should handle its own initialization. That was what I was replying to. I'll reply to your position now. You know the old adage, if you ask 5 geeks a question you get 6 different answers. This whole discussion is somewhat surreal to me, when taken in conjunction with the other heated debate we just finished having: * udev is evil and horrible because it's trying to do too much and is too complex. * system is evil and horrible because it isn't doing enough and is too simple. And I'm pretty I've seen at least one person making both arguments simultaneously. Why does that spawned process have to be sshd? Why can't it be some shell script which does the one-time checks, and then launches sshd itself? So instead of the initscript doing the checking+setup and launching the service, it launches a a second script... which does the checking+setup and launches the service FACEPALM. See my post with the joke of digging a second hole to dump the dirt from the first hole into. Instead of one script, we now have two scripts. This is *NOT* simplification. It works fine for mysql, or postfix, or apache, or any of the dozens of other programs that have helper scripts whose sole purposes is to act as an entry point to starting up the actual service. It's a common and well-accepted way of performing required initialization on startup. I don't see why sshd has to be special here. Why does that shell script need to be distributed as part of the init system's package, and not part of the package associated with the service? I don't understand what you're arguing here. *THE INITSCRIPT IS OWNED BY THE SERVICE PACKAGE*, not by the init package. E.g. net-misc/openssh, not sys-apps/openrc. You are absolutely correct; the discussion of who owns the init script is completely tangential to the system vs openrc argument; in both cases, the required startup files will be provided by the package maintainer and installed by the ebuild, not by the rc system. I think the confusion may have started way back when Canek tried to compare the simplicity of sshd.service to the complexity of /etc/init.d/sshd. That's the unfair, apples-to-oranges comparison that triggered this entire debate. The part that's been lost here is that system doesn't run init scripts(*); it launches configured services. These are *not* shell scripts; they are ini-file-like things that define parameters, much like xinetd's configuration files. Of course, I don't see why this is a problem: configure system to launch sshd's init script, which keeps doing the same thing it always has been doing. This is why the comparison between systemd's service config and openrc's script is unfair. You /cannot/ get rid of the complexity of /etc/init.d/sshd, you can only make it so that openrc and systemd can *both* take advantage of that complexity when starting sshd. That may, of course, require the package maintainer to provide 3 items instead of one: an openrc init script, a systemd service description, and an rc-agnostic helper script, in order to be fully systemd-compatible. In the meantime, the systemd package maintainer will likely be forced to provide some kind of compatibility shims to run existing openrc scripts that have not yet been refactored, but that's the cost of choice. It may already do this, I don't know. I have not yet installed systemd anywhere but I am curious enough to try it on my laptop. So I will be that much more informed in the near future :) (*) As I understand it, systemd *can* run SysV-style init scripts, but Gentoo's startup scripts are too dependent on openrc-supplied logic to be reusable in any meaningful sense. --Mike
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Wed, Mar 21, 2012 at 09:35:55PM -0400, Michael Mol wrote What we're talking about with systemd vs openrc, and things like ssh'd first-time initialization is all within the realm of responsibility of the packager. It's a shift in the way the distribution itself works. We're not talking about a scenario where you shunt things upstream, so the whole your position would have rejected Linux angle is a red herring. This is a frustrating game of whack-a-mole. Person A comes up with a position, I rebut it, and then person B comes up with a different position, and I have to rebut it.. There have been people in this thread who have said that the program best knows what it needs, and should handle its own initialization. That was what I was replying to. I'll reply to your position now. Why does that spawned process have to be sshd? Why can't it be some shell script which does the one-time checks, and then launches sshd itself? So instead of the initscript doing the checking+setup and launching the service, it launches a a second script... which does the checking+setup and launches the service FACEPALM. See my post with the joke of digging a second hole to dump the dirt from the first hole into. Instead of one script, we now have two scripts. This is *NOT* simplification. Why does that shell script need to be distributed as part of the init system's package, and not part of the package associated with the service? I don't understand what you're arguing here. *THE INITSCRIPT IS OWNED BY THE SERVICE PACKAGE*, not by the init package. E.g. net-misc/openssh, not sys-apps/openrc. waltdnes@d530 ~ $ equery b /etc/init.d/sshd * Searching for /etc/init.d/sshd ... net-misc/openssh-5.8_p1-r1 (/etc/init.d/sshd) Having the shell script be part of the package associated with the service keeps bugs related to that script associated with that package. That's the way it is right now. See above. At least, that's the way I see it. Any issue of compatibility between the two can be addressed by the service's package manager, either by adaption via that script, or by expressing an explicit dependency on one init architecture or another. My point in this whole argument is that there is some checking and setup that has to be done before launch. Therefore shuffling off some or all of the shellscript code to another script is a pointless shell game (sorry) that adds no value. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Thu, Mar 22, 2012 at 5:13 PM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Mar 21, 2012 at 09:35:55PM -0400, Michael Mol wrote What we're talking about with systemd vs openrc, and things like ssh'd first-time initialization is all within the realm of responsibility of the packager. It's a shift in the way the distribution itself works. We're not talking about a scenario where you shunt things upstream, so the whole your position would have rejected Linux angle is a red herring. This is a frustrating game of whack-a-mole. Person A comes up with a position, I rebut it, and then person B comes up with a different position, and I have to rebut it.. There have been people in this thread who have said that the program best knows what it needs, and should handle its own initialization. That was what I was replying to. I'll reply to your position now. Why does that spawned process have to be sshd? Why can't it be some shell script which does the one-time checks, and then launches sshd itself? So instead of the initscript doing the checking+setup and launching the service, it launches a a second script... which does the checking+setup and launches the service FACEPALM. See my post with the joke of digging a second hole to dump the dirt from the first hole into. Instead of one script, we now have two scripts. This is *NOT* simplification. No. In a system V scenario, you'd probably just symlink to the genericized init script. In the systemd scenario, as I understand it, you have a configuration file (distinct from a script), and you'd include the path to the genericized init script there. What I'm talking about is an implementation of the adapter pattern. http://en.wikipedia.org/wiki/Adapter_pattern If there are going to be competing init systems (and there will be), and a service needs to be compatible with both (and there will be such services), then that's going to be the most elegant solution. Why does that shell script need to be distributed as part of the init system's package, and not part of the package associated with the service? I don't understand what you're arguing here. *THE INITSCRIPT IS OWNED BY THE SERVICE PACKAGE*, not by the init package. E.g. net-misc/openssh, not sys-apps/openrc. waltdnes@d530 ~ $ equery b /etc/init.d/sshd * Searching for /etc/init.d/sshd ... net-misc/openssh-5.8_p1-r1 (/etc/init.d/sshd) Sure. And that's what I was arguing. Though by the sound of it, there's stuffed in the openrc package which doesn't need to be there, and a blog post flameeyes posted today suggests the systemd package is intended to absorb the hardware database. ( http://blog.flameeyes.eu/2012/03/refreshing-a-4-years-old-problem ) Having the shell script be part of the package associated with the service keeps bugs related to that script associated with that package. That's the way it is right now. See above. And that's the way it should be. At least, that's the way I see it. Any issue of compatibility between the two can be addressed by the service's package manager, either by adaption via that script, or by expressing an explicit dependency on one init architecture or another. My point in this whole argument is that there is some checking and setup that has to be done before launch. Therefore shuffling off some or all of the shellscript code to another script is a pointless shell game (sorry) that adds no value. See reference to the adapter pattern above. Systemd has its merits in its capabilities. System V init has merits in that it's far more portable. Open source software which operates as a system service will need to support both. There are, of course, things I loathe. I loathe the apparent mindset behind systemd and behind udev, wherein all things belong as part of a monolithic system. That runs counter to principles of modular design, portability and even systemic stability in changing things. I loathe the desire to lunge forward without working out a transition plan, or even having the appearance of interest in one. And I loathe the terrible PR. -- :wq
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Tue, Mar 20, 2012 at 01:18:24AM +0200, Alan McKinnon wrote I'm not sure where you're going with this. We're discussing an init system and good, simple ways to start services. App maintainers are going to continue to do whatever they feel they ought to do, some might write the systemd files, some might not - that is what already happens. Someone has to write it and what goes in it depends on what the app code does, not the other way round. The point I'm making is that if the initialization is moved into the binary, then the binary will have to be patched/modified/whatever. There's already somebody with a systemd overlay. Assuming that the initialization code gets shoved into the binary, how does it simultaneously support openrc/systemd/linux/bsd/Sun/HPUX/etc/etc? The only realistic answer I see is leaving the init code to the distro maintainer. We don't expect the upstream for sshd or any other software to write Gentoo-specific stuff like ebuilds. Whey should they be expected to write Gentoo-specific initscripts? As for the last question, I really have no idea where you're taking this. I don't know the answer, I've never been a maintainer in that position. Being the arrogant shit that I am, I reckon I would probably tell the user to piss off and I don't support hobby crap. But hey, that's just what I think I might say while sitting here on my couch. So you're saying you wouldn't have supported... From: torva...@klaava.helsinki.fi (Linus Benedict Torvalds) Newsgroups: comp.os.minix Subject: What would you like to see most in minix? Summary: small poll for my new operating system Message-ID: 1991aug25.205708.9...@klaava.helsinki.fi Date: 25 Aug 91 20:57:08 GMT Organization: University of Helsinki Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready.I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system(due to practical reasons) among other things). I've currently ported bash(1.08) and gcc(1.40),and things seem to work.This implies that I'll get something practical within a few months, andI'd like to know what features most people would want. Any suggestions are welcome, but I won't promise I'll implement them :-) Linus (torva...@kruuna.helsinki.fi) PS. Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Wed, 21 Mar 2012 00:40:27 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Tue, Mar 20, 2012 at 01:18:24AM +0200, Alan McKinnon wrote I'm not sure where you're going with this. We're discussing an init system and good, simple ways to start services. App maintainers are going to continue to do whatever they feel they ought to do, some might write the systemd files, some might not - that is what already happens. Someone has to write it and what goes in it depends on what the app code does, not the other way round. The point I'm making is that if the initialization is moved into the binary, then the binary will have to be patched/modified/whatever. There's already somebody with a systemd overlay. Assuming that the initialization code gets shoved into the binary, how does it simultaneously support openrc/systemd/linux/bsd/Sun/HPUX/etc/etc? The only realistic answer I see is leaving the init code to the distro maintainer. We don't expect the upstream for sshd or any other software to write Gentoo-specific stuff like ebuilds. Whey should they be expected to write Gentoo-specific initscripts? Fair enough As for the last question, I really have no idea where you're taking this. I don't know the answer, I've never been a maintainer in that position. Being the arrogant shit that I am, I reckon I would probably tell the user to piss off and I don't support hobby crap. But hey, that's just what I think I might say while sitting here on my couch. So you're saying you wouldn't have supported... No, you're saying that you believe that you think I would say that based on some extrapolation of I don't know what. I said no such thing. I said that I don't know what I would do Let's not get too carried away with Linus's little project being representative of anything. It's a fluke. There are 100s of other hobby systems that went nowhere. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Wed, Mar 21, 2012 at 10:29 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Wed, 21 Mar 2012 00:40:27 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Tue, Mar 20, 2012 at 01:18:24AM +0200, Alan McKinnon wrote I'm not sure where you're going with this. We're discussing an init system and good, simple ways to start services. App maintainers are going to continue to do whatever they feel they ought to do, some might write the systemd files, some might not - that is what already happens. Someone has to write it and what goes in it depends on what the app code does, not the other way round. The point I'm making is that if the initialization is moved into the binary, then the binary will have to be patched/modified/whatever. There's already somebody with a systemd overlay. Assuming that the initialization code gets shoved into the binary, how does it simultaneously support openrc/systemd/linux/bsd/Sun/HPUX/etc/etc? The only realistic answer I see is leaving the init code to the distro maintainer. We don't expect the upstream for sshd or any other software to write Gentoo-specific stuff like ebuilds. Whey should they be expected to write Gentoo-specific initscripts? Fair enough As for the last question, I really have no idea where you're taking this. I don't know the answer, I've never been a maintainer in that position. Being the arrogant shit that I am, I reckon I would probably tell the user to piss off and I don't support hobby crap. But hey, that's just what I think I might say while sitting here on my couch. So you're saying you wouldn't have supported... No, you're saying that you believe that you think I would say that based on some extrapolation of I don't know what. I said no such thing. I said that I don't know what I would do Let's not get too carried away with Linus's little project being representative of anything. It's a fluke. There are 100s of other hobby systems that went nowhere. I said this before, but it sounds useful to try to reiterate: * It's probable that service-specific files should not be included in the init system package. * Service-specific init files should probably be part of the distro-localized version of a service-providing package. This doesn't mean modifying binaries, this is part of bootstrapping a service's environment. Call it deferred installation stages, if you like; things which need to be done for the service to be configured and properly operate. -- :wq
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Wed, Mar 21, 2012 at 12:02:32PM -0400, Michael Mol wrote I said this before, but it sounds useful to try to reiterate: * It's probable that service-specific files should not be included in the init system package. * Service-specific init files should probably be part of the distro-localized version of a service-providing package. This doesn't mean modifying binaries, this is part of bootstrapping a service's environment. Call it deferred installation stages, if you like; things which need to be done for the service to be configured and properly operate. My point is that the startup, sanity-checking, and initialization code has to go *SOMEWHERE*. Where do you propose moving it to? This discussion reminds me of an ethnic joke. A bunch of workers had dug out a hole for the basement and foundations where a new house was to be built. The workers ask their foreman what they should do with the pile of dirt they had from digging out the hole for the new house. Their foreman, who is tells them to go dig another hole in the ground and throw the dirt in there. G -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Wed, Mar 21, 2012 at 6:55 PM, Walter Dnes waltd...@waltdnes.org wrote: On Wed, Mar 21, 2012 at 12:02:32PM -0400, Michael Mol wrote I said this before, but it sounds useful to try to reiterate: * It's probable that service-specific files should not be included in the init system package. * Service-specific init files should probably be part of the distro-localized version of a service-providing package. This doesn't mean modifying binaries, this is part of bootstrapping a service's environment. Call it deferred installation stages, if you like; things which need to be done for the service to be configured and properly operate. My point is that the startup, sanity-checking, and initialization code has to go *SOMEWHERE*. Where do you propose moving it to? Sure. But there's a difference between moving, e.g. sshd's first-time code into the net-misc/openssh package and moving it into the sshd binary itself. I don't want to sound condescending, but I really don't know how much of this is going to be generally known on this list, and I get the impression that it's unclear... (Also, I'm not an expert on this...) The distribution of software, as I understand it, generally has three groups of people who hold it: 1) Upstream. Generally, upstream will keep their software portable and agnostic, so it can be installed in a variety of places. That's not a requirement, but it's considered polite in the open-source world, and fairly necessary if they want the software to be broadly used. Upstream is expected to know their software well enough to keep it in active development, or at least in current maintenance. 2) Packager. A packager adapts upstream's software so that it fits in and plays nicely with the rest of the software in the system. The packager is expected to have the required understanding of both the software and the target distribution in order to accomplish this. 3) End user. The end user isn't typically expected to have a full understanding of the software or the distribution. He'll run the distribution's package manager to install the software, follow any instructions given for configuration, and apply any domain expertise he has to configure things to conform to site-local needs. What we're talking about with systemd vs openrc, and things like ssh'd first-time initialization is all within the realm of responsibility of the packager. It's a shift in the way the distribution itself works. We're not talking about a scenario where you shunt things upstream, so the whole your position would have rejected Linux angle is a red herring. Now, let's look at what an init system does. For each service, it spawns some process, checks a return code, declares either success or failure, and may take some further action based on that success or failure. Why does that spawned process have to be sshd? Why can't it be some shell script which does the one-time checks, and then launches sshd itself? Why does that shell script need to be distributed as part of the init system's package, and not part of the package associated with the service? Having the shell script be part of the package associated with the service keeps bugs related to that script associated with that package. As far as compatibility between init systems is concerned, you can symlink the init system's launch file (e.g. /etc/init.d/some_file) to wherever this shell script is, or you can configure the init system such that it knows where the shell script is. At least, that's the way I see it. Any issue of compatibility between the two can be addressed by the service's package manager, either by adaption via that script, or by expressing an explicit dependency on one init architecture or another. -- :wq
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sat, 17 Mar 2012 22:48:54 -0400 (EDT), Bruce Hill, Jr. wrote: And for the Lennart fanboi, his coding is so questionable that Lennartware has become derogatory slang. (Of course, you already know that.) And this is such a common term nowadays that when Googling for Lennartware only one reference to it turn up on the first page, and that is your post! I suppose by quoting your post I have doubled the popularity of this commonplace slang :-O This whole systemd for and against thread has turned up some interesting points - interspersed with vague handwaving from you. -- Neil Bothwick When there's a will, I want to be in it. signature.asc Description: PGP signature
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
i want to try this systemd thingy, where do is start at? i have a vm for testing and i might will adopt it on the real one. Thanks, Eliezer On 18/03/2012 09:28, Canek Peláez Valdés wrote: it or at least try it, and given the level of discussion you present, I'm starting to think you don't actually have the capacity to study it. So, in that sense, the one spreading the FUD is you. -- Eliezer Croitoru https://www1.ngtech.co.il IT consulting for Nonprofit organizations elilezer at ngtech.co.il
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sat, 17 Mar 2012 19:45:06 -0600, Canek Peláez Valdés wrote: * 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. This I like the sound of. -- Neil Bothwick Walking on water and writing software to specification is easy if they're frozen. signature.asc Description: PGP signature
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sun, 18 Mar 2012 02:49:56 -0600, Canek Peláez Valdés wrote: They ensure that there is an sshd configuration file and give a meaningful message (including where to find the sample) if it is not present, and check for the presence of the hostkeys (again which are needed) and create them if they are not present. Your 9 lines of sshd.service do none of this. That is completely true. I also think that those checks does not belong into the init script: I think the configuration file presence should be guarantee by the package manager at install time, and so the creation of the hostkeys. sshd is a bit of a special case. Think like CDs, like SystemRescueCD. If the keys were created at installation time, every CD would have the same keys, which is not particularly desirable. -- Neil Bothwick I heard someone tried the monkeys-on-typewriters bit trying for the plays of W. Shakespeare but all they got was the collected works of Francis Bacon signature.asc Description: PGP signature
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
Eliezer Croitoru writes: i want to try this systemd thingy, where do is start at? http://wiki.gentoo.org/wiki/Systemd Wonko
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Mon, Mar 19, 2012 at 9:33 AM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 18 Mar 2012 02:49:56 -0600, Canek Peláez Valdés wrote: They ensure that there is an sshd configuration file and give a meaningful message (including where to find the sample) if it is not present, and check for the presence of the hostkeys (again which are needed) and create them if they are not present. Your 9 lines of sshd.service do none of this. That is completely true. I also think that those checks does not belong into the init script: I think the configuration file presence should be guarantee by the package manager at install time, and so the creation of the hostkeys. sshd is a bit of a special case. Think like CDs, like SystemRescueCD. If the keys were created at installation time, every CD would have the same keys, which is not particularly desirable. I prefer counterexample to special case ... I don't like calling things special cases because it suggests that they're somehow more privileged than anything else, and unnecessarily weighs against software which hasn't been written yet. A similar case which falls into the same kind of circumstance: per-host IDs in mass-deployment scenarios. You see this in large arrays of similar systems; 'sbc-a3d6' 'sbc-a3d9' 'sbc-7721' ... Heck, applying something like that to live installation media would be nice; not having every new install called simply 'gentoo' by default would be very helpful in installfest scenarios. Identical hostnames screw with DHCP-driven DDNS updates. I ran into that on my home network. -- :wq
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On March 19, 2012 at 9:13 AM Neil Bothwick n...@digimed.co.uk wrote: On Sat, 17 Mar 2012 22:48:54 -0400 (EDT), Bruce Hill, Jr. wrote: And for the Lennart fanboi, his coding is so questionable that Lennartware has become derogatory slang. (Of course, you already know that.) And this is such a common term nowadays that when Googling for Lennartware only one reference to it turn up on the first page, and that is your post! I suppose by quoting your post I have doubled the popularity of this commonplace slang :-O This whole systemd for and against thread has turned up some interesting points - interspersed with vague handwaving from you. -- Neil Bothwick mingdao@workstation ~ $ grep Lennartware irclogs/* irclogs/#gentoo-dev.log:09:01 @bonsaikitten Caster: do you see now why I don't appreciate Lennartware? irclogs/#gentoo.log:10:56 @bonsaikitten Zaba: Lennartware. Linux needs to be more like MacOS https://s6-us2.startpage.com/do/search?cmd=process_searchpid=04014d679c59b80b606405a6fe33495a --- 4 references Various other mentions of systemd being nefarious software are mostly amongst kernel devs and might not use the word Lennartware, but the logical reasons why systemd is a _bad_ idea are the same. -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Mon, Mar 19, 2012 at 12:35:26AM +0200, Alan McKinnon wrote systemd is like Captain Picard of STTNG (Start Trek The Next Generation) always saying make it so. *HOW DO YOU MAKE IT SO? That intelligence has to be somewhere. So what alternative do you propose? A bash or ash script is more guaranteed to run than a binary. Shoving all that intelligence into the service itself, means that the service has to start up in order to determine whether it's safe for the service to start up. What's wrong with this picture? The intelligence goes in the init system's config file for that service of course. I know I didn't clearly say so, but that's where it goes. The config file can specify upper/lower limits, variables, settings, etc, etc. But in the end, some executable somewhere is going to have to parse the config file, check the actual environment, and decide whether or not to launch the service, and with what parameters. Note also that many open source programs are multiplatform. I.e. they run on FreeDOS with DJGPP, multiple flavours of Windows, multiple BSDs (including Apple), linux, and multiple commercial unix flavours. Do you really want to throw multiple platform-specific IFDEFs into the program code to allow the services to do the appropriate platform-specific initialization? Isn't it be easier to move the service setup out of the main service, and let the maintainers of the specific platforms figure it out? One last question. Let's go back in time 20 years, and assume that you're the maintainer for a program that runs as a service. A small handfull of end-users come along. They're running a hobby OS that fits on a couple floppies. Said hobby OS has been cobbled together by a university student. Would you... * download that university student's hobby OS, and install it * throw in a bunch of additional IFDEF initialization code in your program * test and debug the program to make sure it runs under that OS -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Mon, 19 Mar 2012 10:33:11 -0400 (EDT), Bruce Hill, Jr. wrote: And for the Lennart fanboi, his coding is so questionable that Lennartware has become derogatory slang. (Of course, you already know that.) And this is such a common term nowadays that when Googling for Lennartware only one reference to it turn up on the first page, and that is your post! mingdao@workstation ~ $ grep Lennartware irclogs/* irclogs/#gentoo-dev.log:09:01 @bonsaikitten Caster: do you see now why I don't appreciate Lennartware? irclogs/#gentoo.log:10:56 @bonsaikitten Zaba: Lennartware. Linux needs to be more like MacOS Wow, 2 mentions on IRC - the term really has invaded the English language. --- 4 references Still not enough for Google to see it, barely enough for a contrived allegation. Various other mentions of systemd being nefarious software are mostly amongst kernel devs and might not use the word Lennartware, but the logical reasons why systemd is a _bad_ idea are the same. Where does systemd come into it? Gentoo is following udev's upstream requirements. These may have been triggered by udev's support for systemd but that in no way means that systemd is required. Greg K-H is also in favour of making /usr available to early boot, are you going to accuse him of shoddy coding too? -- Neil Bothwick Of course, I could switch back to Windows. At least there, if I have a problem, I don't suffer under the illusion that I could ever fix it. - Unknown (paraphrased) signature.asc Description: PGP signature
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Mon, 19 Mar 2012 18:58:22 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Mon, Mar 19, 2012 at 12:35:26AM +0200, Alan McKinnon wrote systemd is like Captain Picard of STTNG (Start Trek The Next Generation) always saying make it so. *HOW DO YOU MAKE IT SO? That intelligence has to be somewhere. So what alternative do you propose? A bash or ash script is more guaranteed to run than a binary. Shoving all that intelligence into the service itself, means that the service has to start up in order to determine whether it's safe for the service to start up. What's wrong with this picture? The intelligence goes in the init system's config file for that service of course. I know I didn't clearly say so, but that's where it goes. The config file can specify upper/lower limits, variables, settings, etc, etc. But in the end, some executable somewhere is going to have to parse the config file, check the actual environment, and decide whether or not to launch the service, and with what parameters. Note also that many open source programs are multiplatform. I.e. they run on FreeDOS with DJGPP, multiple flavours of Windows, multiple BSDs (including Apple), linux, and multiple commercial unix flavours. Do you really want to throw multiple platform-specific IFDEFs into the program code to allow the services to do the appropriate platform-specific initialization? Isn't it be easier to move the service setup out of the main service, and let the maintainers of the specific platforms figure it out? One last question. Let's go back in time 20 years, and assume that you're the maintainer for a program that runs as a service. A small handfull of end-users come along. They're running a hobby OS that fits on a couple floppies. Said hobby OS has been cobbled together by a university student. Would you... * download that university student's hobby OS, and install it * throw in a bunch of additional IFDEF initialization code in your program * test and debug the program to make sure it runs under that OS I'm not sure where you're going with this. We're discussing an init system and good, simple ways to start services. App maintainers are going to continue to do whatever they feel they ought to do, some might write the systemd files, some might not - that is what already happens. Someone has to write it and what goes in it depends on what the app code does, not the other way round. I'm not punting the merits of systemd, I don;t know enough about it. I started off by saying a nice clean easy way to do init would be awesome, as I'm sick and tired of having to deal with sysvinit. That's all, don't read more into it than that. As for the last question, I really have no idea where you're taking this. I don't know the answer, I've never been a maintainer in that position. Being the arrogant shit that I am, I reckon I would probably tell the user to piss off and I don't support hobby crap. But hey, that's just what I think I might say while sitting here on my couch. Any other answer would be equally made up. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sat, Mar 17, 2012 at 10:17 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 17, 2012 at 10:57 PM Canek Peláez Valdés can...@gmail.com wrote: On Sat, Mar 17, 2012 at 8:48 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 17, 2012 at 8:48 PM Nikos Chantziaras rea...@gmail.com wrote: On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd. I'm the OP, and often I don't know how to express myself. It is my understanding that systemd is going to force an initramfs on you even if you only have / and no other partitions. (Could it be initrd and not initramfs?) I'm all for automounting a device when it's plugged in, if that's what the user chooses. But for me, with my workstation, laptop, wife's PC and daughter's laptop -- we just don't need or care for it. Seems a shame to be using udev and then have to completely change your system when 181 comes out, or freeze it at . Therefore, we don't install anything to automount devices. We have lines such as these in fstab: UUID=6C5F-3742 /Libby-Vivitar vfat noauto,users,rw,gid=100,dmask=0002,fmask=0113 0 0 for those devices we own. When we get a new device, we add a new line. We don't use a DE either, just Fluxbox. The bottom line is that I don't like things being forced on me (hint, get the vaseline, they're on the way!) And I don't like upstream forcing such nefarious changes on the distros. And for the Lennart fanboi, his coding is so questionable that Lennartware has become derogatory slang. (Of course, you already know that.) No need to get personal man, relax. I disagree ... there's every reason to get personal. Not getting personal doesn't assign the blame. Men stand up and take responsibility for their actions. You called me Lennart fanboi. That wasn't personal? I'm getting my PhD in Computer Science snip I got my PhD in life before your parents met. So what? Just saying... I'm not bragging; I just explained my credentials as to why I say that Lennart's code is actually quite good. Because I have actually studied it, besides tried it. Have you? And, are you gonna keep saying you are not getting personal, by the way? So again, please, [citation needed]. You still haven't provided any reference to support your claim that Lennart's code (specifically systemd's code) is poorly done. Mate, have you heard of the world wide web? The internet? And the Internet has always the same opinion. And it's never wrong. Seriously, mate ... are you his boyfriend, on his payroll, related, or what? No, I don't even know him. Are you gonna keep saying you are not getting personal, by the way? You search LKML for yourself. I've been there since 2003 and have numerous memories. Me too. Lennart has actually code accepted into the Linux Kernel, and he's a member of the Linux Kernel Plumbers. How's that as proof of the quality of his code? How about: http://www.change.org/petitions/lennart-poettering-stop-writing-useless-programs-systemd-journal Really? A petition on-line? With 235 votes? That's the best reference you can present? On one side, we have a guy whose code is included in all the levels on the stack, from kernel to end-user application. On the other, we have an open internet petition with 235 votes. Yeah, I'm gonna side with the on-line poll. Sorry, mate ... many of us here are allergic to FUD :-)} I would say that you are allergic to Lennart's work. But I'm pretty sure that you haven't take the time at least once to actually study it or at least try it, and given the level of discussion you present, I'm starting to think you don't actually have the capacity to study it. So, in that sense, the one spreading the FUD is you. All I keep saying is that I use systemd (and udev, and GNOME 3), and that I like it, and that I agree with the technical decisions behind it. That's it. Of course you don't have to agree with me (as I don't agree with you). But at least I'm not resort to name-calling, and I actually have tried (and studied) both systemd and OpenRC (which is the topic of this particular branch of the thread we are in). I'm out of this thread. As always, I give my opinion, do whatever you want with it.
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
Canek Peláez Valdés can...@gmail.com writes: * 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). But the 80 lines of /etc/init.d/sshd do a lot more than just and stop the service. They ensure that there is an sshd configuration file and give a meaningful message (including where to find the sample) if it is not present, and check for the presence of the hostkeys (again which are needed) and create them if they are not present. Your 9 lines of sshd.service do none of this.
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sun, Mar 18, 2012 at 2:02 AM, Graham Murray gra...@gmurray.org.uk wrote: Canek Peláez Valdés can...@gmail.com writes: * 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). But the 80 lines of /etc/init.d/sshd do a lot more than just and stop the service. Yes, it does. They ensure that there is an sshd configuration file and give a meaningful message (including where to find the sample) if it is not present, and check for the presence of the hostkeys (again which are needed) and create them if they are not present. Your 9 lines of sshd.service do none of this. That is completely true. I also think that those checks does not belong into the init script: I think the configuration file presence should be guarantee by the package manager at install time, and so the creation of the hostkeys. Having said that, systemd provides ConditionPathExists, which allows you to set a file as necessary for a service execution. So my 9 lines transform into $ cat /etc/systemd/system/sshd.service [Unit] Description=SSH Secure Shell Service After=syslog.target ConditionPathExists=/etc/ssh/sshd_config [Service] ExecStart=/usr/sbin/sshd -D [Install] WantedBy=multi-user.target If the config file doesn't exists, the service will not start, and you can check the reason why with systemctl status sshd.service And of course you can set another mini sevice unit file to create the hostkeys. But I repeat: I think those tasks belong into the package manager, no the init script. 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: systemd? [ Was: The End Is Near ... ]
On Mar 18, 2012 3:52 PM, Canek Peláez Valdés can...@gmail.com wrote: If the config file doesn't exists, the service will not start, and you can check the reason why with systemctl status sshd.service And of course you can set another mini sevice unit file to create the hostkeys. But I repeat: I think those tasks belong into the package manager, no the init script. Between installation by package manager and actual execution by the init system, things might happen on the required file(s). Gentoo's initscript guards against this possibility *plus* providing helpful error messages in /var/rc.log Or, said configuration files might be corrupted; the OpenRC initscript -- if written defensively -- will be able to detect that and (perhaps) fallback to something sane. systemd can't do that, short of putting all required intelligence into a script which it executes on boot. Now, if one has to put all the intelligence into a script file which gets executed by systemd, that results in a system that's more complex than plain OpenRC. Not only would one need to maintain the starting script, but one must also maintain systemd + dbus. So, the *only* benefit I can see about systemd is the smarter parallel startup of services. And believe me if I say that server guys (the ones handling tens or even hundreds of servers) would much prefer sequential startup of services than parallel ones. The former is deterministic, the latter is not. Rgds,
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sat, 17 Mar 2012 19:45:06 -0600 Canek Peláez Valdés can...@gmail.com 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). I'm having a wet dream right about now :-) init has been my pet peeve for years, starting with sysvinit. Why do I need 9 runlevels all fully configured, when me, my machines, the company's server, every Linux user in the company and every other use I have ever personally met, only use 1 of them? Let's not even discuss the amount of complexity that gets pushed into the init scripts themselves. Here's what I want: When the machine starts, I want services X, Y and Z to run. The software figures out what order they must start in and how the deps work. Clean, neat, easy. Maintenance mode is handled easily with two stages in startup: early_start and late_start. Maintenance mode is what you have between them. Again - nice, clean and simple. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
Alan McKinnon wrote: On Sat, 17 Mar 2012 19:45:06 -0600 Canek Peláez Valdés can...@gmail.com 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). I'm having a wet dream right about now :-) init has been my pet peeve for years, starting with sysvinit. Why do I need 9 runlevels all fully configured, when me, my machines, the company's server, every Linux user in the company and every other use I have ever personally met, only use 1 of them? Let's not even discuss the amount of complexity that gets pushed into the init scripts themselves. Here's what I want: When the machine starts, I want services X, Y and Z to run. The software figures out what order they must start in and how the deps work. Clean, neat, easy. Maintenance mode is handled easily with two stages in startup: early_start and late_start. Maintenance mode is what you have between them. Again - nice, clean and simple. Well, I am not normal. I, on a regular basis, use single, boot and default runlevels. So there !! lol Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words! Miss the compile output? Hint: EMERGE_DEFAULT_OPTS=--quiet-build=n
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sun, Mar 18, 2012 at 5:23 AM, Pandu Poluan pa...@poluan.info wrote: On Mar 18, 2012 3:52 PM, Canek Peláez Valdés can...@gmail.com wrote: If the config file doesn't exists, the service will not start, and you can check the reason why with systemctl status sshd.service And of course you can set another mini sevice unit file to create the hostkeys. But I repeat: I think those tasks belong into the package manager, no the init script. Between installation by package manager and actual execution by the init system, things might happen on the required file(s). Gentoo's initscript guards against this possibility *plus* providing helpful error messages in /var/rc.log Or, said configuration files might be corrupted; the OpenRC initscript -- if written defensively -- will be able to detect that and (perhaps) fallback to something sane. systemd can't do that, short of putting all required intelligence into a script which it executes on boot. That is a completely valid point, but I don't think that task belongs into the init system. The init system starts and stops services, and monitors them; checking for configuration files and creating hostkeys is part of the installation process. If something got corrupted between installation time and now, I would prefer my init system not to start a service; just please tell me that something is wrong. However, it's of course debatible. I agree with systemd's behavior; it's cleaner, more elegant, and it follows the Unix tradition: do one thing, and doing it right. 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: systemd? [ Was: The End Is Near ... ]
On Sun, Mar 18, 2012 at 3:25 PM, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Mar 18, 2012 at 5:23 AM, Pandu Poluan pa...@poluan.info wrote: On Mar 18, 2012 3:52 PM, Canek Peláez Valdés can...@gmail.com wrote: If the config file doesn't exists, the service will not start, and you can check the reason why with systemctl status sshd.service And of course you can set another mini sevice unit file to create the hostkeys. But I repeat: I think those tasks belong into the package manager, no the init script. Between installation by package manager and actual execution by the init system, things might happen on the required file(s). Gentoo's initscript guards against this possibility *plus* providing helpful error messages in /var/rc.log Or, said configuration files might be corrupted; the OpenRC initscript -- if written defensively -- will be able to detect that and (perhaps) fallback to something sane. systemd can't do that, short of putting all required intelligence into a script which it executes on boot. That is a completely valid point, but I don't think that task belongs into the init system. The init system starts and stops services, and monitors them; checking for configuration files and creating hostkeys is part of the installation process. If something got corrupted between installation time and now, I would prefer my init system not to start a service; just please tell me that something is wrong. However, it's of course debatible. I agree with systemd's behavior; it's cleaner, more elegant, and it follows the Unix tradition: do one thing, and doing it right. I like and see benefit to the systemd approach, honestly, but I don't think it necessarily follows to say that that belongs in the installation process, since it shouldn't be the responsibility of the init process. The way things sit currently, Gentoo doesn't default to adding new services to any runlevel, and in the process of setting up or reconfiguring a system, services may be added, removed, then possibly added again. Having a service's launch script perform one-time checks makes perfect sense in this regard. It's lazy evaluation; you don't do non-trivial work until you know it needs to be done. (And generating a 2048-bit or 4096-bit SSH key certainly qualifies as non-trivial work!) Also, I think the code golf argument is a poor one; how many lines something does to meet some particular goal ignores any other intended goals the compared object also meets. When you're comparing apples to apples, the argument is fine. When you're comparing apples to oranges, the argument is weakened; they're both fruits, but they still have different purposes in the larger context. In this case, I think the happy medium would be for systemd to start a service-provided launch script, which performs whatever additional checks are wanted or desired. Either way, it's the responsibility of whoever maintains the package for that service. -- :wq
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sun, 18 Mar 2012 13:25:32 -0600
Canek Peláez Valdés can...@gmail.com wrote:
Or, said configuration files might be corrupted; the OpenRC
initscript -- if written defensively -- will be able to detect that
and (perhaps) fallback to something sane. systemd can't do that,
short of putting all required intelligence into a script which it
executes on boot.
That is a completely valid point, but I don't think that task belongs
into the init system. The init system starts and stops services, and
monitors them; checking for configuration files and creating hostkeys
is part of the installation process. If something got corrupted
between installation time and now, I would prefer my init system not
to start a service; just please tell me that something is wrong.
I tend to agree. All most no daemons and services out there check that
their config files are not corrupt. At most they do syntax
checking, throw errors and leave it up to the caller to deal with it in
some appropriate manner. Most often, the caller is a human with a shell.
Same with sshd and all that checking that happens in the init script.
That stuff correctly belongs in the ebuild config phase, or as an
ad-hoc action done by the sysadmin whenever {,s}he feel like it. The
major point being, if the software itself does not perform a certain
check, then the launching script should also not concern itself with
those checks.
[There are exceptions of course, some stuff is brain-dead, like
tac_plus. Nice software, but if it can't write to it's own log files,
it silently stops working and doesn't tell you. To all intents it looks
like it works fine, but doesn't. Presumably, openssh does not fall in
that category of brain-dead software]
--
Alan McKinnnon
alan.mckin...@gmail.com
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sun, Mar 18, 2012 at 01:25:32PM -0600, Canek Peláez Valdés wrote: On Sun, Mar 18, 2012 at 5:23 AM, Pandu Poluan pa...@poluan.info wrote: On Mar 18, 2012 3:52 PM, Canek Peláez Valdés can...@gmail.com wrote: If the config file doesn't exists, the service will not start, and you can check the reason why with systemctl status sshd.service And of course you can set another mini sevice unit file to create the hostkeys. But I repeat: I think those tasks belong into the package manager, no the init script. Between installation by package manager and actual execution by the init system, things might happen on the required file(s). Gentoo's initscript guards against this possibility *plus* providing helpful error messages in /var/rc.log Or, said configuration files might be corrupted; the OpenRC initscript -- if written defensively -- will be able to detect that and (perhaps) fallback to something sane. systemd can't do that, short of putting all required intelligence into a script which it executes on boot. That is a completely valid point, but I don't think that task belongs into the init system. The init system starts and stops services, and monitors them; That I can agree upon. checking for configuration files and creating hostkeys is part of the installation process. But not this. Installation is a one-time event whose lifetime is over once installation is done. If something got corrupted between installation time and now, I would prefer my init system not to start a service; just please tell me that something is wrong. Obviously, a service itself knows best about its own config files. So *it* should check for the files and if they are invalid/non-existent, it should abort starting and notify the init system. -- Gruß | Greetings | Qapla' I forbid any use of my email addresses with Facebook services. Today’s stress is the good old times of the day after tomorrow. pgpXsMGgDtKkX.pgp Description: PGP signature
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sun, Mar 18, 2012 at 03:15:02PM +0200, Alan McKinnon wrote Here's what I want: When the machine starts, I want services X, Y and Z to run. The software figures out what order they must start in and how the deps work. Clean, neat, easy. systemd is like Captain Picard of STTNG (Start Trek The Next Generation) always saying make it so. *HOW DO YOU MAKE IT SO? That intelligence has to be somewhere. So what alternative do you propose? A bash or ash script is more guaranteed to run than a binary. Shoving all that intelligence into the service itself, means that the service has to start up in order to determine whether it's safe for the service to start up. What's wrong with this picture? And if systemd is so great, here's my supersystemd #!/bin/bash ... ... /etc/init.d/net.lo start /etc/init.d/net.eth0 start /etc/init.d/net.sshd start etc, etc, etc -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sun, 18 Mar 2012 18:23:37 -0400 Walter Dnes waltd...@waltdnes.org wrote: On Sun, Mar 18, 2012 at 03:15:02PM +0200, Alan McKinnon wrote Here's what I want: When the machine starts, I want services X, Y and Z to run. The software figures out what order they must start in and how the deps work. Clean, neat, easy. systemd is like Captain Picard of STTNG (Start Trek The Next Generation) always saying make it so. *HOW DO YOU MAKE IT SO? That intelligence has to be somewhere. So what alternative do you propose? A bash or ash script is more guaranteed to run than a binary. Shoving all that intelligence into the service itself, means that the service has to start up in order to determine whether it's safe for the service to start up. What's wrong with this picture? The intelligence goes in the init system's config file for that service of course. I know I didn't clearly say so, but that's where it goes. The information isn't complicated, you need some BEFORE and AFTER type settings and various other bits and pieces (pid files etc). For services that don't behave nicely when stopped and started in regular ways, supply start/stop/restart/reload functions in the same file that override the defaults. In principle it mirrors exactly how portage works with ebuilds. And if systemd is so great, here's my supersystemd #!/bin/bash ... ... /etc/init.d/net.lo start /etc/init.d/net.eth0 start /etc/init.d/net.sshd start etc, etc, etc No no, you misunderstand me. I'm not saying necessarily that systemd is great. I'm saying that sysvinit sucks big-time and we've needed something better for 15 years. Systemd's design seems to fit that bill nicely (whether it does it in practice remains to be seen) -- Alan McKinnnon alan.mckin...@gmail.com
[gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd.
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziaras rea...@gmail.com wrote: On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd. 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. * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. * 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). My question is: why bother? systemd is already here, it already works, and it's actually supported in Gentoo. But again, remember that I'm biased: I keep an overlay to run Gentoo systems with only systemd; no OpenRC, no baselayout, no SysV. You guys can try it if you want: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ Usual disclaimer: I take no responsibility if using my overlay results in your systems asploding. That said, I'm using it on all my machines without a hitch. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On 18/03/12 03:45, Canek Peláez Valdés wrote: On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziarasrea...@gmail.com wrote: On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd. Take this with a grain (or a kilo) of salt, since I'm obviously biased, but IMHO this are systemd advantages over OpenRC: [...] * 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. Out of the things you listed, this strikes me as the most important. Linux really needs standards. When I install software on Windows, it knows how to add its startup services. On Linux, this is all manual work if your distro isn't supported, especially on Gentoo. If there's no ebuild for it, you spend your whole day trying to make it work.
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Mar 18, 2012 8:48 AM, Canek Peláez Valdés can...@gmail.com wrote: On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziaras rea...@gmail.com wrote: On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd. 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. * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. * 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). My question is: why bother? systemd is already here, it already works, and it's actually supported in Gentoo. But again, remember that I'm biased: I keep an overlay to run Gentoo systems with only systemd; no OpenRC, no baselayout, no SysV. You guys can try it if you want: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ Usual disclaimer: I take no responsibility if using my overlay results in your systems asploding. That said, I'm using it on all my machines without a hitch. Regards. Interesting... However, what if the service is complex? For example, I created a gatewall service which, upon boot, initializes : * Routing tables and the RPDB * ipset * iptables while ensuring that upon shutdown, the settings of the above are (optionally) saved. How do I specify such intelligence? Rgds,
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sat, Mar 17, 2012 at 8:20 PM, Pandu Poluan pa...@poluan.info wrote: On Mar 18, 2012 8:48 AM, Canek Peláez Valdés can...@gmail.com wrote: On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziaras rea...@gmail.com wrote: On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd. 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. * Really parallel service startup: OpenRC has never been reliable on parallel service startup; its documentation says it explicitly. * 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). My question is: why bother? systemd is already here, it already works, and it's actually supported in Gentoo. But again, remember that I'm biased: I keep an overlay to run Gentoo systems with only systemd; no OpenRC, no baselayout, no SysV. You guys can try it if you want: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ Usual disclaimer: I take no responsibility if using my overlay results in your systems asploding. That said, I'm using it on all my machines without a hitch. Regards. Interesting... However, what if the service is complex? For example, I created a gatewall service which, upon boot, initializes : * Routing tables and the RPDB * ipset * iptables while ensuring that upon shutdown, the settings of the above are (optionally) saved. How do I specify such intelligence? Well, first of all you have options for starting a service, but also for stopping it. But besides that, please understand that while systemd does not use shell files *itself*, it doesn't stop you from using them if you so desire. In other words, put the intelligence on a script:
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sat, Mar 17, 2012 at 10:12 PM, Nikos Chantziaras rea...@gmail.com wrote: On 18/03/12 03:45, Canek Peláez Valdés wrote: snip [...] * 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. Out of the things you listed, this strikes me as the most important. Linux really needs standards. When I install software on Windows, it knows how to add its startup services. On Linux, this is all manual work if your distro isn't supported, especially on Gentoo. If there's no ebuild for it, you spend your whole day trying to make it work. My day job's on the windows side of things... and as true as it is that the application developer knows the approach they're going to use today to get their piece of software to start when windows does (as often as not, doing so without the knowledge of the user), there's a *massive* range of ways to do just that, and they *do* vary as you move from one version of windows to the next... and tracking down what's actually starting at boot (and why) without tools explicitly created to give that information is an incredible amount of work on the side of the user and even the usual admin. I'm not sure I'd cite that as a positive benefit on the windows side of things... -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On March 17, 2012 at 8:48 PM Nikos Chantziaras rea...@gmail.com wrote: On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd. I'm the OP, and often I don't know how to express myself. It is my understanding that systemd is going to force an initramfs on you even if you only have / and no other partitions. (Could it be initrd and not initramfs?) I'm all for automounting a device when it's plugged in, if that's what the user chooses. But for me, with my workstation, laptop, wife's PC and daughter's laptop -- we just don't need or care for it. Seems a shame to be using udev and then have to completely change your system when 181 comes out, or freeze it at . Therefore, we don't install anything to automount devices. We have lines such as these in fstab: UUID=6C5F-3742/Libby-Vivitar vfat noauto,users,rw,gid=100,dmask=0002,fmask=0113 0 0 for those devices we own. When we get a new device, we add a new line. We don't use a DE either, just Fluxbox. The bottom line is that I don't like things being forced on me (hint, get the vaseline, they're on the way!) And I don't like upstream forcing such nefarious changes on the distros. And for the Lennart fanboi, his coding is so questionable that Lennartware has become derogatory slang. (Of course, you already know that.) -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Mar 18, 2012 9:44 AM, Joshua Murphy poiso...@gmail.com wrote: On Sat, Mar 17, 2012 at 10:12 PM, Nikos Chantziaras rea...@gmail.com wrote: On 18/03/12 03:45, Canek Peláez Valdés wrote: snip [...] * 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. Out of the things you listed, this strikes me as the most important. Linux really needs standards. When I install software on Windows, it knows how to add its startup services. On Linux, this is all manual work if your distro isn't supported, especially on Gentoo. If there's no ebuild for it, you spend your whole day trying to make it work. My day job's on the windows side of things... and as true as it is that the application developer knows the approach they're going to use today to get their piece of software to start when windows does (as often as not, doing so without the knowledge of the user), there's a *massive* range of ways to do just that, and they *do* vary as you move from one version of windows to the next... and tracking down what's actually starting at boot (and why) without tools explicitly created to give that information is an incredible amount of work on the side of the user and even the usual admin. I'm not sure I'd cite that as a positive benefit on the windows side of things... True, that. Case in point : a couple of months back, I had great trouble trying to start the server service *after* the iSCSI service. Finally have to resort on a script starting using Windows Scheduler (post-boot event) On Linux, I *know* where services are started. The locations might be different from one distro to another, but within one distro, there's (usually) only 2 ways a service get started. Plus, as a server guy, I don't really care if the boot up process is faster; I need deterministic boot process, with as succinct instrumentation as possible. Rgds,
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sat, Mar 17, 2012 at 8:48 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 17, 2012 at 8:48 PM Nikos Chantziaras rea...@gmail.com wrote: On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd. I'm the OP, and often I don't know how to express myself. It is my understanding that systemd is going to force an initramfs on you even if you only have / and no other partitions. (Could it be initrd and not initramfs?) I'm all for automounting a device when it's plugged in, if that's what the user chooses. But for me, with my workstation, laptop, wife's PC and daughter's laptop -- we just don't need or care for it. Seems a shame to be using udev and then have to completely change your system when 181 comes out, or freeze it at . Therefore, we don't install anything to automount devices. We have lines such as these in fstab: UUID=6C5F-3742 /Libby-Vivitar vfat noauto,users,rw,gid=100,dmask=0002,fmask=0113 0 0 for those devices we own. When we get a new device, we add a new line. We don't use a DE either, just Fluxbox. The bottom line is that I don't like things being forced on me (hint, get the vaseline, they're on the way!) And I don't like upstream forcing such nefarious changes on the distros. And for the Lennart fanboi, his coding is so questionable that Lennartware has become derogatory slang. (Of course, you already know that.) No need to get personal man, relax. I'm getting my PhD in Computer Science, and worked several years as professional programmer. In my not-so-limited experience, Lennart's code is clean, fast, and usually does what he says it will do. So, no, I don't already know that. You could argue about the overall design, or what goals his code has, but its quality you are the only one questioning it. So again, please, [citation needed]. You still haven't provided any reference to support your claim that Lennart's code (specifically systemd's code) is poorly done. 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: systemd? [ Was: The End Is Near ... ]
On March 17, 2012 at 9:45 PM Canek Peláez Valdés can...@gmail.com wrote: But again, remember that I'm biased: I keep an overlay to run Gentoo systems with only systemd; no OpenRC, no baselayout, no SysV. You guys can try it if you want: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ Usual disclaimer: I take no responsibility if using my overlay results in your systems asploding. That said, I'm using it on all my machines without a hitch. Regards. -- Canek Peláez Valdés Okay, I'm game. Monday (time and work flow permitting) I plan on building a new PC and installing Gentoo, and replacing the mechanical drive in this Lenovo T420 with a SSD. Far be it from me to be guilty of contempt prior to investigation. Therefore, I'll follow your referenced guide above and do at least one of these installs with systemd. If there is anything out of sync with present stage3 tarballs and portage, it would be great if you could update your docs. The last 2 new installs this week are running Python3.2, and with zero time to actually work on it, I'm submitting even sloppy bug reports to BGO. (Just ran across another app tonight which won't build with python2.) -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On Sat, Mar 17, 2012 at 9:02 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 17, 2012 at 9:45 PM Canek Peláez Valdés can...@gmail.com wrote: But again, remember that I'm biased: I keep an overlay to run Gentoo systems with only systemd; no OpenRC, no baselayout, no SysV. You guys can try it if you want: http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/ Usual disclaimer: I take no responsibility if using my overlay results in your systems asploding. That said, I'm using it on all my machines without a hitch. Regards. -- Canek Peláez Valdés Okay, I'm game. Monday (time and work flow permitting) I plan on building a new PC and installing Gentoo, and replacing the mechanical drive in this Lenovo T420 with a SSD. Far be it from me to be guilty of contempt prior to investigation. Therefore, I'll follow your referenced guide above and do at least one of these installs with systemd. If there is anything out of sync with present stage3 tarballs and portage, it would be great if you could update your docs. The last 2 new installs this week are running Python3.2, and with zero time to actually work on it, I'm submitting even sloppy bug reports to BGO. (Just ran across another app tonight which won't build with python2.) If you want to test systemd, you don't need to use my overlay; and actually, I would not recommend it: it's made thinking for people already using systemd. Just follow the wiki instructions: http://wiki.gentoo.org/wiki/Systemd I don't want you to get the wrong idea because of my possible mistakes: use systemd for Gentoo as the Gentoo devs have planned it. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
On March 17, 2012 at 10:57 PM Canek Peláez Valdés can...@gmail.com wrote: On Sat, Mar 17, 2012 at 8:48 PM, Bruce Hill, Jr. da...@happypenguincomputers.com wrote: On March 17, 2012 at 8:48 PM Nikos Chantziaras rea...@gmail.com wrote: On 17/03/12 13:53, Alan Mackenzie wrote: Hello, Nikos. On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote: Happy Computer Users, systemd is on your horizon. No, we don't. I hope systemd arrives soon. It's the best init system I ever saw. What's so good about it? What will it do for me? I have this horrible sneaking suspicion that it will be more complicated than /sbin/init + OpenRC, just like udev + initramfs is more complicated than udev, and CUPS is more complicated than classical lpr. Why do you find it so good? No idea. I only posted this because the OP didn't say what's bad about systemd :-) I really don't know I should care whether my system runs OpenRC or systemd. I'm the OP, and often I don't know how to express myself. It is my understanding that systemd is going to force an initramfs on you even if you only have / and no other partitions. (Could it be initrd and not initramfs?) I'm all for automounting a device when it's plugged in, if that's what the user chooses. But for me, with my workstation, laptop, wife's PC and daughter's laptop -- we just don't need or care for it. Seems a shame to be using udev and then have to completely change your system when 181 comes out, or freeze it at . Therefore, we don't install anything to automount devices. We have lines such as these in fstab: UUID=6C5F-3742/Libby-Vivitar vfat noauto,users,rw,gid=100,dmask=0002,fmask=0113 0 0 for those devices we own. When we get a new device, we add a new line. We don't use a DE either, just Fluxbox. The bottom line is that I don't like things being forced on me (hint, get the vaseline, they're on the way!) And I don't like upstream forcing such nefarious changes on the distros. And for the Lennart fanboi, his coding is so questionable that Lennartware has become derogatory slang. (Of course, you already know that.) No need to get personal man, relax. I disagree ... there's every reason to get personal. Not getting personal doesn't assign the blame. Men stand up and take responsibility for their actions. I'm getting my PhD in Computer Science snip I got my PhD in life before your parents met. So what? Just saying... So again, please, [citation needed]. You still haven't provided any reference to support your claim that Lennart's code (specifically systemd's code) is poorly done. Mate, have you heard of the world wide web? The internet? Regards. -- Canek Peláez Valdés Seriously, mate ... are you his boyfriend, on his payroll, related, or what? You search LKML for yourself. I've been there since 2003 and have numerous memories. How about: http://www.change.org/petitions/lennart-poettering-stop-writing-useless-programs-systemd-journal Sorry, mate ... many of us here are allergic to FUD :-)} -- Happy Penguin Computers`) 126 Fenco Drive( \ Tupelo, MS 38801^^ 662-269-2706; 662-491-8613 support at happypenguincomputers dot com http://www.happypenguincomputers.com
