Linux-Advocacy Digest #26, Volume #27            Sun, 11 Jun 00 14:13:05 EDT

Contents:
  Re: Open Source Programmers Demonstrate Incompetence (mlw)
  Re: Linux advocate trapped inside a Windows Box (Terry Porter)
  Re: Open Source Programmers Demonstrate Incompetence (Christopher Browne)
  Re: Open Source Programmers Demonstrate Incompetence (Christopher Browne)
  Re: W2K BSOD's documented *not* to be hardware (Was: lack of goals. (Bart Oldeman)
  Re: No need to take sides (WhyteWolf)
  Re: Linux Game Available (Mark S. Bilk)
  Re: Linux newbie requires advice..... ("Tim")
  Re: Dealing with filesystem volumes (B'ichela)

----------------------------------------------------------------------------

From: mlw <[EMAIL PROTECTED]>
Subject: Re: Open Source Programmers Demonstrate Incompetence
Date: Sun, 11 Jun 2000 12:59:09 -0400

"[EMAIL PROTECTED]" wrote:
> 
> On Sun, 11 Jun 2000 09:35:15 -0400, mlw <[EMAIL PROTECTED]> wrote:
> 
> >This is actually a fairly decent debug routine. A 4k limit is not
> >uncommon. I think (if I remember correctly) the Windows 386 executive
> >debug has a limit of 1k.
> 
> It is useful as a debug routine. I am not arguing its usefulness, I am
> arguing its implementation with a 4K limit. Any programmer who has any
> programming experience at all can code the routine with no limit at all.
> It's absolutely trivial to do.

Hold on sport, maybe so, but what's the point? It is unlikely a point of
failure. 4K is a pretty good length for debugging info. It does not call
malloc. It is a debug function, it should be as simple as possible.

> 
> >I am also baffled as to why the original poster claims it is not
> >documented. Any C/C++ programmer should know there is a limit.
> 
> Incorrect. Anybody who has been doing C/C++ for more than an hour can
> trivially make that routine work for an arbitrary length string. Only
> those new to C, will believe that there needs to be a limit.

You are missing the big picture in that it is a "debug" function, which
by necessity, should work under all but the most catastrophic
circumstances.

> 
> >Even if BUFLEN is in a header, a simple grep would find it. If this is an
> >example of where open source is badly written, I would take OSS over
> >commercial code, any day.
> 
> You appear to be missing "the big picture". The problem is not finding a
> tool to search for strings in files, but in identifying places where fixed
> limits exist. The string "BUFLEN" does not indicate the presence of a
> fixed limit of the function, nor does the absence of it mean that one is
> not present. How many projects have you worked on with at least 250,000
> lines? In these projects the function stack is pretty deep, often hovering
> around 10 or 20. Input is passed from here to Mars before it finally hits
> system calls. Fixed limits of any time are difficult to track down. It is
> not a matter of searching for strings in text files.

Again, you seem to be missing the issue of it being a debug function. It
should rely, as little as possible, on the the program being in a fully
operational state.

Also, the choice of vsnprintf over vfprintf makes sense if you
understand how printf works, and assume a file stream used for debugging
should not be buffered.

BTW: I have managed and coded many projects, well over 250k lines.

> 
> Most programmers typically have fixed size buffers all over the place,
> which do not indeed represent fixed sized limits for the function. As I
> said before BUFLEN-type constructs are used all over the place where there
> is no limit. Here is an example:
> 
> PROGRAM_STATUS read_in_file(FILE *fd, char **buffer, size_t *size)
> {
> #define BUFLEN 4096
> 
>     char buf[BUFLEN];
>     size_t rt;
> 
>     if (!fd || !buffer || !size)
>     {
>         return PROGRAM_E_INVPARM;
>     }
> 
>     *buffer = NULL;
>     *size = 0;
> 
>     while ((rt = fread(&buf[0], 1, BUFLEN, fd)) > 0))
>     {
>         if ((*buffer = realloc(*buffer, (*size) + rt)) == NULL)
>         {
>             return PROGRAM_E_INSVIRMEM;
>         }
> 
>         memcpy(*buffer + *size, &buf[0], rt);
> 
>         *size += rt;
>     }
> 
>     return PROGRAM_S_NORMAL;
> }

