The problem with the domain system is that it is a huge,
nearly flat namespace.
Just adding new TLD's to the current system
is a poor way of fixing its problems
(although it was a much better idea back when Jon
Postel first suggested it).
No company with a.com is going to willingly give it
up now.
Do you think Nissan Motors is going to settle for
"nissan.auto"?
Or that the fellow they're trying to take nissan.com from
is going to give it up for "nissan.name"?
There's only one way to level the playing field:
eliminate the current TLD's and force everyone (whether
corporation, organization, or individual) to choose a new
one from a reasonably large and comprehensive list.
There are various restictions that might rationalize
the system even more (e.g. restrict each entity to a
single 2nd-level name per TLD and use further levels to
subdivide, e.g. "suvs.nissan.auto") but I'm not sure such
regulation would be necessary (or desirable).
But one thing for sure: there is too much vested interest
in the current system for incremental changes to work.
I think there might be a problem with Linus' attitude.
He, and other kernel developers, have already
been informed that certain code probably violates
SGI's patents.
In fact, there is considerable public record of
this in the form of mailing list postings.
Given that he has received and acknowledged
this information, it is entirely possible that
a court would consider infringment to be willful
even if he refuses to verify the patents concerned.
Prior to this public discussion he probably could have
claimed that any infringment was innocent.
I think that he's lost the ability to make that claim.
IANAL, but IMHO Linus should be talking with one.
I understand his extreme frustration at a situation
that almost all of us agree is, at root, ridiculous.
But it's also unfortunately a serious situation as well.
He needs legal advice.
-Ed
Re:Finally, ABI stabilization. Now about optimizat
on
GCC 3.2 Released
·
· Score: 5, Informative
Bugs that come and go depending upon whether strict
aliasing rules are assumed or not are generally due
to broken code.
The C standard is quite explicit about when
aliasing is allowed and when it isn't.
(Aliasing is when there are two or more pointers to
the same region of memory.
This is generally OK if the pointers are of the same type,
or if an appropriate union is used.
Two pointers of different types pointing to the same
region of memory are generally veboten (char* is an
exception).)
The aliasing rules tend to be a source of trouble
since violating them was fairly common in pre-standard
days.
(The V6 Unix kernel used to use generic pointers --
like "register *p" -- just about everywhere,
something that is prohibited under ANSI.)
They exist to allow the compiler to optimize based on the
assumption that only pointers of the appropriate type
can be used to access a stored value, and thus that value
can be assumed to be unmodified (allowing redundant accesses to be
eliminated) in a larger number of cases.
A Google search on "C aliasing" will turn up a fair
amount of info on the subject.
-Ed
Re:Breaking interoperability... again???
on
GCC 3.2 Released
·
· Score: 3, Interesting
They also promised that the ABI was finished in 3.0.
In fact, that was one of the reasons given for taking so
long in getting 3.0 out the door.
Not a good track-record, IMHO.
Still, it will be good to get closer to standards-compliance.
C++ has been standardized for four years, now, and fully
compliant compilers are just now starting to appear.
GCC has actually been fairly good compared to some (cough,
Microsoft, cough) in adhering to the standard.
Neither my wife nor I liked the aesthetics of diamonds.
We just didn't think that they looked that good on her.
So we looked at other gemstones, and wound up with a
ruby set with three small diamonds.
The red and gold look great together, and match her
color preferences much better than a
gold-set diamond would.
Thirteen years later it still looks good, and she still
gets complements on it.
If you are thinking in terms of social statements -- whether
the social conventions concerning diamonds on the one hand
or the questionable ethics of their production on the other
-- you might be ignoring the fact the ring is jewelry, and
not just symbolism.
Sure, a big diamond has a lot of symbolic value now.
But that won't mean you and your wife will like the way it
looks five years from now.
It's been tried.
The problem was that people would ask for more
Masterpiece Theatre, but watch Baywatch anyway.
Face it, TV is a guilty habit for a lot of folks.
What you posted would have been more the case in the days when
the Big Three networks were all you had (assuming you
could even receive them all).
But with hundreds of channels on cable or satellite, people
have a pretty good chance of getting some of the stuff they
say they want, at least occasionally.
But guess what?
They don't watch it.
Everything from government subsidy to "public access"
channels has been tried to "improve" the quality and breadth
of TV programming.
And it hasn't worked.
The mean-spirited and outright nasty comments that have
gotten attached to every post mentioning Gene Kan's death
remind me of why I cringe every time Slashdot announces
that someone has died.
Although it would be nice for Slashdot to provide a place
for those of us touched by this tragedy to pay our
respects, I'm actually relieved that they haven't.
It would be painful to see all the trash that some of
the miscreant AC's who hang out here would post.
Yes, it's pretty primitive.
It appears to have been hacked together based on an exploit
that was published just a few days ago.
But there is little, other than greater vigilance on the
part of Apache webmasters (as opposed to IIS's) to prevent
a succession of worms that ultimately will rival in
sophistication and virulence anything
IIS has seen.
I thought it was pathetic how a couple hundred thousand IIS
servers stayed unpatched for so long, but it will be even
more pathetic if the same happens to Apache.
This is a chance for us to prove how much better open source
can handle these situations.
And I think there is a good chance that we will do just that.
But that means that the word has to be spread as far
as possible, not just to people who subscribe to Apache
mailing lists or who read the Apache section on a website
like Slashdot.
And, face it, there are plenty of people out there
running Apache who are two thoughts short of a clue.
You can criticize ignorant webmasters all you want, but
that doesn't change the fact that, for better or worse,
what they do (or don't do) will reflect on all of us.
I don't use Microsoft products.
I use Apache, at work and at home, on Linux and FreeBSD.
But I also recognize hypocrisy when I see it.
This is the Code Red of the Apache world.
So far as "News for Nerds. Stuff that matters" it's
more significant than 95% of what appears on the front
page.
CT and the Slashdot crew should hang their heads in shame.
Ah, so a banner that says "Sponsor Matches" above
such links along with
a link to a page describing just what sponsor matches are
isn't enough for you?
That's what Yahoo! does.
Actually, I found it "+1 Funny" but I didn't have any
moderator points.
Seriously, though, it looks like a good group,
one that will be a little more activist than the
last one, more likely to reign in some of the
petty weenie-waving that has happened of late
but not get overbearing about it.
Like my post said, SQL is largely derived from
SEQUEL, and the latter is the "more primitive predecessor" of the former; that's essentially the
relationship you describe.
And you're right about the reason for the name change
(though the odd thing is that the conflict was with the name
of an airplane -- IBM's lawyers must have been
paranoid in those days).
But we were discussing the name, and the
pronunciation of the name.
Check out the following document on the history of
SQL:
You'll note that the originators of SEQUEL/SQL
are very careful to use one term or the other
depending upon which point in time they're discussing.
That the name change corresponded to some pretty significant
additions to the language is probably why in circles outside
of the creator's group SEQUEL and SQL are
often treated as separate but related entities.
But whether or not they are the same language misses
the point: they are two different names, and as the
above article shows, SQL was named in the style of
other three-letter-languages of the era like APL
(by "squeezing the vowels out of SEQUEL"),
and was pronounced accordingly.
This is why old farts
(especially IBMers and ex-IBMers) are quick to correct
whippersnappers who pronounce it SEE kwell.
Although SQL is largely derived from it,
SEQUEL was the
query language of IBM's first Relational Data Base
Management System,
System/R, dating back to the mid-1970's.
(IBM's second --and current -- RDBMS was creatively
named DB2.)
So pedantic old farts like me are careful to distinguish
between the two and pronounce SQL as ess kyoo ell
to avoid confusing it with its more primitive predecessor,
SEQUEL (though it's not like there is any real chance
of confusion these days).
That's pretty much a non sequitur; capability-based
schemes can be a component (and a
particularly byzantine one, in my opinion) of a
security system.
But they aren't necessary for security.
They are just a way of implementing specific
security policies -- and you
can make the latter mountain as high as you want.
That doesn't have anything to do with FreeBSD's goals,
however, just as extreme "portability" is not a FreeBSD
goal.
What the EROS folks do is their own business.
As a footnote, I think the idea of trying to preserve
the Unix API in the face of such a radically un-Unix-like
security sceheme is a bit silly.
The object of finding bugs isn't to result in fewer bugs by fixing them. It's to result in fewer bugs by not writing them in the first place.
The developers need to review found bugs on a regular basis,
with the objective of changing development methods to
avoid them in the future.
It's all fine and good to say "don't write buggy code in the first place," but this sort of feedback is the only way to get there.
What makes this so hard in many organizations -- aside from the usual disrespect many developers have for QA people -- is that developers fear that this process is some sort of performance evaluation. As soon as this happens, the focus shifts from finding better processes to defending existing processes: "It's not really a bug," "There isn't really a better way of doing that," "We just don't have time to do it the 'right' way," and so on.
This is why the feedback needs to be direct from QA to the developers, who are then tasked to categorize bugs and develop recommendations for avoiding them. It's the latter that is the "product" required by management, not a list of bugs with developer's names on them. Management should otherwise get the hell out of the way.
Please
draw distinctions between webpages with news,
mindless link propagation, discussion sites, personal
diaries or journals, etc.
That's often a matter of opinion.
Anyone who's spent more than a fortnight
reading Slashdot knows this, unless they're
brain-dead -- it's all of these,
as are numerous other blogs and bloggish sites.
Gatespeed is LOS, which isn't what we're talking about here.
Check the article out for the differences.
And at $99/mo for 256Kbps, I don't think most folks would
consider them a bargain.
Sun's OS derived directly from BSD.
One of Sun's founders, Bill Joy (now their Chief Scientist),
was one of the primary developers of BSD and one of the
people responsible for getting BSD to run on the 68000
(which was the processor used in the first Suns).
At the time, Apollo didn't even run Unix, but rather
their own OS named "Domain."
To compete, Apollo modified Domain to support a Unix
emulation (including a switching
mechanism based on conditional symlinks).
Domain didn't die until HP bought Apollo,
though I believe they did ultimately port native Unix
to Apollos just before then.
-Ed
Re:nothing particularly groundbreaking about it
on
lowercase music
·
· Score: 1
Another nice thing about PD: it's Open Source, and it
runs on Linux.
In fact, it runs best on Linux.
If copyright laws are passe, then why is the GPL based
on copyright law?
That's right, the GPL, like any software license, tells
me what I can and cannot do with the software and I am
bound to follow that by copyright.
Otherwise, I could do whatever the hell I wanted to
with it.
Now what does this have to do with the RIAA/MPAA?
I believe people should be paid for their work,
but I also believe that there are far too many other
people who add little but take much as middlemen -- like
the RIAA and MPAA.
But they
are dinosaurs headed for extinction,
and I won't miss them a bit.
As for "supply->infinity,price->zero," that's simply
silly.
The dot-com bubble is over, and no one repealed
the laws of economics after all.
Even though the additional cost of a copy is
vanishingly small, you can't simply wish away the initial
costs of production no matter how many
copies are made.
Now, that hardly means that the Microsoft model for
software production is the only one -- far from it.
There has been a lot written about the
economics of free software, and as you note it can be much
more efficient in some circumstances.
But there are domains where it doesn't work so well
because production costs are high and the number of
likely end users low.
And those are the areas where commercial software will
continue to dominate.
Larry feels that sourcecode management software is one
of those domains where development costs are high
(even though his company is arguably about as lean as
a software company can get) but the market small.
I'm not so sure that's true if, as he claims,
the market is a million users, with most of those
users being software developers.
In fact, I'd think that Bitkeeper would be a pretty
good candidate for the free software model.
But Linus thinks it's the best tool for the job, and
that is more important to him than using only
GPL tools.
Only if it already exists. You can easily and ethically charge whatever the market will bear for writing it in the first place (or enhancing someone else's).
That only works for a minority of software.
It essentially means that the original purchaser has
to pay for the entire development, and all others pay
essentially nothing.
A fair amount of contract software could be done that way
since it is either highly specialized or is relatively
minor modification of existing software.
But the overwhelming number of desktop applications
reasonably couldn't
be developed with such a payment model.
I see it argued all the time that people are confusing
the two meanings of "free," and that the two concepts
don't have much to do with each other.
But that's not true.
When we're talking about software, libre
pretty much compels gratis.
It's easy to see why: if I attempt to charge more
than a pittance for my software you can simply get
a copy elsewhere.
The GPL doesn't oppose commercial software in so many
words, but is sets up such strong forces against the
commercialization of software that it can be considered
to do so.
It is disingenuous to say otherwise.
Now, Stallman may think that this particular downside
is ignorable compared to the virtues of
his particular codification
of "freedom," but others see things differently.
Interestingly, several highly qualified information security candidates I know haven't
even been able to get even contract work at the state.
I don't think you can read much into that.
Money for contact workers is the first thing to go in
a fiscal crisis.
(That even tends to be true at private companies,
especially if the companies are unionized.)
No, you don't have to patent.
But if someone else patents it, it will cost you
a bundle to have the patent voided.
A patent is thus cheap insurance.
Frankly, I think getting a patent and promising
royalty-free license (except to those who won't
do the same to you) makes a stronger statement
of principle than refusing to play the game.
But it remains to be seen if RH will do this...
The code should be written so that it is
clear what it does from the code itself.
Descriptive identifiers, well-focused classes and
single-purpose functions all help.
Careful use of white space (e.g. dividing code into
"paragraphs") helps.
If it isn't clear what the code does, rework it until it
is clear.
The code should be well-commented to explain
why it does what it does. Explain how it fits
into the overall scheme (and make sure you've
explained that scheme).
One way of doing this is to have a comment block
introduce each class and each function.
If these comments are not in a standardized format,
at least make them consistant.
If you're using a non-obvious algorithm,
this is where you should describe it, in full.
If it is spectacularly non-obvious, provide a reference
to a separate doc.
And if your project has created design documents prior
to coding, provide references back to those docs.
Obviously, the way code is "chunked" in item (1)
has a lot to do with how it gets documented in item (2),
and vice-versa; I put them in that order because it made
it easier to explain, though in practice much of (2) is
done before (1).
But the two have to be taken as a whole and ultimately
completed as a whole.
I don't know how many times I've seen comment-as-you-go
code where the comments disagreed with the code, and it
wasn't clear just what a function was trying to
accomplish.
But if I understand the goals of a piece of code, and
reasonable care has been taken in naming and
organizing it, in-line comments just get in the way.
Slashdot Mirror
The problem with the domain system is that it is a huge, nearly flat namespace. Just adding new TLD's to the current system is a poor way of fixing its problems (although it was a much better idea back when Jon Postel first suggested it). No company with a .com is going to willingly give it
up now.
Do you think Nissan Motors is going to settle for "nissan.auto"? Or that the fellow they're trying to take nissan.com from is going to give it up for "nissan.name"? There's only one way to level the playing field: eliminate the current TLD's and force everyone (whether corporation, organization, or individual) to choose a new one from a reasonably large and comprehensive list.
There are various restictions that might rationalize the system even more (e.g. restrict each entity to a single 2nd-level name per TLD and use further levels to subdivide, e.g. "suvs.nissan.auto") but I'm not sure such regulation would be necessary (or desirable). But one thing for sure: there is too much vested interest in the current system for incremental changes to work.
I think there might be a problem with Linus' attitude. He, and other kernel developers, have already been informed that certain code probably violates SGI's patents. In fact, there is considerable public record of this in the form of mailing list postings. Given that he has received and acknowledged this information, it is entirely possible that a court would consider infringment to be willful even if he refuses to verify the patents concerned. Prior to this public discussion he probably could have claimed that any infringment was innocent. I think that he's lost the ability to make that claim.
IANAL, but IMHO Linus should be talking with one. I understand his extreme frustration at a situation that almost all of us agree is, at root, ridiculous. But it's also unfortunately a serious situation as well. He needs legal advice.
Bugs that come and go depending upon whether strict aliasing rules are assumed or not are generally due to broken code. The C standard is quite explicit about when aliasing is allowed and when it isn't. (Aliasing is when there are two or more pointers to the same region of memory. This is generally OK if the pointers are of the same type, or if an appropriate union is used. Two pointers of different types pointing to the same region of memory are generally veboten (char* is an exception).)
The aliasing rules tend to be a source of trouble since violating them was fairly common in pre-standard days. (The V6 Unix kernel used to use generic pointers -- like "register *p" -- just about everywhere, something that is prohibited under ANSI.) They exist to allow the compiler to optimize based on the assumption that only pointers of the appropriate type can be used to access a stored value, and thus that value can be assumed to be unmodified (allowing redundant accesses to be eliminated) in a larger number of cases.
A Google search on "C aliasing" will turn up a fair amount of info on the subject.
They also promised that the ABI was finished in 3.0. In fact, that was one of the reasons given for taking so long in getting 3.0 out the door. Not a good track-record, IMHO.
Still, it will be good to get closer to standards-compliance. C++ has been standardized for four years, now, and fully compliant compilers are just now starting to appear. GCC has actually been fairly good compared to some (cough, Microsoft, cough) in adhering to the standard.
Neither my wife nor I liked the aesthetics of diamonds. We just didn't think that they looked that good on her. So we looked at other gemstones, and wound up with a ruby set with three small diamonds. The red and gold look great together, and match her color preferences much better than a gold-set diamond would. Thirteen years later it still looks good, and she still gets complements on it.
If you are thinking in terms of social statements -- whether the social conventions concerning diamonds on the one hand or the questionable ethics of their production on the other -- you might be ignoring the fact the ring is jewelry, and not just symbolism. Sure, a big diamond has a lot of symbolic value now. But that won't mean you and your wife will like the way it looks five years from now.
It's been tried. The problem was that people would ask for more Masterpiece Theatre, but watch Baywatch anyway.
Face it, TV is a guilty habit for a lot of folks. What you posted would have been more the case in the days when the Big Three networks were all you had (assuming you could even receive them all). But with hundreds of channels on cable or satellite, people have a pretty good chance of getting some of the stuff they say they want, at least occasionally. But guess what? They don't watch it.
Everything from government subsidy to "public access" channels has been tried to "improve" the quality and breadth of TV programming. And it hasn't worked.
The mean-spirited and outright nasty comments that have gotten attached to every post mentioning Gene Kan's death remind me of why I cringe every time Slashdot announces that someone has died. Although it would be nice for Slashdot to provide a place for those of us touched by this tragedy to pay our respects, I'm actually relieved that they haven't. It would be painful to see all the trash that some of the miscreant AC's who hang out here would post.
Goodbye, Gene.
Yes, it's pretty primitive. It appears to have been hacked together based on an exploit that was published just a few days ago. But there is little, other than greater vigilance on the part of Apache webmasters (as opposed to IIS's) to prevent a succession of worms that ultimately will rival in sophistication and virulence anything IIS has seen.
I thought it was pathetic how a couple hundred thousand IIS servers stayed unpatched for so long, but it will be even more pathetic if the same happens to Apache. This is a chance for us to prove how much better open source can handle these situations. And I think there is a good chance that we will do just that. But that means that the word has to be spread as far as possible, not just to people who subscribe to Apache mailing lists or who read the Apache section on a website like Slashdot. And, face it, there are plenty of people out there running Apache who are two thoughts short of a clue. You can criticize ignorant webmasters all you want, but that doesn't change the fact that, for better or worse, what they do (or don't do) will reflect on all of us.
(Time to blow some karma.)
Because it isn't IIS.
I don't use Microsoft products. I use Apache, at work and at home, on Linux and FreeBSD. But I also recognize hypocrisy when I see it. This is the Code Red of the Apache world. So far as "News for Nerds. Stuff that matters" it's more significant than 95% of what appears on the front page.
CT and the Slashdot crew should hang their heads in shame.
Ah, so a banner that says "Sponsor Matches" above such links along with a link to a page describing just what sponsor matches are isn't enough for you? That's what Yahoo! does.
Actually, I found it "+1 Funny" but I didn't have any moderator points.
Seriously, though, it looks like a good group, one that will be a little more activist than the last one, more likely to reign in some of the petty weenie-waving that has happened of late but not get overbearing about it.
Like my post said, SQL is largely derived from SEQUEL, and the latter is the "more primitive predecessor" of the former; that's essentially the relationship you describe. And you're right about the reason for the name change (though the odd thing is that the conflict was with the name of an airplane -- IBM's lawyers must have been paranoid in those days). But we were discussing the name, and the pronunciation of the name. Check out the following document on the history of SQL:
You'll note that the originators of SEQUEL/SQL are very careful to use one term or the other depending upon which point in time they're discussing. That the name change corresponded to some pretty significant additions to the language is probably why in circles outside of the creator's group SEQUEL and SQL are often treated as separate but related entities. But whether or not they are the same language misses the point: they are two different names, and as the above article shows, SQL was named in the style of other three-letter-languages of the era like APL (by "squeezing the vowels out of SEQUEL"), and was pronounced accordingly. This is why old farts (especially IBMers and ex-IBMers) are quick to correct whippersnappers who pronounce it SEE kwell.
SQL != SEQUEL
Although SQL is largely derived from it, SEQUEL was the query language of IBM's first Relational Data Base Management System, System/R, dating back to the mid-1970's. (IBM's second --and current -- RDBMS was creatively named DB2.) So pedantic old farts like me are careful to distinguish between the two and pronounce SQL as ess kyoo ell to avoid confusing it with its more primitive predecessor, SEQUEL (though it's not like there is any real chance of confusion these days).
That's pretty much a non sequitur; capability-based schemes can be a component (and a particularly byzantine one, in my opinion) of a security system. But they aren't necessary for security. They are just a way of implementing specific security policies -- and you can make the latter mountain as high as you want. That doesn't have anything to do with FreeBSD's goals, however, just as extreme "portability" is not a FreeBSD goal. What the EROS folks do is their own business.
As a footnote, I think the idea of trying to preserve the Unix API in the face of such a radically un-Unix-like security sceheme is a bit silly.
The object of finding bugs isn't to result in fewer bugs by fixing them. It's to result in fewer bugs by not writing them in the first place. The developers need to review found bugs on a regular basis, with the objective of changing development methods to avoid them in the future.
It's all fine and good to say "don't write buggy code in the first place," but this sort of feedback is the only way to get there. What makes this so hard in many organizations -- aside from the usual disrespect many developers have for QA people -- is that developers fear that this process is some sort of performance evaluation. As soon as this happens, the focus shifts from finding better processes to defending existing processes: "It's not really a bug," "There isn't really a better way of doing that," "We just don't have time to do it the 'right' way," and so on.
This is why the feedback needs to be direct from QA to the developers, who are then tasked to categorize bugs and develop recommendations for avoiding them. It's the latter that is the "product" required by management, not a list of bugs with developer's names on them. Management should otherwise get the hell out of the way.
Gatespeed is LOS, which isn't what we're talking about here. Check the article out for the differences. And at $99/mo for 256Kbps, I don't think most folks would consider them a bargain.
It's not well known, because it isn't true.
Sun's OS derived directly from BSD. One of Sun's founders, Bill Joy (now their Chief Scientist), was one of the primary developers of BSD and one of the people responsible for getting BSD to run on the 68000 (which was the processor used in the first Suns).
At the time, Apollo didn't even run Unix, but rather their own OS named "Domain." To compete, Apollo modified Domain to support a Unix emulation (including a switching mechanism based on conditional symlinks). Domain didn't die until HP bought Apollo, though I believe they did ultimately port native Unix to Apollos just before then.
Another nice thing about PD: it's Open Source, and it runs on Linux. In fact, it runs best on Linux.
"New Paradigm?" How quaint.
If copyright laws are passe, then why is the GPL based on copyright law? That's right, the GPL, like any software license, tells me what I can and cannot do with the software and I am bound to follow that by copyright. Otherwise, I could do whatever the hell I wanted to with it.
Now what does this have to do with the RIAA/MPAA? I believe people should be paid for their work, but I also believe that there are far too many other people who add little but take much as middlemen -- like the RIAA and MPAA. But they are dinosaurs headed for extinction, and I won't miss them a bit.
As for "supply->infinity,price->zero," that's simply silly. The dot-com bubble is over, and no one repealed the laws of economics after all. Even though the additional cost of a copy is vanishingly small, you can't simply wish away the initial costs of production no matter how many copies are made. Now, that hardly means that the Microsoft model for software production is the only one -- far from it. There has been a lot written about the economics of free software, and as you note it can be much more efficient in some circumstances. But there are domains where it doesn't work so well because production costs are high and the number of likely end users low. And those are the areas where commercial software will continue to dominate.Larry feels that sourcecode management software is one of those domains where development costs are high (even though his company is arguably about as lean as a software company can get) but the market small. I'm not so sure that's true if, as he claims, the market is a million users, with most of those users being software developers. In fact, I'd think that Bitkeeper would be a pretty good candidate for the free software model. But Linus thinks it's the best tool for the job, and that is more important to him than using only GPL tools.
That only works for a minority of software. It essentially means that the original purchaser has to pay for the entire development, and all others pay essentially nothing. A fair amount of contract software could be done that way since it is either highly specialized or is relatively minor modification of existing software. But the overwhelming number of desktop applications reasonably couldn't be developed with such a payment model.
I see it argued all the time that people are confusing the two meanings of "free," and that the two concepts don't have much to do with each other. But that's not true. When we're talking about software, libre pretty much compels gratis. It's easy to see why: if I attempt to charge more than a pittance for my software you can simply get a copy elsewhere.
The GPL doesn't oppose commercial software in so many words, but is sets up such strong forces against the commercialization of software that it can be considered to do so. It is disingenuous to say otherwise. Now, Stallman may think that this particular downside is ignorable compared to the virtues of his particular codification of "freedom," but others see things differently.
I don't think you can read much into that. Money for contact workers is the first thing to go in a fiscal crisis. (That even tends to be true at private companies, especially if the companies are unionized.)
No, you don't have to patent. But if someone else patents it, it will cost you a bundle to have the patent voided. A patent is thus cheap insurance.
Frankly, I think getting a patent and promising royalty-free license (except to those who won't do the same to you) makes a stronger statement of principle than refusing to play the game. But it remains to be seen if RH will do this...
One way of doing this is to have a comment block introduce each class and each function. If these comments are not in a standardized format, at least make them consistant. If you're using a non-obvious algorithm, this is where you should describe it, in full. If it is spectacularly non-obvious, provide a reference to a separate doc. And if your project has created design documents prior to coding, provide references back to those docs.
Obviously, the way code is "chunked" in item (1) has a lot to do with how it gets documented in item (2), and vice-versa; I put them in that order because it made it easier to explain, though in practice much of (2) is done before (1). But the two have to be taken as a whole and ultimately completed as a whole.
I don't know how many times I've seen comment-as-you-go code where the comments disagreed with the code, and it wasn't clear just what a function was trying to accomplish. But if I understand the goals of a piece of code, and reasonable care has been taken in naming and organizing it, in-line comments just get in the way.