subject:"implicit linkage"

On Mon, Oct 13, 2014 at 4:18 PM, Jonathan Dowland j...@debian.org 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 zen75...@zen.co.uk 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 talking about getting Linux

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 7:34 PM, Ansgar Burchardt ans...@43-1.org 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 (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

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 j...@debian.org 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 zen75...@zen.co.uk 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

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 j...@debian.org 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 zen75...@zen.co.uk 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: Bash usage: was implicit linkage

2014-10-13 Thread Chris Bannister

On Mon, Oct 13, 2014 at 02:10:11PM +0900, Joel Rees wrote:
 
  Which is another way of saying that you want others to have already made
  the mistakes for you.
 
  No it isn't!  Ponder why most people take their car to a mechanic for
  servicing.
 
 And you snipped:

  As long as you recognize that somebody has to make the mistakes,
  and don't mind watching and learning while they do, that's not necessarily
  a bad thing, given courtesy and quid-pro-quo, of course.

Not on purpose. I didn't see it. It wasn't near that paragraph.

 Paying a mechanic is one kind of quid-pro-quo, wouldn't you say?

Don't know about you, but I don't know anyone who pays their mechanic to 
make mistakes. Au contraire in fact.

 Do I need to unpack that a bit more, talk about how testing is a
 substitute for making mistakes?

No thanks.

-- 
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/20141013135359.GC2362@tal

Re: Bash usage: was implicit linkage

On Mon, Oct 13, 2014 at 10:53 PM, Chris Bannister
cbannis...@slingshot.co.nz wrote:
On Mon, Oct 13, 2014 at 02:10:11PM +0900, Joel Rees wrote:

Which is another way of saying that you want others to have already made
the mistakes for you.

No it isn't! Ponder why most people take their car to a mechanic for
servicing.

And you snipped:

As long as you recognize that somebody has to make the mistakes,
and don't mind watching and learning while they do, that's not necessarily
a bad thing, given courtesy and quid-pro-quo, of course.

Not on purpose. I didn't see it. It wasn't near that paragraph.

Paying a mechanic is one kind of quid-pro-quo, wouldn't you say?

Don't know about you, but I don't know anyone who pays their mechanic to
make mistakes. Au contraire in fact.

Do I need to unpack that a bit more, talk about how testing is a
substitute for making mistakes?

No thanks.

And yet it is apparent that you need it unpacked for you.

Good mechanics made plenty of mistakes while learning the trade, and
learned from their mistakes. That's what schools are for, and that's
why those who learn on the job practice on junkers and their own
hot-rods before they tackle customers' cars.

Tests at school are one more opportunity to make sure that most of the
learning by mistakes is behind you when you start working on customer
equipment.

(I don't want the straight-A student right out of school as my
mechanic, or doctor. Straight-A students make their mistakes on the
job.)

--
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/CAAr43iOWKjMpdQCei65i-CuECnSXoDZyRWEnfs1Mhtz2ZZ0y=g...@mail.gmail.com

Re: implicit linkage

On Mon, Oct 13, 2014 at 10:44 PM, Chris Bannister
cbannis...@slingshot.co.nz 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 j...@debian.org 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 zen75...@zen.co.uk 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

Re: implicit linkage

2014-10-13 Thread Steve Litt

On Mon, 13 Oct 2014 08:18:57 +0100
Jonathan Dowland j...@debian.org 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 zen75...@zen.co.uk
  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: Way OT: Re. lines of code [was Re: implicit linkage]

On Mon, Oct 13, 2014 at 10:47 PM, Miles Fidelman
mfidel...@meetinghouse.net 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 j...@debian.org
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 zen75...@zen.co.uk
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: Way OT: Re. lines of code [was Re: implicit linkage]

2014-10-13 Thread Steve Litt

On Tue, 14 Oct 2014 07:37:17 +0900
Joel Rees joel.r...@gmail.com wrote:

 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.

Three words: Follow the money.

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/20141013191401.07738...@mydesq2.domain.cxm

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

2014-10-13 Thread Ansgar Burchardt

Joel Rees joel.r...@gmail.com writes:
 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.

YMMD :-D

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/87siir1rk5@deep-thought.43-1.org

Re: Bash usage: was implicit linkage

2014-10-12 Thread Martin Read


On 12/10/14 04:12, Peter Zoeller wrote:

But the nice
thing is shell scripting is simplistic easy to learn and understand.


I refer the audience to David A. Wheeler's essay[1] on how to handle 
filenames correctly in shell scripts, and to the bug report that he 
filed against POSIX.1-2008[2] on the subject. From those, I take away 
the lesson that no, shell scripting is not simplistic, easy to learn, 
and easy to understand. It just *looks* simplistic, easy to learn, and 
easy to understand, in ways that make it a horribly effective footgun.


[1] http://www.dwheeler.com/essays/filenames-in-shell.html

[2] http://austingroupbugs.net/view.php?id=248 - If the people who 
curate the standard commit these kinds of errors when writing examples 
for the standard, what hope does J. Random User have?



--
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/543a3ce7.5000...@zen.co.uk

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

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

On Sun, Oct 12, 2014 at 6:28 AM, Steve Litt sl...@troubleshooters.com 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 12

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 12 , (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 12
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

implicit linkage

2014-10-12 Thread Jonathan de Boyne Pollard


Andrei Popescu:

Why should I write a script? I'm not a programmer.
I can write a (simple) shellscript, but I wouldn't dare write an
initscript or even a daemontools runscript.


You have an incorrect mental model of the relative difficulty of the 
tasks.  A run program for a daemontools-family service is a handful of 
lines of script, often a one-liner.  And many shell constructs are 
simply unnecessary, to the point that people sometimes don't even write 
these scripts with a shell as the interpreter at all, using one of the 
several simpler script interpreters available instead (such as 
execline).  (And there's nothing saying that run programs even have to 
be interpreted scripts at all.)  Gerrit Pape has collected a few run 
scripts over the years, and one can see what a typical run script looks 
like.  The one for squid is at 
http://smarden.org/runit/runscripts.html#squid for example.  Wayne 
Marshall also made an annotated collection about 10 years ago, which can 
be seen at http://thedjbway.b0llix.net/services.html .  An /etc/init.d/ 
script, on the other hand, is lots of shell in comparison and by far the 
more difficult of the twain to write.


The irony is that your stated ability to write a simple shell script is 
in fact enough to be able to write a run script for a daemontools-family 
service.


Andrei Popescu:

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?).


The service scanner directory used by the daemontools-run package in 
Debian Linux is /etc/service/, which is not a top-level directory by 
anyone's measure.  You actually have a Debian package with the 
Debianisms already built in for you.  You'd have done much better to 
have started with it.



--
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/543a5530.2010...@ntlworld.com

implicit linkage

2014-10-12 Thread Jonathan de Boyne Pollard


Andrei Popescu:

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 [...]


And here's how one can do it with the nosh package 
(http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html).


I took a template service unit for imapfilter from the WWW and tweaked 
it a little bit:


root /var/sv #cat imapfilter@.service
[Unit]
Description=%p daemon service for %I

[Service]
Type=simple
ExecStart=%p -c /home/%I/.%p/config.lua
Restart=always
User=%I

[Install]
WantedBy=workstation.target
root /var/sv #

The nosh package's native service configuration is of course the service 
bundle, a compatible superset of the daemontools-family service/ and 
supervise/ directories; and the package has a tool for converting 
systemd service, socket, and target units (within some fairly broad 
limits, as explained in depth in the chapter on converting systemd units 
in the nosh Guide).  So I ran it, instatiating the template:


root /var/sv #system-control convert-systemd-units 
./imapfilter@popescu.service

root /var/sv #

It produced an entire service bundle.  Since you've been talking about 
how, supposedly, hard run scripts are to write, the interesting part is 
the auto-generated run script that the import tool produced.  Even this 
isn't particularly complex:


root /var/sv #cat imapfilter@popescu/service/run
#!/bin/nosh
#Run file generated from ./imapfilter@.service
#imapfilter daemon service for popescu
chdir /
setuidgid popescu
imapfilter -c /home/popescu/.imapfilter/config.lua
root /var/sv #

It uses one of those minimum-functionality script interpreters that I 
mentioned before.  One could of course write a similarly short shell 
script by hand:


root /var/sv #cat imapfilter@popescu/service/run.sh
#!/bin/sh -e
exec setuidgid popescu imapfilter -c 
/home/popescu/.imapfilter/config.lua

root /var/sv #

But I'm illustrating starting from a systemd unit here, and letting the 
import tool write the scripts.


For kicks, I decided to log the output of this service to a dedicated 
logging service.  I started with the cyclog@.service template that comes 
in the nosh source archive and instantiated it with the same systemd 
unit import tool as before:


root /var/sv #system-control convert-systemd-units 
./cyclog@imapfilter@popescu.service

root /var/sv #

This made me another service bundle.  Again, the interesting part for 
this discussion is the run script that the import tool made:


root /var/sv #cat cyclog@imapfilter@popescu/service/run
#!/bin/nosh
#Run file generated from ./cyclog@.service
#Standard format cyclog logging service for imapfilter@popescu
chdir /var/log/sv/
setuidgid imapfilter@popescu-log
cyclog imapfilter@popescu/
root /var/sv #

Setting up /var/log/sv/imapfilter@popescu and its dedicated logging user 
(or editing the run script to use, say, popescu as the logging user) 
is a simple exercise in making a directory and adding a user to the 
system's user database (and editing a script file), of course.  I could 
have made one big logging service for /var/log/sv/popescu instead:


root /var/sv #system-control convert-systemd-units 
./cyclog@popescu.service

root /var/sv #

This is because I can plumb main services to log services however I 
like, including many-to-one fan-in and 1:1 dedicated logging services.  
I chose the latter:


root /var/sv #ln -s ../cyclog@imapfilter@popescu imapfilter@popescu/log
root /var/sv #

The rest of the process goes beyond this discussion of how simple it is 
to write daemontools-family run scripts and is an exercise in enabling 
the two services and starting them:


root /var/sv #systemctl enable imapfilter@popescu.service 
cyclog@imapfilter@popescu.service
root /var/sv #systemctl start imapfilter@popescu.service 
cyclog@imapfilter@popescu.service

root /var/sv #

Were this machine running the daemontools compatibility old-style 
service scanner, enabling the two services and starting them would have 
been:


root /var/sv #ln -s /var/sv/imapfilter@popescu/ /var/service/
root /var/sv #

But this machine is running the nosh package's system manager, has the 
standard targets system in place, and is always starting things with 
system-control (a.k.a. systemctl).  It was the same machine as used at 
http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh-example.html 
in fact (which will come as a surprise to those who remember that we're 
starting from a systemd unit file here).



--
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/543a5658.9040...@ntlworld.com

implicit linkage

2014-10-12 Thread Jonathan de Boyne Pollard

Steve Litt:

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

Joel Rees:

You can go a little further. man envuidgid, man envdir, and man
setuidgid for the remaining clues. The Debian daemontools package has manual pages, derived from the
original WWW pages.

* http://untroubled.org/daemontools-encore/envuidgid.8.html
* http://cr.yp.to/daemontools/envuidgid.html
* http://untroubled.org/daemontools-encore/envdir.8.html
* http://cr.yp.to/daemontools/envdir.html
* http://untroubled.org/daemontools-encore/setuidgid.8.html
* http://cr.yp.to/daemontools/setuidgid.html

Both s6 and nosh have manual pages for these commands in the package, too.

* http://skarnet.org/software/s6/s6-envuidgid.html
* http://skarnet.org/software/s6/s6-envdir.html
* http://skarnet.org/software/s6/s6-setuidgid.html

You'll notice that whilst experimenting, M. Litt has ended up with a script
that has an unnecessary command in it. (-:

* http://thedjbway.b0llix.net/daemontools/uidgid.html

--
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/543a5f39.6090...@ntlworld.com

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

On Du, 12 oct 14, 01:41:34, Reco wrote:
  Hi.
 
 On Sat, 11 Oct 2014 23:02:01 +0300
 Andrei POPESCU andreimpope...@gmail.com wrote:
 
  On Sb, 11 oct 14, 23:20:34, Reco wrote:
   On Sat, 11 Oct 2014 20:47:36 +0300
   Andrei POPESCU andreimpope...@gmail.com 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

On Sb, 11 oct 14, 17:41:28, Steve Litt wrote:
 On Sat, 11 Oct 2014 22:28:31 +0300
 Andrei POPESCU andreimpope...@gmail.com 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: Bash usage: was implicit linkage

On Sb, 11 oct 14, 21:40:49, Steve Litt wrote:
 
 From my viewpoint, shellscripts were never intended to be big, huge
 programs. To me, they just glue together commands, and have a few
 rudimentary branching and looping constructs.

Isn't that like buying IKEA furniture, but when you get home you realise 
all those little plastic bags with screws and mounting pieces are 
missing? I will say this:

Any program that requires additional scripting just to get it 
running is insufficiently advanced.

(you can quote me on that)

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: Bash usage: was implicit linkage

2014-10-12 Thread The Wanderer

On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote:

 On Sb, 11 oct 14, 21:40:49, Steve Litt wrote:
 
 From my viewpoint, shellscripts were never intended to be big,
 huge programs. To me, they just glue together commands, and have a
 few rudimentary branching and looping constructs.
 
 Isn't that like buying IKEA furniture, but when you get home you
 realise all those little plastic bags with screws and mounting pieces
 are missing? I will say this:

Except that

A: different glue (screws and mounting pieces) may be required for
different environments where you would use the furniture;

B: there's no practical way to predict all possible environments where
someone might want to use it, or to provide the necessary glue for all
of those unpredicted environments;

C: there's a lot more room for individual flexibility in shell scripts,
et cetera, than there is in furniture assembly hardware; and

D: in many / most cases, the glue is already provided for you (either
by upstream or by some middleman) by the time the furniture reaches
you to begin with.


In addition, I understood the comment you're responding to as being
about shell scripts as an overall idea, rather than about their usage in
any particular context. It's entirely possible for the needed scripts to
have been written by upstream, just as it would be possible for logic in
other languages to have been written by upstream.

All that comment seems to say is that shell scripts are specifically
intended as the glue to let you stick together existing components *in
whatever way you happen to want*, as opposed to being intended as a
building block for contructing such components. If you don't need to
stick the components together because they're fine on their own (e.g.,
grep is useful without any shell constructs), that's OK; if you want to
stick the components together using something else, that's fine too; but
if you want to stick them together, shell scripts are one tool you have
with which to do so.

 Any program that requires additional scripting just to get it running
 is insufficiently advanced.
 
 (you can quote me on that)

Part of the tradeoff for power is responsibility - both in the
responsibility to use the power wisely, and in the responsibility to do
things yourself rather than have others do them for you.

If you don't want the responsibility of writing shell scripts (or other
scripting), you will have to accept not having the power to do some of
the things you could do with such scripts.

