subject:"Re\: implicit linkage"

On Mon, Oct 13, 2014 at 10:47 PM, Miles Fidelman
 wrote:
> Chris Bannister wrote:
>>
>> On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote:
>>>
>>> On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland 
>>> wrote:

 On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
>
> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read 
> wrote:
>>
>> On 12/10/14 18:13, John Hasler wrote:
>>>
>>> You have no problem with an 1800 line function?

 ...
>>
>> I have a problem with 1800 line functions in general;

 ...
>
> I have no problem with an 1800 line function.

 ...

 *What* 1800 line function? The commit URI that was shared was an
 1894-line
 *file* with a large function definition starting at line 638 and ending
 at
 1890. That's a 1252-line function.
>>>
>>> mmm? 1800 vs. 1252 ?
>>>
>>> 30 years ago, when we still read printouts, 60 lines was considered
>>> the ideal max because that's what would fit on a page.
>>>
>>> Nowadays, we use a screen, but 60 lines is hard on the eyes (9 pt or
>>> so), so 40 lines is a good screen-full. But it turns out, with being
>>> about to scroll quickly, that 60 lines is still not hard to reach.
>>> Moreover, 60 lines seems to be a pretty good average for what an
>>> experienced coder can keep in his head.
>>
>> LOC is a silly way to measure anyway. You could put all the code on one
>> line --- PITA to read, but hey! it's only one line of code! :)
>>
>
> Go Perl.
> Go APL.
> :-)

I'm afraid the reasons we don't use perl or APL to write pid 1 code is
not clear to most casual readers, so I'll be uncool and say it out
loud:

Non-deterministic execution.

If pid 1 gets stalled, lots of things all over the system get to wait
for something important that can't happen until pid 1 gets un-stalled,
and that's true even with quad core. It may not freeze every process,
but it can cause dropped packets and such things. Potentially, you
could, every now and then, lose a buffer-full of data headed for a
file on disk, as well.

Again, to be painfully pedantic, one in ten thousand buffers is more
of a problem than one in a hundred. You notice frequent dropped
buffers, so you're likely to fix the problem. Infrequent dropped
buffers tend to be not noticed until the data is lost.

The only way to fix that in systemd is for systemd to delegate the
complicated stuff like managing dbus to child processes, so the
processes that will occasionally stall won't impact the whole system
as much.

When/if that happens, we should see the hard dependencies between
systemd and other stuff that has been absorbed by systemd disappear.

The real problem is that Poettering and others over there have rather
indicated an unwillingness to do that.

If we are willing to accept this kind of engineering, we have to
assume that either the developers at systemd will eventually get
around to a proper refactoring of the processes (and not just code
within pid 1), or we have to hope that open processes will ultimately
force their hand.

-- 
Joel Rees

Be careful when you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself.

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caar43imlfvvy0+pm+eejr_xjwuzh8mtvedsgqt87_d6ujth...@mail.gmail.com

Re: implicit linkage

2014-10-13 Thread Steve Litt

On Mon, 13 Oct 2014 08:18:57 +0100
Jonathan Dowland  wrote:

> On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
> > On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read 
> > wrote:
> > > On 12/10/14 18:13, John Hasler wrote:
> > > > You have no problem with an 1800 line function?
> ...
> > > I have a problem with 1800 line functions in general; 
> ...
> > I have no problem with an 1800 line function.
> ...
> 
> *What* 1800 line function? The commit URI that was shared was an
> 1894-line *file* with a large function definition starting at line
> 638 and ending at 1890. That's a 1252-line function.

OK, %s/1800/1252/g

I have a hunch the guy I replied to would have had as much of a problem
with a 1252 line function as an 1800 line one. My Ruby friends
disparage functions over 30 lines long. I view function lengths as an
implementation detail and don't worry too much about them. The code
looked reasonable to me.

> 
> Not only that but you're looking at a commit dating from August last
> year. The function doesn't even exist any more in current systemd[1].
> There are no functions of even a 100 lines length in that file now.
> 
> [1]
> http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c

I'm not that concerned about function lengths anyway.


> 
> 
> > What I *DO* have a problem with is the guy's welding pam onto his
> > new init, and welding other critical and former separate OS
> > functionalities onto his "toolset", preventing (either technically
> > or by them being removed from the packages) former modules from
> > being used.
> 
> Which guy is that? The commit that the URI referenced was written by
> Lennart Poettering, so I guess you mean him; 

Yep.

> but that commit didn't
> touch the file that was being complained about. Maybe you mean one of
> the other 17 people who have contributed to that file?

I wasn't talking about that commit, I was talking about what has been
done, and what Poettering has stated his goal is.

> 
> > If I were to maintain his code, before reducing the 1800 line
> > function, I'd do something about the function with 20 arguments,
> > with each argument including a function call. I'd replace all of
> > that with a struct pointer. 
> 
> I'd start with *reading the code* if I were you; something you guys
> clearly aren't doing.

OK, nothing in that code was that important. I *did* notice a function
with 20 arguments, and I, personally, would substitute a struct pointer
for that. But, as I said before, my objection to systemd isn't coding
style.

> 
> But if you get past that you'll be pleased to discover that such
> clean ups and refactors are happening quite often. See e.g.
> df2d202e6ed4001a21c6512c244acad5d4706c87 ("bus: let's simplify things
> by getting rid of unnecessary bus parameters"). I'll leave you to
> guess the author of that one.

I couldn't find that, but once again, I'm not saying anything about the
coding style. As a matter of fact, the thrust of my post was basically
that I'm not concerned about the referenced code's coding style, I'm
concerned about the macro-architecture.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141013141807.27141...@mydesq2.domain.cxm

Re: implicit linkage

On Mon, Oct 13, 2014 at 10:44 PM, Chris Bannister
 wrote:
> On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote:
>> On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland  wrote:
>> > On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
>> >> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read  wrote:
>> >> > On 12/10/14 18:13, John Hasler wrote:
>> >> > > You have no problem with an 1800 line function?
>> > ...
>> >> > I have a problem with 1800 line functions in general;
>> > ...
>> >> I have no problem with an 1800 line function.
>> > ...
>> >
>> > *What* 1800 line function? The commit URI that was shared was an 1894-line
>> > *file* with a large function definition starting at line 638 and ending at
>> > 1890. That's a 1252-line function.
>>
>> mmm? 1800 vs. 1252 ?
>>
>> 30 years ago, when we still read printouts, 60 lines was considered
>> the ideal max because that's what would fit on a page.
>>
>> Nowadays, we use a screen, but 60 lines is hard on the eyes (9 pt or
>> so), so 40 lines is a good screen-full. But it turns out, with being
>> about to scroll quickly, that 60 lines is still not hard to reach.
>> Moreover, 60 lines seems to be a pretty good average for what an
>> experienced coder can keep in his head.
>
> LOC is a silly way to measure anyway. You could put all the code on one
> line --- PITA to read, but hey! it's only one line of code! :)

You didn't read the rest of my post, did you?

> "If you're not careful, the newspapers will have you hating the people
> who are being oppressed, and loving the people who are doing the
> oppressing." --- Malcolm X
>
>
> --
> To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: https://lists.debian.org/20141013134448.GB2362@tal
>

-- 
Joel Rees

Be careful when you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caar43ipbkzh94rctqtmh1d-jhgpadmtsffzbdynfc6guwz5...@mail.gmail.com

Way OT: Re. lines of code [was Re: implicit linkage]

2014-10-13 Thread Miles Fidelman


Chris Bannister wrote:

On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote:

On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland  wrote:

On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:

On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read  wrote:

On 12/10/14 18:13, John Hasler wrote:

You have no problem with an 1800 line function?

...

I have a problem with 1800 line functions in general;

...

I have no problem with an 1800 line function.

...

*What* 1800 line function? The commit URI that was shared was an 1894-line
*file* with a large function definition starting at line 638 and ending at
1890. That's a 1252-line function.

mmm? 1800 vs. 1252 ?

30 years ago, when we still read printouts, 60 lines was considered
the ideal max because that's what would fit on a page.

Nowadays, we use a screen, but 60 lines is hard on the eyes (9 pt or
so), so 40 lines is a good screen-full. But it turns out, with being
about to scroll quickly, that 60 lines is still not hard to reach.
Moreover, 60 lines seems to be a pretty good average for what an
experienced coder can keep in his head.

LOC is a silly way to measure anyway. You could put all the code on one
line --- PITA to read, but hey! it's only one line of code! :)



Go Perl.
Go APL.
:-)


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


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543bd7e8.5050...@meetinghouse.net

Re: implicit linkage

2014-10-13 Thread Chris Bannister

On Mon, Oct 13, 2014 at 07:14:29PM +0900, Joel Rees wrote:
> On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland  wrote:
> > On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
> >> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read  wrote:
> >> > On 12/10/14 18:13, John Hasler wrote:
> >> > > You have no problem with an 1800 line function?
> > ...
> >> > I have a problem with 1800 line functions in general;
> > ...
> >> I have no problem with an 1800 line function.
> > ...
> >
> > *What* 1800 line function? The commit URI that was shared was an 1894-line
> > *file* with a large function definition starting at line 638 and ending at
> > 1890. That's a 1252-line function.
> 
> mmm? 1800 vs. 1252 ?
> 
> 30 years ago, when we still read printouts, 60 lines was considered
> the ideal max because that's what would fit on a page.
> 
> Nowadays, we use a screen, but 60 lines is hard on the eyes (9 pt or
> so), so 40 lines is a good screen-full. But it turns out, with being
> about to scroll quickly, that 60 lines is still not hard to reach.
> Moreover, 60 lines seems to be a pretty good average for what an
> experienced coder can keep in his head.

LOC is a silly way to measure anyway. You could put all the code on one
line --- PITA to read, but hey! it's only one line of code! :)

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141013134448.GB2362@tal

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

2014-10-13 Thread Reco

