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

Groups > linux.debian.user > #179886 > unrolled thread

If Linux Is About Choice, Why Then ...

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  If Linux Is About Choice, Why Then ... David Niklas <doark@mail.com> - 2017-04-07 20:50 +0200
    Re: If Linux Is About Choice, Why Then ... David Niklas <doark@mail.com> - 2017-04-07 22:10 +0200
    Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-08 03:30 +0200
      Re: If Linux Is About Choice, Why Then ... Richard Owlett <rowlett@cloud85.net> - 2017-04-08 07:10 +0200
        Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-08 09:20 +0200
          Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-08 11:10 +0200
            Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-08 22:30 +0200
          Re: If Linux Is About Choice, Why Then ... Martin Read <zen75502@zen.co.uk> - 2017-04-08 11:50 +0200
            Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-08 12:00 +0200
              Re: If Linux Is About Choice, Why Then ... The Wanderer <wanderer@fastmail.fm> - 2017-04-08 13:00 +0200
              Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-08 22:40 +0200
          Re: If Linux Is About Choice, Why Then ... Mart van de Wege <mvdwege@gmail.com> - 2017-04-08 15:20 +0200
          Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-09 01:30 +0200
            Re: If Linux Is About Choice, Why Then ... Joe <joe@jretrading.com> - 2017-04-09 09:50 +0200
              Re: If Linux Is About Choice, Why Then ... Greg Wooledge <wooledg@eeg.ccf.org> - 2017-04-10 15:40 +0200
                Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-10 16:10 +0200
                  Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-10 16:20 +0200
                    Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-10 16:30 +0200
                      Re: If Linux Is About Choice, Why Then ... Nicolas George <george@nsup.org> - 2017-04-10 16:40 +0200
                        Re: If Linux Is About Choice, Why Then ... tomas@tuxteam.de - 2017-04-10 21:10 +0200
                        Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-11 02:20 +0200
                      Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-10 23:30 +0200
                        Re: If Linux Is About Choice, Why Then ... deloptes <deloptes@gmail.com> - 2017-04-10 23:40 +0200
                        Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-11 16:40 +0200
                          Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-12 17:40 +0200
                        Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-12 17:30 +0200
                          Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-12 18:50 +0200
                            Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-12 21:50 +0200
                              Re: If Linux Is About Choice, Why Then ... Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-13 00:00 +0200
                            Re: If Linux Is About Choice, Why Then ... Ric Moore <wayward4now@gmail.com> - 2017-04-12 22:50 +0200
                              Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 00:50 +0200
                                Re: If Linux Is About Choice, Why Then ... Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-13 02:20 +0200
                                Re: If Linux Is About Choice, Why Then ... Ric Moore <wayward4now@gmail.com> - 2017-04-13 08:50 +0200
                                Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-13 11:00 +0200
                            Re: If Linux Is About Choice, Why Then ... Mart van de Wege <mvdwege@gmail.com> - 2017-04-12 22:50 +0200
                              Re: If Linux Is About Choice, Why Then ... Ric Moore <wayward4now@gmail.com> - 2017-04-12 23:20 +0200
                            Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-12 23:20 +0200
                              Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 01:20 +0200
                                Re: If Linux Is About Choice, Why Then ... Nicholas Geovanis <nickgeovanis@gmail.com> - 2017-04-13 02:00 +0200
                          Re: If Linux Is About Choice, Why Then ... Mart van de Wege <mvdwege@gmail.com> - 2017-04-12 22:50 +0200
                            Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-13 01:00 +0200
                    Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-11 02:20 +0200
                Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-11 02:10 +0200
                  Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-11 05:40 +0200
                Re: If Linux Is About Choice, Why Then ... Ric Moore <wayward4now@gmail.com> - 2017-04-11 03:40 +0200
                  Re: If Linux Is About Choice, Why Then ... Miles Fidelman <mfidelman@meetinghouse.net> - 2017-04-11 05:10 +0200
            Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-09 12:30 +0200
              Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-09 20:10 +0200
        Re: If Linux Is About Choice, Why Then ... Ric Moore <wayward4now@gmail.com> - 2017-04-11 03:10 +0200
          Re: If Linux Is About Choice, Why Then ... Richard Owlett <rowlett@cloud85.net> - 2017-04-11 15:00 +0200
            Re: If Linux Is About Choice, Why Then ... Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-11 15:20 +0200
              Re: If Linux Is About Choice, Why Then ... Richard Owlett <rowlett@cloud85.net> - 2017-04-11 17:10 +0200
    Re: If Linux Is About Choice, Why Then ... Michael Fothergill <michael.fothergill@gmail.com> - 2017-04-09 17:50 +0200
      Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-09 22:20 +0200
        Re: If Linux Is About Choice, Why Then ... Miles Fidelman <mfidelman@meetinghouse.net> - 2017-04-09 23:50 +0200
          Re: If Linux Is About Choice, Why Then ... Lisi Reisz <lisi.reisz@gmail.com> - 2017-04-10 00:20 +0200
          Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-10 08:10 +0200
            Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-10 09:40 +0200
            Re: If Linux Is About Choice, Why Then ... Miles Fidelman <mfidelman@meetinghouse.net> - 2017-04-10 16:30 +0200
            Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-12 11:40 +0200
              Re: If Linux Is About Choice, Why Then ... Patrick Bartek <nemommxiv@gmail.com> - 2017-04-12 18:20 +0200
                Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-12 23:10 +0200
                  Re: If Linux Is About Choice, Why Then ... Reco <recoverym4n@gmail.com> - 2017-04-13 17:50 +0200
                    Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-13 19:40 +0200
                      Re: If Linux Is About Choice, Why Then ... Reco <recoverym4n@gmail.com> - 2017-04-14 14:00 +0200
                        Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-17 23:40 +0200
                          Re: If Linux Is About Choice, Why Then ... Reco <recoverym4n@gmail.com> - 2017-04-18 16:40 +0200
                            Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-18 17:10 +0200
                              Re: If Linux Is About Choice, Why Then ... Gene Heskett <gheskett@shentel.net> - 2017-04-18 17:50 +0200
                                Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-20 02:20 +0200
                                  Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-21 16:40 +0200
                              Re: If Linux Is About Choice, Why Then ... Reco <recoverym4n@gmail.com> - 2017-04-18 18:50 +0200
                                Re: If Linux Is About Choice, Why Then ... <tomas@tuxteam.de> - 2017-04-20 12:00 +0200
                                Re: If Linux Is About Choice, Why Then ... Jonathan Dowland <jmtd@debian.org> - 2017-04-20 12:00 +0200
                                  Debian contributor Register of Interests (was Re: If Linux Is About  Choice, Why Then ...) Jonathan Dowland <jmtd@debian.org> - 2017-05-09 17:00 +0200
                                    Re: Debian contributor Register of Interests (was Re: If Linux Is  About Choice, Why Then ...) <tomas@tuxteam.de> - 2017-05-09 21:10 +0200
                            Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-18 17:40 +0200
                            Re: If Linux Is About Choice, Why Then ... Ben Caradoc-Davies <ben@transient.nz> - 2017-04-18 23:30 +0200
        Re: If Linux Is About Choice, Why Then ... Michael Fothergill <michael.fothergill@gmail.com> - 2017-04-11 18:10 +0200
    Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 03:10 +0200
      Re: If Linux Is About Choice, Why Then ... Joel Rees <joel.rees@gmail.com> - 2017-04-13 03:40 +0200
        Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 11:00 +0200
      Re: If Linux Is About Choice, Why Then ... David Wright <deblis@lionunicorn.co.uk> - 2017-04-13 04:20 +0200
        Re: If Linux Is About Choice, Why Then ... Joe <joe@jretrading.com> - 2017-04-13 09:20 +0200
      Re: If Linux Is About Choice, Why Then ... Catherine Gramze <rhiamom@mac.com> - 2017-04-13 04:20 +0200
        Re: If Linux Is About Choice, Why Then ... GiaThnYgeia <GiaThnYgeia@openmailbox.org> - 2017-04-13 11:30 +0200
          Re: If Linux Is About Choice, Why Then ... Catherine Gramze <rhiamom@mac.com> - 2017-04-13 17:20 +0200

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#180036