If you don't want that power either, that's fine for you - but others
may not feel the same way.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: implicit linkage

2014-10-12 Thread lee

Reco recovery...@gmail.com 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 lee

Reco recovery...@gmail.com 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

Steve Litt sl...@troubleshooters.com 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 Martin Read


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

Reco recovery...@gmail.com 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

On Sun, 12 Oct 2014 03:05:59 +0200
lee l...@yagibdah.de wrote:

 Steve Litt sl...@troubleshooters.com 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 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: Bash usage: was implicit linkage

On Du, 12 oct 14, 10:30:52, The Wanderer wrote:
 On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote:
 
  Any program that requires additional scripting just to get it running
  is insufficiently advanced.
  
  (you can quote me on that)
 
 Part of the tradeoff for power is responsibility - both in the
 responsibility to use the power wisely, and in the responsibility to do
 things yourself rather than have others do them for you.
 
But I'm also aware of the limits of my powers and don't try to do too 
much, but instead use the right tool.

 If you don't want the responsibility of writing shell scripts (or other
 scripting), you will have to accept not having the power to do some of
 the things you could do with such scripts.
 
As well as avoid some of the mistakes I would (most probably) do.

 If you don't want that power either, that's fine for you - but others
 may not feel the same way.

And I'm fine with that. It's just that others seem to think that simply 
because Debian is using a specific tool by default it will suddenly 
discard the alternatives.