I would call this routine badly written. Why would you not read directly
into buffer? Why do you need to go through the data twice? Why would you
not make a few function calls to get file position and length and
reallocate the buffer upfront? Why would you even consider using a FILE
* when you want the whole file, an experienced developer would try to
use mmap.

In fact, this function is poorly designed to do its job. If its job is
to manage the memory into which a file will be read (the calls to
realloc mandate this). It should issue the original malloc call, or call
mmap and avoid using the heap. What if the called passes a stack based
buffer to this function? Talk about unexpected results. The example you
gave as bad, only cuts off characters on a debug string, your's could
corrupt the program's heap if used incorrectly.

In short, if you showed this to me as an example of code you would
write, I would not hire you. If I saw this in a production product, I'd
fire you.


-- 
Mohawk Software
Windows 9x, Windows NT, UNIX, Linux. Applications, drivers, support. 
Visit http://www.mohawksoft.com
Have you noticed the way people's intelligence capabilities decline
sharply the minute they start waving guns around?

------------------------------

From: [EMAIL PROTECTED] (Terry Porter)
Subject: Re: Linux advocate trapped inside a Windows Box
Reply-To: No-Spam
Date: 12 Jun 2000 01:09:14 +0800

On Sat, 10 Jun 2000 10:26:05 -0400,
 Secretly Cruel <[EMAIL PROTECTED]> wrote:
>On Sat, 10 Jun 2000 12:08:46 GMT, [EMAIL PROTECTED] wrote:
>
>>2.) My printer doesn't work!  I have a NEC SuperScript 870 (yes, one of
>>those not-quite-postscript lasers) but I love it, and can't afford a
>>true PS printer..
>
>I dunno... my printer is an el cheapo Canon BJC-4400 and it prints
>perfectly. IIRC, I paid less than $100 for the thing.
>
>>But when I sit down to my everyday system, I want the ol' comforts..
>>easy configuration, ready multimedia, and device support.
Ahh yes the ol' comforts, virii and "safe mode".

>>
>>Understand me--I DON'T want windows!  But I DO want to be able to admit
>>to myself that Linux isn't ready for my everyday workstation needs.
Then admit it to yourself, but you *won't* convince me, as Linux had been
doing all my workstation needs since 1997.

>>And if it isn't ready for me, the well-informed, experimental consumer,
>>I don't think it's ready for the average consumer.
If Linux isnt, what do you think is ?

Don't say Windows, cause thats utter nonsense. Its users live in fear of virii
, covert spying programs, installed by "free" Windows software, and their
system being rendered unbootable by the installation of new software.

 
>>
>>I know many of these problems can be attributed to problems arising
>>from issues such as lackluster driver support from device companies,
The Windows breakup will help fix that anomaly.

>>time and $$ it takes to make these things possible.  I know Linux has a
>>zealous (but not over-zealous.. :c) and talented following of
>>programmers and advocates.
>>
>>It just seems like some linux advocates like to sell the idea that the
>>OS is perfect for everyone...
More likely its the $$$ comercial interests of Linux, or Windows mags out
to make a quick buck, with a free Linux CD.

>>  But I think the OS is perfect for a
>>great many things, but maybe it doesn't NEED to be perfect for
>>everyone...
Once again what OS is perfect for everyone ?

>>
>>I dunno.. Go ahead and hammer me if you think I'm crazy, but at least
>>tell me why.
>
>You're exactly right. For the average user, Linux is not ready for
>prime time just yet. I'm pretty new at all this myself, having bought
>Redhat 5.2 several years ago.
Really ?
Considering Redhat was producing 4.2 in 1997, which was only 3 years ago
I find this a little innacurate.

