Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #4296 > unrolled thread

OT: Open letter to the Linux World

Back to article view | Back to comp.misc

Contents

  OT: Open letter to the Linux World Rich <rich@example.invalid> - 2014-08-13 00:35 +0000
    Re: OT: Open letter to the Linux World Kara M'bola <maxupixu@in.val.it> - 2014-08-13 15:31 +0000
      Re: OT: Open letter to the Linux World Jim Jackson <jj@franjam.org.uk> - 2014-08-14 16:55 +0000
      Re: OT: Open letter to the Linux World Mike Spencer <mds@bogus.nodomain.nowhere> - 2014-08-14 15:38 -0300
      Re: OT: Open letter to the Linux World RS Wood <rsw@therandymon.com> - 2014-08-19 14:30 +0000
        Re: OT: Open letter to the Linux World Rich <rich@example.invalid> - 2014-08-19 15:38 +0000
    Re: OT: Open letter to the Linux World Randy Westlund <Vorzakir@invalid.invalid> - 2014-08-14 20:30 +0000
    Re: OT: Open letter to the Linux World Dan Espen <despen@verizon.net> - 2014-08-14 16:42 -0400
      Re: OT: Open letter to the Linux World Tim Streater <timstreater@greenbee.net> - 2014-08-14 21:57 +0100
      Re: OT: Open letter to the Linux World Anssi Saari <as@sci.fi> - 2014-08-15 10:11 +0300
        Re: OT: Open letter to the Linux World Kara M'bola <maxupixu@in.val.it> - 2014-08-15 12:26 +0000
          Re: OT: Open letter to the Linux World Dan Espen <despen@verizon.net> - 2014-08-15 10:06 -0400
            Re: OT: Open letter to the Linux World Kara M'bola <maxupixu@in.val.it> - 2014-08-15 14:48 +0000
              Re: OT: Open letter to the Linux World Dan Espen <despen@verizon.net> - 2014-08-15 11:49 -0400
                Re: OT: Open letter to the Linux World Kara M'bola <maxupixu@in.val.it> - 2014-08-15 17:47 +0000
                Re: OT: Open letter to the Linux World Rich <rich@example.invalid> - 2014-08-15 18:54 +0000
                  Re: OT: Open letter to the Linux World Dan Espen <despen@verizon.net> - 2014-08-15 16:05 -0400
                    Re: OT: Open letter to the Linux World Rich <rich@example.invalid> - 2014-08-15 21:22 +0000
                    Re: OT: Open letter to the Linux World Rich <rich@example.invalid> - 2014-08-15 21:26 +0000
        Re: OT: Open letter to the Linux World Rich <rich@example.invalid> - 2014-08-15 15:51 +0000
          Re: OT: Open letter to the Linux World Anssi Saari <as@sci.fi> - 2014-08-20 19:40 +0300
            Re: OT: Open letter to the Linux World Rich <rich@example.invalid> - 2014-08-20 22:07 +0000
            Re: OT: Open letter to the Linux World "D.D." <xyzzy@inbox.com> - 2014-08-21 02:40 -0700
      Re: OT: Open letter to the Linux World Geoff Clare <geoff@clare.See-My-Signature.invalid> - 2014-08-15 13:25 +0100
      Re: OT: Open letter to the Linux World Jerry Peters <jerry@example.invalid> - 2014-08-15 20:11 +0000
        Re: OT: Open letter to the Linux World Rich <rich@example.invalid> - 2014-08-15 21:32 +0000
      Re: OT: Open letter to the Linux World Eric Pozharski <whynot@pozharski.name> - 2014-08-16 14:25 +0300

Page 2 of 2 — ← Prev page 1 [2]

#4508

Rich <rich@example.invalid> writes:

> Anssi Saari <as@sci.fi> wrote:
>
>> Yeah. I have to say also that my laptop running the Gentoo-based
>> Sabayon distro boots wicked fast with systemd. Granted, that's only
>> after I built a custom kernel and threw out the bloated initrd they
>> use by default but still.

> Which is fine, except that you should only need to boot when doing a
> kernel upgrade.  Anytime in between you should be sleeping/hibernating,
> in which case "time to boot" is not an issue.

In a better world, yes. And that has worked perfectly on my file server
and fairly well on my desktop. I can even hibernate the desktop in Linux
and instead of shutting down boot Windows instead and when I'm done with
that, Linux resumes. Mostly, sometimes the resume hangs but it's been
getting rarer. I guess Nvidia is improving their drivers.

Unfortunately with my laptop I have to frequently boot because:

- It didn't go to sleep or hibernation even though it's configured to do
  that after some idle time and ran out of battery.

  I may have identified the culprit, namely x2go client. At least I
  managed multiple timed sleeps yesterday without it running. I guess
  I'll have to go back to VNC for remote access. x2go has definitely
  been weird and buggy but on the other hand it doesn't have the
  annoying limitations of VNC which prompted me to search for
  alternatives.