This is not how Debian works.

As long as there will be people available to do the work in maintaining 
the alternatives they will have their place in Debian, just like 
file-rc, runit, etc.

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: Bash usage: was implicit linkage

On Sun, 12 Oct 2014 09:33:43 +0100
Martin Read zen75...@zen.co.uk wrote:

 On 12/10/14 04:12, Peter Zoeller wrote:
  But the nice
  thing is shell scripting is simplistic easy to learn and understand.
 
 I refer the audience to David A. Wheeler's essay[1] on how to handle 
 filenames correctly in shell scripts, and to the bug report that he 
 filed against POSIX.1-2008[2] on the subject. From those, I take away 
 the lesson that no, shell scripting is not simplistic, easy to learn, 
 and easy to understand. It just *looks* simplistic, easy to learn,
 and easy to understand, in ways that make it a horribly effective
 footgun.
 
 [1] http://www.dwheeler.com/essays/filenames-in-shell.html

Martin,

Thanks so much for the preceding resource. It's worth its weight in
gold, and I've bookmarked it for quick retrieval.

This essay practically screams out for somebody to write a C program
that takes an argument of an arbitrary string, finds all files in a
directory, and returns a long string with those files separated by the
arbitrary string. A shellscript can then use mktemp or some other
facility to make that arbitrary string, pass it to the C program, and
then use the temporary string as a sure fire field separator. The C
program could also take an option as to whether or not should find
hidden files, and it could prepend ./ onto all relative paths not
already beginning with ./. I might do that tonight.