> It was cryptic and confusing, and I gave
>up on it after a while.
My experience was totally different, in 1997 I installed Redhat4.2 first time
it ran my soundcard, printer, videocard, everything.
I was on the net in 20 Minutes, its STILL running here, *right now* as I type
this.

My 17 year old son, just installed  RedHat6.2, today. KDE, etc. He did it all
himself, including HDD partition with 2 hard disks. He installed it using 
a single boot floppy on his machine, and the RedHat CD in my machine, using
our in house network.

He's NEVER installed Linux before, and I did not help him in any way, I was too
busy chatting to a lady on IRC :)

He added WindowMaker to the XDM menu, and selected all the packages himself,
and it was done in about 4 hrs. Not bad for a first time, and a 17 year old.


> Then six months ago I bought Caldera 2.3 and
>was blown away by the ease of installation. Now I run Redhat 6.2 and
>Windows no longer lives on my machine. Linux is getting much, much
>better extremely quickly. Don't give up yet, just check back in
>another year or so. :-)
Linux may be ready for you NOW, don't wait a year, you'll only be a year behind
all your friends.



Kind Regards
Terry
--
**** To reach me, use [EMAIL PROTECTED]  ****
   My Desktop is powered by GNU/Linux, and has been   
 up 3 days 4 hours 11 minutes
** Registration Number: 103931,  http://counter.li.org **

------------------------------

From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Open Source Programmers Demonstrate Incompetence
Reply-To: [EMAIL PROTECTED]
Date: Sun, 11 Jun 2000 17:20:47 GMT

Centuries ago, Nostradamus foresaw a time when [EMAIL PROTECTED] would say:
>On Sun, 11 Jun 2000 09:35:15 -0400, mlw <[EMAIL PROTECTED]> wrote:
>
>>This is actually a fairly decent debug routine. A 4k limit is not
>>uncommon. I think (if I remember correctly) the Windows 386 executive
>>debug has a limit of 1k.
>
>It is useful as a debug routine. I am not arguing its usefulness, I am
>arguing its implementation with a 4K limit. Any programmer who has any
>programming experience at all can code the routine with no limit at all.
>It's absolutely trivial to do. 

This seems to me to be much ado about nothing.

In a logging routine, I'd be game to set a limit of 80 characters,
because I'd really rather be able to read the message on one line.

And if I'm planning to generate messages longer than that, I really
ought to plan them out so that there's _some_ sort of meaningful
layout for the hapless reader, that is likely _me_.

So, quite frankly, I disagree with the 4K limit; I'd really rather
that a debugging routine limit widths to something that is readily
readable, and a decent lowest common denominator for that is 80 bytes.

80 bytes isn't a common limitation _merely_ because punched cards had
that size; there are _good reasons_ for it, including that it fits
reasonably well as an inclusion in a document without reformatting.

>>I am also baffled as to why the original poster claims it is not
>>documented. Any C/C++ programmer should know there is a limit. 
>
>Incorrect. Anybody who has been doing C/C++ for more than an hour can
>trivially make that routine work for an arbitrary length string. Only
>those new to C, will believe that there needs to be a limit.

Whatever.

I'll be contrarian here and suggest that limiting things to sizes that
are human-readable will commonly be usefully convenient.

>>Even if BUFLEN is in a header, a simple grep would find it. If this is an
>>example of where open source is badly written, I would take OSS over
>>commercial code, any day.
>
>You appear to be missing "the big picture". The problem is not finding a
>tool to search for strings in files, but in identifying places where fixed
>limits exist. The string "BUFLEN" does not indicate the presence of a
>fixed limit of the function, nor does the absence of it mean that one is
>not present. How many projects have you worked on with at least 250,000
>lines? In these projects the function stack is pretty deep, often hovering
>around 10 or 20. Input is passed from here to Mars before it finally hits
>system calls. Fixed limits of any time are difficult to track down. It is
>not a matter of searching for strings in text files.

Which is why:
a) C probably needs to die, eventually.  
b) Same for C++.
c) Java is likely to be useful in helping there to be a new generation
   of programmers that do not hold to the doctrine of "automated
   memory management considered evil." 