On Wed 12 Apr 2017 at 22:24:16 (+0200), Mart van de Wege wrote:
> David Wright <deblis@lionunicorn.co.uk> writes:
> 
> > On Mon 10 Apr 2017 at 21:21:00 (+0000), GiaThnYgeia wrote:
> >> For a second month under freeze not much
> >> development can take place in unstable, as it is really tomorrow's
> >> testing.
> >
> > What do you mean? Sid (unstable) is always sid. It doesn't suddenly
> > become buster (the next testing) when stretch is released.
> >
> To be fair, as someone running Sid and doing almost daily updates, it is
> noticeable when there is a testing freeze, as Sid comes to an almost
> complete standstill while developers concentrate on the freeze.

I think you're right. And then there may be an avalanche after release
day, something that tyros running sid should be aware of.

(But I was just pointing out in passing that packages don't get a
"free pass" from unstable to testing on release day. In fact,
of course, unstable's contents, and testing's too, do not change at all.)

Cheers,
David.

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

#179968

On Mon, Apr 10, 2017 at 11:13 PM, Nicolas George <george@nsup.org> wrote:
> Le primidi 21 germinal, an CCXXV, tomas@tuxteam.de a écrit :
>> SysV init is broken because it has no process monitoring? No.
>> Process monitoring isn't in its scope.
>
> Your other arguments make sense, but sorry, this one does not. The
> process with PID one is the only immortal process on the system, and
> adopts all orphan processes. For that reason, any kind of process
> monitoring, if it needs reliability, must be rooted in PID 1. And in
> turn, that makes process monitoring in scope for any project that aims
> to implement a program for PID 1.