Thanks for this great info. I wish I'd had it a decade ago.

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/20141012134204.37901...@mydesq2.domain.cxm

Re: Bash usage: was implicit linkage

2014-10-12 Thread The Wanderer

On 10/12/2014 at 01:42 PM, Steve Litt wrote:

 On Sun, 12 Oct 2014 09:33:43 +0100 Martin Read zen75...@zen.co.uk
 wrote:
 
 On 12/10/14 04:12, Peter Zoeller wrote:
 
 But the nice thing is shell scripting is simplistic easy to learn
 and understand.
 
 I refer the audience to David A. Wheeler's essay[1] on how to
 handle filenames correctly in shell scripts, and to the bug report
 that he filed against POSIX.1-2008[2] on the subject. From those, I
 take away the lesson that no, shell scripting is not simplistic,
 easy to learn, and easy to understand. It just *looks* simplistic,
 easy to learn, and easy to understand, in ways that make it a
 horribly effective footgun.
 
 [1] http://www.dwheeler.com/essays/filenames-in-shell.html
 
 Martin,
 
 Thanks so much for the preceding resource. It's worth its weight in
 gold, and I've bookmarked it for quick retrieval.
 
 This essay practically screams out for somebody to write a C program
 that takes an argument of an arbitrary string, finds all files in a
 directory, and returns a long string with those files separated by
 the arbitrary string.