d) Note that more dynamic languages like Python and Perl generally do
   not need to supply such restrictions...
-- 
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/>
"Usenet is like a herd of performing elephants with diarrhea; massive,
difficult to  redirect, awe-inspiring,  entertaining, and a  source of
mind-boggling amounts of excrement when you least expect it."  
-- Gene Spafford (1992)

------------------------------

From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: Open Source Programmers Demonstrate Incompetence
Reply-To: [EMAIL PROTECTED]
Date: Sun, 11 Jun 2000 17:20:49 GMT

Centuries ago, Nostradamus foresaw a time when [EMAIL PROTECTED] would say:
>On Sun, 11 Jun 2000 08:04:34 -0700, Jacques Guy <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] wrote:
>>
>>> You are a liar. I _never_ in that post said that closed source was better,
>>> or anything even remotely resembling that fact.  I was, in fact, very
>>> careful not to say that. Please re-read the post, critically this time.
>>
>>Well, what about the subject line:
>>    Open Source Programmers Demonstrate Incompetence
>>
>>In my books, and within my feeble command of the English language,
>>it implies that ...
>
>Obviously you are new to English. "Open Source Programmers Demonstrates
>Incompetence" says nothing about the competence of closed source
>programmers.

That is true.

Open Source provides a way of having a public evaluation of the
competence of any given programmer.

Closed Source prevents there from being such _public_ evaluations, and
if the producers of the software don't do the evaluations internally,
then no evaluation is ever done.

We don't know if the writers of Windows NT were competent, for
instance, because we can't look at the code to review its quality.
[Blue Screens of Death are pretty suggestive, mind you...]

I _know_ that:
a) Some of the programmers in Waldorf, Germany, who work on SAP R/3
   are pretty good, because I've seen some pretty good code here and
   there.

b) Some of those programmers who work on SAP R/3 are _pretty bad_,
   because I've read, and patched, some such code.

Open Source means "wearing the quality evaluation on your sleeve."
Generalizing about the quality is as stupid as generalizing about the
quality of "programs that run on Windows," because there are _wide_
variations in the quality of code that is produced.
-- 
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/>
"If God  meant us to be vegetarians  why'd He make cows  out of meat?"
-- seen on a bumper sticker

------------------------------

Crossposted-To: comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy
From: Bart Oldeman <[EMAIL PROTECTED]>
Subject: Re: W2K BSOD's documented *not* to be hardware (Was: lack of goals.
Reply-To: [EMAIL PROTECTED]
Date: Sun, 11 Jun 2000 17:43:21 GMT

On 11 Jun 2000, Tim Palmer wrote:

> Yes. You can even have graffics inside them! Lets' see an "X" DOS box do that!

http://www.dosemu.org/old/

Bart


------------------------------

From: [EMAIL PROTECTED] (WhyteWolf)
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: No need to take sides
Date: 11 Jun 2000 15:58:27 GMT

In article <8hve4g$mob$[EMAIL PROTECTED]>, Matt Chiglinsky wrote:
>
>
>It's only a computer.

no offence ... but thats alot like saying ... 
It's only a gun... 

of course it's a computer ... 
but it's used for more then the sum of it's 
parts ... and the advocacy groups are about flaming why 
this OS is better then that one about damn near everything



>
>
>That's all I have to say.

which automounted to a hill of beans?


-- 
-=-=-=-=-
Advice to young men: Be ascetic, and if you can't be ascetic,
then at least be asceptic.
-=-=-=-=-

------------------------------

From: [EMAIL PROTECTED] (Mark S. Bilk)
Subject: Re: Linux Game Available
Date: 11 Jun 2000 17:56:07 GMT

"James", if you consider the article to be spam, then why 
are you being so nasty to Simms, who has posted a total of 
three times, instead of to the following spammers, many of 
whom have posted *thousands* of articles each, in which 
they tell adverse lies about Linux, and try to convince 
people to buy Windows and other products from Microsoft?