No, it means you need to redesign certain aspects of the permissions systems.

systemd essentially does that through cgroups and something else I'm
not placing, but it shouldn't be at pid 1. It can be moved off to a
higher pid daemon. It takes refactoring that ripples into the kernel.
So does systemd.

The big problem with systemd was that the design was to put it all in
pid 1, which Linus rightly protested.

> And that is what makes SysV init unsalvageable.

... without refactoring. It takes work. We should quite fighting
against the idea that something takes work.

> Socket activation, automounting, etc., are entirely optional and
> peripheral. Process monitoring is not.

Socket activation is not optional. Automounting is. Process monitoring
may not be optional, but it has to be kept out of pid 1 because pid 1
has to be kept small.

> Regards,
>
> --
>   Nicolas George



-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

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

#179967

On Mon, Apr 10, 2017 at 10:37 PM, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Sun, Apr 09, 2017 at 08:41:28AM +0100, Joe wrote:
>> Someone correct me if I'm wrong, but I run sid and see things come and
>> go. Didn't we have this:
>>
>> https://wiki.debian.org/LSBInitScripts
>>
>>    long before systemd?
>
> This and start-stop-daemon and probably a few other things are all
> hacks that were layered on top of sysvinit, in an attempt to work around
> its limitations and produce some kind of management system.

That's one way of looking at it.

> Ultimately, all of these hacks are fragile and doomed to failure.

The kernel was once a fragile hack. People layered things on top of
it, people helped refactor it, ...

Linus stuck with it, in no small part because he was single and in a
situation where he could.

Fragile is not quite the argument it seems. There are other factors --
a small group willing to stick with it, the formation of a community,
...