How would you handle the case where the arbitrary string appears in one
or more of the filenames?

The usual approach is by escaping, which is easy enough with a single
character, but offhand I don't see any potentially robust way to do
escaping of an arbitrary string in such a way that the result would be
necessarily clear to the calling shell script. At the very least you'd
probably need an escape syntax complicated enough to obviate most of the
advantages of not needing to handle filename parsing directly in
shell code...

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

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 (was: Re: Effectively criticizing decisions you disagree with in Debian)

On Sun, 12 Oct 2014 19:06:11 +0900
Joel Rees joel.r...@gmail.com 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
 sl...@troubleshooters.com 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: Bash usage: was implicit linkage

2014-10-12 Thread Don Armstrong

On Sun, 12 Oct 2014, Steve Litt wrote:
 This essay practically screams out for somebody to write a C program
 that takes an argument of an arbitrary string, finds all files in a
 directory, and returns a long string with those files separated by the
 arbitrary string.

You seem to be looking for find -print0; \0 is one of the few characters
which is not valid to have in a file name.

It's not like it's that hard to do this properly in a policy compliant
POSIX shell, either. Use IFS and reset it as appropriate, or properly
quote things. 

-- 
Don Armstrong  http://www.donarmstrong.com

Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
 -- Antoine de Saint-Exupe'ry, Terres des Hommes


-- 
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/20141012181654.gx23...@teltox.donarmstrong.com

Re: Bash usage: was implicit linkage

2014-10-12 Thread Miles Fidelman


Andrei POPESCU wrote:

On Sb, 11 oct 14, 21:40:49, Steve Litt wrote:

 From my viewpoint, shellscripts were never intended to be big, huge
programs. To me, they just glue together commands, and have a few
rudimentary branching and looping constructs.

Isn't that like buying IKEA furniture, but when you get home you realise
all those little plastic bags with screws and mounting pieces are
missing? I will say this:

 Any program that requires additional scripting just to get it
 running is insufficiently advanced.

 (you can quote me on that)




Maybe if you're in a desktop environment.  If you're managing servers 
and services, one tends to wire together multiple services, often in 
environment-specific ways - and it's very common to write glue scripts.


Seems to me that a big part of the issue is increasing use of Debian 
(and Linux in general) on the desktop.  It seems like desktop support is 
driving more and more design decisions.


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/543ac7c6.4090...@meetinghouse.net

Re: implicit linkage

On Sun, 12 Oct 2014 15:33:48 +0300
Andrei POPESCU andreimpope...@gmail.com wrote:

 On Sb, 11 oct 14, 17:41:28, Steve Litt wrote:
  On Sat, 11 Oct 2014 22:28:31 +0300
  Andrei POPESCU andreimpope...@gmail.com 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: Bash usage: was implicit linkage