Steve/Mike/Heather/Simon/teknite/keymaster/keys88/Sewer Rat/
"S"/Sponge/Sarek/piddy/McSwain/pickle_pete/Ishmeal_hafizi/etc. 
Drestin Black, Chad Myers, Erik Funkenbusch, Stephen Edwards, 
Chad Mulligan/boobaabaa, Jeff Szarka, Robert Moir, Brent Davies, 
Steve Sheldon, Boris, ubercat/Odin, Xerophyte/Kelly_Robinson, 
[EMAIL PROTECTED](newsguy.com), Cuor di Mela, etc.

In article <3943a7c3$0$[EMAIL PROTECTED]>,
James <[EMAIL PROTECTED]> wrote:
>Apologies.  Should have said "spambag".

>"Mark S. Bilk" <[EMAIL PROTECTED]> wrote in message
>news:8i04af$tqr$[EMAIL PROTECTED]...
>>"James", this nastiness is totally unwarranted.  Michael
>>Simms has posted only *twice* before, and makes a good case
>>for this particular commercial announcement.  The avail-
>>ability of games for Linux is an important factor for its
>>acceptance, and the number of games won't increase unless
>>some people buy them.

>>In article <3942a2af$0$[EMAIL PROTECTED]>,
>>James <[EMAIL PROTECTED]> wrote:
>>>Bugger off, scumbag!!!!!!!!!

>>>"Michael Simms" <[EMAIL PROTECTED]> wrote in message
>>>news:[EMAIL PROTECTED]...
>>>>Hi
>>>>
>>>>This is moderately advocacy-related so I am posting here
>>>>
>>>>Phantom EFX has produced a new game for Linux. This is 
>>>>their first game, and they are producing it in the same 
>>>>box for Linux and Windows.
>>>>
>>>>If they get a decent sales-level for it, then maybe 
>>>>their next game will be available for Linux also, but 
>>>>if it gets few sales, well, the chances are lower.
>>>>
>>>>The company is Phantom EFX, http://www.phantomefx.com
>>>>
>>>>The game is Reel Deal Slots, and is available from 
>>>>July 1st
>>>>
>>>>You can pre-order the game for $19.99 from
>>>>http://www.tuxgames.com/details.cgi?gameref=44&referrer=news
>>>>
>>>>Thanks
>>>>--
>>>>Tux Games - http://www.tuxgames.com
>>>>We supply the games that will distract you from working.



------------------------------

From: "Tim" <[EMAIL PROTECTED]>
Subject: Re: Linux newbie requires advice.....
Date: Sun, 11 Jun 2000 17:56:54 GMT

In article <[EMAIL PROTECTED]>, mlw <[EMAIL PROTECTED]>
wrote:
> 
> Second: avoid Corel like the plague, flip a coin between the other two.
> 

Why do you say this? I saw Corel at a roadshow and it looked ridiculously easy to 
install
and pretty slick as well.


------------------------------

From: [EMAIL PROTECTED] (B'ichela)
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Dealing with filesystem volumes
Date: Sun, 11 Jun 2000 13:17:28 -0400
Reply-To: [EMAIL PROTECTED]

On Sun, 11 Jun 2000 07:39:26 GMT, Quantum Leaper <[EMAIL PROTECTED]> wrote:
>You can't partition a floppy disk on a PC,  but my FD2000 (1.6meg) floppy
>drive on my C64/C128 could partition a floppy disk, into a multiply '1541',
>'1571' or '1581' or any combination up to 1.6Megs or use the whole disk.
>It even had subdirectories in native mode.
>
>
        Email me with what this Fd2000 for a C64 is. the biggest I
heard of is the 1581! (I have an old 1541 at my parents house along
with my C64c (old 64 croaked). Since it is off topic in Linux
Adavocacy email me with the info.
        To bring things back on topic. is there a way to plug a 1541
into a linux box? I would like to dload some software and I got an
extra 1571 here as I no longer have my 64 software librairy.


-- 

                        B'ichela


------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.advocacy) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Advocacy Digest
******************************

Reply via email to