Various Topics on Linux System Development

..n ..e..

http://www.newsforge.com/programming...6.shtml?tid=25


This has once been suggested a few times before on the Internet. I do
think it is a very good idea!

My main concern is with the quality of code being contributed to the
Linux Open Source pool. The applications works with small set of
features. When trying to compile it there are a warning messages flying
past the screen. This is true even with the Linux Kernel compile. This
suggests that:

-The Linux programmer only knows how to implement the function but does
not know the C programming language well. Their knowledge in pointer
usage, global variable usage, union, types and function parameters is not
good.

In Software Engineering cl***es it is a well know maxim, "You can prove
the presence of bugs but you cannot prove their absence." A clean
compile is atleast a lot better than a screen full of warning messages.
While that it may not prove the absence of bugs, it certainly is the
closest thing to reliablility.

Rewarding programmers to clean up the code is a great way to create a
robust OS and applications. A prize of $200 to clean up the code for
GNOME XYZ application OR Linux Network drivers, is a lot of money for a
programmer in India. Similar prizes could be setup to clean the code for
the kernel, KDE, OpenOffice etc.

The reward for any application/system should have a definite deadline and
should meet the code do***enting standards. It should have a basic
standard for the "Makefile" and compiler options. For example, the
"Makefile" should not have "2>&1 > /dev/null" for the file compile.

The Linux kernel 2.6 compile is a lot better. There are still tons of
warning messages that fly by the screen. Doesn't this raise the concern
about buffer overflow problems in those drivers or modules?

Accept it or not, the truth is that the Open Source developer will not
hang on to the same project for the rest of his/her life. If there is a
better opportunity he/she will leave their "baby" for the world to take
care of it. A crude analogy would be someone doing odd jobs for whatever
reason. Once there is a better opportunity, the odd job is history.
Open Source developing is more like an "odd" job for these programmers.
Whatever great things that they have contributed should be cleaned up.
With giving some financial reward it can be accomplished. For example
the GNOME's "Bounty" system is a great idea to add features to a product!

My personal observation (being a command line afficianado) is that the
Windows environment on Linux is so Bloated (with a capital "B"), it makes
Windows look like a great champ. Suddenly, using KDE apps or GNOME apps
on Linux doesn't seem to be too attractive. Besides when I tried to
build them there were tons of warning messages which does make me
nervous, for any possible buffer overflow problems.

"Paying developers to get features fast" is the way to go for Open Source
movement. "For the love of coding" is a temporary truth for the coder.
When reality hits with bills to pay, then that love is gone. The code
can be cleaned up by many other "C" linguists at a great deal. I am sure
that if a 1000 Linux users around the world give $1 each to clean up code
in the Linux Kernel or GNOME or KDE, then that is $1000 prize amount.
That is a LOT of money for a teenager in Germany or a small group of
progammers in India. Everyone benefits with this approach.

The "clean compile" should be demonstarted on atleast 5 major
distributions. That is the proof of some good work and money well
earned.

The required infrastructure is already in place. For example,
sourceforge.net is a great place to start.

This is a great article and people should pay more attention to it!

BT

..e.. ..ldow..

On Wed, 21 Jan 2004 21:41:54 GMT, Ben Theil <noname@nowhere.net>
wrote:

>
>
>http://www.newsforge.com/programming...6.shtml?tid=25

interesting article on how some software houses base their products on
existing Open Source, rather than starting from scratch.
>
>
>This has once been suggested a few times before on the Internet. I do
>think it is a very good idea!
>
>My main concern is with the quality of code being contributed to the
>Linux Open Source pool. The applications works with small set of
>features. When trying to compile it there are a warning messages flying
>past the screen. This is true even with the Linux Kernel compile. This
>suggests that:
>
>-The Linux programmer only knows how to implement the function but does
>not know the C programming language well. Their knowledge in pointer
>usage, global variable usage, union, types and function parameters is not
>good.
I disagree. Many linux developers come from the time where c used
integers for almost everything. What is seen by some as warnings is
seen by others as shortcomings of th compiler. It works, and works
well.
>
>In Software Engineering cl***es it is a well know maxim, "You can prove
>the presence of bugs but you cannot prove their absence." A clean
>compile is atleast a lot better than a screen full of warning messages.
>While that it may not prove the absence of bugs, it certainly is the
>closest thing to reliablility.
There are far better ways to show the reliability of code. Thorough,
do***ented testing is one that springs to mind.
>
>Rewarding programmers to clean up the code is a great way to create a
>robust OS and applications. A prize of $200 to clean up the code for
>GNOME XYZ application OR Linux Network drivers, is a lot of money for a
>programmer in India. Similar prizes could be setup to clean the code for
>the kernel, KDE, OpenOffice etc.
But then you still need a viable measure of the improvement. Anyone
can get rid of the compiler warnings... the tell you what they're
complaining about!
>
>The reward for any application/system should have a definite deadline and
>should meet the code do***enting standards. It should have a basic
>standard for the "Makefile" and compiler options. For example, the
>"Makefile" should not have "2>&1 > /dev/null" for the file compile.