On Sun, 12 Oct 2014 17:07:01 +0300
Andrei POPESCU andreimpope...@gmail.com wrote:

 On Sb, 11 oct 14, 21:40:49, Steve Litt wrote:
  
  From my viewpoint, shellscripts were never intended to be big, huge
  programs. To me, they just glue together commands, and have a few
  rudimentary branching and looping constructs.
 
 Isn't that like buying IKEA furniture, 

Exactly!

 but when you get home you
 realise all those little plastic bags with screws and mounting pieces
 are missing? 

Not similar, becase either the parts are there, or they're creatable
with a few very basic tools (much easier to create files than screws).

 I will say this:
 
 Any program that requires additional scripting just to get it 
 running is insufficiently advanced.
 
 (you can quote me on that)


I can't argue with the preceding, because it's a belief, no more or
less valid than my (very contradictory) belief. The best I could do is
create a run script making program that asks you a few questions and
writes the script for you. Which, if it would bring more people into
the daemontools fold, isn't a half bad idea.

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/20141012143419.10361...@mydesq2.domain.cxm

Re: Bash usage: was implicit linkage

2014-10-12 Thread Ansgar Burchardt

Don Armstrong d...@debian.org writes:
 On Sun, 12 Oct 2014, Steve Litt wrote:
 This essay practically screams out for somebody to write a C program
 that takes an argument of an arbitrary string, finds all files in a
 directory, and returns a long string with those files separated by the
 arbitrary string.

 You seem to be looking for find -print0; \0 is one of the few characters
 which is not valid to have in a file name.

Sadly POSIX has no -print0 for find[1]. So if you are for some reason
limited to POSIX, there is no nice solution.

 It's not like it's that hard to do this properly in a policy compliant
 POSIX shell, either. Use IFS and reset it as appropriate, or properly
 quote things. 

It's possible, but prone to errors.

Ansgar

  [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html


-- 
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/85oatht9ci@tsukuyomi.43-1.org

Re: implicit linkage

On Sun, 12 Oct 2014 19:02:08 +0100
Martin Read zen75...@zen.co.uk 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: Bash usage: was implicit linkage

On Sun, 12 Oct 2014 11:16:54 -0700
Don Armstrong d...@debian.org wrote:

 On Sun, 12 Oct 2014, Steve Litt wrote:
  This essay practically screams out for somebody to write a C program
  that takes an argument of an arbitrary string, finds all files in a
  directory, and returns a long string with those files separated by
  the arbitrary string.
 
 You seem to be looking for find -print0; \0 is one of the few
 characters which is not valid to have in a file name.

Let me think about that. I wasn't aware that \0 couldn't get into a
filename. I was concerned about the following
in /http://www.dwheeler.com/essays/filenames-in-shell.html :

=
Most shells cannot store byte 0 in a variable at all. You can’t even
pass such null-separated lists back to the shell via command
substitution; cat $(find . -print0) and similar “for” loops don’t work.
Even the POSIX standard’s version of “read” can’t use \0 as the
separator (POSIX’s read has the -r option, but not bash’s -d option).
=
 
 It's not like it's that hard to do this properly in a policy compliant
 POSIX shell, either. Use IFS and reset it as appropriate, or properly
 quote things. 

I'll try these things, before writing my own return each filename
program. Thanks.

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/20141012150633.0dc9e...@mydesq2.domain.cxm

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

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

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: Bash usage: was implicit linkage

2014/10/12 23:07 Andrei POPESCU andreimpope...@gmail.com:

 On Sb, 11 oct 14, 21:40:49, Steve Litt wrote:
 
  From my viewpoint, shellscripts were never intended to be big, huge
  programs. To me, they just glue together commands, and have a few
  rudimentary branching and looping constructs.

 Isn't that like buying IKEA furniture, but when you get home you realise
 all those little plastic bags with screws and mounting pieces are
 missing? I will say this:

 Any program that requires additional scripting just to get it
 running is insufficiently advanced.

s/advanced/customized/

Or you could talk about the difference between the jobs of distributor and
integrator, if you're completely anti-DIY.

  [...]

Although, some of us don't really care all that much for IKEA furniture.

Joel Rees

Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.

Re: Bash usage: was implicit linkage

2014/10/13 2:14 Andrei POPESCU andreimpope...@gmail.com:

 On Du, 12 oct 14, 10:30:52, The Wanderer wrote:
  On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote:
 
   Any program that requires additional scripting just to get it running
   is insufficiently advanced.
  
   (you can quote me on that)
 
  Part of the tradeoff for power is responsibility - both in the
  responsibility to use the power wisely, and in the responsibility to do
  things yourself rather than have others do them for you.

 But I'm also aware of the limits of my powers and don't try to do too
 much, but instead use the right tool.

Let's gloss over the idea that opinions on what constitutes the right
tool differ, and ignore the question of what to do when the right tool
doesn't exist.

  If you don't want the responsibility of writing shell scripts (or other
  scripting), you will have to accept not having the power to do some of
  the things you could do with such scripts.

 As well as avoid some of the mistakes I would (most probably) do.

