It is not really binary compatible, but protocol compatible.
Right you are. But note that binary compatibility goes back to the original release of X11R6, which happened in April or May of 1994, if I remember correctly. That's assuming you still compile against the same C library, of course - and most of us moved away from libc4 some time ago.
Maintaining compatability is just as simple (OK a bit less since it is a complex protocol, but the
extention mechanism was very clever)
Agreed.
as backwards compatability for ftp,nntp,dns etc.
Note that SMTP, FTP and HTTP have nice extension mechanisms as well. (SMTP: the ESMTP EHLO response lists all supported extensions. FTP: the HELP command lists all available server commands. HTTP: you can do just about anything you want with extra headers / header flags.) I don't know about NNTP (probably a similar extension mechanism to SMTP) or DNS.
By utilizing a single, underlying library for these things, problems like these would disappear. I don't
see anything wrong in all applications behaving the same - a consistent user experience can't be bad.
OK. Now. It's your job to convince all the GTK+ and GNOME hackers that they should all start programming in C++ instead of the half-dozen languages they currently use, so that they can use the Qt toolkit. Obviously this requires a complete rewrite of all the GTK+ programs they currently have. To make this an easier pill for them to swallow, you should mention that they will also have the wonderful opportunity to rethink their component model, their a11y model, their i18n model, their UI generation method (for those who use Glade), and so forth.
Alternately, you can convince all those silly KDE hackers that their applications should all be rewritten to use GTK+ and the GNOME libraries. Similar to above, but reactions will probably be even more amusing.
Keep in mind, here, that these are the same people who are so flexible and open-minded that they hacked on KDE for literally years while Qt was available only with a non-GPL-compatible license (and KDE is GPL-licensed), which created the interesting situation where KDE was illegal to distribute at all. While some KDE hackers acknowledged this discrepancy, they didn't want to look bad so they refused even to add a license clause to KDE to allow it to be distributed with its Qt bindings. This would have been a simple exception clause - two lines at most. Instead, they (by implication) refused to allow anyone to distribute their software. (Many parties such as Caldera and Red Hat just "looked the other way" and distributed it anyway - strict license compliance took a back seat to customer demand.)
I mention the license difficulty not to reopen long-dead flame wars [oops, I probably did already] - because indeed the situation resolved itself admirably when Troll Tech relicensed Qt to the GPL - but to show the extreme loyalty these people have shown towards Qt, despite its former legal issues.
A third option is for you to do all the necessary porting work to move all your favorite applications to a single widget set / desktop framework. Pick whichever one you want, though you might keep in mind that if you decide on Qt, you will have to rewrite a lot of stuff in C++. Of course, you're rewriting a lot of stuff either way....
This is true. If you require unity of vision, you need to look at a single-source lock-in solution. These days, that pretty much means Microsoft.
But it seems to me that that people who
develop tools for Linux are all suffering from Attention Deficit Disorder. They start projects and never
finish them!
Also true. A majority, perhaps even a vast majority, of open source projects are never finished - but then, by what definition of finished? Many projects are quite usable and IMO could be considered feature-complete, without ever hitting the magic "1.0". (My browser, links, is only at 0.96 but has been quite nice since the mid-0.80s.) Some projects get developed to the point of being feature-complete and reasonably bug-free, but never achieve the spit and polish expected by non-programmer users - since the developers are themselves interested in neither spit nor polish. Other projects never get to be actually usable, or never overcome major limitations in functionality.
Why can't they standardize on something as simple as command-line parameter prefixes? Is it a single
dash, or a double-dash, or something else?
You mean like the DOS/Windows world, where sometimes you use/OPTION, sometimes -OPTION, and the/OPTION usually comes after filename arguments, but occasionally before filenames, and the/OPTION is usually but not always case-insensitive, and usually a single command invocation can only handle a single filename argument, but a few tools can take a list of filenames, and tools that expect a filename usually do not, but occasionally do, have a default mode of operation for "no filename", and the filename itself usually, but not always, undergoes wildcard processing, and it is usually, but not always, necessary to quote filenames with spaces?
If you're looking for command-line consistency, you won't find it in Unix or in Windows. Perhaps the functions of the programs involved are too divergent to support a common "interface".
As to single-dash versus double-dash, it's historical. Double-dash exists because that way a program can unambiguously support long option names and option clustering. Programs for which option clustering is not as practical, like gcc, sometimes use a single dash with long option names.
I'd congradulate your sister but her email is messed up. help?
Hmmm, not sure... it's the right address, but I notice their servers don't accept VRFY or EXPN, and they refuse with 500 [command unrecognized] instead of 550 [access denied / service not available]. I think this is RFC821-compliant, but it's not common practice. Perhaps your mailer is trying to VRFY the address before sending, or something, and getting confused. Oh well, thanks for trying.
A programing keeping many zombies around is bad ettiquite for sure, but not really a problem.
Well, unless it's Solaris 2.2 which as I recall used to keep zombies around for no reason at all, eventually filling up your process table and forcing you to reboot, if something else didn't take the system down first. Which was also not exactly unheard-of. And to think, with that... unillustrious... introduction to Unix - I still turned out a Unix weenie.
I must be some sort of AD because any distractions at all will seriously mess me up. Closed room, no colleagues / games / TV / web access / etc seems to work best for me. The trouble is enforcing this sort of environment... for myself alone, never mind enforcing it for multiple people who work this way..
Oh yeah, large quantities of caffeinated and insanely-sugared beverages always helps.
Re:What about 'use' for students
on
GPL's Strength
·
· Score: 2
The students aren't copying, distributing, or making derivative works, unless installing it on a pc is
considering copying!?! I think MS is taking it too far.
Welcome to the world of "why all EULAs should be considered legally invalid". Many of us believe this. If you refuse to agree to an EULA, honestly, what can the company do to you? Tell you you don't have the right to make fair use of copyrighted material you have purchased? Apparently, Microsoft and most other off-the-shelf commercial software houses would like us all to believe they have this power.
Unfortunately, the courts would likely agree with them, if it ever came up... under what I like to call the Don't Rock The Boat doctrine. This basically states that if an industry, society or business model would be sufficiently disrupted by a logical ruling, the illogical status quo (or de facto status quo), regardless of how illogical, must be upheld. (That's an empyrical analysis, of course, not official doctrine.)
With an actual front-page article like this one, perhaps I can stop having to make this exact point [GPL gives rights, normal EULA takes away rights] every time someone demonstrates belief in the fallacy that the GPL is "just like an EULA", or the related fallacy that "GPL restricts actual use of a product".
Oh wait. I guess that would require people to read the article, now, wouldn't it? <sigh>
Now travel back a bit further to Chaucer (another English author). Now THAT is Old English.
Sorry, no, that is Middle English. Old English is even worse.
And pretty much NOBODY nowadays can read the original text without lessons in how to actually read it.
Lessons, or just a bit of practice. If you read it aloud it actually doesn't sound all that bad. It also helps to have a line-by-line translation to refer to for awhile until you get the hang of the common transformations.
As for the connection settings,
it is set up by default that way because if you are querying a Windows 2000 DNS/DHCP server, it supports
DDNS (as per RFC 2136). It only causes problems with UNIX servers.
Uhhh, it doesn't cause problems with Unix servers. Many Unix DNS servers support DDNS. And many of us disable it because we prefer for random, unauthenticated machines on our networks not to be messing with our DNS databases. Therefore we get lines in our syslog files saying that certain machines tried and failed to push a DNS update to our server. If we get too many such lines and become annoyed, we hunt down the Win2k machine in question and untick the box under advanced TCP/IP settings.
It only becomes a problem when too many of these machines try to hammer the same few servers, to no purpose. Believe me, if the root servers were running Win2k, the root server admins still wouldn't have enabled DDNS. It's not about platforms, except for the arguably stupid default in the client.
Do many firewalls have the capability to inspect outgoing DNS updates to deterimine if they are valid or
not? I'm no expert in firewalls, but I've not seen this capability.
As others have said, you can just block all outgoing DNS (port 53) and probably be fine - just let it through for your internal DNS cache servers. The only reason not to use your internal cache servers is for diagnostic purposes, or if you disagree with your netadmin about whose root servers to use.
But beyond that - these are updates here: if you don't untick a box in the advanced TCP/IP settings, it will try to send updates of all its vital stats to the nearest DNS servers. This is to emulate the old NetBIOS automagic dynamic network name service Microsoft is finally deprecating. (NetBIOS is no longer required, even for Windows networking - Win2k can now run SMB without NetBIOS, on port 445 I believe.)
Dynamic DNS updates should never need to be sent outside your firewall, except in some rather unusual situations. (And think about how easy it is to spoof DNS updates, unless you use DNSsec.) A firewall may not be able to distinguish between different types of DNS updates, but perhaps one could just block all updates.
(Damn, the window title is so pathethic.. "JPG Compression - The Bandwidth Saver". I demand a public
apology from Hemos)
That's the title? My browser shows "JPG Compression * The Bandwidth Saver". I guess either my browser doesn't know what character #150 is, or someone forgot to run demoronizer.
Although jpg compression is definitely helpful, the article forgets to mention that two image formats
are supported by all browsers. GIF being the second.
XBM being the first, right? (Not that I recommend using it for anything other than its quintessential web purpose: icons in directory listings.) Really, though, JPEG is supported by almost all browsers nowadays, except of course mine (links) which is text-only. The days of using GIF only because JPEG wasn't supported by NCSA Mosaic are past. We're fast approaching the day of using PNG, since it is finally supported by most of the commonly used browser versions.
There is little need for extensions what so ever when you are working in a graphical environment. The
GUI can assign icons to types [if someone hasn't already monopolized on that media type and got their
icon on the 'top].
Many Unix and MacOS fans laugh at the fact that Windows deduces file type by name, instead of by content. I really like having the file(1) command available, and I use it all the time, but categorizing things by file extension is much more efficient, for casual use. It's bad enough, when reading a directory listing in an NFS mount, for the kernel to have to run a stat(2) on each file to determine the elemental file type (file, dir, link, device, pipe, socket) - it would be much worse if my copy of ls(1) felt the need to read the first 512 bytes or so of each file, so it could colorise it properly.
Interestingly, Microsoft actually take a hybrid approach. Certain file extensions -.EXE,.ICO,.LNK,.CUR - prompt the explorer shell to look inside the file for more information on its true icon. Again, IMO a waste of bandwidth for network shares.
It's unfortunate that the JPEG format ends up being described as the JPG, due to DOS naming constraints.
Are we doom to see the usage of 3 name extension only in the future due to this lack of vision from the
early implementers?
(Side note - since you're getting pedantic about names, you probably mean the JFIF format, which features the JPEG family of codecs.)
I haven't looked at Windows XP (thank goodness) but at least through Windows 2000, Microsoft still uses only 8.3 names on the CD-ROM and floppies, and seems to do so in %SYSTEMROOT%. My private theory is that they know VFAT (aka long filename support for DOS filesystems) is still flaky by design and prone to corruption, so they avoid it for the really essential stuff.
Come to think of it, that doesn't really explain the CD-ROMs. They have had Joliet (aka long filename support for ISO-9660 CD-ROMs) for quite some time now.
It also doesn't explain why almost all MSFT shops still write.htm pages when the whole Unix world has used.html from the beginning. I guess that one is just plain stubbornness / momentum. (:
At least everyone has settled on.class as the extension of choice for Java - even in the Windows world. Perhaps there is hope. Oh wait - Java is Microsoft's Public Enemy #1. Coincidence? (:
I would probably use.png instead of.gif though since it doesn't have
all the patent problems:)
That's a good reason, but how about the fact that PNG uses a better compression algorithm (flate versus LZW) and has more features (superior interlace options, full alpha channel) - there are non-idealogical reasons to switch. The one disadvantage of PNG is that some older browsers don't fully support it. (That was a reason not to switch to JPEG, back in the day. Old versions of NCSA Mosaic didn't support it.)
i often use it to install 30+ apps after i reformat my windows partition...
You, my friend, don't need a faster CD-ROM drive. You need a more stable OS. I can't imagine "often" reinstalling my OS - what a colossal waste of time....
i use it to load packages for mandrake...
Broadband is nice. I rarely use my CD-ROM to install software, since 'apt-get' directly off HTTP is almost as fast, and a lot more convenient. I don't know if Linux Mandrake has an equivalent, come to think of it. It must, though, since otherwise everyone would have switched to Debian or Conectiva by now.
The GPL does not prevent you from using software that you get
Only for really, really tiny values of "using" that don't include incorporating the code into a
non-GPL-licensed codebase. It's entirely unrealistic for you to say that simply dumping those
theoretical "swoopty file compression routines" into another product as an external binary is a viable
use of that code.
And you, in turn, are using a really, really tiny value of "using" that assumes every company sells software. Think about it. What percentage of companies out there are producers of software, and what percentage are consumers? Answer: I don't know about producers, but consumers comprise pretty much 100% of businesses.
So for most of those companies out there, who would like to use, say, a neat new government-funded word processor... and all of whom pay taxes... the ability to reuse the code in their own proprietary software is not at all useful. On the other hand, consider the benefits of using the GPL to attract developers to improve the program while keeping it free.
Depending on how literal
a view you take of the GPL, they're probably blocked from even looking at it to see how it works so they
can better design their own compression routines.
No, that would be depending on the view you take to the legal doctrine of derivative works. The GPL says nothing about looking at code and getting ideas - unlike some proprietary software licenses and NDAs. As far as I have ever seen, all authors of GPL code have taken the stance that this would not be infringing - thus making a lawsuit rather unlikely. Anyway, if you find copyright law to be ambiguous about this, it's not exactly the fault of the GPL.
Sheesh, I wish people like you would stop working for news media. I am a great supporter of the art of the pun, and the lame ones reporters always come up with really give the art a bad name. Please, oh please, can I read an article in InfoWorld about Java services that doesn't refer to some vendor "brewing" new solutions?
Would you happen to have any info about when Mozilla will be ported to GTK 2.0? In particular, is there
some development version for it already in cvs or somewhere?
Slashdot Mirror
Right you are. But note that binary compatibility goes back to the original release of X11R6, which happened in April or May of 1994, if I remember correctly. That's assuming you still compile against the same C library, of course - and most of us moved away from libc4 some time ago.
Agreed.
Note that SMTP, FTP and HTTP have nice extension mechanisms as well. (SMTP: the ESMTP EHLO response lists all supported extensions. FTP: the HELP command lists all available server commands. HTTP: you can do just about anything you want with extra headers / header flags.) I don't know about NNTP (probably a similar extension mechanism to SMTP) or DNS.
OK. Now. It's your job to convince all the GTK+ and GNOME hackers that they should all start programming in C++ instead of the half-dozen languages they currently use, so that they can use the Qt toolkit. Obviously this requires a complete rewrite of all the GTK+ programs they currently have. To make this an easier pill for them to swallow, you should mention that they will also have the wonderful opportunity to rethink their component model, their a11y model, their i18n model, their UI generation method (for those who use Glade), and so forth.
Alternately, you can convince all those silly KDE hackers that their applications should all be rewritten to use GTK+ and the GNOME libraries. Similar to above, but reactions will probably be even more amusing.
Keep in mind, here, that these are the same people who are so flexible and open-minded that they hacked on KDE for literally years while Qt was available only with a non-GPL-compatible license (and KDE is GPL-licensed), which created the interesting situation where KDE was illegal to distribute at all. While some KDE hackers acknowledged this discrepancy, they didn't want to look bad so they refused even to add a license clause to KDE to allow it to be distributed with its Qt bindings. This would have been a simple exception clause - two lines at most. Instead, they (by implication) refused to allow anyone to distribute their software. (Many parties such as Caldera and Red Hat just "looked the other way" and distributed it anyway - strict license compliance took a back seat to customer demand.)
I mention the license difficulty not to reopen long-dead flame wars [oops, I probably did already] - because indeed the situation resolved itself admirably when Troll Tech relicensed Qt to the GPL - but to show the extreme loyalty these people have shown towards Qt, despite its former legal issues.
A third option is for you to do all the necessary porting work to move all your favorite applications to a single widget set / desktop framework. Pick whichever one you want, though you might keep in mind that if you decide on Qt, you will have to rewrite a lot of stuff in C++. Of course, you're rewriting a lot of stuff either way....
Yeah - then people who want to catch a ride with Comet Hale-Bopp can actually do it!
This is true. If you require unity of vision, you need to look at a single-source lock-in solution. These days, that pretty much means Microsoft.
Also true. A majority, perhaps even a vast majority, of open source projects are never finished - but then, by what definition of finished? Many projects are quite usable and IMO could be considered feature-complete, without ever hitting the magic "1.0". (My browser, links, is only at 0.96 but has been quite nice since the mid-0.80s.) Some projects get developed to the point of being feature-complete and reasonably bug-free, but never achieve the spit and polish expected by non-programmer users - since the developers are themselves interested in neither spit nor polish. Other projects never get to be actually usable, or never overcome major limitations in functionality.
You mean like the DOS/Windows world, where sometimes you use /OPTION, sometimes -OPTION, and the /OPTION usually comes after filename arguments, but occasionally before filenames, and the /OPTION is usually but not always case-insensitive, and usually a single command invocation can only handle a single filename argument, but a few tools can take a list of filenames, and tools that expect a filename usually do not, but occasionally do, have a default mode of operation for "no filename", and the filename itself usually, but not always, undergoes wildcard processing, and it is usually, but not always, necessary to quote filenames with spaces?
If you're looking for command-line consistency, you won't find it in Unix or in Windows. Perhaps the functions of the programs involved are too divergent to support a common "interface".
As to single-dash versus double-dash, it's historical. Double-dash exists because that way a program can unambiguously support long option names and option clustering. Programs for which option clustering is not as practical, like gcc, sometimes use a single dash with long option names.
Hmmm, not sure ... it's the right address, but I notice their servers don't accept VRFY or EXPN, and they refuse with 500 [command unrecognized] instead of 550 [access denied / service not available]. I think this is RFC821-compliant, but it's not common practice. Perhaps your mailer is trying to VRFY the address before sending, or something, and getting confused. Oh well, thanks for trying.
Maybe they can put that in as an extra feature of the Ballmer dance DVD.
Well, unless it's Solaris 2.2 which as I recall used to keep zombies around for no reason at all, eventually filling up your process table and forcing you to reboot, if something else didn't take the system down first. Which was also not exactly unheard-of. And to think, with that ... unillustrious ... introduction to Unix - I still turned out a Unix weenie.
I must be some sort of AD because any distractions at all will seriously mess me up. Closed room, no colleagues / games / TV / web access / etc seems to work best for me. The trouble is enforcing this sort of environment ... for myself alone, never mind enforcing it for multiple people who work this way..
Oh yeah, large quantities of caffeinated and insanely-sugared beverages always helps.
Welcome to the world of "why all EULAs should be considered legally invalid". Many of us believe this. If you refuse to agree to an EULA, honestly, what can the company do to you? Tell you you don't have the right to make fair use of copyrighted material you have purchased? Apparently, Microsoft and most other off-the-shelf commercial software houses would like us all to believe they have this power.
Unfortunately, the courts would likely agree with them, if it ever came up ... under what I like to call the Don't Rock The Boat doctrine. This basically states that if an industry, society or business model would be sufficiently disrupted by a logical ruling, the illogical status quo (or de facto status quo), regardless of how illogical, must be upheld. (That's an empyrical analysis, of course, not official doctrine.)
With an actual front-page article like this one, perhaps I can stop having to make this exact point [GPL gives rights, normal EULA takes away rights] every time someone demonstrates belief in the fallacy that the GPL is "just like an EULA", or the related fallacy that "GPL restricts actual use of a product".
Oh wait. I guess that would require people to read the article, now, wouldn't it? <sigh>
Sorry, no, that is Middle English. Old English is even worse.
Lessons, or just a bit of practice. If you read it aloud it actually doesn't sound all that bad. It also helps to have a line-by-line translation to refer to for awhile until you get the hang of the common transformations.
Uhhh, it doesn't cause problems with Unix servers. Many Unix DNS servers support DDNS. And many of us disable it because we prefer for random, unauthenticated machines on our networks not to be messing with our DNS databases. Therefore we get lines in our syslog files saying that certain machines tried and failed to push a DNS update to our server. If we get too many such lines and become annoyed, we hunt down the Win2k machine in question and untick the box under advanced TCP/IP settings.
It only becomes a problem when too many of these machines try to hammer the same few servers, to no purpose. Believe me, if the root servers were running Win2k, the root server admins still wouldn't have enabled DDNS. It's not about platforms, except for the arguably stupid default in the client.
As others have said, you can just block all outgoing DNS (port 53) and probably be fine - just let it through for your internal DNS cache servers. The only reason not to use your internal cache servers is for diagnostic purposes, or if you disagree with your netadmin about whose root servers to use.
But beyond that - these are updates here: if you don't untick a box in the advanced TCP/IP settings, it will try to send updates of all its vital stats to the nearest DNS servers. This is to emulate the old NetBIOS automagic dynamic network name service Microsoft is finally deprecating. (NetBIOS is no longer required, even for Windows networking - Win2k can now run SMB without NetBIOS, on port 445 I believe.)
Dynamic DNS updates should never need to be sent outside your firewall, except in some rather unusual situations. (And think about how easy it is to spoof DNS updates, unless you use DNSsec.) A firewall may not be able to distinguish between different types of DNS updates, but perhaps one could just block all updates.
ITYM "Don't hate us, here's your Tolkien minority"
I'm-- no, wait, I'm not sorry.
And JPEG is the codec, not the file format. The file format is JFIF. Since we're talking about files here, better luck next time to you too. (:
That's the title? My browser shows "JPG Compression * The Bandwidth Saver". I guess either my browser doesn't know what character #150 is, or someone forgot to run demoronizer.
What browser do you use, anyway? I use links.
XBM being the first, right? (Not that I recommend using it for anything other than its quintessential web purpose: icons in directory listings.) Really, though, JPEG is supported by almost all browsers nowadays, except of course mine (links) which is text-only. The days of using GIF only because JPEG wasn't supported by NCSA Mosaic are past. We're fast approaching the day of using PNG, since it is finally supported by most of the commonly used browser versions.
Many Unix and MacOS fans laugh at the fact that Windows deduces file type by name, instead of by content. I really like having the file(1) command available, and I use it all the time, but categorizing things by file extension is much more efficient, for casual use. It's bad enough, when reading a directory listing in an NFS mount, for the kernel to have to run a stat(2) on each file to determine the elemental file type (file, dir, link, device, pipe, socket) - it would be much worse if my copy of ls(1) felt the need to read the first 512 bytes or so of each file, so it could colorise it properly.
Interestingly, Microsoft actually take a hybrid approach. Certain file extensions - .EXE, .ICO, .LNK, .CUR - prompt the explorer shell to look inside the file for more information on its true icon. Again, IMO a waste of bandwidth for network shares.
(Side note - since you're getting pedantic about names, you probably mean the JFIF format, which features the JPEG family of codecs.)
I haven't looked at Windows XP (thank goodness) but at least through Windows 2000, Microsoft still uses only 8.3 names on the CD-ROM and floppies, and seems to do so in %SYSTEMROOT%. My private theory is that they know VFAT (aka long filename support for DOS filesystems) is still flaky by design and prone to corruption, so they avoid it for the really essential stuff.
Come to think of it, that doesn't really explain the CD-ROMs. They have had Joliet (aka long filename support for ISO-9660 CD-ROMs) for quite some time now.
It also doesn't explain why almost all MSFT shops still write .htm pages when the whole Unix world has used .html from the beginning. I guess that one is just plain stubbornness / momentum. (:
At least everyone has settled on .class as the extension of choice for Java - even in the Windows world. Perhaps there is hope. Oh wait - Java is Microsoft's Public Enemy #1. Coincidence? (:
Heh, another TLA.
That's a good reason, but how about the fact that PNG uses a better compression algorithm (flate versus LZW) and has more features (superior interlace options, full alpha channel) - there are non-idealogical reasons to switch. The one disadvantage of PNG is that some older browsers don't fully support it. (That was a reason not to switch to JPEG, back in the day. Old versions of NCSA Mosaic didn't support it.)
You, my friend, don't need a faster CD-ROM drive. You need a more stable OS. I can't imagine "often" reinstalling my OS - what a colossal waste of time....
Broadband is nice. I rarely use my CD-ROM to install software, since 'apt-get' directly off HTTP is almost as fast, and a lot more convenient. I don't know if Linux Mandrake has an equivalent, come to think of it. It must, though, since otherwise everyone would have switched to Debian or Conectiva by now.
And you, in turn, are using a really, really tiny value of "using" that assumes every company sells software. Think about it. What percentage of companies out there are producers of software, and what percentage are consumers? Answer: I don't know about producers, but consumers comprise pretty much 100% of businesses.
So for most of those companies out there, who would like to use, say, a neat new government-funded word processor ... and all of whom pay taxes ... the ability to reuse the code in their own proprietary software is not at all useful. On the other hand, consider the benefits of using the GPL to attract developers to improve the program while keeping it free.
No, that would be depending on the view you take to the legal doctrine of derivative works. The GPL says nothing about looking at code and getting ideas - unlike some proprietary software licenses and NDAs. As far as I have ever seen, all authors of GPL code have taken the stance that this would not be infringing - thus making a lawsuit rather unlikely. Anyway, if you find copyright law to be ambiguous about this, it's not exactly the fault of the GPL.
Sheesh, I wish people like you would stop working for news media. I am a great supporter of the art of the pun, and the lame ones reporters always come up with really give the art a bad name. Please, oh please, can I read an article in InfoWorld about Java services that doesn't refer to some vendor "brewing" new solutions?
No clue.
Yeah, if (pw_uid != 1)) { printf("%s is an imposter", pw_gecos); }