Re: init scripts [was: If Not Systemd, then What?]
On Mon, Nov 17, 2014 at 08:54:16PM -0500, Miles Fidelman wrote: > Ludovic Meyer wrote: > >On Mon, Nov 17, 2014 at 06:34:47PM -0500, Miles Fidelman wrote: > >>Ludovic Meyer wrote: > >>>On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote: > >>>>>Given all the talk about not being able to influence upstream, it > >>>>>occurred to me to actually take a look at which of the major > >>>>>applications I rely on actually come with native systemd service > >>>>>scripts. I just went through the documentation, and in some cases, > >>>>>the source trees, for the following: > >>>>>bind9 > >>>>>apache > >>>>>sympa > >>>>>mailman > >>>>>mysql > >>>>>mariadb > >>>>>postgres > >>>>>postfix > >>>>>spamassassin > >>>>>amavisd > >>>>>clamav > >>>>> > >>>>>Most come with sysvinit scripts, several come with their own > >>>>>startup scripts (e.g., apachectl) that get dropped into rc.local. > >>>>>Not a one comes with a native systemd service file (even though, > >>>>>when you search through the mysql documentation it tells you that > >>>>>oracle linux has switched to systemd). > >>>>>So... with systemd, one has to: > >>>>>- rely on packagers to generate systemd service files, and/or, > >>>>>- rely on systemd's support for sysvinit scripts, which > >>>>> > >>>>>In the later case, one just has to read: > >>>>>http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ > >>>>>to get very, very scared > >>>>> > >>>>>Among the implications of this, the old standby of installing > >>>>>software from upstream (bypassing packaging), has just gotten a > >>>>>lot riskier. > >>>>Interesting, since I posted this, a bunch of people have jumped on > >>>>my comment that relying on packagers and systemd to support sysvinit > >>>>scripts seems increasingly risky, but... > >>>> > >>>>Not a single person has commented on the observation that upstream > >>>>developers, at least of core server applications, are thoroughly > >>>>ignoring systemd. > >>>No one commented because that's false. > >>>I also guess that you will use anyone response to later justify > >>>"see, it try to force its way by forcing people to > >>>integrate with systemd". Either way, that's gonna be used > >>>as a way to criticize. > >>False, how? > >the whole part that you erased showed there is a few upstreams > >that care about integration with systemd at the source code level. > > > >Ie, using features of systemd ( journald, socket activation ), > >rather than just providing a .service file. > > No... my point is that NONE of the major upstream projects that I > use on our servers, bother to produce systemd service files, but all > of them produce sysvinit files. so you select only the upstream you want, on the point you want. And erase when someone point the problem. > And I'll note that those are precisely some of the most used, most > mature packages, that you'll find on practically every production > server in the world (well, ok, I left out sendmail, but I just > checked, and guess what, no systemd service file in upstream). > > What do they know? Show us where Debian is using the file shipped by upstream. Then, tell me, is Debian wrong to not use them, or are the script shipped upstream deficient ? In fact, you show "they are shipping initscript", but tell me, how many of them are proper initscript, following lsb ? http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/iniscrptact.html As you didn't gave any link to source code, you place extra burden on the one trying to be critics about your argument. Maybe that's what you want, maybe not. -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141118090718.ga18...@gmail.com
Re: init scripts [was: If Not Systemd, then What?]
On Mon, Nov 17, 2014 at 06:34:47PM -0500, Miles Fidelman wrote: > Ludovic Meyer wrote: > >On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote: > >>>Given all the talk about not being able to influence upstream, it > >>>occurred to me to actually take a look at which of the major > >>>applications I rely on actually come with native systemd service > >>>scripts. I just went through the documentation, and in some cases, > >>>the source trees, for the following: > >>>bind9 > >>>apache > >>>sympa > >>>mailman > >>>mysql > >>>mariadb > >>>postgres > >>>postfix > >>>spamassassin > >>>amavisd > >>>clamav > >>> > >>>Most come with sysvinit scripts, several come with their own > >>>startup scripts (e.g., apachectl) that get dropped into rc.local. > >>>Not a one comes with a native systemd service file (even though, > >>>when you search through the mysql documentation it tells you that > >>>oracle linux has switched to systemd). > >>>So... with systemd, one has to: > >>>- rely on packagers to generate systemd service files, and/or, > >>>- rely on systemd's support for sysvinit scripts, which > >>> > >>>In the later case, one just has to read: > >>>http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ > >>>to get very, very scared > >>> > >>>Among the implications of this, the old standby of installing > >>>software from upstream (bypassing packaging), has just gotten a > >>>lot riskier. > >>Interesting, since I posted this, a bunch of people have jumped on > >>my comment that relying on packagers and systemd to support sysvinit > >>scripts seems increasingly risky, but... > >> > >>Not a single person has commented on the observation that upstream > >>developers, at least of core server applications, are thoroughly > >>ignoring systemd. > >No one commented because that's false. > >I also guess that you will use anyone response to later justify > >"see, it try to force its way by forcing people to > >integrate with systemd". Either way, that's gonna be used > >as a way to criticize. > > False, how? the whole part that you erased showed there is a few upstreams that care about integration with systemd at the source code level. Ie, using features of systemd ( journald, socket activation ), rather than just providing a .service file. > I went through the release notes, install instructions, > support wikis, source trees, and did some googling for good measure, > and all that I found re. systemd scripts for pretty much the most > popular server-side programs were a few emails in the Arch users > list about how to get these things working w/ systemd. Now, if you really want to see how much do ship a unit file, i suggest using proper tools, like : http://code.openhub.net/ Look for ExecStart= Now, the problem is that the search engine do give around 16 millions of matches, because it also include the result of various distribution, and I guess duplicate and fork, so you would surely have to filter. But looking at the 200 seconds first results, this doesn't seems to be full of completely wrong results. -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141118001418.ga16...@gmail.com
Re: Installing an Alternative Init?
On Tue, Nov 18, 2014 at 12:41:14AM +0300, Reco wrote: > On Mon, Nov 17, 2014 at 07:15:38PM +0100, Ludovic Meyer wrote: > > On Mon, Nov 17, 2014 at 06:29:24PM +0300, Reco wrote: > > > Hi. > > > > > > On Sun, Nov 16, 2014 at 03:48:34PM +0100, Ludovic Meyer wrote: > > > > On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote: > > > > > As much as I dislike systemd, I'm not sure that it's a vendor > > > > > conspiracy to "control the Linux ecosystem." Yes, redhat pays > > > > > Lennart Poettering's salary (among others). But... I'm hard pressed > > > > > to see how turning a collection of free distros into functional > > > > > equivalent's of redhat, or increasing the resources applied to free > > > > > distros, is really to their benefit. If anything, it would seem to > > > > > dilute the competitive advantage of paid RHEL. > > > > > > > > > > Personally, I think it's more a matter of one, prima donna > > > > > developer, who has the advantage of a salary, who has a vision and > > > > > design philosophy that he's promoting in a very aggressive and > > > > > single minded way. And he's very overt about it. (Somebody posted > > > > > an email from Poettering last week saying, roughly, 'first we're > > > > > going to get kdbus into the kernel, then we're going to make udev > > > > > depend on it, and then everyone will have to eat systemd to get > > > > > udev.' As I recall, the message closed with 'gentoo, be warned.') > > > > > > > > > > I figure this is more a case of redhat management not wanting to > > > > > tick off valued prima donna, and maybe seeing what he's doing as a > > > > > contribution to the open source community (to date, redhat has been > > > > > pretty good about contributing to the community in lots of different > > > > > ways). Still, if I were in their shoes, I'd be trying to reign the > > > > > guys in. > > > > > > > > Why would the management of a external company care about what > > > > happen in Debian ? > > > > > > Because Debian is upstream for several critical RHEL parts, such as > > > shadow (passwd, useradd and friends). > > > > 1 ( ie shadow-utils ) is not "several". > > Google is your friend. Sorry, could not resist. I spend time to give concrete response. It would be polite to do the same. > > > And by having a critical look at your affirmation, RH is paying a lot > > of upstreams contributors for several critical Debian part : > > - glibc > > Not as of Wheezy. Wheezy uses eglibc. > And, while we're on topic of glibc - RedHat isn't writing new 'Modern' > libc to replace an old one. Yet. That doesn't change the fact that before, this was glibc, with the infamous Ulrich Drepper, and that eglibc is now merged in glibc. > Next few years we may see systemd-libc if things go as they're going > now. > > > > - gcc > > A GNU project. Not a RedHat pet. Read again : "RH is paying a lot of upstreams contributors" GCC was pushed historically by cygnus, and cygnus got acquired by RH. If you look at the committers, you would see lots of people from the company. > > > - util-linux-ng > > A kernel.org project. Not a RedHat pet again. https://git.kernel.org/cgit/utils/util-linux/util-linux.git Look who make release, look where he work. In fact, by that same reasoning, we can say that systemd is a freedesktop.org project, whic is not more controlled by RH than stuff hosted on kernel.org. > > > - kernel > > A joint project, controlled by Torvalds & co. RedHat is one of the few > who's playing a major role there, true. But that role was not enough to > push the most controversial features (kdbus, for example) into the > mainline. Kdbus is pushed by Greg Kroah-Hartman, who is employed by the Linux Foundation. Before, he was working at Novell, and has no link with RH afaik. > > - udevd > > Yup. You nailed that one if we consider latest udev development. It took > a merging into systemd to became that way. Mhh no. http://blog.bofh.it/debian/id_442 Looking at the graph made by the debian maintener, we can see that more than 95% of the system have it installed since 2008. > Keep shooting, and you may score a couple of more hits ;) That's not a constest, I am not keeping score. > > > to name a few. I
Re: init scripts [was: If Not Systemd, then What?]
On Mon, Nov 17, 2014 at 02:56:20PM -0500, Miles Fidelman wrote: > >Given all the talk about not being able to influence upstream, it > >occurred to me to actually take a look at which of the major > >applications I rely on actually come with native systemd service > >scripts. I just went through the documentation, and in some cases, > >the source trees, for the following: > >bind9 > >apache > >sympa > >mailman > >mysql > >mariadb > >postgres > >postfix > >spamassassin > >amavisd > >clamav > > > >Most come with sysvinit scripts, several come with their own > >startup scripts (e.g., apachectl) that get dropped into rc.local. > >Not a one comes with a native systemd service file (even though, > >when you search through the mysql documentation it tells you that > >oracle linux has switched to systemd). > >So... with systemd, one has to: > >- rely on packagers to generate systemd service files, and/or, > >- rely on systemd's support for sysvinit scripts, which > > > >In the later case, one just has to read: > >http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ > >to get very, very scared > > > >Among the implications of this, the old standby of installing > >software from upstream (bypassing packaging), has just gotten a > >lot riskier. > > Interesting, since I posted this, a bunch of people have jumped on > my comment that relying on packagers and systemd to support sysvinit > scripts seems increasingly risky, but... > > Not a single person has commented on the observation that upstream > developers, at least of core server applications, are thoroughly > ignoring systemd. No one commented because that's false. I also guess that you will use anyone response to later justify "see, it try to force its way by forcing people to integrate with systemd". Either way, that's gonna be used as a way to criticize. > So tell me again about all the great features > that are in such demand, that systemd is a solution for? Most of the features do not requires anything upstream. For example : - being able to autorestart when crashed. Done on the distribution side, and usually, that's a policy left to the admin, not upstream - limiting the service with cgroups. Again, dependent on the installation, so left to the admin. - limiting the access with namespaces. Again, depend on the setup, so left for the admin. - starting on demand, that can be achieved with either xinetd protocol ( ie, reading stdin, writing stdout instead of a socket ), so no need here. - clean environment, that's not a feature that requires any patch upstream - journald integration, again, most software do use syslog, so no special need to have something that work. There is a few feature that requires any upstream patches. 1) socket activation using the systemd way ( ie, not xinetd ) 2) using journald to have more metadata that regular syslog 3) notifcation protocol and automated restart > Where's > the demand? Maybe upstream knows something that seems to elude > systemd proponents? Apache has support as a module in trunk : https://httpd.apache.org/docs/trunk/mod/mod_systemd.html There is support for journal too, see mod_journal. And also see https://github.com/apache/httpd/commit/9e6638622be042eb00af5234a48049f7b5487a15#diff-92a02cae0d4feb2dfea5d1532ba1b977 for support directly in apache. HAProxy do have some support for integration https://github.com/jvehent/haproxy/blob/master/src/haproxy-systemd-wrapper.c Php-fpm does too : http://thanatos.be/2014/04/12/php-fpm-ondemand.html Nodejs has a module for nodejs application: https://savanne.be/articles/deploying-node-js-with-systemd/ Docker has support for it in various place ( socket activation, support in libcontainer ), and I could surely find lots of core stuff and newer code that do have native support. Dovecot have support for it, there is a service file : http://hg.dovecot.org/dovecot-2.2/file/8973329d1ceb/dovecot.service.in There is support for it : http://hg.dovecot.org/dovecot-2.2/file/8973329d1ceb/src/master/service-listen.c There is the upstream of mdadm who even wrote 2 articles on how to do it for nfs : http://lwn.net/Articles/584175/ http://lwn.net/Articles/584176/ Older software are just integrated with xinetd do not need anything. So for example, openssh already support socket activation like it does for xinetd. Had you done your homework and spent 5 minutes double checking your affirmation, you would surely have found the same links as me. just search for HAVE_SYSTEMD on github, bitbucket, etc. And to show there is demand, you can even look on modern configuration tools and you can see they all support to configure systemd : To give the 4 most spoken of at the moment : - ansible https://github.com/ansible/ansible-modules-core/blob/devel/system/service.py#L396 - chef http://www.rubydoc.info/github/opscode/chef/Chef/Provider/Service/Systemd - puppet https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/service/systemd.rb -
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Mon, Nov 17, 2014 at 08:44:06AM +0900, Joel Rees wrote: > One thing at a time. > > On Mon, Nov 17, 2014 at 1:23 AM, Ludovic Meyer wrote: > > [...] > > Your definition of mainstream is strange. > > What's strange about it? Do I need to provide a link to the dictionary > for you for that? I assume not. > > Given a community, there is a mainstream within that community. Well, the point is "what is the community" exactly. Not the community in general but the community you are refering. As it could be "debian users", "all regular linux distro users" ( by regular, I mean desktop/server ), or all linux users ( ie counting embedded appliance ? ), or do we count android as well ? if we go just by the number, do we count users or systems, especially in the light of amazon/yahoo/google/facebook server, who likely have combined more server than there is desktop users of linux ( see a estimation in 2009 http://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-servers/ ) > We have a community of users of Linux-kernel OSses that provide, > without excessive effort, command-line shells, full C compiler suites, > administrator access to the device owner, etc. So your definition is the community of people who are root on a linux system. No problem, but that's not exactly clear. > (Sure, Android has No-root Debian and Terminal-IDE, but those are > third-party apps and don't give true administrator access. The sdk is > not something mainstream Android users can figure out without a lot of > effort, and takes a separate machine. Thus, Android is outside the > domain of discussion, and I shouldn't have had to explain why. Unless > you think that Linux OSses should start limiting the device owner from > doing things like adding users and changing the unit infrastructure, > in which case, the reason we can't communicate is clear.) > > Now, you note that Fedora claims in the range of a million users. Even > if their estimates are an order of magnitude high, that's hundreds of > thousands. > > How can that not be mainstream? Sure, so then Debian waited 3 years after the systemd hit the mainstream, if you consider Fedora to be mainstream. Therefore, your request of waiting was fullfilled. > Or are you under the misapprehension that there is only one > mainstream? Fedora and Debian are the mainstreams of what most of us > consider the Linux community. (Ubuntu being part of the greater Debian > community and Cent being part of the greater Fedora community.) You have been using the word as singular, so I was wondering which one you have been using. So based on the definition everybody will understand, Linux itself not being mainstream > Now, before you throw up any more quibbles, what I am talking about > when I say mainstream users is those users who have not specifically > chosen to be part of an experiment who are being dragged into an > experiment. The whole free software movement is mostly experiments. Experiment in the governance at the internet age, in term of software methodology, in term of research. There is people trying new things. The kernel itself is always evolving, getting new features, etc. > Except you'll now point out that Fedora is the "cutting edge" of Red > Hat's stuff, which is ignoring the issue. And Fedora has rawhide, and > Debian has sid, which is ignoring the issue. > > sid is locked into the future of stable, just like Rawhide is locked > into the future of Fedora. The release schedule does not allow for > major changes to be unrolled easily. Anything that gets accepted into > sid and passes into testing gets into stable, unless a lot of people > get excited during the testing phase. > > Now, is systemd a major change or isn't it? > > If you ask Poettering when he wants to sell systemd, it's a MAJOR > improvement. If you ask systemd proponents when they are sandbagging, > NO! NO! It's NOT a major change. (Sorry about the shouting, I'm just > describing how it looks to me. It does look like you guys are being > emphatic.) It depend on how you measure it. Number of impacted packages ? Number of impacted users ? Change of the name of the software, versionning ? Debian did switch to parralel init, was it a major change ( as it required to fix all initscript for lsb ) Gnome 3, kde 4, grub2, was it major change ? Xfree to xorg ? Glibc to eglibc ? Linux 2.0 to 2.2 to 2.4 ? Why none of this had a alternative ? There is lots of major change anytime and since the start of Debian. And again, you keep using word as if it was ginving any meaning to what you propose but there is no actionable items at all. > If it's a major change, it needs more time, and, I'm asserting, the >
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sun, Nov 16, 2014 at 04:09:52PM -0500, The Wanderer wrote: > On 11/16/2014 at 02:51 PM, Ludovic Meyer wrote: > > > On Sun, Nov 16, 2014 at 01:28:35PM -0500, The Wanderer wrote: > > [about the Linux kernel developers] > > >> They do, however, maintain their external interfaces - rigidly so, > >> sometimes to what others might call the point of insanity. An > >> intentionally user-visible API from the Linux kernel will > >> essentially never change, and if an exception to that is ever made, > >> it will be announced *years* in advance. That is one reason why > >> they try to be *VERY* careful to get the user-facing interface > >> "right", at least on some basic level, before ever pulling it into > >> a released kernel. > >> > >> The kernel interfaces which kernel modules need to use are > >> kernel-internal interfaces. > >> > >> The systemd interfaces described on the page you link to appear to > >> be systemd-external interfaces. > > > > I know the difference, and I know this is just some tradeoff, there > > is advantages and disadvantages on doing that, and if I was cynical, > > I would postulate that companies like redhat do push for that model > > of internal/external interfaces in the kernel, because this give a > > reason to take entreprise distributions. ( ie, SLES, RHEL do have a > > stable promise API for each release like Windows do, because > > customers do pay also for that ) > > > > My point is not that kernel or systemd devs are right or wrong. But > > the point is that people who complain that systemd do not have a > > internal interface yet forget that kernel do not have one since the > > start and will not have in a near future. > > Er... were people complaining that systemd does not have a stable > internal interface? > > I thought (given the context of that linked-to page) that the complaint > was that systemd does not have a stable *external* interface. I think it does. The real question is - is this interface sufficient - is the boundary the one we agree on > With possible room for dispute about what constitutes an "interface", > what qualifies as "stable", and maybe even what counts as "internal" vs. > "external"... but I didn't see anything that I recognized as being a > complaint about systemd's internal interfaces. Let's take the one about logind. What people complain is that logind requires systemd as pid1, and the reason about this is because logind requires the internal and non stable interface of systemd, otherwise, someone would be able to run it with another init, provided it implement the stable interface (this particular interface that do not exist). Or people do complain they cannot replace or remove journald. Again, because there is no separation between the 2, because there is no documented separation ie a external interface. I hope this clarify my point, but we seems to agree on this, if I read well what you said just after. > No one is even trying to implement something outside of the systemd > project that talks to systemd's internal interfaces directly, AFAIK - > unless systemd-shim does, but I didn't think systemd-shim talked to > systemd itself at all, just to other tools provided by the systemd > project. > > And if the interfaces which those tools use to talk to > systemd-the-init-system are considered "internal" interfaces, which is a > position for which an argument could be made, then that would simply > bring up the argument that since those are separate tools the interfaces > between them should be considered external to each tool. Whether or not > that's a reasonable argument, and the extent to which it might be > possible to treat those interfaces that way, could be a discussion worth > having - but having it would require *getting* to that point first. > > -- >The Wanderer > > The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man. -- George Bernard Shaw -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117205859.gc31...@gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sun, Nov 16, 2014 at 08:29:28PM -0500, Marty wrote: > On 11/16/2014 03:32 PM, Ludovic Meyer wrote: > >On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote: > > >>My point is that in a modular design nothing should be so entrenched > >>as to be irreplaceable. Absence of an alternate should not normally > >>indicate impossibility of an alternate, but some discussions I've > >>read about logind, udev and dbus are enough to raise serious > >>concerns. > > > >The problem is that, without any action, the difference between "nothing > >can be replaced" and "it can be replaced" is purely theorical. > > The problem is very real, but there seems to be no agreement about > solutions, which by itself is evidence of a problem. There is not even anyone keeping a list of the solution or even the problem. Even the basis are not done. If you truly want to iterate on a solution, you should start doing it and document it. > Now you > >can discuss for years in theory, > > In fact, people have been discussing this problem for years. And how did it change anything ? It didn't. So what make you think that yet another year is gonna result in something ? I do not want to be too critical, but that's the exact problem that the troll in the Hobbit face, by discussing endless on how to cook the dwarfs, they get petrified. And maybe the time to test and get something wrong, as itcan hardly be slower than discussing. The whole agile methodology. > if this doesn't result in any practical > >outcome, you have just stresstested the mailling lists software. > > Until there's a rough consensus and a clear way forward, I don't > think many people will commit to specific solutions. There are also > unknowns like kdbus, to further complicate the matter. "Talk is cheap", as Linus said. You seems to be in favor of design by comitee, but this doesn't seems to work for now. > >>People who just say, "write your own, it's all FOSS" are missing the > >>point, I think. Debian is not one guy working in his mom's basement. > >>It's one of the world's largest software projects. When Debian is > >>stumped, because its best developers and upstreams are caught in the > >>entanglement hairball, and see no clear way out, the it's clear case > >>of *Houston we have a problem.* > > > >That's a interesting point, because with all those brillant minds, > >a vast majority do not even seems to care about this > >"entanglement hairball". Maybe it is time to admit you do not > >know the whole details and accept that if developpers do not care, > >then they are maybe right in doing so ? > > > >Especially since you have been unable to give any technical reasons > >to why you do not want it, and how you would proceed. > > For you, I would start by explaining the Unix Philosophy and how it > is a critical aspect of Debian's design: > > http://en.wikipedia.org/wiki/Unix_philosophy That's not a technical reason. > Then I would proceed to explain how various aspects of systemd > conflict with this, causing said hairball. Finally, I would explain > (to the best of my ability) how the entanglement issue precludes a > quick resolution, and the delay does not indicate lack of interest. And how would that be a technical reason ? If you disagree with the philosophy, that's not a technical problem. That's just a opinion. Show a real technical issue, not "here is the design decided 20 years ago and that was ignored by several others components". heck, even in 1989, people wrote "the unix hater handbook" to explain how the philosophy is wrong. For example, the example of cat not being following this design anymore. No one throw a fuse over it, despites being here, documented and visible by all since more than 20 years. And I know Debian has popularized the idea of "release when it is ready", but that's also the exact definition of vaporware. And people do not even have a estimation of the work. Not knowing what solution to choose do not preclude from saying the time one of them would take. In fact, it would even help to choose. > >In fact, a quick google check would even give you the required > >knowledge of why it is better to link : > >http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html > > > >You can compare the code with "link to systemd library" vs "cut and > >paste in every source code". As a exercise, you can > >surely add "use dlopen()" and see which one is simpler and easier to maintain > >in the long term. >
Re: Installing an Alternative Init?
On Mon, Nov 17, 2014 at 06:29:24PM +0300, Reco wrote: > Hi. > > On Sun, Nov 16, 2014 at 03:48:34PM +0100, Ludovic Meyer wrote: > > On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote: > > > As much as I dislike systemd, I'm not sure that it's a vendor > > > conspiracy to "control the Linux ecosystem." Yes, redhat pays > > > Lennart Poettering's salary (among others). But... I'm hard pressed > > > to see how turning a collection of free distros into functional > > > equivalent's of redhat, or increasing the resources applied to free > > > distros, is really to their benefit. If anything, it would seem to > > > dilute the competitive advantage of paid RHEL. > > > > > > Personally, I think it's more a matter of one, prima donna > > > developer, who has the advantage of a salary, who has a vision and > > > design philosophy that he's promoting in a very aggressive and > > > single minded way. And he's very overt about it. (Somebody posted > > > an email from Poettering last week saying, roughly, 'first we're > > > going to get kdbus into the kernel, then we're going to make udev > > > depend on it, and then everyone will have to eat systemd to get > > > udev.' As I recall, the message closed with 'gentoo, be warned.') > > > > > > I figure this is more a case of redhat management not wanting to > > > tick off valued prima donna, and maybe seeing what he's doing as a > > > contribution to the open source community (to date, redhat has been > > > pretty good about contributing to the community in lots of different > > > ways). Still, if I were in their shoes, I'd be trying to reign the > > > guys in. > > > > Why would the management of a external company care about what > > happen in Debian ? > > Because Debian is upstream for several critical RHEL parts, such as > shadow (passwd, useradd and friends). 1 ( ie shadow-utils ) is not "several". And by having a critical look at your affirmation, RH is paying a lot of upstreams contributors for several critical Debian part : - glibc - gcc - util-linux-ng - kernel - udevd to name a few. I could name a few non critical stuff, from gnome, openjdk. So I am not sure that your point is valid. Given the size of Redhat, I also suspect that having someone working on shadow-utils wouldn't be a problem. Judging by SEC fillings, public information, there is around 6900 people. 1 more coder is not a stretch at all. > And, curiously enough, systemd's > goal is to replace those parts (see "Revisiting How We Put Together Linux > Systems" at http://0pointer.net/blog ). > Apparently, management doesn't like to be left out of control :) This is free software, there is no way to be left out of control. That's the whole point of the movement, provided you can code of course. A lot of people seems to totally forget that point. > And of course, another distribution = testing a product for free. I wonder how, since Debian is lagging so much behind that even RHEL 7 is released with systemd. I wonder even why they still have jobs posting for QA people if all is needed is to have users of others distributions. > > People keep wanting the project to be free of corporate influence, but > > it seems that some wouldn't be against having a bit of corporate influence > > if the > > influence was in the way they want.. > > > > > Given that RHEL's main selling points are enterprise > > > capabilities, quality control, and (for the government market) > > > security accreditation and lots of support, I'd much rather see > > > diversity and weak code spread across competing distributions. > > > > Canonical was criticized for keeping their code for their ( mir, unity ), > > and Redhat would be criticized for not keeping the code only for them. > > No. RedHat is criticized for pushing their code to everyone and their > dog. People keep saying that, but none show no conclusive proof. Just stating it doesn't make it true. And it doesn't resist simple inquiry such as: "if they wanted to push it everywhere, why would it be non portable to BSD ?" We go back to criticize everything that happen, that's getting old. And kinda poisonous, looking at the people leaving TC or Debian or maintainership. > And it started way before systemd (dbus, hal and pulseaudio to > name a few). At least Canonical keeps their 'innovations' to themselves > last time. So you agree with me. If you share, you are criticized, if you don't, y
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sun, Nov 16, 2014 at 01:05:08PM -0500, Marty wrote: > On 11/16/2014 05:26 AM, Laurent Bigonville wrote: > >Le Sat, 15 Nov 2014 20:21:49 -0500, > >Marty a écrit : > > > >>On 11/15/2014 06:49 AM, Andrei POPESCU wrote: > >[...] > >>> > >>> At least some of people rejecting systemd demand that it be removed > >>> completely, including libsystemd. How is it pro-choice to forbid me > >>> from being able to use a software at its full potential? > >> > >>For me it's more about being unable to remove it completely, because > >>of vendor lock-in. There's no technical reason that I know of that > >>anything in userspace cannot modular, and replaceable, so when > >>something cannot be replaced then an alternative must be provided, or > >>else my default assumption is that vendor lock-in is in effect. > > > >Well, yes there are technical reasons why you cannot remove a library > >package when you have symbols provided by this library used in an > >executable. You can still recompile the package and remove some > >configure flag if you want to remove this dependency. > > > >OTHO there is no technical reasons that I can see, to completely remove > >libsystemd package. You have tenth of other libraries on your system > >that, like libsystemd, turn them self into a noop if some some > >functionality or daemon are not enable. I'm thinking here for example > >about libselinux and libaudit (both also written by Red Had and the > >NSA, OMG!!!11), and yet I fail to see any outcry here... > > > >So as long as you cannot _prove_ that having libsystemd installed on > >your machine is causing any issues, I'll personally mentally classify > >your request as "I don't want to see any packages containing the > >"systemd" string on my machine" and redirect these to /dev/null. > > Except that proponents seem more prone to avoiding the hairball > issue by just covering their eyes. ;) > > My point is that in a modular design nothing should be so entrenched > as to be irreplaceable. Absence of an alternate should not normally > indicate impossibility of an alternate, but some discussions I've > read about logind, udev and dbus are enough to raise serious > concerns. The problem is that, without any action, the difference between "nothing can be replaced" and "it can be replaced" is purely theorical. Now you can discuss for years in theory, if this doesn't result in any practical outcome, you have just stresstested the mailling lists software. > People who just say, "write your own, it's all FOSS" are missing the > point, I think. Debian is not one guy working in his mom's basement. > It's one of the world's largest software projects. When Debian is > stumped, because its best developers and upstreams are caught in the > entanglement hairball, and see no clear way out, the it's clear case > of *Houston we have a problem.* That's a interesting point, because with all those brillant minds, a vast majority do not even seems to care about this "entanglement hairball". Maybe it is time to admit you do not know the whole details and accept that if developpers do not care, then they are maybe right in doing so ? Especially since you have been unable to give any technical reasons to why you do not want it, and how you would proceed. In fact, a quick google check would even give you the required knowledge of why it is better to link : http://spootnik.org/entries/2014/11/09_pid-tracking-in-modern-init-systems.html You can compare the code with "link to systemd library" vs "cut and paste in every source code". As a exercise, you can surely add "use dlopen()" and see which one is simpler and easier to maintain in the long term. Then it will be your turn to explain why it is better to cut and paste or link statically the library, or why it is better to have to patch every upstream to use dlopen(). And once you will have been able to justify that on a technical level, maybe people will start to listen to you. For the record, see also the discussion on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555980 -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116203224.gg25...@gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sun, Nov 16, 2014 at 01:28:35PM -0500, The Wanderer wrote: > On 11/16/2014 at 11:23 AM, Ludovic Meyer wrote: > > > On Sun, Nov 16, 2014 at 09:43:23PM +0900, Joel Rees wrote: > > > >> I have been informed off-list that some might misinterpret > >> something I wrote here, so I will attempt to clarify a few things. > >> > >> On Fri, Nov 14, 2014 at 8:59 AM, Joel Rees > >> wrote: > > >>> This all would have been okay for them, if they had followed > >>> proper engineering (management) principles. As long as they were > >>> an independent maverick, they could do what they want. That was > >>> correct, that was good. > >> > >> I want to repeat that. As long as they kept their work out of the > >> mainstream, it was no problem. > > > > Your definition of mainstream is strange. So far, I didn't see > > systemd being on something else than Linux, and GNU/Linux is not > > mainstream ( android is, but systemd is out of android ). > > > > So they kept it out of mainstream, unless you define mainstream as > > "being used by users", in which way I would love to see how you get > > user feedback without having users in the first place. > > I suspect that he meant "the mainstream of Linux", which is reasonable > considering the scope of the discussion. Sure, and what does he mean by that ? because I suspect also that Android, being Linux based, is not the mainstream he is speaking about. So is Debian more mainstream that Ubuntu ? Is Debian more mainstream than Mageia or Opensuse ? if he want to be clearly understood, and I think we all want that, he must be a bit more clearer in what he say. > >> They could refine their API as they went and the repercussions were > >> limited to their own source tree. That means they could redefine > >> the API as necessary without interfering with the day-to-day > >> operations of thousands, or even hundreds of thousands of users. > >> > >> The more users you have, the harder it is to fix an API error. > > > > yeah, and that's why there is a table : > > http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ > > > > now, the linux kernel do not have such table, and prevent anyone > > from writing a out of kernel module due to that, despites requests. > > One important distinction: > > The Linux kernel recognizes and maintains a separation between internal > and external interfaces. > > They refuse to stabilize and fix on, or I think even particularly to > document (beyond the source code itself), the internal interfaces. Doing > so would constrain them from making structural and design improvements > when and as they think that is necessary. I know the arguments, but this doesn't contradict the fact that there is demand for such interfaces. This is also something that windows, solaris or mac osx offer, and that help hardware vendors to support their systems, and companies to offer software (firewall, antivirus are the example that came to mind, but i am not dealing with windows anymore). Now, that's indeed a costly approach due to the reduced agility, and while I am sure this can be surely automated, I can see why kernel coders do not want to take care of that ( coders in general would prefer not care of boring stuff and constraints, as we can see in the free software world, who is hard to consume unless you have group between users and coders to make thing usable ). > They do, however, maintain their external interfaces - rigidly so, > sometimes to what others might call the point of insanity. An > intentionally user-visible API from the Linux kernel will essentially > never change, and if an exception to that is ever made, it will be > announced *years* in advance. That is one reason why they try to be > *VERY* careful to get the user-facing interface "right", at least on > some basic level, before ever pulling it into a released kernel. > > The kernel interfaces which kernel modules need to use are > kernel-internal interfaces. > > The systemd interfaces described on the page you link to appear to be > systemd-external interfaces. I know the difference, and I know this is just some tradeoff, there is advantages and disadvantages on doing that, and if I was cynical, I would postulate that companies like redhat do push for that model of internal/external interfaces in the kernel, because this give a reason to take entreprise distributions. ( ie, SLES, RHEL do have a stable promise API for each release like Windows do, because customers do pay also for that ) My point is not that kernel or systemd devs are right
Re: If Not Systemd, then What?
On Sun, Nov 16, 2014 at 06:08:48PM +, Martin Read wrote: > On 16/11/14 17:33, Laurent Bigonville wrote: > >Are you aware that this is the approach that systemd and upstart have > >taken, right? > > > >1) Both systemd (PID1) and upstart are drop-in replacement for the good > >old SysVinit as they both support the common "standard" that are LSB > >scripts (A really good share of the existing LSB initscripts in the > >debian archive are just working out of the box). > > Well. They're (mostly) a drop-in replacement for sysvrc and its > supporting tools. They're certainly not a *drop-in* replacement for > *sysvinit*, because they don't support all of sysvinit's interfaces; > specifically, they don't support /etc/inittab. > > Luckily (for some values of lucky), /etc/inittab was such a terrible > interface (it's unpleasantly reminiscent of Angband's monster, item, > etc. databases) that it seems even most people who prefer sysvinit > to systemd or upstart were using a factory-default /etc/inittab. Writing a generator would be trivial. http://www.freedesktop.org/wiki/Software/systemd/Generators/ No one seemed to care enough for writing one however, but reading the file and generating a unit file ( with the automated restart behavior ) is easy to do. -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116192021.ge25...@gmail.com
Re: init scripts [was: If Not Systemd, then What?]
On Sun, Nov 16, 2014 at 11:50:25AM -0500, Miles Fidelman wrote: > Given all the talk about not being able to influence upstream, it > occurred to me to actually take a look at which of the major > applications I rely on actually come with native systemd service > scripts. > > I just went through the documentation, and in some cases, the source > trees, for the following: > > bind9 > apache > sympa > mailman > mysql > mariadb > postgres > postfix > spamassassin > amavisd > clamav > > Most come with sysvinit scripts, several come with their own startup > scripts (e.g., apachectl) that get dropped into rc.local. Not a one > comes with a native systemd service file (even though, when you > search through the mysql documentation it tells you that oracle > linux has switched to systemd). > > So... with systemd, one has to: > - rely on packagers to generate systemd service files, and/or, > - rely on systemd's support for sysvinit scripts, which > > In the later case, one just has to read: > http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ > to get very, very scared In practice, what would be broken ? Taking the list : - the fact that direct invocation is deprecated is a good thing, since this was previously broken. Starting stuff directly from the script mean that your environment leak in the daemon environment, which is a source of fun bug ( like sorting in php depending on the locale, and the locale not being always C, something that US people tend to forget ). It also help when you are using SELinux or another MAC, since the domain of the admin do not leak to the daemon, and things are clearly separated. - LSB information have to be correct anyway in Debian, or you would have bug anyway. LSB is also old enough to have no excuse to have transitionned, and is a standard. See https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot - timeout that would block boot are a bug, since this mean that your server could not boot if the timeout was undefinite. Again, i can't see why a correct execution would depend on "not booting due to 1 system blocking everything", especially in the list of service you gave. - again, clean env just requires you to make sure that what is needed to be set is present. That's a question of correctness, and I think no one will advocate that being correct is a regression. - none of the script you gave seems interactive, and that's kinda already causing issue anyway ( for example, when automating restart accross a cluster with a tool like ansible, or when you are not near the keyboard when the server reboot and the script start at boot ). - additional verbs are supported on service binary, not on the script level, at least on Centos. If that's misisng, I am sure that can be done on Debian as well, if that's not done already. - stopping non running service seems again a weird things to do. I do not see anything that would depend on this behavior to be correct, as that's more "we stop something that said to be stopped, but wasn't". None of the service you gave rely on this behavior, and I would be interested into getting precise details on what service would need this. - run levels support is limited, but it still exist. Again, explain what is your usecase, so we can see if that's broken or not ( because you do not test and do not give details ). Migration to target is likely not hard ( just different directory to make symlinks ), so i do not see why you would fear it. - chkconfig is already returning misleading information, due to a complete lack of standard on the return code of the initscript, despites LSB trying to clean that mess. Again, it will just be broken in a different way. At least, mediating the interaction with systemd make script more reliable once they use it, because there is no local variation in return code. - next one is again on runlevels. Please tell what local variation you have, then people can judge if that's a reason to fear or not. Otherwise, that's just spreading FUD since most people do not have complex runlevels systems, as "running/not running" is enough for most cases I did see. - early boot scripts would be the biggest challenge for your setup I guess. While you didn't gave any details , you seems to use some customs script instead of Debian, so you would have to change that integration. Yet, without giving the usecase, no one know and maybe I am wrong. If your setup cannot be handled by Debian regular script, maybe the Debian developpers would be interested to fix that use case. And last: - no real time privs. No service you gave use that, but then there is workaround. At most 1 line to add and a reboot. That's not what I would qualify as a cause of fear. > Among the implications of this, the old standby of installing > software from upstream (bypassing packaging), has just gotten a lot > riskier. What is the risk ? before, you were on your own, now, you would be on your own. Differenc
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sun, Nov 16, 2014 at 09:43:23PM +0900, Joel Rees wrote: > I have been informed off-list that some might misinterpret something I > wrote here, so I will attempt to clarify a few things. > > On Fri, Nov 14, 2014 at 8:59 AM, Joel Rees wrote: > > On Thu, Nov 13, 2014 at 11:04 PM, Tanstaafl > > wrote: > >> On 11/12/2014 5:18 PM, Andrei POPESCU wrote: > >>> On Mi, 12 nov 14, 15:43:09, Tanstaafl wrote: > > Sounds good to me, but in reality, since the default *and only* init > system for the last very many years was Sysvinit (this extremely salient > point seems to be completely and totally lost on the systemd > proponents), I think only systemd and sysvinit need to be there... but > allowing for additions once required bugs implementing them are resolved > as fixed. > >>> > >>> You're forgetting about: > >> > >> It doesn't matter Andrei... > >> > >> 1. The *default* is what we are discussing. > >> > >> The *default* for Debian has been sysvinit since - forever? > >> > >> 2. The systemd proponents pushed to make systemd the *new* default - a > >> massively major change from *all* previous releases since... forever? > >> > >> 3. A bug was opened to allow for the ability to allow a clean install to > >> be performed with systemd on wheezy, while sysvinit was still the default. > >> > >> It should have been made mandatory that the systemd folks get this bug > >> fully resolved and functional *on wheezy*, *and* commit to maintaining > >> this ability in jessie, as a pre-condition to even getting the question > >> of a change of the default init system for jessi on the ballot. > >> > >> Anything else, as I said, makes no sense. > > > > To explain to the systemd advocates who refuse to understand the > > engineering questions, this is the real engineering mistake in > > systemd. > > > > The engineering question keeps getting sidetracked by people who > > assert that we are talking about technical details, and then proceed > > to question (foolishly) the necessity of modularity, or (rightly) the > > meaning of modularity, etc. That all was and is still relevant, but if > > proper engineering principles had been followed in bringing systemd > > in, the open development practices our larger community claims as its > > reason for existence would have taken care of the technical details. > > > > Maybe it would help if I said, "engineering management", instead of > > just "engineering", although you really can't separate management from > > engineering. > > This person says that I have misrepresented the Fedora community's > reaction in my description of events. And you still do. Proofreading and giving links is not so hard, but way harder if that mean discovering that you may base your ideas on wrong premises. > This is not an attempt to be a linear history of systemd adoption in > Fedora. It is simply intended as a few of my observations there when I > was a user, and from here in the two years since I left. > > > It was clear much longer than four years ago how deeply the changes > > would effect the infrastructure which defines the system, and on which > > the stability of the system depends. Every daemon package would be > > effected, even if the systemd project had restrained themselves to > > working only on the init part of the infrastructure. Every daemon > > package needed to be fixed to the new interface, and tested under it. > > (Many still need that.) > > This is not disparaging, it is acknowledging reality. If I were to > develop an alternative init, add full daemon/service management, tie > it to device management, login management, error logging, etc., the > result would impose the same level of re-implementation and testing > burden across the OS. > > I wouldn't do it that way, of course, but that's the level of > engineering cost the approach they take incurred. You say that every daemon need to be fixed for the new interface, but then either things are broken, and so, you should be able to show bugs reports ( from mageia, from arch, from opensuse ), or they are not and so you cannot really show they are not broken. It was a explicit goal of system to still support regular scripts, and there isn't a flood of debian bug reports to say that it not working. > > They didn't, of course they didn't, > > ... restrain themselves, that is. > > > they've admitted many times that > > the init system was not their ultimate target. > > Links to Poetterings blog have been posted. It's hard to assume that > he was intending to speak in the absurd, or that he was > misrepresenting the goals of the project he leads. > > > Therefore, every package that uses or provides authentication got > > entangled in the changes and needed both careful editing and extensive > > testing. The testing is still to be completed, because we are not > > talking about context-free grammar simplicity here in any of the > > parts. > > I know that the systemd proponents want to claim that
Re: Installing an Alternative Init?
On Sat, Nov 15, 2014 at 09:41:23PM -0500, Miles Fidelman wrote: > Marty wrote: > >On 11/15/2014 07:45 PM, Ludovic Meyer wrote: > >>On Wed, Nov 12, 2014 at 12:26:26AM -0500, Marty wrote: > >>>On 11/11/2014 02:16 PM, Brian wrote: > >>>>On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote: > >>>> > >>>>>On 11/11/2014 12:07 PM, Laurent Bigonville wrote: > >>>>>> > >>>>>>There are no functional differences between an installation with > >>>>>>sysvinit-core out of the box or an install where sysvinit-core is > >>>>>>installed later, this is a fact. > >>>>>> > >>>>>>Allowing the user to choose this at install time from the > >>>interface is > >>>>>>a "nice to have" feature (wishlist bug) not a RC bug like you were > >>>>>>claiming earlier. > >>>>> > >>>>>There is a potential practical consequence of not advertising an > >>>>>init alternative during setup. It makes users less likely to be > >>>>>aware of it, or even aware that the init system has changed. > >>>> > >>>>New users do not need to be be aware of all the background to the > >>>>choosing of a default init. No advertisement is needed. By definition, > >>>>they do not care. They want Debian. Please let them have it. > >>> > >>>They will not care "by definition" only if they are not aware of the > >>>change, and most won't be aware unless they are informed during the > >>>installation. > >>> > >>>>>They won't know they lost the choice they didn't know they > >>>had. Capisce? > >>>> > >>>>What choice have they lost? > >>> > >>>They lost an *informed* choice. I think the installation program > >>>should not take sides but just inform the user. A choice that the > >>>user is not aware of is the same as no choice, and is potentially > >>>coercive and disrespectful. It makes Debian seem partial to Red > >>>Hat's business plan to take over the Linux ecosystem. > >> > >>If you care so much about Redhat code, maybe you should document > >>yourself, and see there pay coders for glibc, gcc, the kernel ( a > >>ton of them, according to lwn and linux fundations reports ), on > >>coreutils, gnome, kde, php, python, openssh, etc, etc. > >> > >>>> Whatever it was, it didn't exist as you imply > >>>> in Wheezy. > >>> > >>>It wasn't an issue in Wheezy because the default init option had not > >>>changed from the previous release, and any release before that. > >>> > >>>>>They won't know, that is, until it bites them somewhere down the > >>>>>line. Then they won't know where to look or who to blame, and will > >>>>>blame Debian. > >>>> > >>>>What bites them? > >>> > >>>Individually, probably something that requires sysvinit or one many > >>>core services that got replaced. Collectively, getting trapped by > >>>vendor lock-in. > >> > >>You keep using those words, but you do not seems to use them correctly. > >>If the same system is present on more than one distributio, that's not > >>vendor lock-in since you can switch distribution and then reuse the same > >>system. > > > >I meant that one vendor seeks to control the Linux ecosystem. > >Whether that plan is viable or even sane, is another issue, but I > >am not eager to see if their plan will succeed or be a guinea pin > >in the experiment. > > As much as I dislike systemd, I'm not sure that it's a vendor > conspiracy to "control the Linux ecosystem." Yes, redhat pays > Lennart Poettering's salary (among others). But... I'm hard pressed > to see how turning a collection of free distros into functional > equivalent's of redhat, or increasing the resources applied to free > distros, is really to their benefit. If anything, it would seem to > dilute the competitive advantage of paid RHEL. > > Personally, I think it's more a matter of one, prima donna > developer, who has the advantage of a salary, who has a vision and > design philosophy that he's promoting in a very aggressive and > single minded way. And he's very overt about it. (Somebody posted > an email fro
Re: Installing an Alternative Init?
On Sat, Nov 15, 2014 at 09:25:01PM -0500, Marty wrote: > On 11/15/2014 07:45 PM, Ludovic Meyer wrote: > >On Wed, Nov 12, 2014 at 12:26:26AM -0500, Marty wrote: > >>On 11/11/2014 02:16 PM, Brian wrote: > >>>On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote: > >>> > >>>>On 11/11/2014 12:07 PM, Laurent Bigonville wrote: > >>>>> > >>>>>There are no functional differences between an installation with > >>>>>sysvinit-core out of the box or an install where sysvinit-core is > >>>>>installed later, this is a fact. > >>>>> > >>>>>Allowing the user to choose this at install time from the interface is > >>>>>a "nice to have" feature (wishlist bug) not a RC bug like you were > >>>>>claiming earlier. > >>>> > >>>>There is a potential practical consequence of not advertising an > >>>>init alternative during setup. It makes users less likely to be > >>>>aware of it, or even aware that the init system has changed. > >>> > >>>New users do not need to be be aware of all the background to the > >>>choosing of a default init. No advertisement is needed. By definition, > >>>they do not care. They want Debian. Please let them have it. > >> > >>They will not care "by definition" only if they are not aware of the > >>change, and most won't be aware unless they are informed during the > >>installation. > >> > >>>>They won't know they lost the choice they didn't know they had. Capisce? > >>> > >>>What choice have they lost? > >> > >>They lost an *informed* choice. I think the installation program > >>should not take sides but just inform the user. A choice that the > >>user is not aware of is the same as no choice, and is potentially > >>coercive and disrespectful. It makes Debian seem partial to Red > >>Hat's business plan to take over the Linux ecosystem. > > > >If you care so much about Redhat code, maybe you should document > >yourself, and see there pay coders for glibc, gcc, the kernel ( a > >ton of them, according to lwn and linux fundations reports ), on > >coreutils, gnome, kde, php, python, openssh, etc, etc. > > > >>> Whatever it was, it didn't exist as you imply > >>> in Wheezy. > >> > >>It wasn't an issue in Wheezy because the default init option had not > >>changed from the previous release, and any release before that. > >> > >>>>They won't know, that is, until it bites them somewhere down the > >>>>line. Then they won't know where to look or who to blame, and will > >>>>blame Debian. > >>> > >>>What bites them? > >> > >>Individually, probably something that requires sysvinit or one many > >>core services that got replaced. Collectively, getting trapped by > >>vendor lock-in. > > > >You keep using those words, but you do not seems to use them correctly. > >If the same system is present on more than one distributio, that's not > >vendor lock-in since you can switch distribution and then reuse the same > >system. > > I meant that one vendor seeks to control the Linux ecosystem. > Whether that plan is viable or even sane, is another issue, but I am > not eager to see if their plan will succeed or be a guinea pin in > the experiment. > > (I would like to see systemd succeed in Debian, however, *without* > sacrificing modularity or user choice. That would be like "embrace > and extend" in reverse, and could serve to protect downstreams.) > > >Being tied to one package format ( and so on the ecosystem around ) would > >be true lock-in. And no one complained that much since Debian existed, > >despites the .deb having a few shortcomings at start, shortcomings that > >were fixed later such as having checksum of installed software, a feature > >rpm had at a time the dpkg didn't ( around 2002, so that's really a old > >stuff ). > > > >>In both cases it could be the result of users being steered to the > >>default init by the installation program, leaving alternatives to > >>rot. > > > >Alternatives will rot if no one use them, so either you recognize than > >no one is interested to use them and it will indeed rot, > >or that the few interested to use them are unable to fill bug reports and > >help the alternatives survives. > > > >Giv
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat, Nov 15, 2014 at 03:43:40PM -0500, Tanstaafl wrote: > On 11/15/2014 7:20 AM, Andrei POPESCU wrote: > > On Vi, 14 nov 14, 08:55:47, Tanstaafl wrote: > >> On 11/14/2014 5:26 AM, Andrei POPESCU wrote: > >>> It was claimed that sysvinit was the default *and only* (emphasis not > >>> mine) init, and therefore no selection was needed, but now that there > >>> are several a selection suddenly is needed. > >> > >> I don't recall claiming that sysvinit was the *only* init, nor do I > >> recall anyone else making such a claim. > > > > https://lists.debian.org/debian-user/2014/11/msg00814.html > > Maybe a language issue? (I'm not a native speaker). > > Nope, that was me and I actually did say it... weird that I didn't > remember saying that... but it doesn't really change anything... That's a attempt at moonlighting people, not very classy. > Just because other init systems exist doesn't mean they were actually > being used, other than maybe just someone toying around. > > Are you seriously suggesting that anything other than a tiny and > insignificant fraction were using anything other than sysvinit (until > systemd came along at least)? > > For fresh installs, given that there is a suitable[1] workaround > > > > how many times does it have to be said - that is not a workaround for a > CLEAN INSTALL. > > > For dist-upgrades, even assuming systems will be switched automatically > > (which is still undecided): > > > > - one can prevent switching by installing sysvinit-core before the > > dist-upgrade step > > - the sysvinit package contains the binary /lib/sysvinit/init which can > > be used with the init= kernel parameter > > - there is a grub patch[3] pending integration[4] to offer an > > alternative sysvinit boot option > > Yes, and how long after upgrading to jessie staying with sysvinit until > things start breaking (most likely subtle breakage, which is the least > desirable on a server). The distinction server/desktop is clearly not relevent. There is huge deployment of Debian desktop, and they do not want subtle breakage anymore than others people. Now, if there is breakage ( so far, you speak of the future ), it will be because no one detected them in the first place, and given the Debian structure, that mean that not enough people were using that setup on testing and/or unstable. For this, there is a few fixes : - find people to test that ( starting by yourself ). If half of the people who rant since a few months on this list were doing tests and filling bug report, this would be rock solid. - automate that testing ( Ubuntu has a lot of ressources on the topic https://wiki.ubuntu.com/Testing/Automation and so does OpenSuse ). - make sure that bugfixes are propagated faster to stable and provides patches and or bugs when stable is here. Now of course, if no one take time to do any of theses, that's gonna cause problem. But that's a problem because people who want the work to happen do not make it happen. ( and no "we do not have time", if people have time to post on ml, they have time to post bug reports ). > > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757298 > > [4] https://lists.debian.org/debian-ctte/2014/10/msg00057.html > > > > The transition plan[5] has been posted on -devel since July with no > > objections. > > Maybe because most debian *users* don't follow the dev list because they > aren't devs... At the same time, most debian users likely do not really care about transition plan and systemd. It was widely published everywhere in March and yet, no one would have cared if this mattered ? And those that care should make the efforts to follow what happen in the distribution, reading one or two time a week the title on a web archive is not a huge time investment. ( at least not more than following this lists and answering on it ) -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116013520.gd22...@gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat, Nov 15, 2014 at 10:05:49PM +0100, Erwan David wrote: > Le 15/11/2014 20:24, Brian a écrit : > > On Sat 15 Nov 2014 at 11:37:14 -0500, Miles Fidelman wrote: > > > >> Brian wrote: > >>> On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote: > >>> > On Vi, 14 nov 14, 08:04:00, Marty wrote: > > By the same token systemd is a major waste with no real gain. It > > duplicates > > equivalent modular alternatives, and also requires unnecessary effort to > > repair damage from excessive coupling. > I challenge you to come up with a configuration that duplicates > systemd's features with a combination of other software. > >> That assumes that one needs or wants systemd's features. > > I rather think Andrei might not regard this as answering his challenge. > > (You also didn't say whether the link's picture made you chuckle :) ). > > > >> For some (many?) of us, systemd represents no gain, and significant > >> operational impact (time required to deal with changes). > > Fair enough, but working within the realities of a situation is also > > part of the deal. The deal for Jessie is systemd. This is not on a take > > it or leave basis; quite a lot of work has been put into ensuring the > > alternatives you want are there. > > > It isq : when you have bugs like > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762623 > Once said "oh it works with systemd", then no more activity on the bug, > nothing. I would suggest to read the url you post. There was a message from the maintainer saying "sorry, i tought I answered, I already reported it to udev, please give more information on the bug". Then indeed, you didn't followed up. > That means that practically, systemd is de facto compulsory. Not the > default, the only way allowed. > > So it is take or leave. I think this conclusion is likely wrong and hasty, given the lack of activity is a result on waiting on more information from the reporter. -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116011301.gc22...@gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat, Nov 15, 2014 at 11:37:14AM -0500, Miles Fidelman wrote: > Brian wrote: > >On Sat 15 Nov 2014 at 13:49:18 +0200, Andrei POPESCU wrote: > > > >>On Vi, 14 nov 14, 08:04:00, Marty wrote: > >>>By the same token systemd is a major waste with no real gain. It duplicates > >>>equivalent modular alternatives, and also requires unnecessary effort to > >>>repair damage from excessive coupling. > >>I challenge you to come up with a configuration that duplicates > >>systemd's features with a combination of other software. > > That assumes that one needs or wants systemd's features. > > For some (many?) of us, systemd represents no gain, and significant > operational impact (time required to deal with changes). Well, maybe taking some of the time you used to send 71 mails over the course of 15 days on this list could be invested into dealing with the changes. It is not like Jessie will not come with others configuration breaking changes ( such as Apache 2.4, to name one ). You say "significant operational impact", but all your mails seems to imply that you are basing your analysis on absolutely no test. If you did things right with your servers, you would just have to use your configuration management system to spin a new server to test, either bare metal or a VM if you can't afford a test machine, and see by yourself, and then, be precise in what is the problem. ( provided you use configuration management, but I would find baffling than any serious sysadmin do not use one these days ) Cause if no one can reproduce the problem ( because you give no indication ) and no one can find it ( because people test and have no issues ), it is not different from having a problem that do not really exist, and insisting on it is then no different than baseless trolling. You want to make a difference, so just do something useful. -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141116010515.gb22...@gmail.com
Re: Installing an Alternative Init?
On Wed, Nov 12, 2014 at 12:26:26AM -0500, Marty wrote: > On 11/11/2014 02:16 PM, Brian wrote: > >On Tue 11 Nov 2014 at 12:36:14 -0500, Marty wrote: > > > >>On 11/11/2014 12:07 PM, Laurent Bigonville wrote: > >>> > >>>There are no functional differences between an installation with > >>>sysvinit-core out of the box or an install where sysvinit-core is > >>>installed later, this is a fact. > >>> > >>>Allowing the user to choose this at install time from the interface is > >>>a "nice to have" feature (wishlist bug) not a RC bug like you were > >>>claiming earlier. > >> > >>There is a potential practical consequence of not advertising an > >>init alternative during setup. It makes users less likely to be > >>aware of it, or even aware that the init system has changed. > > > >New users do not need to be be aware of all the background to the > >choosing of a default init. No advertisement is needed. By definition, > >they do not care. They want Debian. Please let them have it. > > They will not care "by definition" only if they are not aware of the > change, and most won't be aware unless they are informed during the > installation. > > >>They won't know they lost the choice they didn't know they had. Capisce? > > > >What choice have they lost? > > They lost an *informed* choice. I think the installation program > should not take sides but just inform the user. A choice that the > user is not aware of is the same as no choice, and is potentially > coercive and disrespectful. It makes Debian seem partial to Red > Hat's business plan to take over the Linux ecosystem. If you care so much about Redhat code, maybe you should document yourself, and see there pay coders for glibc, gcc, the kernel ( a ton of them, according to lwn and linux fundations reports ), on coreutils, gnome, kde, php, python, openssh, etc, etc. > > Whatever it was, it didn't exist as you imply > > in Wheezy. > > It wasn't an issue in Wheezy because the default init option had not > changed from the previous release, and any release before that. > > >>They won't know, that is, until it bites them somewhere down the > >>line. Then they won't know where to look or who to blame, and will > >>blame Debian. > > > >What bites them? > > Individually, probably something that requires sysvinit or one many > core services that got replaced. Collectively, getting trapped by > vendor lock-in. You keep using those words, but you do not seems to use them correctly. If the same system is present on more than one distributio, that's not vendor lock-in since you can switch distribution and then reuse the same system. Being tied to one package format ( and so on the ecosystem around ) would be true lock-in. And no one complained that much since Debian existed, despites the .deb having a few shortcomings at start, shortcomings that were fixed later such as having checksum of installed software, a feature rpm had at a time the dpkg didn't ( around 2002, so that's really a old stuff ). > In both cases it could be the result of users being steered to the > default init by the installation program, leaving alternatives to > rot. Alternatives will rot if no one use them, so either you recognize than no one is interested to use them and it will indeed rot, or that the few interested to use them are unable to fill bug reports and help the alternatives survives. Given that a reading of the archives here show less than 50 people by a large margin complaining on this list, I would indeed see that as a minority. ( as I hope there is more than 100 000 to 1 million Debian users, since Ubuntu speak of 20 millions, Fedora speaking around 2 or 3 millions. But that doesn't matter, since 100 000 or 1 million, there would still be far less than 1% of the user base ). > >>Installation time may be only means that most users (like me*) ever > >>would learn about it. > >> > >>* Install instructions? We don't need no stinkin' instructions > > > >Reading? You are right. Who wants it? Just spew out nonsense and hope > >nobody notices. > > Isn't that where the dumbed-down install is headed? Don't worry > about the details silly, Windows tells you when it's time to reboot. The part about Debian being a universal operating system also mean it should aim for people who are not interested in details. Maybe you are ok by having Debian being seen as "complicated and hard to use, spewing useless questions on install", but that just mean than regular people will avoid it. And if you want free software to be used, you would recognize that the setting is advanced and do not belong to d-i. Now of course, maybe you are fine of having people staying on Windows or Mac OS X because they have less trouble to install them and to use them, but you kinda lose the right to complain " why do no one use Linux ?" ( and you also lose the right to complain when others take that opportunity and are successful ). -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.deb
Re: If Not Systemd, then What?
On Tue, Oct 21, 2014 at 12:02:38AM -0700, Rusi Mody wrote: > There are other choices to > - do nothing as weve done for 20 years > - do it now > > In particular, one can take a holistic view: not just Stable -> Jessie, > but rather Stable -> Jessie -> Jessie+1 > > and work out the least disruptive, most generally acceptable solution > in that +1ed widened frame The fact is that this is already what happened. Systemd is a option in the current stable, and I just tested, it run fine. So the plan was more "Stable -> Wheezy -> Jessie". What you are asking is not what you say, this is to push again now the moment to switch have happened. And this happened because upstream has a need for feature proposed by systemd, and they waited long enough ( as the plan was first proposed 2 years, in october 2012 ago and likely being discussed before during Guadec and others events ). KDE people, wayland developpers among others also decided to reuse systemd features, so if you think that Debian should wait 2 or 3 years more than the 2 or 3 years that was already done, sure. But the more time you wait, the less Debian will be a attractive target to upstream, the more work will have to be done to integrate, and the less innovation will happen. Ubuntu pushing for new stuff is why we see ubuntu and not Debian as the goto OS for docker and amazon. For example, spotify decided to switch to Ubuntu rather than keeping Debian, and if you look around, they are not the only ones. Procrastination and protests are not really a solution. If people want to keep sysvinit, they should help adopt systemd-shim and do bug reports, not wait on others to do the work when there is obviously not much people who care about that ( since besides ubuntu, almost no big community do use systemd-shim, so hope of getting wide coverage and tests are rather slim ). -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021190510.gb13...@gmail.com
Re: If Not Systemd, then What?
On Tue, Oct 21, 2014 at 02:46:46AM -0400, Steve Litt wrote: > On Tue, 21 Oct 2014 08:12:17 +0200 > Ludovic Meyer wrote: > > > On Mon, Oct 20, 2014 at 09:34:48PM -0400, Steve Litt wrote: > > > On Mon, 20 Oct 2014 12:45:11 -0700 > > > Patrick Bartek wrote: > > > > > > > After much vitriolic gnashing of teeth from those opposed to > > > > systemd, I wonder... What is a better alternative? > > > > > > * Nosh > > > > So this one is fun, it is just a direct copy of the systemd service > > format. Guess the proof that's at least a feature that people do > > want, dropping shell. > > I think you meant a direct copy of daemontools, didn't you? No. I mean't the format of the service is exactly the one of systemd, download the tarball, and look at the code, like smbd.service : $ cat smbd.service ## ** ## For copyright and licensing terms, see the file named COPYING. ## ** [Unit] Description=SAMBA file and print services daemon [Service] systemdWorkingDirectory=false ExecStart=smbd -F -s /usr/local/etc/smb.conf Restart=always [Install] WantedBy=server.target > http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html > > It's not a direct copy, it's an enhanced superset of daemontools, kind > of. Daemontools preceded systemd by several years, and I sincerely doubt > daemontools and systemd have anything in common. Indeed, one is used and alive, and the other is written by djb. > > > > And of course, not only the format is copied, it took the set of > > systemd services and copied them like this. I am sure ftp-masters > > wouldn't accept a GPL violation ( as the .service file are likely not > > un the BSD ). > > Daemontools wasn't GPL'ed, it was Public Domained, so anyone can do > absolutely anything with it. nosh take the same file for ssh with a service, a socket file and a separate service for the keys generation than systemd, and this is not a copy ? Look at the code, it use the same exact naming : Unit, Install etc section, and everything. If that's not a copy, that's a rather strong inspiration, showing again that people recognize that systemd is doing the right thing when it come to dropping shell. And since you recommend nosh, I guess you agree on this point. Nosh also take over the job of showing a tty ( login-banner.cpp ), of setting the network hostname ( set-dynamic-hostname.cpp ), of mouting ( nmount.cpp ), and maybe more. See for example common-manager.cpp where it take over lots of configuration. So yeah, nosh is basically following systemd steps, which is also likely showing that systemd is doing the right thing. And while the code is not that ugly, there is still some very specific ugly stuff like mixing goto and exception for checking of errors, or there is magic constants everywhere in some place of the code like service-is-up.cpp , common-manager.cpp > > > > > * Runit > > > > was non free for a long time, not sure if developped > > anymore, especially since last post on one of the ml date back to > > June 2013. > > Funtoo is using it, and I seriously doubt they'd be using something not > developed anymore. You would be surprised to see the number of people who are using cron and at. At least, cron have been forked by RH to become cronie, but at didn't involve since years. > > > > > * Upstart > > > > no longer developped, and suffer from several bugs, go read the > > tech-ctte debate. > > I read it, and if Upstart problems were the most distressing thing in > that debate, I'd be a happy man. If Upstart is no longer under > development, the reason would be that the Debian CTTE decided on > systemd, so Cannonical reluctantly followed suit. No, in fact, it was already not much developped during the previous years : https://www.openhub.net/p/upstart/commits/summary Compare with more active projects : https://www.openhub.net/p/systemd/commits/summary https://www.openhub.net/p/python/commits/summary https://www.openhub.net/p/perl/commits/summary In fact, I would postulate that's systemd that made upstart being developped again after the developper went to Google and the reason why Canonical switched so fast was because they were not totally unhappy to drop it, and I guess their biggest concern was doing the integration work, and guess what, as soon as they found Debian would do it for "free", they decided to switch. And they even do collaborate with systemd people quite well: https://wiki.debian.org/Sprints/2014/SystemdGNOMESprint ( 3 people f
Re: If Not Systemd, then What?
On Mon, Oct 20, 2014 at 09:34:48PM -0400, Steve Litt wrote: > On Mon, 20 Oct 2014 12:45:11 -0700 > Patrick Bartek wrote: > > > After much vitriolic gnashing of teeth from those opposed to systemd, > > I wonder... What is a better alternative? > > * Nosh So this one is fun, it is just a direct copy of the systemd service format. Guess the proof that's at least a feature that people do want, dropping shell. And of course, not only the format is copied, it took the set of systemd services and copied them like this. I am sure ftp-masters wouldn't accept a GPL violation ( as the .service file are likely not un the BSD ). > * Runit was non free for a long time, not sure if developped anymore, especially since last post on one of the ml date back to June 2013. > * Upstart no longer developped, and suffer from several bugs, go read the tech-ctte debate. > * S6 likely the same as runit when it come to be alive. > * Probably more I don't know about. You could add openrc, the only serious contender. > > And it can't be sysvinit. > > > > Yes. Syvinit still works, but it is after all 20 years old. It's been > > patched and bolted onto and jury-rigged > > Nobody's arguing for sysvinit as a long term solution, for the exact > reasons you post above. Those of us who appeared to favor sysvinit were > saying "let's wait until we have something good." We also pointed out > the false choice of prematurely narrowing it to systemd, Upstart or > sysvinit. You mean "let's do like we did since 20 years, wait, in case if something will happen". None of the alternatives you propose have been widely adopted by anyone except upstart. And that's mostly because no one cared about them up to the point to even propose them. > Now of course, the systemd cabal will argue that we can't wait any > longer. My question to them is, why was sysvinit not a dire emergency > until Red Hat's systemd juggernaut came along, and then all of a > sudden we just couldn't wait? You mean that after waiting several years, the solution is to wait again, because no one cared before, and when 1 group came and changed, the solution is to refuse and go back doing nothing ? -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021061217.ga29...@gmail.com
Re: GR proposed re: choice of init systems
On Mon, Oct 20, 2014 at 04:49:48PM -0400, Ric Moore wrote: > On 10/20/2014 02:35 PM, Andrei POPESCU wrote: > > >If you mean you are actually DOSing Debian's support channels just to > >make you're point that's likely to get you banned instead, besides not > >achieving anything. > > ~OR!~ > > "List archives get refreshed every 20 minutes." is a more likely > reason for the list to go down just for a bit, especially with the > higher than normal activity. I doubt any of the 4chan types to give > a whit, one way or the other, as we're not exactly clubbing baby > seals here. Maybe there is a GNU/Low Orbit Ion Cannon?? That would > be more likely. :) Ric You must have missed the memo : http://www.vitavonni.de/blog/201410/2014101801-beware-of-trolls---do-not-feed.html I didn't found any communication from the DSA, but I wouldn't be surprised that some guy decided to retaliate on Debian because of idiotic reasons. And that's why the server was down for a while. And the server is fully able to handle the load of debian-user, given that it handle all others lists as well : https://lists.debian.org/completeindex.html Even with the addition 10 to 20 people posting on systemd, it shouldn't be a issue. -- l. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021062531.gb29...@gmail.com