(And the group in charge, although they need to be able to assert
themselves, doesn't need to decide it is the cabal.)

> The basic design concept of sysvinit is that you launch a daemon in
> the background and record its PID in a file on disk.  Later, if you want
> to stop it, or see if it's still running, you open up this PID file,
> read the PID from it, and ask the kernel about the process with that ID.

sysvinit really never had an overarching design, but that could be
fixed with refactoring.

> Sounds OK, right?  At least, if don't have much experience with system
> administration.

Heh heh

> The problem is, PIDs get recycled.

That's one of the things that could, erm, should get redesigned and refactored.

> If the daemon died 17 days ago, and
> something else came along and used that PID, the sysvinit approach of
> checking that the PID is still running will give the wrong result.

We need two sets of pids, system pids below 1024, maybe, but, no, set
the boundary at 2^16-1. Yeah, I'm saying we need to make pids 32 bits,
which will break things.

(Or, if we think of uptime in terms of years, maybe we need 64 bit
pids. But 16 bits is not enough.)

Or, maybe we need a process fingerprint in addition to the pid, if the
pid really can't be widened without making too much other stuff blow
up.

The non-system pid processes should be managed by something not pid 1,
which means that we may need to move traditional low pid processes
down in the list.

> Add to that the very real problem of the legacy behavior of daemons that
> originated in the 1980s: they double-fork themselves into the background,
> on purpose.  This severs their tie to the parent process.  That means
> you can't even *get* the PID of the actual daemon from the outside.
> The daemon itself has to discover its *own* PID and write that to a PID
> file.  And your init structure has to rely on that somehow?  That's what
> the start-stop-daemon hack was introduced to try to work around, by
> the way.

Which means we need a daemon (but not at pid 1) that is the absolute
parent of all system processes, impossible to sever, and another that
is the absolute parent of all non-system processes, impossible to
sever. (And probably absolute parents for login sessions and absolute
parents per user, which takes some significant redesign, but we can
push that redesign work off for a while, because none of this is
directly managed by pid 1.)

Eventually, we'll have a service id or a daemon id that is separate
from the pid, and managed by a non-pid-1 process. (cgroups tries to do
this and misses the mark.)

> Hacks on top of hacks to work around hacks.  That's sysvinit.  It is not
> salvageable.

Not salvageable without a lot of work.

But the lot-of-work factor comes into play whether we start from
scratch or are willing to refactor what is there.

> Does that mean systemd is the ideal replacement?  No.  Systemd has these
> overreaching tendrils in places it's got no business sticking tendrils.
> Why does it have its own ntp daemon?  Why does it implement file system
> automount behavior?  These things already exist as userspace processes.
> Mature, trusted userspace processes, sometimes with multiple competing
> alternatives already.

And this is why systemd should have been developed in a fork of
Fedora, and why, since it wasn't, should have been integrated into a
fork of debian instead of directly.

> But then on the other hand, what else would you use instead of systemd?
> Nobody has proposed a superior alternative yet, that I've seen.

Lot's of people have proposed superior alternatives, but RedHat was
not patient enough, management didn't want to understand engineering,
etc. And the systemd cabal has a certian charisma. (If you think
"charisma" means "nice", go look the word up again.)

> So, IMHO, the best thing to do is to use systemd, but don't use any of
> its optional intrusive tendrils.  Other people have other opinions, and
> that's awesome.  A healthy, vigorous competitive environment benefits
> all of us.

Fortunately, a lot of people are standing up to the cabal.

> My wheezy servers use wheezy's sysvinit + daemontools.  My locally
> installed services are managed by daemontools.  Debian's services are
> managed by sysvinit.
>
> On my jessie machines, I have systemd (with its syvinit compat layer)
> plus daemontools, started as a systemd service.  I'm slowly transitioning
> my local stuff from daemontools to systemd services, but I am in no hurry
> to do so.

What we needed was probably for a group like Canonical to have funded
development of several alternative services management systems earlier
on. What we need now is for Redhat to back off just a little more than
they already have.

-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

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

#179973

On Tue, Apr 11, 2017 at 10:48 AM, somebody wrote, off list:

(I'm not sure why you sent it off-list, but I want to respond on-list.

> On 04/10/2017 08:08 PM, Joel Rees wrote:
>
>> What we needed was probably for a group like Canonical to have funded
>> development of several alternative services management systems earlier
>> on. What we need now is for Redhat to back off just a little more than
>> they already have.
>
> [something about redhat earning a billion dollars in a year.]

Last year, their net wasn't even a half-billion. I don't remember if
it's going up or down, and I don't remember them actually netting a
billion. Grossing, yes. They grossed well over 2 billion last fiscal
year, if I haven't already forgotten what I just read.

But I haven't been paying attention, really.

It's (relatively) easy to saturate a market. It's much harder to turn
saturation into a stable business model. It's often much easier to
develop a stable business if you avoid saturation. One of the problems
of the current economy is that almost everyone seems to be focused on
saturation instead of stability.

Anyway, the argument of money has to be applied carefully, and
generally should not supplant the technological discussion. Unless you
want to make your killing and exit the market.

> If you know of a way for RedHat to earn more than a billion in a year, I'm
> sure they would be all ears.

I'm not sure Redhat really wants another saturation point more than
stability, and systemd, actually, was more about stability. They
needed to keep selling things to managers who wanted to believe they
could control their infrastructure.

Systemd definitely gives more apparent evidence of control.

> Until then, I'm betting they will keep on doing
> what they do quite successfully.

Success is relative, and keeping on doing exactly what you are doing
now is not a good way to maintain success. you have to adapt to
changing times to even keep your focus steady.

> It could be they aren't quite so dumb and
> that for Debian to survive they ought to be following RedHat's lead.  :) Ric

Well, if "Debian" as a company that needs to succeed (Is it?) wants to
follow Redhat's lead into a now saturated area, that's generally not
good business. Someone would need to analyze how much and what kind of
saturation has occurred, so that the theoretical company could focus
on areas that aren't saturated.

On the other hand, following Redhat's example (not lead) would mean
making their (our?) own init and service management solution, and
making it better than Redhat's.

But I'm not sure what you were trying to get at. If the systemd cabal
learns how to move important functions that have been absorbed into
pid 1 back out, systemd will become a properly usable tool. (It's only
usable now in comparison to what had not been uniformly available
before.) They haven't yet done that, even though I think they have had
time to.

Future success requires fixing things that don't currently work, even
if they aren't yet causing enough problems to impinge on the present
bottom line. Problems ignored hit the bottom line eventually.

(Unless you bail first, and no one wants that, I hope.)

-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

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

#179971

On 04/10/2017 09:37 AM, Greg Wooledge wrote:

> Does that mean systemd is the ideal replacement?  No.  Systemd has these
> overreaching tendrils in places it's got no business sticking tendrils.
> Why does it have its own ntp daemon?  Why does it implement file system
> automount behavior?  These things already exist as userspace processes.
> Mature, trusted userspace processes, sometimes with multiple competing
> alternatives already.
>
> But then on the other hand, what else would you use instead of systemd?
> Nobody has proposed a superior alternative yet, that I've seen.
>
> So, IMHO, the best thing to do is to use systemd, but don't use any of
> its optional intrusive tendrils.  Other people have other opinions, and
> that's awesome.  A healthy, vigorous competitive environment benefits
> all of us.

If and when you start to manage a cluster, the need for those "tendrils" 
become apparent. You will need autostart and auto-restart features close 
to kernel level processes on node failures. SystemD seems to foot that 
bill. 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.
http://linuxcounter.net/user/44256.html

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

#179972

On 4/10/17 9:32 PM, Ric Moore wrote:

> On 04/10/2017 09:37 AM, Greg Wooledge wrote:
>
>> Does that mean systemd is the ideal replacement?  No.  Systemd has these
>> overreaching tendrils in places it's got no business sticking tendrils.
>> Why does it have its own ntp daemon?  Why does it implement file system
>> automount behavior?  These things already exist as userspace processes.
>> Mature, trusted userspace processes, sometimes with multiple competing
>> alternatives already.
>>
>> But then on the other hand, what else would you use instead of systemd?
>> Nobody has proposed a superior alternative yet, that I've seen.
>>
>> So, IMHO, the best thing to do is to use systemd, but don't use any of
>> its optional intrusive tendrils.  Other people have other opinions, and
>> that's awesome.  A healthy, vigorous competitive environment benefits
>> all of us.
>
> If and when you start to manage a cluster, the need for those 
> "tendrils" become apparent. You will need autostart and auto-restart 
> features close to kernel level processes on node failures. SystemD 
> seems to foot that bill. Ric
>
Funny thing, I don't hear folks who run clusters agitating for systemd - 
perhaps the contrary.  They want far more granular control of their 
systems than some huge monolithic blob of code that doesn't always 
behave as desired.

Miles Fidelman



-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

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

#179914

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Apr 09, 2017 at 08:20:16AM +0900, Joel Rees wrote:

[...]

> There is no plus to a restricted declaration syntax except the walls
> between the controlling service and the controlled services. In other
> words, the minus of separation is the plus of separation.

To be fair, there *is* a plus: with a restricted language, you can be
sure that some properties of the whole system are maintained. It then
becomes easier to reason about the whole behaviour. I think it becomes
a tradeoff.

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljqCuEACgkQBcgs9XrR2kbADQCcDpqg5P8RMFFFyk4YDUslK22w
nFAAnAm1/LMIznTSv84Lffg1/AI7319D
=fNYy
-----END PGP SIGNATURE-----

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

#179934

On Sun, Apr 9, 2017 at 7:20 PM,  <tomas@tuxteam.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sun, Apr 09, 2017 at 08:20:16AM +0900, Joel Rees wrote:
>
> [...]
>
>> There is no plus to a restricted declaration syntax except the walls
>> between the controlling service and the controlled services. In other
>> words, the minus of separation is the plus of separation.
>
> To be fair, there *is* a plus: with a restricted language, you can be
> sure that some properties of the whole system are maintained. It then
> becomes easier to reason about the whole behaviour. I think it becomes
> a tradeoff.

I think that was what I was trying to say, that the plus is also a
minus and you have to weigh it as a tradeoff.

But you do have to understand, in the weighing, that the restrictions
are not a perfect wall.

Also, I was trying to refer to the restricted dependency declaration
language becoming infrastructure that allows management software to
reliably analyze the dependencies. That was what was not happening
when the shell itself was being used to declare (or search out) the
dependencies.

Assuming that the declaration language is sufficient, the plus side is
that once the declarations are made, the management tools can work on
the dependencies more or less directly.

The minus side includes the problems of new language and the question
of whether it is sufficient, and, as someone else said elsewhere, the
baggage that systemd brings along with the new language.

The language itself could be made independent of systemd, if the
systemd project would cooperate with that.

> regards
> - -- tomás
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEYEARECAAYFAljqCuEACgkQBcgs9XrR2kbADQCcDpqg5P8RMFFFyk4YDUslK22w
> nFAAnAm1/LMIznTSv84Lffg1/AI7319D
> =fNYy
> -----END PGP SIGNATURE-----
>



-- 
Joel Rees

I'm imagining I'm a novelist:
http://joel-rees-economics.blogspot.com/2017/01/soc500-00-00-toc.html
More of my delusions:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

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

#179970

On 04/08/2017 01:06 AM, Richard Owlett wrote:

> 'They' never told us, owners of single user laptops, why we should chose
> it.

Simple, as I see it, single user laptop support doesn't pay the bills. 
Neither do Desktops. Ubuntu found that one out, for all of their user 
friendly features. When Red Hat broke the billion dollar amount for a 
single year of support services to big iron, everyone else salivated. 
The decision to switch to SystemD is simple ...Docker, clusters and "The 
Cloud", where the big dollars roam.



-- 
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.
http://linuxcounter.net/user/44256.html

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

#179977

On 04/10/2017 07:59 PM, Ric Moore wrote:
> On 04/08/2017 01:06 AM, Richard Owlett wrote:
>
>> 'They' never told us, owners of single user laptops, why we should chose
>> it.
>
> Simple, as I see it, single user laptop support doesn't pay the bills.
> Neither do Desktops. Ubuntu found that one out, for all of their user
> friendly features. When Red Hat broke the billion dollar amount for a
> single year of support services to big iron, everyone else salivated.
> The decision to switch to SystemD is simple ...Docker, clusters and "The
> Cloud", where the big dollars roam.
>

"Simple" it ain't.
I don't believe that the "single user laptop" market has been targeted 
in recent generations of operating systems.

I suspect an underlying problem is "linguistic" rather than "technological".

Ric didn't quote a key (IMMHO;) sentence of my post. I said:
> I never saw anything addressing potential advantages for a
> specific organic user owning a discrete laptop.

When speaking Linux (as opposed to English) the terms "user" and "single 
user" have meanings and implications quite divergent than what the 
general population would perceive.

The mass marketers [Microsoft, Canonical(Ubuntu), Google(Android)] use 
the "high power blunderbuss" approach. They bag enough sales to keep 
bean counters happy. Please note I did NOT use the term "customer" nor 
"accountants" in the previous sentence.

Now Ric has suggested that Red Hat has developed a large caliber rifle 
known as 'systemd' which is suitable for 'big iron'. The herd of vendors 
have jumped on the band wagon.

To shift idiom a bit. When facing a charging rhino an elephant gun would 
be more useful than a blunderbuss. But when deer hunting, wouldn't a 
hunting rifle with scope be more appropriate than either?

More editorials likely to follow.
The OWL ducks fer cover ;/

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

#179978

On Tuesday 11 April 2017 13:54:50 Richard Owlett wrote:
> >> 'They' never told us, owners of single user laptops, why we should chose
> >> it.

Because they don't care whether you chose it or not?  Debian offers 
alternatives, but had to chose a default.  Other distros have made their 
choice.  Ubuntu has chosen - of course - to go where the money is.

No-one cares what Richard Owlett - or Lisi Reisz - has chosen for his (her) 
laptop.  And why should anyone?

Lisi

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

#179981

On 04/11/2017 08:16 AM, Lisi Reisz wrote:
> On Tuesday 11 April 2017 13:54:50 Richard Owlett wrote:
>>>> 'They' never told us, owners of single user laptops, why we
>>>> should chose it.

Your quoting lost important context ;<
You quoted only one sentence (as Ric did) of my post of April 8.
But you link to my reply earlier today to Ric's post.
As you argued in another thread, context can be everything,
"Which is referenced here by its own name - Exe GNU-Linux.  When
I first saw it I wondered why a Linux distro was named after a
Windows binary.  The answer is, it isn't.  It is named after the
River Exe in Devon, England."

>
> Because they don't care whether you chose it or not?  Debian offers
> alternatives, but had to chose a default.  Other distros have made
> their choice.
>  Ubuntu has chosen - of course - to go where the money is.
>
> No-one cares what Richard Owlett - or Lisi Reisz - has chosen for his
> (her) laptop.  And why should anyone?
>
> Lisi
>

As to your question, the BMOC (Big Monopolists Of Consumerism) have 
blinded themselves to the potential size of a market.

I get a chuckle following an Android oriented USENET group. There is 
much effort going into how to 'root' an Android object because 
purchaser's actually wish to use those objects for their (the 
purchasers) purpose. After all, Android was touted as a Linux for such 
objects.

The current crop of dinosaurs (MS, Google, Canonical) should remember 
"Those who don't know history are doomed to repeat it.”
[https://www.goodreads.com/quotes/tag/doomed-to-repeat-it]
Seen any T. Rex lately? They were once top of food chain.

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

#179926

[Multipart message — attachments visible in raw view] — view raw

On 7 April 2017 at 19:27, David Niklas <doark@mail.com> wrote:

> On  Mon, 13 Mar 2017 12:30:11 -0700
> Patrick Bartek <nemommxiv@gmail.com> wrote:
> > The Linux mantra has always been "choice," plethoras of choices. So why
> > at install time, is there no choice for the init system?  You get what
> > the developers decide. Yes, you can install a new one -- I've done it
> > and it works -- but only after the install.  It'd be a lot easier, if
> > there were a choice to begin with just like whether you want a GUI and
> > which one.
> >
> > Now, I know with LFS, you get to choose everything, etc.  But is a
> > choice of init at install time so outrageous that no one ever
> > considered it or is it technically unfeasible or something else.
> >
> > Just curious.
> >
>
> Because this reply is so late I'm CC'ing you off list.
>
> I sympathize, I run Gentoo Linux and us OpenRC. I plan on running Devuan,
> a Debain derivative that supports lots of different init systems.
> Why no one looks at their project and sees the people involved when
> making a statistic up for the amount of dissatisfied systemd users I don't
> know.
>
> Sincerely,
> David
>
>
​I have been reading through some of this stuff and I think that the debian
users who are fans of the sysinit boot up scripts should switch to running
Gentoo.

I use Gentoo with the openrc option.

Those who are OK with systemd should stick with Debian.

Regards

MF
​

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

#179939

On Sun, 9 Apr 2017 16:25:57 +0100 Michael Fothergill
<michael.fothergill@gmail.com> wrote:

> On 7 April 2017 at 19:27, David Niklas <doark@mail.com> wrote:
> 
> > On  Mon, 13 Mar 2017 12:30:11 -0700
> > Patrick Bartek <nemommxiv@gmail.com> wrote:
> > > The Linux mantra has always been "choice," plethoras of choices.
> > > So why at install time, is there no choice for the init system?
> > > You get what the developers decide. Yes, you can install a new
> > > one -- I've done it and it works -- but only after the install.
> > > It'd be a lot easier, if there were a choice to begin with just
> > > like whether you want a GUI and which one.
> > >
> > > Now, I know with LFS, you get to choose everything, etc.  But is a
> > > choice of init at install time so outrageous that no one ever
> > > considered it or is it technically unfeasible or something else.
> > >
> > > Just curious.
> > >
> >
> > Because this reply is so late I'm CC'ing you off list.
> >
> > I sympathize, I run Gentoo Linux and us OpenRC. I plan on running
> > Devuan, a Debain derivative that supports lots of different init
> > systems. Why no one looks at their project and sees the people
> > involved when making a statistic up for the amount of dissatisfied
> > systemd users I don't know.
> >
> > Sincerely,
> > David
> >
> >
> ​I have been reading through some of this stuff and I think that the
> debian users who are fans of the sysinit boot up scripts should
> switch to running Gentoo.
> 
> I use Gentoo with the openrc option.

Gentoo is a rolling release.  I prefer the "stable" philosophy of Debian
-- basically only bug and security fixes. I've been running Wheezy
now for 5 years, and it's, for all practical purposes, the "same" as
when I installed it.  After such a time, a rolling release would be a
completely different animal versionwise.

I've tried rolling releases before.  They are usually cutting edge and
more problematical (Unless they've gotten a lot better).  I want
something that works for years and doesn't break. That's one of the
reasons I chose Debian five years ago. Now, because of the systemd
thing, I'm looking at alternatives.

> Those who are OK with systemd should stick with Debian.

After much reading, I consider systemd more suited to large, busy
servers than a desktop box or notebook with just one user.  It's
like being forced to use a huge tractor-trailer rig with lots of chrome
and lights and 24 gears when a simple mini-van will do. ;-)

B

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

#179940

On 4/9/17 4:15 PM, Patrick Bartek wrote:

> After much reading, I consider systemd more suited to large, busy
> servers than a desktop box or notebook with just one user.  It's
> like being forced to use a huge tractor-trailer rig with lots of chrome
> and lights and 24 gears when a simple mini-van will do. ;-)
>
>
Funny thing.  As far as I can tell, those of us who run production 
servers are the ones who are most disturbed by the ways that systemd 
wends its way into all aspects of a system.

Miles Fidelman


-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

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

#179941

On Sunday 09 April 2017 22:39:50 Miles Fidelman wrote:
> On 4/9/17 4:15 PM, Patrick Bartek wrote:
> > After much reading, I consider systemd more suited to large, busy
> > servers than a desktop box or notebook with just one user.  It's
> > like being forced to use a huge tractor-trailer rig with lots of chrome
> > and lights and 24 gears when a simple mini-van will do. ;-)
>
> Funny thing.  As far as I can tell, those of us who run production
> servers are the ones who are most disturbed by the ways that systemd
> wends its way into all aspects of a system.

