from:"joel"

On Sun, Oct 5, 2014 at 9:31 PM, Chris Bannister
 wrote:
> On Sun, Oct 05, 2014 at 09:51:54PM +1100, Charlie wrote:
>>
>> As I thought.
>> Downloaded on a very fast cable connection and burnt the CD on media
>> which has never had any problems on a modern laptop etc., etc..
>>
>> Probably, but not certain that I did the checksum confirmation.

Sorry, I mis-read that. Thought you had downloaded the netinstall
image on the slow connection.

>> I thought it was just a glitch because I can't recall anyone ever
>> having a problem just like that, but I may not have read that thread.

Well, thinking a little harder, it had been some time since the
netinstall image was downloaded, so the kernel in the netinstall image
was, indeed, not likely to be matching the non-kernel stuff it was
finding in the current repositories. If the mismatch were bad enough,
it might make sense for the installer to complain.

Otherwise, it would need to ask if you wanted to re-load the kernel
and other elements of the netinstall image from the web instead of
proceeding with the stuff from the CD, or whether you had a substitute
repository that matched the kernel it was using for the install.

>> Thanks for your time to reply.

If it helps more than hinders, you're welcome.

> If you think you have found a problem, then as a user of testing you
> should report it. You may have found an obscure bug which should be
> fixed *before* Jessie becomes the new stable.
>
> As users of testing, we should take a more active role with regards to
> bugs, after all one of the reasons to run testing is to help make the
> stable release as bug free as possible.

Chris, I'm not understanding your reasoning here.

Are you thinking he should be considering the possibility he's been
hit by a MITM or something? Do you want him to try to roll back the
testing repository or a mirror so he can do a full binary compare?

-- 
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/CAAr43iPM5z0e5eM6W7wcV9kRx_L5Cd-CSbhytjHmueL=x2c...@mail.gmail.com

sock puppets (Re: (Song) ** SystemD)

On Sun, Oct 5, 2014 at 7:54 PM, Chuck Ebbert  wrote:
> On Sun, 5 Oct 2014 10:29:24 +
> Gregory Smith  wrote:
> [...]

Chuck, Al, anyone else paying attention to "Gregory" or "Tom Collins"
or whatever he's calling himself -- I'll repeat what I posted to
debian-user, but this is quite apparently a sockpuppet, either
engaging in recreational trolling, or trying very hard to make it
impossible to discuss systemd with any semblance of rationally.

It seems to be hard enough for the more avid of both the proponents
and opponents to be rational as it is, let's try not to get sucked
into this kind of baiting. (Speaking as one who got a little bit
sucked into it last week or so.)

-- 
Joel Rees

Computer storage is just fancy paper, the CPUs just fancy pens;
all is text, streaming forever from the past into the future.

-- 
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/caar43imnonrlamgergaxgazo-dvppmefusk5rhjnqxz1-6x...@mail.gmail.com

Re: Jessie netinstall CD on very limited internet connection.......

2014/10/06 10:44 "Chris Bannister" :
>
> On Sun, Oct 05, 2014 at 10:34:57PM +0900, Joel Rees wrote:
> >
> > > If you think you have found a problem, then as a user of testing you
> > > should report it. You may have found an obscure bug which should be
> > > fixed *before* Jessie becomes the new stable.
> > >
> > > As users of testing, we should take a more active role with regards to
> > > bugs, after all one of the reasons to run testing is to help make the
> > > stable release as bug free as possible.
> >
> > Chris, I'm not understanding your reasoning here.
>
> How do you think bugs get fixed if they're not reported?
> What else can you read into the above paragraphs?
>
> > Are you thinking he should be considering the possibility he's been
> > hit by a MITM or something? Do you want him to try to roll back the
> > testing repository or a mirror so he can do a full binary compare?
>
> *WHAT*? I was thinking nothing of the sort. I'm not the person
> responsible for producing the netinst image, but if I was that would be
> the last thing I'd be thinking --- more likely just a silly mistake BUT
> how would I get to hear about it if whomever found the mistake didn't
> let me know, *Hrrrmmm*?

Okay, looking at the OP's descriptions of the problems, should we ask the
OP to go ask the release team whether an old netinstall image for testing
should, in general, be able to recover from having the kernel on the CD out
of sync with the current repository? And would they like him to image the
old netinstall CD and upload it somewhere for analysis? Or would they like
him to try to replay the install, maybe from a mirror where they can watch?

I don't know how slow the friend's connection is, but unless there were
some specific bug I were chasing, I'd hesitate to ask for a replay if it's
going to take two of them a good part of a day, and erasing a working
system. Especially considering that my record on installs leaves me with
about one in five install CDs botched for various reasons.

Joel Rees

Re: Jessie netinstall CD on very limited internet connection.......

2014/10/06 12:47 "Chris Bannister" :
>
> [...]
> Jessie is a moving target, I personally would download the wheezy
> netinst image and install that. Why does the OP need Jessie which is
> uodated constantly when only a limited bandwidth is available?

I have to admit, I was wondering that myself, but since he seemed to
understand what he was doing in upgrading from wheezy, I assumed he'd
understand that Jessie would likely have issues requiring a bit of patience
and nursing on a slow connection.

Charlie, care to enlighten us?

Joel Rees

Re: [exim4] mixed up about terminology

2014-10-06 Thread Joel Rees

2014/10/06 12:16 "Harry Putnam" :
>
> Jerry Stuckle  writes:
>
> > The first question - why do you think you need to relay to other
> > networks, even if they're your own?  Do you have other SMTP servers
> > running on those networks?
>
> Good question and apparently thee is no reason.  It stemmed from a deep
> seated confusion about what relaying means.  All I really want is to
> be able to do this:
>
> On my lan machines:
>
> HOST-1
> HOST-2
> [...]
> HOST-mail-server now being configured
>
> HOST-[12...N] would have the server host above listed as smarthost in
> there respective mail config.
>
> So they would all be sending mail by way of server host.
>
> I guess that is not what is meant by relaying?

I think that's relaying, but not open relay (if you get it set up right).

But you should consider why you want to send out through a central server,
unless your firewall is for some reason set up to only allow outbound mail
from that server, in which case you probably do want to authenticate on the
lan, too. (Think, for example, about the possibility of malware on a local
box.)

Incoming mail may make sense to cache on a local server. Or maybe not.

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: Jessie netinstall CD on very limited internet connection.......

2014-10-06 Thread Joel Rees

2014/10/06 15:13 "Charlie" :
>
> On Mon, 6 Oct 2014 13:30:32 +0900 Joel Rees sent:
>
> 
>
> > Charlie, care to enlighten us?
>
> Thanks for your time with this.
>
> Joel I think you're right. I just didn't understand the way that the
> netinstall CD's work. The disk or rather the installer was too old.

Maybe.