- Or I tried to go to hibernation but that's unreliable and crashes
  maybe once out of three attempts. It's partly my fault for using a
  newish 3.14.9 kernel with TuxOnIce which may not be quite debugged
  yet. But the vanilla hibernation is ridiculously slow waking up and
  the 3.14 supposedly has RC6 support for Ironlake and that does seem to
  make a difference with battery life.

  This may have gotten fixed with the 3.14.15 TuxOnIce kernel I
  installed yesterday. At least no hibernation hangs with a handful of
  hibernations.

- The internal 3G modem has a bad day and and crashes. Although come to
  think of it, it should be resettable by forcing a FW reload with
  gobi_loader.

Of course, patching and building kernels and hoping for a fix on these
issues is a big reason for the reboots too.

> systemd's claim to fame of wiked fast boot times is optimizing for a
> windows problem (the need to reboot to make any change to much of
> anything).

True. So I boot my Windows machines about once a month at work after
"Patch Tuesday" or whatever. It's pretty rare these days that an app or
driver install on Windows needs a reboot. For the record I don't *like*
Windows, it's like an annoying relative who always gets under your skin
somehow without having obvious faults... But in my life, Windows (2000,
XP, 7) haven't had obvious faults other than being ugly, annoying to use
and slow.

> If you almost never reboot, then speed of boot is less important. 
> Instead they should be focusing on making sleep/hibernate reliable
> enough to never need to reboot.

Oh I agree. But I don't think "they" will be coming to help me with my
specific already oldish laptop and I don't have that much time to work
on it. Specifically with Linux, Tux on Ice is really a big improvement
especially with hibernation but it doesn't look like it'll make it into
mainline like ever and it has only one dev.

I'm currently hoping I can actually get NetworkManager to manage my 3G
but I'm not overly hopeful. My bug report was just put in "unconfirmed"
state and I doubt it's ever going to get fixed or even looked at as the
devs don't have my setup to test with. Besides, the problem seems to be
an interaction between NetworkManager, dhcpcd and the modem driver but I
don't even know how to debug it and I expect at most finger pointing
between the various devs... Or nothing at all.

[toc] | [prev] | [next] | [standalone]

#4511

Anssi Saari <as@sci.fi> wrote:
> Rich <rich@example.invalid> writes:

> > Anssi Saari <as@sci.fi> wrote:
> >
> >> Yeah. I have to say also that my laptop running the Gentoo-based
> >> Sabayon distro boots wicked fast with systemd. Granted, that's only
> >> after I built a custom kernel and threw out the bloated initrd they
> >> use by default but still.

> > Which is fine, except that you should only need to boot when doing a
> > kernel upgrade.  Anytime in between you should be sleeping/hibernating,
> > in which case "time to boot" is not an issue.

> In a better world, yes. And that has worked perfectly on my file server
> and fairly well on my desktop. I can even hibernate the desktop in Linux
> and instead of shutting down boot Windows instead and when I'm done with
> that, Linux resumes. Mostly, sometimes the resume hangs but it's been
> getting rarer. I guess Nvidia is improving their drivers.

> Unfortunately with my laptop I have to frequently boot because:

> ... (long list of problems clipped)

Understood.  My laptop does sleep/hibernate fairly well, about once
every 3 weeks or so it fails to return from hibernation, and so gets a
reboot.  Newer kernels have progressively been better about running for
longer periods of time before it messes up in restore.

However, one of the big purported reasons for needing to write systemd
was that of speeding up cold boots.  Now, imagine how much developer
effort and time has been expended so far on systemd , and
reimplimenting all the other side services that systemd is now taking
over.

Now imagine if that effort and time had been directed towards rooting
out the issues causing sleep/hibernate to not work on various different
machines, and fixing those issues.

Where do you think Linux sleep/hibernate might be reliability wise if
the effort spent on systemd had instead been spent on trying to make
sure that you never needed to cold boot except for kernel upgrades?

I suspect Linux's sleep/hibernate would surpass windows in reliability
(and windows sleep/hibernate is not the model of reliability either) if
that effort had been redirected.


> Of course, patching and building kernels and hoping for a fix on these
> issues is a big reason for the reboots too.

True, although unless your laptop is wicked fast (or you build your
kernels on another, wicked fast, machine), the time to actually build
the kernel far surpasses the time to go through the cold boot to start
up the new kernel.

[toc] | [prev] | [next] | [standalone]

#4519

On 08/20/2014 09:40 AM, Anssi Saari wrote:>> If you almost never reboot, then 
speed of boot is less important.
>> Instead they should be focusing on making sleep/hibernate reliable
>> enough to never need to reboot.
>
> Oh I agree. But I don't think "they" will be coming to help me with my
> specific already oldish laptop and I don't have that much time to work
> on it.

Most of the time I've been in Linux, my systems have been 5-10 years old, so I 
know the feeling.  My experience, though, has thankfully been that needed fixes 
continue to be released even a decade into the system's age.

For example, from 2008 until February of this year, I was using one of two 
2004ish Centrino laptops, neither of which could reliably suspend, hibernate, or 
blur transparent/translucent graphics at first.  Suspend started working in 
2010, hibernate followed along in 2012 -- and to my shock, "blur" was finally 
enabled in an upgrade last summer.

