Ah, but if you haven't disclosed the source, then you obviously didn't use the code under the terms of the GPL.
You were free to choose the GPL, but, since the software was not documented to be available under those terms, evidently you didn't.
As a result, the GPL terms don't apply, and since you didn't negotiate a contract for other terms, you must have felt amenable to the Big Bill License.
Registering the software with the appropriate office will lead to being able to demand triple "damages;" the problem is that of determining precisely what that amount should be.
On the one hand, the original software is being offered "free of charge," which means that one could assume that "damages" are $0.
On the other hand, the GPL is an interesting license in that it does not necessarily prevent the authors of software from simultaneously licensing under some other arrangement.
How about this for an entertaining scenario:
Software is licensed under the GPL;
If you want to use some other licensing arrangement, you can contact the authors to make an arrangement;
There is a default offer that if you do not offer the software explicitly under the GPL, and do not wish to contact the authors, you are free to deploy the software, At A Price.
That price (heh, heh!) being $50,000 USD payable to each author for the source license, plus $5,000 USD payable to each author for deployment of each binary copy of the software.
Thus, if the gentle folk in New Delhi (having been there recently, it is really just the "newer" part of Delhi:-)), in not making arrangements, they would start by oweing $50,000, trebled to $150K, plus a not inconsiderable sum based on the number of copies of the software sold:-).
The "each author" part would need to be more clearly nailed down; it would mean that the company making the mistake of "pirating" the Linux kernel would owe payments to (at recent count of /usr/src/linux/CREDITS) 293 people, thus making the penalties owing not too distant from $1B, and giving those 293 people a tidy sum of money:-).
... And if you store data using Ext2 filesystems, or ReiserFS filesystems, or BSD filesystems, or... ad infinitum, and don't mark blocks as protected, this prevents me from storing data on the disk precisely how?
I will certainly grant that this misfeature provides some wonderful exploits for the nefarious. After all, how long will it be before some hacker constructs a WinTel virus that marks the whole disk as being "copy protected," thereby rendering it into so much chaff from the perspective of anyone that was planning to actually store data on it.
Western Digital, Quantum, Seagate, and friends will be gloriously happy at that one; it's a wonderful opportunity to sell people more disk drives.
But as for the number of ways that this is a Spectacularly Stupid Idea, I'm not sure I have enough fingers and toes to cope with counting it... I'll probably need a Pentium processor, one without the FDIV bug, hopefully!
It provides performance roughly similar to "SCSI-3"; perhaps not quite UW-SCSI, but certainly better than SCSI-2.
And it takes only about 3-4 wires to use it, rather than the 50-odd wires you find in SCSI and IDE cables. THAT is a pretty big deal; that simplifies the building and layout of systems.
The really cool part would be to stick a whole lot of Serial-ATA interfaces onto a system; while it would be ludicrous to try to connect 6 SCSI cards to a PCI bus, as the attendant cabling for the potential 90 SCSI drives would be be frightening, and result in a system shaped like the star required to get those cables to go in 6 different directions, the simpler cabling of Serial-ATA might allow such a design to be much cleaner.:-).
It's certainly not as nice as the latest and fanciest SCSI standard, but if it makes plugging in an extra few drives a cheap and simple matter, that will suffice. SCSI is neither simple nor cheap.
(Note: The only SCSI variation that I don't have drives for, at this point, is the latest 80MB thing that just doubled "Ultra-Wide" bandwidth again.)
In contrast, it is not a "contribution" to buy a copy of Civ:CTP, however nice the folks at Loki are.
The thing that is most irritating about the whole "commercial games" thing is that there are so many middlecritters in between you and the producer of the game. If you pay $40 for a game, it is unlikely that Loki sees much more than $10, which makes this a pretty inefficient way of getting funding to them.
I've bought games (well, one game) from them, so it would be pretty hypocritical to argue that it's dramatically evil to spend your money that way.
It's just a bit silly to regard this as a "contribution" when it's largely likely to be a contribution to the bottom line of the retailer rather than the producers...
Perhaps it's not the ultimate of failed technologies, but Magnetic Bubble Memories, from the Intel Magnetics Operation (IMO), was an interesting technology.
These days, everyone's deploying "FlashMemory;" I would think it a very nice thing if there were something in the way of a solid state technology that would provide something much cheaper than RAM, and less sensitive to vibration than disk.
What would be real nice would be to have something that would provide the 512MB of storage you want for a portable computer, cheaper than flash, and without the mechanical requirements of hard drives...
The other interesting alternative would be to take some variation on the BSD Ports and build that as the "user space" with Linux as the underlying kernel.
Note that the Debian folk once had the (arguably deranged!) counter-idea of doing the opposite, namely using FreeBSD as kernel for Gnu/Debian/FreeBSD.
I'd contend that neither approach is the least bit "deranged;" I'm actually quite surprised that, with all the BSD connections, Slackware has never headed to using Ports as its package management system...
Perhaps the "best feature" of Red Hat is their tendancy to aggressively pursue the most bleeding edge experimental stuff out there, whether that be ELF, GLIBC2.0, GNOME, or GCC 2.96...
SuSE's "best feature" is that they have built vast quantities of RPM packages for all sorts of stuff, with considerable numbers of "engineering hours" tweaking the packages.
Note that these tweaks are to make the packages work with the SuSE "layout," and may not work with other distributions...
Debian's "best" features are three, namely that they have built vast quantities of DEB packages, with a huge group of package managers (that are people) that tweak those packages, that they have built tools to validate those DEB package to ensure conformance with their standards, and, thirdly, that they have a sophisticated package dependancy manager, APT, which will automatically install the dependancies called for by what you want to install.
The stable release, as typically released on CDs, takes the conservative approach of only releasing what they know already works well.
Slackware takes the approach of requiring that packages be managed as "tarballs," with somewhat more limited dependancy checking, and with the expectation that you, the sysadmin, will be installing and configuring the services that you want, as opposed to GUIing it all.
Note that none of this has anything to do with licenses, only with the respective design choices. And some of those choices are downright incompatible.
I would argue that the notion of the "best uberdistribution" is a contradiction in terms and thus an inherent impossibility.
As for the "licensing thing," one part of constructing a distribution is indeed in assessing the respective licenses of the components and how that fits with what you plan to release. If you can't cope with the legalities there, you're probably not legally prepared to release any kind of collection of this sort of thing...
Even if there are now merely "islands of Corel" amongst the increasing "oceans of Microsoft" within the Canadian government, that confirms the all-critical political effect.
I'll bet that Corel sales reps have been tearing their hair (if not eyes!) out the last couple of years watching Canadian government contracts go to Microsoft.
The critical point is that the "stream" of revenue moves from "gushing river" towards "mere trickle."
I wasn't aware of Copeland's PC connections; that makes the entire situation make complete sense when it had never seemed sensible before.
When I saw Corel getting into the "SideWinder" business, the only way I could fathom the strategy being faintly sensible was if they could get some fat sales out of the Canadian government. The decline of Corel (in various ways) parallels the decline of ability to get such sales.
A quick search at eBay finds auctions for PS2's with pricing sitting around $400 for auctions that are about to expire. Which indicates that at least some rationality sits in the marketplace. At least, they're not still selling for $5K a pop.
There will always be some degree of conflict between pricing of game units and PCs; consider:
PCs that provide PCI bus should cost a bit more because they offer the option of upgrading video hardware, RAM, and possibly even CPU. (Plus other options not so directly relevant to gaming.
PCs are built in smaller lot sizes with less uniform hardware, so you'd expect them to be a bit more expensive.
PCs as "general purpose" hardware can run any software (within some limits); as a result, the hardware vendors cannot afford to assume they can subsidize low-priced hardware by virtue of people having to come to their software arm to buy from their 'video game monopoly.'
Put that together and the present pricing of PCs being a fair bit more expensive is quite rational.
Those factors seem to me to be more crucial than that of "cutting-edgeness."
It isn't obvious that moving to "optical" computers would necessarily diminish the amount of heat involved; the problem is that the switching principle changes, and I'm not sure that we really have suitable "superconductors of light" to correspond to the electrical properties of superconductors.
The idea isn't new; Congo used a "special form of diamonds" that would be used in exactly this manner as the McGuffin that was the excuse for them to go to Africa. And the book dates back 20 years.
What an outrageous licensing arrangement. The book is in the public domain. The notion of applying such a dramatically rapacious license to something that is acknowledged as a contribution from Project Gutenberg just screams for there to be both a combination of boycott of Adobe and something to be done in support of PG.
Whether fortunately or unfortunately, the movers at PG are extremely resistant to the notion of using anything other than plain ASCII text; while they appear somewhat unreasonable about this, they are legitimately looking at a longer term scope. XML happens to be "hot" this year, but it may be something else that is "hotter" a couple years down the road.
Jumping into XML would mandate defining a whole lot more "structuring" information than anyone can necessarily agree on. One person's "not enough structure" may be another's "too much structure," and there may well not be a "happy enough" medium.
By all means, more tools to do automated processing of PG texts would be a Good Thing; transcribing more texts would similarly be a Good Thing. Sending Project Gutenberg $20 wouldn't be the most horrible idea on earth...
If the new models cost $600, then the fact that they've got "cool new stuff" doesn't prevent them from being as prohibitively too-expensive as are the "Pocket PC" units.
When there are models selling for $250 ( insert evil joke about Claudia Schiffer here as needed:-)), the transition will be there.
Until that occurs, they're not comparable, regardless of how Powerfully K001 they are.
... indicates that the costs of accounting for the charitable organization eat up much of the would-be benefits.
... And if the purchaser pays for an "invoice" for "software/services," then the money given may be deductable as a business expense.
The big "merit" in the "donation" thing is if this allows the organization to receive individual contributions from individuals that wouldn't otherwise be able to "deduct" the payment for tax purposes.
While, when you add this sort of thing up across thousands of churches, it adds up to real money, it's not going to be spectacularly worthwhile for a software project that might get $30K in donations and have to spend a chunk of that on organizational costs.
Well, if not done right, it can be pretty fatal to the boot process:-( if not to the user:-).
It's not as if this is the only thing that occasionally requires some upgraded tools; I did a Linux install on the weekend on an Athlon 600 box where I am still fighting with fdisk to get it to properly recognize the 40MB UDMA IDE hard drive. Apparently UDMA doesn't agree all that well with many of the distributions.
I tried out what I had around with pretty mixed results:
TurboLinux 4.0 was completely unable to cope with /dev/hda
Red Hat 6.2 was completely unable to cope with /dev/hda
Debian 2.1 [the "O'Reilly/VA Linux Boxed Set"] was unable to fdisk the drive, but once I had a set of partitions, it could at least recognize them;
[Most Recent] Caldera OpenLinux was the only system able to boot off the CD-ROM and successfully run fdisk so I could get the HD partitioned.
I'm still looking for a better answer; I suspect fiddling with LILO parameters should clear things up so I can finish partitioning the disk and transfer FSes over to ReiserFS.
The really relevant point here is that the distributions from about a year ago were quite completely unable to cope with the new hard drive. It should be no great surprise when new classes of hardware cause some breakage.
A year from now, we'll probably all need to do some upgrading to cope with the new USB and Serial ATA hardware that is likely to be available; install disks from 1999 will be so much shrapnel as far as some of the "new-for-2002" hardware is concerned.
This is why there actually is something of a business model for those that sell Linux distributions...:-)
I'm not going to go out and buy a Dreamcast just because I could run Linux on it. (Mind you, it very well might "tilt the scales" towards my buying one one of these days...)
The real point of this is that it actually brings some truth to the Linux for N64 April Fools joke of a few years ago.
It's not done because it's practical.
It's done because it's a "cool hack."
IBM didn't make put a Linux port onto a wristwatch because they wanted to sell wristwatches. (I'm a little confused, mind you, as to why IBM are now selling 2.4GHz wireless phones, and getting into a market typically fought over by Sony and Panasonic...) They built the watch because it was a cool hack that would get them publicity.
Give an extra generation for the video game units to get a bit more powerful and this actually starts being realistically useful; while the video game may lack a hard drive, if it has:
Wireless networking
A keyboard
Is dirt cheap
That could make for nice "disposable" desktop boxes. Certainly not relevant this year, just as the Linux-based PDAs aren't powerful enough this year to be tremendously viable.
But if someone prototypes it on this year's wimpy models, this may make them quite ready to build something more useful based on next year's hardware...
Usefulness and Innovation and Power: Three Things
on
The Future Of The GUI?
·
· Score: 4
GNUstep and Berlin both suffer similarly from the problem that neither provide much an "upgrade path" from where people are now.
Berlin inherits approaches from Fresco and InterViews; this doesn't provide any ability to run any existing code.
Your Gnome apps? Would need to be completely rewritten. Ditto for the KDE apps.
Everything needs to get recoded using OmniORB, C++, GGI, and the Berlin libs.
As a result, jumping to Berlin means losing all the GUIed applications that you might be running now, from StarOffice to GNOME to Netscape to KDE.
If you run Berlin atop GGI atop X, then maybe you can run some of those concurrently...
GNUstep has similar expectations of your adopting Objective C, DPS, and LibFoundation.
It makes you jump through the hoop of applying DPS to everything, which will be quite wonderful for anything that should be WYSIWYG, and which may represent a big "who cares?" for other sorts of applications.
It has the merit over Berlin that there may be some existing NeXTstep and OPENSTEP applications out that would be an "easy port away," and might have a bit more ability to play well with existing X apps.
Unfortunately, both suffer from the same daunting problem that in order to make them useful, there's a whopping lot of code that needs to be written. And they're pretty useless until both libraries, services, and applications get written.
GNUstep is somewhat closer to usefulness, with the added merit that there are parts of it (namely the DPS services/libraries) that can be usable with other graphical environments.
In similar senses, Linux and the BSDs are not particularly "innovative," as they all "merely" represent Yet Another Unix Clone. In contrast, EROS is a truly innovative OS kernel design, but since building a user space to go along with that is daunting, practically nobody uses EROS.
Innovation is pretty cool and all, but I'm just not sure that it actually represents something deployable.
... Though I'm not sure I agree with all of yours.
I'd focus on data storage first; without that, it really doesn't matter what kind of pretty GUI face you put on the front of it.
One of the "keys to success" on both PalmOS and Newton was that of having a whole lot of the system based on persistent data structures, e.g. where "everything is stored in a database." (Newton called this soups. )
Thus, when you're "juggling data," all you're juggling is a record here and there, rather than the traditional Unix "filesystem" approach where it's a whole file full of data being juggled, with attendant increases in risk of failure, in time consumed, and in storage required for "scratch space."
There is something arguably similar available on Linux; take a look at Casbah, which maps data in various forms onto a directory hierarchy.
Given a sound way of storing information, it then makes sense to proceed to provide useful abstractions for accessing that information; PalmOS has been successful foremost because they were open to developers wanting to use the system, from whence comes the hordes of useful and not so useful Palm apps.
It is not at all obvious to me that the up and coming would-be dethroners of PalmOS have taken seriously the task to get data storage right; most of the Linux-based systems seem pretty loose about this.
I would like to favor Linux-based PDAs, but based on what I see so far, I see little reason to consider an iPAQ running Linux over the alternative of upgrading to a TRGPro with 8MB of RAM.
Unfortunately, the Newton is pretty much the epitome of discontinued systems; the only way to build a newer model would be to redesign it from scratch.
Were it not for that, it was a vastly clever and sophisticated design that would be really neat to hack further on.
Furthermore, its model is more what is needed for a whole lot of things, namely a persistent data store that applications attach additional data to. PalmOS does somewhat similar, in its use of "little databases for everything;" this is really different from the Unix thing of "everything is a file."
... And if Microsoft bought them, what would it really have?
It wouldn't have total control over distribution of GCC, or Red Hat Linux, or any such stuff, after all, Mandrake was originally based essentially on RHAT's distribution.
The source of market value for these companies is indeed rather "vaprous;" it is mainly in the possibility of future cash flows, and with the way that free software is "like herding cats," it won't be the Iron Fist Of Bill that would pull in the money, but rather a rather more subtle, less rigid Waiting Carefully For The Money To Perhaps Come In.
Bringing in the "Bulletin Board" part demonstrates the crucial change; in yesteryear, a substantial part of the point to a "computer club" was often the fact that they ran a BBS to help coordinate disseminating news, discussion, and tools for the platform in question.
Back then, the issue of Long Distance Charges meant that it was expensive to talk to anyone far away, thus meaning that there was considerable value to replicating BBS material.
The growth of the Internet means that (with apologies to Mr Ed):
A host is a host, and coast to coast, nobody talks with a host that's close, unless the host that isn't close is busy, hung, or dead.
Where, fifteen years ago, communicating with software authors was quite daunting, it's easy enough now to bounce Linus Torvalds a note, or to find discussion specialized to my interests on a mailing list that joins participants on multiple continents, or to download patches from ftp.debian.org
The Internet does nothing directly to eliminate the need for human interaction; when it destroys user groups, this occurs as a result of:
Them being so tied to supporting communications technologies (like BBSes) that when the value of that disappears, the "social" value disappears;
On the one hand, if Theo brought in $300K, "10,000 @$30" and didn't have any expenses, that would be pretty impressive funding.
More realistically, the amounts get diminished in two obvious ways:
Theo needs to pay, up front, for the CD "burns." I'd expect that to be around $5/unit, which just ate $50K right there.:-(
Many of the CDs are not sold directly, but are rather resold. In which case it's likely something more like $15 that comes in to Theo.
Unsold inventory, anyone?
What doesn't get sold transforms magically into "pieces of chad" that aren't being fought over by Floridan electoral officials, but which rather cost that $5, and result in zero input of cash.
I'd be surprised if Theo's seeing as much as $100K of "positive" cash flow, all in all. If he's seeing more than that, bully for him; it's not as if he hasn't put in a lot of work that resulted in that.
As for your suggestion that it would be slick to have a "charity" to handle the money, while part of me agrees, there's definitely room for duality here.
What I would like to see is for people to take the action of Just Plain Giving Out Gifts to developers that they want to give money to. No "charitable contribution;" no "tax deduction."
One might think that this is a losing proposition, as there's "no deduction." To the contrary, if there's that deduction, on your side, then the money must be treated as a taxable income on the part of those that receive it as income.
It's worse than that; employment income involves deductions, which means that lots of the money gets eaten up by taxation.
In contrast, if you give someone $50 a gift of your after-tax income, it may not be deductible in your hands, but should correspondingly not be taxable in their hands. If someone received $40K in nontaxable gifts, that might well be as good as receiving $60K in taxable income...
From my certainly-biased perspective, it's nowhere near as evident where manifest superiority lies:
Is Debian superior, because it doesn't suffer from the RHAT thing of releasing weird customized versions of kernels and compilers, or is it inferior because it took longer to get The XFree86 4.0.1 release out?
I no longer use RHAT these days, using Debian instead; the long times between Debian "stable" releases is legitimately a pain against which the questionable robustness of RHAT "dot 0" releases must be balanced.
On Debian, I've had a whopping lot more success running GNOME applications than I have had with KDE applications; your "clearly superior" code has tended to suffer badly from segmentation faults. I've never gotten any of the prepackaged KOffice stuff running.
I tend to prefer the architecture of GNOME to that of KDE, particularly because information about it is actually published and available.
Most of the documentation about KDE development seems to focus on the "soft" matter of "What are the UI guidelines?", with a distinct dearth of technical architectural material.
I could argue that KDE, by largely forcing developers to program in C++, this represents its own "denial of passion for excellence."
After all:
"C++ is more of a rube-goldberg type thing full of high-voltages, large chain-driven gears, sharp edges, exploding widgets, and spots to get your fingers crushed. And because of it's complexity many (if not most) of it's users don't know how it works, and can't tell ahead of time what's going to cause them to lose an arm." -- Grant Edwards
:-)
GNOME, by being agnostic about what language you are expected to use, does not force you into
"Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to hit computing since MS-DOS." -- Alan Kay
The notion that GNOME is necessarily terribly awful and that to use it means denying any notion of "passion for excellence" seems to me to be a ludicrously unfair way of characterizing it.
At one time, GNOME wasn't much more than a counterreaction to KDE's adoption of the then-rather-more-proprietary Qt toolkit; that is certainly no longer true.
Slashdot Mirror
You were free to choose the GPL, but, since the software was not documented to be available under those terms, evidently you didn't.
As a result, the GPL terms don't apply, and since you didn't negotiate a contract for other terms, you must have felt amenable to the Big Bill License.
Ignorance is no excuse; Pay up! :-)
On the one hand, the original software is being offered "free of charge," which means that one could assume that "damages" are $0.
On the other hand, the GPL is an interesting license in that it does not necessarily prevent the authors of software from simultaneously licensing under some other arrangement.
How about this for an entertaining scenario:
That price (heh, heh!) being $50,000 USD payable to each author for the source license, plus $5,000 USD payable to each author for deployment of each binary copy of the software.
Thus, if the gentle folk in New Delhi (having been there recently, it is really just the "newer" part of Delhi :-)), in not making arrangements, they would start by oweing $50,000, trebled to $150K, plus a not inconsiderable sum based on the number of copies of the software sold :-).
The "each author" part would need to be more clearly nailed down; it would mean that the company making the mistake of "pirating" the Linux kernel would owe payments to (at recent count of /usr/src/linux/CREDITS) 293 people, thus making the penalties owing not too distant from $1B, and giving those 293 people a tidy sum of money :-).
I will certainly grant that this misfeature provides some wonderful exploits for the nefarious. After all, how long will it be before some hacker constructs a WinTel virus that marks the whole disk as being "copy protected," thereby rendering it into so much chaff from the perspective of anyone that was planning to actually store data on it.
Western Digital, Quantum, Seagate, and friends will be gloriously happy at that one; it's a wonderful opportunity to sell people more disk drives.
But as for the number of ways that this is a Spectacularly Stupid Idea, I'm not sure I have enough fingers and toes to cope with counting it... I'll probably need a Pentium processor, one without the FDIV bug, hopefully!
And it takes only about 3-4 wires to use it, rather than the 50-odd wires you find in SCSI and IDE cables. THAT is a pretty big deal; that simplifies the building and layout of systems.
The really cool part would be to stick a whole lot of Serial-ATA interfaces onto a system; while it would be ludicrous to try to connect 6 SCSI cards to a PCI bus, as the attendant cabling for the potential 90 SCSI drives would be be frightening, and result in a system shaped like the star required to get those cables to go in 6 different directions, the simpler cabling of Serial-ATA might allow such a design to be much cleaner. :-).
It's certainly not as nice as the latest and fanciest SCSI standard, but if it makes plugging in an extra few drives a cheap and simple matter, that will suffice. SCSI is neither simple nor cheap.
(Note: The only SCSI variation that I don't have drives for, at this point, is the latest 80MB thing that just doubled "Ultra-Wide" bandwidth again.)
In contrast, it is not a "contribution" to buy a copy of Civ:CTP, however nice the folks at Loki are.
The thing that is most irritating about the whole "commercial games" thing is that there are so many middlecritters in between you and the producer of the game. If you pay $40 for a game, it is unlikely that Loki sees much more than $10, which makes this a pretty inefficient way of getting funding to them.
I've bought games (well, one game) from them, so it would be pretty hypocritical to argue that it's dramatically evil to spend your money that way.
It's just a bit silly to regard this as a "contribution" when it's largely likely to be a contribution to the bottom line of the retailer rather than the producers...
These days, everyone's deploying "FlashMemory;" I would think it a very nice thing if there were something in the way of a solid state technology that would provide something much cheaper than RAM, and less sensitive to vibration than disk.
What would be real nice would be to have something that would provide the 512MB of storage you want for a portable computer, cheaper than flash, and without the mechanical requirements of hard drives...
Note that the Debian folk once had the (arguably deranged!) counter-idea of doing the opposite, namely using FreeBSD as kernel for Gnu/Debian/FreeBSD.
I'd contend that neither approach is the least bit "deranged;" I'm actually quite surprised that, with all the BSD connections, Slackware has never headed to using Ports as its package management system...
Note that these tweaks are to make the packages work with the SuSE "layout," and may not work with other distributions...
The stable release, as typically released on CDs, takes the conservative approach of only releasing what they know already works well.
Note that none of this has anything to do with licenses, only with the respective design choices. And some of those choices are downright incompatible.
I would argue that the notion of the "best uberdistribution" is a contradiction in terms and thus an inherent impossibility.
As for the "licensing thing," one part of constructing a distribution is indeed in assessing the respective licenses of the components and how that fits with what you plan to release. If you can't cope with the legalities there, you're probably not legally prepared to release any kind of collection of this sort of thing...
I'll bet that Corel sales reps have been tearing their hair (if not eyes!) out the last couple of years watching Canadian government contracts go to Microsoft.
The critical point is that the "stream" of revenue moves from "gushing river" towards "mere trickle."
I wasn't aware of Copeland's PC connections; that makes the entire situation make complete sense when it had never seemed sensible before.
When I saw Corel getting into the "SideWinder" business, the only way I could fathom the strategy being faintly sensible was if they could get some fat sales out of the Canadian government. The decline of Corel (in various ways) parallels the decline of ability to get such sales.
There will always be some degree of conflict between pricing of game units and PCs; consider:
- PCs that provide PCI bus should cost a bit more because they offer the option of upgrading video hardware, RAM, and possibly even CPU. (Plus other options not so directly relevant to gaming.
- PCs are built in smaller lot sizes with less uniform hardware, so you'd expect them to be a bit more expensive.
- PCs as "general purpose" hardware can run any software (within some limits); as a result, the hardware vendors cannot afford to assume they can subsidize low-priced hardware by virtue of people having to come to their software arm to buy from their 'video game monopoly.'
Put that together and the present pricing of PCs being a fair bit more expensive is quite rational.Those factors seem to me to be more crucial than that of "cutting-edgeness."
The idea isn't new; Congo used a "special form of diamonds" that would be used in exactly this manner as the McGuffin that was the excuse for them to go to Africa. And the book dates back 20 years.
Whether fortunately or unfortunately, the movers at PG are extremely resistant to the notion of using anything other than plain ASCII text; while they appear somewhat unreasonable about this, they are legitimately looking at a longer term scope. XML happens to be "hot" this year, but it may be something else that is "hotter" a couple years down the road.
Jumping into XML would mandate defining a whole lot more "structuring" information than anyone can necessarily agree on. One person's "not enough structure" may be another's "too much structure," and there may well not be a "happy enough" medium.
By all means, more tools to do automated processing of PG texts would be a Good Thing; transcribing more texts would similarly be a Good Thing. Sending Project Gutenberg $20 wouldn't be the most horrible idea on earth...
When there are models selling for $250 ( insert evil joke about Claudia Schiffer here as needed :-)), the transition will be there.
Until that occurs, they're not comparable, regardless of how Powerfully K001 they are.
For the "peanut gallery," yes, that should have been 40GB.
The big "merit" in the "donation" thing is if this allows the organization to receive individual contributions from individuals that wouldn't otherwise be able to "deduct" the payment for tax purposes.
While, when you add this sort of thing up across thousands of churches, it adds up to real money, it's not going to be spectacularly worthwhile for a software project that might get $30K in donations and have to spend a chunk of that on organizational costs.
Well, if not done right, it can be pretty fatal to the boot process :-( if not to the user :-).
It's not as if this is the only thing that occasionally requires some upgraded tools; I did a Linux install on the weekend on an Athlon 600 box where I am still fighting with fdisk to get it to properly recognize the 40MB UDMA IDE hard drive. Apparently UDMA doesn't agree all that well with many of the distributions.
I tried out what I had around with pretty mixed results:
I'm still looking for a better answer; I suspect fiddling with LILO parameters should clear things up so I can finish partitioning the disk and transfer FSes over to ReiserFS.
The really relevant point here is that the distributions from about a year ago were quite completely unable to cope with the new hard drive. It should be no great surprise when new classes of hardware cause some breakage.
A year from now, we'll probably all need to do some upgrading to cope with the new USB and Serial ATA hardware that is likely to be available; install disks from 1999 will be so much shrapnel as far as some of the "new-for-2002" hardware is concerned.
This is why there actually is something of a business model for those that sell Linux distributions... :-)
The real point of this is that it actually brings some truth to the Linux for N64 April Fools joke of a few years ago.
It's not done because it's practical.
It's done because it's a "cool hack."
IBM didn't make put a Linux port onto a wristwatch because they wanted to sell wristwatches. (I'm a little confused, mind you, as to why IBM are now selling 2.4GHz wireless phones, and getting into a market typically fought over by Sony and Panasonic...) They built the watch because it was a cool hack that would get them publicity.
Give an extra generation for the video game units to get a bit more powerful and this actually starts being realistically useful; while the video game may lack a hard drive, if it has:
- Wireless networking
- A keyboard
- Is dirt cheap
That could make for nice "disposable" desktop boxes. Certainly not relevant this year, just as the Linux-based PDAs aren't powerful enough this year to be tremendously viable.But if someone prototypes it on this year's wimpy models, this may make them quite ready to build something more useful based on next year's hardware...
Your Gnome apps? Would need to be completely rewritten. Ditto for the KDE apps.
Everything needs to get recoded using OmniORB, C++, GGI, and the Berlin libs.
As a result, jumping to Berlin means losing all the GUIed applications that you might be running now, from StarOffice to GNOME to Netscape to KDE.
If you run Berlin atop GGI atop X, then maybe you can run some of those concurrently...
It makes you jump through the hoop of applying DPS to everything, which will be quite wonderful for anything that should be WYSIWYG, and which may represent a big "who cares?" for other sorts of applications.
It has the merit over Berlin that there may be some existing NeXTstep and OPENSTEP applications out that would be an "easy port away," and might have a bit more ability to play well with existing X apps.
Unfortunately, both suffer from the same daunting problem that in order to make them useful, there's a whopping lot of code that needs to be written. And they're pretty useless until both libraries, services, and applications get written.
GNUstep is somewhat closer to usefulness, with the added merit that there are parts of it (namely the DPS services/libraries) that can be usable with other graphical environments.
In similar senses, Linux and the BSDs are not particularly "innovative," as they all "merely" represent Yet Another Unix Clone. In contrast, EROS is a truly innovative OS kernel design, but since building a user space to go along with that is daunting, practically nobody uses EROS.
Innovation is pretty cool and all, but I'm just not sure that it actually represents something deployable.
Christopher Browne
(Who Slashdot cut off at the "E")
I'd focus on data storage first; without that, it really doesn't matter what kind of pretty GUI face you put on the front of it.
One of the "keys to success" on both PalmOS and Newton was that of having a whole lot of the system based on persistent data structures, e.g. where "everything is stored in a database." (Newton called this soups. )
Thus, when you're "juggling data," all you're juggling is a record here and there, rather than the traditional Unix "filesystem" approach where it's a whole file full of data being juggled, with attendant increases in risk of failure, in time consumed, and in storage required for "scratch space."
There is something arguably similar available on Linux; take a look at Casbah, which maps data in various forms onto a directory hierarchy.
Given a sound way of storing information, it then makes sense to proceed to provide useful abstractions for accessing that information; PalmOS has been successful foremost because they were open to developers wanting to use the system, from whence comes the hordes of useful and not so useful Palm apps.
It is not at all obvious to me that the up and coming would-be dethroners of PalmOS have taken seriously the task to get data storage right; most of the Linux-based systems seem pretty loose about this.
I would like to favor Linux-based PDAs, but based on what I see so far, I see little reason to consider an iPAQ running Linux over the alternative of upgrading to a TRGPro with 8MB of RAM.
Were it not for that, it was a vastly clever and sophisticated design that would be really neat to hack further on.
Furthermore, its model is more what is needed for a whole lot of things, namely a persistent data store that applications attach additional data to. PalmOS does somewhat similar, in its use of "little databases for everything;" this is really different from the Unix thing of "everything is a file."
It wouldn't have total control over distribution of GCC, or Red Hat Linux, or any such stuff, after all, Mandrake was originally based essentially on RHAT's distribution.
The source of market value for these companies is indeed rather "vaprous;" it is mainly in the possibility of future cash flows, and with the way that free software is "like herding cats," it won't be the Iron Fist Of Bill that would pull in the money, but rather a rather more subtle, less rigid Waiting Carefully For The Money To Perhaps Come In.
Back then, the issue of Long Distance Charges meant that it was expensive to talk to anyone far away, thus meaning that there was considerable value to replicating BBS material.
The growth of the Internet means that (with apologies to Mr Ed):
Where, fifteen years ago, communicating with software authors was quite daunting, it's easy enough now to bounce Linus Torvalds a note, or to find discussion specialized to my interests on a mailing list that joins participants on multiple continents, or to download patches from ftp.debian.org
The Internet does nothing directly to eliminate the need for human interaction; when it destroys user groups, this occurs as a result of:
More realistically, the amounts get diminished in two obvious ways:
What doesn't get sold transforms magically into "pieces of chad" that aren't being fought over by Floridan electoral officials, but which rather cost that $5, and result in zero input of cash.
I'd be surprised if Theo's seeing as much as $100K of "positive" cash flow, all in all. If he's seeing more than that, bully for him; it's not as if he hasn't put in a lot of work that resulted in that.
As for your suggestion that it would be slick to have a "charity" to handle the money, while part of me agrees, there's definitely room for duality here.
What I would like to see is for people to take the action of Just Plain Giving Out Gifts to developers that they want to give money to. No "charitable contribution;" no "tax deduction."
One might think that this is a losing proposition, as there's "no deduction." To the contrary, if there's that deduction, on your side, then the money must be treated as a taxable income on the part of those that receive it as income.
It's worse than that; employment income involves deductions, which means that lots of the money gets eaten up by taxation.
In contrast, if you give someone $50 a gift of your after-tax income, it may not be deductible in your hands, but should correspondingly not be taxable in their hands. If someone received $40K in nontaxable gifts, that might well be as good as receiving $60K in taxable income...
Food for thought...
Most of the documentation about KDE development seems to focus on the "soft" matter of "What are the UI guidelines?", with a distinct dearth of technical architectural material.
After all:
GNOME, by being agnostic about what language you are expected to use, does not force you into
The notion that GNOME is necessarily terribly awful and that to use it means denying any notion of "passion for excellence" seems to me to be a ludicrously unfair way of characterizing it.
At one time, GNOME wasn't much more than a counterreaction to KDE's adoption of the then-rather-more-proprietary Qt toolkit; that is certainly no longer true.