The question being whether it's worth replaying an install to be sure that
was the only problem. If you'd had such a problem with the wheezy
installer, the devs would probably like to at least know about it. And you
might want to check with the guys who make the CD images about this one, if
you don't mind looking for the right mailing list to post to. A casual
check of

   lists.debian.org

would suggest the debian-cd , as Chris (I think it was) suggested.

>[description of what sounds like reasonably reasonable practice]

Keep up the good work, but if you think you've hit a real bug, don't think
you don't know enough to file a bug. Look for similar bugs first, ask on
the list if you want, but you know enough by now and filing bugs is part of
how users support the development effort.

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: Moderated posts?

2014-10-06 Thread Joel Rees

As Don pointed out, it's the threads that have been clipped, as it were,
not the topics: I think it's probably just as well, as those threads
themselves were started by either a sockpuppet or someone who had lost
control of himself, and the threads were counterproductive.

So I can say, "systemd!" here,

And this post will still not be blocked.

Joel Rees
On lkml, they block html.

Re: Moderated posts?

2014-10-07 Thread Joel Rees

On Tue, Oct 7, 2014 at 10:28 PM, The Wanderer  wrote:
> On 10/07/2014 at 02:58 AM, Joel Rees wrote:
>
>> As Don pointed out, it's the threads that have been clipped, as it
>> were, not the topics: I think it's probably just as well, as those
>> threads themselves were started by either a sockpuppet or someone who
>> had lost control of himself, and the threads were counterproductive.
>>
>> So I can say, "systemd!" here,
>>
>> And this post will still not be blocked.
>
> And that's fair enough in its way. (Though it does unfairly also hit
> subthreads which were not on the same topic anymore, but I can see where
> trying to be fine-grained enough to comb out one but not the other might
> well be more trouble than it would be worth.)
>
> But it should still be accompanied by a public announcement that such
> action is being taken, with at least a vague indication of which
> thread(s) are being so filtered - and/or a system of automated replies
> (possibly rate-limited to stymie DoS efforts) to any attempt to reply to
> such a thread, explaining the situation.
>
> Doing such moderation silently, without comment or explanation, is just
> not cricket.
>
>> Joel Rees
>> On lkml, they block html.
>
> But do they do it silently, or is there an explanation of why an
> attempted post containing such will not be posted?
>
> If the latter, I think I might actually approve of such a policy...

Well, all you get is a generic RFC compliant message from your ISP
saying it was rejected, but not really specifically why.

IIRC, the FAQ is referenced in the rejection message, so you at least
have a clue to go read the FAQ, where, if you read as far as the
mailing list guidelines, you see that it says the list is pretty much
open if you don't post in html, and html messages are automatically
rejected.

-- 
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/CAAr43iOJvKUeO7hjowUSTtOcZ=ujoehzxet82rw3j5mi_tx...@mail.gmail.com

Re: Moderated posts?

2014-10-07 Thread Joel Rees

2014/10/08 6:07 "Andrei POPESCU" :
>
> On Ma, 07 oct 14, 12:00:57, Steve Litt wrote:
> >
> >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
> >
> > Read ^H^H^H^H skim the thread. Notice how, in the first 10 posts, after
> > insisting that alternate inits be part of the discussion, a guy named
> > Thorsten Glaser was ordered not to bring up alternate inits in the
>
> That doesn't match my memory of the entire debate, care to refresh my
> memory with a reference?

Well, I'll tell you, Andrei. I was raised on the idea that KISS is never an
optional principle in engineering, and more especially to be strictly
observed when working with anything that has to respond to real-world
events in some pre-determined amount of time.

Perhaps that point of view colors my interpretation of the conversation in
a way different from the way you read or watched it.

> > thread again. Again and again, the conversation is steered into the
> > most limiting set of alternatives, often trampling on those who say
> > "wait a minute, let's consider other things."
>
> As far as I recall OpenRC was indeed deemed unsuitable quite early, but
> this was done on technical grounds (not ready, lack of documentation,
> lack of features, etc.).

Lack of documentation is one kind of technical ground, I suppose, but it is
a completely different topic from deterministic execution paths.

Lack of features is not a defect in a pid 1 process. If the traditional
sysv inherited inits have issues, pid 1 being too simple is not one of the
problems.

A good engineer can read code. No amount of engineering magic can read the
execution of a pid 1 process that is chasing its tail trying to parse an
error state. Pid 1 should never see anything more than three options to an
event -- kill, pass it on, or ignore -- and the decision chain should have
as few steps as possible, preferably less than three. Otherwise, and it
doesn't matter how many processors you have going how fast, you are going
to see the system freeze at odd times, punt at odd times, and fail to
enforce at odd times, among other issues.

And these will be the quiet kind of errors where data gets corrupted and is
lost and no one is aware of the corruption until months later, when you
really need the data but there is no way to go back and re-build it. Months
and data corruption if you're lucky, backdoors never discovered if you
aren't.

All the fuss about race conditions, all the fuss about logging, the steady
absorption of daemons, like cron, that should be separate, etc., all of
these are not features. They are symptoms of the failure to keep it simple
and avoid trying to make it too smart.

If openrc was not ready because of documentation, how can systemd ever be
considered ready until pid 1 is stripped down to the bare minimum? Greater
than 1M is two orders of magnitude beyond too big.

Does that help you see what Steve and others interpret as railroading?

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: Moderated posts?

2014-10-08 Thread Joel Rees

On Wed, Oct 8, 2014 at 6:16 PM, Andrei POPESCU  wrote:
> On Mi, 08 oct 14, 11:41:05, Joel Rees wrote:
>> 2014/10/08 6:07 "Andrei POPESCU" :
>> >
>> > On Ma, 07 oct 14, 12:00:57, Steve Litt wrote:
>> > >
>> > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708
>> > >
>> > > Read ^H^H^H^H skim the thread. Notice how, in the first 10 posts,

(I'm wondering whether that's the first ten, or the first ten
currently visible.)

>> > > after
>> > > insisting that alternate inits be part of the discussion, a guy named
>> > > Thorsten Glaser was ordered not to bring up alternate inits in the
>> >
>> > That doesn't match my memory of the entire debate, care to refresh my
>> > memory with a reference?
>>
>> Well, I'll tell you, Andrei. I was raised on the idea that KISS is never an
>> optional principle in engineering, and more especially to be strictly
>> observed when working with anything that has to respond to real-world
>> events in some pre-determined amount of time.
>> [...(background information that I thought might be helpful, with the 
>> following quetsion)...]
>> Does that help you see what Steve and others interpret as railroading?

... which  you also snipped, but then replied:

> I was specifically asking about a reference for "Thorsten Glaser was
> ordered not to bring up alternate inits...".

So, I assume it did not help you see.

I think what Steve is talking about may have occurred between

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#20

and

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#30

but right now I'm only seeing every fifth message, so it's hard to tell.

#30 does quote something worded pretty strongly to the effect of "Go
make your arguments somewhere else!" however. (Remembering that
"please" does not always mean, "if you please".)

