Re: OT: complaints about systemd
On Fri, Oct 10, 2014 at 02:53:56AM +0200, Michael wrote: > where did you find that ? I searched for the message I got at shutdown. This was on amd64. Hardly an unusual architecture. :) > Not here ? > https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=systemd > > If you talk ARM then #74280 could apply. Besides pulseaudio IIRR is from the > same folks. It's also - since years - among the first things i rip off > standard installations. > > Or maybe ? > https://bugs.freedesktop.org/show_bug.cgi?id=33421 > which demonstrates a nice shot in their own knee, plus Big L (c) favorite > approach to solve systemd bugs: By adding systemd support to xyz package. > Well, on second thought they went for the standard ugly workaround (around > design flaws). > My bad mood again, i need my pills |-) > > ugh i really think it's time to change the subject (done.) And overly complicated system that wasn't designed with proper debuging in mind. -- 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/20141010023536.gc4...@csclub.uwaterloo.ca
OT: complaints about systemd
Lennart, > shutting down samba by the looks of it. Seems to be bug #762002. where did you find that ? Not here ? https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=systemd If you talk ARM then #74280 could apply. Besides pulseaudio IIRR is from the same folks. It's also - since years - among the first things i rip off standard installations. Or maybe ? https://bugs.freedesktop.org/show_bug.cgi?id=33421 which demonstrates a nice shot in their own knee, plus Big L (c) favorite approach to solve systemd bugs: By adding systemd support to xyz package. Well, on second thought they went for the standard ugly workaround (around design flaws). My bad mood again, i need my pills |-) ugh i really think it's time to change the subject (done.) -- 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/20141010025356.6b755...@mirrors.kernel.org
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
