Re: complaints about systemd
I don't see the similarity. They are all files on a disk? :P Dean On 2014-10-22 00:32, Lennart Sorensen wrote: On Tue, Oct 21, 2014 at 11:47:51AM +1100, Dean Hamstead wrote: I think BSD style init is underrated. Controlling everything in rc.conf is wonderful :) Lets have that in Debian please? Next you will suggest config.sys and autoexec.bat are a good design too. :) -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/06acb2d7b1ae486923201319f84e8...@fragfest.com.au
Re: complaints about systemd
On 10/20/2014 05:28 PM, Christopher Browne wrote: While I wasn't keen on Upstart getting chosen, I think the page they prepared describing the merits of moving from SysVInit presents good points well. Sure, there is always merit to both sides of an argument. In the process of fighting about things, we gradually resort to deeper and sillier caricatures of the 'other side' and before ya know it, things get stupid. Unfortunately, the current goings-on seem to risk being free of technical content, and fodder for flame warring. And that's what should be resisted at all costs. It must be about merit. I guess I find myself displeased with certain technical points (e.g. - claims of 1s boot time, that seem invalidated), but I'm usually finding things working on my systems that have SystemD. So far, I can't establish, from my own observations, that "different" == "bad". Experienced people tend to have a natural gut level distrust of anything new-fangled, often not without reason. Still, almost everyone agrees that the old sysV needed a brush up, so what's next? Surely the best possible thing would be to address the problems with 'D' without abandoning it altogether? The alternative systems don't seem to have any huge enthusiasm behind them. Anyway, I sure hope it doesn't come down to a schism. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5446b0ec.3070...@eastlink.ca
Re: complaints about systemd
On Tue, Oct 21, 2014 at 11:47:51AM +1100, Dean Hamstead wrote: > I think BSD style init is underrated. Controlling everything in rc.conf > is wonderful :) > > Lets have that in Debian please? Next you will suggest config.sys and autoexec.bat are a good design too. :) -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021133211.ge24...@csclub.uwaterloo.ca
Re: complaints about systemd
I think BSD style init is underrated. Controlling everything in rc.conf is wonderful :) Lets have that in Debian please? Dean On 2014-10-21 11:28, Christopher Browne wrote: > On 17 October 2014 18:51, Ray Andrews wrote: > >> On 10/17/2014 02:38 PM, Christopher Browne wrote: >> >> On 9 October 2014 19:49, Lennart Sorensen >> wrote: >>> >>> On Thu, Oct 09, 2014 at 09:25:23AM -0700, Ray Andrews wrote: Can *anything* justify creating a problem that can't be debugged? >>> I suppose that this invalidates one of the functionality claims that was >>> part >>> of the basis for adoption... >> >>> Specifically... >> >>> https://wiki.debian.org/Debate/initsystem/systemd [1] >> >> Well, they certainly write a glowing review of themselves, do they not? >> That's a very well written and convincing doc, but it does seem that not >> enough attention has been paid to the issues that have been raised here. > > Well, it stands to reason that when they were promoting the notion of being > a replacement for SysVInit, they'd put the best face forward. > > And everybody *did* get opportunity to put a face-of-choice forward. > https://wiki.debian.org/Debate/initsystem [2] > > While I wasn't keen on Upstart getting chosen, I think the page they prepared > describing the merits of moving from SysVInit presents good points well. > >> On my system I get strange messages about 'start jobs' and 'stop jobs' which >> come with one minute, thirty second countdowns. I don't know why it has to >> be 90 seconds, would 60 seconds not do the trick? 30 seconds just totally >> wrong? > > Based on the sales job that quotes startup time as 1 second, for there to be > something that takes more than 1 second seems like a severe matter. > >> Still, the big question is: are these fixable glitches and bugs, or do they >> point >> to those deeper, fundamental problems that we've talked about? >> >> But, to be devil's advocate: One thing about the systemd doc above that >> struck me >> as a sound argument was that starting a service is ... starting a service, >> and that >> whereas that mostly happens at init, it makes sense that whatever code/method >> is used to do it at init may as well be used generally. No? > Unfortunately, the current goings-on seem to risk being free of technical > content, > and fodder for flame warring. > > I guess I find myself displeased with certain technical points > (e.g. - claims of 1s boot time, that seem invalidated), but I'm usually > finding > things working on my systems that have SystemD. So far, I can't establish, > from > my own observations, that "different" == "bad". > > -- > When confronted by a difficult problem, solve it by reducing it to the > question, "How would the Lone Ranger handle this?" Links: -- [1] https://wiki.debian.org/Debate/initsystem/systemd [2] https://wiki.debian.org/Debate/initsystem
Re: complaints about systemd
On 17 October 2014 18:51, Ray Andrews wrote: > On 10/17/2014 02:38 PM, Christopher Browne wrote: > > On 9 October 2014 19:49, Lennart Sorensen wrote: >> >> On Thu, Oct 09, 2014 at 09:25:23AM -0700, Ray Andrews wrote: >> > Can *anything* justify creating a problem that can't be debugged? >> I suppose that this invalidates one of the functionality claims that was part >> of the basis for adoption... > >> Specifically... > >> https://wiki.debian.org/Debate/initsystem/systemd > > Well, they certainly write a glowing review of themselves, do they not? > That's a very well written and convincing doc, but it does seem that not > enough attention has been paid to the issues that have been raised here. Well, it stands to reason that when they were promoting the notion of being a replacement for SysVInit, they'd put the best face forward. And everybody *did* get opportunity to put a face-of-choice forward. https://wiki.debian.org/Debate/initsystem While I wasn't keen on Upstart getting chosen, I think the page they prepared describing the merits of moving from SysVInit presents good points well. > On my system I get strange messages about 'start jobs' and 'stop jobs' which > come with one minute, thirty second countdowns. I don't know why it has to > be 90 seconds, would 60 seconds not do the trick? 30 seconds just totally wrong? Based on the sales job that quotes startup time as 1 second, for there to be something that takes more than 1 second seems like a severe matter. > Still, the big question is: are these fixable glitches and bugs, or do they point > to those deeper, fundamental problems that we've talked about? > > But, to be devil's advocate: One thing about the systemd doc above that struck me > as a sound argument was that starting a service is ... starting a service, and that > whereas that mostly happens at init, it makes sense that whatever code/method > is used to do it at init may as well be used generally. No? Unfortunately, the current goings-on seem to risk being free of technical content, and fodder for flame warring. I guess I find myself displeased with certain technical points (e.g. - claims of 1s boot time, that seem invalidated), but I'm usually finding things working on my systems that have SystemD. So far, I can't establish, from my own observations, that "different" == "bad". -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
Re: complaints about systemd
On 10/17/2014 02:38 PM, Christopher Browne wrote: On 9 October 2014 19:49, Lennart Sorensen mailto:lsore...@csclub.uwaterloo.ca>> wrote: On Thu, Oct 09, 2014 at 09:25:23AM -0700, Ray Andrews wrote: > Can *anything* justify creating a problem that can't be debugged? I noticed on a reboot yesterday that there was a 5 minute countdown shutting down samba by the looks of it. Seems to be bug #762002. I suppose that this invalidates one of the functionality claims that was part of the basis for adoption... Specifically... https://wiki.debian.org/Debate/initsystem/systemd Well, they certainly write a glowing review of themselves, do they not? That's a very well written and convincing doc, but it does seem that not enough attention has been paid to the issues that have been raised here. On my system I get strange messages about 'start jobs' and 'stop jobs' which come with one minute, thirty second countdowns. I don't know why it has to be 90 seconds, would 60 seconds not do the trick? 30 seconds just totally wrong? Still, the big question is: are these fixable glitches and bugs, or do they point to those deeper, fundamental problems that we've talked about? But, to be devil's advocate: One thing about the systemd doc above that struck me as a sound argument was that starting a service is ... starting a service, and that whereas that mostly happens at init, it makes sense that whatever code/method is used to do it at init may as well be used generally. No?
Re: complaints about systemd
On 9 October 2014 19:49, Lennart Sorensen wrote: > On Thu, Oct 09, 2014 at 09:25:23AM -0700, Ray Andrews wrote: > > Can *anything* justify creating a problem that can't be debugged? > > I noticed on a reboot yesterday that there was a 5 minute countdown > shutting down samba by the looks of it. Seems to be bug #762002. I suppose that this invalidates one of the functionality claims that was part of the basis for adoption... Specifically... https://wiki.debian.org/Debate/initsystem/systemd "Systemd is incredibly fast (1 second to boot). It was not designed with speed in mind, but doing things correctly avoids all the delays currently incurred by the boot process." If there are conditions where it takes 5 minutes, that's a pretty clear indication of falsity... I should think that there may be acceptable counterexamples, but it should be decently documented as to what kinds of cases are expected to fail to be quick. I would think that part of the process of arguing that Debian should "roll back" the SystemD change involves going back to the debate material, and demonstrating that there are claims about the behaviour of SystemD that are materially wrong. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
Re: complaints about systemd
On Thu, Oct 09, 2014 at 08:11:57AM -0700, Ray Andrews wrote: > On 10/09/2014 02:41 AM, Tomasz Kundera wrote: > identified, and some real solutions offered, but it looks to me like systemd > needs a sober re-think. Sometimes we really can be too clever for our own > good. It is not "clever" to make things unnecessarily complex. Nor clever to ignore good computer science. Sorry, I know what you/OP meant, but let's try not to degrade language. ael -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141010134446.GA12534@shelf.conquest
Re: complaints about systemd
On Thu, Oct 09, 2014 at 09:25:23AM -0700, Ray Andrews wrote: > Can *anything* justify creating a problem that can't be debugged? I noticed on a reboot yesterday that there was a 5 minute countdown shutting down samba by the looks of it. Seems to be bug #762002. > Again, bedrock principles: > > "Do one thing, and do it well." > "Keep entanglements to a minimum". > "Keep everything as modular as possible." > > How can it even be considered that a desktop is somehow entangled > with an init system? > Supposing I bought a new fridge, and found my stove no longer worked? > Supposing I bought a new car from Toyota but it could only run on > Toyota gas? That would certainly be unreasonable too. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009234920.gb4...@csclub.uwaterloo.ca
Re: complaints about systemd
On 10/09/2014 08:46 AM, Giacomo Mulas wrote: On Thu, 9 Oct 2014, Ray Andrews wrote: From what I've read about the history and philosophy of all 'nix, I thought it was a bedrock rule that primary inputs and outputs *must* be text. Especially any sort of error log! To abandon that is to travel down the road to Redmond, is it not? Mr. Poettering seems to be a very clever lad, and it seems that some real deficiencies in the old init have been identified, and some real solutions offered, but it looks to me like systemd needs a sober re-think. Sometimes we really can be too clever for our own good. I could not write it any better than this, I agree with every word. Also, I have the same very annoying behaviour on several machines that shutdown hangs forever (or for a very long time), and in the end I frequently end up pushing the power button. That is happening here, also. Can *anything* justify a reduction in stability? This began to happen with systemd, and it is horribly difficult to debug: shutdown hangs after syslog was stopped, so the only way to get some decent debug info is (would have been in SystemV times) have the scripts dump a lot of info in text files, and then read them. Now, with systemd, how do you go about debugging this? Can *anything* justify creating a problem that can't be debugged? I second this: systemd has some good points, but the price tag is unreasonably high. And, most importantly, there should be some real choice, it should not be as deeply embedded as a dependency into many completely unrelated things: what does a desktop environment have to do with the init system? why on earth should gnome or any other desktop environment depend on systemd and be somewhat broken, or even uninstallable, without it? Again, bedrock principles: "Do one thing, and do it well." "Keep entanglements to a minimum". "Keep everything as modular as possible." How can it even be considered that a desktop is somehow entangled with an init system? Supposing I bought a new fridge, and found my stove no longer worked? Supposing I bought a new car from Toyota but it could only run on Toyota gas? Had I wanted this kind of overclever stuff, in which everything "magically" (sort of) works but at the price of being a nightmare to customize/debug, I would have installed ubuntu, not debian! Pretty please... Giacomo -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5436b6f3.3070...@eastlink.ca
Re: complaints about systemd
On Thu, Oct 09, 2014 at 11:41:55AM +0200, Tomasz Kundera wrote: > I'd like to say "me too" as the shortest opinion. Dealing with local >networks it is absolutely not important how much time the boot takes. Most >machines works all the time. During maintenance reboots I can wait a few >seconds more. But the complete lack of simplicity and transparency is >horrible. Binary logs are horrible, too. Logs are mostly needed when some >troubles arises. In that situation they should be accessible as easy and >fast as possible. Often there will be no possibility to start a dedicated >binary log analyzer. You need only "more" and "sed" to deal with text >logs. systemd with no possibility to stay with SystemV is a horrible >mistake. If you can start "more" or "sed" you should be able to start "journalctl". But them again, that probably won't help as, by default, Debian doesn't write the journal to disk (that's the syslogd's job and that writes in the familiar (if inconsistent) text format). >On Wed, Oct 8, 2014 at 10:25 PM, Ray Andrews <[1]rayandr...@eastlink.ca> >wrote: > > On 10/08/2014 12:39 PM, ael wrote: > >On Wed, Oct 08, 2014 at 03:32:58PM +0200, Michael wrote: > > The new system reduces some complexity on one side while introducing > much more on the other. > >The whole design so far as I can see lacks the simplicity and >transparency that the greatest minds in computer science advocate. > >That seems to be confirmed in that systemd is more or less permanently >broken, ... > > I don't know enough to weigh in on this, but I spent the morning > researching the subject and it does seem like this is no small issue. I > myself am deeply troubled by what I read, it seems that cleverness has > replaced level-headedness, wiz-bang technology has replaced simplicity > and transparency, and featureitis has replaced stability. I hope this > gets sorted out. Me, I want my computer to boot reliably, and I > wouldn't care even if it did take 2 seconds longer, and I want to be > able to understand and even edit how it works. But that's just me. > >at least on all my machines. It takes *far longer* to boot up >and particularly shutdown than ever the old init system did. >I have given up even thinking about bug reporting it: what do I say? >Where are the logs that throw any light on the system problems? >Which bug do I report when it changes from day to day? > >I suspect that many others are in a similar situation, so that the bug >tracking doesn't reflect the real situation. > >All of that said, some of the underlying design ideas are good, but >particulary concurrent systems need that simplicity and transparency, >and >the technology to do it exists if little used. > >ael > > -- > To UNSUBSCRIBE, email to [2]debian-amd64-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > [3]listmas...@lists.debian.org > Archive: [4]https://lists.debian.org/54359d9d.5070...@eastlink.ca > >-- >Tomasz Kundera > > References > >Visible links >1. mailto:rayandr...@eastlink.ca >2. mailto:debian-amd64-requ...@lists.debian.org >3. mailto:listmas...@lists.debian.org >4. https://lists.debian.org/54359d9d.5070...@eastlink.ca signature.asc Description: Digital signature
Re: complaints about systemd
On Thu, 9 Oct 2014, Ray Andrews wrote: From what I've read about the history and philosophy of all 'nix, I thought it was a bedrock rule that primary inputs and outputs *must* be text. Especially any sort of error log! To abandon that is to travel down the road to Redmond, is it not? Mr. Poettering seems to be a very clever lad, and it seems that some real deficiencies in the old init have been identified, and some real solutions offered, but it looks to me like systemd needs a sober re-think. Sometimes we really can be too clever for our own good. I could not write it any better than this, I agree with every word. Also, I have the same very annoying behaviour on several machines that shutdown hangs forever (or for a very long time), and in the end I frequently end up pushing the power button. This began to happen with systemd, and it is horribly difficult to debug: shutdown hangs after syslog was stopped, so the only way to get some decent debug info is (would have been in SystemV times) have the scripts dump a lot of info in text files, and then read them. Now, with systemd, how do you go about debugging this? I second this: systemd has some good points, but the price tag is unreasonably high. And, most importantly, there should be some real choice, it should not be as deeply embedded as a dependency into many completely unrelated things: what does a desktop environment have to do with the init system? why on earth should gnome or any other desktop environment depend on systemd and be somewhat broken, or even uninstallable, without it? Had I wanted this kind of overclever stuff, in which everything "magically" (sort of) works but at the price of being a nightmare to customize/debug, I would have installed ubuntu, not debian! Pretty please... Giacomo -- _ Giacomo Mulas _ INAF - Osservatorio Astronomico di Cagliari via della scienza 5 - 09047 Selargius (CA) tel. +39 070 71180244 mob. : +39 329 6603810 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1410091735420.17...@capitanata.oa-cagliari.inaf.it
Re: complaints about systemd
On 10/09/2014 02:41 AM, Tomasz Kundera wrote: I'd like to say "me too" as the shortest opinion. Dealing with local networks it is absolutely not important how much time the boot takes. Most machines works all the time. During maintenance reboots I can wait a few seconds more. But the complete lack of simplicity and transparency is horrible. Binary logs are horrible, too. Logs are mostly needed when some troubles arises. In that situation they should be accessible as easy and fast as possible. Often there will be no possibility to start a dedicated binary log analyzer. You need only "more" and "sed" to deal with text logs. systemd with no possibility to stay with SystemV is a horrible mistake. From what I've read about the history and philosophy of all 'nix, I thought it was a bedrock rule that primary inputs and outputs *must* be text. Especially any sort of error log! To abandon that is to travel down the road to Redmond, is it not? Mr. Poettering seems to be a very clever lad, and it seems that some real deficiencies in the old init have been identified, and some real solutions offered, but it looks to me like systemd needs a sober re-think. Sometimes we really can be too clever for our own good. https://www.youtube.com/watch?v=xos2MnVxe-c -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5436a5bd.2040...@eastlink.ca
Re: complaints about systemd
What I find most frustrating of all is that there are LOTS of valid concerns for the use of systemd but that it is coming out at the point of implementation. I am sure I am a bit out of the loop with with daily tasks etc but this kinda seems like it came out of nowhere destined for integration without even a simple PROS and CONS being done in it's design phase. The CONCEPT of systemd sounds great but the implementation/design has more "easy" to notice holes that it makes you wonder what else has been overlooked with it... Would personally like to express a "me too" to all the comments on this thread so far as they sum up my concerns of simplicity, transparency and accessibility in regards to system start up and logging. On Thu, Oct 9, 2014 at 5:41 AM, Tomasz Kundera wrote: > I'd like to say "me too" as the shortest opinion. Dealing with local > networks it is absolutely not important how much time the boot takes. Most > machines works all the time. During maintenance reboots I can wait a few > seconds more. But the complete lack of simplicity and transparency is > horrible. Binary logs are horrible, too. Logs are mostly needed when some > troubles arises. In that situation they should be accessible as easy and > fast as possible. Often there will be no possibility to start a dedicated > binary log analyzer. You need only "more" and "sed" to deal with text logs. > systemd with no possibility to stay with SystemV is a horrible mistake. > > On Wed, Oct 8, 2014 at 10:25 PM, Ray Andrews > wrote: > >> On 10/08/2014 12:39 PM, ael wrote: >> >>> On Wed, Oct 08, 2014 at 03:32:58PM +0200, Michael wrote: >>> The new system reduces some complexity on one side while introducing much more on the other. >>> The whole design so far as I can see lacks the simplicity and >>> transparency that the greatest minds in computer science advocate. >>> >>> That seems to be confirmed in that systemd is more or less permanently >>> broken, ... >>> >> I don't know enough to weigh in on this, but I spent the morning >> researching the subject and it does seem like this is no small issue. I >> myself am deeply troubled by what I read, it seems that cleverness has >> replaced level-headedness, wiz-bang technology has replaced simplicity and >> transparency, and featureitis has replaced stability. I hope this gets >> sorted out. Me, I want my computer to boot reliably, and I wouldn't care >> even if it did take 2 seconds longer, and I want to be able to understand >> and even edit how it works. But that's just me. >> >> >> at least on all my machines. It takes *far longer* to boot up >>> and particularly shutdown than ever the old init system did. >>> I have given up even thinking about bug reporting it: what do I say? >>> Where are the logs that throw any light on the system problems? >>> Which bug do I report when it changes from day to day? >>> >>> I suspect that many others are in a similar situation, so that the bug >>> tracking doesn't reflect the real situation. >>> >>> All of that said, some of the underlying design ideas are good, but >>> particulary concurrent systems need that simplicity and transparency, and >>> the technology to do it exists if little used. >>> >>> ael >>> >>> >>> >> >> -- >> To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact >> listmas...@lists.debian.org >> Archive: https://lists.debian.org/54359d9d.5070...@eastlink.ca >> >> > > > -- > Tomasz Kundera >
Re: complaints about systemd
I'd like to say "me too" as the shortest opinion. Dealing with local networks it is absolutely not important how much time the boot takes. Most machines works all the time. During maintenance reboots I can wait a few seconds more. But the complete lack of simplicity and transparency is horrible. Binary logs are horrible, too. Logs are mostly needed when some troubles arises. In that situation they should be accessible as easy and fast as possible. Often there will be no possibility to start a dedicated binary log analyzer. You need only "more" and "sed" to deal with text logs. systemd with no possibility to stay with SystemV is a horrible mistake. On Wed, Oct 8, 2014 at 10:25 PM, Ray Andrews wrote: > On 10/08/2014 12:39 PM, ael wrote: > >> On Wed, Oct 08, 2014 at 03:32:58PM +0200, Michael wrote: >> >>> The new system reduces some complexity on one side while introducing >>> much more on the other. >>> >> The whole design so far as I can see lacks the simplicity and >> transparency that the greatest minds in computer science advocate. >> >> That seems to be confirmed in that systemd is more or less permanently >> broken, ... >> > I don't know enough to weigh in on this, but I spent the morning > researching the subject and it does seem like this is no small issue. I > myself am deeply troubled by what I read, it seems that cleverness has > replaced level-headedness, wiz-bang technology has replaced simplicity and > transparency, and featureitis has replaced stability. I hope this gets > sorted out. Me, I want my computer to boot reliably, and I wouldn't care > even if it did take 2 seconds longer, and I want to be able to understand > and even edit how it works. But that's just me. > > > at least on all my machines. It takes *far longer* to boot up >> and particularly shutdown than ever the old init system did. >> I have given up even thinking about bug reporting it: what do I say? >> Where are the logs that throw any light on the system problems? >> Which bug do I report when it changes from day to day? >> >> I suspect that many others are in a similar situation, so that the bug >> tracking doesn't reflect the real situation. >> >> All of that said, some of the underlying design ideas are good, but >> particulary concurrent systems need that simplicity and transparency, and >> the technology to do it exists if little used. >> >> ael >> >> >> > > -- > To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: https://lists.debian.org/54359d9d.5070...@eastlink.ca > > -- Tomasz Kundera
Re: complaints about systemd
I will weigh in. In the FOSS world - I could care less what people decide to code up and run. If you like it, go for it. Scratch that itch and share your code. I liked the look of systemd early on, but this was in comparison to upstart. Debian's dash based init scripts always struck me as well thought out and robust. For people with energy and inclination to radically change things, might I suggest two areas far more important than merging everything with init: 1. proper use of cpu rings 2. unified hardware raid interfaces and corresponding cli tools Ok perhaps #2 isnt widely impacting. But OpenBSD has done it, i am still baffled that Linux is such a mess. Dean On 2014-10-09 07:25, Ray Andrews wrote: On 10/08/2014 12:39 PM, ael wrote: On Wed, Oct 08, 2014 at 03:32:58PM +0200, Michael wrote: The new system reduces some complexity on one side while introducing much more on the other. The whole design so far as I can see lacks the simplicity and transparency that the greatest minds in computer science advocate. That seems to be confirmed in that systemd is more or less permanently broken, ... I don't know enough to weigh in on this, but I spent the morning researching the subject and it does seem like this is no small issue. I myself am deeply troubled by what I read, it seems that cleverness has replaced level-headedness, wiz-bang technology has replaced simplicity and transparency, and featureitis has replaced stability. I hope this gets sorted out. Me, I want my computer to boot reliably, and I wouldn't care even if it did take 2 seconds longer, and I want to be able to understand and even edit how it works. But that's just me. at least on all my machines. It takes *far longer* to boot up and particularly shutdown than ever the old init system did. I have given up even thinking about bug reporting it: what do I say? Where are the logs that throw any light on the system problems? Which bug do I report when it changes from day to day? I suspect that many others are in a similar situation, so that the bug tracking doesn't reflect the real situation. All of that said, some of the underlying design ideas are good, but particulary concurrent systems need that simplicity and transparency, and the technology to do it exists if little used. ael -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/16dcab9115d4e70928b8186addb51...@fragfest.com.au
Re: complaints about systemd
On 10/08/2014 12:39 PM, ael wrote: On Wed, Oct 08, 2014 at 03:32:58PM +0200, Michael wrote: The new system reduces some complexity on one side while introducing much more on the other. The whole design so far as I can see lacks the simplicity and transparency that the greatest minds in computer science advocate. That seems to be confirmed in that systemd is more or less permanently broken, ... I don't know enough to weigh in on this, but I spent the morning researching the subject and it does seem like this is no small issue. I myself am deeply troubled by what I read, it seems that cleverness has replaced level-headedness, wiz-bang technology has replaced simplicity and transparency, and featureitis has replaced stability. I hope this gets sorted out. Me, I want my computer to boot reliably, and I wouldn't care even if it did take 2 seconds longer, and I want to be able to understand and even edit how it works. But that's just me. at least on all my machines. It takes *far longer* to boot up and particularly shutdown than ever the old init system did. I have given up even thinking about bug reporting it: what do I say? Where are the logs that throw any light on the system problems? Which bug do I report when it changes from day to day? I suspect that many others are in a similar situation, so that the bug tracking doesn't reflect the real situation. All of that said, some of the underlying design ideas are good, but particulary concurrent systems need that simplicity and transparency, and the technology to do it exists if little used. ael -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54359d9d.5070...@eastlink.ca
Re: complaints about systemd
On Wed, Oct 08, 2014 at 03:32:58PM +0200, Michael wrote: > The new system reduces some complexity on one side while introducing much > more on the other. The whole design so far as I can see lacks the simplicity and transparency that the greatest minds in computer science advocate. That seems to be confirmed in that systemd is more or less permanently broken, at least on all my machines. It takes *far longer* to boot up and particularly shutdown than ever the old init system did. I have given up even thinking about bug reporting it: what do I say? Where are the logs that throw any light on the system problems? Which bug do I report when it changes from day to day? I suspect that many others are in a similar situation, so that the bug tracking doesn't reflect the real situation. All of that said, some of the underlying design ideas are good, but particulary concurrent systems need that simplicity and transparency, and the technology to do it exists if little used. ael -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141008193947.GA29092@shelf.conquest
Re: complaints about systemd
After having read much of the stuff available online (including parts of Lennart Poetterings blog), it appears that the essential point of it all seems to have been to make boot up a little faster. Bit i have a strong feeling that just a few seconds faster boot up simply do not justify the heavy impact. The new systemd is by no means easier to maintain or customize, or even just to grok in the first place, with binary logs, abandoned script format (no more init scripts), providing a temporary hardware base - like sockets or autofs mounts - for later daemons (so you have to configure 2 different places now), and so many backward dependencies that it soon (already?) will be impossible to don't use it. And even trivial updates may need a reboot now. The new system reduces some complexity on one side while introducing much more on the other. It will make Linux a lot less attractive for people who want to work with it as developer, or distributor, finally cutting its dev base. Unfortunately, these few seconds were just about all that normal users recognize, and thus they constantly nagged their favorite distributions to make the move. I can very well imagine how just these few seconds are also the most impressing argument to be presented to the Red Hat board, which anyway never had the time to dive into details of pros and cons. They want the summary. In Lennarts presentation, those seconds probably were the killing measure of success. Making the developer inexchangeable... I can't help but it reminds me of the way city govs pay horrible sums for planting huge trees, to have a visual result immediately. Faster is always better ! As a tree biologist, i know how these trees are grown in nurseries, cutting their roots dozen times to football size, and how they are doomed to crank many years later, shortening their life span - of course, with additional cut-down and exchange costs. For all my life, so far, i was growing and planting trees, and for some time, was part time working to cut the unlucky ones down, and i should know the money involved. But in the budget plans, there's simply no connection between nursery, planting, and replacing. There's simply no one judging about it in synopsis of decades. It's all about now and here. Right now i see such a thing happening now and here in the linux world, too. It gives me the creeps. I'd insist to know who ever complained about a few seconds boot up if there was no knowledge of any faster alternative. Is there any real problem behind it ? Like, for my 4 y old PC desktop (which, besides, boot up in 7 seconds with some customized sysv init) or for way too old hardware which always needs too long either way ? Is there a problem in server farms ? In laptops or smartphones which anyway got hibernated most of the time, instead of a reboot ? If my first task of the day is to boot my whatever-device, what for would i need these spared seconds. Just because they exist, would i wait, and get my first whatsapp, even before doing anything else, like going for a coffee ? Am i addicted like 'Did you already watch your boot up today ?' Instead of doing something useful in parallel, which spares me just this time. But wait, wasn't parallelizing one of the core issues. Or was it hypnotizing, ugh, i just can't remember. That said, i don't deny that systemd contains some good ideas. But they should be implemented in the respective (daemon/subsystem) packages, and in a smart 'launchd' which does not need to be more than that. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141008153258.7e193...@mirrors.kernel.org
Re: complaints about systemd
On Sun, Aug 10, 2014 at 03:17:44PM +0200, Michael wrote: > There were several problems, like with shut down, when sound card state > should be saved but created a guru. Sometimes it didn't even boot because > some ACPI thing stuck. Also my reboot / shutdown keys did not work anymore. I > did not have these problems with sysvinit and now they seem to be gone again. I too have had my debian testing amd64 hosed after an upgrade in the last few days. I spent most of a day using a live disk just to get back to something that would boot. Now at least I can get to a terminal and the command line. I suspect that it is going to take at least a further day to get the x back. I have better things to do with my time :-) . I agree entirely about the silent broken "up"grade. There are some aspects of systemd, in particular, the parallel design which are good or better. But I agree entirely about the wrongheaded monolithic structure, although it is indeed built from small units, but seem so interdependent. And debugging seems daunting and hardly supported. Another problem is enforcing one way of doing things: it seems very inflexible and unable to work around minor quirks that it is not expecting. Disclaimer: I have not read the source so perhaps the above is not accurate. ael -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811082610.GA6914@elf.conquest
Re: complaints about systemd
> Unfortunately we can't go back now. Well, i did, just yesterday. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810180401.660ac...@mirrors.kernel.org
Re: complaints about systemd
I am with you on this one. Unfortunately we can't go back now. On Aug 10, 2014 4:33 PM, "Michael" wrote: > Hello all, > > I just want to load off my bad mood :) so let me tell you, today i > deinstalled systemd. > > There were several problems, like with shut down, when sound card state > should be saved but created a guru. Sometimes it didn't even boot because > some ACPI thing stuck. Also my reboot / shutdown keys did not work anymore. > I did not have these problems with sysvinit and now they seem to be gone > again. > > The next thing i don't like is the configuration, which is anything but > intuitive. I had a hard time to find out how to fine tune my booting again > (which requires some small custom adaptions), or to just shut up the > massive message blurb that systemd loaded off my terminals, but still have > a human readable logging. > > What pisses me off the most however is that the upgrade did not even ask > me, if i want to switch. > > I read up the architecture description and i'm shocked. The new systemd > swallows a lot of essential subsystems (like udev and acpid) and its hunger > seems still not satisfied. The main developers (which seem to be just 2 > guys, only, which also is quite shocking for me, given the essential > importance and critical freshness of the whole thing!) even state they want > to integrate and streamline as much as possible. > > However, i'm quite sure that the old unix way of 'splitting it up into > small specialized parts' is much more robust. For example, if one component > is not working correctly, it can replaced . With systemd, you don't have > this choice anymore and the whole system will be affected, in worst case, > break down. You'll need to wait until upstream fixes your little thing, and > with such a small developer base, and deep integration, it's highly > questionable if that will be anything like timely, or happen at all. (These > always were particular features of the Microsoft OS which i never was able > to accept.) > > Having a choice also implies more security, because a secured system which > set of active components are rather unknown can't be easily cracked. As a > network admin, i'm totally against the idea of general 'streamlining'. > > Now it seems the developers managed to convince gnome to create a > dependency to systemd. It only means, i will not use gnome anymore. I hope > KDE is not that silly. > > I know this topic does not strictly belong here, well, but let's see if > anyone here likes to argue my ideas. I don't even now to whom to complain, > since i don't want systemd to get better, but rather, a completely > different approach, and first of all with much broader agreement and > support from upstream developers. > But if it boils down to 'do it yourself' which then this is clearly beyond > my scope. I'm on the looser side here. > > (But does anyone know who would be responsible for the switch, in Debian ?) > > Kind regards, > > mi > > > > > > > > > > -- > To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > https://lists.debian.org/20140810151744.472d1...@mirrors.kernel.org > >
Re: complaints about systemd
See also... http://lwn.net/Articles/585319/ and http://boycottsystemd.org/ Dean On 10/08/14 23:17, Michael wrote: > Now it seems the developers managed to convince gnome to create a dependency > to systemd. It only means, i will not use gnome anymore. I hope KDE is not > that silly. > > I know this topic does not strictly belong here, well, but let's see if > anyone here likes to argue my ideas. I don't even now to whom to complain, > since i don't want systemd to get better, but rather, a completely different > approach, and first of all with much broader agreement and support from > upstream developers. > But if it boils down to 'do it yourself' which then this is clearly beyond my > scope. I'm on the looser side here. > > (But does anyone know who would be responsible for the switch, in Debian ?) -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e77888.2070...@fragfest.com.au