-- 
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/caar43inuvmx2guxxzxozntugszzmbu8fkbvmowgc9sqq+fz...@mail.gmail.com

Re: [exim4] mixed up about terminology

2014-10-08 Thread Joel Rees

On Wed, Oct 8, 2014 at 9:32 PM, Jonathan Dowland  wrote:
> On Tue, Oct 07, 2014 at 10:40:28PM -0400, Jerry Stuckle wrote:
>> And how can you be positive your network is secure?  For instance, you
>> don't have a configuration error, a bug in a router, an access point
>> with weak encryption...  the list of potential holes is almost endless.
>
> The likelyhood of both one of those scenarios AND a spammer with local access
> discovering and exploiting them are rather lower, than the risk of getting
> something wrong when setting up SMTP Auth and SSL properly for all current
> and future clients on this small home LAN, especially since the OP is not an
> experienced administrator of SMTP servers. Using (or abusing, if you insist)
> dc_relay_nets for this scenario is entirely sensible advice, IMHO.

I dunno.

I rather think (not that I'd rather it be so) that you're more likely
to have a spammer with local access in the mentioned scenarios than
should there be a lack thereof.

Configuration is configuration, some may be harder than others, but
misunderstanding the configuration invites errors. (I don't see client
configuration as being that hard, myself, BTW.)

Also, he seems to be talking about VMs as much as (or more than) an
actual network with physical boxes on it. 30 VMs, I think he said. So
he is going to be getting practice.

-- 
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/CAAr43iO2q9cCkdgrd+-+T-U2pQt0wGm22gM+_5cWpDSp3oR=m...@mail.gmail.com

Re: mounting local hd from live usb, was 'root account inaccessible'

2014-10-08 Thread Joel Rees

Does jessie still provide /dev/disk/by-id , etc.?

as in

 ls -la /dev/disk/by-id
 ls -la /dev/disk/by-label

etc.?

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

2014-10-09 Thread Joel Rees

2014/10/09 10:58 "lee" :
>
> Joel Rees  writes:
>
> >> 2014/09/25 9:15 "lee" :
> >>
> >>> Joel Rees  writes:
> >>
> >>
> >> Hmm.  So linkage is a result of complexity,
> >
> > What is complexity?
> >
> > Complexity is not a simple topic. :-\

Indeed. And one of the problems with computers is that people want to
believe that computers can make complexities go away.

Some complexities you can encapsulate or hide, or expose in an
organized manner so that that are easier to deal with. Others, no.

> >> and implicity is a result of
> >> undeclaredness (or unawareness of declaredness).
> >
> > Sort of, but not quite.
> >
> > I would rather say,
> >
> > Implicitness is the lack of explicit declaration at the point
> > where the linkage is expressed (or occurs).
> >
> > but I'm not sure that would be universally well understood, either.
>
> So implicitness isn't a result of something but a lack of explicitness.

Generally, the things which are implicit are the things which are not
said, but assumed to be understood: unspoken assumptions.

Logical implication is a different thing, the process of deriving
something from assumptions which have to be explicit. The base word
"imply" can cause yet another kind of confusion.

> Too much explicitness isn't good, either, because it'll get into your
> way.

Yeah, if you take the time to explicitly specify every parameter,
you're going to have a hard time getting started coding. And
specifying too many parameters can really slow an implementation down.

> You could as well argue that linkage is basically a bad thing and
> therefore should only be accepted for instances where it has significant
> advantages which outweigh the disadvantages.  At least we have a
> tautology here.

Oh! The problem of evil rears its head in mathematics. ;-/ (sorry.)

But the hidden assumption that linkages can be completely done away
with is where the logic goes wrong. Remove all externally accessible
parameters and you can't even write the algorithm, much less implement
it.

> > Generally, reducing complexity and reducing linkage are related, but
> > not necessarily. The degree to which linkage is implicit, or to which
> > entanglement is hidden, is not necessarily dependent on the degree of
> > either complexity or linkage. These can be independent variables,
> > depending on the case in question. In some cases, you can even make
> > them indpendent variables, when they didn't start out that way in your
> > analysis.
>
> Hm, true ... Less linkage is easier to hide than more linkage.  It makes
> me think of a simple perl script.  Such a script probably has an
> unbelievable amount of implicit linkage. For example:
>
> perl -e 'print scalar localtime, "\n";'

Well, that indeed illustrates a lot about complexity, and about hiding
it, along with the hidden parameters that can turn into implicit
linkage.

(I'd like to say more about perl, but I don't have time.)

> >> Since you cannot make things less complex,
> >
> > I'm not sure what you're trying to say.
> >
> > If you know you can make things more complex, you know that there must
> > be things that can be made less complex.
>
> The less complicated things tend to be deprecated and to become
> obsolete.

Well, the sales crew definitely wants you to believe it.

> 25 years ago, computers didn't have sound cards.  You could possibly add
> one, making your computer more complicated both in terms of total
> complexity of hardware and software.  Nowadays, a replacement for a
> sound card is built in.  Making things less complicated would mean to
> omit or to remove the sound cards and their replacements.  Who wants to
> do that?

On the one hand, sometimes you do remove most of the sound software,
leaving just enough of the drivers to keep the sound card in a safely
powered-down state.

On the other hand, with sound-on-the-motherboard, many old sound card
modes are unsupported. The overall number of externally accessible
parameters, and the complexity of interaction of what remains is
decidedly less  that what all but the cheapest sound cards used to
supply.

Also, with all the stuff that is on the motherboard, you can often get
rid of much of the circuitry that would otherwise drive the external
busses, and simplify much of the driver software.

You really can't say that progress is linear in the direction of
increasing complexity.

> > There are several kinds of complexity.
> >
> > One is purely subjective -- perceived complexity: "It's different, so
> > it's complicated." or &qu

Re: Effectively criticizing decisions you disagree with in Debian

2014-10-09 Thread Joel Rees

2014/10/10 8:47 "Steve Litt" :
>
> On Thu, 25 Sep 2014 21:27:30 +0900
> Joel Rees  wrote:
>
> > Complexity is not a simple topic. :-\
>
> Can I quote you on that?

Heh.

I was quoting several teachers and co-workers, I don't know if anyone has
figured out who said it first. It predates the Greek philosophers, however.
8-)

But go ahead, if you think it's a good idea.

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: question about systemd

2014-10-09 Thread Joel Rees

2014/10/10 9:03 "Steve Litt" :
>
> [...]
> LOL, the more people bust old features putting in new features, the
> more I kludge.

And that sums the entire argument up nicely, perhaps.

