Re: systemd bug closed - next steps?
On 25/09/14 03:43, Brian wrote: > On Wed 24 Sep 2014 at 12:33:35 -0400, Steve Litt wrote: > >> Look at it this way: If GNU wanted to stick stuff into their compiler >> to reduce the utility of Linux, they would have done so years ago. They >> never have. Redhat just did, bigtime. > > This is the Red Hat Conspiracy Theory. Does the promotion of blatent FUD > ever stop? Why is it necessary to have to have a bogeyman? > > No. (sigh) Because it's a conspiracy silly. (That *you* don't see it as obvious is proof). But wait - there's more! Intel, IBM, Google, NSA, binary, ATF, woody words, etc. Condition check:- Conspiracy obvious only to those who can see the hidden undeniable underlying interconnectiveness of everything? It's all connected, RedHat, Google, NSA, obligatory Nazi reference, egotistical individuals who fail the humility and manners test (don't pay homage). Check. End of Times prophecies? The sky is falling, wait for the third boot to drop, then it'll be too late and you'll be sorry. Check. Evangelists? We're doing this for your own good (tough love). Join us at the front lines for glory (we'll be along later). Check. Conservatism for the sake of Conservatism? The old way works for me - if it didn't work for you it's because you are wrong/part of the conspiracy. Therefore change is bad. Check. Appeal to authority? It's not the UNIX way. Check. Rent-a-mob support? Carpark full of veterans from [insert previous loyalty] in campervans come to save you from the same thing happening here. Check. Martyrs (persecution complex)? No no, it's "us" who are under-attack. *We* take offence with argument - the reverse does not apply. Check. Gish Gallop deployed as debate? No new argument just a rambling list of rephrased, illogical, and sophistic statements - which you *must* answer now or are proven true[*1]. Check. Confirmation bias? Forget about all the proven falsehoods they only strengthen our case - look at my corner case then go prove a negative. Technical committee decision invalid because "not technical"/rigged/"I wasn't heard". Check. Hypocrisy? Consider all our (Gish Gallop) complaints - but we refuse to read or consider all previous argument (developer lists tl;dr). Play our game (on your field) or we're taking your ball home with us (yes - we're still here, but we're going soon and we represent thousands of our silent congregation) All 10 boxes checked? Proceed with the revolution (against change). Kind regards P.S. I do hope you weren't being sarcastic -- 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/5424cbd2.2000...@gmail.com
Re: systemd bug closed - next steps?
On 09/24/2014 02:45 PM, Brian wrote: Chanting "Red Hat Conspirancy" to yourself before falling into a deep slumber is one thing. Convincing most other people it exists is a task which requires a little bit more. Let's see, the real goal of systemd has nothing to do with init or service management, but with IPC standardization, sandboxing apps and TC/DRM support, enabling an internet app store for Linux distros. That requires a PID 1 kitchen sink service to drive its dependency chains deeply into userspace using at least 40 APIs. Then just call it an "init" system and anyone opposing a luddite, manufacture a crisis by killing services it replaces and threaten the whole application stack. By then everyone has compared it with the old init, a perfect foil. While everyone is arguing about init systems, nobody will notice your original goal, but if they do just call it a paranoid conspiracy theory. you're right, too unbelievable. Back to Hanlon's razor. :) -- 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/54238718.7070...@ix.netcom.com
Re: systemd bug closed - next steps?
On Tue, Sep 23, 2014 at 07:07:08PM +0100, Brian wrote: > On Tue 23 Sep 2014 at 12:58:26 -0400, Steve Litt wrote: > > > > === Depending on glibc === > > True, it's a single point of failure, but it's made by GNU, whose > > agenda is less harmful to Linux than the agenda of Redhat. > > Misinformation. systemd is not in the control of or managed or developed > by Red Hat, although it will, like Debian, contribute to it. I doubt you > will retract the statement, though. > > > === udev === > > Udev is one of the components that provide hot plugging. Take it out > > and root needs to manually mount stuff. OK, that's a pain in the butt, > > but it's limited. Most of us remember the days when you really had to > > do a mount, as root, to read a thumb drive. Hassle? Yes. Comparable to > > the invasiveness of a PID 1 whose most intimate details are necessary > > to run the most mundane user apps? No. > > Running mc depends on what PID 1 is? Are you sure we are both using > Debian? You are peddling more misinformation. > > I use pmount myself and do not see it as a hassle. Others want what they > see as a more convenient method. They need udev. They're happy and I'm > happy; it's only you who seems a bit miserable. Cheer up; you have the > same choice as us available. > > (Next time, would you please do a question and answer session which > bears some releationship to reality?). > > > === X.org === > > First, no CLI program gives a flying flamingo about what GUI provider > > is used: They don't access it. Systemd, on the other hand, has its > > sticky little fingers in CLI and GUI alike. Second, by definition, a > > GUI program must access GUI system software. There's no such definition > > that CLI user identification must interact with part of PID 1's > > package, nor that a GUI program know the intimate details of PID 1. > > I don't understand what you are trying to say here. You probably don't > either. Not so much misinformation but a propagation of confusion. IOW, FUD -- "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/20140924212236.GI13946@tal
Re: systemd bug closed - next steps?
On 09/24/2014 01:43 PM, Brian wrote: On Wed 24 Sep 2014 at 12:33:35 -0400, Steve Litt wrote: Look at it this way: If GNU wanted to stick stuff into their compiler to reduce the utility of Linux, they would have done so years ago. They never have. Redhat just did, bigtime. This is the Red Hat Conspiracy Theory. Does the promotion of blatent FUD ever stop? Why is it necessary to have to have a bogeyman? This is interesting on the gcc thread: http://lkml.iu.edu/hypermail/linux/kernel/1407.3/02593.html "For cases where it's really critical that userspace know whether a particular kernel bug or feature is present, one of the tricks I use is the presence or absense of a file in /sys/fs/ext4/features. That way, userspace can reliably detect if feature or bug fix is present, without relying solely on a version check which doesn't take into account enterprise distro backports." I have three files there- ric@iam:/sys/fs/ext4/features$ ls batched_discard lazy_itable_init meta_bg_resize ric@iam:/sys/fs/ext4/features$ Is this what he refers to? :) 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/542335cd.5070...@gmail.com
Re: systemd bug closed - next steps?
On Wed 24 Sep 2014 at 14:01:04 -0400, Steve Litt wrote: > On Wed, 24 Sep 2014 21:16:26 +0400 > Reco wrote: > > > Hi. > > > > On Wed, Sep 24, 2014 at 12:33:35PM -0400, Steve Litt wrote: > > > Look at it this way: If GNU wanted to stick stuff into their > > > compiler to reduce the utility of Linux, they would have done so > > > years ago. They never have. > > > > Or did they? > > > > http://lkml.iu.edu/hypermail/linux/kernel/1407.3/00650.html > > > > Reco > > The referenced URL looks like incompetance, not agenda. If the GNU > folks made their compiler require Python, that would be more akin to > what the systemd lobby, led by Red Hat, is doing. Chanting "Red Hat Conspirancy" to yourself before falling into a deep slumber is one thing. Convincing most other people it exists is a task which requires a little bit more. -- 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/24092014193256.611dbf5dc...@desktop.copernicus.demon.co.uk
Re: systemd bug closed - next steps?
On Wed, 24 Sep 2014 21:16:26 +0400 Reco wrote: > Hi. > > On Wed, Sep 24, 2014 at 12:33:35PM -0400, Steve Litt wrote: > > Look at it this way: If GNU wanted to stick stuff into their > > compiler to reduce the utility of Linux, they would have done so > > years ago. They never have. > > Or did they? > > http://lkml.iu.edu/hypermail/linux/kernel/1407.3/00650.html > > Reco The referenced URL looks like incompetance, not agenda. If the GNU folks made their compiler require Python, that would be more akin to what the systemd lobby, led by Red Hat, is doing. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- 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/20140924140104.367f2...@mydesq2.domain.cxm
Re: systemd bug closed - next steps?
On Wed 24 Sep 2014 at 12:33:35 -0400, Steve Litt wrote: > Look at it this way: If GNU wanted to stick stuff into their compiler > to reduce the utility of Linux, they would have done so years ago. They > never have. Redhat just did, bigtime. This is the Red Hat Conspiracy Theory. Does the promotion of blatent FUD ever stop? Why is it necessary to have to have a bogeyman? -- 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/24092014183435.0446517b4...@desktop.copernicus.demon.co.uk
Re: systemd bug closed - next steps?
Hi. On Wed, Sep 24, 2014 at 12:33:35PM -0400, Steve Litt wrote: > Look at it this way: If GNU wanted to stick stuff into their compiler > to reduce the utility of Linux, they would have done so years ago. They > never have. Or did they? http://lkml.iu.edu/hypermail/linux/kernel/1407.3/00650.html Reco -- 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/20140924171625.GA16565@x101h
Re: systemd bug closed - next steps?
On Wed, 24 Sep 2014 09:30:22 +0100 Jonathan Dowland wrote: > On Tue, Sep 23, 2014 at 12:58:26PM -0400, Steve Litt wrote: > > True, it's a single point of failure, but it's made by GNU, whose > > agenda is less harmful to Linux than the agenda of Redhat. > > I nearly choked on my coffee reading that. Redhat built their > business on Linux; GNU have been hostile towards it for years. Hi Jonathan, I think you're talking about the Redhat from the days of Robert Young. Robert Young, and the business he ran, were totally devoted to Linux and free software. Those days are gone. You mention that Redhat built their business on Linux. That's indisputable. And, starting in the days of Robert Young, they Embraced Linux. Now, with systemd, they've Extended Linux in ways that, from my perception, are bumping right up against most peoples' definition of Linux. I'm very worried about the third shoe dropping. As far as GNU hostility, that hostility goes only so far as: 1) They feel GNU should be given credit for most of its utilities being used together with the Linux kernel so to make a complete OS. All they ask is to call it GNU/Linux. 2) They have some licensing issues with some software used on GNU/Linux. 3) Stallman's a hostile kinda guy. Linux is nothing special :-) Look at it this way: If GNU wanted to stick stuff into their compiler to reduce the utility of Linux, they would have done so years ago. They never have. Redhat just did, bigtime. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- 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/20140924123335.4f92e...@mydesq2.domain.cxm
Re: systemd bug closed - next steps?
On Wed, Sep 24, 2014 at 9:36 PM, Reco wrote: > On Wed, Sep 24, 2014 at 09:30:22AM +0100, Jonathan Dowland wrote: >> On Tue, Sep 23, 2014 at 12:58:26PM -0400, Steve Litt wrote: >> > True, it's a single point of failure, but it's made by GNU, whose >> > agenda is less harmful to Linux than the agenda of Redhat. >> >> I nearly choked on my coffee reading that. Redhat built their business on >> Linux; GNU have been hostile towards it for years. > > And the most interesting thing is that for many years glibc was > maintained by Ulrich "Stop Reopening" Drepper who was paid by Red Hat > for this task :) > Glibc maintainer style was the main reason of glibc → eglibc transition > in Debian. Just for fun, I did a search on "gnu vs. redhat". One of the more amusing links that popped up: http://www.informit.com/library/content.aspx?b=red_hat_linux7&seqNum=12 Irony abounds. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. -- 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/CAAr43iOci2nUC1YD=_7oaCHuU+dv5Pev0zF6E7L=tavshmh...@mail.gmail.com
Re: systemd bug closed - next steps?
On Wed, Sep 24, 2014 at 09:30:22AM +0100, Jonathan Dowland wrote: > On Tue, Sep 23, 2014 at 12:58:26PM -0400, Steve Litt wrote: > > True, it's a single point of failure, but it's made by GNU, whose > > agenda is less harmful to Linux than the agenda of Redhat. > > I nearly choked on my coffee reading that. Redhat built their business on > Linux; GNU have been hostile towards it for years. And the most interesting thing is that for many years glibc was maintained by Ulrich "Stop Reopening" Drepper who was paid by Red Hat for this task :) Glibc maintainer style was the main reason of glibc → eglibc transition in Debian. Reco -- 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/20140924123631.GA6968@x101h
Re: systemd bug closed - next steps?
On Tue, Sep 23, 2014 at 12:58:26PM -0400, Steve Litt wrote: > True, it's a single point of failure, but it's made by GNU, whose > agenda is less harmful to Linux than the agenda of Redhat. I nearly choked on my coffee reading that. Redhat built their business on Linux; GNU have been hostile towards it for years. -- 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/20140924083022.GA25524@debian
Re: systemd bug closed - next steps?
On 09/23/2014 12:11 PM, Andrei POPESCU wrote: On Lu, 22 sep 14, 21:17:28, Marty wrote: 1) The goal is "modular Debian." Multi-init is the means to achieve it. Being tied to one init system is what caused Debian’s problems, and the replacement did not fix it. A modular system has to support all init systems, including systemd, clones and custom inits. While you're at it how about also making sure we can have a dietlibc or uClibc version of Debian? After all, depending on glibc is also not very good. Oh, and don't forget about udev and X.Org. There is already work in progress trying to compile Debian with something other than GCC, so you don't need to worry about that. Yes this is a joke, but only in part. It's very interesting how suddenly people are so worried about Debian being tied to one piece of software, while this has been happening all along. Kind regards, Andrei I don't think the problem is being tied to software, as much as the software one is being tied to, and the person(s) doing the tying. Anyway I intentionally did not propose to solve all the world's problems. That comes later. For now it's just a tiny bite-sized project well within the charter, that would at least suggest that adults are still in control. -- 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/54221a2f.3010...@ix.netcom.com
Re: systemd bug closed - next steps?
On Tue 23 Sep 2014 at 21:09:30 +0200, Erwan David wrote: > Le 23/09/2014 20:46, Brian a écrit : > > You do not like that systemd will be the default init system for Jessie. > > Tough. Exercise your choice not to have it. Or is easier to moan rather > > than just get on with using sysvinit? > > > > As for your link, you could at least have quoted a primary source, the > > mail from Joey Hess making the announcement. That way people could judge > > for themselves rather than relying on your inconsequential remarks. > > That's just not the behaviour of _something meant to be a "default" with > options. > First, we see that other packages become dependant on it, making the > "option" thing somewhat irrelevant. > > Next, other choices are done because of "integration" with systemd. > > Why ? why integration with a mere default choice among other choices > woud be relevant ? > Except if the agenda is *not* what was sold and agreed upon which was a > mere *default*. > > Sorry, but this kind of things just make suspicious. > > What will next step be ? Months ago I'd have written a mail advising you to install sysvinit-core and systemd-shim and given details. Now I am getting weary. Do and say what you want. It not will alter the fact that systemd will be the default init system on Jessie. -- 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/23092014203143.2f7000a68...@desktop.copernicus.demon.co.uk
Re: systemd bug closed - next steps?
Le 23/09/2014 20:46, Brian a écrit : > On Tue 23 Sep 2014 at 19:30:34 +0200, Erwan David wrote: > >> Compare it to to a init system which is the main reason to choose a >> desktop environment... >> >> See >> http://www.webupd8.org/2014/09/debian-switches-back-to-gnome-from-xfce.html >> >> >> So sytemd does in fact orient *everything*. You are not "integrated" >> into systemd, I am not sure debian will still be for you. >> >> That's the worse behaviuour of the worst commercial software vendor : >> wanting to lock usrers into what the vendor choose and denying them >> freedom to choose. > You do not like that systemd will be the default init system for Jessie. > Tough. Exercise your choice not to have it. Or is easier to moan rather > than just get on with using sysvinit? > > As for your link, you could at least have quoted a primary source, the > mail from Joey Hess making the announcement. That way people could judge > for themselves rather than relying on your inconsequential remarks. > > That's just not the behaviour of _something meant to be a "default" with options. First, we see that other packages become dependant on it, making the "option" thing somewhat irrelevant. Next, other choices are done because of "integration" with systemd. Why ? why integration with a mere default choice among other choices woud be relevant ? Except if the agenda is *not* what was sold and agreed upon which was a mere *default*. Sorry, but this kind of things just make suspicious. What will next step be ? -- 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/5421c56a.6090...@rail.eu.org
Re: systemd bug closed - next steps?
On Tue 23 Sep 2014 at 19:30:34 +0200, Erwan David wrote: > Compare it to to a init system which is the main reason to choose a > desktop environment... > > See > http://www.webupd8.org/2014/09/debian-switches-back-to-gnome-from-xfce.html > > > So sytemd does in fact orient *everything*. You are not "integrated" > into systemd, I am not sure debian will still be for you. > > That's the worse behaviuour of the worst commercial software vendor : > wanting to lock usrers into what the vendor choose and denying them > freedom to choose. You do not like that systemd will be the default init system for Jessie. Tough. Exercise your choice not to have it. Or is easier to moan rather than just get on with using sysvinit? As for your link, you could at least have quoted a primary source, the mail from Joey Hess making the announcement. That way people could judge for themselves rather than relying on your inconsequential remarks. -- 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/23092014193629.17b707508...@desktop.copernicus.demon.co.uk
Re: systemd bug closed - next steps?
On Tue 23 Sep 2014 at 13:40:02 -0400, Mike McGinn wrote: > > On Tuesday, September 23, 2014 12:54:44 Chris Bannister wrote: > > > > I just had a look and didn't realise how closely Debian is reliant on the > > C language! Surely, this can't be good! > > The entire kernel is written in C. A language is just a tool. That is like > saying "The sink was installed with a wrench! Surely, this can't be good!" I initially saw what you wrote as "The sink was installed with a wench!" Great, someone to do the washing up was my first thought. No such luck! I'm sure Chris Bannister sees C in the same light as you do. -- 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/20140923181941.gr4...@copernicus.demon.co.uk
Re: systemd bug closed - next steps?
On Tue 23 Sep 2014 at 12:58:26 -0400, Steve Litt wrote: > On Tue, 23 Sep 2014 19:11:03 +0300 > Andrei POPESCU wrote: > > Let's discuss your analogies... > > === Depending on glibc === > True, it's a single point of failure, but it's made by GNU, whose > agenda is less harmful to Linux than the agenda of Redhat. Misinformation. systemd is not in the control of or managed or developed by Red Hat, although it will, like Debian, contribute to it. I doubt you will retract the statement, though. > === udev === > Udev is one of the components that provide hot plugging. Take it out > and root needs to manually mount stuff. OK, that's a pain in the butt, > but it's limited. Most of us remember the days when you really had to > do a mount, as root, to read a thumb drive. Hassle? Yes. Comparable to > the invasiveness of a PID 1 whose most intimate details are necessary > to run the most mundane user apps? No. Running mc depends on what PID 1 is? Are you sure we are both using Debian? You are peddling more misinformation. I use pmount myself and do not see it as a hassle. Others want what they see as a more convenient method. They need udev. They're happy and I'm happy; it's only you who seems a bit miserable. Cheer up; you have the same choice as us available. (Next time, would you please do a question and answer session which bears some releationship to reality?). > === X.org === > First, no CLI program gives a flying flamingo about what GUI provider > is used: They don't access it. Systemd, on the other hand, has its > sticky little fingers in CLI and GUI alike. Second, by definition, a > GUI program must access GUI system software. There's no such definition > that CLI user identification must interact with part of PID 1's > package, nor that a GUI program know the intimate details of PID 1. I don't understand what you are trying to say here. You probably don't either. Not so much misinformation but a propagation of confusion. You did say you were involved in a plan to replace Jessie's default init system? Heaven help us. -- 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/20140923180707.gq4...@copernicus.demon.co.uk
Re: systemd bug closed - next steps?
On Tuesday, September 23, 2014 12:54:44 Chris Bannister wrote: > On Tue, Sep 23, 2014 at 07:11:03PM +0300, Andrei POPESCU wrote: > > On Lu, 22 sep 14, 21:17:28, Marty wrote: > > > 1) The goal is "modular Debian." Multi-init is the means to achieve > > > it. Being tied to one init system is what caused Debian’s problems, > > > and the replacement did not fix it. A modular system has to support > > > all init systems, including systemd, clones and custom inits. > > > > While you're at it how about also making sure we can have a dietlibc or > > uClibc version of Debian? After all, depending on glibc is also not very > > good. Oh, and don't forget about udev and X.Org. There is already work > > in progress trying to compile Debian with something other than GCC, so > > you don't need to worry about that. > > > > Yes this is a joke, but only in part. It's very interesting how suddenly > > people are so worried about Debian being tied to one piece of software, > > while this has been happening all along. > > I just had a look and didn't realise how closely Debian is reliant on the > C language! Surely, this can't be good! The entire kernel is written in C. A language is just a tool. That is like saying "The sink was installed with a wrench! Surely, this can't be good!" -- Mike McGinn KD2CNU Be happy that brainfarts don't smell. No electrons were harmed in sending this message, some were inconvenienced. ** Registered Linux User 377849 -- 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/201409231340.02412.mikemcg...@mcginnweb.net
Re: systemd bug closed - next steps?
Le 23/09/2014 18:58, Steve Litt a écrit : > On Tue, 23 Sep 2014 19:11:03 +0300 > Andrei POPESCU wrote: > >> On Lu, 22 sep 14, 21:17:28, Marty wrote: >>> 1) The goal is "modular Debian." Multi-init is the means to achieve >>> it. Being tied to one init system is what caused Debian’s problems, >>> and the replacement did not fix it. A modular system has to support >>> all init systems, including systemd, clones and custom inits. >> While you're at it how about also making sure we can have a dietlibc >> or uClibc version of Debian? After all, depending on glibc is also >> not very good. Oh, and don't forget about udev and X.Org. There is >> already work in progress trying to compile Debian with something >> other than GCC, so you don't need to worry about that. >> >> Yes this is a joke, but only in part. It's very interesting how >> suddenly people are so worried about Debian being tied to one piece >> of software, while this has been happening all along. > Let's discuss your analogies... > > === Depending on glibc === > True, it's a single point of failure, but it's made by GNU, whose > agenda is less harmful to Linux than the agenda of Redhat. > > === udev === > Udev is one of the components that provide hot plugging. Take it out > and root needs to manually mount stuff. OK, that's a pain in the butt, > but it's limited. Most of us remember the days when you really had to > do a mount, as root, to read a thumb drive. Hassle? Yes. Comparable to > the invasiveness of a PID 1 whose most intimate details are necessary > to run the most mundane user apps? No. > > === X.org === > First, no CLI program gives a flying flamingo about what GUI provider > is used: They don't access it. Systemd, on the other hand, has its > sticky little fingers in CLI and GUI alike. Second, by definition, a > GUI program must access GUI system software. There's no such definition > that CLI user identification must interact with part of PID 1's > package, nor that a GUI program know the intimate details of PID 1. > > SteveT > > Steve Litt* http://www.troubleshooters.com/ > Troubleshooting Training * Human Performance > > Compare it to to a init system which is the main reason to choose a desktop environment... See http://www.webupd8.org/2014/09/debian-switches-back-to-gnome-from-xfce.html So sytemd does in fact orient *everything*. You are not "integrated" into systemd, I am not sure debian will still be for you. That's the worse behaviuour of the worst commercial software vendor : wanting to lock usrers into what the vendor choose and denying them freedom to choose. -- 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/5421ae3a.5030...@rail.eu.org
Re: systemd bug closed - next steps?
On Tue, 23 Sep 2014 19:11:03 +0300 Andrei POPESCU wrote: > On Lu, 22 sep 14, 21:17:28, Marty wrote: > > > > 1) The goal is "modular Debian." Multi-init is the means to achieve > > it. Being tied to one init system is what caused Debian’s problems, > > and the replacement did not fix it. A modular system has to support > > all init systems, including systemd, clones and custom inits. > > While you're at it how about also making sure we can have a dietlibc > or uClibc version of Debian? After all, depending on glibc is also > not very good. Oh, and don't forget about udev and X.Org. There is > already work in progress trying to compile Debian with something > other than GCC, so you don't need to worry about that. > > Yes this is a joke, but only in part. It's very interesting how > suddenly people are so worried about Debian being tied to one piece > of software, while this has been happening all along. Let's discuss your analogies... === Depending on glibc === True, it's a single point of failure, but it's made by GNU, whose agenda is less harmful to Linux than the agenda of Redhat. === udev === Udev is one of the components that provide hot plugging. Take it out and root needs to manually mount stuff. OK, that's a pain in the butt, but it's limited. Most of us remember the days when you really had to do a mount, as root, to read a thumb drive. Hassle? Yes. Comparable to the invasiveness of a PID 1 whose most intimate details are necessary to run the most mundane user apps? No. === X.org === First, no CLI program gives a flying flamingo about what GUI provider is used: They don't access it. Systemd, on the other hand, has its sticky little fingers in CLI and GUI alike. Second, by definition, a GUI program must access GUI system software. There's no such definition that CLI user identification must interact with part of PID 1's package, nor that a GUI program know the intimate details of PID 1. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- 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/20140923125826.6633a...@mydesq2.domain.cxm
Re: systemd bug closed - next steps?
On Tue, Sep 23, 2014 at 07:11:03PM +0300, Andrei POPESCU wrote: > On Lu, 22 sep 14, 21:17:28, Marty wrote: > > > > 1) The goal is "modular Debian." Multi-init is the means to achieve > > it. Being tied to one init system is what caused Debian’s problems, > > and the replacement did not fix it. A modular system has to support > > all init systems, including systemd, clones and custom inits. > > While you're at it how about also making sure we can have a dietlibc or > uClibc version of Debian? After all, depending on glibc is also not very > good. Oh, and don't forget about udev and X.Org. There is already work > in progress trying to compile Debian with something other than GCC, so > you don't need to worry about that. > > Yes this is a joke, but only in part. It's very interesting how suddenly > people are so worried about Debian being tied to one piece of software, > while this has been happening all along. I just had a look and didn't realise how closely Debian is reliant on the C language! Surely, this can't be good! -- "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/20140923165444.GC22423@tal
Re: systemd bug closed - next steps?
On Lu, 22 sep 14, 21:17:28, Marty wrote: > > 1) The goal is "modular Debian." Multi-init is the means to achieve > it. Being tied to one init system is what caused Debian’s problems, > and the replacement did not fix it. A modular system has to support > all init systems, including systemd, clones and custom inits. While you're at it how about also making sure we can have a dietlibc or uClibc version of Debian? After all, depending on glibc is also not very good. Oh, and don't forget about udev and X.Org. There is already work in progress trying to compile Debian with something other than GCC, so you don't need to worry about that. Yes this is a joke, but only in part. It's very interesting how suddenly people are so worried about Debian being tied to one piece of software, while this has been happening all along. 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: systemd bug closed - next steps?
On 09/22/2014 05:07 AM, Jonathan Dowland wrote: Hi Rob, I saw the bug closed (via mail on -devel) and personally thought it shouldn't have been. However when considering next steps my advice would be to leave bugs alone for a short while and let things cool off. It's important and useful to file bugs, but that in and of itself doesn't solve problems - they just track problems. My advice, if you have spare time to spend on trying to get this problem solved, would be to think beyond the bug filing, and try to figure out which packages need to be modified in order to solve the problem. First you have to know what the design goals are. Without that, there can be no agreement on what packages have to be modified. I don't think anything less than multi-init support would be worth pursuing at this point. There are a number of well-know arguments for and against it so I won't repeat them. This is just a list of steps I think it will take to accomplish it: 1) The goal is "modular Debian." Multi-init is the means to achieve it. Being tied to one init system is what caused Debian’s problems, and the replacement did not fix it. A modular system has to support all init systems, including systemd, clones and custom inits. 2) All init systems, to support multi-init, will probably have to support sysvinit as a backwards compatibility option, and systemd unit/service files or a translator for future compatibility. 3) All services obsoleted by systemd (like login) must be supported at least until they can be upgraded or replaced. They may have to support some systemd features for compatibility reasons. 4) To have the slightest chance of succeeding, I think modular Debian packages will have to go into unstable soon and be in the next testing cycle. Time is against it and it be too late already. 5) It would be a massive project, but the individual tasks are small and modular. I think it could succeed with sufficient buy-in. Even systemd proponents can see the value of modular Debian, and will accept the challenge of maintaining a "universal operating system." -- 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/5420ca28.7010...@ix.netcom.com
Re: systemd bug closed - next steps?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/22/2014 at 05:39 AM, berenger.mo...@neutralite.org wrote: > Le 22.09.2014 01:51, John Hasler a écrit : > >> Martin Read writes: >> >>> consolekit is indeed the thing that systemd-logind replaces >>> (and systemd-logind was the reason the maintainers of >>> consolekit stopped maintaining it). >> >> So who is going to step forward and start maintaining it? > > Nobody needs to. systemd-login does *not* depends on the init > system. At no levels. So why should someone have to maintain an > alternative? (well, there are probably tons of reasons, indeed, but > systemd-login being a part of systemd is not a correct one since > login part does not depends on init part.) So I was remembering wrong, and the consolekit angle is apparently a false trail. The problem is not systemd-logind (except from the perspective of people who just don't want any systemd-project code on their systems in the first place), but the dependency from libpam-systemd on systemd-sysv. The fact that we went down that false trail is my fault. The question of "what did these packages do before systemd was available?" was asked, and I provided an incorrect answer, due to my faulty memory. I apologize for that mistake, for the ensuing confusion, and for any associated FUD. Revisiting that question now, it's not quite as simple as "before systemd was available". There are actually three timeframes to consider: 1. Now, with libpam-systemd depending on systemd-sysv (and thus on systemd being PID 1), as a source of cgroups management functionality. 2. The previous timeframe, with libpam-systemd not depending on systemd-sysv, because it provided its own cgroups management. 3. The timeframe preceding that one, with libpam-systemd not available at all. In timeframe 2, the packages in question depended on libpam-systemd, just as they now do. The only difference is that this dependency did not result in an indirect dependency on a particular init system. In timeframe 3, the packages in question did not depend on libpam-systemd, because it was not available. This would have to be confirmed by looking at the individual packages, but I strongly suspect that they simply did not provide the functionality which libpam-systemd now enables. The transition between timeframe 3 and timeframe 2 came when libpam-systemd became available, upstreams added support for the new features it provided, and package dependencies were added appropriately. There's nothing visibly wrong at this stage. The transition between timeframe 2 and timeframe 1 apparently occurred because of a decision by the Linux kernel's cgroups maintainer (or someone with a good claim at authority in that area, anyway) that having multiple programs maintaining multiple cgroups hierarchies - or having multiple programs writing to a single cgroups hierarchy - was bad design, and should no longer be supported at some point. In response to that, the sytemd project removed cgroups management from libpam-systemd, and made libpam-systemd rely on the cgroups management available in systemd-sysv (the PID-1 systemd). As a result, without having changed anything themselves, suddenly all of the packages which had already depended on libpam-systemd now indirectly depended on having systemd be PID 1. What I maintain / argue is that even assuming the kernel's cgroups maintainer's decision was correct (on which I have not yet established any opinion), the correct thing to do in response to that decision would not have been to move all systemd cgroups handling into PID 1 as the most central place where it was already implemented, but to move it all *out* of PID 1 into a separate, standalone daemon. (Or even library, if suitable.) This issue has already been worked around in Debian by the implementation of cgroups support in systemd-shim, using cgmanager. However, that's still a workaround, because the design flaw in having this feature be (primarily) provided by systemd itself is still present. It has been suggested (in filed bugs) that one of the primary consequences of this flaw - the automatic transition to systemd-as-PID-1 when installing packages which depend on libpam-systemd, while not already having systemd-shim installed - be minimized by expressing the dependency on that cgroups management as preferring systemd-shim (the "standalone" implementation) over systemd-sysv (the init-system-dependent implementation). The Debian systemd maintainers have rejected this suggestion, with reasonable arguments (albeit ones which I think are insufficient). There is presently TC discussion going on over whether or not to override that rejection. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUIBkVAAoJEA
Re: systemd bug closed - next steps?
On Mon, Sep 22, 2014 at 02:12:52PM CEST, Marty said: > On 09/22/2014 05:39 AM, berenger.mo...@neutralite.org wrote: > > > > > >Le 22.09.2014 01:51, John Hasler a écrit : > >>Martin Read writes: > >>>consolekit is indeed the thing that systemd-logind replaces (and > >>>systemd-logind was the reason the maintainers of consolekit stopped > >>>maintaining it). > >> > >>So who is going to step forward and start maintaining it? > > > >Nobody needs to. systemd-login does *not* depends on the init system. > >At no levels. So why should someone have to maintain an alternative? > >(well, there are probably tons of reasons, indeed, but systemd-login > >being a part of systemd is not a correct one since login part does not > >depends on init part.) > > So Debian won't do it, or maybe Red Hat. Not sure whose calling the shots > here. > > Nobody wants it, at least nobody who counts. It's not the business plan. Only upstream refuses to have a systemd-* without the init system. So it makles it dependent of the init system. Bad lick (or bad upstream ?) -- 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/20140922123406.ge16...@rail.eu.org
Re: systemd bug closed - next steps?
On 09/22/2014 05:39 AM, berenger.mo...@neutralite.org wrote: Le 22.09.2014 01:51, John Hasler a écrit : Martin Read writes: consolekit is indeed the thing that systemd-logind replaces (and systemd-logind was the reason the maintainers of consolekit stopped maintaining it). So who is going to step forward and start maintaining it? Nobody needs to. systemd-login does *not* depends on the init system. At no levels. So why should someone have to maintain an alternative? (well, there are probably tons of reasons, indeed, but systemd-login being a part of systemd is not a correct one since login part does not depends on init part.) So Debian won't do it, or maybe Red Hat. Not sure whose calling the shots here. Nobody wants it, at least nobody who counts. It's not the business plan. -- 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/54201244.8010...@ix.netcom.com
Re: systemd bug closed - next steps?
Le 22.09.2014 01:51, John Hasler a écrit : Martin Read writes: consolekit is indeed the thing that systemd-logind replaces (and systemd-logind was the reason the maintainers of consolekit stopped maintaining it). So who is going to step forward and start maintaining it? Nobody needs to. systemd-login does *not* depends on the init system. At no levels. So why should someone have to maintain an alternative? (well, there are probably tons of reasons, indeed, but systemd-login being a part of systemd is not a correct one since login part does not depends on init part.) -- 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/223ddf9bcfbbef1fdf7aa2741b827...@neutralite.org
Re: systemd bug closed - next steps?
Hi Rob, I saw the bug closed (via mail on -devel) and personally thought it shouldn't have been. However when considering next steps my advice would be to leave bugs alone for a short while and let things cool off. It's important and useful to file bugs, but that in and of itself doesn't solve problems - they just track problems. My advice, if you have spare time to spend on trying to get this problem solved, would be to think beyond the bug filing, and try to figure out which packages need to be modified in order to solve the problem. -- Jonathan Dowland -- 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/20140922090702.GA8355@debian
Re: systemd bug closed - next steps?
Martin Read writes: > consolekit is indeed the thing that systemd-logind replaces (and > systemd-logind was the reason the maintainers of consolekit stopped > maintaining it). So who is going to step forward and start maintaining it? -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- 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/8738bkedne@thumper.dhh.gt.org
Re: systemd bug closed - next steps?
On 21/09/14 23:47, The Wanderer wrote: I did mean policykit, but that's because I was talking about my understanding, which does have policykit in that slot. My understanding may well be wrong, and if so, consolekit may very well be what *should* go in that slot instead. consolekit is indeed the thing that systemd-logind replaces (and systemd-logind was the reason the maintainers of consolekit stopped maintaining 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/541f5a86.3080...@zen.co.uk
Re: systemd bug closed - next steps?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/21/2014 at 06:05 PM, Brian wrote: > On Sun 21 Sep 2014 at 14:40:13 -0400, The Wanderer wrote: > >> On 09/21/2014 at 01:37 PM, John Hasler wrote: >>> >>> What did those packages do for that functionality before >>> systemd existed? >> >> According to my understanding, either they depended on policykit >> (which used to provide such, or at least related, functionality, >> and which is now unsupported and may be unsuitable for other >> reasons as well), or they didn't yet include the features which >> that functionality enables. > > Is it possible you mean consolekit, not policykit? I did mean policykit, but that's because I was talking about my understanding, which does have policykit in that slot. My understanding may well be wrong, and if so, consolekit may very well be what *should* go in that slot instead. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUH1WFAAoJEASpNY00KDJrJhwQAJdx5bKN1sp7DbklhgvBDPfK Y6pt8l5+TV5A8JaoUeX9KrFvIdASzUsrU9chGVsYow+5MrSPSEB/wz4F7worvZhu 9WjoGX5RlxF2Nv3HDkH1Fn54ebVkLkOTkb+37yHBkaGZcqs5DUhhe8k1NhH2v3XC 6JWnyp/B5Z1zqb+68jDZk7KQY4GuPT4ACgHL1pRAXmdDi5TrH3M7LMqwlW3BdhlR UrZ1r73LsLslxisPiRDWBE6JjLWVEYl0LRgMUG8HtYxPZJbuiiG2/t8rc2XFb69d 16HzJiqSBN+86eAWrAa59juZDgUzvD/Jh3EBDB6yEpwDKAnW5I9z9p/7DoT1y828 GEb0+D3H57061voqhwobRHXCBD2P4SCdzka6pbArSjJplo+dBPRPieH9qaMC35M/ rHxbbQozJQNFHG/yiaWGObv6dvceOQeqFiBqGw8NorQm+mY12fMLLoG4mZ7zADJw ISMEXVwkP/nubko604yCpxhoKa03n8MlJYkWebm2SIGo7TKnqO3Bo6dXlYUzau5r 3qpsbNEfUgM6FZm0wweuDpwF+EKLsQ6eqQm7lU1JnAkgE7NRIr+D7KFU+SF/1CZj NU+xZo4iNTxa8o6QV3yEi0LQnJetD5tA/0FlWFR0oMLTb1kSw2TAxuI0HNjYq5QO 1VvPyUIAyaMOwvlwVHvj =2PtL -END PGP SIGNATURE- -- 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/541f5585.6010...@fastmail.fm
Re: systemd bug closed - next steps?
On Sun 21 Sep 2014 at 14:40:13 -0400, The Wanderer wrote: > On 09/21/2014 at 01:37 PM, John Hasler wrote: > > > > What did those packages do for that functionality before systemd > > existed? > > According to my understanding, either they depended on policykit (which > used to provide such, or at least related, functionality, and which is > now unsupported and may be unsuitable for other reasons as well), or > they didn't yet include the features which that functionality enables. Is it possible you mean consolekit, not policykit? -- 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/21092014230338.4f60b4682...@desktop.copernicus.demon.co.uk
Re: systemd bug closed - next steps?
On Sun 21 Sep 2014 at 18:08:58 +0100, Martin Read wrote: > As far as the Debian-related aspects of the matter are concerned, it > seems to me that it would not be unreasonable to file bugs against > sysvinit-core and upstart suggesting that they should have a > Recommends: reference to systemd-shim. A systemd-shim maintainer would disagree: > In that case, perhaps the alternate init systems should Recommend > systemd-shim? No, that's not the true package relationship. There's no reason that you should always get this added service by default when you install a system with non-systemd init that doesn't need logind. Making this a recommends would be a workaround for bad metadata in the libpam-systemd package; we should fix that problem at its source the right way. https://lists.debian.org/debian-devel/2014/09/msg00164.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/20140921220206.gm4...@copernicus.demon.co.uk
Re: systemd bug closed - next steps?
On Sun 21 Sep 2014 at 10:48:51 -0400, Rob Owens wrote: > Looking for advice from people in the know... > > I submitted a general bug regarding packages which require changing your > init system to systemd. I pointed out that this runs counter to > Debian's goals of supporting multiple init systems. The bug was closed > without fixing in a matter of hours. The title of the bug is "Some packages depend on a particular init system". Titles can be difficult to frame, so we won't hold you to it, and it can be altered later to reflect better the nature of the report. Anyway, the title doesn't look bad to me. In the body of the mail you set out your stall with This bug applies to many desktop applications, and runs counter to Debian's goals of supporting multiple init systems. I classified this bug as normal, but I think consideration should be given to classifying it as serious. and So installing a cd-burning application triggers a change of my init system. At this stage one would question on why the bug reporter seems to be unaware of apt-get install sysvinit-core systemd-shim when it has been advised many times as a practical measure to avoid the situation outlined. Issuing the command means that installing a cd-burning application does not trigger a change of the init system. So that is the claim that it "runs counter to Debian's goals of supporting multiple init systems" disposed of. But, hold on, he does know about systemd-shim! I know about systemd-shim, and I'll talk about that in a minute. and then goes on to venture the opinion (framed as a rhetorical question) But is systemd-shim really the solution we need to the problem above? So, at this stage we have a user who know how to solve his problem but wants to explore a different, completely unspecified course of action for unspecified reasons and in an unspecified way. The bug report has fallen apart; it is only heading into the realms of speculation. No sensible maintainer or triager is going to follow that route. wontfix or close?, that is the question. I'd go for close because there is nothing to fix. > Perhaps I didn't explain the bug well enough, or maybe I should have > submitted it elsewhere. I am hoping to get advice on what to do next, > or constructive criticism showing me where I went wrong. What to do next (possibly): 1. Accept the decision; graciously or ungraciously. 2. Read #746578 and #762194. 3. Reopen #762116 and merge it with #746578. -- 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/20140921190231.gk4...@copernicus.demon.co.uk
Re: systemd bug closed - next steps?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/21/2014 at 01:37 PM, John Hasler wrote: > The Wanderer writes: > >> Filing bugs about that against the packages which depend on that >> functionality, as advised in the mail closing the bug which this >> thread is about, is not productive; they don't control what >> provides the functionality they need. > > What did those packages do for that functionality before systemd > existed? According to my understanding, either they depended on policykit (which used to provide such, or at least related, functionality, and which is now unsupported and may be unsuitable for other reasons as well), or they didn't yet include the features which that functionality enables. I had a few drafts of a possibly extended rant on the latter point, explaining why there's nothing wrong with a program adding features to take advantage of external functionality. It was getting incoherent and reiterating points from my previous mail, however, so I decided to omit it. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUHxuNAAoJEASpNY00KDJrTm0P/iZ8t19BaAKvSyvN2+3xU+QX 6VrWYBam1Xi8JO1p+1sGaaTsfpSp1vAG+CGETvHWJ/jGWpiha83trev2rJMirH0N yX+DBH/LQibfLc9iybg2qQWVjqo0GcZ7mbssRRUbqTLd68oBayAPuYzh3Ijo8hz9 BfRt/VBBvyKPsaoL0dW3648Vq1Lmuvs5BZEA1cS20neRjzgvwoF1wJ0c9YjndinJ sll52A1fxYmJPiFvZwX1WPKLgaoijWJfmJAMQvERox6u3IDxyEOy3plVNBCnnVVz yA8VelnRHbmhE4BTQ5D0tnwMqWcuYkrY4hg4w9ejFmGwHMOFYIneGWm+/TeMxf8f A+lwFKpQkgOlQYCKzuBLK4HVB3X8GJoeMrHeuOaSniE1Llxc/KcHGmv7R02zkEEl Jo5Lm8LwS9eqlkfKnYWa/p0OPsNbqpaAOmloMJiT4dUDZNARZzWTp+gbbww3LVH9 diaCPD6Cp43mFPxlnw5gI/DyaWbpNiJKHU1CvLIEmcMl0CZFp605FRvQfocrC1pi mlww8idoYLpgEZvFWOBF23kedlsiV4ZRb2Qiw9YCAXhIlia3jJBHojaAEe36DZBU bXmO9Cq70lowjhxjHP0G5mT38+BvEbX4CUS5MhzG4cDnOYgCEHPQL3Byf5BjvNQ5 o7Wi5mok2kX1QgrhnfPI =VImq -END PGP SIGNATURE- -- 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/541f1b8d.6090...@fastmail.fm
Re: systemd bug closed - next steps?
The Wanderer writes: > Filing bugs about that against the packages which depend on that > functionality, as advised in the mail closing the bug which this > thread is about, is not productive; they don't control what provides > the functionality they need. What did those packages do for that functionality before systemd existed? -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- 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/87fvfkeuy4@thumper.dhh.gt.org
Re: systemd bug closed - next steps?
On 21/09/14 15:48, Rob Owens wrote: The bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762116 I think I agree with John Hasler in: https://lists.debian.org/debian-user/2014/09/msg01430.html that much of this is a matter of Debian package dependencies reflecting dependencies of the upstream design, and that filing bugs against Debian (either the "general" pseudo-package, or specific individual packages) is unlikely to be the most effective approach. As far as the Debian-related aspects of the matter are concerned, it seems to me that it would not be unreasonable to file bugs against sysvinit-core and upstart suggesting that they should have a Recommends: reference to systemd-shim. -- 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/541f062a.3090...@zen.co.uk
Re: systemd bug closed - next steps?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/21/2014 at 12:12 PM, John Hasler wrote: > Rob Owens writes: > >> I submitted a general bug regarding packages which require >> changing your init system to systemd. I pointed out that this >> runs counter to Debian's goals of supporting multiple init >> systems. > > No, it doesn't. Any individual package can depend on any other > package. Unfortunately, many upstreams are writing their code in > such a way as to require that when their software is packaged for > Debian the resulting package must depend on systemd features. How does this contradict the idea that having packages which require the use of a particular init system runs counter to the goal of supporting multiple init systems? The problem is specifically that the features which these upstreams want to depend on are provided by an init system. That should be rejected out of hand; any functionality which a separate project might legitimately want to depend on should not be provided (primarily or exclusively) by an init system, unless all init systems will necessarily provide that functionality. Filing bugs about that against the packages which depend on that functionality, as advised in the mail closing the bug which this thread is about, is not productive; they don't control what provides the functionality they need. Filing bugs about it against systemd - either in Debian or upstream - would be getting closer to the root of the problem, but would also not be productive; providing these features in the init system is an intentional design choice of systemd. It is also exactly what should be changed, but good luck getting anyone in the systemd project to agree to the idea of changing it. > The only solutions for this are to either convince upstream > authors to change their ways or to make other init systems able to > emulate systemd to the extent necessary. > > If you can find packages that gratuitously depend on systemd file > specific bugs against those packages. When the systemd dependency > is deeply embedded in the upstream source, though, there is > nothing the package maintainer can do about it. Just because there's nothing the (depending) package maintainer can do about it doesn't mean there isn't a bug, though. As I've argued before, the bug lies in the design stage, specifically in the decision to implement certain functionality in systemd rather than outside of it. The resulting behavior, in terms of packages which are not related to a particular init system but which will only work with that init system present, is undesirable and unnecessary - which seems like a decent enough mapping to "buggy", at least to me. Saying "Yes, it's a problem, but there's nothing we can do about it" would be one thing (although there *is* something which could be done about it, in terms of pushing back on systemd upstream). But saying "This isn't a bug" is very much another. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJUHwLCAAoJEASpNY00KDJrNzkQAIkrqWa/n001Yasrlb+E860N lrk71gSlESdOAvOR+iuxoYdi8E6F//ADuAePuSH4a9vxg6U9UiL80KjL9IZn2CGO cCbPRv+XqENsdmAFKXPVNZikxPG5Tien+YW8uHUWApnUDGa3lQoZiJr98A+1LaP/ Ga2kChuJDYKhCR1ceKoz710xPGvjqrp7jYl4H5l1I8nBpDw0omm3MBaGX4US5ugy bNWgN7MAMstUR44RMZCVHEsI3+SgjynQ4UW0nDQ+6MuVMY2ZacRHQx1M4aubZVvH 0QcOwLi3livCvuQvjXFMzrKprBr/iisWk18BTug8Fp+2vP12i+XgzdUDaegKdBGu 5DDPnwqqcC1kXZsWdRPA/1A1fNlsp1stVQyygYfQhtj2p20PMc1esOKIE/PHp246 84sbwtKH8SGoWlgVRZUNsosF4qbMjg0gznXqtk3V0LxYN2O0/oqZDk2iHJ7iwcuY fSkX/Ps8dH5N+N6kQkAFcQPjwJsUBriXaGA7zSWL+HuJChcJ6FYy877YsTQL75Lj 22JAJwaCO2Ml8PmLS4U+jLEvV7hK0OAiPDrR808T1Q13JmgRLS1XibvWyQTfko2l YnwjrC8bxkHnSZiWpPyU6s+s2JkGPvEHxiQvmpcVrW4oz9Nlyq2zNLYqpyR6DwXq 2JiCDfkEpC1yvHExMfuh =tWIr -END PGP SIGNATURE- -- 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/541f02c2.2040...@fastmail.fm
Re: systemd bug closed - next steps?
Rob Owens writes: > I submitted a general bug regarding packages which require changing > your init system to systemd. I pointed out that this runs counter to > Debian's goals of supporting multiple init systems. No, it doesn't. Any individual package can depend on any other package. Unfortunately, many upstreams are writing their code in such a way as to require that when their software is packaged for Debian the resulting package must depend on systemd features. The only solutions for this are to either convince upstream authors to change their ways or to make other init systems able to emulate systemd to the extent necessary. If you can find packages that gratuitously depend on systemd file specific bugs against those packages. When the systemd dependency is deeply embedded in the upstream source, though, there is nothing the package maintainer can do about it. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- 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/87mw9tdkbr@thumper.dhh.gt.org