Which is another way of saying that you want others to have already made
the mistakes for you.

As long as you recognize that somebody has to make the mistakes, and don't
mind watching and learning while they do, that's not necessarily a bad
thing, given courtesy and quid-pro-quo, of course.

 [...]

Joel Rees

Computer memory is just fancy paper,
CPUs just fancy pens.
All is a stream of text
flowing from the past into the future.

Re: Bash usage: was implicit linkage

2014/10/13 2:45 Steve Litt sl...@troubleshooters.com:

 On Sun, 12 Oct 2014 09:33:43 +0100
 Martin Read zen75...@zen.co.uk wrote:

  On 12/10/14 04:12, Peter Zoeller wrote:
   But the nice
   thing is shell scripting is simplistic easy to learn and understand.
 
  I refer the audience to David A. Wheeler's essay[1] on how to handle
  filenames correctly in shell scripts, and to the bug report that he
  filed against POSIX.1-2008[2] on the subject. From those, I take away
  the lesson that no, shell scripting is not simplistic, easy to learn,
  and easy to understand. It just *looks* simplistic, easy to learn,
  and easy to understand, in ways that make it a horribly effective
  footgun.
 
  [1] http://www.dwheeler.com/essays/filenames-in-shell.html

 Martin,

 Thanks so much for the preceding resource. It's worth its weight in
 gold, and I've bookmarked it for quick retrieval.

mutter mutter  ... cleaning input ...  tool ... quick hack belt ...
generalized tool box mutter mutter

 This essay practically screams out for somebody to write a C program
 that takes an argument of an arbitrary string, finds all files in a
 directory, and returns a long string with those files separated by the
 arbitrary string. A shellscript can then use mktemp or some other
 facility to make that arbitrary string, pass it to the C program, and
 then use the temporary string as a sure fire field separator. The C
 program could also take an option as to whether or not should find
 hidden files, and it could prepend ./ onto all relative paths not
 already beginning with ./. I might do that tonight.

mutter mutter ... RE ... glob ... sed - awk wars ... perl ... python - ruby
... mutter mutter erk

cough cough

man xargs

mutter mutter

Re: implicit linkage

On Mon, Oct 13, 2014 at 1:39 AM, Martin Read zen75...@zen.co.uk wrote:
 On 12/10/14 01:43, lee wrote:

 Reco recovery...@gmail.com 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: Bash usage: was implicit linkage

2014-10-12 Thread Chris Bannister

On Mon, Oct 13, 2014 at 07:53:03AM +0900, Joel Rees wrote:
 2014/10/13 2:14 Andrei POPESCU andreimpope...@gmail.com:
 
  On Du, 12 oct 14, 10:30:52, The Wanderer wrote:
   On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote:
  
Any program that requires additional scripting just to get it running
is insufficiently advanced.
   
(you can quote me on that)
  
   Part of the tradeoff for power is responsibility - both in the
   responsibility to use the power wisely, and in the responsibility to do
   things yourself rather than have others do them for you.
 
  But I'm also aware of the limits of my powers and don't try to do too
  much, but instead use the right tool.
 
 Let's gloss over the idea that opinions on what constitutes the right
 tool differ, and ignore the question of what to do when the right tool
 doesn't exist.
 
   If you don't want the responsibility of writing shell scripts (or other
   scripting), you will have to accept not having the power to do some of
   the things you could do with such scripts.
 
  As well as avoid some of the mistakes I would (most probably) do.
 
 Which is another way of saying that you want others to have already made
 the mistakes for you.

No it isn't!  Ponder why most people take their car to a mechanic for
servicing.

-- 
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/20141013043828.GJ22545@tal

Re: Bash usage: was implicit linkage

On Mon, Oct 13, 2014 at 1:38 PM, Chris Bannister
cbannis...@slingshot.co.nz wrote:
On Mon, Oct 13, 2014 at 07:53:03AM +0900, Joel Rees wrote:
2014/10/13 2:14 Andrei POPESCU andreimpope...@gmail.com:

On Du, 12 oct 14, 10:30:52, The Wanderer wrote:
On 10/12/2014 at 10:07 AM, Andrei POPESCU wrote:

Any program that requires additional scripting just to get it running
is insufficiently advanced.

(you can quote me on that)

Part of the tradeoff for power is responsibility - both in the
responsibility to use the power wisely, and in the responsibility to do
things yourself rather than have others do them for you.

But I'm also aware of the limits of my powers and don't try to do too
much, but instead use the right tool.

Let's gloss over the idea that opinions on what constitutes the right
tool differ, and ignore the question of what to do when the right tool
doesn't exist.

If you don't want the responsibility of writing shell scripts (or other
scripting), you will have to accept not having the power to do some of
the things you could do with such scripts.

As well as avoid some of the mistakes I would (most probably) do.

Which is another way of saying that you want others to have already made
the mistakes for you.

No it isn't! Ponder why most people take their car to a mechanic for
servicing.

And you snipped:

As long as you recognize that somebody has to make the mistakes,
and don't mind watching and learning while they do, that's not necessarily
a bad thing, given courtesy and quid-pro-quo, of course.

Paying a mechanic is one kind of quid-pro-quo, wouldn't you say?

Paying money to buy the car is another form of quid-pro-quo, as well, I'd say.

Do I need to unpack that a bit more, talk about how testing is a
substitute for making mistakes?

--
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

--
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/caar43io+hd6vbnnjmvetz-nnt9ernukfb6fdrkdqqz3fvrq...@mail.gmail.com

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

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
  
- 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.
  
- 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.
  
- 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.)

- etc.

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.

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.

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

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.

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 15:18:58 +0300
Andrei POPESCU andreimpope...@gmail.com 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 
with a subject of

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

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 (was: Re: Effectively criticizing decisions you disagree with in Debian)

On Sat, 11 Oct 2014 15:18:58 +0300
Andrei POPESCU andreimpope...@gmail.com 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
 never adopted on a large scale or eventually

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 andreimpope...@gmail.com 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 clear and simple method for the daemon 
to notify when it is ready to provide its service if its

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 my user # 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

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)

 Hi.
 
On Sat, 11 Oct 2014 20:47:36 +0300
Andrei POPESCU andreimpope...@gmail.com wrote:

 On Sb, 11 oct 14, 19:57:42, Reco wrote:
  On Sat, 11 Oct 2014 15:18:58 +0300
  Andrei POPESCU andreimpope...@gmail.com 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 complex themselves with removable devices, 
 complex network connectivity, etc.
  
  'Removable devices' could

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)

On Sb, 11 oct 14, 23:20:34, Reco wrote:
 On Sat, 11 Oct 2014 20:47:36 +0300
 Andrei POPESCU andreimpope...@gmail.com 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 (was: Re: Effectively criticizing decisions you disagree with in Debian)

On Sat, 11 Oct 2014 21:21:14 +0300
Andrei POPESCU andreimpope...@gmail.com 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 12
while ! ping -q -c1 $pingaddr  /dev/null; do
  sleep 1
  echo littcrond REchecking network 12
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 Sat, 11 Oct 2014 23:20:34 +0400
Reco recovery...@gmail.com wrote:

  Hi.
  
 On Sat, 11 Oct 2014 20:47:36 +0300
 Andrei POPESCU andreimpope...@gmail.com 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)

 Hi.

On Sat, 11 Oct 2014 23:02:01 +0300
Andrei POPESCU andreimpope...@gmail.com wrote:

 On Sb, 11 oct 14, 23:20:34, Reco wrote:
  On Sat, 11 Oct 2014 20:47:36 +0300
  Andrei POPESCU andreimpope...@gmail.com 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 way you like it.


  As for the x11vnc - I doubt that it could be

Re: implicit linkage

On Sat, 11 Oct 2014 22:28:31 +0300
Andrei POPESCU andreimpope...@gmail.com 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 17:35:00 -0400
Steve Litt sl...@troubleshooters.com wrote:

 On Sat, 11 Oct 2014 23:20:34 +0400
 Reco recovery...@gmail.com wrote:
 
   Hi.
   
  On Sat, 11 Oct 2014 20:47:36 +0300
  Andrei POPESCU andreimpope...@gmail.com 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

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 andreimpope...@gmail.com 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 12
 while ! ping -q -c1 $pingaddr  /dev/null; do
sleep 1
echo littcrond REchecking network 12
 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

Bash usage: was implicit linkage