You mean that the other way round??? Otherwise stderr is displayed on
stdout, and stdout is discarded.
>
>The Linux kernel 2.6 compile is a lot better. There are still tons of
>warning messages that fly by the screen. Doesn't this raise the concern
>about buffer overflow problems in those drivers or modules?
No, not at all.
>
>Accept it or not, the truth is that the Open Source developer will not
>hang on to the same project for the rest of his/her life. If there is a
>better opportunity he/she will leave their "baby" for the world to take
>care of it. A crude analogy would be someone doing odd jobs for whatever
>reason. Once there is a better opportunity, the odd job is history.
>Open Source developing is more like an "odd" job for these programmers.
>Whatever great things that they have contributed should be cleaned up.
>With giving some financial reward it can be accomplished. For example
>the GNOME's "Bounty" system is a great idea to add features to a product!
As most people currently develop because they want to, the code that
is generated is of a far higher quality than most commercial products,
where people develop what they're told. OK, real life gets in the way,
but you're never going to make a living out of it are you. So the
difference is between unpaid and paid work that you do in your spare
time. Which one will be of better quality???
>
>My personal observation (being a command line afficianado) is that the
>Windows environment on Linux is so Bloated (with a capital "B"), it makes
>Windows look like a great champ. Suddenly, using KDE apps or GNOME apps
>on Linux doesn't seem to be too attractive. Besides when I tried to
>build them there were tons of warning messages which does make me
>nervous, for any possible buffer overflow problems.
What is this correlation you have between compiler warnings and buffer
overflows??? Makes no sense to me.
>
>"Paying developers to get features fast" is the way to go for Open Source
>movement. "For the love of coding" is a temporary truth for the coder.
>When reality hits with bills to pay, then that love is gone. The code
>can be cleaned up by many other "C" linguists at a great deal. I am sure
>that if a 1000 Linux users around the world give $1 each to clean up code
>in the Linux Kernel or GNOME or KDE, then that is $1000 prize amount.
>That is a LOT of money for a teenager in Germany or a small group of
>progammers in India. Everyone benefits with this approach.
I don' want to use code cut by a teenager in Germany, or to have come
out of a software sweatshop in India or anywhere else for that matter.
>
>The "clean compile" should be demonstarted on atleast 5 major
>distributions. That is the proof of some good work and money well
>earned.
What! Do you mean at least 5 different compilers, or what? To compile
against different distros proves that all library calls are standard,
and nothing else ( major that I can think of at the moment! ).
>
>The required infrastructure is already in place. For example,
>sourceforge.net is a great place to start.
>
>This is a great article and people should pay more attention to it!
>
>BT

$0.02 from an old f*rt who's just been in the industry too long!

..n ..asur..

Ben Theil wrote:
> My main concern is with the quality of code being contributed to the
> Linux Open Source pool. The applications works with small set of
> features. When trying to compile it there are a warning messages flying
> past the screen. This is true even with the Linux Kernel compile. This
> suggests that:
>
> -The Linux programmer only knows how to implement the function but does
> not know the C programming language well. Their knowledge in pointer
> usage, global variable usage, union, types and function parameters is not
> good.
Not at all. Warnings are just that, warnings are not errors. Warnings do
not even mean errors in the code. They just alert you to the fact that
you need to keep an eye on certain parts of your code to make sure they
do what you want them to do.

Many code optimisations generate warnings but the programmer knows best,
and only the programmer can decide whether or not the code does what
he/she wants it to do, as always.

To suggest that a certain programmer doesn't know the ins and outs of
C/C++ because GCC threw some warnings is at best ignorant and offensive.

> In Software Engineering cl***es it is a well know maxim, "You can prove
> the presence of bugs but you cannot prove their absence." A clean
> compile is atleast a lot better than a screen full of warning messages.
Warning warn of *possible* problems. It gets it wrong sometimes.

Conversely, having no warning messages doesn't mean that your code has
fewer bugs.

> Rewarding programmers to clean up the code is a great way to create a
> robust OS and applications. A prize of $200 to clean up the code for
> GNOME XYZ application OR Linux Network drivers, is a lot of money for a
> programmer in India. Similar prizes could be setup to clean the code for
> the kernel, KDE, OpenOffice etc.
There are several points raised by that proposition, and here are just a
few I can think of:

How do you judge the "winner" of the prize? What happens to all the
other attempts at "clean code"? It sounds a lot like "You do such and
such, and I might pay you". Not very attractive, even to the poorest of
people.

Now you might say it would work similarly to how other software
competitions are done. The problem is, free-software programmers enjoy
writing free software because
a.) The software has never been written or thought possible before.
b.) The software gives them recognition of their programming skills.
c.) The software will forever have bug fixes and features added for as
long as people use it.
The lure of the competition is in the winning, not necessarily the
prize. The prize just increases the amount of time they are prepared to
spend on the project. Cleaning somebody else's code is about as
attractive as cleaning your neighbor's toilet.

Frequently, cleaning bad code means rewriting it. Rewriting code is the
same as making new code - there will be a whole other can of bugs,
pardon my pun. If it works leave it alone.

The alternative is to accept only clean code into the project. This is
very often the case with big projects with poor code being rejected or
rewritten before being accepted. Keeping a house clean is easier and
less chaotic than cleaning a dirty house.

> The reward for any application/system should have a definite deadline and
> should meet the code do***enting standards.
What do you mean by code do***enting standards? Since source code is
sufficiently varied in operation and purpose, you could at best have
guidelines for do***entation. These are out there, and are being used.

> It should have a basic standard for the "Makefile" and compiler options.
They do, and the "standards" are written in 'man makefile' and 'man
gcc'. If there is an option there, its because it is needed.

> The Linux kernel 2.6 compile is a lot better. There are still tons of
> warning messages that fly by the screen. Doesn't this raise the concern
> about buffer overflow problems in those drivers or modules?
No. Warnings don't always mean buffer overflows. Buffer overflows don't
always give warnings. Their relationship is virtually non-existent. I
say again, warnings don't always mean bad code.

> Accept it or not, the truth is that the Open Source developer will not
> hang on to the same project for the rest of his/her life. If there is a
> better opportunity he/she will leave their "baby" for the world to take
> care of it. A crude analogy would be someone doing odd jobs for whatever
> reason. Once there is a better opportunity, the odd job is history.
Whether or not a project is being actively maintained by its programmer
or not is inconsequential. Thats the beauty of GNU free software. If
somebody finds a bug or wants a new feature then they can and will add
it for themselves. The baby never dies unless nobody uses it, in which
case, who cares?

> Open Source developing is more like an "odd" job for these programmers.
Programmers don't develop free software because they have nothing better
to do! Believe it or not, they have lives that need living too. They
only take time to write free software for the reasons given above and
the freedom it gives programmers in general.

> Whatever great things that they have contributed should be cleaned up.
> With giving some financial reward it can be accomplished. For example
> the GNOME's "Bounty" system is a great idea to add features to a product!
Financial reward alone is not enough. You would have to guarantee them
more pay than their day jobs, and at around $100/hr the reward would
have to be astronomical.

GNOME's Bounty Hunt works because these are features that people want.
If you get paid for providing them then "whoo-hoo" but thats not why you
do them. Heck, some people even decline the winnings and put it back in
the fund!

> My personal observation (being a command line afficianado) is that the
> Windows environment on Linux is so Bloated (with a capital "B"), it makes
> Windows look like a great champ. Suddenly, using KDE apps or GNOME apps
> on Linux doesn't seem to be too attractive.
"...the Windows environment on Linux..."? I'll ignore that one...

I agree that graphical applications are bigger than text-only
applications. This is simply due to the sheer complexity of displaying
graphics, not because of poor/unnecessary code.

Now that harddisks are so cheap, there's no valid reason to spend vast
quantities of time for the sole purpose of making applications smaller.
Its time better spent squashing bugs.

> Besides when I tried to build them there were tons of warning messages
> which does make me nervous, for any possible buffer overflow problems.
Look, buffer exploits are few and far between in the grand scheme of
things. If you're really that concerned about them, just keep an eye on
the open-source security pages - the fixes are usually out only
hours/minutes of the problem being discovered.

> "Paying developers to get features fast" is the way to go for Open Source
> movement.
The "open source movement" isn't about features. Its about freedom. I
know it sounds cliched but not if you know the facts: www.gnu.org

> "For the love of coding" is a temporary truth for the coder.
> When reality hits with bills to pay, then that love is gone.
Coders have day jobs. These pay well. When the bills come, the love
keeps on showing.

> This is a great article and people should pay more attention to it!
Even I'm not conceited enough to claim this of mine. Though I do want
people to read it.

--
Ben M.