:-(

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: In Poettering's own words: was question about systemd

2014-10-11 Thread Joel Rees

Testing, here.

Just want to check whether I get filtered out from here, as well.

(Two responses to a thread that invites discussion of the /usr merge
have not made it to the list yet.)


-- 
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/caar43inwe0hv5puqovuakwe0sxtks0qm-xb78k_hlqewwyp...@mail.gmail.com

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  wrote:
> [...]
> Daemontools runscripts are incredibly simple shellscripts, that I'm
> sure you could write no sweat except in very wierd edge cases. Here's
> my run script for my home-grown cron substitute:
>
> ==
> #!/bin/sh
>
> ### DON'T START littcrond UNTIL THE NETWORK'S UP ###
> pingaddr=8.8.8.8
> pingaddr=192.168.something

Binding a value to pingaddr twice?

> echo littcrond checking network 1>&2

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

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

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

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

Exclamation mark inverts the test.

ping returns a success value.

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

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

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

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

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

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

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

> ==

--
Joel Rees

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

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

Re: Bash usage: was implicit linkage

2014/10/12 23:07 "Andrei POPESCU" :
>
> 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" :
>
> 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" :
>
> On Sun, 12 Oct 2014 09:33:43 +0100
> Martin Read  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: Moderated posts?

On Sun, Oct 12, 2014 at 11:28 PM, lee  wrote:
> Steve Litt  writes:
>
>> A) Tell everyone it's a moderated list
>> B) Send the poster a short reason why his post has been moderated.
>
> It would be against RFC-821 to silently drop messages.

That's why RFCs aren't/shouldn't be consider hard standards.

But, anyway, see RFCs 2821 and 5321 as well, noting such entries in
the headers as obsoleted-by and updated-by, and remember, "Request For
Comments", even though many news sources insist that these things must
be considered standards. (I know that's a lot to read and remember in
one sitting. I don't remember/understand it all, myself, either.)

(But in this case, absolutely requiring a response would be building a
DOS and potential privacy vulnerability into the message
infrastructure. The RFCs really should be stored with a summary of
relevant comments.)

-- 
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/CAAr43iO6deoipA=oc_y28tr+arhmrv6osgega95__lctpq7...@mail.gmail.com

Re: piece of mind (Re: Moderated posts?)

On Mon, Oct 13, 2014 at 7:04 AM, lee  wrote:
> Bas Wijnen  writes:
>
>> [Moving this to -project, where it belongs; please follow up only
>> there, not on -user or -devel.]

Uhm, might I ask, ${what}-project ?

Oh.

https://lists.debian.org/debian-project/2014/10/

Is that going to be appreciated?

>> On Sun, Oct 12, 2014 at 06:18:01PM +0200, lee wrote:
>>> Why doesn't Debian just do a GR on this issue?
>>
>> Because for a GR, a member of Debian has to request it and it needs to
>> be seconded by at least 5 other members (constitution 4.2.1, 4.2.7).
>> This has not happened.
>
> I know, and I'm suggesting to omit this requirement.
>
>>> Considering that the users are Debians' priority, couldn't this issue be
>>> a case in which significant concerns from/of the users about an issue
>>> might initiate a GR?
>>
>> No. Debian is a very elitist organization.  The members decide what to
>> do, and nobody else does.  As a whole we rule over our users with
>> enlightened absolutism.  The main difference with rulers of countries is
>> that our users can go away more easily. ;-)
>>
>> Debian is extremely democratic for its members, but it is utterly
>> undemocratic for its users.  And there's nothing wrong with that, IMO.
>
> Then they shouldn't say in their social contract that the users and
> their needs are the priority.
>
>>> Wouldn't it speak loudly for Debian and its ways and for what it
>>> stands for, or used to stand for, if it was established procedure that
>>> issues arising significant concerns amongst the users can lead to a
>>> GR?
>>
>> I'll speak for myself here: I don't really care about the init system.
>> I am unhappy with the emotions that this debate is causing, but I'm not
>> very interested in the technical parts.

Are you a dev? If you are, it seems odd that you wouldn't be looking
into the technical issues of something that is causing so much debate.

>> From what I see on the mailing
>> lists, it seems that a few users are very unhappy and they keep bringing
>> this up.  But if this would be a big issue for many people, then there
>> should be no problem finding 6 members to start a GR (our members are
>> users, too).  That still hasn't happened, so I conclude that it isn't a
>> big issue.
>
> There can be many reasons for why there hasn't been a GR.  Some of these
> may be that the devs/maintainers don't really care about the init
> system, or that they aren't aware of how far-reaching this issue is.

I'm inclined, seeing as I've watched political processes in committees
before, to believe that most of the devs are under the impression that
even having an opinion on the subject will taint them. Ergo,
peer-pressure from a lot of conversations, probably in BOFs,
"hackfests", and such, that are now lost to history.

When you are familiar with this kind of politics (referred to by some
in our community as social engineering), you recognize the
after-effects in the way people who are normally reasonable and
reasonably logical suddenly start saying things that are non-sequitur
and stopping too early at politically correct conclusions when the
tainted subject comes up.

I'm not accusing anyone of overt threats. I kind of like the term
"social engineering" (except that it's a bad reflection on engineering
disciplines, in general) for this kind of stuff. It's simply a matter
of respected, charismatic types, people who "should know about a
subject" mentioning off-hand in private conversations things like

Oh, gee, didn't you know that Doctor A. B. C. proved the
non-existence of NP-complete problems?

in a group of people who are sort-of familiar with the idea of
NP-complete problems, but not really equipped with the tools to say to
themselves

Huh? that's kind of like saying somebody found a way to defeat entropy.

and not really in a position to try to find anything written by Doctor
A. B. C. or about his work because they are out of the social network.

>>> I'm sure we could find quite a few supporters for having a GR amongst
>>> the users (here).  And after all, we're all kinda stuck in the same
>>> boat.  A GR might have the potential to make the gap between users and
>>> devs/maintainers a lot smaller.  Otherwise, this gap will only continue
>>> to become wider and wider.
>>
>> There are many members.  If you can't manage to convince 6 of them, we
>> don't consider it a big issue.  You may disagree, but that's Debian's
>> rules.
>
> I think I don't need to convince 6 people on th

Re: implicit linkage

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

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

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

-- 
Joel Rees

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

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

Re: MTAs denying messages (was: Re: Moderated posts?)

On Mon, Oct 13, 2014 at 9:24 AM, lee  wrote:
> Joel Rees  writes:
>
>> (But in this case, absolutely requiring a response would be building a
>> DOS and potential privacy vulnerability into the message
>> infrastructure. The RFCs really should be stored with a summary of
>> relevant comments.)
>
> Could you explain how an MTA would create a privacy vulnerability or
> expose itself to DOS attacks by not accepting messages?
>
> For example, my MTA does not accept messages that have an empty Subject:
> header.  How does that expose my privacy or allow for DOS attacks?

Somebody mentioned both the problem and the usual solution later in
the thread, but, laying it out in more detail:

I have an e-mail address my ISP gave me. Back almost twenty years ago,
when the internet was still a bit safe for naive use, I put my
isp-provided e-mail address in my home page. For the last fifteen
years, I've had to periodically clear that mailbox of junkmail, a
thousand in a week at the worst times, down to about a hundred a week
now.

