Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 18/02/2014 23:32, Canek Peláez Valdés wrote: And you always can run other legacy logger alongside the journal, and have both things; binary logs for fast retrieval, and text logs if you so desire. Please do not use that phrase legacy in this context. Classic syslogging is not legacy. It is current. The systemd method is not the new thing that replaces and deprecates the old thing, it is merely a new (and unproven) kid on the block. Legacy in the context of logging can only really mean the old syslogger protocol as implemented by syslogd. It has no standard behind it and is correctly described as whatever syslogd does, whereas there is a new syslogging protocol, with an RFC. This is most certainly not a legacy standard. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 18/02/2014 13:54, Mark David Dumlao wrote: Shouldn't sysadmins use the init-scripts for that? If done correctly, permissions should not be an issue. Restarting services without keeping file ownership into account will always cause issues. Regardless of the init-system used. That's just the thing though. As a sysadmin, how do you debug a service that isn't starting to begin with? Let's say your new to the service. You're not even sure if you got the config right the first time around. Or maybe you're adjusting a setting somewhere, and you're confused why it isn't taking effect. All the /upstream documentation/, all the /man pages/, all the /usr/share/doc stuff will tell you to start it _raw_. The init script obscures the starting options, environment variables, and sometimes even the running user from you. What are you gonna do, play a human shell script parser? Nobody's perfect, do it enough times and you're going to casually gloss over the line where --safe-mode is appended to the string depending on the phase of the moon... I do all of that, I've been around long enough to have learned. Like yourself. ps and tailing a daemon's log file is my standard approach to really verify that a daemon is running. The other side of the coin is I usually start with the distro's init scripts and assume for argument sake they work. When the facts prove that wrong, I dig deeper. The list of daemons I use that are not well behaved wrt init scripts are rather short in reality If you're lucky, you've never had to start an unfamiliar service, or debug someone else's unfamiliar config under time pressure... Nope, not so lucky. Not even close. We're getting OT, but by far the worst behaved daemons out there are non-OSS paid-for things for a corproate market. Like Ossec. Oracle databases. Sybase. Anything and everythign that purports to do backups. I shan't mention Oracle's various offerings for business use for fear my brain shall explode. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 18/02/2014 14:16, J. Roeleveld wrote: On Tue, February 18, 2014 12:17, Alan McKinnon wrote: On 18/02/2014 11:52, J. Roeleveld wrote: On Tue, February 18, 2014 10:47, Alan McKinnon wrote: What I do run into is daemons that drop privs on start up, like tac_plus. Unwary new sysadmins always try start/stop it as root, causing an unholy mess. Root the owns the log and pid files, when tac_plus drops privs it can't record it's state so continues to service requests but fails to log any of them. For an auth daemon, that's a serious issue. Shouldn't sysadmins use the init-scripts for that? If done correctly, permissions should not be an issue. It's a little more complex than just that. It's an auth service and user are frequently added, removed and modified. The daemon does syntax checking on it's config file at startup or after being HUP'ed but that only finds static errors. It catches things like adding people to a grop instead of to a group, but misses dynamic mistakes like adding users to groups that don't exist. The auth-service gets the current state from a static file that is only read upon service-start? Yes. It's a good design for reasonably static userbases. The user details, priviledge definitions, passwords hashes and such are stored in a single flat file readable only by root and protected by file permissions. Overall protection is provided by restricted shell access to the host. We're not talking about ATT's radius servers for dsl users here who sign up on a web form - for that you would use a database backend - this is for the company's network support personnel who log into the backbone and configure the network itself. There's no rush to add new (and unproven...) users so this scheme suits me just fine. Yes, it has quirks but these no longer bother me myself, we get caught out by new sysadmins who have not felt that pain yet It's exactly analogous to compile-time vs runtime errors, compilers can't catch the latter. Despite this all being run out of cron with wrapper scripts to check validity, automated additions and safety checks between all three daemons, plus being fully documented on the internal wiki and in bold blinking red caps in the login motd, people still find ways to do stuff things in an attempt to fix it. (OT: Does the bold blinking red caps work on all terminals? :) ) Um, OK, you got me there. I was exaggerating! The daemon also tries to log these errors, by writing to a log file it has no write permissions on. setuid on the group with group-write in the umask not an option? Hmmm, that's worth investigating. I hadn't really considered that as I have an aversion to trying to use umask as a control for anything. There is nothing I can do about the quality of sysadmins, I have no input into the HR process and damagement think cheaper is always better, including skills. What I can do, is find ways to make the software more resistant to errors than it already is. And only grant access permissions to these rookies once they have proven they understand rule #1: If In Doubt, Call Someone Who Knows! Hah! I fought that good fight for years and fought it well. They don't call me the sysadmin from hell around here without good reason. And I did manage to get a cowboy network under control and instill respect for how much breakage Cisco's products can cause. It's getting harder to grant access based purely on expertise, especially when someone crunched the numbers. It turns out that the cost of fixing mistakes is far less than the cost of leaving new untrained people unutilized and have support tickets pile up... But yes, I fully understand the methods of HR and Damagement. It is a financial mistake and risk not to include technical expertise checks in the recruitement fase for technical positions. Interesting story: I once had a good shouting match with a support manager about the quality of his recruits. I demanded to know why he hired so many clueless idiots (my exact words). This manager knows me well so he just smiled and said Alan, you didn't get to see the applicants we rejected. These are the best in the market who applied. *That* was a wake-up call of note :-) How much does it cost the company each time this goes wrong and someone like you has to come online to fix the issue? That is what Damagement needs to understand. Surprisingly, it's not too expensive. There's always one of us on duty or standby and outages don't continue unnoticed for long. Longest that I recall is 3 minutes, then the phone starts ringing non-stop. remember, this system is internal, it does not service customers. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 4:35 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On 18/02/2014 23:32, Canek Peláez Valdés wrote: And you always can run other legacy logger alongside the journal, and have both things; binary logs for fast retrieval, and text logs if you so desire. Please do not use that phrase legacy in this context. I apologize. I did not intended to use legacy as a pejorative term. I use rsyslog myself in some servers. 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] Debian just voted in systemd for default init system in jessie
On 02/18/2014 12:14 PM, Canek Peláez Valdés wrote: On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko birc...@gmail.com wrote: On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote: Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) That's the best response I've read in, like, many years. That's perfect; I'm 100% behind it. I even volunteer to help (with testing) to anyone going for this. You guys create a systemd-sucks-we-dont-want-it profile, and I promise to give you guys a hand. Make a profile that frees users from using systemd, and I think even several Gentoo developers will get behind that. Now we are talking; this has been my whole point the whole time. Everybody that don't want to use systemd; help this idea, and if there are enough of you, you'll pulled through. Regards. For such a profile to be legitimate, systemd would have to be chosen as the default. Gentoo is one of the last bastions of choice available to GNU/Linux users and it would create a complete shitstorm if systemd were pushed on Gentoo's users. You're just trying to push systemd on one of the few distros that doesn't use it by default. Do you hang out with John Paul Adrian Glaubitz? He's a Debian developer who has a long-running history of pushing systemd as well. There is nothing wrong with systemd as a choice, but to push it as the default is ridiculous. systemd can have its own profile while the rest of the world goes on without it. Everybody wins. For all this talk about technical details, nobody seems to notice the marketing that's going on and frankly it disgusts me.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Wed, February 19, 2014 00:06, Alan McKinnon wrote: On 18/02/2014 14:16, J. Roeleveld wrote: On Tue, February 18, 2014 12:17, Alan McKinnon wrote: It's a little more complex than just that. It's an auth service and user are frequently added, removed and modified. The daemon does syntax checking on it's config file at startup or after being HUP'ed but that only finds static errors. It catches things like adding people to a grop instead of to a group, but misses dynamic mistakes like adding users to groups that don't exist. The auth-service gets the current state from a static file that is only read upon service-start? Yes. It's a good design for reasonably static userbases. The user details, priviledge definitions, passwords hashes and such are stored in a single flat file readable only by root and protected by file permissions. Overall protection is provided by restricted shell access to the host. True, then again, I use ldap for the user accounts at home. Allows my wife to change her own password and I can quickly add an account in case someone needs access. We're not talking about ATT's radius servers for dsl users here who sign up on a web form - for that you would use a database backend - this is for the company's network support personnel who log into the backbone and configure the network itself. There's no rush to add new (and unproven...) users so this scheme suits me just fine. Yes, it has quirks but these no longer bother me myself, we get caught out by new sysadmins who have not felt that pain yet Show them a blood-stained (ok, some dark red paint) stick when they start. Then tell them it's used when they kill that service? ;) Despite this all being run out of cron with wrapper scripts to check validity, automated additions and safety checks between all three daemons, plus being fully documented on the internal wiki and in bold blinking red caps in the login motd, people still find ways to do stuff things in an attempt to fix it. (OT: Does the bold blinking red caps work on all terminals? :) ) Um, OK, you got me there. I was exaggerating! Too bad, I could use that on one of my machines :) The daemon also tries to log these errors, by writing to a log file it has no write permissions on. setuid on the group with group-write in the umask not an option? Hmmm, that's worth investigating. I hadn't really considered that as I have an aversion to trying to use umask as a control for anything. Same here, but that could work. Then again, I believe setuid on the folder does the same on some OSs. (Not Linux though) There is nothing I can do about the quality of sysadmins, I have no input into the HR process and damagement think cheaper is always better, including skills. What I can do, is find ways to make the software more resistant to errors than it already is. And only grant access permissions to these rookies once they have proven they understand rule #1: If In Doubt, Call Someone Who Knows! Hah! I fought that good fight for years and fought it well. They don't call me the sysadmin from hell around here without good reason. And I did manage to get a cowboy network under control and instill respect for how much breakage Cisco's products can cause. It's getting harder to grant access based purely on expertise, especially when someone crunched the numbers. It turns out that the cost of fixing mistakes is far less than the cost of leaving new untrained people unutilized and have support tickets pile up... True, unfortunately... Then again, a core of really good people can be the better option. But then you end up becoming overly dependent on that group. But yes, I fully understand the methods of HR and Damagement. It is a financial mistake and risk not to include technical expertise checks in the recruitement fase for technical positions. Interesting story: I once had a good shouting match with a support manager about the quality of his recruits. I demanded to know why he hired so many clueless idiots (my exact words). This manager knows me well so he just smiled and said Alan, you didn't get to see the applicants we rejected. These are the best in the market who applied. *That* was a wake-up call of note :-) Either done during the boom of IT, or wrong recruitment tactics. How much does it cost the company each time this goes wrong and someone like you has to come online to fix the issue? That is what Damagement needs to understand. Surprisingly, it's not too expensive. There's always one of us on duty or standby and outages don't continue unnoticed for long. Longest that I recall is 3 minutes, then the phone starts ringing non-stop. remember, this system is internal, it does not service customers. 3 minutes downtime is acceptable, even for customers. They generally first assume they are making a mistake ;) -- Joost
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Wed, Feb 19, 2014 at 1:04 AM, Daniel Campbell li...@sporkbox.us wrote: On 02/18/2014 12:14 PM, Canek Peláez Valdés wrote: On Tue, Feb 18, 2014 at 12:07 PM, Andrew Savchenko birc...@gmail.com wrote: On Tue, 18 Feb 2014 11:22:23 -0600 Canek Peláez Valdés wrote: Yet again, I respect ones right to use whatever one wants, but I ask to respect mine as well. That's why I propose a separate systemd profile for those willing to use it. Then write. Just be aware that to write a systemd profile, you need to use systemd. Or to create a non-systemd profile :) That's the best response I've read in, like, many years. That's perfect; I'm 100% behind it. I even volunteer to help (with testing) to anyone going for this. You guys create a systemd-sucks-we-dont-want-it profile, and I promise to give you guys a hand. Make a profile that frees users from using systemd, and I think even several Gentoo developers will get behind that. Now we are talking; this has been my whole point the whole time. Everybody that don't want to use systemd; help this idea, and if there are enough of you, you'll pulled through. Regards. For such a profile to be legitimate, systemd would have to be chosen as the default. Gentoo is one of the last bastions of choice available to GNU/Linux users and it would create a complete shitstorm if systemd were pushed on Gentoo's users. You're just trying to push systemd on one of the few distros that doesn't use it by default. Do you hang out with John Paul Adrian Glaubitz? He's a Debian developer who has a long-running history of pushing systemd as well. There is nothing wrong with systemd as a choice, but to push it as the default is ridiculous. systemd can have its own profile while the rest of the world goes on without it. Everybody wins. For the record, and being completely honest (I've always been), at some point, yeah, I would like for the devs to discuss the idea of systemd as default init system. It does not depends on me though; the devs (and the council they elect) will take such decision, and the discussion (if it happens) will be in a long, long time. But my (previous) push for a systemd-sucks profile was because I sincerely believe that the burden of work should be on the ones proposing *any* profile, and to support a systemd profile you *need* to use systemd, and then it makes no sense that the people that *don't want* systemd need to do the work for a systemd profile. However, after Andreas K. Huettel pointed out (in [1]) how simple and minimal a systemd profile actually is[2], I changed my mind. I now wholeheartedly support a systemd profile, since is so small, that the burden of work is basically negligible, and apparently the same GNOME/systemd Gentoo developers are already doing it. So, I think, everybody agrees now. Lets have a systemd profile. (I mean, the work to have it apparently it's already done, so it does not matter what I, or anyone here, argues about it). For all this talk about technical details, nobody seems to notice the marketing that's going on and frankly it disgusts me. There is no marketing; no one is selling nothing. We are just discussing different technologies and their merits (or demerits), according to what each one of us knows/believe. It's interesting, it's fun, we learn things (I learned about the systemd profile in existence) and it changes absolutely nothing about Linux, Gentoo, or the status of systemd anywhere. To change Linux, Gentoo, or the status of systemd somewhere, people need to contribute code, testing or documentation, not post arguments in mailing lists. But again, it's fun (except for a couple of trolls), so no harm is done. Regards. [1] http://article.gmane.org/gmane.linux.gentoo.user/272668 [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/targets/systemd/ -- 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] Debian just voted in systemd for default init system in jessie
Thanks to all who chimed in... On 2014-02-16 3:27 PM, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Feb 16, 2014 at 1:26 PM, Mick michaelkintz...@gmail.com wrote: [snip] You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. I had read that blog entry before. Is full of errors, like believing that everything that systemd does is inside PID 1. Maybe it is 'full of errors', but is the primary point true? There is actually little code inside PID 1; The quoted text said nothing about this, so please stay on point. As to the point raised: Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. So my main concern is - will it still be possible - *and* easy - in a year? Three years? Five? If the answer to *any* of those is no, then I think the best solution - for gentoo at least - is to make whether or not systemd is to be used more like a *profile* choice - a decision that you can make at install time, similar to choosing between hardened or not (not easy/simple to switch to/from after a system is up and running). In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, having it be a choice made by selecting a corresponding *profile* is the *ideal* solution - at least for gentoo. At least this way everything could be documented, and switching between a systemd and non-systemd profile can be supported for as long as possible, understanding that at some point in time it may have to become an install time choice - kind of like choosing between hardened or not is mostly an install time choice now.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 02/17/2014 06:17 AM, Tanstaafl wrote: Thanks to all who chimed in... On 2014-02-16 3:27 PM, Canek Peláez Valdés can...@gmail.com wrote: On Sun, Feb 16, 2014 at 1:26 PM, Mick michaelkintz...@gmail.com wrote: [snip] You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. I had read that blog entry before. Is full of errors, like believing that everything that systemd does is inside PID 1. Maybe it is 'full of errors', but is the primary point true? There is actually little code inside PID 1; The quoted text said nothing about this, so please stay on point. As to the point raised: Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. So my main concern is - will it still be possible - *and* easy - in a year? Three years? Five? If the answer to *any* of those is no, then I think the best solution - for gentoo at least - is to make whether or not systemd is to be used more like a *profile* choice - a decision that you can make at install time, similar to choosing between hardened or not (not easy/simple to switch to/from after a system is up and running). In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, having it be a choice made by selecting a corresponding *profile* is the *ideal* solution - at least for gentoo. At least this way everything could be documented, and switching between a systemd and non-systemd profile can be supported for as long as possible, understanding that at some point in time it may have to become an install time choice - kind of like choosing between hardened or not is mostly an install time choice now. That's actually a really smart idea. It would allow for the integration that systemd-fans desire and still respect the choice of people that don't want systemd on their systems. Combined with USE flags and the PORTDIR_MASK variable (iirc), it should create a best of both worlds situation for Gentoo and a decision wouldn't need to be made. Despite my distaste for systemd, I think this is a great middle ground that everyone could, with some considerations or compromises, agree to.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 17/02/2014 14:17, Tanstaafl wrote: In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, having it be a choice made by selecting a corresponding *profile* is the *ideal* solution - at least for gentoo. At least this way everything could be documented, and switching between a systemd and non-systemd profile can be supported for as long as possible, understanding that at some point in time it may have to become an install time choice - kind of like choosing between hardened or not is mostly an install time choice now. To me, this is as close to ideal as it can get. As I said in my opening post, I do not suffer from the problem RedHat is solving - my machines seldom reboot quicker than every 10 days (including laptops) and OpenRC gets me to a useable prompt faster than the BIOS takes to do it's thing :-) A profile-like solution would suit me perfectly, something I can use or not as I see fit and the choice made at install time. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon alan.mckin...@gmail.com wrote: ... Whatever problems Red Hat are trying to solve in the Red Hat space are problems that do not affect me, so I do not need Red Hat's solution. As for Gnome, I have yet to see a valid reason why Gnome *must* use systemd; that is simply not true at all. I thought this all boiled down to trying to login to GDM using accessibility functions and a bluetooth hearing aid (or bluetooth keyboard, for that matter). Stroller.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl tansta...@libertytrek.org wrote: [snip] Maybe it is 'full of errors', but is the primary point true? False implies whatever you want it to imply. You can't prove anything if your assumptions are incorrect. There is actually little code inside PID 1; The quoted text said nothing about this, so please stay on point. I was answering to someone else. As to the point raised: Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. I am not. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? I've never said it was easy. I said it could be done by someone willing and able. I repeated that like five times I think. I said it was done before; I never said it was easy. But it can be done, and that's a indisputable fact. It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Some of those packages *could* be made to switch functionality at run time instead of compile time, but SOMEONE has to write that support, and it's probably that the upstream for the package will not accept those changes, since for binary distributions it makes no sense to have the complexity on the code of switching behavior at runtime when doing at compile time is easier and the distribution generates one binary per architecture for all its users. So my main concern is - will it still be possible - *and* easy - in a year? Three years? Five? If the answer to *any* of those is no, then I think the best solution - for gentoo at least - is to make whether or not systemd is to be used more like a *profile* choice - a decision that you can make at install time, similar to choosing between hardened or not (not easy/simple to switch to/from after a system is up and running). That's how it works right now, because Gentoo developers *did* the work. And the whole point of my willing and able mantra is to see if someone here steps up into the plate. It's *really* easy to say oh, systemd should be provided by a profile so the user is free to CHOICE if she wants to use it or not, but *someone* has to write the necessary support so that the profile actually exists. You want to be sure your choice is not taken away from you? Join Gentoo and help to make that choice possible. Don't expect that someone will do it for you. There is a lengthy discussion in gentoo-dev about the problem with understaffed arch teams. It's worth a reading, but the general consensus is that the minor archs cannot be kept in stable if there are not enough developers for said arch to do the testing. It sucks? Of course it sucks; but there is no magical fairy that automatically will keep working all the ebuilds for all the archs in Gentoo. SOMEONE has to do the testing, someone has to triage bugs, someone has to *fix* them. If there is no one, then the arch cannot be kept in stable. And that's a hard cold fact. If *all* the Gentoo developers switched to systemd (highly unlikely), then how could they support a separated profile for systemd? They won't, and your choice will then be taken away. If the Gentoo developers decide that having systemd in a separated profile is too much work (likely, even now), then what? More whining from users because they took away their choice? They could whine all they want, but if nobody steps up to the plate to do the actual work, nobody (necessarily) will do it for them. In fact, it seems to me that, since (from what I've read) the
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? Bugs are different. Bugs in the critical system components are critical to the whole system. If Libreoffice or browser segfaults, some data may be lost and inconvenience created, but the system will continue to run. If PID 1 segfaults — everything is lost, you have a kernel panic. That's why critical components should be as simple and clean as possible. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Looks broken. Broken by design. The worst form of broken. By your opinion, not others. That is not just an opinion. There is a science and experience behind system's design. And all that science was ignored during systemd architecture process if there was any at all. Best regards, Andrew Savchenko pgpPqKWNVnvHI.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote: It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. And here we have a small problem: for modules to be replaceable the core system should be designed to support replaceable modules, but systemd is not. The whole deep integration approach and lack of inter-module boundaries doesn't allow one to write replaceable blocks without crazy hacking. Just imagine that one have PCI-E bus and this bug is being replaced with some other PC-systemd bus, where one have to interface each component differently. And if one removes e.g. audio card some other seemingly independent component e.g. network controller becomes broken. That is the nature of systemd and that is many people dislike this technology. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Some of those packages *could* be made to switch functionality at run time instead of compile time, but SOMEONE has to write that support, and it's probably that the upstream for the package will not accept those changes, since for binary distributions it makes no sense to have the complexity on the code of switching behavior at runtime when doing at compile time is easier and the distribution generates one binary per architecture for all its users. The most sane and fair solution was already proposed: create a systemd profile for those who need it. I personally highly dislike systemd technology, but I respect the right of other to shoot them in the leg (or head) as much as they want to. This is Gentoo: a universal constructor providing people means to build any system in any shape they need. Unfortunately chances are that in future some software may become unusable or unsupported outside of systemd profile. But patches may be created and other profiles will continue to live the same way hardened exists now and will continue to exist later. BTW it was shown at the recent LVEE Winter 2014 conference that GDM can be easily freed from systemd and OpenBSD guys have an interesting idea for faking systemd presence for applications requesting one mandatory. Though IMO any end-user application strictly dependable on any init system is broken by design: for a daemon there should be no difference by which tool it was started. In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, You are wrong; systemd was created because Upstart had the silly CLA from Canonical[1], and because its authors wanted a novel init system for Linux (and Linux only) that used all the cool technologies the kernel provides, and that it could solve problems like: how to easily and consistently start daemons with well defined semantics for its dependencies; how to easily and consistently apply resource quotas to them; how to deal with modern computers where hardware comes and goes (including CPUs) all the time, etc. [2]. Excuse me please, but what you wrote above is very naive. All that reasons are just an excuse. The real reason is money: systemd is a Red Hat project (despite being formally open for everyone) and is their tool^Wweapon to fight with Canonical for a sales market. It the last years RH was pushed near even in a server market and now they are fighting back. They were lucky enough to acquire Poettiring guy and create from a simple and sound sysvinit (which is an important but not dictating peace of software) a key component where they can dictate their own line, where they can lead all Linux community in a way they need. That the real reason I despise systemd: in replaces the freedom of choice by a dictatorship of a small bunch of managers of a single corporation (yes, managers, not developers). And all this is under the veil of GPL and technical merits. This is the poison in the well of FOSS. Best regards, Andrew Savchenko pgpNXWRgUgRgH.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Sorry for entering others' dialog... On 17.02.2014 21:13, Canek Peláez Valdés wrote: On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl tansta...@libertytrek.org wrote: [snip] Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. I am not. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? I've never said it was easy. I said it could be done by someone willing and able. I repeated that like five times I think. I said it was done before; I never said it was easy. The whole point of creating new software is making things easier. Easier to use, easier to maintain, easier to remove. But it can be done, and that's a indisputable fact. A total ground-up rewrite of the whole Linux is also quite possible. It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* integration, *standards* integration not *software* integration. You do want tight integration where it just can't work otherwise, but the design of Unix provides (well, again repeating this), and almost any robust design should provide, the ignorance of one abstraction level about another. Why HAL? Why udev? Why drivers as modules? Why not just go and integrate all stuff into the kernel, well (again!) like MS do, and don't please say I compare wrong things just because MS is not OSS. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. We really don't expect that systemd's authors do anything for us. Anything they do is not for us, thanks. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. For now it's not, but take a look into the future when not a single product will be published without systemd's support, just because it's everywhere -- and since it's everywhere, then why bother support anything other? Time, money... So it's a matter of time -- you'll personally be happy with this scenario -- at first -- but think further... They'll be able to stuff everything into it, making effectively a thing in itself which will dictate you where to go and what to do, just because you're not technically competent enough to deal with it -- hence more support calls and more $ etc etc. I don't believe in Red Hat's being a corporation of Good, nor any other corporation being such, and please remember the notorious examples of almost privatizing OSS by other 'corporations of Good'. (Android, MySQL, almost OpenOffice...) Well, there's some probability that by the time systemd occupies all linux distros, some clever RH guy (or a green soxx guy) will emerge and emerge systemd v2 which will be different ... But it's not something one should count on. [...] If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE it would happen. But don't complain if no one does, and it doesn't. That's your point -- and mine. We aren't complaining -- we want to prevent this. The forward-looking people must unite, it may sound ridiculous, against systemd -- not because of its design, technical details etc, but because otherwise in short time you'll end up comparing systemd to itself. You know what it is: everything's free but nothing to choose from. We had it before, it's called communism. Maybe it is not that bad but we don't want it anymore. Regards. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-17 12:52 PM, Andrew Savchenko birc...@gmail.com wrote: And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Forcefully? Are you saying that *anyone* can *force* Linus to put something into the kernel? I'd also really, *really* like to hear a *recent* opinion from Linus on systemd...
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 17/02/2014 17:29, Stroller wrote: On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon alan.mckin...@gmail.com wrote: ... Whatever problems Red Hat are trying to solve in the Red Hat space are problems that do not affect me, so I do not need Red Hat's solution. As for Gnome, I have yet to see a valid reason why Gnome *must* use systemd; that is simply not true at all. I thought this all boiled down to trying to login to GDM using accessibility functions and a bluetooth hearing aid (or bluetooth keyboard, for that matter). That was the classic rationale for no separate /usr without an initrd in udev - the claimed need to have any arbitrary runnable code available to be run before the entire system is up and running. Red Hat's reasons for pushing systemd are more fuzzy and nothing I've read so far tells me we have the full picture. Two things seem highly plausible: 1. An init system that can use modern features of the Linux kernel (most often Linux-only at this point) like cgroups 2. Extremely fast boot times to spin up virtual machines in a fraction of the time it currently takes. #1 may or may not be desirable, I honestly don't know. What I have seen is a lot of theory and not much reproducable fact. #2 is highly desirable if you run massive VM farms; folks like google, rh and amazon would be very interested. Doesn't really sound like a valid reason to consume and replace the entire existing ecosystem though. How many googles, red hats and amazons are out there versus how many regular joes like thee and me? Why didn't red hat just write their magic sauce to be non-intrusive? Profit and politics I suppose, I really don't see a valid overarching technical reason why it *must* be so. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 14:52:33 -0500 Tanstaafl wrote: On 2014-02-17 12:52 PM, Andrew Savchenko birc...@gmail.com wrote: And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Forcefully? Are you saying that *anyone* can *force* Linus to put something into the kernel? OK, my choice of words was not appropriate. I mean that not every kernel dev is happy that kdbus is in the kernel now. I'd also really, *really* like to hear a *recent* opinion from Linus on systemd... Judging from his previous opinions this one is unlikely to be systemd- friendly. Best regards, Andrew Savchenko pgpoH_OQWnQcJ.pgp Description: PGP signature
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 17, 2014 at 11:52 AM, Andrew Savchenko birc...@gmail.com wrote: On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? Bugs are different. Bugs are bugs, period. And they get reported and fixed. Bugs in the critical system components are critical to the whole system. Yeah, that's why we have unit testing and QA teams and stable and unstable releases, etc. If Libreoffice or browser segfaults, some data may be lost and inconvenience created, but the system will continue to run. If PID 1 segfaults — everything is lost, you have a kernel panic. And the world will end? The same happens if the kernel has an error. That's why critical components should be as simple and clean as possible. Like the kernel? You call that simple? I'm sorry, but you are (IMO) wrong: critical components should be thoroughly tested and debugged, and have integrated unit testing, and a large enough group of volunteers to test new releases before they go into the general public. SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. Also, again, systemd have a lot of little binaries, many of them optional. The LOC of PID 1 is actually closer to SysV (although still bigger). Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. FACT: almost no bug report in systemd involves a segfault in PID 1. All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. kdbus uses a different wire protocol than dbus; but for clients that doesn't matter; libsystemd-dbus will offer a compatibility layer (talk about standard and replaceable), so if your application uses dbus today, it will work with kdbus. Of course, new applications will take advantage of the new features of kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Good for you. Guess what will be done in mine? Looks broken. Broken by design. The worst form of broken. By your opinion, not others. That is not just an opinion. There is a science and experience behind system's design. Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand, or Keith Packard of X.org fame? None of them works for Red Hat; both of them know more about Unix and Linux than you and me together, and both of them promote systemd. I mean, I myself know a thing or two about computing and Linux, and I promote systemd (and nobody pays me, BTW), but obviously you don't need to believe in my credentials. And, no offense, but I will always give more weight to the words of Greg Kroah-Hartman or Keith Packard (to name only two), instead of a random user in gentoo-user. There are knowledgeable people who are against systemd. But usually they don't give *technical* sound reasons. And all that science was ignored during systemd architecture process if there was any at all. You should read systemd-devel and Lennart's blog posts before saying something like that. I did. 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] Debian just voted in systemd for default init system in jessie
On Mon, Feb 17, 2014 at 12:24 PM, Andrew Savchenko birc...@gmail.com wrote: On Mon, 17 Feb 2014 11:13:39 -0600 Canek Peláez Valdés wrote: It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. And here we have a small problem: for modules to be replaceable the core system should be designed to support replaceable modules, but systemd is not. You misunderstood me: I didn't mean to say that someone should write a module to replace one of systemd's modules. I mean that distributions and projects are using systemd's features, and that if you want those features to be easily and simply replaceable, then someone needs to write them like that. Systemd developers decided the tightly integrated route; if you don't like that, and that the distributions are using systemd's features, write something similar being easily and simply replaceable so the distros don't need to use systemd. The whole deep integration approach and lack of inter-module boundaries doesn't allow one to write replaceable blocks without crazy hacking. Well, then go and show them how it's done. And please don't say that it's already done, because if that were the case, no distro would have adopted systemd. They adopted it because of the features it offers. Just imagine that one have PCI-E bus and this bug is being replaced with some other PC-systemd bus, where one have to interface each component differently. And if one removes e.g. audio card some other seemingly independent component e.g. network controller becomes broken. That is the nature of systemd and that is many people dislike this technology. That is a broken analogy; if logind has a bug, that doesn't affect timedated, nor udev. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. It depends; right now you can't switch back and forth between OpenRC and systemd without reemerging some stuff. Some of those packages *could* be made to switch functionality at run time instead of compile time, but SOMEONE has to write that support, and it's probably that the upstream for the package will not accept those changes, since for binary distributions it makes no sense to have the complexity on the code of switching behavior at runtime when doing at compile time is easier and the distribution generates one binary per architecture for all its users. The most sane and fair solution was already proposed: create a systemd profile for those who need it. I personally highly dislike systemd technology, but I respect the right of other to shoot them in the leg (or head) as much as they want to. This is Gentoo: a universal constructor providing people means to build any system in any shape they need. If someone willing and able provides any choice, that choice will be available. Unfortunately chances are that in future some software may become unusable or unsupported outside of systemd profile. But patches may be created and other profiles will continue to live the same way hardened exists now and will continue to exist later. Yeah, and that's my whole point: if you want that the world outside of systemd keeps working, you need to step in. Complaining about systemd will get no one nowhere. BTW it was shown at the recent LVEE Winter 2014 conference that GDM can be easily freed from systemd and OpenBSD guys have an interesting idea for faking systemd presence for applications requesting one mandatory. Though IMO any end-user application strictly dependable on any init system is broken by design: for a daemon there should be no difference by which tool it was started. GNOME depends on logind, not systemd. And no one has been willing and able to produce a compatible replacement: logind works with a dbus API, so it's (in theory) *easy* to duplicate its functionality. Ubuntu has been working in a replacement, but (AFAIU) is not finished. In fact, it seems to me that, since (from what I've read) the primary reason that systemd was written in the first place was to provide extremely fast boots *in virtualized environments*, You are wrong; systemd was created because Upstart had the silly CLA from Canonical[1], and because its authors wanted a novel init system for Linux (and Linux only) that used all the cool
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 17, 2014 at 12:28 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: Sorry for entering others' dialog... On 17.02.2014 21:13, Canek Peláez Valdés wrote: On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl tansta...@libertytrek.org wrote: [snip] Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). I think you are being a little disingenuous here. I am not. The obvious unspoken meaning behind the 'can you surgically remove' was: Can you do it *easily*? I'm sure you would not suggest that getting rid of the above were 'easy'? I've never said it was easy. I said it could be done by someone willing and able. I repeated that like five times I think. I said it was done before; I never said it was easy. The whole point of creating new software is making things easier. Easier to use, easier to maintain, easier to remove. Well, systemd is easier to use after a little time learning how it works. And it seems to be easier to maintain that thousands of lines of spaghetti shell code. And, I'm sorry, did you just said easier to remove? Seriously? You think the kernel is easier to remove? Or glibc? But it can be done, and that's a indisputable fact. A total ground-up rewrite of the whole Linux is also quite possible. Of course it is; that's the beauty of free (libre) software. It simply doesn't matter if systemd boils down to one monolithic binary, or 600, if they are tied together in such a way that they can not *individually* be replaced *easily and simply* (ie, without having to rewrite the whole of systemd). You are setting a group of conditions that preemptively wants to stop adoption of anything that is tightly integrated. That is a losing strategy (different projects actually *want* tight integration), and besides the burden of work should not fall on the people wanting to use a tightly integrated stack. How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* integration, *standards* integration not *software* integration. You do want tight integration where it just can't work otherwise, but the design of Unix provides (well, again repeating this), and almost any robust design should provide, the ignorance of one abstraction level about another. Why HAL? Why udev? Why drivers as modules? Why not just go and integrate all stuff into the kernel, well (again!) like MS do, and don't please say I compare wrong things just because MS is not OSS. You make a wrong comparison, because MS is not free (libre) software. With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we have been able to try new technologies (and see that some of them fail, like HAL [yuck!]), because we have the source. As you said, you can replace the whole of Linux if you so desire (and have the technical ability). You will never be able to do that with any MS software, and so the comparison makes no sense. You want individual modules that are easily and simply replaced? Then WROTE THEM. Don't expect the systemd authors (or any other) to do it for you. We really don't expect that systemd's authors do anything for us. Anything they do is not for us, thanks. Sorry, but they do. Read the mailing list. Feature requests, bugs, they do it for their users. Every time a new distro chooses systemd as init, the developers try to help the maintainers to integrate systemd to it. That said, it seems to me that, for now at least, it isn't that big a deal to switch back and forth between systemd and, for example, OpenRC. For now it's not, but take a look into the future when not a single product will be published without systemd's support, just because it's everywhere -- and since it's everywhere, then why bother support anything other? Time, money... If enough people, willing and able, want to do it, they will. Look at ReactOS. Or Syllable. Or Hurd. Or Debian/kFreeBSD. The thing (and that's also my point), apparently *most* of the people willing and able to create cool software have decided that systemd is the way to go. And, even if you want to attribute that to a simple monetary issue, most of them do it *happily* because many things are just easier to do with systemd. So it's a matter of time -- you'll personally be happy with this scenario -- at first -- but think further... I do. All the time, since 1996 when I started using Linux. They'll be able to stuff everything into it, making effectively a thing in itself which will dictate you where
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, 17 Feb 2014 18:35:34 -0600 Canek Peláez Valdés can...@gmail.com wrote: On Mon, Feb 17, 2014 at 11:52 AM, Andrew Savchenko birc...@gmail.com wrote: On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? Bugs are different. Bugs are bugs, period. And they get reported and fixed. Bugs in the critical system components are critical to the whole system. Yeah, that's why we have unit testing and QA teams and stable and unstable releases, etc. If Libreoffice or browser segfaults, some data may be lost and inconvenience created, but the system will continue to run. If PID 1 segfaults — everything is lost, you have a kernel panic. And the world will end? The same happens if the kernel has an error. That's why critical components should be as simple and clean as possible. Like the kernel? You call that simple? I'm sorry, but you are (IMO) wrong: critical components should be thoroughly tested and debugged, and have integrated unit testing, and a large enough group of volunteers to test new releases before they go into the general public. How can you be sure if something is large enough if, as you say below, you do not care about probabilities? SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. Also, again, systemd have a lot of little binaries, many of them optional. The LOC of PID 1 is actually closer to SysV (although still bigger). Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; If you do not care (= do not now anything) about probabilities (and mathematics, in general), you just unable to understand that debugging a program with 200K lines of code take 20!/(1!)^20 more time than debugging of 20 different programs with 10K lines of code. You can try to calculate that number yourself but I quite sure that if the latter can take, say, 20 days, the former can take millions of years. It is all the probability! Or, to be more precise, combinatorics. I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. Have you ever tried forex? If yes, you should have been warned that no past performance guarantee the future one. And if you do not believe that (and do not care about probability and all the stuff like that), you should visit any of the forex forums where you will be suggested a magical money winning strategy that, in the past, behaved very well and earned 200 or even 500% a month. FACT: almost no bug report in systemd involves a segfault in PID 1. All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. kdbus uses a different wire protocol than dbus; but for clients that doesn't matter; libsystemd-dbus will offer a compatibility layer (talk about standard and replaceable), so if your application uses dbus today, it will work with kdbus. Of course, new applications will take advantage of the new features of kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. Lol, he seems to start to use the arguments like You even do not know my elder brother/acquaintance from the street nearby who can easily hit you down! So, here, I would like to thank everybody in this discussion who helped me to understand the danger of systemd and note that it is now became pointless to continue this discussion with this unpayed systemd promoter. anyway it is possible to disable this stuff in kernel and
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Tue, Feb 18, 2014 at 3:53 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On 17/02/2014 17:29, Stroller wrote: On Sun, 16 February 2014, at 4:41 pm, Alan McKinnon alan.mckin...@gmail.com wrote: ... Whatever problems Red Hat are trying to solve in the Red Hat space are problems that do not affect me, so I do not need Red Hat's solution. As for Gnome, I have yet to see a valid reason why Gnome *must* use systemd; that is simply not true at all. I thought this all boiled down to trying to login to GDM using accessibility functions and a bluetooth hearing aid (or bluetooth keyboard, for that matter). That was the classic rationale for no separate /usr without an initrd in udev - the claimed need to have any arbitrary runnable code available to be run before the entire system is up and running. Red Hat's reasons for pushing systemd are more fuzzy and nothing I've read so far tells me we have the full picture. Two things seem highly plausible: 1. An init system that can use modern features of the Linux kernel (most often Linux-only at this point) like cgroups 2. Extremely fast boot times to spin up virtual machines in a fraction of the time it currently takes. #1 may or may not be desirable, I honestly don't know. What I have seen is a lot of theory and not much reproducable fact. init scripts, in general, are ad-hoc, quirky, and incomplete implementations of service supervision in bash. They're reliable so long as the daemon can be relied on to advertise one or all of its processes in a pid file. Thing is, there are way too many different possible setups for services for that to be the case. In the average case watching a PID file works. And since most people use average software, most people don't care. That's ok. Thing is an init isn't just for most people. It's for all people. It should be reliable for all services. I used to use cherokee. Fast, light, awesome, and with a web admin. The init script always failed me. /etc/init.d/cherokee stop was not a guaranteed stop to all forked cherokee processes - the parent pid dies, but some forked process or something, usually related to rrdtool, doesn't. Or the parent does exit and erases the pid file but it returns control immediately and its not yet done exiting. Something like that or other. Point is, I've several times had to ps aux|grep ... kill; zap; start - on production servers. Was it cherokee's fault? Maybe. But the init script should have told me that. Or even better, the init script should have done its job and terminted the processes. See, pid files are just a proxy, they don't work for all services and all setups. Maybe a process crashes before it kills its forks. Maybe the server has a restart feature that fails to write the pid file because the init script created it as root but the daemon relinquished privileges. Maybe there's a bug somewhere. Maybe the pid file gets overwritten accidentally. Maybe the pid file is stale because of a power failure. Point is you don't know until the service restart which should just take a sec costs you maybe an hour or two in billable time. With supervised cgroups that's not a problem. Because all process forks are grouped together, it doesn't matter if there's a pid file or not. When its kill time, the daemon and all forks and children go down. Because they're dynamically created on start, they don't get stale or point to the wrong process. Sounds to me like the right tool for the job. The init script introduces a point of fragility and brittleness into the system making it harder to debug, all to implement service supervision. If you look at the upstream docs of your daemon, it'll probably just tell you to run /usr/sbin/somethingd, maybe with a -d argument, to find out why it isn't starting. Cue the init script now always failing because you just created a bunch of files as the root user. Bit me in the back a few times with mysqld. Oh, I'm supposed to read the whole init script to determine all environment variables, settings, and switches the system uses to start a daemon, right? Good luck grepping. Because from a unit file, I can tell the command to run in a single glance. -- This email is:[ ] actionable [x] fyi[ ] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate[ ] soon [x] none
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Mon, Feb 17, 2014 at 8:05 PM, Gevisz gev...@gmail.com wrote: [ snip ] How can you be sure if something is large enough if, as you say below, you do not care about probabilities? By writing correct code? SysVinit code size is about 10 000 lines of code, OpenRC contains about 13 000 lines, systemd — about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. Also, again, systemd have a lot of little binaries, many of them optional. The LOC of PID 1 is actually closer to SysV (although still bigger). Even assuming systemd code is as mature as sysvinit or openrc (though I doubt this) you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; If you do not care (= do not now anything) about probabilities (and mathematics, in general), you just unable to understand that debugging a program with 200K lines of code take 20!/(1!)^20 more time than debugging of 20 different programs with 10K lines of code. You can try to calculate that number yourself but I quite sure that if the latter can take, say, 20 days, the former can take millions of years. It is all the probability! Or, to be more precise, combinatorics. My PhD thesis (which I will defend in a few weeks) is in computer science, specifically computational geometry and combinatorics. But hey, thanks for the lesson. I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. Have you ever tried forex? If yes, you should have been warned that no past performance guarantee the future one. I never said that. I trust the quality of the code, measured by my own judgment and bug reports, etc. Not past performance. And even if a bug goes by, then what? The world will end? No, the bug will be reported, and fixed. And life will go on. And if you do not believe that (and do not care about probability and all the stuff like that), you should visit any of the forex forums where you will be suggested a magical money winning strategy that, in the past, behaved very well and earned 200 or even 500% a month. Thanks for the tip, but I have never understood the people that believes economics is closer to mathematics than sociology. FACT: almost no bug report in systemd involves a segfault in PID 1. All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. And this is a very, very bad idea. Looks like you don't know matter at all: to begin with kdbus protocol is NOT compatible dbus and special converter daemon will be needed to enable dbus to talk to kdbus. kdbus uses a different wire protocol than dbus; but for clients that doesn't matter; libsystemd-dbus will offer a compatibility layer (talk about standard and replaceable), so if your application uses dbus today, it will work with kdbus. Of course, new applications will take advantage of the new features of kdbus. The whole kdbus technology is very questionable itself (and was forcefully pushed by RH devs), Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. Lol, he seems to start to use the arguments like You even do not know my elder brother/acquaintance from the street nearby who can easily hit you down! If you don't think Greg's words have any weight in a Linux-related technical discussion, then I'm afraid we will need to agree to disagree on any technical subject. So, here, I would like to thank everybody in this discussion who helped me to understand the danger of systemd and note that it is now became pointless to continue this discussion with this unpayed systemd promoter. Getting personal, are we? anyway it is possible to disable this stuff in kernel and guess what will be done on my systems. Good for you. Guess what will be done in mine? Looks broken. Broken by design. The worst form of broken. By your opinion, not others. That is not just an opinion. There is a science and experience behind system's design. Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand, or Keith Packard of X.org fame? None of them works for Red Hat; both of them know more about Unix and Linux than you and me together, and both of them promote systemd. Aha! How could you even doubt my understanding the words of these prophets! :-) They, contrary to you, actually give technical arguments instead of splutter some nonsense about combinatorics that has nothing to do
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16/02/2014 17:46, Tanstaafl wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc I don't know much about systemd, I do know openrc. Thus far, the only real actual benefit I have seen of systemd that is a real issue that really affects me is consolekit. It's not exactly the best piece of software out there, comparable to HAL and how it was replaced by udev. So systemd replaces and fixes consolekit by providing logind. As for all the other supposed benefits of systemd - I don't see them in my world; perhaps they do exist in someone else's worls, I can't really comment on that. But they don't exist in mine and therefore that makes systemd's solutions theoretical for me. Everything I might like in systemd is already implemented in OpenRC so I have no compelling need to switch. Besides, my computers do not break when they boot and shutdown, service management works reliably and well, there are no race conditions on boot that affect me and I still to this day do not understand why I would need cgroups at all. Whatever problems Red Hat are trying to solve in the Red Hat space are problems that do not affect me, so I do not need Red Hat's solution. As for Gnome, I have yet to see a valid reason why Gnome *must* use systemd; that is simply not true at all. Systemd is there, Gnome decided to use it. the Gnome team could just as easily have decided to not use it, or use bits of it, or whatever. Using systemd in Gnome was a choice, not something that had to be done due to a constraint. So overall, systemd might very well solve a particular vertical problem (point to them if it does), but I truly do not see how it can be the OneTrueInitSystem, the One That In The Darkness Binds Us. My 0.02 millicents -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... Well, that's the pickle, isn't it? We have the usual stuff: • OpenRC wasn't able (until very recently) to properly do parallel execution of daemons. There will be someone who will say that isn't important. • Then there is the inability of OpenRC to properly stop/monitor daemons (everybody here had to use /etc/init.d/daemon zap at some point, I suppose). Someone will say that there is experimental cgroups support for OpenRC... experimental being the important word, and there is also the little matter of that not being integrated into the official package (AFAIU). Also, with that OpenRC loses the advantage of being portable to FreeBSD and/or Hurd. • And of course, OpenRC is slow as hell compared to systemd (although there are reports of being really fast using reentrant busybox... I never used that way, so I don't know). Which again, someone will say that that doesn't matter because I never reboot my machine. Great. But then we have the whole load of features that systemd provides that no other init system does (OpenRC included). That is an advantage if you believe that having an standardized plumbing in all mainstream Linux distributions has technical merit and is a good design. If you believe so (like I and many others do), then systemd is several orders of magnitude better than OpenRC. If you don't believe so (like many... although apparently they are less and less as time goes by), then systemd is the spawn of the devil and it should be killed with fire. For General Purpose Linux distributions, systemd is a godsend since it solves and centralizes a lot of stuff that matters to a lot of people. It's fast and small (if you remove the optional dependencies), so the embedded guys like it. It offers (for the first time ever) proper daemon control and management and O(log n) access logs, so the server guys like it. And if offers proper session monitoring and seat control, so the desktop guys like it too. But all those advantages only will be so, if you agree with having a tightly integrated plumbing interface directly above the kernel and below PAM and/or X (soon Wayland) sessions. It gets kind of philosophical, which is why a lot of people taunts the fuzzy term UNIX philosophy so much when they rave against systemd. As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc It's because they are cons only if you agree with systemd's view of the world. I do. 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] Debian just voted in systemd for default init system in jessie
On 16/02/14 18:41, Alan McKinnon wrote: On 16/02/2014 17:46, Tanstaafl wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc I don't know much about systemd, I do know openrc. Thus far, the only real actual benefit I have seen of systemd that is a real issue that really affects me is consolekit. It's not exactly the best piece of software out there, comparable to HAL and how it was replaced by udev. So systemd replaces and fixes consolekit by providing logind. ConsoleKit works just fine for the features it advertises to have, where as HAL never did, so I really don't know what you are referring to?
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sunday 16 Feb 2014 16:50:26 Canek Peláez Valdés wrote: On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... Well, that's the pickle, isn't it? We have the usual stuff: • OpenRC wasn't able (until very recently) to properly do parallel execution of daemons. There will be someone who will say that isn't important. • Then there is the inability of OpenRC to properly stop/monitor daemons (everybody here had to use /etc/init.d/daemon zap at some point, I suppose). Someone will say that there is experimental cgroups support for OpenRC... experimental being the important word, and there is also the little matter of that not being integrated into the official package (AFAIU). Also, with that OpenRC loses the advantage of being portable to FreeBSD and/or Hurd. • And of course, OpenRC is slow as hell compared to systemd (although there are reports of being really fast using reentrant busybox... I never used that way, so I don't know). Which again, someone will say that that doesn't matter because I never reboot my machine. Great. But then we have the whole load of features that systemd provides that no other init system does (OpenRC included). That is an advantage if you believe that having an standardized plumbing in all mainstream Linux distributions has technical merit and is a good design. If you believe so (like I and many others do), then systemd is several orders of magnitude better than OpenRC. If you don't believe so (like many... although apparently they are less and less as time goes by), then systemd is the spawn of the devil and it should be killed with fire. For General Purpose Linux distributions, systemd is a godsend since it solves and centralizes a lot of stuff that matters to a lot of people. It's fast and small (if you remove the optional dependencies), so the embedded guys like it. It offers (for the first time ever) proper daemon control and management and O(log n) access logs, so the server guys like it. And if offers proper session monitoring and seat control, so the desktop guys like it too. But all those advantages only will be so, if you agree with having a tightly integrated plumbing interface directly above the kernel and below PAM and/or X (soon Wayland) sessions. It gets kind of philosophical, which is why a lot of people taunts the fuzzy term UNIX philosophy so much when they rave against systemd. As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc It's because they are cons only if you agree with systemd's view of the world. I do. I think what people primarily object to is not the parts that systemd does well or does better than other init process start up systems. The main objection from what I understand is the removal of choice that systemd developers have forced upon users, by making certain architectural decisions. These are decisions which may look optimal for RHL, but appear to be less so for the rest of the *nix ecosystem given the objections to systemd across the populace. For some Gentoo users in particular, removing the choice of running /usr on a separate partition (without *forcing* the use of initramfs) created the first pain point, or wakeup call. Many complaints were posted on this M/L, centering on this removal of choice. Unlike binary distros Gentoo is all about choice, so the complaints were perhaps louder than elsewhere. People speaking of *nix design philosophy are not necessarily having a rant, but can be legitimately concerned that architectural decisions to hardwire systemd into Linux will remove choice from its wider user base. I am similarly concerned that a monoculture has less success of survival. The fact that Debian decided to embrace the systemd option will no doubt have an impact on what Gentoo follows. I am not educated in init start up systems to know why other options were not considered as part of the Debian debate. Is it that runit, or epoch or what- else are not even close in terms of functionality, versatility and choice? Framing a question can narrow the answers. I hope that
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Am 15.02.2014 16:16, schrieb Tanstaafl: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. Read it here: http://vsido.org/index.php?topic=653.45 I'd really like to see a similar discussion/debate by those far more knowledgeable than I with respect to systemd vs OpenRC, but the above does bring up a lot of salient points. http://ewontfix.com/14/
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Am 16.02.2014 17:50, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... Well, that's the pickle, isn't it? We have the usual stuff: • OpenRC wasn't able (until very recently) to properly do parallel execution of daemons. There will be someone who will say that isn't important. • Then there is the inability of OpenRC to properly stop/monitor daemons (everybody here had to use /etc/init.d/daemon zap at some point, I suppose). Someone will say that there is experimental cgroups support for OpenRC... experimental being the important word, and there is also the little matter of that not being integrated into the official package (AFAIU). Also, with that OpenRC loses the advantage of being portable to FreeBSD and/or Hurd. • And of course, OpenRC is slow as hell compared to systemd (although there are reports of being really fast using reentrant busybox... I never used that way, so I don't know). Which again, someone will say that that doesn't matter because I never reboot my machine. Great. But then we have the whole load of features that systemd provides that no other init system does (OpenRC included). That is an advantage if you believe that having an standardized plumbing in all mainstream Linux distributions has technical merit and is a good design. or it is an idiotic decision. Because features means complexity. Complexity means bugs. And you don't want complexity in PID1 or init. Let those 'features' be handled by their own specialists. You know, the unix way. Do one thing, do it well. Use text to communicate. That stuff. That makes things easy. And flexible. And replaceable.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16.02.2014 20:50, Canek Peláez Valdés wrote: [ ... ] It's because they are cons only if you agree with systemd's view of the world. I do. Isn't there too many if you believe and if you agree? A church of systemd? ;) I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. But why then is Linux drifting to systemd? The answer is simple: money. Time is money. You have to support two init systems - twice the time, twice the money. Sooner or later, a sum of money will outweigh the users' opinion. To be a realist, one has to admit that in near future 90% of new distro versions will be systemd-based. Unless some green soxx emerge and take over Red Hat... -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sunday 16 Feb 2014 19:00:43 Yuri K. Shatroff wrote: On 16.02.2014 20:50, Canek Peláez Valdés wrote: [ ... ] It's because they are cons only if you agree with systemd's view of the world. I do. Isn't there too many if you believe and if you agree? A church of systemd? ;) I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. But why then is Linux drifting to systemd? The answer is simple: money. Time is money. You have to support two init systems - twice the time, twice the money. Sooner or later, a sum of money will outweigh the users' opinion. To be a realist, one has to admit that in near future 90% of new distro versions will be systemd-based. Unless some green soxx emerge and take over Red Hat... You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16.02.2014 23:26, Mick wrote: On Sunday 16 Feb 2014 19:00:43 Yuri K. Shatroff wrote: [ ... ] But why then is Linux drifting to systemd? The answer is simple: money. Time is money. You have to support two init systems - twice the time, twice the money. Sooner or later, a sum of money will outweigh the users' opinion. To be a realist, one has to admit that in near future 90% of new distro versions will be systemd-based. Unless some green soxx emerge and take over Red Hat... You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: Sorry, by the time Volker posted his message, I was already writing mine. ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? Do you disagree with my statement that in near future 90% of new distro versions will be systemd-based? Or with some other statement of mine? If the former, then I intentionally put it down to money with no regard to technical performance because money is usually what ultimately matters for maintainers. From a Software User's POV, as I said, I agree that systemd is a load of bul^W things whose significance is at the least overrated. From a technical POV, I bet, most systemd's cookies could be implemented within any other init system as well, if required. But in the Real World, software users either develop theirs own if they have the resources, or get what they are given by those who have. So my whole message was about -- whether OpenRC/upstart/anything guys have resources to show'em or eventually fall to systemd. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 12:31 PM, Mick michaelkintz...@gmail.com wrote: [ snip ] well or does better than other init process start up systems. The main objection from what I understand is the removal of choice that systemd developers have forced upon users, by making certain architectural decisions. These are decisions which may look optimal for RHL, but appear to be less so for the rest of the *nix ecosystem given the objections to systemd across the populace. I'm sorry, but what is being forced on whom? Everything is Free Software, anyone can choose to use SysV, OpenRC, or Upstart if they so do desire. *Someone* needs to support that software, though. In the case of SysV and OpenRC, I don't think they will have problem; they will probably live forever. Upstart, on the other hand, could be easily be dead in a couple of months: its original author actually endrses systemd [1]. For some Gentoo users in particular, removing the choice of running /usr on a separate partition (without *forcing* the use of initramfs) created the first pain point, or wakeup call. That has nothing to do with systemd, nor udev; they actually work with /usr in another partition, they just print a warning. And presently OpenRC also requires an initramfs if you have /usr on another partition. Again, that is not *forcing* anything on anyone. It's just maintainers (Gentoo devs in the case of Gentoo's council decision) limiting the total number of supported combinations, because the number of developers/maintainers we have is finite. Again, if anyone wants *every*, possible combination, *someone* has to write the software to support them. Many complaints were posted on this M/L, centering on this removal of choice. Unlike binary distros Gentoo is all about choice, so the complaints were perhaps louder than elsewhere. Gentoo and Linux in general are about choice, as long as someone is willing and able to write the software to support that choice. People speaking of *nix design philosophy are not necessarily having a rant, but can be legitimately concerned that architectural decisions to hardwire systemd into Linux will remove choice from its wider user base. *Any* choice will be *always* available as long as someone willing and able to write the software to support that choice. I am similarly concerned that a monoculture has less success of survival. I think that's a legitimate concern, but it's again kind of philosophical; all the software it's out there: systemd, Upstart, OpenRC, SysV, the kernel (including all the versions from the last 22 years), GNOME, KDE, etc., and it's libre. If systemd dies, we will replace it with something cooler. I'm willing to bet the functioning of all my machines to that (as I'm currently doing). The fact that Debian decided to embrace the systemd option will no doubt have an impact on what Gentoo follows. For sure. I am not educated in init start up systems to know why other options were not considered as part of the Debian debate. Is it that runit, or epoch or what- else are not even close in terms of functionality, versatility and choice? Framing a question can narrow the answers. I don't know those init systems enough to give you an answer. What I do know if that none of them has the momentum of systemd, or as many developers (and their undeniable talent), as systemd. But who knows, if someone willing and able keeps punching at it (with code, not rants), maybe from there it will come the next big thing. I hope that whatever the Gentoo decision may be one day, it will not irreversibly remove choice from us Gentoo-ers. The only way a choice will be always available, is that someone is willing and able to write the software to support it. It's really that simple. Regards. [1] https://plus.google.com/u/0/+ScottJamesRemnant/posts/4eHMc2tvp7C -- 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] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. And you don't want complexity in PID1 or init. Let those 'features' be handled by their own specialists. Almost all the features of systemd live outside of PID 1. You know, the unix way. Do one thing, do it well. This is from my desktop machine: /usr/lib/systemd/systemd-reply-password /usr/lib/systemd/ntp-units.d /usr/lib/systemd/systemd-coredump /usr/lib/systemd/systemd-hostnamed /usr/lib/systemd/systemd-binfmt /usr/lib/systemd/systemd-localed /usr/lib/systemd/systemd-machined /usr/lib/systemd/systemd-sleep /usr/lib/systemd/system-generators /usr/lib/systemd/system-generators/systemd-system-update-generator /usr/lib/systemd/system-generators/systemd-gpt-auto-generator /usr/lib/systemd/system-generators/systemd-efi-boot-generator /usr/lib/systemd/system-generators/systemd-fstab-generator /usr/lib/systemd/system-generators/systemd-getty-generator /usr/lib/systemd/system-generators/gentoo-local-generator /usr/lib/systemd/systemd-fsck /usr/lib/systemd/systemd-bootchart /usr/lib/systemd/systemd-shutdown /usr/lib/systemd/systemd-random-seed /usr/lib/systemd/system-sleep /usr/lib/systemd/systemd-remount-fs /usr/lib/systemd/user-generators /usr/lib/systemd/systemd-sysctl /usr/lib/systemd/systemd-timedated /usr/lib/systemd/catalog /usr/lib/systemd/system-shutdown /usr/lib/systemd/systemd-udevd /usr/lib/systemd/systemd-multi-seat-x /usr/lib/systemd/systemd-cgroups-agent /usr/lib/systemd/systemd-user-sessions /usr/lib/systemd/systemd-journal-gatewayd /usr/lib/systemd/systemd-quotacheck /usr/lib/systemd/systemd-shutdownd /usr/lib/systemd/systemd-modules-load /usr/lib/systemd/systemd-backlight /usr/lib/systemd/systemd-ac-power /usr/lib/systemd/systemd-initctl /usr/lib/systemd/systemd-readahead /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-activate /usr/lib/systemd/systemd /usr/lib/systemd/systemd-update-utmp /usr/lib/systemd/systemd-vconsole-setup /usr/lib/systemd/systemd-logind All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. Use text to communicate. systemd can comunicate basically everything via text: centurion ~ # systemctl show sshd.service | head Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon LoadState=loaded For performance reasons, some things are passed or stored as data. Bu everything works with text also. So, again, it passes your definition. That stuff. That makes things easy. And flexible. And replaceable. Easy to whom? And systemd is more flexible that a lot of init systems, in my opinion including OpenRC. All the configuration and APIs are documented, public and open source. Everything is replaceable if there is someone willing and able to write a replacement. 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] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 1:00 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: [ snip ] Isn't there too many if you believe and if you agree? A church of systemd? ;) As I said to Tanstaafl, it gets kind of philosophical. Technically, systemd is the obvious superior choice, and that's why the TC voted for it in Debian (read the discussion). I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? If it's practically useless, why so many distributions keep choosing it? Why GNOME started using it? Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. All the software is libre; with only that any comparison to Microsoft becomes moot. A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? That's *your* approach. It's certainly not my approach: I don't care if Emacs is standards-compliant (whatever that means for a text editor); I don't care if Inkscape has an alternative compatible implementation; and for the rest of your questions, my answer would be yes. AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. From your point of view. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. That's fine; you don't have to use systemd. But if (as an extreme and unlikely example), Gentoo decided to switch exclusively to systemd, then either someone willing and able would need to come out ant start maintaining the alternatives, or then you should do it. That's how free software works. But why then is Linux drifting to systemd? The answer is simple: money. Time is money. You have to support two init systems - twice the time, twice the money. Sooner or later, a sum of money will outweigh the users' opinion. To be a realist, one has to admit that in near future 90% of new distro versions will be systemd-based. Unless some green soxx emerge and take over Red Hat... I don't think neither time nor money had to do with Debian's (nor Arch's, nor OpenSuse's, nor Maegia's, nor Sabayon's) decision. It's just technically superior. But's that's just my opinion, and what I believe ;) So, amen? :D 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] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 1:26 PM, Mick michaelkintz...@gmail.com wrote: [snip] You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. I had read that blog entry before. Is full of errors, like believing that everything that systemd does is inside PID 1. There is actually little code inside PID 1; most of systemd functionality comes from separated binaries. You know, do one thing, do it right? From [1]: If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). You can get rid of *everything*, if so you desire. But *someone* needs to write/patch the code. Regards. [1] http://0pointer.de/blog/projects/the-biggest-myths.html -- 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] Debian just voted in systemd for default init system in jessie
Am 16.02.2014 21:27, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 1:26 PM, Mick michaelkintz...@gmail.com wrote: [snip] You may have lost it in the link that Volker posted (thanks Volker), but this comment from HaakonKL probably sums it up: ... I will give Upstart this though: Should something better come along, you could replace upstart. I guess this holds true for OpenRC as well. You can't say that about systemd. I had read that blog entry before. Is full of errors, like believing that everything that systemd does is inside PID 1. There is actually little code inside PID 1; most of systemd functionality comes from separated binaries. You know, do one thing, do it right? From [1]: If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. and all are linked (not compilelink) in such a manner that you can't just pick and choose. Oh no, you get the full treatment if you like it or not. Can you surgically remove systemd in the future without reverse engineering half of what the LSB would look at the time, or will its developers ensure that this is a one time choice only? You guys talk about software like if it was a big bad black magical box with inexplicable powers. If someone is willing and able, *everything* can be surgically remove[d]. We got rid of devfs, remember? We got rid of OSS (thank the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, and ESD. KDE got rid of aRts (and who knows what more). yeah, as soon as everybody had worked out devfs it got scrapped. As soon as hal was usable, it was replaced with something new, that never stopped changing since then. And then came pulseaudio. The solution to a problem that does not exist. And because of pulseaudio, all the things that led. to systemd happened. You can get rid of *everything*, if so you desire. But *someone* needs to write/patch the code. Regards. [1] http://0pointer.de/blog/projects/the-biggest-myths.html I am not trusting the people who lied about udev.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. And you don't want complexity in PID1 or init. Let those 'features' be handled by their own specialists. Almost all the features of systemd live outside of PID 1. You know, the unix way. Do one thing, do it well. This is from my desktop machine: /usr/lib/systemd/systemd-reply-password /usr/lib/systemd/ntp-units.d /usr/lib/systemd/systemd-coredump /usr/lib/systemd/systemd-hostnamed /usr/lib/systemd/systemd-binfmt /usr/lib/systemd/systemd-localed /usr/lib/systemd/systemd-machined /usr/lib/systemd/systemd-sleep /usr/lib/systemd/system-generators /usr/lib/systemd/system-generators/systemd-system-update-generator /usr/lib/systemd/system-generators/systemd-gpt-auto-generator /usr/lib/systemd/system-generators/systemd-efi-boot-generator /usr/lib/systemd/system-generators/systemd-fstab-generator /usr/lib/systemd/system-generators/systemd-getty-generator /usr/lib/systemd/system-generators/gentoo-local-generator /usr/lib/systemd/systemd-fsck /usr/lib/systemd/systemd-bootchart /usr/lib/systemd/systemd-shutdown /usr/lib/systemd/systemd-random-seed /usr/lib/systemd/system-sleep /usr/lib/systemd/systemd-remount-fs /usr/lib/systemd/user-generators /usr/lib/systemd/systemd-sysctl /usr/lib/systemd/systemd-timedated /usr/lib/systemd/catalog /usr/lib/systemd/system-shutdown /usr/lib/systemd/systemd-udevd /usr/lib/systemd/systemd-multi-seat-x /usr/lib/systemd/systemd-cgroups-agent /usr/lib/systemd/systemd-user-sessions /usr/lib/systemd/systemd-journal-gatewayd /usr/lib/systemd/systemd-quotacheck /usr/lib/systemd/systemd-shutdownd /usr/lib/systemd/systemd-modules-load /usr/lib/systemd/systemd-backlight /usr/lib/systemd/systemd-ac-power /usr/lib/systemd/systemd-initctl /usr/lib/systemd/systemd-readahead /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-activate /usr/lib/systemd/systemd /usr/lib/systemd/systemd-update-utmp /usr/lib/systemd/systemd-vconsole-setup /usr/lib/systemd/systemd-logind All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? Besides - why is garbage essential for booting in /usr? Looks broken. Broken by design. The worst form of broken. Use text to communicate. systemd can comunicate basically everything via text: centurion ~ # systemctl show sshd.service | head Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon LoadState=loaded For performance reasons, some things are passed or stored as data. Bu everything works with text also. So, again, it passes your definition. oh? I can pipe that output into cat or any any daemon I like? Doesn't look like so. That stuff. That makes things easy. And flexible. And replaceable. Easy to whom? And systemd is more flexible that a lot of init systems, in my opinion including OpenRC. oh really? because everything is done by the magical Pöttering? All the configuration and APIs are documented, public and open source. Everything is replaceable if there is someone willing and able to write a replacement. and that has been debunked by others.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Am 16.02.2014 21:19, schrieb Canek Peláez Valdés: Why GNOME started using it? because of redhat. Seriously, you had to ask that?
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: Am 16.02.2014 21:08, schrieb Canek Peláez Valdés: On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann volkerar...@googlemail.com wrote: [ snip ] or it is an idiotic decision. Because features means complexity. Yeah, like the kernel. Complexity means bugs. Bugs get reported, bugs get fixes. Life goes on. You didn't answered this, did you? And you don't want complexity in PID1 or init. Let those 'features' be handled by their own specialists. Almost all the features of systemd live outside of PID 1. You know, the unix way. Do one thing, do it well. This is from my desktop machine: /usr/lib/systemd/systemd-reply-password /usr/lib/systemd/ntp-units.d /usr/lib/systemd/systemd-coredump /usr/lib/systemd/systemd-hostnamed /usr/lib/systemd/systemd-binfmt /usr/lib/systemd/systemd-localed /usr/lib/systemd/systemd-machined /usr/lib/systemd/systemd-sleep /usr/lib/systemd/system-generators /usr/lib/systemd/system-generators/systemd-system-update-generator /usr/lib/systemd/system-generators/systemd-gpt-auto-generator /usr/lib/systemd/system-generators/systemd-efi-boot-generator /usr/lib/systemd/system-generators/systemd-fstab-generator /usr/lib/systemd/system-generators/systemd-getty-generator /usr/lib/systemd/system-generators/gentoo-local-generator /usr/lib/systemd/systemd-fsck /usr/lib/systemd/systemd-bootchart /usr/lib/systemd/systemd-shutdown /usr/lib/systemd/systemd-random-seed /usr/lib/systemd/system-sleep /usr/lib/systemd/systemd-remount-fs /usr/lib/systemd/user-generators /usr/lib/systemd/systemd-sysctl /usr/lib/systemd/systemd-timedated /usr/lib/systemd/catalog /usr/lib/systemd/system-shutdown /usr/lib/systemd/systemd-udevd /usr/lib/systemd/systemd-multi-seat-x /usr/lib/systemd/systemd-cgroups-agent /usr/lib/systemd/systemd-user-sessions /usr/lib/systemd/systemd-journal-gatewayd /usr/lib/systemd/systemd-quotacheck /usr/lib/systemd/systemd-shutdownd /usr/lib/systemd/systemd-modules-load /usr/lib/systemd/systemd-backlight /usr/lib/systemd/systemd-ac-power /usr/lib/systemd/systemd-initctl /usr/lib/systemd/systemd-readahead /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-activate /usr/lib/systemd/systemd /usr/lib/systemd/systemd-update-utmp /usr/lib/systemd/systemd-vconsole-setup /usr/lib/systemd/systemd-logind All of them are different tools providing one capability to systemd as a whole. So systemd is a collection of tools, where each one does one thing, and it does it well. By your definition, systemd perfectly follows the unix way. no, it isn't. How are those binaries talk to each other? dbus, which is about to be integrated into the kernel with kdbus. Besides - why is garbage essential for booting in /usr? Is not. Most of it is optional, in a server I have there are much less binaries. Looks broken. Broken by design. The worst form of broken. By your opinion, not others. Use text to communicate. systemd can comunicate basically everything via text: centurion ~ # systemctl show sshd.service | head Id=sshd.service Names=sshd.service Requires=basic.target Wants=system.slice WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice Description=OpenSSH server daemon LoadState=loaded For performance reasons, some things are passed or stored as data. Bu everything works with text also. So, again, it passes your definition. oh? I can pipe that output into cat or any any daemon I like? Doesn't look like so. But it does, you can cat with journalctl; it's one of its output options: -o, --output= cat generates a very terse output only showing the actual message of each journal entry with no meta data, not even a timestamp. That stuff. That makes things easy. And flexible. And replaceable. Easy to whom? And systemd is more flexible that a lot of init systems, in my opinion including OpenRC. oh really? because everything is done by the magical Pöttering? OK, sorry, I thought you wanted to have a civil, serious, technical conversation. I'm done with you in this thread. 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] Debian just voted in systemd for default init system in jessie
On 16/02/2014 20:11, Samuli Suominen wrote: On 16/02/14 18:41, Alan McKinnon wrote: On 16/02/2014 17:46, Tanstaafl wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc I don't know much about systemd, I do know openrc. Thus far, the only real actual benefit I have seen of systemd that is a real issue that really affects me is consolekit. It's not exactly the best piece of software out there, comparable to HAL and how it was replaced by udev. So systemd replaces and fixes consolekit by providing logind. ConsoleKit works just fine for the features it advertises to have, where as HAL never did, so I really don't know what you are referring to? It's a poor design. It's also unmaintained currently. But I don't want to debate consolekit, it's OT for this thread. It runs on my machines currently because ebuilds pulled it in. It seems to do what it should, so for the moment I'm happy to leave it in place. But I don't regard it as a good design, it's one of those things I list in the risk register in my head and keep an eye on as I consider it brittle. I only brought it up as an example, an illustration of my position. If you feel it's a lousy analogy then so be it, but I'd rather not detract from the topic of the thread, which is systemd. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 16/02/14 23:28, Alan McKinnon wrote: On 16/02/2014 20:11, Samuli Suominen wrote: On 16/02/14 18:41, Alan McKinnon wrote: On 16/02/2014 17:46, Tanstaafl wrote: On 2014-02-15 3:32 PM, Canek Peláez Valdés can...@gmail.com wrote: For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1]https://wiki.debian.org/Debate/initsystem/ I would really, really, REALLY like to see a thorough, civil debate involving those far more knowledgeable than I on the pros and cons of systemd vs OpenRC... As it seems to me, the Debian OpenRC page says that the cons are not nearly as large as the systemd proponents would have us believe. https://wiki.debian.org/Debate/initsystem/openrc I don't know much about systemd, I do know openrc. Thus far, the only real actual benefit I have seen of systemd that is a real issue that really affects me is consolekit. It's not exactly the best piece of software out there, comparable to HAL and how it was replaced by udev. So systemd replaces and fixes consolekit by providing logind. ConsoleKit works just fine for the features it advertises to have, where as HAL never did, so I really don't know what you are referring to? It's a poor design. It's also unmaintained currently. How long has it been since Debian decided to go with systemd? Like, three? So, up until three days ago I would have disagreed since despite original upstream ditching ConsoleKit, it was still being maintained by Debian and Gentoo maintainers (me) and last release, 0.4.6, was in fact a result of that. But still, the fact that there is no more active development, doesn't mean it's obsolete. It still works fine as it ever did and there has been no need to cut any of it's features for any reason. Since logind works only on systemd, ConsoleKit is nothing less than what dhcp-client is to dhcpcd. So, it's definately not 'deprecated', or 'obsolete'. I call it 'mature'. Many BSDs still use it, and with Xfce upstream including a OpenBSD developer, and Xfce's commitment to keeping it working with BSDs in otherway too, I'm not worried about it becoming one of these nasty words of 'unmaintained', 'deprecated', 'obsolete' and co. even if I didn't do the legwork myself. So no, we don't get to blame ConsoleKit for any of this what has been happening. Take my word for it, it's not going to go anywhere from Portage anyday soon. But OK, it's a bit off-topic to this thread, I'm just getting ugly itch when people are so eager to call it anything else than mature despite it still working fine. - Samuli
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
17.02.2014 00:19, Canek Peláez Valdés пишет: On Sun, Feb 16, 2014 at 1:00 PM, Yuri K. Shatroff yks-...@yandex.ru wrote: [ snip ] Isn't there too many if you believe and if you agree? A church of systemd? ;) As I said to Tanstaafl, it gets kind of philosophical. Even religious. Technically, systemd is the obvious superior choice, and that's why the TC voted for it in Debian (read the discussion). Oh I have read so many discussions already... :) To me, systemd's technical superiority is far not obvious. Just another init system would be, but as long as systemd is much more that one, I can't say that. It should NOT be compared to OpenRC / upstart alone, rather to a whole bunch of tools it replaces, and probably even those it's ambitious to replace. I wonder why all systemd's fancy stuff hasn't yet been integrated into any existing init system, because of theoretical impossibility or just practical uselessness? If it's practically useless, why so many distributions keep choosing it? Why GNOME started using it? Well, I said that technical superiority matters little for maintainers; what matters is money. If I'd write some super-puper fancy init system and kernel replacement, who would be interested? It's not the time of Linus' rise, now you don't deal with USENET freaks, but with Intel, RedHat and other billionaire corps. Do you have the guts and means to keep up with competitors, even not about kernel/init subsystems, but a user app like mailer/browser/messenger... A kernel subsystem requires much more technical competence to maintain and is far more critical for functioning, so much more important here is not any 'technical superiority' but simply resources, human and financial, spared if using RH-maintained systemd. Actually why not do the daemon management, logging, cron etc in the Linux kernel itself? It's obvious, and we even have a perfect example of kernel-integrated graphics around -- `guess the OS name`. It also has much in common with systemd; Believe us it's the best OS, Believe us it provides loads of features, Agree with having binary logs etc. All the software is libre; with only that any comparison to Microsoft becomes moot. Once you mentioned technical superiority, let's compare other stuff technically too. :) A competent approach for choosing software for a task is answering the questions: 1. Is the software standards-compliant? 2. Does the software have an alternative compatible implementation? 3. Is the software developed to achieve a certain, concrete goal? 4. Does the software achieve the goal? 5. Does the software achieve the goal gracefully? 6. Does the software have a clear perspective and view what it will be like? 7. Is the software developed and maintained by a reliable company or group? That's *your* approach. It's certainly not my approach: I don't care if Emacs is standards-compliant (whatever that means for a text editor); I don't care if Inkscape has an alternative compatible implementation; and for the rest of your questions, my answer would be yes. You don't care about Emacs and Inkscape but do you care the same nought about e.g. /bin/cp, /bin/mv etc? Do you care that your browser talks HTTP rather than SHiTP? Do you care that once after a couple of years your systems get unmaintained and unmaintainable because the software on them becomes a load of bashed up crap which only a world's head lennart can deal with? Well, you'll say that red hat tralala, but we've seen the rise and fall of many giants e.g. Sun with their once 'technically superior' Solaris and SPARCs, well one can name many I just don't have time, also we seen MySQL bought by Oracle, and all. Nothing is eternal, and it's (Again!) quite not always technical matters that matters. AFAICT, with systemd there's by far one yes. The other answers are dubious if just plain no. From your point of view. I'd personally share Alan McKinnon's POV: there's no real reason to switch to systemd since the present init systems serve pretty well and the benefit, if any, isn't worth the adaptation threshold. That's fine; you don't have to use systemd. But if (as an extreme and unlikely example), Gentoo decided to switch exclusively to systemd, then either someone willing and able would need to come out ant start maintaining the alternatives, or then you should do it. At present, no. But the trend is clear. That's how free software works. Actually, free software (one you don't pay for) works like any other software you pay for. You probably wanted to say that's how the OSS model works but it's getting less and less true. The OSS model in many cases retains only its open source. Take MySQL, take KDE, take GNOME. Who cares about users? We do what we deem feasible regardless if you like it or not. Don't like it? C'mon, fork, it's free. C'mon, it's technically superior. C'mon, who are you? An admin? A programmer? A Bachelor/PhD? Ha, man, we're BILLIONAIRES. That
[gentoo-user] Debian just voted in systemd for default init system in jessie
Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. Read it here: http://vsido.org/index.php?topic=653.45 I'd really like to see a similar discussion/debate by those far more knowledgeable than I with respect to systemd vs OpenRC, but the above does bring up a lot of salient points.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. One of which was logging: 20. Myth: systemd makes it impossible to run syslog. Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service. From: http://0pointer.de/blog/projects/the-biggest-myths.html
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. One of which was logging: 20. Myth: systemd makes it impossible to run syslog. Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service. From: http://0pointer.de/blog/projects/the-biggest-myths.html Also, for those of you who don't follow Linux-related news, Ubuntu will also change to systemd in the future: http://www.markshuttleworth.com/archives/1316 And I *heard* that Slackware was also discussing the possibility, but since I don't follow Slackware at all, I don't know for sure. Anyway, distros not using systemd, and that they are not really small and/or niche, seem to be disappearing. The discussion that Tanstaafl posted is interesting since the arguments used by the four TC members are really focused on the technical merits of the proposed init systems. 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] Debian just voted in systemd for default init system in jessie
On Saturday 15 Feb 2014 17:32:44 Canek Peláez Valdés wrote: On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. One of which was logging: 20. Myth: systemd makes it impossible to run syslog. Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service. From: http://0pointer.de/blog/projects/the-biggest-myths.html Also, for those of you who don't follow Linux-related news, Ubuntu will also change to systemd in the future: http://www.markshuttleworth.com/archives/1316 And I *heard* that Slackware was also discussing the possibility, but since I don't follow Slackware at all, I don't know for sure. Anyway, distros not using systemd, and that they are not really small and/or niche, seem to be disappearing. The discussion that Tanstaafl posted is interesting since the arguments used by the four TC members are really focused on the technical merits of the proposed init systems. There was a thread sometime last year mentioning a slimmer/slicker and obeying to the *nix design principles initialisation system, but can't find it at the moment. Isn't that at all in the running? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On 02/15/2014 11:32 AM, Canek Peláez Valdés wrote: On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org mailto:tansta...@libertytrek.org wrote: On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org mailto:tansta...@libertytrek.org wrote: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. One of which was logging: 20. Myth: systemd makes it impossible to run syslog. Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service. From: http://0pointer.de/blog/projects/the-biggest-myths.html Also, for those of you who don't follow Linux-related news, Ubuntu will also change to systemd in the future: http://www.markshuttleworth.com/archives/1316 And I *heard* that Slackware was also discussing the possibility, but since I don't follow Slackware at all, I don't know for sure. Anyway, distros not using systemd, and that they are not really small and/or niche, seem to be disappearing. The discussion that Tanstaafl posted is interesting since the arguments used by the four TC members are really focused on the technical merits of the proposed init systems. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México The lack of foresight on social and political ramifications is epidemic to most of the FOSS world, as evidenced by the creeping adoption of systemd. Things are already depending on things that systemd provides, and is dividing the ecosystem into systemd vs everything else. Ambitious projects like systemd are damaging to the rich variety that should be found in the FOSS ecosystem. systemd in particular encourages embracing vertical integration and rejection of POSIX and UNIX principles. Its culture is adversarial to anyone who doubts the Great Image that Lennart and his employer has. If it were a project that was humble, without an agenda, and did not undergo evangelism, I'd have no problems with it because choice is something that I value immensely. But because it *isn't* humble, *has* an agenda, only reached the adoption it currently has by *lots* of arguing and pushing, and refuses to coexist with other init systems, I cannot respect it as a legitimate, non-aggressive, non-intrusive software project. I consider it a toxic threat to FOSS and refuse to have it on any system I maintain. systemd has technical merits (cgroups, socket activation, parellel execution of daemons, etc), but they fall by the wayside and become irrelevant to me when it swallows the functionality of multiple projects that should be separate (see: udev) and tries to be everything to everyone (splash image, web server, boot time graphs, etc). The social tactics at work from the systemd team (and verily, other Red Hat projects like GNOME) are reminiscent of Microsoft through the use of the Embrace, Extend, Extinguish methodology. With their paid developers and more abundant resources, Red Hat (and arguably other corporations) can use their developers to push their agendas and, in a sense, commandeer control of the FOSS world. I will give them no inch on my systems. I am skeptical of their involvement in the kernel, as well. It's sad to see Debian giving into peer pressure. I honestly thought that they would see the agenda miles away and prevent a monoculture. For people who are technically intelligent, they're seriously lacking any foresight in their decisions and are completely blind to the social and political ramifications. Distros will regret depending on such a project and it will set GNU/Linux development back many years when systemd becomes a full stack and working without it is made difficult or impractical (through the use of lock-in tactics). I hope that Gentoo continues to be a safe haven for choice and the spirit of FOSS. Without it, I may have to concede and either start building my own distro, or going to the BSDs. Just my two cents. Ignore or reply at your discretion.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sat, Feb 15, 2014 at 2:23 PM, Mick michaelkintz...@gmail.com wrote: On Saturday 15 Feb 2014 17:32:44 Canek Peláez Valdés wrote: On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. One of which was logging: 20. Myth: systemd makes it impossible to run syslog. Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service. From: http://0pointer.de/blog/projects/the-biggest-myths.html Also, for those of you who don't follow Linux-related news, Ubuntu will also change to systemd in the future: http://www.markshuttleworth.com/archives/1316 And I *heard* that Slackware was also discussing the possibility, but since I don't follow Slackware at all, I don't know for sure. Anyway, distros not using systemd, and that they are not really small and/or niche, seem to be disappearing. The discussion that Tanstaafl posted is interesting since the arguments used by the four TC members are really focused on the technical merits of the proposed init systems. There was a thread sometime last year mentioning a slimmer/slicker and obeying to the *nix design principles initialisation system, but can't find it at the moment. Isn't that at all in the running? For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1] https://wiki.debian.org/Debate/initsystem/ -- 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] Debian just voted in systemd for default init system in jessie
On 02/15/2014 02:32 PM, Canek Peláez Valdés wrote: On Sat, Feb 15, 2014 at 2:23 PM, Mick michaelkintz...@gmail.com wrote: On Saturday 15 Feb 2014 17:32:44 Canek Peláez Valdés wrote: On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. One of which was logging: 20. Myth: systemd makes it impossible to run syslog. Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service. From: http://0pointer.de/blog/projects/the-biggest-myths.html Also, for those of you who don't follow Linux-related news, Ubuntu will also change to systemd in the future: http://www.markshuttleworth.com/archives/1316 And I *heard* that Slackware was also discussing the possibility, but since I don't follow Slackware at all, I don't know for sure. Anyway, distros not using systemd, and that they are not really small and/or niche, seem to be disappearing. The discussion that Tanstaafl posted is interesting since the arguments used by the four TC members are really focused on the technical merits of the proposed init systems. There was a thread sometime last year mentioning a slimmer/slicker and obeying to the *nix design principles initialisation system, but can't find it at the moment. Isn't that at all in the running? For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1] https://wiki.debian.org/Debate/initsystem/ Why didn't they consider runit? It has parallel execution of daemons and is backwards compatible with sysv. It has a few other mini-features as well, iirc. I used for a little while before Arch pushed systemd on their community and it was interesting.
Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
On Sat, Feb 15, 2014 at 2:34 PM, Daniel Campbell li...@sporkbox.us wrote: On 02/15/2014 02:32 PM, Canek Peláez Valdés wrote: On Sat, Feb 15, 2014 at 2:23 PM, Mick michaelkintz...@gmail.com wrote: On Saturday 15 Feb 2014 17:32:44 Canek Peláez Valdés wrote: On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org wrote: On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org wrote: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. One of which was logging: 20. Myth: systemd makes it impossible to run syslog. Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service. From: http://0pointer.de/blog/projects/the-biggest-myths.html Also, for those of you who don't follow Linux-related news, Ubuntu will also change to systemd in the future: http://www.markshuttleworth.com/archives/1316 And I *heard* that Slackware was also discussing the possibility, but since I don't follow Slackware at all, I don't know for sure. Anyway, distros not using systemd, and that they are not really small and/or niche, seem to be disappearing. The discussion that Tanstaafl posted is interesting since the arguments used by the four TC members are really focused on the technical merits of the proposed init systems. There was a thread sometime last year mentioning a slimmer/slicker and obeying to the *nix design principles initialisation system, but can't find it at the moment. Isn't that at all in the running? For Slackware, I have no idea. For Debian, no the only options were[1]: 1. sysvinit (status quo) 2. systemd 3. upstart 4. openrc (experimental) 5. One system on Linux, something else on non-linux 6. multiple It should also be noted that no one in the TC voted OpenRC above systemd AND upstart, and that while a couple voted systemd below everything else, it can be argued that it was a tactical vote. Regards. [1] https://wiki.debian.org/Debate/initsystem/ Why didn't they consider runit? It has parallel execution of daemons and is backwards compatible with sysv. It has a few other mini-features as well, iirc. I used for a little while before Arch pushed systemd on their community and it was interesting. Because nobody proposed it? And almost no one is using it? Which means; no high availability upstream, no momentum, and a small community, which translates in few real-live systems using it in production, and few testers and possible contributors... Besides, systemd and upstart are backwars compatible with sysv, and, well, nobody does parallel execution of daemons better than systemd, AFAICT. So, what advantages would runit bring to the table? Even OpenRC, now that it has (apparently) proper parallel execution support, would be a better choice. But you can read the discussion directly in [1], and see the different proposals in [2]. The discussion got nasty at some points, but I believe in general it was a very civil and intelligent debate. And the social/political problems you mentioned in your last mail were addressed as well. Problems in quotes because there are many of us who don't think they are problems at all, if they even exist. Regards. [1] https://lists.debian.org/debian-ctte/2014/02/threads.html [2] https://wiki.debian.org/Debate/initsystem/ -- 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] Debian just voted in systemd for default init system in jessie
On Sat, 15 Feb 2014 14:30:10 -0600 Daniel Campbell li...@sporkbox.us wrote: On 02/15/2014 11:32 AM, Canek Peláez Valdés wrote: On Feb 15, 2014 11:02 AM, Tanstaafl tansta...@libertytrek.org mailto:tansta...@libertytrek.org wrote: On 2014-02-15 10:16 AM, Tanstaafl tansta...@libertytrek.org mailto:tansta...@libertytrek.org wrote: Hi all, Not to revive a flame-fest against systemd, but... I'm sure some or most of you have already heard about this, but I found a really decent thread discussing this whole systemd thing. It is only really comparing systemd and upstart, as that was the debate going on in the debian TC, but it is a great read, and has actually made me rethink my blind objections to systemd a bit. One of which was logging: 20. Myth: systemd makes it impossible to run syslog. Not true, we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service. From: http://0pointer.de/blog/projects/the-biggest-myths.html Also, for those of you who don't follow Linux-related news, Ubuntu will also change to systemd in the future: http://www.markshuttleworth.com/archives/1316 And I *heard* that Slackware was also discussing the possibility, but since I don't follow Slackware at all, I don't know for sure. Anyway, distros not using systemd, and that they are not really small and/or niche, seem to be disappearing. The discussion that Tanstaafl posted is interesting since the arguments used by the four TC members are really focused on the technical merits of the proposed init systems. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México The lack of foresight on social and political ramifications is epidemic to most of the FOSS world, as evidenced by the creeping adoption of systemd. Things are already depending on things that systemd provides, and is dividing the ecosystem into systemd vs everything else. Ambitious projects like systemd are damaging to the rich variety that should be found in the FOSS ecosystem. systemd in particular encourages embracing vertical integration and rejection of POSIX and UNIX principles. Its culture is adversarial to anyone who doubts the Great Image that Lennart and his employer has. If it were a project that was humble, without an agenda, and did not undergo evangelism, I'd have no problems with it because choice is something that I value immensely. But because it *isn't* humble, *has* an agenda, only reached the adoption it currently has by *lots* of arguing and pushing, and refuses to coexist with other init systems, I cannot respect it as a legitimate, non-aggressive, non-intrusive software project. I consider it a toxic threat to FOSS and refuse to have it on any system I maintain. systemd has technical merits (cgroups, socket activation, parellel execution of daemons, etc), but they fall by the wayside and become irrelevant to me when it swallows the functionality of multiple projects that should be separate (see: udev) and tries to be everything to everyone (splash image, web server, boot time graphs, etc). The social tactics at work from the systemd team (and verily, other Red Hat projects like GNOME) are reminiscent of Microsoft through the use of the Embrace, Extend, Extinguish methodology. With their paid developers and more abundant resources, Red Hat (and arguably other corporations) can use their developers to push their agendas and, in a sense, commandeer control of the FOSS world. I will give them no inch on my systems. I am skeptical of their involvement in the kernel, as well. It's sad to see Debian giving into peer pressure. I honestly thought that they would see the agenda miles away and prevent a monoculture. For people who are technically intelligent, they're seriously lacking any foresight in their decisions and are completely blind to the social and political ramifications. Distros will regret depending on such a project and it will set GNU/Linux development back many years when systemd becomes a full stack and working without it is made difficult or impractical (through the use of lock-in tactics). I hope that Gentoo continues to be a safe haven for choice and the spirit of FOSS. Without it, I may have to concede and either start building my own distro, or going to the BSDs. Thank you for the explanation. I suspected this yet from the beginning of this discussion and waited for such or similar explanations. Technically, I so far know a very little on this subject and only suspect :-) that my Gentoo system uses openrc. I am quite satisfied with it and afraid of switching Gentoo default to systemd.
