Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 11/17/2014 01:54 PM, Ludovic Meyer wrote: 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. There *are* people doing it, e.g. systemd-shim, uselessd, nosh and eudev, the refracta team, and others. There are so many projects, it's hard to know where to join in, but I'm willing to help if I can. 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 ? Right now Jessie is seems to have acceptable sysvinit support. The main concerns seem to be about Stretch, but that's 3-4 years away, so I think there's time to work on solutions. 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. Keep in mind this is a mostly volunteer project, with a lot of people working in their spare time. 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. I think small teams are the way to go in FOSS. >>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. It's a philosophy, and not even the dominant one in the software industry, but it is about technology and engineering, and part of the culture and design of Debian. I recognize that it also clashes with the "universal operating system" moniker, because the whole world is not Unix, so I see a place in Debian for monolithic OSs like systemd and Android clones, but I would have been more conservative about introducing it. 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". Design philosophies have major technical implications. If Debian had started with Windows 3.1, I don't think the project would be where it is today. Loose package coupling works well with volunteer projects. For systemd to work in Debian it has to work within the existing modular framework, and I think it can be done, with difficulty. 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 s
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 > special handling of a temporary parallel fork. You mean like it was the case in the previous stable, where systemd was present but not as default ? And you say "more time", how much more time ? If that's not time based, what are the criteria, what are the bug that should be solved
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?)
Le 16/11/2014 02:13, Ludovic Meyer a écrit : > 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. > Sorry, I was not asked more precision since 2 days ago, and could not answer right away. >> 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. > Reporter cannot give info if not asked to... Moreover even when systemd is not pid 1, it must be used through logind, pam, etc... I cannot help more since I do not find any doc on debugging systemd components, for people not knowng systemd internals. -- 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/546a5df3.40...@rail.eu.org
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. > > > >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(). > > Not sure how we went from entanglement issues to PID tracking, but > granting your point, it still doesn't explain how we arrive at kdb, > console and qcodes in PID 1. :) Because the blog post say how and why stuff requires to be linked with systemd. As you didn't explain what you mean by hairballs ( ie, what re
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sun, Nov 16, 2014 at 12:00:52PM -0500, Ric Moore wrote: > On 11/15/2014 08:35 PM, Ludovic Meyer wrote: > > >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 ? > > I installed systemd to Jessie as soon as it was announced. No problems so > far. I'm happy. :) Ric Me too. A slight glitch at the start, but easily fixed. Everything running smooth as! -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- 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/20141117114909.GG20978@tal
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat, Nov 15, 2014 at 10:14:17PM +0900, Joel Rees wrote: > On Sat, Nov 15, 2014 at 8:51 PM, Andrei POPESCU > wrote: > > On Vi, 14 nov 14, 22:53:36, Joel Rees wrote: > >> > >> If you can't deal with it, snip it? > > > > I don't think it brings anything useful to a discussion on -user. That's > > much more suitable for some -devel list. > > Re-read the wall of text you deleted, then think again about this suggestion. Or even the off-topic list, if anyone is interested. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- 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/20141117114428.GF20978@tal
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. Now you can discuss for years in theory, In fact, people have been discussing this problem for years. 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. 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 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. 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(). Not sure how we went from entanglement issues to PID tracking, but granting your point, it still doesn't explain how we arrive at kdb, console and qcodes in PID 1. :) 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 You did not make much of a case for a complex PID 1 process, and on that question I defer to a kernel dev who takea a rather dim view of it: http://lwn.net/Articles/618024/ -- 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/54694f78.6090...@ix.netcom.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. 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. (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? 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.) 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. 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.) If it's a major change, it needs more time, and, I'm asserting, the special handling of a temporary parallel fork. If it's not a major change, why do we have problems like the problem of installing other inits? > [...] -- Joel Rees Be careful when you look at conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself, as well. -- 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/CAAr43iNJ8-+tDvqyXzHGm8Zhn6n41vOirSy-=tl2ux0gid8...@mail.gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. 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. 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 signature.asc Description: OpenPGP digital signature
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 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. And this, despites having (IMHO) a bigger need for a internal interface of the kernel than one for systemd. By bigger needs, I mean that there is a lot more of people wanting to have out of tree modules, while I gues
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. >> 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. 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. -- 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 signature.asc Description: OpenPGP digital signature
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. 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.* -- 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/5468e754.4020...@ix.netcom.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 11/15/2014 08:35 PM, Ludovic Meyer wrote: 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 ? I installed systemd to Jessie as soon as it was announced. No problems so far. I'm happy. :) Ric -- My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. Linux user# 44256 -- 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/5468d844.5070...@gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
Andrei POPESCU wrote: On Du, 16 nov 14, 10:18:24, Miles Fidelman wrote: Let me also turn the question back at you: Have you considered, just for a fraction of a second, that a migration to systemd, could, in fact, make some systems LESS reliable and understandable? Sure I did. systemd is not bug-free and it's approach is different, so it does require learning before understanding it. However, I fail to see any significant difference compared to any other major change I've been through since using Debian. I guess that we have different ideas of "major change." -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- 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/5468d2ff.5020...@meetinghouse.net
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: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Du, 16 nov 14, 10:18:24, Miles Fidelman wrote: > > Let me also turn the question back at you: > > Have you considered, just for a fraction of a second, that a migration > to systemd, could, in fact, make some systems LESS reliable and > understandable? Sure I did. systemd is not bug-free and it's approach is different, so it does require learning before understanding it. However, I fail to see any significant difference compared to any other major change I've been through since using Debian. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
Andrei POPESCU wrote: On Sb, 15 nov 14, 11:37:14, Miles Fidelman wrote: For some (many?) of us, systemd represents no gain, and significant operational impact (time required to deal with changes). Have you considered, just for a fraction of a second, that a migration to systemd, however painful it may prove, could in fact make your setup much more reliable and understandable? Let me also turn the question back at you: Have you considered, just for a fraction of a second, that a migration to systemd, could, in fact, make some systems LESS reliable and understandable? But in answer to your question: Sure. For a long time, I just assumed that Jessie would be an improvement on Wheezy (otherwise, why release a new version), and like previous releases, it would be largely backwards compatible, have some bugs resolved, some security holes tightened, and offer some new features that might or might not be of interest. To the extent that I thought about systemd at all, it was to the same degree as I think of any other core system service - it's there, it works, nothing to see here. Then, I became aware of how many basic system services were being incorporated into the systemd collection of stuff, and how many other things it touched (like, for example, PAM - which I use extensively), and logging, and so on. And then I started reading the (conflicting) documentation, such as there is, describing all the things I'd have to test, change, watch out for when it came to rebuilding our servers on top of Jessie. Followed by reading about the design, philosophy, approach, and agenda of its developers - in their own words, in their own emails, and on their own blogs. And then, I started seeing the reactions of the developers and apologists to legitimate criticisms and concerns. I've sat through an awful lot of design reviews for software and system projects, on both sides of the table, and personally, I would have killed this thing early in its life. Joel Rees has this exactly right, this has all the signs of a death march project, not just for Debian but for large chunks of the Linux ecosystem. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- 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/5468c040.6040...@meetinghouse.net
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sb, 15 nov 14, 11:37:14, Miles Fidelman wrote: > > For some (many?) of us, systemd represents no gain, and significant > operational impact (time required to deal with changes). Have you considered, just for a fraction of a second, that a migration to systemd, however painful it may prove, could in fact make your setup much more reliable and understandable? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. 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. > 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 testing is almost finished, but, hey, we all know how it is when we tell them that the project is 90% complete. It's 90% of what we can see, and more than half the time we aren't seeing anything close to the real extent of what remains. Top-down was supposed to fix that, objects were supposed to fix that, declarative programming was supposed to fix that, but programming projects tend to be like cave systems. The more we get done, the deeper we dig, the more we discover has to be done before we are finished. This is one of the very reasons for the existence of open source software, that we can decide, when it is our own project, this is where we stop for now. But just because we stop doesn't mean we are finished. I know the systemd proponents really want the job to be mostly complete, and most
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. -- 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/20141116112652.78d2a...@fornost.bigon.be
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 11/15/2014 06:49 AM, Andrei POPESCU wrote: On Vi, 14 nov 14, 08:04:00, Marty wrote: On 11/14/2014 05:26 AM, Andrei POPESCU wrote: >On Vi, 14 nov 14, 08:59:11, Joel Rees wrote: Jumping in here as myself, not Joel's tag-team member. :) >"Debian" as an entity doesn't really do much. There are only one or >several volunteers who start doing things. Setting up a separate "port" >for systemd would have been a major waste of resources (both human and >hardware) with no real gain. 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. http://0pointer.de/blog/projects/why.html >You are completely dismissing the work of Debian Developers who *did* >have a very good look at the options and decided switching to systemd is >doable and would be a good thing from a *technical* point of view. Non-responsive to his argument. If the work was biased and over-optimistic then it doesn't matter how much they looked at it. This argument cuts both ways :) >However, you and several others are rejecting systemd on ideological >grounds. There's not much that can be done about that, short or >re-implementing systemd according to your vision. Many others reject choice and the anti-choice stance is the ideological position at issue here. It is in direct conflict with Debian policy. The systemd upstream are the ones with "vision," ideology, rejecting opponents as "haters" in an overt campaign to establish a Linux monopoly. They have a financial interest in *psychological projection* of this kind. I still cannot see what Debian stands to gain by jumping on their marketing bandwagon. 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. >I hope you do understand why neither the systemd developers, maintainers >or users have any interest whatsoever in doing that. But upstreams have other interests, like establishment of a Linux monopoly via tying and customer lock-in. Why should there not be a rational effort to counter that? In my opinion the best "defence" against a monopoly[1] of any kind is to develop competitive alternatives. That's true on a level playing field, but here is just one player with control of the user-space software stack, fully leveraging it by dependency tying. It's like a manufacturing business that creates a monopoly by vertically integrating, in a way that no competitor can. [1] which I don't believe applies, but will ignore for the moment. They seem determined to make it apply in the future, so that's what drives the original concern (for me). It may apply in a way you are not expecting. After all, systemd >already works fine for them. Windows already works fine for most people, and it is consistent with the anti-choice philosophy, so why bother with Linux at all? Doesn't work fine for me. At $dayjob I'm forced to use it and I can tell you my private laptop with a Dual Core 1,8 GHz and 2 GB RAM runs circles around a Core i5 with Windows 7. But this is off-topic for d-u. It might be somewhat on-topic after all, because I was thinking more about Windows 10, which is Red Hat's likely target and competitor. Debian and the other free software distros are just Wall Street cannon fodder. Kind regards, Andrei -- 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/5467fc2d.7010...@ix.netcom.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: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat 15 Nov 2014 at 19:24:49 +, Brian wrote: > Upgrading > - > >After changing sources.list and an 'apt-get update' do > > apt-get install sysvinit-core systemd-shim > >Then proceed with an upgrade and dist-upgrade. > > New Install > --- > >Use the apt-get command above immediately after installation or >preseed the installation of sysvinit-core and systemd-shim. In the light of https://lists.debian.org/debian-ctte/2014/11/msg00063.html I'd like to revise the above and point out that at some time in the near future the command apt-get install sysvinit-core or preseeding the installation of only sysvinit-core should be sufficient. -- 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/15112014231357.f27ee7fd4...@desktop.copernicus.demon.co.uk
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
Brian wrote: 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 :) ). Well yes, but also shudder. 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. We have been here before, so some of what follows is repetition. For users who feel the same as you it is (AFAIK) the way to get basically what you want. It cannot be definitive because changes between now and the release of Jessie are likely to alter the advice. Upgrading - After changing sources.list and an 'apt-get update' do apt-get install sysvinit-core systemd-shim Then proceed with an upgrade and dist-upgrade. New Install --- Use the apt-get command above immediately after installation or preseed the installation of sysvinit-core and systemd-shim. Both of these may or may not have an operational impact in individual cases but (as an outline) they are (AKAIK) the only ways to avoid systemd-sysv being installed. After that you are on your own, leaving aside bugs. I appreciate any major change to a way of working can be stressful but (without wishing to teach anyone how to do their job) there are ways of testing which can increase confidence in the provided methods. The testing also has the added benefit (should there be problems) of improving on the already large amount of work done within Debian. The BTS would be the appropriate place to put one's experiences. At the risk of repeating myself, I'm going to stick with Wheezy as long as I can, see of LTS kicks in, and wait to see if bug #668001 ever gets fixed (and note that an awful lot of conflict might have been avoided if it had been marked release critical.) Meanwhile, I'm going to start testing other distros, including BSD and illumos based ones. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- 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/5467c332.9090...@meetinghouse.net
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. That means that practically, systemd is de facto compulsory. Not the default, the only way allowed. So it is take or leave. -- 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/5467c02d.2010...@rail.eu.org
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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... 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). > [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... -- 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/5467bafc.9030...@libertytrek.org
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. We have been here before, so some of what follows is repetition. For users who feel the same as you it is (AFAIK) the way to get basically what you want. It cannot be definitive because changes between now and the release of Jessie are likely to alter the advice. Upgrading - After changing sources.list and an 'apt-get update' do apt-get install sysvinit-core systemd-shim Then proceed with an upgrade and dist-upgrade. New Install --- Use the apt-get command above immediately after installation or preseed the installation of sysvinit-core and systemd-shim. Both of these may or may not have an operational impact in individual cases but (as an outline) they are (AKAIK) the only ways to avoid systemd-sysv being installed. After that you are on your own, leaving aside bugs. I appreciate any major change to a way of working can be stressful but (without wishing to teach anyone how to do their job) there are ways of testing which can increase confidence in the provided methods. The testing also has the added benefit (should there be problems) of improving on the already large amount of work done within Debian. The BTS would be the appropriate place to put one's experiences. -- 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/20141115192449.gn3...@copernicus.demon.co.uk
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 15-11-2014 16:59, Brian wrote: On Sat 15 Nov 2014 at 15:22:06 +0200, Dimitrios Chr. Ioannidis wrote: On 15-11-2014 14:17, 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. > >One picture is worth a thousand words. > > https://np237.livejournal.com/34598.html > >(Sorry, couldn't resist). I couldn't resist also ... "A use case better covered by SysV init: encrypted block devices" http://tanguy.ortolo.eu/blog/categorie2/debian I'll see you and raise you with a link to a helpful post: https://lists.debian.org/debian-user/2014/04/msg01286.html https://lists.debian.org/debian-devel/2014/07/msg01048.html Irrelevant ... Read carefullty " ... use case better covered ... " "if systemd requires specific configuration to handle such a case, whereas SysV init does not, that means this case is better covered by SysV init;" systemd : "[Unit] Description=Unlock EncFS DefaultDependencies=no After=local-fs.target Before=display-manager.service getty@tty1.service [Service] Type=oneshot RemainAfterExit=true Environment=RootDir=/home/.encfs/crypt Environment=MountPoint=/home/crypt ExecStart=/bin/sh -c "systemd-ask-password --no-tty --timeout=30 'Unlock EncFS' | encfs --stdinpass $RootDir $MountPoint" ExecStop=/bin/umount $MountPoint [Install] WantedBy=sysinit.target" This is a specific configuration ... Any way thx for playing ... ( it was just humor ... ) Regards, -- Dimitrios Chr. Ioannidis -- 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/d48be499e67f1d6cc9c3c37f2b0d8...@nephelae.eu
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- 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/5467813a.2060...@meetinghouse.net
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
2014/11/15 22:57 "Andrei POPESCU" : > > On Sb, 15 nov 14, 22:05:58, Joel Rees wrote: > > On Sat, Nov 15, 2014 at 9:20 PM, Andrei POPESCU > > wrote: > > > [(clipping too much, I now realize)] > > > The transition plan[5] has been posted on -devel since July with no > > > objections. > > > > > > [5] https://lists.debian.org/debian-devel/2014/07/msg00611.html > > > > My impression is that objections logged to that thread, had there been > > any, would have been to the method or timing, not to the switch > > itself. > > > > In other words, members of dev who disagreed to the switch itself > > would have needed a different thread to register their continued > > disagreement. > > In my impression Debian is most of the times much *less* formalised than > this. > > What is actually quite frustrating in this particular case (for me as an > outsider, can't even imagine how it is for people directly involved) is > how people don't engage in such a thread, but instead escalate to the TC > and/or GR directly. > > > And I am under the impression that there was an undercurrent of > > "object to this and lose your geek cred." > > Definitely doesn't match my impression. Well, Brian posted a link to a repurposed graphic of the waiting forever meme. And Dimitrios posted a link to a use case that is, indeed, not well covered by the _current_ (as of the freeze) systemd package. Sure, if you know the trick, you can get it to go, with some compromise. Have to encrypt root too or something equally counterintuitive. And I'm sure they'll get that fixed, too, put the documentation in, get plymouth set up to no longer be just a splash screen by default, instruct everyone to encrypt their root partitions or whatever the other part was. Maybe after the freeze they get whatever requires that second part fixed as well. What they are selling is a solution to everyone's problems, and they way it works is that they provide a solution after we find the problem. That is not substantially different from the way it was with sysvinit, except now the systemd crowd are the go-to guys for all things init, where, before, you had the expertise spread out. There wasn't a single group. We teach them and they become our experts. And it works as long as everyone will just do it their way. Renaud's sig had a rather interesting quote from Simon Bolivar a few posts up. Joel Rees
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat 15 Nov 2014 at 15:22:06 +0200, Dimitrios Chr. Ioannidis wrote: > On 15-11-2014 14:17, 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. > > > >One picture is worth a thousand words. > > > > https://np237.livejournal.com/34598.html > > > >(Sorry, couldn't resist). > > I couldn't resist also ... > > "A use case better covered by SysV init: encrypted block devices" > > http://tanguy.ortolo.eu/blog/categorie2/debian I'll see you and raise you with a link to a helpful post: https://lists.debian.org/debian-user/2014/04/msg01286.html https://lists.debian.org/debian-devel/2014/07/msg01048.html -- 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/15112014145609.e73095746...@desktop.copernicus.demon.co.uk
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sb, 15 nov 14, 22:05:58, Joel Rees wrote: > On Sat, Nov 15, 2014 at 9:20 PM, Andrei POPESCU > wrote: > > [(clipping too much, I now realize)] > > The transition plan[5] has been posted on -devel since July with no > > objections. > > > > [5] https://lists.debian.org/debian-devel/2014/07/msg00611.html > > My impression is that objections logged to that thread, had there been > any, would have been to the method or timing, not to the switch > itself. > > In other words, members of dev who disagreed to the switch itself > would have needed a different thread to register their continued > disagreement. In my impression Debian is most of the times much *less* formalised than this. What is actually quite frustrating in this particular case (for me as an outsider, can't even imagine how it is for people directly involved) is how people don't engage in such a thread, but instead escalate to the TC and/or GR directly. > And I am under the impression that there was an undercurrent of > "object to this and lose your geek cred." Definitely doesn't match my impression. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 15-11-2014 14:17, 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. One picture is worth a thousand words. https://np237.livejournal.com/34598.html (Sorry, couldn't resist). I couldn't resist also ... "A use case better covered by SysV init: encrypted block devices" http://tanguy.ortolo.eu/blog/categorie2/debian Regards, -- Dimitrios Chr. Ioannidis -- 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/66dd4e331f467402fea441f4814d6...@nephelae.eu
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat, Nov 15, 2014 at 8:51 PM, Andrei POPESCU wrote: > On Vi, 14 nov 14, 22:53:36, Joel Rees wrote: >> On Fri, Nov 14, 2014 at 7:26 PM, Andrei POPESCU >> wrote: >> > On Vi, 14 nov 14, 08:59:11, Joel Rees wrote: >> > > [...] >> > [snip another wall of text about engineering principles] >> >> And, thus, once again, >> >> > > The engineering question keeps getting sidetracked by people who >> > > assert that we are talking about technical details, [...] >> >> If you can't deal with it, snip it? > > I don't think it brings anything useful to a discussion on -user. That's > much more suitable for some -devel list. Re-read the wall of text you deleted, then think again about this suggestion. If you still don't see how this suggestion is a short-circuit to ground for objections, I've written a bit more colorfully on the subject on my general blog, maybe you would care to re-read that as well. There's something in this question that is actually entangled in the difference between declarative and procedural programming, but I can't really talk with you about it until you start digging in to one or the other. -- Joel Rees Living without understanding programming is kind of like playing poker without understanding statistics. -- 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/caar43in2dxjcauqbxm21sb1jahek7a+rxjtr6yvq7y9pvfd...@mail.gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat, Nov 15, 2014 at 9:20 PM, Andrei POPESCU wrote: > [(clipping too much, I now realize)] > The transition plan[5] has been posted on -devel since July with no > objections. > > [5] https://lists.debian.org/debian-devel/2014/07/msg00611.html My impression is that objections logged to that thread, had there been any, would have been to the method or timing, not to the switch itself. In other words, members of dev who disagreed to the switch itself would have needed a different thread to register their continued disagreement. And I am under the impression that there was an undercurrent of "object to this and lose your geek cred." -- Joel Rees There is one conspirator against you, that has not changed. The only question is whether you will participate or turn your back to it. -- 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/caar43inl1sxtpndpprn4twa4zpfijoq6b9pzrfrpb5oyo6m...@mail.gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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). > My very simple point is and has been that, *because* the *default* init > system for debian has been sysvinit since anyone can apparently > remember, the very act of even *suggesting* that it be switched in > jessie to not only a *different*, but a (relatively) *very new* one, > should have invoked a very simple requirement - for which the > responsibility for implementation and maintenance would be on those > calling for the switch - to provide a means for easily switching back > and forth so that everyone else could easily test things, and > ultimately, after the release of jessie with the new default, provide a > means to easily choose the previous default installer at both update > *and* install time, and maintain such at *least* during the life of the > jessie (if not jessie+1). For fresh installs, given that there is a suitable[1] workaround the incentive to fix the bug[2] so late in the release cycle is low, as it might introduce other breakage. [1] so far the only claims against that workaround have been of the sort "I don't want systemd anywhere near my systems", without actual proof of something going wrong. [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001 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 [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. [5] https://lists.debian.org/debian-devel/2014/07/msg00611.html Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. One picture is worth a thousand words. https://np237.livejournal.com/34598.html (Sorry, couldn't resist). -- 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/15112014121345.2e551aff5...@desktop.copernicus.demon.co.uk
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Sat, 15 Nov 2014 13:49:18 +0200 Andrei POPESCU wrote: > In my opinion the best "defence" against a monopoly[1] of any kind is to > develop competitive alternatives. We have seen how well that worked with MS Windows over the years... Cheers, Ron. -- Nada es tan peligroso como dejar permanecer largo tiempo a un mismo ciudadano en el poder. El pueblo se acostumbra a obedecer, y él se acostumbra a mandarlo; de donde se origina la usurpación y la tiranía. -- Simon Bolivar -- http://www.olgiati-in-paraguay.org -- -- 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/20141115091340.4e213...@ron.cerrocora.org
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Vi, 14 nov 14, 22:53:36, Joel Rees wrote: > On Fri, Nov 14, 2014 at 7:26 PM, Andrei POPESCU > wrote: > > On Vi, 14 nov 14, 08:59:11, Joel Rees wrote: > > > [...] > > [snip another wall of text about engineering principles] > > And, thus, once again, > > > > The engineering question keeps getting sidetracked by people who > > > assert that we are talking about technical details, [...] > > If you can't deal with it, snip it? I don't think it brings anything useful to a discussion on -user. That's much more suitable for some -devel list. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Vi, 14 nov 14, 08:04:00, Marty wrote: > On 11/14/2014 05:26 AM, Andrei POPESCU wrote: > >On Vi, 14 nov 14, 08:59:11, Joel Rees wrote: > > > Jumping in here as myself, not Joel's tag-team member. :) > > >"Debian" as an entity doesn't really do much. There are only one or > >several volunteers who start doing things. Setting up a separate "port" > >for systemd would have been a major waste of resources (both human and > >hardware) with no real gain. > > 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. http://0pointer.de/blog/projects/why.html > >You are completely dismissing the work of Debian Developers who *did* > >have a very good look at the options and decided switching to systemd is > >doable and would be a good thing from a *technical* point of view. > > Non-responsive to his argument. If the work was biased and over-optimistic > then it doesn't matter how much they looked at it. This argument cuts both ways :) > >However, you and several others are rejecting systemd on ideological > >grounds. There's not much that can be done about that, short or > >re-implementing systemd according to your vision. > > Many others reject choice and the anti-choice stance is the ideological > position at issue here. It is in direct conflict with Debian policy. > The systemd upstream are the ones with "vision," ideology, rejecting > opponents as "haters" in an overt campaign to establish a Linux monopoly. > They have a financial interest in *psychological projection* of this kind. I > still cannot see what Debian stands to gain by jumping on their marketing > bandwagon. 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? > >I hope you do understand why neither the systemd developers, maintainers > >or users have any interest whatsoever in doing that. > > But upstreams have other interests, like establishment of a Linux monopoly > via tying and customer lock-in. Why should there not be a rational effort to > counter that? In my opinion the best "defence" against a monopoly[1] of any kind is to develop competitive alternatives. [1] which I don't believe applies, but will ignore for the moment. >After all, systemd > >already works fine for them. > > Windows already works fine for most people, and it is consistent with the > anti-choice philosophy, so why bother with Linux at all? Doesn't work fine for me. At $dayjob I'm forced to use it and I can tell you my private laptop with a Dual Core 1,8 GHz and 2 GB RAM runs circles around a Core i5 with Windows 7. But this is off-topic for d-u. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Vi, 14 nov 14, 13:27:22, Helmut Wollmersdorfer wrote: > > And all this says nothing about big servers, which need some > magnitudes more of reliability, stability and scaling. E.g. not using > plain text files for logs causes problems in the long run and in daily > work. The default setting for the Debian systemd package is to forward all messages to your syslog and rsyslog is still installed by default. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
2014/11/14 23:12 "Tanstaafl" : > > 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. > > I merely pointed out that it was the *default* for many, many years > (actual time unknown and googling didn't easily reveal it). > > > I was just pointing out that alternatives were indeed available, for > > quite some time, > > Yes, but obviously no one was switching often enough for any bugs to > allow for easy switching to be opened/scratched. > > My very simple point is and has been that, *because* the *default* init > system for debian has been sysvinit since anyone can apparently > remember, the very act of even *suggesting* that it be switched in > jessie to not only a *different*, but a (relatively) *very new* one, > should have invoked a very simple requirement - for which the > responsibility for implementation and maintenance would be on those > calling for the switch - to provide a means for easily switching back > and forth so that everyone else could easily test things, and > ultimately, after the release of jessie with the new default, provide a > means to easily choose the previous default installer at both update > *and* install time, and maintain such at *least* during the life of the > jessie (if not jessie+1). > > > it's just that maintainers and users of alternate inits did not yell > > at the sysvinit maintainers to implement the choice for them. > > And I would argue that the number of people who did switch was probably > miniscule, with respect to the entire debian user base. And maybe we can tie some points together here: Those who have switched init systems without install-level support from the debian community have generally not made claims like, "It worked for me, so why should you complain if I try really hard to see that you end up switching, too, without having a chance to get ready, much less choose?" -- Joel Rees
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
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. I merely pointed out that it was the *default* for many, many years (actual time unknown and googling didn't easily reveal it). > I was just pointing out that alternatives were indeed available, for > quite some time, Yes, but obviously no one was switching often enough for any bugs to allow for easy switching to be opened/scratched. My very simple point is and has been that, *because* the *default* init system for debian has been sysvinit since anyone can apparently remember, the very act of even *suggesting* that it be switched in jessie to not only a *different*, but a (relatively) *very new* one, should have invoked a very simple requirement - for which the responsibility for implementation and maintenance would be on those calling for the switch - to provide a means for easily switching back and forth so that everyone else could easily test things, and ultimately, after the release of jessie with the new default, provide a means to easily choose the previous default installer at both update *and* install time, and maintain such at *least* during the life of the jessie (if not jessie+1). > it's just that maintainers and users of alternate inits did not yell > at the sysvinit maintainers to implement the choice for them. And I would argue that the number of people who did switch was probably miniscule, with respect to the entire debian user base. -- 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/546609e3.6000...@libertytrek.org
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Fri, 14 Nov 2014 13:10:22 + Lisi Reisz wrote: > > Do you remember the Gnome/KDE war? Now > > we have two great desktop. Let's not impose by law an init system. > > Yes, but Gnome is the default and you have to be an "advanced user" to get > KDE. Not really, you just have to choose whether you download the Gnome-CD, the KDE-CD, or the Xfce-CD (which I prefer). There is choice without being "advanced". Cheers, Ron. -- The liar's punishment is not in the least that he is not believed, but that he cannot believe anyone else. --George Bernard Shaw -- http://www.olgiati-in-paraguay.org -- -- 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/20141114105256.218e7...@ron.cerrocora.org
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Fri, Nov 14, 2014 at 7:26 PM, Andrei POPESCU wrote: > On Vi, 14 nov 14, 08:59:11, Joel Rees wrote: > > [...] > [snip another wall of text about engineering principles] And, thus, once again, > > The engineering question keeps getting sidetracked by people who > > assert that we are talking about technical details, [...] If you can't deal with it, snip it? I don't think it becomes you, Andrei. -- Joel Rees Conspiracy? What conspiracy? http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html -- 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/caar43imsp+8enuxz8rpu0uez_isakdhzrghdljgmq9pmk2b...@mail.gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Friday 14 November 2014 12:27:22 Helmut Wollmersdorfer wrote: > Am 14.11.2014 um 11:26 schrieb Andrei POPESCU : > > Again, I can't comment on Fedora, but my Raspberry Pi runs systemd just > > fine. Also my laptop running is quite far from being a speed monster. > > On my two Raspberries I do not care. > > On a laptop it depends on your usage profile, and what your requirements > are. My Acer One (Atom, 1 GB) got to slow after upgrade to wheezy. To much > bloat, to much swapping. > > And all this says nothing about big servers, which need some magnitudes > more of reliability, stability and scaling. E.g. not using plain text files > for logs causes problems in the long run and in daily work. What is the connection between problems you may have with Wheezy and systemd, which you have to make a conscious effort to install in wheezy? Lisi -- 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/201411141313.01576.lisi.re...@gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
Le Fri, 14 Nov 2014 12:26:09 +0200, Andrei POPESCU a écrit : > On Vi, 14 nov 14, 08:59:11, Joel Rees wrote: [...] > > > So Fedora is not, itself, really ready yet, except for two groups, a > > certain group of workstation users who want and are willing to use > > fairly new, relatively high-end hardware, including enough RAM and > > processors to use VMs for certain things, and a certain group of > > server-farm users who want and have budget for similarly recent, > > relatively high-end hardware and lots of RAM and processors for lots > > of VMs. > > > > The rest of the Fedora users jumped ship. > > Again, I can't comment on Fedora, but my Raspberry Pi runs systemd > just fine. Also my laptop running is quite far from being a speed > monster. Also, different embedded projects (the Jolla phone, car board computers,...) are already using or planning to use systemd. -- 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/20141114141021.435d4...@soldur.bigon.be
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Friday 14 November 2014 11:42:32 Dan wrote: > Do you remember the Gnome/KDE war? Now > we have two great desktop. Let's not impose by law an init system. Yes, but Gnome is the default and you have to be an "advanced user" to get KDE. And anyway, some of us want neither and have to go to even greater lengths to avoid them. It has always been thus. No-one is imposing an init system by law. There has to be a default. Lisi -- 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/201411141310.22260.lisi.re...@gmail.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 11/14/2014 05:26 AM, Andrei POPESCU wrote: On Vi, 14 nov 14, 08:59:11, Joel Rees wrote: Jumping in here as myself, not Joel's tag-team member. :) "Debian" as an entity doesn't really do much. There are only one or several volunteers who start doing things. Setting up a separate "port" for systemd would have been a major waste of resources (both human and hardware) with no real gain. 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. The systemd folks claimed it wouldn't be necessary. If we had looked at the situation with an unbiased eye, we would have known they were being overly optimistic. We still turn a blind eye to the problems, claiming that the only problems are a bunch of recalcitrant noisemakers like yours-truly. You are completely dismissing the work of Debian Developers who *did* have a very good look at the options and decided switching to systemd is doable and would be a good thing from a *technical* point of view. Non-responsive to his argument. If the work was biased and over-optimistic then it doesn't matter how much they looked at it. And yes, that included the costs for the migration. Those are largely TBD ast this time. As far as I can tell by watching debian-user, debian-devel and pkg-systemd-maintainers the integration of systemd is mostly working fine and remaining issues (not all in systemd itself) will be dealt with before the release. The freeze could help with that, since the number of variables is reduced greatly. From the same lists, I can't tell whether non-systemd use will result in second-class citizenship and effective vendor lock-in for most users. However, you and several others are rejecting systemd on ideological grounds. There's not much that can be done about that, short or re-implementing systemd according to your vision. Many others reject choice and the anti-choice stance is the ideological position at issue here. It is in direct conflict with Debian policy. The systemd upstream are the ones with "vision," ideology, rejecting opponents as "haters" in an overt campaign to establish a Linux monopoly. They have a financial interest in *psychological projection* of this kind. I still cannot see what Debian stands to gain by jumping on their marketing bandwagon. I hope you do understand why neither the systemd developers, maintainers or users have any interest whatsoever in doing that. But upstreams have other interests, like establishment of a Linux monopoly via tying and customer lock-in. Why should there not be a rational effort to counter that? After all, systemd already works fine for them. Windows already works fine for most people, and it is consistent with the anti-choice philosophy, so why bother with Linux at all? Kind regards, Andrei -- 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/5465fdc0.7030...@ix.netcom.com
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
Dimitrios Chr. Ioannidis wrote: On 14-11-2014 12:26, Andrei POPESCU wrote: < snip > However, you and several others are rejecting systemd on ideological grounds. There's not much that can be done about that, short or re-implementing systemd according to your vision. I personally reject the design of systemd. To paraphrase Joel Spolsky : "As i see it every new feature systemd has is a tradeoff, between the people who could really use such a feature and the people who are just going to get overwhelmed by all the options. Even if you think that the new feature is all good and can't hurt because "people who don't care can just ignore it," you're forgetting that the people who allegedly don't care are still forced to look at that feature and figure out if they need it." Kind of like Microsoft Word, since v6. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra -- 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/5465f9ca.9050...@meetinghouse.net
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
Am 14.11.2014 um 11:26 schrieb Andrei POPESCU : > Again, I can't comment on Fedora, but my Raspberry Pi runs systemd just > fine. Also my laptop running is quite far from being a speed monster. On my two Raspberries I do not care. On a laptop it depends on your usage profile, and what your requirements are. My Acer One (Atom, 1 GB) got to slow after upgrade to wheezy. To much bloat, to much swapping. And all this says nothing about big servers, which need some magnitudes more of reliability, stability and scaling. E.g. not using plain text files for logs causes problems in the long run and in daily work. Helmut Wollmersdorfer -- 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/1333bfea-2556-469f-9103-5629a3a4b...@fixpunkt.de
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Fri, Nov 14, 2014 at 11:26 AM, Andrei POPESCU wrote: > On Vi, 14 nov 14, 08:59:11, 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? > > 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 was just pointing out that alternatives were indeed available, for > quite some time, it's just that maintainers and users of alternate inits > did not yell at the sysvinit maintainers to implement the choice for > them. > >> To explain to the systemd advocates who refuse to understand the >> engineering questions, this is the real engineering mistake in >> systemd. > > [snip another wall of text about engineering principles] > >> For Fedora, where it was first brought into a major distribution, the >> proper way to bring it in would have been to break policy and set up a >> parallel fork. Keep the damage that necessarily occurs with this kind >> of thing restricted to a sub-community willing _and_ _able_ to deal >> with the damage by cooperating in the separate bug tracking, triage, >> etc. Keep the questions of direction somewhat independent so that the >> systemd side and the "legacy" side don't have to be in lock-step on >> every tiny detail. Allow separate of source so that regressions and >> merges can be safely scheduled and safely carried out. Etc. > > I'm not familiar with how Fedora evolves as a distribution, so I will > refrain from commenting on this. > >> If they had done it right from the start, just about now, they would >> be ready for beginning the integration process in earnest, which would >> mean that about the beginning of this year, when the question came >> formally before the committee here, Fedora would have been >> implementing their own version of an installer that would allow >> choosing the new init system on install. > > What the Fedora installer can or cannot do is irrelevant for Debian, > unless one can use it to install Debian (is this the case?). > >> So Fedora is not, itself, really ready yet, except for two groups, a >> certain group of workstation users who want and are willing to use >> fairly new, relatively high-end hardware, including enough RAM and >> processors to use VMs for certain things, and a certain group of >> server-farm users who want and have budget for similarly recent, >> relatively high-end hardware and lots of RAM and processors for lots >> of VMs. >> >> The rest of the Fedora users jumped ship. > > Again, I can't comment on Fedora, but my Raspberry Pi runs systemd just > fine. Also my laptop running is quite far from being a speed monster. > >> Now, you who complain that Fedora and Red Hat are off-topic here, >> remember that Debian is inheriting the results of Red Hat's work. Work >> that did not allow a choice of inits on install, as one example of >> where their work is incomplete. That choice was something we still >> haven't got quite right yet, after how many months? > > Even if Fedora and/or Red Hat would have this choice it still wouldn't > have helped Debian in any way, because the bug is in a Debian component > (debootstrap, guess what the "de" stands for). > >> Debian set up kfreebsd to deal with these kinds of issues, relative to >> replacing the linux kernel with the freebsd kernel. Setting up a >> debian-sysd would not have been as extensive a project as setting up >> kfreebsd, but would have been similar, because we are basically >> pulling in a new layer between the kernel and the rest of the system. > > "Debian" as an entity doesn't really do much. There are only one or > several volunteers who start doing things. Setting up a separate "port" > for systemd would have been a major waste of resources (both human and > hardware) with no real gain. > >> The systemd folks claimed it wouldn't be necessary. If we had looked >> at the situation with an unbiased eye, we would have known they were >> being overly optimistic. We still turn a blind eye to the problems, >> claiming that the only problems are a bunch of recalcitrant >> noisemakers like yours-truly. > > You are completely dismissing the work of Debian Developers who *did* > have a very good look at the options and decided switching t
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On 14-11-2014 12:26, Andrei POPESCU wrote: < snip > However, you and several others are rejecting systemd on ideological grounds. There's not much that can be done about that, short or re-implementing systemd according to your vision. I personally reject the design of systemd. To paraphrase Joel Spolsky : "As i see it every new feature systemd has is a tradeoff, between the people who could really use such a feature and the people who are just going to get overwhelmed by all the options. Even if you think that the new feature is all good and can't hurt because "people who don't care can just ignore it," you're forgetting that the people who allegedly don't care are still forced to look at that feature and figure out if they need it." IMHO, systemd don't have that ineffable quality ( of doing less ) that will make knowledgable people to use it even if it doesn't have flaws. Regards, -- Dimitrios Chr. Ioannidis -- 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/38748c5f44f3013e804b37d0390b4...@nephelae.eu
Re: engineering management practices and systemd (Re: Installing an Alternative Init?)
On Vi, 14 nov 14, 08:59:11, 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? 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 was just pointing out that alternatives were indeed available, for quite some time, it's just that maintainers and users of alternate inits did not yell at the sysvinit maintainers to implement the choice for them. > To explain to the systemd advocates who refuse to understand the > engineering questions, this is the real engineering mistake in > systemd. [snip another wall of text about engineering principles] > For Fedora, where it was first brought into a major distribution, the > proper way to bring it in would have been to break policy and set up a > parallel fork. Keep the damage that necessarily occurs with this kind > of thing restricted to a sub-community willing _and_ _able_ to deal > with the damage by cooperating in the separate bug tracking, triage, > etc. Keep the questions of direction somewhat independent so that the > systemd side and the "legacy" side don't have to be in lock-step on > every tiny detail. Allow separate of source so that regressions and > merges can be safely scheduled and safely carried out. Etc. I'm not familiar with how Fedora evolves as a distribution, so I will refrain from commenting on this. > If they had done it right from the start, just about now, they would > be ready for beginning the integration process in earnest, which would > mean that about the beginning of this year, when the question came > formally before the committee here, Fedora would have been > implementing their own version of an installer that would allow > choosing the new init system on install. What the Fedora installer can or cannot do is irrelevant for Debian, unless one can use it to install Debian (is this the case?). > So Fedora is not, itself, really ready yet, except for two groups, a > certain group of workstation users who want and are willing to use > fairly new, relatively high-end hardware, including enough RAM and > processors to use VMs for certain things, and a certain group of > server-farm users who want and have budget for similarly recent, > relatively high-end hardware and lots of RAM and processors for lots > of VMs. > > The rest of the Fedora users jumped ship. Again, I can't comment on Fedora, but my Raspberry Pi runs systemd just fine. Also my laptop running is quite far from being a speed monster. > Now, you who complain that Fedora and Red Hat are off-topic here, > remember that Debian is inheriting the results of Red Hat's work. Work > that did not allow a choice of inits on install, as one example of > where their work is incomplete. That choice was something we still > haven't got quite right yet, after how many months? Even if Fedora and/or Red Hat would have this choice it still wouldn't have helped Debian in any way, because the bug is in a Debian component (debootstrap, guess what the "de" stands for). > Debian set up kfreebsd to deal with these kinds of issues, relative to > replacing the linux kernel with the freebsd kernel. Setting up a > debian-sysd would not have been as extensive a project as setting up > kfreebsd, but would have been similar, because we are basically > pulling in a new layer between the kernel and the rest of the system. "Debian" as an entity doesn't really do much. There are only one or several volunteers who start doing things. Setting up a separate "port" for systemd would have been a major waste of resources (both human and hardware) with no real gain. > The systemd folks claimed it wouldn't be necessary. If we had looked > at the situation with an unbiased eye, we would have known they were > being overly optimistic. We still turn a blind eye to the problems, > claiming that the only problems are a bunch of recalcitrant > noisemakers like yours-truly. You are completely dismissing the work of Debian Developers who *did* have a very good look at the options and decided switching to systemd is doable and would be a good thing from a *technical* point of view. And yes, that included the costs for the migration. As far as I can tell by watching