I'd change the address, but a junkmail magnet is actually an
interesting resource.

Every now and then, I still get a spate of junkmail there, where the
to: field has a long list of semi-random na...@isp.tld . I know those
names are bogus because I know there are not that many users at this
isp who have registered themselves with English names. Rather amusing.

What are the junkmailers doing? Shotgun mailing the isp with possible
user names.

If the isp responds with a code that says my user-id is valid, the
junk mailer knows he has a live address.

If the isp responds to the bad ones with an invalid user-id code, any
user-id that doesn't get that response is assumed live. There's your
privacy problem.

If the isp accepts the message without acknowledging the existence of
the user id, and then later sends an undelivered message, that's still
revealing what user-ids in the random attack were valid, and it also
amplifies the attack -- backscatter. Wikipedia's current article is
fairly informative, check the references, too.

http://en.wikipedia.org/wiki/Backscatter_%28email%29

If the sending box is a bot, it will disappear by the time a delayed
rejection message is sent, which will cause a host-not-found message
from somewhere. This also amplifies traffic.

There have been several relatively well-known cases where this kind of
opportunistic junkmail temporarily took an isp off the network.

Searching the web for such things as "backscatter spam" should get you
more information.

-- 
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/caar43ipjskq9tyfod9vymjszwm3ye5bydwe2tugcnupfcsu...@mail.gmail.com

Re: Bash usage: was implicit linkage

On Mon, Oct 13, 2014 at 1:38 PM, Chris Bannister
 wrote:
> On Mon, Oct 13, 2014 at 07:53:03AM +0900, Joel Rees wrote:
>> 2014/10/13 2:14 "Andrei POPESCU" :
>> >
>> > 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: [exim4] mixed up about terminology

On Mon, Oct 13, 2014 at 11:24 AM, lee  wrote:
> Jerry Stuckle  writes:
>
>> Among other things, legitimate MTAs have MX records.  Anti-spam routines
>
> Who prevents a MUA from having an MX record and sending a HELO that
> matches the RDNS entry?  And what are these "other things" you're
> referring to?

MX record? Recorded in the domain name servers? When the sender is a
bot with an ephemeral MTA/MUA?

Hmm. Yeah, it can be done. Patient and careful use of free dynamic DNS
services, or DNS poisoning. Temporary and slow.

But the more you make the junkmailers work for their money, the more
they switch to legitimate work.

-- 
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/caar43inryoejfasuzzp_wjxlhqch_wgsa+mgavga4ovdnxv...@mail.gmail.com

Re: implicit linkage

de 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 ready to compete seriously
in embedded, and the kernel needs a bit of work before we start
talking about that. (Not that you can't use it now, sans systemd, in
some of the less demanding embedded applications. There are some
embedded applications it will work for, with reasonable pid 1
processes.)

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.

(I think this target would be significantly better than sysv-init, but
you have to set a really good target to get things into a reasonable
range.)

It should not interface directly with dbus, cgroups, udev, or pamd. It
should delegate interfacing to such things to non-pid 1 daemons, and
restrict itself strictly to keeping the daemons themselves working
together.

There are other goals I should mention, but I don't imagine Lennart
Poettering is even the slightest interested in what we have to say
here, so I won't bother.

No matter how much better it is now than last year, the code is still
just plain wrong.

--
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+cd_fc42ytmch7mtqjm+cocxfqh+n0wvthno8cvx...@mail.gmail.com

Re: implicit linkage

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

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

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

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

Does the scheduler run as pid 1?

Have you traced execution paths?

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

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

Or do the execution path analysis.

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

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

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

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

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

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

-- 
Joel Rees

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

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

Re: Bash usage: was implicit linkage

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

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

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

-- 
Joel Rees

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


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

Re: piece of mind (Re: Moderated posts?)

2014/10/14 4:35 "Jonathan Dowland" :
>
> On Mon, Oct 13, 2014 at 12:23:42PM -0700, Bob Holtzman wrote:
> > If that's true, why the avalanche of dissent now?
>
> I see a lot of posts, but hardly any posters, and not a great deal of
clarity
> or consistency about what the complaints are. I also see a lot of FUD,
both
> about systemd and what Debian has agreed to do. In other words I don't
see an
> avalanche, nor the tip of an iceberg.

Step 1: Somebody raises a valid problem, but doesn't have a whitepaper and
list of bugs that will happen.

Step 2: Somebody notices, very publicly, that there is no whitepaper, and
that the person raising the issue is not clairvoyant. (We really want that
list of bugs, of course.)

Step 3: Somebody notices that the complaint can be conflated with a
non-issue, and implicitly advises everyone to do so.

Step 4: Somebody tries to point out that conflating problems with
non-issues is not a good idea.

Step 5: A chorus of boos rises aganst the whole thread, because there is no
whitepaper, and no clairvoyance, and besides, it looks "just like this
non-issue".

Presto: All dissent is fud.

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: Way OT: Re. lines of code [was Re: implicit linkage]

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

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

Non-deterministic execution.

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

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

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

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

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

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

-- 
Joel Rees

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

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

Re: debian-advocacy?

On Tue, Oct 14, 2014 at 7:35 AM, Brian  wrote:
> On Mon 13 Oct 2014 at 15:07:33 -0700, Buntunub wrote:
>
>> This list is the perfect place for such things. The decision to make Systemd
>> default in Jessie was done by the Technical Committee, not by general vote,
>> so I guess it was decided that the whole discussion about Systemd is a bug
>> because it was relegated to such. This is the mailing list used to discuss
>> bugs and technical issues, is it not?
>
> I wanted so much to understand and make sense of what was being said
> here but gave up in the end and turned to the comfort of a book on
> Quantum Chromodynamics.

Can I recommend a thesis on analyzing execution paths of critical processes?

-- 
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/caar43ipokgmhr+y-5eeyxi1nslxssmodsyk6xqhe35btx1b...@mail.gmail.com

Re: debian-advocacy?

On Tue, Oct 14, 2014 at 8:14 AM, Brian  wrote:
> On Tue 14 Oct 2014 at 08:02:28 +0900, Joel Rees wrote:
>
>> On Tue, Oct 14, 2014 at 7:35 AM, Brian  wrote:
>> > On Mon 13 Oct 2014 at 15:07:33 -0700, Buntunub wrote:
>> >
>> >> This list is the perfect place for such things. The decision to make 
>> >> Systemd
>> >> default in Jessie was done by the Technical Committee, not by general 
>> >> vote,
>> >> so I guess it was decided that the whole discussion about Systemd is a bug
>> >> because it was relegated to such. This is the mailing list used to discuss
>> >> bugs and technical issues, is it not?
>> >
>> > I wanted so much to understand and make sense of what was being said
>> > here but gave up in the end and turned to the comfort of a book on
>> > Quantum Chromodynamics.
>>
>> Can I recommend a thesis on analyzing execution paths of critical processes?
>
> I'd try anything if it brought enlightenment to the post I responded to.

