[9fans] quote o' the day

[9fans] quote o' the day

[erik quanstrom]

http://lwn.net/Articles/378219/
	"[...] anything which combines tricky locking
	and 30-line preprocessor macros is going to raise eyebrows.
	But the core concept here is simple: [...]

oh, really?

- erik

Re: [9fans] quote o' the day

[maht]

On 25/03/2010 14:08, erik quanstrom wrote:
> http://lwn.net/Articles/378219/
> 	"[...] anything which combines tricky locking
> 	and 30-line preprocessor macros is going to raise eyebrows.
> 	But the core concept here is simple: [...]
>
> oh, really?
>
> - erik
>
>

Trying to acquire one lock per CPU will work just dandy.

 > One such case - the target for this new lock - is vfsmount_lock,
which is required (for read access) in pathname lookup operations.
Lookups are frequent events, and are clearly performance-critical. On
the other hand, write access is only needed when filesystems are being
mounted or unmounted - a much rarer occurrence. So a brlock is a good
fit here, and one small piece (out of many) of the VFS scalability
puzzle has been put into place.


bye bye private Linux namespaces, it wasn't even nice knowing you

Re: [9fans] quote o' the day

[ron minnich]

It just keeps getting better:

   $ hugeadm --create-global-mounts
    $ hugeadm --pool-pages-max DEFAULT:8G
    $ hugeadm --set-recommended-min_free_kbytes
    $ hugeadm --set-recommended-shmmax
    $ hugeadm --pool-pages-min DEFAULT:2048MB
    $ hugeadm --pool-pages-max DEFAULT:8192MB

"In this installment, it was shown that with minimal amounts of
additional work, huge pages can be easily used to improve benchmarks."

woo hoo!

ron

Re: [9fans] quote o' the day

[Corey Thomasson]

Not really related, but I got a good laugh from this.
As soon as I opened this email in gmail, the "targeted ad" changed to

"Editing xml is difficult."

Followed by some stuff about Xopus xml editor, but still.

On Thu, Mar 25, 2010 at 12:56 PM, ron minnich <rminnich@gmail.com> wrote:
>
> It just keeps getting better:
>

Re: [9fans] quote o' the day

[maht]

On 25/03/2010 17:11, Corey Thomasson wrote:
> Not really related, but I got a good laugh from this.
> As soon as I opened this email in gmail, the "targeted ad" changed to
>
> "Editing xml is difficult."
>
well that is true, the following snippets are not the same, the second
has two more nodes

<a><b>hi</b></a>

<a>
<b>hi</b>
</a>

Re: [9fans] quote o' the day

[Corey Thomasson]

Of course it's true, that's why its funny.

On Thu, Mar 25, 2010 at 1:15 PM, maht <maht-9fans@maht0x0r.net> wrote:
> well that is true, the following snippets are not the same, the second has
> two more nodes
[...]

Re: [9fans] quote o' the day

[Robert Raschke]