Yes, ISTR being told during the flame wars that systemd was great for desktops 
because it speeded up the boot process, but, just possibly, not so good for 
servers.

My own experience is sadly the exact opposite.  I find it very slow, including 
some very awkward hangs.

Still, I shall just have to add the vagaries of systemd to the many things I 
need to learn urgently!

Lisi

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

#179943

On Sun, 9 Apr 2017 17:39:50 -0400 Miles Fidelman
<mfidelman@meetinghouse.net> wrote:

> On 4/9/17 4:15 PM, Patrick Bartek wrote:
> 
> > After much reading, I consider systemd more suited to large, busy
> > servers than a desktop box or notebook with just one user.  It's
> > like being forced to use a huge tractor-trailer rig with lots of
> > chrome and lights and 24 gears when a simple mini-van will do. ;-)
> >
> >
> Funny thing.  As far as I can tell, those of us who run production 
> servers are the ones who are most disturbed by the ways that systemd 
> wends its way into all aspects of a system.

Perhaps instead of "..more suited," it should have been "intended" for
servers.  After all, wasn't systemd adopted first for RHEL whose
market is mainly servers?

B

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

#179945

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Apr 09, 2017 at 11:07:13PM -0700, Patrick Bartek wrote:
> On Sun, 9 Apr 2017 17:39:50 -0400 Miles Fidelman
> <mfidelman@meetinghouse.net> wrote:
> 
> > On 4/9/17 4:15 PM, Patrick Bartek wrote:
> > 
> > > After much reading, I consider systemd more suited to large, busy
> > > servers [...]