On Sun, Oct 12, 2014 at 03:30:49PM +0300, Andrei POPESCU wrote:
> > > > > This is the same reason we are using shared libraries and the Debian 
> > > > > Security Team is doing it's best to track code copies.
> > > > 
> > > > Consider /etc/init.d/skeleton a library then. It's sources to
> > > > any /etc/init.d script anyway.
> > > 
> > > No, it doesn't. 
> > 
> > Again, simple 'no' is beautiful, but hardly contributes to the
> > discussion.
> 
> $ grep skeleton /etc/init.d/*
> /etc/init.d/dictd:# based on /etc/init.d/skeleton v1.7  05-May-1997  by 
> miqu...@cistron.nl
> /etc/init.d/README:# Provides:  skeleton
> /etc/init.d/skeleton:# Provides:  skeleton
> 
> It seems like you misunderstood the purpose of /etc/init.d/skeleton. 
> It's not a library, but something to use as a base to write your own 
> script.
> 
> As of Jessie most of 'skeleton' has been turned into 'init-d-script' 
> though.

It was my mistake indeed. Thanks for the correction.
Somehow I mistook /lib/lsb/init-functions for /etc/init.d/skeleton. 


> > > > > True, but sysv-rc still can't deal with them correctly.
> > > > 
> > > > It does not have to deal with the hardware, as it not its' job.
> > > 
> > > It has to mount filesystems.
> > 
> > No, it does not have to. In Debian, there's /etc/init.d/mountall.sh to
> > do this job, in case initrd didn't care for it already. init(8) does
> > not mount anything.
> 
> $ dpkg -S /etc/init.d/mountall.sh
> initscripts: /etc/init.d/mountall.sh
> 
> I never said init(8) would mount anything, but sysv-rc. By sysv-rc I 
> mean /etc/init.d/rc and all other scripts required to boot your system. 
> Apparently most of these are split out in the initscripts package.

Ok, correction taken.


> > And, to spice things up, [1]. Beautiful link telling everyone that it's
> > not the init job to mount /usr as there's initrd for that.
> 
> But sysv-rc still has to take care your / and /usr is remounted 
> according to your fstab and also for mounting everything else defined in 
> /etc/fstab and how this interacts with the rest of the boot / daemons.

No objections here.


> > Please enlighten me what exactly is systemd-specific here. Basically
> > they tell "yadda-yadda-yadda, fix your applications, and if you don't -
> > we have this 90-second hack for you".
>  
> Systemd makes it possible for me to adjust mpd's .service file to 
> *require* a specific mount. This is not possible with sysv-rc's own 
> mechanisms, I'd have to script it myself.

But that's filesystem dependency, not a network one.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141013132742.ga30...@d1696.int.rdtex.ru

Re: implicit linkage

On Mon, Oct 13, 2014 at 7:34 PM, Ansgar Burchardt  wrote:
> Hi,
>
> On 10/13/2014 12:14, Joel Rees wrote:
>> Get pid 1 down to 100 lines of C, no loops, no functions called, then
>> I'll be impressed.
> [...]
>> Setting aside initialization code, pid 1 should target less than 1000
>> lines of C in the main loop. (If we were to use dash or other
>> streamlined shells, we might set a target of 100 lines of code.) Loops
>> and subroutines should be carefully metered for maximum execution
>> paths, and proven to be deterministic, with a maximum execution path
>> of less than 500 lines of C.
>
> What's the point of this exercise?

What exercise? I'm repeating rules of thumb, not revealing the ways I
derived them (estimates, based on the idea that you don't want
anything close to a millisecond consumed by a pass through the main
loop in pid 1), and admitting that the target I'm proposing is not
necessarily achievable.

systemd doesn't even consider such a target, near as I can tell. I
didn't do a full analysis, but from my casual scan I'm guessing there
are times a pass through the systemd main loop consumes more than a
hundred microseconds, which is too close to a millisecond.

> Linux's process scheduler alone has
> significant more lines. And there runtime complexity actually matters...

Does the scheduler run as pid 1?

Have you traced execution paths?

Did I say the kernel did not need some work? I don't remember saying
such a thing,. In fact, I distinctly remember implying that it did
need continued work.

> I'm just counting lines in kernel/sched/*.[ch], I'm too lazy to filter
> out comments.

Or do the execution path analysis.

Okay, I haven't shown the result of a path analysis for systemd,
either. But systemd runs as process 1. The scheduler does not.

> As an example:
>
> $ wc kernel/sched/fair.c
>   7867  26757 207986 kernel/sched/fair.c

You might want to ask on the kernel list for a pointer to the last
execution path analysis Linus did for the scheduler. You might be
surprised about what they tell you.

You might also want to ask how often the code in fair.c runs.

At any rate, whatever the kernel does is no excuse to introduce the
kind of code in systemd into pid 1.

pid 1 should always delegate any complex task to a child process. That
way, a failure in the complex task does not have to be dealt with
before pid 1 can do it's job the next time around.

-- 
Joel Rees

Be careful when you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.
Arm yourself with knowledge of yourself.

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAAr43iMCytQ12M23yZFNF=SVq3jbKJa-6AvW1L2dDy-V-T+C=w...@mail.gmail.com

Re: implicit linkage

2014-10-13 Thread Ansgar Burchardt

Hi,

On 10/13/2014 12:14, Joel Rees wrote:
> Get pid 1 down to 100 lines of C, no loops, no functions called, then
> I'll be impressed.
[...]
> Setting aside initialization code, pid 1 should target less than 1000
> lines of C in the main loop. (If we were to use dash or other
> streamlined shells, we might set a target of 100 lines of code.) Loops
> and subroutines should be carefully metered for maximum execution
> paths, and proven to be deterministic, with a maximum execution path
> of less than 500 lines of C.

What's the point of this exercise? Linux's process scheduler alone has
significant more lines. And there runtime complexity actually matters...

I'm just counting lines in kernel/sched/*.[ch], I'm too lazy to filter
out comments. As an example:

$ wc kernel/sched/fair.c
  7867  26757 207986 kernel/sched/fair.c

Ansgar


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/543baaab.7050...@43-1.org

Re: implicit linkage

On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland  wrote:
> On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
>> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read  wrote:
>> > On 12/10/14 18:13, John Hasler wrote:
>> > > You have no problem with an 1800 line function?
> ...
>> > I have a problem with 1800 line functions in general;
> ...
>> I have no problem with an 1800 line function.
> ...
>
> *What* 1800 line function? The commit URI that was shared was an 1894-line
> *file* with a large function definition starting at line 638 and ending at
> 1890. That's a 1252-line function.

mmm? 1800 vs. 1252 ?

30 years ago, when we still read printouts, 60 lines was considered
the ideal max because that's what would fit on a page.

Nowadays, we use a screen, but 60 lines is hard on the eyes (9 pt or
so), so 40 lines is a good screen-full. But it turns out, with being
about to scroll quickly, that 60 lines is still not hard to reach.
Moreover, 60 lines seems to be a pretty good average for what an
experienced coder can keep in his head.

1800/60 vs. 1252/60 ? 30 times the ideal max vs. 21 times? (Ignoring,
for the sake of your argument, those macros.)

Well, maybe we can look at things from the perspective of new
functionality. New functionality sometimes breaks rules just because
you need to get things in there and going before you can start
figuring out where and how to cut things.

Okay, that repository only goes back to April 2012:

http://cgit.freedesktop.org/systemd/systemd/log/src/core?ofs=1350

at the time of this post. (Give it a month or two, and that link won't
go all the way back anymore.)

The function in question at that point began at line 545 and ended at line 1540.

http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=b30e2f4c18ad81b04e4314fd191a5d458553773c#n545

That's 996 lines, including the closing brace. Plus-minus one, it's
not going to change much. 16.67 times the ideal max, and, for more
than a year, it just got bigger until some time after a year ago
August. We might assume that non-project people critiquing his code
lit a fire under him.

> Not only that but you're looking at a commit dating from August last year. The
> function doesn't even exist any more in current systemd[1]. There are no
> functions of even a 100 lines length in that file now.
>
> [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c

A quick scan shows a few over the ideal, but the ideal really is an
ideal target. So it would actually be reasonable now, in terms of
length. If it were not pid 1 code.

At least those macros seem to have been replaced with something less fragile.

>> What I *DO* have a problem with is the guy's welding pam onto his new init,
>> and welding other critical and former separate OS functionalities onto his
>> "toolset", preventing (either technically or by them being removed from the
>> packages) former modules from being used.
>
> Which guy is that? The commit that the URI referenced was written by Lennart
> Poettering, so I guess you mean him; but that commit didn't touch the file 
> that
> was being complained about. Maybe you mean one of the other 17 people who have
> contributed to that file?

You do understand that Steve is simply refusing to keep focused on one
file? (I don't blame him. That one file is not the sum and end of the
problems.)

>> If I were to maintain his code, before reducing the 1800 line function, I'd
>> do something about the function with 20 arguments, with each argument
>> including a function call. I'd replace all of that with a struct pointer.
>
> I'd start with *reading the code* if I were you; something you guys clearly
> aren't doing.

How did he know about that 20 parameter function? And don't forget,
the file in question was in the source, substantially as it was, for
more than a year. How much more, I'll have to find a repository that
goes farther back to find out, but I'm not interested. You want to
look for it for me?

> But if you get past that you'll be pleased to discover that such clean ups and
> refactors are happening quite often.

Now, at any rate.

> See e.g.
> df2d202e6ed4001a21c6512c244acad5d4706c87 ("bus: let's simplify things by
> getting rid of unnecessary bus parameters"). I'll leave you to guess the 
> author
> of that one.

Well, I've done a little mousing around in the repository (current, as
well as historical) and it looks like that particular file is part of
the pid 1 code. Correct me if I'm wrong.

Even conceptually, pid 1 code should not be managing dbus. Too much
can go wrong, too many opportunities to get pid 1 chasing it's tail
trying to parse an error state. And the code in that file, much
improved as it is in current, looks like code that can get into
exactly that kind of trouble.

I'd have to dig way down deep to be positive, but I'm still extremely
unimpressed.

Get pid 1 down to 100 lines of C, no loops, no functions called, then
I'll be impressed.

Heh. No, that's talki

Re: implicit linkage

2014-10-13 Thread Jonathan Dowland

On Sun, Oct 12, 2014 at 02:48:55PM -0400, Steve Litt wrote:
> On Sun, 12 Oct 2014 19:02:08 +0100 Martin Read  wrote:
> > On 12/10/14 18:13, John Hasler wrote:
> > > You have no problem with an 1800 line function?
...
> > I have a problem with 1800 line functions in general; 
...
> I have no problem with an 1800 line function.
...

*What* 1800 line function? The commit URI that was shared was an 1894-line
*file* with a large function definition starting at line 638 and ending at
1890. That's a 1252-line function.

Not only that but you're looking at a commit dating from August last year. The
function doesn't even exist any more in current systemd[1]. There are no
functions of even a 100 lines length in that file now.

[1] http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c

> What I *DO* have a problem with is the guy's welding pam onto his new init,
> and welding other critical and former separate OS functionalities onto his
> "toolset", preventing (either technically or by them being removed from the
> packages) former modules from being used.

Which guy is that? The commit that the URI referenced was written by Lennart
Poettering, so I guess you mean him; but that commit didn't touch the file that
was being complained about. Maybe you mean one of the other 17 people who have
contributed to that file?

> If I were to maintain his code, before reducing the 1800 line function, I'd
> do something about the function with 20 arguments, with each argument
> including a function call. I'd replace all of that with a struct pointer. 

I'd start with *reading the code* if I were you; something you guys clearly
aren't doing.

But if you get past that you'll be pleased to discover that such clean ups and
refactors are happening quite often. See e.g.
df2d202e6ed4001a21c6512c244acad5d4706c87 ("bus: let's simplify things by
getting rid of unnecessary bus parameters"). I'll leave you to guess the author
of that one.

-- 
Jonathan Dowland

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141013071857.gc14...@chew.redmars.org

Re: implicit linkage

2014-10-12 Thread Reco

 Hi.

On Sun, 12 Oct 2014 02:53:37 +0200
lee  wrote:

> Reco  writes:
> 
> > 3) User Alice goes away, but keeps her session in place, locking the
> > screen.
> >
> > 4) User Bob logs in another X session.
> 
> How does Bob log in while the screen is locked?

Either by selecting 'Switch session' in said screensaver, or pressing an
appropriate 'Ctrl-Alt-F' sequence on a keyboard, then logging in and
entering 'startx'.

That 'switch session' in a screensaver is about the only redeeming
quality of Display Managers IMO.

Reco

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141013103826.555e159fdb27b3d2e1f4c...@gmail.com

Re: implicit linkage

2014-10-12 Thread Joel Rees

On Mon, Oct 13, 2014 at 1:39 AM, Martin Read  wrote:
> On 12/10/14 01:43, lee wrote:
>>
>> Reco  writes:
>>
>>>
>>> http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3731acf1acfb4a6eb68374a5b137f3b368f63381#n638
>>
>>
>> Ah, this is a wonderful example :)  My assumptions about the code were
>> right.
>>
>> Does all/most of systemd look like that?
>
>
> I'm not seeing a serious problem with that function.
>
> I mean, I can certainly think of better ways to write it, but I don't find
> it bad enough that I'd want to *bother* doing so.

I'm thinking of some really fun things to try with those
XML-constants-in-macro definitions. Maybe. Have to look at where the
code is used, see whether he's keeping the input clean with the right
tools.

But I'm going to challenge you to try to find a better way to write
it. Re-factor it, and get your re-factored code to pass regressions.

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAAr43iMbH3XRZB1uGKs1vjt=UArYcT2+fc7srMFh=QkcwZz=z...@mail.gmail.com

Re: implicit linkage

2014-10-12 Thread Andrei POPESCU

On Du, 12 oct 14, 14:24:32, Steve Litt wrote:
> 
> Because it can run in the foreground, it's a prime candidate for
> daemontools (or one of the daemontools-inspired programs like nosh,
> etc).

$ apt-cache show nosh
E: No packages found

> So if you don't like brand new top level directories, ignore my
> suggestions of using djb's instructions exactly, and consider the
> Debian package.

systemd already does what I need with very little additional fiddling.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: implicit linkage

2014-10-12 Thread Miles Fidelman

On 10/11/2014 12:49 PM, Andrei POPESCU wrote:

On Sb, 11 oct 14, 12:19:29, Marty wrote:

>Could it be that a modular design for such complex tasks becomes too
>difficult to *do it right*?

I don't know, but I think given its history, the burden of proof is on
monolithic, not modular design. A better question may be whether a
distributed volunteer project can do real system architecture? 
(Where is

CERN when you need them?)

Who's history, Linux' (the kernel)? :p

I was thinking of Windows, but opened Pandora's box instead. :/

Couldn't it be that the fact that so many are embracing the "monolithic"
design of systemd is a sign that the modular design was... suboptimal
and nobody came up with a better one?

Umm. no.  In fact the leading edge is going in the other direction.  
Examples:

1. smartos (smartos.com) - latest and greatest out of opensolaris land 
(lean hypervisor - just enough os to run docker containers)

2. unikernels like mirage (http://www.openmirage.org/) - lean hypervisor 
layer to manage machine resources, then each application context is 
essentially a container with o/s like functions compiled in as libraries 
- os functions as modular libraries, just use those that are needed

3. virtual machine environments that run directly on a thin hypervisor - 
Erlang on Xen comes to mind (http://erlangonxen.org/)

4. And there are also attempts to run virtual machines on bare iron 
http://kerlnel.org/ (Erlang on bare iron) - and multiple projects that 
run Java virtual machines on bare iron

Arguably, the hypervisor layer is monolithic, but we're talking a very 
targeted set of functions that are a subset of kernel functions.

Miles Fidelman

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

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543ae813.1020...@meetinghouse.net

Re: implicit linkage

2014-10-12 Thread Marty

On 10/11/2014 12:49 PM, Andrei POPESCU wrote:

On Sb, 11 oct 14, 12:19:29, Marty wrote:

>Could it be that a modular design for such complex tasks becomes too
>difficult to *do it right*?

I don't know, but I think given its history, the burden of proof is on
monolithic, not modular design. A better question may be whether a
distributed volunteer project can do real system architecture? (Where is
CERN when you need them?)

Who's history, Linux' (the kernel)? :p

I was thinking of Windows, but opened Pandora's box instead. :/

Couldn't it be that the fact that so many are embracing the "monolithic"
design of systemd is a sign that the modular design was... suboptimal
and nobody came up with a better one?

Modular design addresses large complex system design, and it seems
counter intuitive to say that higher complexity can favor monolithic
design. Maybe the people "embracing" don't fully understand this, or
just don't care. It's one of the classic debates of computer science,
but for unix in particular, modular design has always been the time
tested, core design philosophy.

It seems ironic that just at the point where unix design superiority is
enabling it to overtake Windows in some areas, we get a monolithic
rewrite of the core system. In their minds, it seems, unix modularity is
a bug and Windows is the model for fixing it.

Components like sysvinit are dinosaurs, but modularity was the key
design feature that made piecewise-replacement possible while keeping
the whole modular system running smoothly. They threw out the
methodology for no sound technical reason, that I can see. They replaced
the Unix tool box with this:

http://partsolutions.com/wp-content/uploads/2014/01/Worlds_largest_Swiss_Army_knife_wenger_giant_knife.jpg

It is no coincidence that it promotes vendor lock-in extending from boot
to DE. It's a predictable result of their monolithic design philosophy.

Looking at the bright side, now that Debian is in the business of
replacement monolithic OS's, let's include Cyanogenmod and Chrome OS.
The future is mobile. :)

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543adbb2.3000...@ix.netcom.com

Re: implicit linkage

On Sun, 12 Oct 2014 19:02:08 +0100
Martin Read  wrote:

> On 12/10/14 18:13, John Hasler wrote:
> > Martin Read writes:
> >> I'm not seeing a serious problem with that function.
> >
> > You have no problem with an 1800 line function?
> 
> The thing that you are asking me if it is the case is not the thing I
> said.
> 
> I have a problem with 1800 line functions in general; they're clearly 
> undesirably long. I don't have a *serious* problem with 1800-line 
> functions *in general*, though they're certainly on my list of things 
> that should be refactored.
> 
> Moving on to the specific case, I don't have a *serious* problem with 
> that particular 1800-line function. It certainly merits refactoring
> (I can even see an obvious starting point for doing so), but it's not 
> unreadable or hard to follow; it's just inconveniently long.
> 
> But while we're on the topic of things I have a problem with, here's 
> one: people choosing to interpret "I'm not seeing a serious problem
> with that function" as "I have no problem with that function" :)

I have no problem with an 1800 line function. Personally, I wouldn't
write one, and I'd hate to maintain one, but how many lines the guy
puts in his function is no business of mine. What I *DO* have a problem
with is the guy's welding pam onto his new init, and welding other
critical and former separate OS functionalities onto his "toolset",
preventing (either technically or by them being removed from the
packages) former modules from being used.

From my perspective, a toolset is a set of tools you can use singly,
in combination, and *in combination with other tools*.

If I were to maintain his code, before reducing the 1800 line
function, I'd do something about the function with 20 arguments, with
each argument including a function call. I'd replace all of that with
a struct pointer. 

But then again, as a user, his implementation is none of my business,
whereas his overall architecture is *certainly* my business, especially
if it constrains my abilities to maintain/modify my system. 

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141012144855.1d37f...@mydesq2.domain.cxm

Re: implicit linkage

On Sun, 12 Oct 2014 15:33:48 +0300
Andrei POPESCU  wrote:

> On Sb, 11 oct 14, 17:41:28, Steve Litt wrote:
> > On Sat, 11 Oct 2014 22:28:31 +0300
> > Andrei POPESCU  wrote:
> > 
> > 
> > > Really? How do you write an initscript that restarts your daemon 
> > > automatically in case it fails for some reason?
> > > 
> > > Also, imapfilter doesn't write a pidfile at all, so I'd need to
> > > make at least some modifications to the script.
> > 
> > Does imapfilter run in the foreground, or does it have an option to
> > run in the foreground?
> 
> In my configuration it runs in the foreground. It can be configured
> to detach from the terminal, but anything more complicated than that
> I'd have to script myself.

Because it can run in the foreground, it's a prime candidate for
daemontools (or one of the daemontools-inspired programs like nosh,
etc).

One more thing: In my belief system and priorities, I personally feel
more comfortable making /system and /command, using the djb installer,
rather than installing the Debian daemontools package. If creating two
new top level directories makes you uncomfortable, the Debian
daemontools package creates the service and command directories in
existing subdirectories. Last time I looked, the documentation for
Debian's daemontools package wasn't as good as the documentation for
raw djb daemontools, but that might have changed.

So if you don't like brand new top level directories, ignore my
suggestions of using djb's instructions exactly, and consider the
Debian package.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141012142432.6f798...@mydesq2.domain.cxm

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

On Sun, 12 Oct 2014 19:06:11 +0900
Joel Rees  wrote:

> Hmm. Let's comment that for people newer to scripting than I am.
> 
> On Sun, Oct 12, 2014 at 6:28 AM, Steve Litt
>  wrote:

> > ### RUN THE DAEMON ###
> > exec envuidgid slitt envdir ./env setuidgid slitt \
> > /d/at/python/littcron/littcron.py \
> > /d/at/python/littcron/crontab
> 
> man exec for clues to that, understand that littcron.py is Steve's
> special cron (right, Steve?), and that he is setting up a special
> environment for things and there's other stuff there that I can only
> guess at, not having the code to littcron, I think. So I'll punt here.

Exec takes the current process, which in this case is the daemontools
run script, and swaps exec's argument for the current process. So, if
the current process is a shellscript PID 4321, after "exec gnumeric",
PID 4321 is now Gnumeric, not a shellscript.

envdir, envuidgid and setuidgid are executables provided by daemontools.

Let's talk about envdir. Although in daemontools you can export
environment variables to sub programs, just like in any other
shellscript, idiomatic daemontools usage specifies that instead of
exporting within a shellscript, you have an "environment directory" in
which each desired environment variable is associated with a file of
the same name as the environment variable name, and the contents of the
file is the value of the environment variable. So:

envdir ./env

The preceding means look in ./env, and all filenames are environment
variable names, and the contents of each is the value of the respective
filename.

setuidgid and envuidgid are daemontools provided executables to
accommodate running as an arbitrary user instead of root. Consider the
command:

setuidgid slitt

The preceding runs the entire command defined by its arguments as user
slitt instead of user root. In other words:

setuidgid gnumuser gnumeric test.gnumeric

The preceding runs gnumeric as user gnumuser. One gotcha: It runs it as
user slitt with user slitt's major group, but it doesn't run it with
auxilliary groups, for slitt, defined in /etc/group. So if the command
depends on membership in those auxilliary groups, you have to do some
fancy footwork.

Here's another challenge: Now that you're running as a non-privileged
user, you can't read the ./env directory. This is where envuidgid comes
in:

envuidgid slitt

The preceding tells daemontools that user slitt can read the
environment directory. And the way envuidgid command works, after
making this notation it simply passes control to the command defined in
its arguments, which include envdir (which finally defines the
environment directory) and setuidgid, and last but not least, the
actual program you're daemonizing.

And speaking of the devil, 

/d/at/python/littcron/littcron.py /d/at/python/littcron/crontab

The preceding is the cron substitute I wrote, whose one argument is the
crontab file you're using. If I wanted, I could manually run it in
the foreground and it would function just fine. But I wanted it
automatic, and managed as a daemon.

So daemontools runs it as user slitt, and puts its environment
variables in the /service/littcrond/env directory. Environment vars
are important here, because my cron program is called upon by its
constituants to run GUI programs, so its $DISPLAY and $XAUTHORITY vars
must be set right.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141012141133.03803...@mydesq2.domain.cxm

Re: implicit linkage

2014-10-12 Thread Martin Read


On 12/10/14 18:13, John Hasler wrote:

Martin Read writes:

I'm not seeing a serious problem with that function.


You have no problem with an 1800 line function?


The thing that you are asking me if it is the case is not the thing I said.

I have a problem with 1800 line functions in general; they're clearly 
undesirably long. I don't have a *serious* problem with 1800-line 
functions *in general*, though they're certainly on my list of things 
that should be refactored.


Moving on to the specific case, I don't have a *serious* problem with 
that particular 1800-line function. It certainly merits refactoring (I 
can even see an obvious starting point for doing so), but it's not 
unreadable or hard to follow; it's just inconveniently long.


But while we're on the topic of things I have a problem with, here's 
one: people choosing to interpret "I'm not seeing a serious problem with 
that function" as "I have no problem with that function" :)



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543ac220.8060...@zen.co.uk

Re: implicit linkage

2014-10-12 Thread John Hasler

Martin Read writes: 
> I'm not seeing a serious problem with that function.

You have no problem with an 1800 line function?
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k3459pp5@thumper.dhh.gt.org

Re: implicit linkage

On Sun, 12 Oct 2014 03:05:59 +0200
lee  wrote:

> Steve Litt  writes:
> 
> > pingaddr=8.8.8.8
> > pingaddr=192.168.100.96
> 
> Why is this is defined multiple times?

Mistake! 

The 8.8.8.8 isn't needed. That's a test of Internet connectivity, when
what I wanted was to test LAN connectivity, which in my case is my
firewall at 192.168.100.96.

You can safely remove the 8.8.8.8. Obviously :-)

Thanks for catching that.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141012125103.37e0c...@mydesq2.domain.cxm

Re: implicit linkage

2014-10-12 Thread Martin Read


On 12/10/14 01:43, lee wrote:

Reco  writes:


http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3731acf1acfb4a6eb68374a5b137f3b368f63381#n638


Ah, this is a wonderful example :)  My assumptions about the code were right.

Does all/most of systemd look like that?


I'm not seeing a serious problem with that function.

I mean, I can certainly think of better ways to write it, but I don't 
find it bad enough that I'd want to *bother* doing so.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/543aaedc.5070...@zen.co.uk

Re: implicit linkage

2014-10-12 Thread lee

Steve Litt  writes:

> pingaddr=8.8.8.8
> pingaddr=192.168.100.96

Why is this is defined multiple times?


-- 
Hallowed are the Debians!


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87d29y3xmw@yun.yagibdah.de

Re: implicit linkage

2014-10-12 Thread lee

Reco  writes:

> 3) User Alice goes away, but keeps her session in place, locking the
> screen.
>
> 4) User Bob logs in another X session.

How does Bob log in while the screen is locked?


-- 
Hallowed are the Debians!


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87h9za3y7i@yun.yagibdah.de

Re: implicit linkage

2014-10-12 Thread lee

Reco  writes:

> http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3731acf1acfb4a6eb68374a5b137f3b368f63381#n638

Ah, this is a wonderful example :)  My assumptions about the code were right.

Does all/most of systemd look like that?


-- 
Hallowed are the Debians!


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oati3yoj@yun.yagibdah.de

Re: implicit linkage

2014-10-12 Thread Andrei POPESCU

On Sb, 11 oct 14, 17:41:28, Steve Litt wrote:
> On Sat, 11 Oct 2014 22:28:31 +0300
> Andrei POPESCU  wrote:
> 
> 
> > Really? How do you write an initscript that restarts your daemon 
> > automatically in case it fails for some reason?
> > 
> > Also, imapfilter doesn't write a pidfile at all, so I'd need to make
> > at least some modifications to the script.
> 
> Does imapfilter run in the foreground, or does it have an option to run
> in the foreground?

In my configuration it runs in the foreground. It can be configured to 
detach from the terminal, but anything more complicated than that I'd 
have to script myself.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

2014-10-12 Thread Andrei POPESCU

On Du, 12 oct 14, 01:41:34, Reco wrote:
>  Hi.
> 
> On Sat, 11 Oct 2014 23:02:01 +0300
> Andrei POPESCU  wrote:
> 
> > On Sb, 11 oct 14, 23:20:34, Reco wrote:
> > > On Sat, 11 Oct 2014 20:47:36 +0300
> > > Andrei POPESCU  wrote:
> > >  
> > > > At least with systemd if you fix a bug it will benefit all daemons 
> > > > using 
> > > > it.
> > > 
> > > No, quite the contrary. By fixing such jack-of-all-trades
> > > libsystemd library you're risking to *break* some other daemons.
> > > But, pretending your point is valid, fixing /etc/init.d/skeleton grants
> > > the same benefits.
> >  
> > Nope.
> 
> The reason being? Code quality of systemd is not top-grade (to say
> lightly), and the project hardly reached its' maturity. It'll only get
> worse from here.
> And, I have to ask. Are you denying both of my statements, or the last
> one only?
 
The last one only. I have no opinion on the code quality of systemd as I 
know nothing of C.
 
> > > > This is the same reason we are using shared libraries and the Debian 
> > > > Security Team is doing it's best to track code copies.
> > > 
> > > Consider /etc/init.d/skeleton a library then. It's sources to
> > > any /etc/init.d script anyway.
> > 
> > No, it doesn't. 
> 
> Again, simple 'no' is beautiful, but hardly contributes to the
> discussion.

$ grep skeleton /etc/init.d/*
/etc/init.d/dictd:# based on /etc/init.d/skeleton v1.7  05-May-1997  by 
miqu...@cistron.nl
/etc/init.d/README:# Provides:  skeleton
/etc/init.d/skeleton:# Provides:  skeleton

It seems like you misunderstood the purpose of /etc/init.d/skeleton. 
It's not a library, but something to use as a base to write your own 
script.

As of Jessie most of 'skeleton' has been turned into 'init-d-script' 
though.

> > > > True, but sysv-rc still can't deal with them correctly.
> > > 
> > > It does not have to deal with the hardware, as it not its' job.
> > 
> > It has to mount filesystems.
> 
> No, it does not have to. In Debian, there's /etc/init.d/mountall.sh to
> do this job, in case initrd didn't care for it already. init(8) does
> not mount anything.

$ dpkg -S /etc/init.d/mountall.sh
initscripts: /etc/init.d/mountall.sh

I never said init(8) would mount anything, but sysv-rc. By sysv-rc I 
mean /etc/init.d/rc and all other scripts required to boot your system. 
Apparently most of these are split out in the initscripts package.

> And, to spice things up, [1]. Beautiful link telling everyone that it's
> not the init job to mount /usr as there's initrd for that.

But sysv-rc still has to take care your / and /usr is remounted 
according to your fstab and also for mounting everything else defined in 
/etc/fstab and how this interacts with the rest of the boot / daemons.
 
> Please enlighten me what exactly is systemd-specific here. Basically
> they tell "yadda-yadda-yadda, fix your applications, and if you don't -
> we have this 90-second hack for you".
 
Systemd makes it possible for me to adjust mpd's .service file to 
*require* a specific mount. This is not possible with sysv-rc's own 
mechanisms, I'd have to script it myself.
 
> Brilliant question. Certainly you've meant systemd, right? Just joking.
> Joke aside - because it's convenient to mount a filesystem once you
> really need it, and (which is much more important) - unmount it once
> it's not needed anymore.
 
You mean a systemd automount? Thanks for the hint ;) 

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

2014-10-12 Thread Joel Rees

Hmm. Let's comment that for people newer to scripting than I am.

On Sun, Oct 12, 2014 at 6:28 AM, Steve Litt  wrote:
> [...]
> Daemontools runscripts are incredibly simple shellscripts, that I'm
> sure you could write no sweat except in very wierd edge cases. Here's
> my run script for my home-grown cron substitute:
>
> ==
> #!/bin/sh
>
> ### DON'T START littcrond UNTIL THE NETWORK'S UP ###
> pingaddr=8.8.8.8
> pingaddr=192.168.something

Binding a value to pingaddr twice?

> echo littcrond checking network 1>&2

echo is kind of like a basic print statement, except you sort of don't
need quotes. littcrond , checking , and network are passed as three
separate tokens to echo, which sees each one as a string literal
(because it doesn't recognize any of them as something defined) and
echoed separately literally.

The clot 1>&2 , (man bash, / search for redirect) redirects  stderr to
stdout for the echo.

> while ! ping -q -c1 $pingaddr > /dev/null; do

between the while and the semicolon is the condition. Between the do
and the done are the commands to execute in the loop. The loop
condition is tested at the start of the loop.

Exclamation mark inverts the test.

ping returns a success value.

In shell, success is zero, failure non-zero. That allows failure to be
an error code, but it also surprises you if you forget that it's the
reverse of C and many other languages. This doesn't really matter
here, because ! expects the shell version of a boolean flag, so it
does what it should.

man ping tells us -q is "quiet" and -c1 says stop after 1 packet.

$pingaddr refers through the name pingaddr, which was last bound to a
LAN local address above, essentially as if pingaddr were a variable.

> sleep 1
> echo littcrond REchecking network 1>&2
> done

So the meat of the loop is in the test, and the body we just sleep and
so we are waiting/checking.

> ### RUN THE DAEMON ###
> exec envuidgid slitt envdir ./env setuidgid slitt \
> /d/at/python/littcron/littcron.py \
> /d/at/python/littcron/crontab

man exec for clues to that, understand that littcron.py is Steve's
special cron (right, Steve?), and that he is setting up a special
environment for things and there's other stuff there that I can only
guess at, not having the code to littcron, I think. So I'll punt here.

> ==

--
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart,
and ask yourself if you are not your own worst enemy.

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAAr43iPyBSL+CHt-wcz2YN1HC5jKWWbbtcmVniwMCkFbp_8=x...@mail.gmail.com

Re: implicit linkage

2014-10-11 Thread Doug

On 10/11/2014 05:28 PM, Steve Litt wrote:
> On Sat, 11 Oct 2014 21:21:14 +0300
> Andrei POPESCU  wrote:
> 
>> On Sb, 11 oct 14, 13:40:08, Steve Litt wrote:
>>>
>>> sysvinit is an idea whose time has gone. sysvinit is a poor way to
>>> showcase the Unix Way. First of all, the whole idea of runlevels is
>>> bizarre, and adds a lot of complexity to init scripts. If you
>>> compare a daemontools /service/myserviced/run to an init script,
>>> you'll see an order of magnetude simplification, without
>>> sacrificing the flexibility of a shellscript.
>>
>> Why should I write a script? I'm not a programmer.
> 
> Why should I configure and maintain a firewall? I'm not an admin.
> 
> One's being a "programmer" is such an arbitrary division. OK, you're
> not the first guy I'd call if I wanted a device driver coded, but I'd
> have complete confidence in you to write a short shellscript. And,
> being able to write a short shellscript (which I'm sure you can do),
> would make you a much more able Linux administrator and user.
> 
>>   
>> [snip]
>>
>>> I *might* characterize the preceding as trying to reduce complexity
>>> for the dufus who can't even write a shellscript. However, the cost
>>> of this reduced complexity for the dufus is huge complexity within
>>> the program: complexity even smart people can't work around without
>>> some truly ridiculous kludges.
>>
>> I can write a (simple) shellscript, but I wouldn't dare write an
>> initscript or even a daemontools runscript.
> 
> Daemontools runscripts are incredibly simple shellscripts, that I'm
> sure you could write no sweat except in very wierd edge cases. Here's
> my run script for my home-grown cron substitute:
> 
> ==
> #!/bin/sh
> 
> ### DON'T START littcrond UNTIL THE NETWORK'S UP ###
> pingaddr=8.8.8.8
> pingaddr=192.168.100.96
> echo littcrond checking network 1>&2
> while ! ping -q -c1 $pingaddr > /dev/null; do
>sleep 1
>echo littcrond REchecking network 1>&2
> done
> 
> ### RUN THE DAEMON ###
> exec envuidgid slitt envdir ./env setuidgid slitt  \
>/d/at/python/littcron/littcron.py \
>/d/at/python/littcron/crontab
> ==
> 
> The last three lines are really one line that wordwraps in email. If I
> hadn't checked for the network being up, this would have been a two
> line shellscript. I've known you (online) for several months, and
> although we sometimes disagree, I know you're pretty smart, so I'm
> positive you could have written this shellscript without breaking a
> sweat.
> 
> 
/snip/

I've been using Linux seriously for about five years, altho I diddled
around with it a bit earlier. About the time I started seriously using
it, I took a course in Linux at the local community college, of which
perhaps a third was devoted to scripting. Quite some time earlier, I
had taken a course in Pascal, which I did very well in, and I actually
wrote some useful code in that language for my job as an engineer. 
Prior to that, I used and wrote a lot of stuff in BASIC. 
Getting back to my Linux class, I received a B+. I don't know how much
code I could have actually written when class was over, since one
needs to know a lot more about system commands. At any rate, it's been 
about five years, and I could not now write the script you use to 
illustrate this message, and I'm not really sure I can read it!

BASH scripts are written in perfectly logical code, quite similar, in 
fact, to Pascal. The problem is that they don't have the advantage
of normal language; they rely on all sorts of abbreviations instead
of the English words that more popular programming languages like
Pascal, C, Python, and BASIC use. It's been probably 25 years
since I wrote anything in Pascal or BASIC, but with about 30 minutes
of reference-book research, I think I could go back and do it now.
I can't imagine that to be true with BASH scripting.

Just call me dufus.

--doug

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5439b7af.4000...@optonline.net

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

 Hi.

On Sat, 11 Oct 2014 17:35:00 -0400
Steve Litt  wrote:

> On Sat, 11 Oct 2014 23:20:34 +0400
> Reco  wrote:
> 
> >  Hi.
> >  
> > On Sat, 11 Oct 2014 20:47:36 +0300
> > Andrei POPESCU  wrote:
> 
> [huge snip]
> 
> > > No, that was just for the "I'm sole user of this system, why would
> > > I need this logind stuff?" crowd.
> > 
> > Thanks, I'm perfectly aware why I don't need logind - it does not
> > solve any of the problems I need to solve. Same for it's predecessor,
> > ConsoleKit.
> > If I ever need a computer with the multiple X servers running
> > simultaneously - I'll consider using logind.
> 
> Am I missing something. If I needed multiple X servers, wouldn't I just
> CLI log into different users on Ctrl+Alt+F2 and Ctrl+Alt+F3, and run
> startx from each?

That's one way of doing it, sure. An old way, and a convenient one,
but it's somewhat cruel to expect from the average user these days.
An alternative would be some kind of a Display Manager (even venerable
xdm will suffice). 

But that's not the point. The point is the following scenario:

1) A single shared PC with 2 users just to keep it simple.

2) User Alice logs in and starts browsing the Internet and listening
some music.

3) User Alice goes away, but keeps her session in place, locking the
screen.

4) User Bob logs in another X session.

5) User Bob does not share Alices' music tastes, yet he's unable to
shut off Alices' music as he's the different user. So, unless Bob has
root password - he's doomed (pun intended) to listen the music he does
not like.

Presumably that scenario is something that logind has to overcome.

Reco

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141012014940.0e2fe89eba55854a664d1...@gmail.com

Re: implicit linkage

On Sat, 11 Oct 2014 22:28:31 +0300
Andrei POPESCU  wrote:


> Really? How do you write an initscript that restarts your daemon 
> automatically in case it fails for some reason?
> 
> Also, imapfilter doesn't write a pidfile at all, so I'd need to make
> at least some modifications to the script.

Does imapfilter run in the foreground, or does it have an option to run
in the foreground?

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141011174128.4afe4...@mydesq2.domain.cxm

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

 Hi.

On Sat, 11 Oct 2014 23:02:01 +0300
Andrei POPESCU  wrote:

> On Sb, 11 oct 14, 23:20:34, Reco wrote:
> > On Sat, 11 Oct 2014 20:47:36 +0300
> > Andrei POPESCU  wrote:
> >  
> > > At least with systemd if you fix a bug it will benefit all daemons using 
> > > it.
> > 
> > No, quite the contrary. By fixing such jack-of-all-trades
> > libsystemd library you're risking to *break* some other daemons.
> > But, pretending your point is valid, fixing /etc/init.d/skeleton grants
> > the same benefits.
>  
> Nope.

The reason being? Code quality of systemd is not top-grade (to say
lightly), and the project hardly reached its' maturity. It'll only get
worse from here.
And, I have to ask. Are you denying both of my statements, or the last
one only?

> > > This is the same reason we are using shared libraries and the Debian 
> > > Security Team is doing it's best to track code copies.
> > 
> > Consider /etc/init.d/skeleton a library then. It's sources to
> > any /etc/init.d script anyway.
> 
> No, it doesn't. 

Again, simple 'no' is beautiful, but hardly contributes to the
discussion.

> > > True, but sysv-rc still can't deal with them correctly.
> > 
> > It does not have to deal with the hardware, as it not its' job.
> 
> It has to mount filesystems.

No, it does not have to. In Debian, there's /etc/init.d/mountall.sh to
do this job, in case initrd didn't care for it already. init(8) does
not mount anything.
And, to spice things up, [1]. Beautiful link telling everyone that it's
not the init job to mount /usr as there's initrd for that.

> > Ok. You have wired, that's one stanza in /etc/network/interfaces. Or
> > one obscure systemd's unit, if you prefer *that*.
> > You have wireless, and while it's possible to
> > use /etc/network/interfaces for that too (I do, for example), Joe the
> > Average User would probably use NetworkDestroyer (sorry, Manager), or
> > wicd. Anyway, wireless requires usage of wpa_supplicant, which is not a
> > part of systemd. Presumably one can use a systemd's unit for that too,
> > but I've never tried it.
> > A dongle for a mobile is probably a good old g_ether network interface
> > aka usb0. It's complicated somewhat as one may need to use
> > usb-modeswitch (not a part of systemd, btw), but it's nothing more
> > complex than yet another stanza in /etc/network/interfaces.
> > As for the IPv6 - unless you're turning your own PC into a router,
> > configuring IPv6 is something that kernel does for you already without
> > any intervention from the userspace (it's called a Router Advertisment).
> 
> My point was that userspace has to react to changes in networking. The 
> following might also provide for an interested read:
> http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

Oh, you've meant *that* by complex. Ok, I misunderstood you.
Along all presumably good things that page tells, there's these gems:

This will ensure that all configured network devices are up and have an
IP address assigned before boot continues. This service will time out
after 90s. Enabling this service might considerably delay your boot
even if the timeout is not reached. Both services are disabled by
default.
…
If you are a developer, instead of wondering what to do about
network.target, please just fix your program to be friendly to
dynamically changing network configuration. That way you will make your
users happy because things just start to work, and you will get fewer
bug reports as your stuff is just rock solid.

Please enlighten me what exactly is systemd-specific here. Basically
they tell "yadda-yadda-yadda, fix your applications, and if you don't -
we have this 90-second hack for you".

> > You don't have to, in this specific case. NFS should be mounted long
> > before any daemon starts, mpd included. Things can break, as your
> > example show.
> > A better example would be 'how I can ensure that mpd will
> > stop if I unmount a NFS share?'.
> > Still, I agree that's a valid point, *if* you disregard an existence
> > of automount(5). Because, mounting NFS from an fstab is *so* AIX.
>  
> Why should I need to install yet another daemon, with yet another 
> configuration file/syntax?

Brilliant question. Certainly you've meant systemd, right? Just joking.
Joke aside - because it's convenient to mount a filesystem once you
really need it, and (which is much more important) - unmount it once
it's not needed anymore.

> > [3] tells us "systemd 30 and newer include systemd-logind. This is a
> > tiny daemon that manages user logins and seats in various ways."
> > I had an impression that an ssh login is an actual login.
> > And, since you can easily start an X session over ssh - there's need to
> > consider it a ssh login a seat too.
> 
> Are you talking about X forwarding? Isn't the X session on the ssh 
> client side (a.k.a. the X server side)?

X server on host A. ssh connection from host A to host B. X clients
wrapped in X session on host B. Saves the trouble of using XDMCP. Call
it the

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

On Sat, 11 Oct 2014 23:20:34 +0400
Reco  wrote:

>  Hi.
>  
> On Sat, 11 Oct 2014 20:47:36 +0300
> Andrei POPESCU  wrote:

[huge snip]

> > No, that was just for the "I'm sole user of this system, why would
> > I need this logind stuff?" crowd.
> 
> Thanks, I'm perfectly aware why I don't need logind - it does not
> solve any of the problems I need to solve. Same for it's predecessor,
> ConsoleKit.
> If I ever need a computer with the multiple X servers running
> simultaneously - I'll consider using logind.

Am I missing something. If I needed multiple X servers, wouldn't I just
CLI log into different users on Ctrl+Alt+F2 and Ctrl+Alt+F3, and run
startx from each?

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141011173500.03936...@mydesq2.domain.cxm

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

On Sat, 11 Oct 2014 21:21:14 +0300
Andrei POPESCU  wrote:

> On Sb, 11 oct 14, 13:40:08, Steve Litt wrote:
> > 
> > sysvinit is an idea whose time has gone. sysvinit is a poor way to
> > showcase the Unix Way. First of all, the whole idea of runlevels is
> > bizarre, and adds a lot of complexity to init scripts. If you
> > compare a daemontools /service/myserviced/run to an init script,
> > you'll see an order of magnetude simplification, without
> > sacrificing the flexibility of a shellscript.
> 
> Why should I write a script? I'm not a programmer.

Why should I configure and maintain a firewall? I'm not an admin.

One's being a "programmer" is such an arbitrary division. OK, you're
not the first guy I'd call if I wanted a device driver coded, but I'd
have complete confidence in you to write a short shellscript. And,
being able to write a short shellscript (which I'm sure you can do),
would make you a much more able Linux administrator and user.

>  
> [snip]
> 
> > I *might* characterize the preceding as trying to reduce complexity
> > for the dufus who can't even write a shellscript. However, the cost
> > of this reduced complexity for the dufus is huge complexity within
> > the program: complexity even smart people can't work around without
> > some truly ridiculous kludges.
> 
> I can write a (simple) shellscript, but I wouldn't dare write an 
> initscript or even a daemontools runscript.

Daemontools runscripts are incredibly simple shellscripts, that I'm
sure you could write no sweat except in very wierd edge cases. Here's
my run script for my home-grown cron substitute:

==
#!/bin/sh

### DON'T START littcrond UNTIL THE NETWORK'S UP ###
pingaddr=8.8.8.8
pingaddr=192.168.100.96
echo littcrond checking network 1>&2
while ! ping -q -c1 $pingaddr > /dev/null; do
  sleep 1
  echo littcrond REchecking network 1>&2
done

### RUN THE DAEMON ###
exec envuidgid slitt envdir ./env setuidgid slitt  \
  /d/at/python/littcron/littcron.py \
  /d/at/python/littcron/crontab
==

The last three lines are really one line that wordwraps in email. If I
hadn't checked for the network being up, this would have been a two
line shellscript. I've known you (online) for several months, and
although we sometimes disagree, I know you're pretty smart, so I'm
positive you could have written this shellscript without breaking a
sweat.

>  
> > I have a theory on that. runit, s6, init-ng, etc never caught on
> > because sysvinit was considered good enough, and it was easier for
> > the average person to work around its rough edges rather than learn
> > a new init system. 
>  
> I recently needed something to run imapfilter and restart it in case 
> it might exit, so I had a look at daemontools. I gave up quickly
> after I realised the amount of scaffolding required just to get
> daemontools itself running (additional top-level directories, are you
> kidding?).
> 
> With systemd (v215) I had to write this unit file:

[clip Andre's easy description of daemonizing imapfilter with systemd]

Yes, there's significant scaffolding, mostly revolving around
installing daemontools. Also, Andre didn't bring this up, but it's
implicit in his objection: Most daemontools documentation is terse and
assumes a whole lot of Unix-smarts on the part of the reader, with few
examples.

That's why I wrote this document:

http://www.troubleshooters.com/linux/djbdns/daemontools_intro.htm

Armed with the preceding document, a person can learn daemontools in a
day, and use it for the rest of his life.

If you can run imapfilter in the foreground, it's trivial to have
daemontools daemonize it for you. And you'll know *exactly* how it's
going to work.

The other benefit of daemontools is it works, every single time. It
never misfires, it never behaves in ways that are unspecified or
against specification, it keeps working for years, and a simple (as
root) backup walks it from distro to distro.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141011172828.4a603...@mydesq2.domain.cxm

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

On Sb, 11 oct 14, 23:20:34, Reco wrote:
> On Sat, 11 Oct 2014 20:47:36 +0300
> Andrei POPESCU  wrote:
>  
> > At least with systemd if you fix a bug it will benefit all daemons using 
> > it.
> 
> No, quite the contrary. By fixing such jack-of-all-trades
> libsystemd library you're risking to *break* some other daemons.
> But, pretending your point is valid, fixing /etc/init.d/skeleton grants
> the same benefits.
 
Nope.

> > This is the same reason we are using shared libraries and the Debian 
> > Security Team is doing it's best to track code copies.
> 
> Consider /etc/init.d/skeleton a library then. It's sources to
> any /etc/init.d script anyway.

No, it doesn't. 
 
> > True, but sysv-rc still can't deal with them correctly.
> 
> It does not have to deal with the hardware, as it not its' job.

It has to mount filesystems.
 
> Ok. You have wired, that's one stanza in /etc/network/interfaces. Or
> one obscure systemd's unit, if you prefer *that*.
> You have wireless, and while it's possible to
> use /etc/network/interfaces for that too (I do, for example), Joe the
> Average User would probably use NetworkDestroyer (sorry, Manager), or
> wicd. Anyway, wireless requires usage of wpa_supplicant, which is not a
> part of systemd. Presumably one can use a systemd's unit for that too,
> but I've never tried it.
> A dongle for a mobile is probably a good old g_ether network interface
> aka usb0. It's complicated somewhat as one may need to use
> usb-modeswitch (not a part of systemd, btw), but it's nothing more
> complex than yet another stanza in /etc/network/interfaces.
> As for the IPv6 - unless you're turning your own PC into a router,
> configuring IPv6 is something that kernel does for you already without
> any intervention from the userspace (it's called a Router Advertisment).

My point was that userspace has to react to changes in networking. The 
following might also provide for an interested read:
http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
 
> You don't have to, in this specific case. NFS should be mounted long
> before any daemon starts, mpd included. Things can break, as your
> example show.
> A better example would be 'how I can ensure that mpd will
> stop if I unmount a NFS share?'.
> Still, I agree that's a valid point, *if* you disregard an existence
> of automount(5). Because, mounting NFS from an fstab is *so* AIX.
 
Why should I need to install yet another daemon, with yet another 
configuration file/syntax?
 
> [3] tells us "systemd 30 and newer include systemd-logind. This is a
> tiny daemon that manages user logins and seats in various ways."
> I had an impression that an ssh login is an actual login.
> And, since you can easily start an X session over ssh - there's need to
> consider it a ssh login a seat too.

Are you talking about X forwarding? Isn't the X session on the ssh 
client side (a.k.a. the X server side)?
 
> As for the x11vnc - I doubt that it could be fixed. x11vnc attaches to
> an existing X server, and is translating said server I/O over VNC to
> anyone. It does not spawn its' own session, so there's nothing that can
> be tracked.

According to the package description it has "UNIX account and password" 
support. If that is done via pam (how else?) it should be possible for 
it to use libpam-logind.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: implicit linkage

On Sb, 11 oct 14, 14:12:20, John Hasler wrote:
> Andrei POPESCU writes:
> > With systemd (v215) I had to write this unit file:
> 
> Which is about as complex as filling out the skeleteon script to create
> an initscript to do the same thing.

Really? How do you write an initscript that restarts your daemon 
automatically in case it fails for some reason?

Also, imapfilter doesn't write a pidfile at all, so I'd need to make at 
least some modifications to the script.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

 Hi.

On Sat, 11 Oct 2014 20:47:36 +0300
Andrei POPESCU  wrote:

> On Sb, 11 oct 14, 19:57:42, Reco wrote:
> > On Sat, 11 Oct 2014 15:18:58 +0300
> > Andrei POPESCU  wrote:
> > 
> > > On Vi, 10 oct 14, 08:36:23, Joel Rees wrote:
> > > > 
> > > > Some complexities you can encapsulate or hide, or expose in an
> > > > organized manner so that that are easier to deal with. Others, no.
> > > 
> > > [big snip]
> > > 
> > > The complexity argument can be used both ways:
> > 
> > Indeed. In fact:
> > 
> > 
> > > - the Unix way (do one thing and do it well) leads to many small tools 
> > >   that can be combined in different ways, where each tool has its own 
> > >   quirks, bugs, release schedules, etc. that only increase complexity
> > 
> > On the other hand, full blown systemd comes with 69 binaries on board,
> > and such number of binaries reduce complexity somehow :)
>  
> coreutils alone has 107 binaries.

Yup. Please calculate how many of them are actually used
in /etc/init.d. You'll lower your number by the point of magnutude.

Besides, coreutils is an essential package in Debian, systemd is not.

> > > - sysvinit (/bin/init) is indeed quite simple, but in practice it's own 
> > >   mechanisms (/etc/inittab) are only used to start sysv-rc 
> > >   (/etc/init.d/rc)
> > 
> > You're wrong. At least gettys are started via /etc/inittab, and
> > Ctrl-Alt-Del handling goes there too.
> 
> Oh yes, forgot about that. But my point still stands: why is (almost) 
> nobody using /etc/inittab to manage their services?

Because one does not start services only, one sometimes needs to stop
them. That's something that dbus people didn't learn in all these
years, it seems.

> > > , which starts all other initscripts, poorly written 
> > >   (/etc/init.d/skeleton itself is known to have bugs) 
> > 
> > Every software more complex than 'Hello World' has bugs. Heck,
> > *systemd* has bugs.
> 
> Yes, but with initscripts you can get slightly different version of the 
> same bug (e.g. depending on which version of 'skeleton' they are based 
> on, the script-fu of the respective maintainer, the phase of the moon, 
> etc), but much more difficult to fix, because you have to inspect each 
> package.

And with systemd you can have the same based on the same criteria. 
I mean, do you really expect a sane behavior from the project with a
code quality like this - [1]?

> At least with systemd if you fix a bug it will benefit all daemons using 
> it.

No, quite the contrary. By fixing such jack-of-all-trades
libsystemd library you're risking to *break* some other daemons.
But, pretending your point is valid, fixing /etc/init.d/skeleton grants
the same benefits.

> This is the same reason we are using shared libraries and the Debian 
> Security Team is doing it's best to track code copies.

Consider /etc/init.d/skeleton a library then. It's sources to
any /etc/init.d script anyway.

> The recent method of using a common script goes in the right direction 
> though.
>  
> > >   in a (poor) 
> > >   programming language (shell script) 
> > 
> > As latest development of OpenSSL show us, C isn't that great
> > programming language either, and more complex than shell.
> 
> Sure, but at least a lot of eyeballs are looking at it. How many eyes do 
> you think look at the average initscript?

As recent 'shellshock' vulnerability shows, many eyeballs are good, but
hardly enough (hint - shellshock was introduced in 1989). And it also
shows, that there're curious minds that are finding bugs everywhere,
including shell scripts. Especially now, after shellshock 'fired'.

> > >   The scrips are not even enough, 
> > >   they have to rely on additional tools like start-stop-daemon(8) with 
> > >   their own quirks and bugs.
> > 
> > That's the intended usage of shell scripts - to be a glue between
> > utilities. Does it surprise you?
> 
> Nope, it just proves my point that sysv-rc is *very* complex.

Hardly. It proves that starting daemons is complex. Sysv-rc is simple
by itself, and that's about the only good thing that can be said about
sysv-rc IMO.

> > > - each service/daemon is implemented in its own unique way, with 
> > >   different methods of running (quite often multiple ways, depending on 
> > >   start-up switches, like foreground, forking, etc.), reloading, 
> > >   logging, etc.
> > 
> > Given that said 'services' are written by different people - that's
> > nothing unusual. In fact, ever-growing DSL of systemd's units clearly
> > shows that 'one size fits all' approach constantly fail to account for
> > various corner cases.
> 
> Such as?

Please see an arbitrary systemd's changelog. Observe phrases such as
"we've added phrase FooBar to the unit files". Such phrases are the
sign of DSL change, and it only happen for two reasons:

a) Sudden irresistible urge (or voices in someone's head) to add a
phrase.
b) There's some daemon that genuinely need it.

I prefer explanation b), what about you?

> > > - computers have gotten quite

Re: implicit linkage

2014-10-11 Thread John Hasler

Andrei POPESCU writes:
> With systemd (v215) I had to write this unit file:

Which is about as complex as filling out the skeleteon script to create
an initscript to do the same thing.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87siiua0a3@thumper.dhh.gt.org

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

On Sb, 11 oct 14, 13:40:08, Steve Litt wrote:
> 
> sysvinit is an idea whose time has gone. sysvinit is a poor way to
> showcase the Unix Way. First of all, the whole idea of runlevels is
> bizarre, and adds a lot of complexity to init scripts. If you
> compare a daemontools /service/myserviced/run to an init script, you'll
> see an order of magnetude simplification, without sacrificing the
> flexibility of a shellscript.

Why should I write a script? I'm not a programmer.
 
[snip]

> I *might* characterize the preceding as trying to reduce complexity for
> the dufus who can't even write a shellscript. However, the cost of this
> reduced complexity for the dufus is huge complexity within the program:
> complexity even smart people can't work around without some truly
> ridiculous kludges.

I can write a (simple) shellscript, but I wouldn't dare write an 
initscript or even a daemontools runscript.
 
> I have a theory on that. runit, s6, init-ng, etc never caught on
> because sysvinit was considered good enough, and it was easier for the
> average person to work around its rough edges rather than learn a new
> init system. 
 
I recently needed something to run imapfilter and restart it in case 
it might exit, so I had a look at daemontools. I gave up quickly after I 
realised the amount of scaffolding required just to get daemontools 
itself running (additional top-level directories, are you kidding?).

With systemd (v215) I had to write this unit file:

,[ .config/systemd/user/imapfilter.service ]
| [Unit]
| Description=Unit to run imapfilter
|
| [Service]
| Type=simple
| ExecStart=/usr/bin/imapfilter
| Restart=always
|
| [Install]
| WantedBy=default.target
`

$ systemctl --user start imapfilter # to start it right away
$ systemctl --user enable imapfilter # to have it start automatically on login

(optional)
# systemctl enable-linger  # to enable my 'systemd --user' instance to 
run even if I'm not logged in.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

On Sb, 11 oct 14, 19:57:42, Reco wrote:
> On Sat, 11 Oct 2014 15:18:58 +0300
> Andrei POPESCU  wrote:
> 
> > On Vi, 10 oct 14, 08:36:23, Joel Rees wrote:
> > > 
> > > Some complexities you can encapsulate or hide, or expose in an
> > > organized manner so that that are easier to deal with. Others, no.
> > 
> > [big snip]
> > 
> > The complexity argument can be used both ways:
> 
> Indeed. In fact:
> 
> 
> > - the Unix way (do one thing and do it well) leads to many small tools 
> >   that can be combined in different ways, where each tool has its own 
> >   quirks, bugs, release schedules, etc. that only increase complexity
> 
> On the other hand, full blown systemd comes with 69 binaries on board,
> and such number of binaries reduce complexity somehow :)
 
coreutils alone has 107 binaries. 

> > - sysvinit (/bin/init) is indeed quite simple, but in practice it's own 
> >   mechanisms (/etc/inittab) are only used to start sysv-rc 
> >   (/etc/init.d/rc)
> 
> You're wrong. At least gettys are started via /etc/inittab, and
> Ctrl-Alt-Del handling goes there too.

Oh yes, forgot about that. But my point still stands: why is (almost) 
nobody using /etc/inittab to manage their services?

> > , which starts all other initscripts, poorly written 
> >   (/etc/init.d/skeleton itself is known to have bugs) 
> 
> Every software more complex than 'Hello World' has bugs. Heck,
> *systemd* has bugs.

Yes, but with initscripts you can get slightly different version of the 
same bug (e.g. depending on which version of 'skeleton' they are based 
on, the script-fu of the respective maintainer, the phase of the moon, 
etc), but much more difficult to fix, because you have to inspect each 
package.

At least with systemd if you fix a bug it will benefit all daemons using 
it.

This is the same reason we are using shared libraries and the Debian 
Security Team is doing it's best to track code copies.

The recent method of using a common script goes in the right direction 
though.
 
> >   in a (poor) 
> >   programming language (shell script) 
> 
> As latest development of OpenSSL show us, C isn't that great
> programming language either, and more complex than shell.

Sure, but at least a lot of eyeballs are looking at it. How many eyes do 
you think look at the average initscript?

> >   with many different 
> >   implementations (bash, dash, etc.). 
> 
> As long as shell in question conforms with POSIX specification, it does
> not matter. And nobody forbids one to put a binary into /etc/init.d,
> it'll work. Or a Perl script. It's just a convention that everyone put
> shell scripts there.

You're right, I just went through Policy 9.3 and can't find it 
explicitly stated that scripts in /etc/init.d/ should be shell scripts, 
but it seems to be an implicit assumption (ha!).

> >   The scrips are not even enough, 
> >   they have to rely on additional tools like start-stop-daemon(8) with 
> >   their own quirks and bugs.
> 
> That's the intended usage of shell scripts - to be a glue between
> utilities. Does it surprise you?

Nope, it just proves my point that sysv-rc is *very* complex.

> > - each service/daemon is implemented in its own unique way, with 
> >   different methods of running (quite often multiple ways, depending on 
> >   start-up switches, like foreground, forking, etc.), reloading, 
> >   logging, etc.
> 
> Given that said 'services' are written by different people - that's
> nothing unusual. In fact, ever-growing DSL of systemd's units clearly
> shows that 'one size fits all' approach constantly fail to account for
> various corner cases.

Such as?
 
> > - computers have gotten quite complex themselves with removable devices, 
> >   complex network connectivity, etc.
> 
> 'Removable devices' could been news in 1980s. 

True, but sysv-rc still can't deal with them correctly.

> 'Complex network connectivity' usually requires one to configure a
> network interface or two, and start a bunch of helper daemons. It would
> be fair argument if systemd suite contained implementations of all VPN
> clients known to the man - but it does not.

I'll just give my laptop as example: I have wired & wireless at home, 
other wired/wireless network if I take my laptop around plus a dongle 
for mobile. And then there's IPv6 (coming... is... coming... whatever).

> > - multiple users on the same system (GNU/Linux is supposed to be a 
> >   multiuser system, isn't it) with different backgrounds, level of 
> >   technical understanding, expectations, etc.
> 
> Wait, wait, wait. You mean there was no multiuser systems based on
> GNU/Linux before systemd invention? Or said multiuser systems were
> unusable?

No, that was just for the "I'm sole user of this system, why would I 
need this logind stuff?" crowd.

> > It feels to me like systemd (the project) is rather *trying* to reduce 
> > complexity, by providing:
> > 
> > - a clear and simple way (unit files) to declare what a service needs 
> >   and how it should be run and a clea

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

On Sat, 11 Oct 2014 15:18:58 +0300
Andrei POPESCU  wrote:

> On Vi, 10 oct 14, 08:36:23, Joel Rees wrote:
> > 
> > Some complexities you can encapsulate or hide, or expose in an
> > organized manner so that that are easier to deal with. Others, no.
> 
> [big snip]
> 
> The complexity argument can be used both ways:
> 
> - the Unix way (do one thing and do it well) leads to many small
> tools that can be combined in different ways, where each tool has its
> own quirks, bugs, release schedules, etc. that only increase
> complexity 

At first, yes. But over time these do-one-thing-and-do-it-well pieces
become battle-hardened and fully tested, and they change very slowly.
And, they're not subject to feature creep.

> - sysvinit (/bin/init) is indeed quite simple, but in practice it's
> own mechanisms (/etc/inittab) are only used to start sysv-rc 
>   (/etc/init.d/rc), which starts all other initscripts, poorly
> written (/etc/init.d/skeleton itself is known to have bugs) in a
> (poor) programming language (shell script) with many different 
>   implementations (bash, dash, etc.). The scrips are not even enough, 
>   they have to rely on additional tools like start-stop-daemon(8)
> with their own quirks and bugs.

:-)

sysvinit is an idea whose time has gone. sysvinit is a poor way to
showcase the Unix Way. First of all, the whole idea of runlevels is
bizarre, and adds a lot of complexity to init scripts. If you
compare a daemontools /service/myserviced/run to an init script, you'll
see an order of magnetude simplification, without sacrificing the
flexibility of a shellscript.

>   
> - each service/daemon is implemented in its own unique way, with 
>   different methods of running (quite often multiple ways, depending
> on start-up switches, like foreground, forking, etc.), reloading, 
>   logging, etc.

Daemontools, and I'd assume all the PID1 softwares based on
daemontools, handles the backgroundization itself. So you just use a
flag to run your daemon in the foreground, and it's taken care of. For
those developers who insist on making their lives difficult by
backgrounding it themselves, with no foreground switch, daemontools
includes a program which *sometimes* can foregroundize the
backgroundized service, although obviously the real way to do it is to
have the original programmer provide a way to run his program in the
foreground.

>   
> - computers have gotten quite complex themselves with removable
> devices, complex network connectivity, etc.
> 
> - multiple users on the same system (GNU/Linux is supposed to be a 
>   multiuser system, isn't it) with different backgrounds, level of 
>   technical understanding, expectations, etc.
> 
> It feels to me like systemd (the project) is rather *trying* to
> reduce complexity, by providing:
> 
> - a clear and simple way (unit files) to declare what a service needs 
>   and how it should be run and a clear and simple method for the
> daemon to notify when it is ready to provide its service if its
> authors choose to implement it
> 
> - mechanisms to deal with badly behaved daemons as well as provide 
>   proper isolation (e.g. cgroups, tmp files handling, etc.)
> 
> - mechanisms to deal with the complex interactions between daemons, 
>   devices, networks, etc.
> 
> - a logging mechanism that can capture *all* output of a daemon
> (stdout, stderr, logging)
> 
> - a unified way to manage users (as in humans) and their complex ways
> of interacting with the computer (different privileges, local,
> remote, etc.)

I *might* characterize the preceding as trying to reduce complexity for
the dufus who can't even write a shellscript. However, the cost of this
reduced complexity for the dufus is huge complexity within the program:
complexity even smart people can't work around without some truly
ridiculous kludges.

Also, and this is just my opinion, reducing complexity is not what I
think Red Hat is trying to do. I think they're trying to make an
operating system so complex that their help is necessary for anything
but the most plain vanilla installations, and they're trying to create
a Linux ecosystem where all distributions must march to the Red Hat
drummer, with the ultimate goal of monopolism and divergence from
standards (POSIX for one). Like I said, this is my opinion. You might
say "Hanlon's razor", and I'd reply "follow the money."

> 
> - etc.
> 
> Is systemd (the project) trying to do too much? Possibly.

:-) Nice understatement.

> Would it be better if this was done in a modular design *done right*? 
> Probably.

I'd say modular design done right would be for systemd to be PID1 and
nothing else. It should be able to accept all PAM implementations
currently accepted. It shouldn't need to subsume all sorts of other OS
functions. And if that were the case, it would be done already, with
not a bit of resistance from users.

> 
> Yet, none of the solutions so far has *really* caught on.
> daemontools, runit, s6, init-ng, etc. and even upstart were either
> neve

Re: implicit linkage

On Sb, 11 oct 14, 12:19:29, Marty wrote:
> 
> >Could it be that a modular design for such complex tasks becomes too
> >difficult to *do it right*?
> 
> I don't know, but I think given its history, the burden of proof is on
> monolithic, not modular design. A better question may be whether a
> distributed volunteer project can do real system architecture? (Where is
> CERN when you need them?)

Who's history, Linux' (the kernel)? :p

Couldn't it be that the fact that so many are embracing the "monolithic" 
design of systemd is a sign that the modular design was... suboptimal 
and nobody came up with a better one?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: implicit linkage

2014-10-11 Thread Marty


On 10/11/2014 08:18 AM, Andrei POPESCU wrote:

Is systemd (the project) trying to do too much? Possibly.
Would it be better if this was done in a modular design *done right*?
Probably.

Yet, none of the solutions so far has *really* caught on. daemontools,
runit, s6, init-ng, etc. and even upstart were either never adopted on a
large scale or eventually abandoned in favor of systemd.


They also probably did not have dependency bundling and an $11B 
corporation behind them either. :)



As far as I understand Linus Torvalds himself admits that a modular
kernel design is better, yet he choose to make Linux monolithic. On the
other hand Hurd is still not even in a releasable state.


I don't think there's any question that modular is harder. It requires 
actual engineering, not systemd-style hacking. Even Windows experimented 
with a "microkernel" in the Cutler days, but ultimately seems to have 
settled back into bloatware, the path of least resistance.


I also wonder if Linux has scaling issues, and how much corporate 
influence this causes and how much longer Linus can fend it off?



Could it be that a modular design for such complex tasks becomes too
difficult to *do it right*?


I don't know, but I think given its history, the burden of proof is on 
monolithic, not modular design. A better question may be whether a 
distributed volunteer project can do real system architecture? (Where is 
CERN when you need them?)



Is systemd going to change the GNU/Linux ecosystem? Definitely.

Will this change be good or bad? Only time will tell, but I'm quite sure
that even if the change will turn out to be bad it will *not* destroy
GNU/Linux, but help it evolve in better ways.


If nothing else it gives us a new low bar, a bogyman to replace Windows, 
which is seeing hard times, and now even resorts to copying Linux. :)




Kind regards,
Andrei




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/54395891.2040...@ix.netcom.com

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)

 Hi.

On Sat, 11 Oct 2014 15:18:58 +0300
Andrei POPESCU  wrote:

> On Vi, 10 oct 14, 08:36:23, Joel Rees wrote:
> > 
> > Some complexities you can encapsulate or hide, or expose in an
> > organized manner so that that are easier to deal with. Others, no.
> 
> [big snip]
> 
> The complexity argument can be used both ways:

Indeed. In fact:

> - the Unix way (do one thing and do it well) leads to many small tools 
>   that can be combined in different ways, where each tool has its own 
>   quirks, bugs, release schedules, etc. that only increase complexity

On the other hand, full blown systemd comes with 69 binaries on board,
and such number of binaries reduce complexity somehow :)

> - sysvinit (/bin/init) is indeed quite simple, but in practice it's own 
>   mechanisms (/etc/inittab) are only used to start sysv-rc 
>   (/etc/init.d/rc)

You're wrong. At least gettys are started via /etc/inittab, and
Ctrl-Alt-Del handling goes there too.

> , which starts all other initscripts, poorly written 
>   (/etc/init.d/skeleton itself is known to have bugs) 

Every software more complex than 'Hello World' has bugs. Heck,
*systemd* has bugs.

>   in a (poor) 
>   programming language (shell script) 

As latest development of OpenSSL show us, C isn't that great
programming language either, and more complex than shell.

>   with many different 
>   implementations (bash, dash, etc.). 

As long as shell in question conforms with POSIX specification, it does
not matter. And nobody forbids one to put a binary into /etc/init.d,
it'll work. Or a Perl script. It's just a convention that everyone put
shell scripts there.

>   The scrips are not even enough, 
>   they have to rely on additional tools like start-stop-daemon(8) with 
>   their own quirks and bugs.

That's the intended usage of shell scripts - to be a glue between
utilities. Does it surprise you?

> - each service/daemon is implemented in its own unique way, with 
>   different methods of running (quite often multiple ways, depending on 
>   start-up switches, like foreground, forking, etc.), reloading, 
>   logging, etc.

Given that said 'services' are written by different people - that's
nothing unusual. In fact, ever-growing DSL of systemd's units clearly
shows that 'one size fits all' approach constantly fail to account for
various corner cases.

> - computers have gotten quite complex themselves with removable devices, 
>   complex network connectivity, etc.

'Removable devices' could been news in 1980s. 

'Complex network connectivity' usually requires one to configure a
network interface or two, and start a bunch of helper daemons. It would
be fair argument if systemd suite contained implementations of all VPN
clients known to the man - but it does not.

> - multiple users on the same system (GNU/Linux is supposed to be a 
>   multiuser system, isn't it) with different backgrounds, level of 
>   technical understanding, expectations, etc.

Wait, wait, wait. You mean there was no multiuser systems based on
GNU/Linux before systemd invention? Or said multiuser systems were
unusable?

> It feels to me like systemd (the project) is rather *trying* to reduce 
> complexity, by providing:
> 
> - a clear and simple way (unit files) to declare what a service needs 
>   and how it should be run and a clear and simple method for the daemon 
>   to notify when it is ready to provide its service if its authors 
>   choose to implement it

By inventing its' own DSL [1] to write such unit files, therefore
moving complexity from writing a shell script to learning constantly
changing DSL.

> - mechanisms to deal with badly behaved daemons as well as provide 
>   proper isolation (e.g. cgroups, tmp files handling, etc.)

You've probably meant 'using existing kernel mechanisms to deal with…'.

> - mechanisms to deal with the complex interactions between daemons, 
>   devices, networks, etc.

Please provide an example of such interaction. And, while we're at it, a
definition of a 'network' you're using here.

> - a logging mechanism that can capture *all* output of a daemon (stdout, 
>   stderr, logging)

Which any daemon shouldn't have at all to start with. The very
definition of daemon implies it detached own stdout, stderr and stdin.
Systemd has couple of interesting tricks for starting daemons
(ptrace, clearing environment, to name a few), but logging
mechanism (aka journald) is an optional part of systemd.

> - a unified way to manage users (as in humans) and their complex ways of 
>   interacting with the computer (different privileges, local, remote, 
>   etc.)

Said unified way is unable to distinguish a user at the console from a
user who's connecting to a computer by means of x11vnc :) Does not
assign a 'seat' to the ssh-connected user. And is only good for a
typical desktop. Clearly there's much work to be done here.

[1] https://en.wikipedia.org/wiki/Domain-specific_language

Reco

-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org

Re: implicit linkage (was: Re: Effectively criticizing decisions you disagree with in Debian)