Well, that would be another topic.

But understanding execution path analysis might help understand some
of the underlying reasons for these kinds of posts.

If you aren't familiar with the topic of execution paths, these
wikipedia articles will get you started on the topic:

http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29
http://en.wikipedia.org/wiki/Performance_engineering
http://en.wikipedia.org/wiki/Worst-case_execution_time

I thought I had some theses handy on the topic, but they discuss tools
for analysis and assume understanding the topic. One is

ftp://ftp.cs.wisc.edu/pub/paradyn/technical_papers/CritPath-ICDCS1988.pdf

-- 
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/CAAr43iO5Jr8oLdsjxh=b-eoc5admj8mtqh1umcerxq75u1v...@mail.gmail.com

Re: Moderated posts?

On Tue, Oct 14, 2014 at 8:18 AM, lee  wrote:
> Jerry Stuckle  writes:
>
>> And, in fact, more and more ISPs are just accepting and discarding
>> emails to non-existent users because rejecting such email helps spammers
>> (any non-rejected email must be a valid user).
>
> That's totally retarded.  When I don't get an error message in return,
> the message I sent has been delivered.  If it hasn't because there's
> some error, I will not be responsible for any damage that may hit the
> recipient or myself.  Quietly dropping messages is not an option.

There is a header for requesting automatic confirmation of delivery,
but it tends to be abused by malicious junkmailers (spammers). MUAs
are supposed to be able to disable it, but I haven't seen that option
in an MUA settings dialog for a long time.

This is a grey area of the e-mail standard. People want it to be like
snail-mail, only automatic, but don't realize that having people in
the loop is what provides the desired feature.

I mean, you really can't have certified delivery without someone to certify it.

-- 
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/caar43in3hz9mvqnvzfm2icctf22wu325rbfchvgl3bwad9o...@mail.gmail.com

Re: Network fails on headless system. I'm stuck!

 message I got on the serial terminal was:
> ng device sys-subsystem-net-devices-eth0.device...
> [   ***] (5 of 7) A start job is running for dev-disk-by\x2dl...14s / 1
> which wasn't readable because of a lot of CR without LF. the syslog
> above tells more about it.
> After this the serial console stops working.
>
>
> attached
> crash.log - the kernel panic that occured while I had network problems
> history.log - /var/log/apt/history.log - I cannot find anything network
> related in there.
>
>
> any idea what the problem is, and how to solve?
>
> thanks for any help,
>
> Jan
>
>
> ps. I did not subscribe the list. Please CC me.



-- 
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/caar43inmhazyqy2g3u-iqqedkt2vszkh6rzd71ed+qnhmdg...@mail.gmail.com

Re: Recipient validation - WAS: Re: Moderated posts?

2014-10-14 Thread Joel Rees

Oh, dear. Somebody is WRONG on the Internet!

You're talking past each other.

Still, the current "standard" e-mail protocols were never meant to be
either reliable or secure, and their is a very good reason for that. People
may not be as reliable as machines in executing protocols, but they cannot
be 100% reliable, and only people can certify things.

2014/10/15 1:04 "Tanstaafl" :
>
> On 10/14/2014 11:17 AM, Jerry Stuckle  wrote:
> > On 10/14/2014 8:05 AM, Tanstaafl wrote:
> >> If you think I'm kidding, please by all means go make these silly
> >> statements on the postfix list and I'll just sit and watch the fun.
>
> > You don't read very well.  This has nothing to do with emails to a valid
> > address.  A large amount of that spam goes to invalid addresses.  I see
> > them go through the logs regularly.
>
> I read fine. The 'silly statements' reference was about your suggestion
> that it is in any way shape or form 'ok' to *accept* mail to invalid
> recipients then send it to dev/null.
>
> >>> To bounce all of those invalid addresses not only would further
> >>> increase the amount of junk on the internet,
>
> >> That is pure and absolute nonsense. The vast majority of spam comes
from
> >> botnets, and *rejecting* garbage from these results in ZERO additional
> >> smtp traffic.
>
> > Wrong.  Rejecting garbage sends a message back to the originator,
>
> No, it doesn't. It closes the connection with a response code.
>
> The system that had opened the connection and was attempting to send the
> email is the one responsible for 'sending a message back to the
originator'.
>
> Well, *if* the system talking to your server is the originating server,
> that is.
>
> If, on the other hand, there were relays involvbed, then it would simply
> relay the response code back down the chain until it got to the
> originating server.
>
> This is very simple to validate. I suggest you do so before compounding
> your error in public.
>
> > increasing the traffic.  Simply dropping them, as I do, does not.
>
> Given an identical mail transaction, with an email with a size of 1MB:
>
> If I reject the mail at the RCPT-TO stage, then I only accepted a few
> bytes of traffic before terminating the connection with an SMTP response
> (error) code. The connecting machine then decides whether to pass the
> response back or not (again, a few bytes at most).
>
> If you *accept* the mail, then you accepted the entire 1MB of traffic.
>
> So, who is responsible for more traffic in such a case?
>
> >>> but by not replying, servers tell the spammers what are valid email
> >>> addresses.
>
> >> More nonsense. Security through obscurity *never* works, and only, in
> >> this case totally breaks SMTP.
>
> > Wrong on two counts.  First of all, the false notion "Security through
> > obscurity *never* works".  This has nothing to do with security.
>
> You said you were concerned about telling spammers valid emails. Why are
> you concerned about that if not from a security perspective?
>
> > And BTW, that statement is also wrong - why do you think people are
> > encouraged to use obscure passwords if it doesn't work? But that's
> > another subject.
>
> Lol! Not even in the same ballpark, Jerry. Passwords, by their very
> nature, are intended to be difficult/impossible to 'guess'.
>
> To suggest that this is even in the same universe as 'security through
> obscurity' is ludicrous.
>
> > On the second count - please point out exactly which RFC I am violating
> > that "breaks SMTP".
>
> You don't necessarily need to explictly violate any give RFC to 'break
> SMTP', Jerry.
>
> Breaking recipient validation defacto breaks SMTP. It tells the sending
> server that everything is OK, when it isn't. It allows someone who
>
> >>> Finally, as for "...undermine confidence in the reliability of the
> >>> Internet's mail systems..." - it hasn't been reliable since spammers
> >>> virtually took over the email.  And even when emails were rejected, it
> >>> still was no indication the recipient got the message.
> >>
> >> Of course it wasn't, but it was certainly a positive indication that
the
> >> recipient did *not* receive it (as long as the sending server is
> >> properly configured).
>
> > And why should I care if a bot finds out the message has not been
received?
>
> No one should. What I do care about is if the President of NBC typos an
> email address to our President when sending an important email, I want
> him to know the email didn't make it.
>
> >>> BTW - by definition, any messages to any of the domains I manage
without
> >>> a valid email address are "seriously fraudulent or otherwise
inappropriate".
> >>>
> >> Really?
> >
> > Yes
> >
> >> So when the President/CEO of XYZ Corporation, who does business with a
> >> customer whose domain happens to be managed by you, accidentally typos
> >> an email address, you consider that a 'seriously fraudulent or
otherwise
> >> inappropriate' email?
>
> > Yes.
>
> Please explain what is *Seriously Fraudulent* or *ot