[-- Attachment #1: Type: text/plain, Size: 631 bytes --]

On Thu, Mar 25, 2010 at 5:15 PM, maht <maht-9fans@maht0x0r.net> wrote:

> On 25/03/2010 17:11, Corey Thomasson wrote:
>
>> Not really related, but I got a good laugh from this.
>> As soon as I opened this email in gmail, the "targeted ad" changed to
>>
>> "Editing xml is difficult."
>>
>>
> well that is true, the following snippets are not the same, the second has
> two more nodes
>
> <a><b>hi</b></a>
>
> <a>
> <b>hi</b>
> </a>
>
>
>
And depending on what parser you're using, you might get the same tree or
not! Found out recently, that some parsers very "helpfully" elide "empty"
TEXT nodes.

Robby

[-- Attachment #2: Type: text/html, Size: 1182 bytes --]

Re: [9fans] quote o' the day

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

The efficiency of XML when being processed by computers or humans proves
that it's neither machine nor human readable, despite all the advertising.

Dave

On Thu, Mar 25, 2010 at 10:11 AM, Corey Thomasson <cthom.lists@gmail.com>wrote:

> Not really related, but I got a good laugh from this.
> As soon as I opened this email in gmail, the "targeted ad" changed to
>
> "Editing xml is difficult."
>
> Followed by some stuff about Xopus xml editor, but still.
>
> On Thu, Mar 25, 2010 at 12:56 PM, ron minnich <rminnich@gmail.com> wrote:
> >
> > It just keeps getting better:
> >
>
>

[-- Attachment #2: Type: text/html, Size: 1003 bytes --]

Re: [9fans] quote o' the day

[erik quanstrom]

On Thu Mar 25 12:58:22 EDT 2010, rminnich@gmail.com wrote:
> It just keeps getting better:
>
>    $ hugeadm --create-global-mounts
>     $ hugeadm --pool-pages-max DEFAULT:8G
>     $ hugeadm --set-recommended-min_free_kbytes
>     $ hugeadm --set-recommended-shmmax
>     $ hugeadm --pool-pages-min DEFAULT:2048MB
>     $ hugeadm --pool-pages-max DEFAULT:8192MB
>
> "In this installment, it was shown that with minimal amounts of
> additional work, huge pages can be easily used to improve benchmarks."

and, finally
	$ hugeadm --induce-involuntary-twitching DEFAULTMODE:crazyunixguy \
		--involuntary-twitching-random-seed 2269  \
		--involuntary-twitching-mean-frequency 1000 milliseconds \
		--involuntary-twitching-ready --involundary-twitching-set --go \
 		--no-i-really-mean-it

was it just me, or was the performance improvement
underwhelming, considering the downsides and the
fact that it was a synthetic benchmark?

- erik

Re: [9fans] quote o' the day

[blstuart]

It's this kind of intellectual ugliness that makes the
teacher in me hang my head in shame.  How could
we be managing to produce a whole generation of
programmers who actually buy into that stuff?  And
it's not as if it's a fad that's getting better.  If anything
it's getting worse.  Somehow we've made it laudible
to go to any lengths to avoid writing a line of real
code and to run as far away from hardware as we
can.  That and worship at the alter of "code reuse"
have created a world where if one abstraction is
good, then 432 must be better.  If a symbol appears
that's not defined in 17 different places all surrounded
by #ifdef's, then that's not "professional."  Everyone
is afraid to point out the nudity of the XML monarch
for fear of being branded as one afraid of change.

I humbly extend my apologies for any of this that
might have been promulgated by any of my former
students :(

\end{soapbox}

BLS

Re: [9fans] quote o' the day

[Patrick Kelly]

On Thu, 25 Mar 2010 14:31:20 -0300, <blstuart@bellsouth.net> wrote:

> It's this kind of intellectual ugliness that makes the
> teacher in me hang my head in shame.  How could
> we be managing to produce a whole generation of
> programmers who actually buy into that stuff?  And
> it's not as if it's a fad that's getting better.  If anything
> it's getting worse.  Somehow we've made it laudible
> to go to any lengths to avoid writing a line of real
> code and to run as far away from hardware as we
> can.  That and worship at the alter of "code reuse"
> have created a world where if one abstraction is
> good, then 432 must be better.  If a symbol appears
> that's not defined in 17 different places all surrounded
> by #ifdef's, then that's not "professional."  Everyone
> is afraid to point out the nudity of the XML monarch
> for fear of being branded as one afraid of change.

I assume you haven't studied human behavior much... sadly we are socially
dependent, we will follow even if we know something is harmful. Look at
fad diets and superstitions.

I always have to laugh at the code reuse crap; I though that was what a
library was. Do modern programmers not know how to create libraries? That
must not be true, there are something like 11 libraries on UNIX that all
do the same stuff, repeated for each new instance of 'stuff'.

Sadly I think this may be the state the computer industry is heading into;
hacks upon hacks, with little logical design. These hackers using
techniques from the 1970's to program machines in the 2000's .. 2010's;
all the while these techniques have decayed and warped to "fit" the modern
era.

May be I've studied too much history and may be I've studied too much
psychology, but, I think the only way for things to change for the better,
is for what we have now to collapse. I do hope I'm wrong.

> I humbly extend my apologies for any of this that
> might have been promulgated by any of my former
> students :(
>
> \end{soapbox}
>
> BLS
>
>


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] quote o' the day

[blstuart]

> On Thu, 25 Mar 2010 14:31:20 -0300, <blstuart@bellsouth.net> wrote:
>
>> It's this kind of intellectual ugliness that makes the
>> teacher in me hang my head in shame.  How could
>> we be managing to produce a whole generation of
>> programmers who actually buy into that stuff?  And
>> ...
>
> I assume you haven't studied human behavior much...

Not much in the collective.  My AI work was focused on
learning in individual organisms.

> sadly we are socially
> dependent, we will follow even if we know something is harmful. Look at
> fad diets and superstitions.

I have seen that, though I still fail to grasp it.

> I always have to laugh at the code reuse crap; I though that was what a
> library was.

Yep.  I try to put it in perspective in the classroom by saying
that we've had code reuse ever since Grace Hopper put a roll
of paper tape for the Mark I in a drawer and labled it square
root.  (Slightly fictionalized, but not too far from reality.)

> These hackers using
> techniques from the 1970's to program machines in the 2000's .. 2010's;
> all the while these techniques have decayed and warped to "fit" the modern
> era.

I also see the other extreme where trendy seems to be preferred
over straighforward.  There has to be a balance.  We have to keep
open minds about new techniques, but we also have to be versed
in older techniques so there can be some reasonable judgement
about when to apply which.  Using the ABC technology (for any of
a million values of ABC over the years) because it was written up
in some management magazines and some marketing type said
"you have to or we won't sell any" is neither engineering nor science
and has no place in Computer Science or the Art of Comptuer Programming.
(And for the record, no marketing person I've ever encountered who
said something like that had the slightest clue about either the
technology or the *market*.  It has always amazed me how much
the story is different when you bypass marketing and talk to the
customer directly.)  (And don't get me started on "Software Engineering."
That's a whole 'nother soapbox I don't have time for today.)

> May be I've studied too much history and may be I've studied too much
> psychology, but, I think the only way for things to change for the better,
> is for what we have now to collapse. I do hope I'm wrong.

I hope you are too, but I must admit that I've often had the
same thought.

It's been observed, even semi-rigorously that the set of programmers
falls into a bi-modal distribution with a small group that's about
an order of magnitude better than the large group, and very little
in between.  When you probe into these bizzare techniques, tools,
processes, etc, the rationale always seems to boil down to preventing
the large, lower calibre group from doing too much damage, and
to allow them to have a modicum of productivity.  Unfotunately,
the tyrany of the majority seems to prevent the examples of the Kens
and Dennises of the world from guiding the progress of the art.  I
have a hard time envisioning how to make it better short of some
kind of collapse that quashes the majority.  In the mean time, I
just try to hide away in a corner and affiliate mostly with the upper
node of the distribution.

But I should get back to real work.  So, I step down from the
soapbox again.

BLS

Re: [9fans] quote o' the day

[andrey mirtchovski]

in similar vein, there's this handful guide on how to make your life
really hard in 11 easy steps:

http://www.pixelbeat.org/docs/unix_file_replacement.html

make sure you check out the final copy.c linked at the bottom of the page

Re: [9fans] quote o' the day

[erik quanstrom]

> make sure you check out the final copy.c linked at the bottom of the page

don't follow this link.  it is a trojan that will eat
into your brain and turn it into grey goo.

☺
- erik

Re: [9fans] quote o' the day

[blstuart]

> in similar vein, there's this handful guide on how to make your life
> really hard in 11 easy steps:
>
> http://www.pixelbeat.org/docs/unix_file_replacement.html
>
> make sure you check out the final copy.c linked at the bottom of the page

It's a sign of the apocalypse.  The configuration of the 6th edition
kernel Lions presented was about 10,000 lines of code.  This version
of cp is nearly 1/4 of that, and the function copy_internal() is over
1000 lines long.  I'm clearly not smart enough to function in a world
where cp is that complex...

Back to real work...again...for real this time...I promise...
BLS

Re: [9fans] quote o' the day

[Francisco J Ballesteros]

As a example for our students we use

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb=HEAD

versus

http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c

In fact, we have both printed on paper hanging from the wall of the corridor
near our office. Let's hope they learn.


On Thu, Mar 25, 2010 at 7:51 PM,  <blstuart@bellsouth.net> wrote:
>> in similar vein, there's this handful guide on how to make your life
>> really hard in 11 easy steps:
>>
>> http://www.pixelbeat.org/docs/unix_file_replacement.html
>>
>> make sure you check out the final copy.c linked at the bottom of the page
>
> It's a sign of the apocalypse.  The configuration of the 6th edition
> kernel Lions presented was about 10,000 lines of code.  This version
> of cp is nearly 1/4 of that, and the function copy_internal() is over
> 1000 lines long.  I'm clearly not smart enough to function in a world
> where cp is that complex...
>
> Back to real work...again...for real this time...I promise...
> BLS
>
>
>

Re: [9fans] quote o' the day

[Patrick Kelly]

On Thu, 25 Mar 2010 18:17:30 -0300, Francisco J Ballesteros
<nemo@lsub.org> wrote:

> As a example for our students we use
>
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb=HEAD

I'm going to have nightmares tonight...

> versus
>
> http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c

Wait, nevermind  :)

Re: [9fans] quote o' the day

[Tim Newsham]

> As a example for our students we use
>
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb=HEAD
>
> versus
>
> http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c
>
> In fact, we have both printed on paper hanging from the wall of the corridor
> near our office. Let's hope they learn.

You should also add:
http://code.google.com/p/unix-jun72/source/browse/trunk/src/cmd/cat.s

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] quote o' the day

[Patrick Kelly]

On Thu, 25 Mar 2010 18:58:30 -0300, Tim Newsham <newsham@lava.net> wrote:

>> As a example for our students we use
>>
>> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb=HEAD
>>
>> versus
>>
>> http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c
>>
>> In fact, we have both printed on paper hanging from the wall of the
>> corridor
>> near our office. Let's hope they learn.
>
> You should also add:
> http://code.google.com/p/unix-jun72/source/browse/trunk/src/cmd/cat.s

When assembly is more readable than C... you know you've done something
wrong.
Oh wait, thats called a 'feature', silly me!

>
> Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
>


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] quote o' the day

[Justin Jackson]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Thu, Mar 25, 2010 at 4:21 PM, Patrick Kelly <kameo76890@gmail.com> wrote:
> On Thu, 25 Mar 2010 18:58:30 -0300, Tim Newsham <newsham@lava.net> wrote:
>
>>> As a example for our students we use
>>>
>>>
>>>
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb=HEAD
>>>
>>> versus
>>>
>>> http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c
>>>
>>> In fact, we have both printed on paper hanging from the wall of the
>>> corridor
>>> near our office. Let's hope they learn.

This is especially funny:
 398               /* Output a currency symbol if requested (-e).  */
 399
 400               if (show_ends)
 401                 *bpout++ = '$';
 402
 403               /* Output the newline.  */
 404
 405               *bpout++ = '\n';

[-- Attachment #2: Type: text/html, Size: 1251 bytes --]

Re: [9fans] quote o' the day

[erik quanstrom]

>  403               /* Output the newline.  */
>  404
>  405               *bpout++ = '\n';

oddly, for such an obvious comment, it's not
exactly what the code does, and somewhat misleading.
that code just puts a newline in a buffer and increments
a pointer.  outputting is elsewhere.

- erik

Re: [9fans] quote o' the day

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> You should also add:
> http://code.google.com/p/unix-jun72/source/browse/trunk/src/cmd/cat.s

Which returns 1062 lines of HTML+Javascript, completely unreadable
in Abaco.

The irony is stunning.

--lyndon

Re: [9fans] quote o' the day

[Anthony Sorace]

>> You should also add:
>> http://code.google.com/p/unix-jun72/source/browse/trunk/src/cmd/cat.s
>
> Which returns 1062 lines of HTML+Javascript, completely unreadable
> in Abaco.


not to spoil the irony, but that works here. it drops indentation, but
that
hardly qualifies as "completely unreadable".

Re: [9fans] quote o' the day

[Lyndon Nerenberg (VE6BBM/VE7TFX)]

> not to spoil the irony, but that works here.

And now it works here, too. Before I was getting a blank window, or
one line of "link ref=..." verbiage.

Now that I think of it, I was seeing similar behaviour last week from other
sites. I wonder if webfs is having problems ...

Re: [9fans] quote o' the day

[Tim Newsham]

>> http://code.google.com/p/unix-jun72/source/browse/trunk/src/cmd/cat.s
> Which returns 1062 lines of HTML+Javascript, completely unreadable
> in Abaco.
> The irony is stunning.

URL to the raw file; 50% less irony:
http://unix-jun72.googlecode.com/svn/trunk/src/cmd/cat.s

> --lyndon

Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com

Re: [9fans] quote o' the day

[andrey mirtchovski]

[-- Attachment #1: Type: text/plain, Size: 198 bytes --]

> URL to the raw file; 50% less irony:
> http://unix-jun72.googlecode.com/svn/trunk/src/cmd/cat.s

try as you might, the irony is unescapable (see the attached "helpful"
suggestion by google).

[-- Attachment #2: czech.png --]
[-- Type: image/png, Size: 38625 bytes --]

Re: [9fans] quote o' the day

[Jack Johnson]

On Fri, Mar 26, 2010 at 5:54 AM, andrey mirtchovski
<mirtchovski@gmail.com> wrote:
> try as you might, the irony is unescapable (see the attached "helpful"
> suggestion by google).

It sounds like a competition.

"Write a program that, when translated by Google into Czech, still
produces valid output."

-Jack

Re: [9fans] quote o' the day

[Corey Thomasson]

I wish I had that link the other day! Got into a debate about gnu cat
etc. With a member of the local LUG.

On Thursday, March 25, 2010, Tim Newsham <newsham@lava.net> wrote:
>
> As a example for our students we use
>
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb=HEAD
>
> versus
>
> http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c
>
> In fact, we have both printed on paper hanging from the wall of the corridor
> near our office. Let's hope they learn.
>
>
> You should also add:
> http://code.google.com/p/unix-jun72/source/browse/trunk/src/cmd/cat.s
>
> Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
>
>

Re: [9fans] quote o' the day

[hugo rivera]

2010/3/25 Francisco J Ballesteros <nemo@lsub.org>:
> In fact, we have both printed on paper hanging from the wall of the corridor
> near our office. Let's hope they learn.

This is a great idea. I think I'll copy it :-)

--
Hugo

Re: [9fans] quote o' the day

[Eris Discordia]

> In fact, we have both printed on paper hanging from the wall of the
> corridor near our office. Let's hope they learn.

Learn to...

1. ... not comment their code?

2. ... not include usage instructions?

3. ... not heed that their code might need to compile on any one of a 
number of platforms that are far from glitch-free?

4. ... not include a preamble introducing their file, automatically 
assuming they work in "clean environs" where nobody except people they know 
on a face-to-face basis commits to their code repository?

5. ... not accommodate their user base insisting they know better what's 
good for the users thereby dramatically cutting down the number of people 
who may want to merely use, and not hack, their code?

6. ... forget to see past appearances in others' code instead of simply and 
rationally counting the lines of code in the body of function 'simple_cat' 
for a proper comparison of equivalent functionality between a feature-heavy 
'cat' and a minimalist 'cat' each with its own merits?

7. ... avoid provisioning for a time when 'coreutils,' in order to become 
feature-heavy, will inevitably contain copious amount of code that needs to 
be amenable to automated testing and documentation?

8. ... avoid any secondary optimization of their first solution under the 
illusion that every optimization counts as the dreaded "premature 
optimization?"

9. ... condescendingly refuse to write or maintain code that is capable of 
cooperation with a dominant archaic design which can only be phased out 
gradually?

10. ... allow themselves to be flattered by agreement from the close-knit 
community of like-minded developers fully shutting their minds close to the 
potential merits of functionally rival software?


Never mind my trolling. I just needed to attention-whore. Continue, please.



--On Thursday, March 25, 2010 22:17 +0100 Francisco J Ballesteros 
<nemo@lsub.org> wrote:

> As a example for our students we use
>
> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb
> =HEAD
>
> versus
>
> http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c
>
> In fact, we have both printed on paper hanging from the wall of the
> corridor near our office. Let's hope they learn.
>
>
> On Thu, Mar 25, 2010 at 7:51 PM,  <blstuart@bellsouth.net> wrote:
>>> in similar vein, there's this handful guide on how to make your life
>>> really hard in 11 easy steps:
>>>
>>> http://www.pixelbeat.org/docs/unix_file_replacement.html
>>>
>>> make sure you check out the final copy.c linked at the bottom of the
>>> page
>>
>> It's a sign of the apocalypse.  The configuration of the 6th edition
>> kernel Lions presented was about 10,000 lines of code.  This version
>> of cp is nearly 1/4 of that, and the function copy_internal() is over
>> 1000 lines long.  I'm clearly not smart enough to function in a world
>> where cp is that complex...
>>
>> Back to real work...again...for real this time...I promise...
>> BLS
>>
>>
>>
>

Re: [9fans] quote o' the day

[hiro]

On 3/29/10, Eris Discordia <eris.discordia@gmail.com> wrote:
>> In fact, we have both printed on paper hanging from the wall of the
>> corridor near our office. Let's hope they learn.
>
> Learn to...
>
> 1. ... not comment their code?
>
> 2. ... not include usage instructions?
>
> 3. ... not heed that their code might need to compile on any one of a
> number of platforms that are far from glitch-free?
>
> 4. ... not include a preamble introducing their file, automatically
> assuming they work in "clean environs" where nobody except people they know
> on a face-to-face basis commits to their code repository?
>
> 5. ... not accommodate their user base insisting they know better what's
> good for the users thereby dramatically cutting down the number of people
> who may want to merely use, and not hack, their code?
>
> 6. ... forget to see past appearances in others' code instead of simply and
> rationally counting the lines of code in the body of function 'simple_cat'
> for a proper comparison of equivalent functionality between a feature-heavy
> 'cat' and a minimalist 'cat' each with its own merits?
>
> 7. ... avoid provisioning for a time when 'coreutils,' in order to become
> feature-heavy, will inevitably contain copious amount of code that needs to
> be amenable to automated testing and documentation?
>
> 8. ... avoid any secondary optimization of their first solution under the
> illusion that every optimization counts as the dreaded "premature
> optimization?"
>
> 9. ... condescendingly refuse to write or maintain code that is capable of
> cooperation with a dominant archaic design which can only be phased out
> gradually?
>
> 10. ... allow themselves to be flattered by agreement from the close-knit
> community of like-minded developers fully shutting their minds close to the
> potential merits of functionally rival software?
>
>
> Never mind my trolling. I just needed to attention-whore. Continue, please.
>
>
>
> --On Thursday, March 25, 2010 22:17 +0100 Francisco J Ballesteros
> <nemo@lsub.org> wrote:
>
>> As a example for our students we use
>>
>> http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cat.c;hb
>> =HEAD
>>
>> versus
>>
>> http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/cat.c
>>
>> In fact, we have both printed on paper hanging from the wall of the
>> corridor near our office. Let's hope they learn.
>>
>>
>> On Thu, Mar 25, 2010 at 7:51 PM,  <blstuart@bellsouth.net> wrote:
>>>> in similar vein, there's this handful guide on how to make your life
>>>> really hard in 11 easy steps:
>>>>
>>>> http://www.pixelbeat.org/docs/unix_file_replacement.html
>>>>
>>>> make sure you check out the final copy.c linked at the bottom of the
>>>> page
>>>
>>> It's a sign of the apocalypse.  The configuration of the 6th edition
>>> kernel Lions presented was about 10,000 lines of code.  This version
>>> of cp is nearly 1/4 of that, and the function copy_internal() is over
>>> 1000 lines long.  I'm clearly not smart enough to function in a world
>>> where cp is that complex...
>>>
>>> Back to real work...again...for real this time...I promise...
>>> BLS
>>>
>>>
>>>
>>
>
>
>
>
>
>

Without reading your post:
No,

just ... that sometimes less is more.

Re: [9fans] quote o' the day

[Connor Lane Smith]

Sorry if I'm feeding the troll, but...

On 29 March 2010 00:05, Eris Discordia <eris.discordia@gmail.com> wrote:
> 1. ... not comment their code?

Comments lie. Code can't. Hence clarity of code is better than commented theses.

> 2. ... not include usage instructions?

$ man cat

> 4. ... not include a preamble introducing their file, automatically assuming
> they work in "clean environs" where nobody except people they know on a
> face-to-face basis commits to their code repository?

It can be identified by its filename.

> 5. ... not accommodate their user base insisting they know better what's
> good for the users thereby dramatically cutting down the number of people
> who may want to merely use, and not hack, their code?

Every user wants something different and incompatible. One cannot
accomodate them all.

> 6. ... forget to see past appearances in others' code instead of simply and
> rationally counting the lines of code in the body of function 'simple_cat'
> for a proper comparison of equivalent functionality between a feature-heavy
> 'cat' and a minimalist 'cat' each with its own merits?

A feature-heavy 'cat' has no merits beyond the minimalist 'cat'. If
you want more features, write a new program. See: cat -v considered
harmful.

> 7. ... avoid provisioning for a time when 'coreutils,' in order to become
> feature-heavy, will inevitably contain copious amount of code that needs to
> be amenable to automated testing and documentation?

See above. A program becoming feature-heavy is a failure in and of
itself. Less is more.

> 8. ... avoid any secondary optimization of their first solution under the
> illusion that every optimization counts as the dreaded "premature
> optimization?"

Simplicity is more important than efficiency. Optimisation should only
be done when there is an identifiable bottleneck. Cat has no such
bottleneck that I'm aware of.

> 9. ... condescendingly refuse to write or maintain code that is capable of
> cooperation with a dominant archaic design which can only be phased out
> gradually?

Why does it have to be phased out gradually? The problems of Unix are
too deep to fix.

> 10. ... allow themselves to be flattered by agreement from the close-knit
> community of like-minded developers fully shutting their minds close to the
> potential merits of functionally rival software?

If it's better for the system's users, it's better for the system's users.

Again, sorry.

cls

Re: [9fans] quote o' the day

[hiro]

On 3/25/10, blstuart@bellsouth.net <blstuart@bellsouth.net> wrote:
> It's this kind of intellectual ugliness that makes the
> teacher in me hang my head in shame.  How could
> we be managing to produce a whole generation of
> programmers who actually buy into that stuff?  And
> it's not as if it's a fad that's getting better.  If anything
> it's getting worse.  Somehow we've made it laudible
> to go to any lengths to avoid writing a line of real
> code and to run as far away from hardware as we
> can.  That and worship at the alter of "code reuse"
> have created a world where if one abstraction is
> good, then 432 must be better.  If a symbol appears
> that's not defined in 17 different places all surrounded
> by #ifdef's, then that's not "professional."  Everyone
> is afraid to point out the nudity of the XML monarch
> for fear of being branded as one afraid of change.
>
> I humbly extend my apologies for any of this that
> might have been promulgated by any of my former
> students :(
>
> \end{soapbox}
>
> BLS
>
>
>

Hurts! He wants to know if it hurts!