I think this is the wrong "dimension". It's not "large <--> small" but
rather "dynamic" <--> "static", dynamic meaning that file systems,
networks and other things come and go (and are interdependent).

This dimension is independent from large vs. small: for example, the
old mainframe of yore learnt to pull off the trick of plugging CPUs
and RAM while running (Linux has learnt that pretty recently, AFAIR),
so they were dynamic down to the guts, while the "good ol' PC", with
its hda, hdb, hdc (and if you were well off hdd ;) was a pretty static
beast. With USB, ESATA and (gasp!) bluetooth, OTOH...

Smartphones... dynamic, I'd say.

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAljrNWUACgkQBcgs9XrR2kZ7cQCfZzAvJJU5ANoXvxVMVWJ0+FPd
rHEAnRHLtsG3zQdTHlugmeX50Ce8VEU5
=weAi
-----END PGP SIGNATURE-----

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

#179956

On 4/10/17 2:07 AM, Patrick Bartek wrote:

> On Sun, 9 Apr 2017 17:39:50 -0400 Miles Fidelman
> <mfidelman@meetinghouse.net> wrote:
>
>> On 4/9/17 4:15 PM, Patrick Bartek wrote:
>>
>>> After much reading, I consider systemd more suited to large, busy
>>> servers than a desktop box or notebook with just one user.  It's
>>> like being forced to use a huge tractor-trailer rig with lots of
>>> chrome and lights and 24 gears when a simple mini-van will do. ;-)
>>>
>>>
>> Funny thing.  As far as I can tell, those of us who run production
>> servers are the ones who are most disturbed by the ways that systemd
>> wends its way into all aspects of a system.
> Perhaps instead of "..more suited," it should have been "intended" for
> servers.  After all, wasn't systemd adopted first for RHEL whose
> market is mainly servers?

That probably has more to do with the people involved, and who they work 
for.

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

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

#179996

[Multipart message — attachments visible in raw view] — view raw

On Sun, Apr 09, 2017 at 11:07:13PM -0700, Patrick Bartek wrote:
> Perhaps instead of "..more suited," it should have been "intended" for
> servers.  After all, wasn't systemd adopted first for RHEL whose
> market is mainly servers?

No, it wasn't. It was in Fedora before RHEL.

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

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

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | linux.debian.user

csiph-web