Re: OT: Re: Recipient validation - WAS: Re: Moderated posts?

On Wed, Oct 15, 2014 at 9:01 PM, Miles Fidelman
 wrote:
> Tanstaafl wrote:
>>
>> On 10/14/2014 1:58 PM, Miles Fidelman  wrote:
>>>
>>> Well, this really is OT for debian-users, but  Turns out that SMTP
>>> WAS/IS intended to be reliable.
>>
>> Reliable, absolutely. 100% reliable? That simply isn't possible when
>> people are involved in the equation (people mis-configure servers -
>> whether accidentally, through ignorance, or intentionally (just because
>> that is the way they want it).
>>
>>> I'd always lumped SMTP in the category of unreliable protocols, w/o
>>> guaranteed delivery
>>
>> The protocol itself is extremely reliable. It is what people *do* with
>> it that can cause it to become less reliable/resilient.

There are three ways in which machines can be unreliable.

One, they can break.

Two, they can do what they are told to do, but what they are told to
do can be wrong.

Three, they can operate in a context in which they were not designed to operate.

Unfortunately, most machines operated outside the context in which
they were designed to operate. It's a limitation of design. We are the
designers, and we can't think of everything, therefore we cannot
really design for a real context.

Put another way, any context we can design for is necessarily more
constrained than reality.

Fortunately, most of the contexts we design for are "close enough" to
be useful under many real contexts. But we have to quit being taken by
surprise when our machines hit corner cases, or we end up wasting our
energy being surprised.

That's one of the reasons the Requests For Comments were RFCs and not
standards dictated from on high (like many of the earlier network
definitions that ended up too inflexible).

> There is a technical distinction between "best efforts" (unreliable)
> protocols, such as IP ('fire and forget' if you will), and "reliable"
> protocols, such as TCP (with explicit acks and retransmits).
>
> At least in the technical circles I run in (BBN - you know, we built the
> ARPANET; Ray Tomlinson, who coined use of the @ sign in email nominally
> worked for me, for a short period - in a matrixy version of "worked for"),
> SMTP is usually discussed as providing a "best efforts" (unreliable) service
> -- which, in reality, it is (particularly in real world configurations where
> mail often gets relayed through multiple servers).
>
> So.. I was just a bit surprised to go back and read the RFC and discover
> that SMTP is explicitly intended to provide a reliable service.

If it is, that has changed.

Elsewhere from the part you quoted, there used to be an explanation of
the self-contradictory nature of the requirements.

Specifically, machines cannot actually (the illusions of PKI becoming
widely accepted notwithstanding) certify delivery. That requires a
human at both ends of the chain, in addition to the possibly human
sender and recipient. RFC 821 messages were intended not to require
any human in the chain.

If that has changed, it would be the unreasoning demands of people who
want e-mail to perfect in ways snail mail only almost could be in the
best of times: people who want to be able to do things like sue other
people for not complying with obscure rules when informed of those
rules by e-mail.

> As to "100% reliable" - nothing is 100% reliable.
>
> Miles Fidelman
>
> --
> In theory, there is no difference between theory and practice.
> In practice, there is.    Yogi Berra

-- 
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/CAAr43iP9t8iJYmPNLkVw_Pg8UAJYHHZeacftZ=fm_rt2cr1...@mail.gmail.com

Re: Conflict of interest in Debian

 they just basically aren't going to get any faster with any
of the technology that we have any Moore.

systemd tries to do too much, and fixing the corner cases will kill it
eventually. Processors aren't going to get faster and save the day
like they have with so many formerly impossible things.

Hopefully, by that point, Poettering will cease to believe he's
Supercoder and start having systemd delegate the hard stuff. Or
someone will fork the code and fix what he is refusing to fix.

He could have designed it that way from the start, but then it would
look mostly like a re-write of sysv-init, and it wouldn't have been
such a "cool new technology."

Going further than that will, again, invite people to call "Foul!", so
I'll refrain.

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.


-- 
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/CAAr43iNH0E92tM29vpLYfPXEk+UMN=cYBxuS-=y0jud-c5b...@mail.gmail.com

Re: Conflict of interest in Debian

2014/10/16 5:46 "Ric Moore" :
>
> On 10/15/2014 12:39 PM, Steve Litt wrote:
>
>> We've actually been in this place before. Wonderful Linux company
>> Caldera became SCO (oversimplification, but you know what I mean).
>> Wonderful Linux company Corel changed their CEO, and promptly accepted
>> money from Microsoft and dropped all their Windows software.
>
> [...]

> If you knew Caldera, then you would know that it started with
capitalization and focus by the retired CEO of Novell, Ray Noorda.
> Now that is my kinda guy, as he knew that Linux would grow to be more
than a desktop hobby toy. And, he put his own money where his mouth was. He
was not responsible for what happened after. I still have a copy of the
Caldera install CD and it worked like a charm on an aging ThinkPad. But it
was too pitiful to watch Netscape try to update itself. :) Ric
>

Yes, Noorda was a good guy.

I think Steve was talking about a later CEO.

Re: piece of mind (Re: Moderated posts?)

2014/10/16 5:59 "Andrei POPESCU" :
>
> On Mi, 15 oct 14, 09:46:47, The Wanderer wrote:
> >
> > I suspect that the answer is "they just didn't provide the functionality
> > which ConsoleKit, and later systemd-logind, now enable them to provide",
> > but I'm not aware - in a clear-understanding, defined-boundaries sense -
> > of exactly what that functionality is, or of why it would be necessary
> > or otherwise valuable, or of what the problem is which that
> > functionality was intended to address.
>
> A problem that ConsoleKit and logind is trying to address is handling
> permissions to access devices.
>
> Traditionally on *nix machines this was done with user groups, e.g.
> members of 'audio' would have full (read/write) access to all audio
> devices and members of 'video' would have full access to video cards or
> web-cams.
>
> The problem with this approach is that it's not fine-grained enough,
> i.e. it can't distinguish between users logged in locally or via ssh.
> This means Mallory could easily spy on Alice remotely, just by being a
> member of 'audio' and 'video'.
>
> Hope this explains,
> Andrei

Two thoughts that this problem brings to mind --

(1) Why should it matter? Local? Remote? A hole is a hole.

(1.5) How does ssh deal with making connections private? Any clues there?

(2) There are times when I don't want to have to be logged in as an admin
user to be able to make an ephemeral group. I've understood that for ten
years. When am I going to make the time to construct the package to manage
it within the standard unix permissions model?