My guess is that it's because individual components keep being used in different 
systems/devices long after a particular computer is discontinued, and that often 
problems are with a whole family of parts.  So when a developer tackles a 
problem reported by someone with a 2-year-old computer, there's a good chance 
that it's going to affect a whole lot of seemingly-unrelated systems.

Also, it seems to me like problems often exist in one distro but not another. 
The Thinkpad T400 I got in late spring couldn't suspend or hibernate in Fedora: 
suspend/sleep did nothing and 'hibernate' shut it off without saving anything. 
In MX-14 (based on Debian Wheezy) & Debian Jessie, however, suspend/sleep works 
just fine.

[toc] | [prev] | [next] | [standalone]

#4385

Dan Espen wrote:

> The old init scripts had to be executed serially at start up

That hasn't been true for Debian for many years (since squeeze, IIRC).
Presumably the same is true for other Linux distros that have LSB
headers in their init scripts.  From /etc/init.d/README:

| All init.d scripts are expected to have a LSB style header documenting
| dependencies and default runlevel settings.  The header look like this
| (not all fields are required):
| 
| ### BEGIN INIT INFO
| [...]
| ### END INIT INFO
| 
| More information on the format is available from insserv(8).  This
| information is used to dynamicaly assign sequence numbers to the
| boot scripts and to run the scripts in parallel during the boot.

Note the last line.

-- 
Geoff Clare <netnews@gclare.org.uk>

[toc] | [prev] | [next] | [standalone]

#4397

Dan Espen <despen@verizon.net> wrote:
> Rich <rich@example.invalid> writes:
> 
>> http://lkml.iu.edu//hypermail/linux/kernel/1408.1/02496.html
>>
>>   "What is intelligence? Not exactly the spook kind, but rather what is
>>    the definition of intelligence in humans? This is pretty good:
>>    http://en.wikipedia.org/wiki/Intelligence#Definitions"
>>
>>   "By most accounts, the self-appointed and arguably too influential
>>    creators and thinkers of the day around the 'One Linux' idea fit the
>>    definition of intelligent people - at least in the technical realm."
> 
> It's rant.
> 
> The guy complains about the complexity of systemd but does
> not propose a simpler solution to the problems systemd solves.
> He also does not make a case that the problems systemd solves
> should not be solved.
> 
> The old init scripts had to be executed serially at start up
> and shutdown but did nothing for those scripts monitoring themselves
> at run time.  That was up to each service.
> 
> I don't like complexity but I won't rant about it unless I
> can do better.

IMO that isn't the problem with systemd. The problem is all of the
additional functions it's accumulating, like crond, dbus, etc and its
intertwining with gnome and the desktop.

[toc] | [prev] | [next] | [standalone]

#4401

Jerry Peters <jerry@example.invalid> wrote:
> Dan Espen <despen@verizon.net> wrote:
> > Rich <rich@example.invalid> writes:
> > 
> >> http://lkml.iu.edu//hypermail/linux/kernel/1408.1/02496.html
> >>
> >>   "What is intelligence? Not exactly the spook kind, but rather what is
> >>    the definition of intelligence in humans? This is pretty good:
> >>    http://en.wikipedia.org/wiki/Intelligence#Definitions"
> >>
> >>   "By most accounts, the self-appointed and arguably too influential
> >>    creators and thinkers of the day around the 'One Linux' idea fit the
> >>    definition of intelligent people - at least in the technical realm."
> > 
> > It's rant.
> > 
> > The guy complains about the complexity of systemd but does
> > not propose a simpler solution to the problems systemd solves.
> > He also does not make a case that the problems systemd solves
> > should not be solved.
> > 
> > The old init scripts had to be executed serially at start up
> > and shutdown but did nothing for those scripts monitoring themselves
> > at run time.  That was up to each service.
> > 
> > I don't like complexity but I won't rant about it unless I
> > can do better.

> IMO that isn't the problem with systemd. The problem is all of the
> additional functions it's accumulating, like crond, dbus, etc and its
> intertwining with gnome and the desktop.

Yes, that is exactly the issue.  It is becoming a 40+ headed hydra with
each head eating a component it has zero business touching (beyond
simple "is it running? no? - start it then." or "is it running? yes -
well, stop it now".

And intertwining the thing such that user level programs require
systemd to function just add's further heads to the hydra that should
not be there.

[toc] | [prev] | [next] | [standalone]

#4422

with <lsj6v1$ngq$1@dont-email.me> Dan Espen wrote:

*SKIP*
> The old init scripts had to be executed serially at start up and
> shutdown but did nothing for those scripts monitoring themselves at
> run time.  That was up to each service.

That idea about "restarting" has never compiled for me.  If a service
has died then may be there's a bigger problem what can't be solved with
restarting already dead service?  And what if it dies again?  Then if
other service "depends" on the dead service (what's in
start-died?-restart cycle) it should be restarted too, right?

> I don't like complexity but I won't rant about it unless I can do
> better.

But you totally can.  It's called -- K.I.S.S.

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.misc

csiph-web