----------------
What are Software Patents for?
To protect the small enterprise from bigger companies.

What do Software Patents do?
In its current form, they protect only companies with
big legal departments as they:
a.) Patent everything no matter how general
b.) Sue everybody. Even if the patent can be argued
invalid, small companies can ill-afford the
typical $500k cost of a law-suit (not to mention
years of har***ment).

Don't let them take away your right to program
whatever you like. Make a stand on Software Patents
before its too late.

Read about the ongoing battle at http://swpat.ffii.org/
----------------

..ristoph.. ..ow..

Centuries ago, Nostradamus foresaw when Ben Measures <saint_abroadremove@removehotmail.com> would write:
> Ben Theil wrote:
>> My main concern is with the quality of code being contributed to the
>> Linux Open Source pool. The applications works with small set of
>> features. When trying to compile it there are a warning messages
>> flying past the screen. This is true even with the Linux Kernel
>> compile. This suggests that:
>> -The Linux programmer only knows how to implement the function but
>> does not know the C programming language well. Their knowledge in
>> pointer usage, global variable usage, union, types and function
>> parameters is not good.
> Not at all. Warnings are just that, warnings are not errors. Warnings
> do not even mean errors in the code. They just alert you to the fact
> that you need to keep an eye on certain parts of your code to make
> sure they do what you want them to do.
>
> Many code optimisations generate warnings but the programmer knows
> best, and only the programmer can decide whether or not the code does
> what he/she wants it to do, as always.
>
> To suggest that a certain programmer doesn't know the ins and outs of
> C/C++ because GCC threw some warnings is at best ignorant and
> offensive.

In the case of the Linux kernel, there are two interesting effects
that have to be thrown in:

1. The kernel programmers have been known to examine the ***embly
language generated by GCC, and to write code to produce the
desired effect.

2. The GCC team have been dueling with this somewhat, making the
compiler conform to _their interpretation_ of ANSI, ISO, and IEEE
standards. Which are not necessarily totally conformant with the
Linux kernel folks' understandings of those standards.

Keep in mind that there is room for interpretation of the C standards;
that there is not perfect agreement does _NOT_ establish that either
"camp" is necessarily wrong.
--
let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;
http://www.ntlug.org/~cbbrowne/linuxdistributions.html
<a href="http://www.netizen.com.au/">thorfinn@netizen.com.au</a>
Millihelen, adj:
The amount of beauty required to launch one ship.

..n ..asur..

Christopher Browne wrote:
> let name="cbbrowne" and tld="cbbrowne.com" in String.concat "@" [name;tld];;

ROFL! Dunno why but I find that hilarious!

--
Ben M.

----------------
What are Software Patents for?
To protect the small enterprise from bigger companies.

What do Software Patents do?
In its current form, they protect only companies with
big legal departments as they:
a.) Patent everything no matter how general
b.) Sue everybody. Even if the patent can be argued
invalid, small companies can ill-afford the
typical $500k cost of a law-suit (not to mention
years of har***ment).

Don't let them take away your right to program
whatever you like. Make a stand on Software Patents
before its too late.

Read about the ongoing battle at http://swpat.ffii.org/
----------------

..r.. ..rgol..

In article <oyHPb.390$4t2.79@news-binary.blueyonder.co.uk>,
Ben Measures <saint_abroadremove@removehotmail.com> wrote:

> > In Software Engineering cl***es it is a well know maxim, "You can prove
> > the presence of bugs but you cannot prove their absence." A clean
> > compile is atleast a lot better than a screen full of warning messages.
> Warning warn of *possible* problems. It gets it wrong sometimes.

Occasional warnings can be understood as anomalies. But if the screen
is full of them, as the OP said, this suggests sloppy coding. Even if
most of the warnings are benign, it's easy for the problematic ones to
get missed due to the volume. Also, if code generates a warning,
there's usually a simple modification that will generate equivalent code
but suppress the warning.

For instance, some compilers warn about code like:

if (<var> = <expression>) ...

on the ***umption that this is a common typo for:

if (<var> == <expression>) ...

Wrapping the ***ignment in an extra set of parentheses will shut the
compiler up, with absolutely no effect on the generated code.

Many programming organizations have standards that require code to
compile with no warnings, and it's usually possible to achieve this (if
a warning really can't be worked around, they may allow a supervisor or
senior programmer to allow the exception).

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

..e.. ..ldow..

On Thu, 22 Jan 2004 05:15:05 GMT, Barry Margolin <barmar@alum.mit.edu>
wrote:

>In article <oyHPb.390$4t2.79@news-binary.blueyonder.co.uk>,
> Ben Measures <saint_abroadremove@removehotmail.com> wrote:
>
>> > In Software Engineering cl***es it is a well know maxim, "You can prove
>> > the presence of bugs but you cannot prove their absence." A clean
>> > compile is atleast a lot better than a screen full of warning messages.
>> Warning warn of *possible* problems. It gets it wrong sometimes.
>
>Occasional warnings can be understood as anomalies. But if the screen
>is full of them, as the OP said, this suggests sloppy coding. Even if
>most of the warnings are benign, it's easy for the problematic ones to
>get missed due to the volume. Also, if code generates a warning,
>there's usually a simple modification that will generate equivalent code
>but suppress the warning.
>
>For instance, some compilers warn about code like:
>
>if (<var> = <expression>) ...
>
>on the ***umption that this is a common typo for:
>
>if (<var> == <expression>) ...
>
>Wrapping the ***ignment in an extra set of parentheses will shut the
>compiler up, with absolutely no effect on the generated code.
>
>Many programming organizations have standards that require code to
>compile with no warnings, and it's usually possible to achieve this (if
>a warning really can't be worked around, they may allow a supervisor or
>senior programmer to allow the exception).
I've worked for projects that...

a) demanded a comment per line of code
b) demanded flow charts for all functionality.

The former led to one or two sarcastic comments that the customer
picked up on and took exception ( ho ho ) to, and the latter much more
than doubled the length of the project.

Just because somebody requires it, doesn't make it worthwhile!

Steve

..r.. ..rgol..

In article <hqnu00d3tutt87k080f5cepfc85kopl9ii@4ax.com>,
Steve Holdoway <steve@itemfront.ltd.uk> wrote:

> Just because somebody requires it, doesn't make it worthwhile!

Nor does it automatically make it worthless, either. Some programming
standards have a reasonable basis.

Warnings usually indicate that there's something wrong, or at least
suspicious. Even if you're sure they're benign, consider the plight of
the next developer to work on the code -- he'll have to go through all
the warnings, trying to figure out which can be ignored and which must
be resolved. The alternative is to blindly ignore all the warnings, in
which case you have a "boy who cried 'wolf'" situation -- inevitably a
warning that should be heeded will come out, and it will be ignored.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

..sp.. ..po..

Barry Margolin wrote:
>
> In article <hqnu00d3tutt87k080f5cepfc85kopl9ii@4ax.com>,
> Steve Holdoway <steve@itemfront.ltd.uk> wrote:
>
> > Just because somebody requires it, doesn't make it worthwhile!
>
> Nor does it automatically make it worthless, either. Some programming
> standards have a reasonable basis.
>
> Warnings usually indicate that there's something wrong, or at least
> suspicious. Even if you're sure they're benign, consider the plight of
> the next developer to work on the code -- he'll have to go through all
> the warnings, trying to figure out which can be ignored and which must
> be resolved. The alternative is to blindly ignore all the warnings, in
> which case you have a "boy who cried 'wolf'" situation -- inevitably a
> warning that should be heeded will come out, and it will be ignored.

In most cases you can get rid of a warning with just a
minor code cleanup. There are of course cases, where a
warning generated for perfectly good code cannot
easilly be surpressed. For example warning about unused
function arguments is reasonable, if the argument
really isn't necesarry, it shouldn't be there at all.
In that case you could remove the argument from the
function and all callers. Of course there are exceptions.
It might be that the argument is required because of the
API being used in which case you can't simply get rid of
the warning.

--
Kasper Dupont -- der bruger for meget tid paa usenet.
For sending spam use mailto:aaarep@daimi.au.dk
/* Would you like fries with that? */

..r.. ..rgol..

In article <400F7448.E48C741E@daimi.au.dk>,
Kasper Dupont <kasperd@daimi.au.dk> wrote:

> In most cases you can get rid of a warning with just a
> minor code cleanup. There are of course cases, where a
> warning generated for perfectly good code cannot
> easilly be surpressed. For example warning about unused
> function arguments is reasonable, if the argument
> really isn't necesarry, it shouldn't be there at all.

This is all correct. But as I said earlier, these should generally be
infrequent. If the screen is full of warnings, it's unlikely that all
of them are the ones that you can't easily suppress. 1-5 warnings per
program is probably not a big deal, but if there are dozens of them you
should do something about it.

Since we're talking about open source software, it's likely that other
people will be compiling your code when they install it. Lots of
warnings can have an impact on your reputation. And even if you don't
care about that, I expect that many of those users will send bug reports
asking whether the warnings are OK, and you'll have to deal with them.
So taking a little time to get rid of the warnings during development
can have some direct payoff later.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***