:-(

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: piece of mind (Re: Moderated posts?)

2014/10/16 8:14 "Chris Bannister" :
>
> On Wed, Oct 15, 2014 at 12:30:26PM -0400, Steve Litt wrote:
> >
> > I completely understand not reinventing the wheel, but if all you need
> > is a spoke, you don't construct an interface to a whole wheel just to
> > get your spoke.
>
> A wise old owl lived in an oak
> The more he saw the less he spoke
> The less he spoke the more he heard.
> Why can't we all be like that wise old bird?

There are "generalisms" like "monolithic is a problem".

And then there are generalisms like "Engage brain, then engage mouth."

I might wonder which is more on-topic here.

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

Would discussion of improving sysv-init be on topic?

systemd's problems would best be discussed at the systemd project. (Modulo
the willingness of the devs over there to discuss them.)

What I'm thinking is to talk about specific features to enable the sort of
"managing services" that systemd seems to be aimed at, and how to implement
them, where existing alternatives exist and how well they work,

With enough discussion, we might be able to get enough mass to get a
project started and get it (mostly) off-list.

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: piece of mind (Re: Moderated posts?)

2014/10/16 15:34 "Jonathan Dowland" :
>
> On Thu, Oct 16, 2014 at 01:12:51AM -0400, Steve Litt wrote:
> > OK, I'll be the first to admit that after Red Hat caused the demise of
> > ConsoleKit (and probably lots more important software), I am free to
> > take significant time out of my day job (that feeds my family) and
> > rescue all sorts of software that Red Hat deliberately scuttled.
>
> You're being completely ludicrous, Steve. The extent of your sense of
> entitlement is breathtaking. Here you are on a list dedicated to an OS
> built almost entirely by volunteers and you're not prepared to roll
> your sleeves up, but you're more than happy to tell everyone how they
> should do it, and what they should do.
>
> I'm not going to engage with you any more on this list.

I think it would help if we wouldn't assume the other guy is freeloading,
just because he seems to have time to be looking places we not to, or
because he shares his work in different ways.

FWIW, I've been getting three or four hours of sleep at night for the last
month, and I haven't touched any of my personal projects since before
summer, including one that should have been making my day job significantly
easier by now.

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: Recipient validation - WAS: Re: Moderated posts?

On Thu, Oct 16, 2014 at 7:58 PM, Tanstaafl  wrote:
> On 10/15/2014 8:37 PM, Jerry Stuckle  wrote:
>> Tanstaafl couldn't answer it, and you can't either, because it's not
>> violating any.
>
> I did answer it, you just ignored it or don't understand it.
>
> Quote:
>
> "You do not have to violate an RFC to break SMTP."
>
> Here is a real world example:
>
> Improperly configured TCP filtering features on firewalls and routers
> don't violate any specific RFC, but they certainly can break SMTP (and
> other things too).

Thus, we can understand that you are an idealist that would rather see
your version of SMTP rules be followed by everyone than try to follow
the RFC yourself.

Where are your SMTP rules spelled out, by the way?

-- 
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/CAAr43iMhgnbTZiDfiG=yyV8cC5O+=-pttkhdaxemzqub6x3...@mail.gmail.com

Re: Would discussion of improving sysv-init be on topic?

On Thu, Oct 16, 2014 at 9:33 PM, Nate Bargmann  wrote:
> * On 2014 15 Oct 19:39 -0500, Joel Rees wrote:
>> systemd's problems would best be discussed at the systemd project. (Modulo
>> the willingness of the devs over there to discuss them.)
>>
>> What I'm thinking is to talk about specific features to enable the sort of
>> "managing services" that systemd seems to be aimed at, and how to implement
>> them, where existing alternatives exist and how well they work,
>>
>> With enough discussion, we might be able to get enough mass to get a
>> project started and get it (mostly) off-list.
>
> Perhaps you are not aware of the development project for sysvinit that
> already exists:
>
> http://savannah.nongnu.org/projects/sysvinit
>
> That would be a far better place to get involved.

Would that be debian's sysv-init?


-- 
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/CAAr43iOPHp9172PXkvJENUqr=lph7+15wgmelz3cdosp-fh...@mail.gmail.com

Re: Recipient validation - WAS: Re: Moderated posts?

On Thu, Oct 16, 2014 at 9:34 PM, Tanstaafl  wrote:
> On 10/16/2014 7:40 AM, Joel Rees  wrote:
>> On Thu, Oct 16, 2014 at 7:58 PM, Tanstaafl  wrote:
>>> > On 10/15/2014 8:37 PM, Jerry Stuckle  wrote:
>>>> >> Tanstaafl couldn't answer it, and you can't either, because it's not
>>>> >> violating any.
>>> >
>>> > I did answer it, you just ignored it or don't understand it.
>>> >
>>> > Quote:
>>> >
>>> > "You do not have to violate an RFC to break SMTP."
>>> >
>>> > Here is a real world example:
>>> >
>>> > Improperly configured TCP filtering features on firewalls and routers
>>> > don't violate any specific RFC, but they certainly can break SMTP (and
>>> > other things too).
>> Thus, we can understand that you are an idealist that would rather see
>> your version of SMTP rules be followed by everyone than try to follow
>> the RFC yourself.
>>
>> Where are your SMTP rules spelled out, by the way?
>
> Ok, I just went and looked it up, and lo and behold...
>
> RFC 2821 is the controlling RFC if I'm not mistaken...
>
> https://tools.ietf.org/html/rfc2821
>
> In there you'll find this:
>
> "   The second step in the procedure is the RCPT command.
>
>   RCPT TO: [ SP  ] 
>
>The first or only argument to this command includes a forward-path
>(normally a mailbox and domain, always surrounded by "<" and ">"
>brackets) identifying one recipient.  If accepted, the SMTP server
>returns a 250 OK reply and stores the forward-path.  If the recipient
>is known not to be a deliverable address, the SMTP server returns a
>550 reply, typically with a string such as "no such user - " and the
>mailbox name (other circumstances and reply codes are possible).
>This step of the procedure can be repeated any number of times."
>
> So, how do you 'interpret' the pertinent part:
>
> "If the recipient is known not to be a deliverable address, the SMTP
> server returns a 550 reply, typically with a string such as "no such
> user - " and the mailbox name (other circumstances and reply codes are
> possible)."
>
> ?
>
> Sounds to me like a mandate to reject invalid recipients at the RCPT-TO
> stage.

Well, I'll tell you what. Before I try to engage with you on this, I'm
going to do my part and re-read RFCs 5321, 5322, 4409, and BCP 14 and
several others referred to therein, completely, and make sure I
understand them.

I strongly encourage you to do the same.

-- 
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/caar43ip5ymnc3zvqsvyqwo3bgabwseaf1djcxif_lmsqsou...@mail.gmail.com

Re: Would discussion of improving sysv-init be on topic?