This is pure bullshit. To think that an application that uses even.001% of Oracle's power was even tested on, much less conditionally finalized for production with, MySQL is 100% crap. It's just not possible in the universe we inhabit. Anything for which Oracle is even a remote possibility precludes even the assessment of MySQL for the same job.
Moreso, in any case where MySQL is suitable for the job, but the GPL precludes its use, PostgreSQL is the logical choice. Hell, PostgreSQL is the logical choice in ANY case that MySQL is a consideration.
Your story is either a complete fabrication, or your "third or fourth hand info" (yes, I read your prior post where you mentioned this before) is fabricated. The only thing that lends it any credibility at all is the fact that the MySQL guys have a very fuzzy understanding of the GPL, so them claiming to the company's management that connecting an application to MySQL requires the application to be GPLd wouldn't be that far-fetched if the whole MySQL-to-Oracle nonsense wasn't so laughable.
My first response to this article is, "no shit, since a direct comparison is never what people meant to begin with."
When we draw comparisons between computers and brains, it's in a sense of gross generalizations rather than one to one correspondence. No one is dumb enough to suggest that human brains process information in terms of 1s and 0s (though I may be mistaken, since there are people dumb enough to believe in gods, demons, and devils).
However, brains are segmented (if not always cleanly) into specialized segments -- parts of the brain handle vision, parts handle speech (and apparently music), etc. It is in this regard that big-picture parallels can be drawn between computers and brains.
These parallels are not by chance most of the time, as much human technology is inspired by knowledge of natural processes.
"(Not associated with TrollTech, just a satisfied customer)"
Another satisfied user/customer here. I even convinced my bosses to buy a commercial Windows license for 3.1 a couple years ago (which I'm still using, btw). The rest of my colleagues are using Borland's C++ Builder, though I am more productive with Qt/KDevelop than they are with Builder (with one possible exception).
Unfortunately, the entirety of Builder costs about as much as just the Qt license. Considering that, for my Windows-only counterparts, the cost of the Qt libraries alone equals or exceeds the cost of a Builder integrated Editor + Compiler + Debugger + GUI library, the Qt-as-a-standard argument was stillborn.
It made no sense to pay for Qt, and then have to spend an equal amount of additional money for a development environment where half its features would go unused. Despite the fact that Builder's GUI system is horrendously primitive compared to Qt, the very well integrated system that Builder provides outweighed everything else.
On the bright side, my productivity with Qt+KDevelop is high enough that they let me continue using it for all my applications. I think they're also hedging their bets that I will eventually arrive at a day when I've rewritten all our in-house stuff to be Linux enabled, therefore allowing us to give Microsoft the Great Big Middle Finger.
"...they can't say this thing has no value so I shouldn't pay for it; if it had no value they would not pirate it."
You are making the logical fallacies of Begging The Question and Circular Reasoning, as well as making a crucial economics error.
You are assuming that the people who illegally copy copyrighted materials would have still wanted those things if they weren't free. That is certainly true in some cases, but certainly not true in other cases. I'm not trying to address the morality of the former, but the assumption is simply incorrect in a substantial number of cases.
You are also assuming that just because it is used, it has market value. Your proof that it has market value is the fact that it is used. You have only to look at the pet rock idiocy of the early 80s to see the fallacy of that. Was it piracy to pick a rock from your local field rather than buying it from the store? Just because someone's selling and someone's buying doesn't make it valuable. It just means that P.T. Barnum was correct.
The economic error is the assumption that something with zero reproduction costs, and that can be trivially reproduced by anyone, fits into an economy of scarcity (the management of scarcity is the foundation of economics).
The (relative) scarcity of digital works exists solely in the initial creation of those works. This cost is the same whether no units are sold or a trillion units are sold. Reproduction cost is so low as to be essentially free. I'm intentionally not counting per-unit costs of manuals, CDs, etc. as those are not required for a successful reproduction of the digital works they accompany. While I think that producers of nontangible goods should be paid by those that use those goods, the problem here is not one that fits into an economic model of scarcity.
People see a distinction between stealing a car and copying music/software/ebooks/etc. for this reason. If you steal a car, you are costing the owner the per-unit cost needed to produce that car. This per-unit cost exist even after the car is designed and the initial production is completed. You are depriving the owner of real, tangible assets.
If you copy a song/program/book, the owner of the copyright loses no per-unit asset. The loss is purely theoretical in the sense that the copy consumed no additional production resource, incurred the copyright owner no additional loss of time or effort, or in any way involved the copyright owner.
That is the basic problem facing the creators of digital works. People consider stealing the disc that stores the music as wrong because that disc cost money to produce, but copying the bits on that disc as perfectly fine because making that copy didn't deprive the owner of a per-unit production cost.
What you've just described is the current cookie system. Each of your 6 points is already implemented as the current standard.
There is nothing secret about the structure of cookies, as each and every field in fully documented and described. The only part of the cookie that varies is the payload value, but that's the way it has to be. Without a varying payload, cookies are useless.
That said, cookies have only one legitimate purpose: identifying a user to the web server. In my opinion, the cookie system could be banished completely and replaced with a standard mechanism that does nothing but that one function. It would not allow the web server to place arbitrary content on the computer. It would only allow two items:
1) The URL of the web server. 2) A hash, the calculation of which would be specified by the standard and verified by the browser, that identifies that user to the site.
"...yet few people have any qualms about paying bills online, using credit cards, or otherwise using money that they never see..."
Paying bills online is still using real money to buy real things. If I don't pay my power bill, my electricity goes off. Lots of bad things happen in the real world when the electicity goes off.
There is nothing wrong with paying a small fee for some intagible entertainment. That's the very nature of going to the theater or listening to a concert. Where people start rightfully ridiculing you is when you spend large amounts of money treating something completely fictitious and completely without tangible value as if it were real.
To answer another poster: paying $10,000 for an autographed baseball IS moronic. Its only redeeming value is that you may someday sell it to some other moron for more real money.
Aside from being able to find someone else dumb enough to pay you money for your fictitious mental image (virtual property), things have value because they are desirable and scarce. Virtual real estate is neither.
Economics 101: money is a medium of exchange. Money works because people know that other people will accept it in return for goods and services. Money represents your level of real power because the more money you have to give, the more things you can make people give you in return.
Credit is borrowing more real world power for immediate use than you have at that moment, with the expectation of returning to the creditor more real world power than it gave you. The more power you have (measured in dollars), the more real things you can get.
It's true that money is a completely artificial economic system, but it's what people will accept in exchange for giving you real things (such as food, clothing, and shelter). If all the people with real property all decided to no longer accept money, then the monetary exchange system would crumble and become no better than buying a mental image on someone's server.
If the time ever comes when people will generally accept a few megs of space on the hard drive of someone's computer in exchange for real houses and cars, then I'll stop ridiculing paying lots of real money for make believe property.
"Not stupid, but badly informed, because it is very easy to install new repositories...."
As much as I like Mandrake (I'm not yet using a Mandrive distribution, so I'm using the name of what I have), installing new repositories is not easy. In fact, it's pretty hard because you have to know too much esoteric information about where things are located on the mirrors.
An easy process would be something like this:
1) MCC automatically connects to the Mandrake/Mandrive site and downloads a list of verified mirrors that is then presented to the user.
2) The user highlights the mirrors to add to the repository list, and says OK.
Done. All the RPMs on the selected mirror sites are now available.
As it stands right now, you have to know the mirror location ahead of time, and you have to know EXACTLY not only where the RPMs are stored on the mirror site, but where the synthesis file is located relative the the RPMs (which is frequently not the same place the RPMs are stored). If you don't get both of those just right, then nothing works.
The quality of the mirrors also varies greatly, as their conformance to the Mandrake master list is not verified. More often than not, the mirror sites are painfully understocked and the dependencies are unresolvable. Even the Mandrake Club reserved mirrors are frequently out of sync or just broken.
When a well made mirror is finally found, urpmi works seamlessly. However, well made mirrors are the exception rather than the rule.
"Sure, Linux can probably do it, but do you really want to spend the next 8 hours walking your friend through downloading and compiling packages, kernel modules, or hunting around for software to accomplish the task?"
It's a stawman argument. You're inventing a point the original author didn't make, and then trying to tear it down.
If someone has a friend install Linux for him, then he's probably going to be making purchasing decisions based on that friend's recommendations. Said friend will have explained the pros and cons well enough for that person to know that off-the-shelf software isn't going to work.
I set my mom's Linux system up for her 5 years ago, and have had exactly 2 trouble calls. One was when her sound died, which was because her speakers died. The other was when her computer would spontaneously crash, and that was because the IDE cable was loose.
Over these last 5 years, I've fielded a few questions about using Mozilla, and a few about Abiword. Other than that, it's been hassle free for us both.
That is a BIG change from when she was using Windows; which would freak out sporadically, unpredictably, and repeatedly. She got so fed up with Windows that she insisted I replace it with Linux (I kid you not) since I was always commenting on how hassle-free it was once things were in place.
Getting a Linux machine running correctly is the same as getting a Mac machine running correctly. Based on Mac user testimonials, I'll assume that Macs are easy to setup. Having used Mandrake for 5 of the 6 years I've been using Linux exclusively, I know that Mandrake is child's play to setup.
With Mac, you have to have Mac-certified hardware (thereby known to work with Mac).
With Linux, you have to use hardware that is known to work (think of it as pseudo Mandrake-certification) with Linux:
1) Video card: NVidia since it just works. Mandrake sees it, configures it, done.
2) Sound Sound Blaster Live! since it just works. Mandrake sees it, configures it, done.
3) Network card. I never owned one that Mandrake didn't like. If another Mandrake is already on the network, the thing is auto-configured.
4) Mice/trackballs. Of the name-brands, I've only used Logitech USB. For simplicity, I rebooted after plugging it in. Mandrake saw my old trackball disappear, and automatically uninstalled its driver. It saw that I had a new trackball, and automatically installed the new driver.
Mandrake 9.1 had issues with sound sporadically not working. Mandrake 9.2 (which I'm still using) has had zero sound problems. I haven't had to edit a configuration file since Mandrake 9.1. XMMS, Konqueror, MPlayer, and Xine all work fine in every combination I have tried.
Either Jamie has an ulterior motive (such as being hired by Apple), is just trying to get people riled up, or he had a lobotomy. These are the only explanations for the things he complains about. The other possible explanation is that he's not using a desktop-oriented Linux, but I'm assuming he's smart enough to know better.
My typical post-install with Mandrake is under 2 minutes, and that's to tweak a few little things:
1) Set the time zone to Central.
2) Select KDE as my desktop. This could be better, as I have to select a desktop twice as part of the install/first-use procedure.
The whole thing is almost, but not quite, as easy as an operating system installation can possibly be. It's much easier than any Windows installation I've ever done.
Thanks, Batman. I want to make it clear that I wasn't proposing the idea as an advancement in the state of the art of software distribution, but rather as a way of improving Linux application software distribution.
As you said, Linux has, and has had for years, all the necessary components in place to make this happen. Unfortunately, no one else has taken the initiative to put them together.
I have been developing an application distribution system, which I call Linstall, that addresses all issues except where to place files (which is deferred to the underlying packaging system itself). My implementation assumes RPM, but distribution makers can easily modify it to use whatever packaging system they desire (deb, tar, etc).
The way it works is basically this:
1) The developer tells the packaging component which program is to be packaged.
2) The packaging component queries the application for all its dynamic dependencies, and walks the packager through the process of locating all the packages that were used in the development of the program.
3) The packaging component creates an ISO image just large enough to contain the application and its dependencies, places everything the program needs into the ISO image, then compresses it.
4) The compressed ISO image is then appended to an extractor stub program, and the resulting file is ready for the user to download.
5) The end-user downloads the file, makes it executable, and runs it.
6) The program extracts the ISO image, decompresses it, mounts it, then passes the correct command line to the packaging system to install the application.
7) The installer unmounts the ISO image, and exits.
Since all dependencies that are not part of the operating system are present in the distributed file, there should be no dependency problems. Since package managers are smart enough to not reinstall packages that are already present, there should be no Windows-like DLL hell.
Your natural first reaction might be that this could dramatically increase the size of the file the end user has to download, and in some cases that is true. In most cases, however, this will not be the case since the user would have to download at least that much during the process of tracking down all the dependencies anyway.
Given the option of downloading a larger package, but knowing that the application will install reliably, versus downloading a smaller file initially but having to spend time tracking down dependencies, most users would choose the former.
This is a logical fallacy called "fallacy by omission", and the specific technique employed was called "Stacking the Deck".
I presume you are familiar with the logical fallacy in your own response: Red Herring. For those just joining in, the Red Herring fallacy is one where someone starts arguing a point unrelated to the actual subject, usually in an attempt to draw attention away from weaknesses in that someone's arguments.
The original poster, like the KDE developer who made the initial complaint, wasn't saying Apple did anything wrong. They were both trying to explain for the bazillionth time that if KHTML trails Safari after Safari has gotten a new whiz-bang feature, don't start harping on the HTML developers. Integrating Apple's code is time consuming.
That's the whole point. Period. Everyone has gotten bent out of shape because they were unable to remember that one point when the KHTML developer went on to explain why that lead time is probably going to be substantial.
The KHTML developer's point about how Apple returns its contributions as huge tarballs with cryptic comments wasn't anger directed at Apple (though there was a strong odor of disappointment). It was an explanation of why KHTML would lag any new Safari feature, if those features got implemented at all. All the talk about Apple's CVS, its cooperation/noncooperation, adherence to license, etc. is all a big Red Herring and is mostly irrelevent to the original point.
The anger that was expressed by the developer was because people were assuming that the KHTML developers were being handed a drop-in gift from Apple, so if KHTML didn't provide the features that Apple placed in the returned code, it must be because the KHTML developers weren't up to snuff.
Zack (the KHTML developer) said that Apple was doing the bare minimum that was required, and he was fine with that. He was obviously not happy about it, but he accepted it as Apple's right.
I doubt Apple had any malevolent intentions, but rather was just caught off guard by the intensity of public expectations vs. years of internal policy.
"Consoles will take over PC gaming when they get the advantages of PC Gaming like bigger harddrives, better memory, better quality graphics..."
Most importantly, better controllers. No console currently sold has a controller better than the keyboard+trackball/mouse. The X-Box, PS/*, and Nintendo controllers all suck -- bad.
Once the consoles get all these things, you will have...wait for it...a personal computer.
To answer a few other posts: if you think that consoles will ever overtake PCs for gaming without some clever people finding effective and efficient ways of allow the casual gamer to copy their games, you need to do a little research about consumer software. It will always be copyable. The only question is how big a window the software providers have before it happens. However big the window, it will be short lived.
My opinion is that consoles will maintain a good, profitable market. But PCs for gaming are not going anywhere as long as there is a large PC market for non-gaming.
"On the one hand, successful open source development relies on the nature of man to contribute to a work without expecting a return - doing it just for the good of the community."
This is 100% false. Open Source relies upon the nature of markets: contributing to the market with the expectation of equal or greater returns.
Open Source isn't about altruism. Open Source functions because I have a need for software that doesn't exist, and I write that software (or portions of it). I expect my contribution to be used and improved on by others. Those improvements commonly occur in ways I either didn't expect, couldn't do myself, or simply didn't have the time to do. Those improvements may not even take place in the program that originated the code, but rather are implemented with pieces of my code that are put in unrelated software to which I later get access. Software that I wouldn't, or couldn't, have created myself is now available to me.
This expectation has been borne out unfailingly over the years.
That my contributions make the world a better place is a secondary concern. It's not that I don't care about making the world a better place, but normal rules of classical economics (i.e. the Invisible Hand) ensure that outcome. Which brings me to Free Software.
Even Free Software, which is driven by philosophy, isn't at all related to Communism. Free Software is driven by the idea that, with the unspoken assumption that software plays a central role in modern society, no one should be beholden to the providers of software. Free Software strives to make the world a better place, but it is no more Communism than the desire for political Freedom is Communism. Both Free Software and the desire for political Freedom draw from the same source (pun intended).
"So to me the question is: who's going to care enough about mundane, boring, business-rules based code to keep it up to date?"
There is no reason that FOSS has to be written by people without a profit motive. So who's going to write the boring business-rules code? The businesses who need those rules coded.
If there are X companies in the same business, it behooves each of them to contribute resources towards FOSS products to be used as the standard in that type of business. Each business benefits, while none of them get an unfair advantage over the others.
Licensing all contributions under the GPL keeps all those greedy little instincts in check and keeps everyone honest.
These guys crack me up when they scream about their so-called innovation. Did Larry invent the convept of source control systems? Hell no. He took the ideas of others and (apparently) improved upon them incrementally. That's not innovation. It's what we all do, regardless of how we license our software.
Most new ideas in software are incremental improvements in processing. There is little real innovation, ever. All improvements in software are inevitable. Someone, somewhere will get peeved enough with the status-quo to change how something is done, and the state of software will creep forward. That is the nature of having conscious thought.
Money is not going to create an idea. Nor will the absence of money destroy an idea. A programmer with a software idea will pursue the idea regardless of most circumstance.
What McVoy is really pissed about is the fact that he isn't all that creative, and he's watching the scientific process shatter his perfect little delusion.
Writing software is physically cheap, and has only one natural scarcity: time. All physical resources for writing software come at essentially no cost by comparison, and that is one of the reasons that software as a revenue generating product is not naturally sustainable in the long term. McVoy must be ignoring this to sustain his perfect little delusion.
The services model is a naturally sustaining model in the absence of artificial constraints such as software patents. People are lazy, and they don't want to know how to use their software. However, they know they have to have that same software to make their (non-software) operations run. More than not are perfectly willing to pay other people to keep that software in order. That is the whole impetus for maintenance subscriptions.
Open Source, however, addresses the one big issue people have with subscriptions to proprietary software: control.
People don't want to have to maintain their own software (and hardware, for that matter), but they also hate the overbearing cruelty imposed upon them by proprietary vendors. Open Source gives customers the best of both worlds. Someone else takes care of the headaches, while the customer retains all the power in the form of the ability to switch service providers. This keeps vendors honest.
None of this is a replacement for keeping knowledgable staff on the payroll, but it's the next best thing.
"Software Perfection" isn't the point the KHTML developers were making. They aren't accusing Apple of violating a license (how the hell did that thread get started????).
They are saying that, despite all the media to the contrary, Apple's work is of no use to the KHTML developers. This is because Apple has been providing its changes in huge blobs without providing any clues what those changes are for or how they relate the the rest of the KHTML renderer.
Apple is following the license, which was never in doubt, but is being mean-spirited about it. The KDE devs just want people to stop the nonsensical meme that Apple is somehow helping KHTML development.
As I understand the situation, it is somewhat like an editor of a large book returning to the author only the errors in the book, but without any type of markup or explanation, in no particular order, and in a foreign language the author doesn't know. While the editor was (strictly speaking) doing his job (which is to find the errors in the book), he wasn't being very helpful.
The code could be sorted out, given enough time, but it's just as productive to ignore Apple's changes and do it from scratch.
This has nothing to do with focusing on the needs of the users, and it has nothing to do with software perfection. It is purely an issue of Apple being credited with helping KHTML, when it is doing nothing of the sort.
Windows required 4 people to maintain one server. 1-5 reboots per day, several leaked gigs of RAM per day. 100% load with 4 browser connections, continuous and massive disk usage after running for less than an hour. Dead upon the 5th connection.
When we switch to Linux:
Red Hat maintained by 1 person (me). 1 reboot whenever a new kernel is released, never at any other time. Insignificant load (barely measurable) with 50 simultaneous connections. Most RAM still listed as unused. Hard drive largely inactive during even peak usage.
This is on the exact same machine.
2) DHCP+DNS
Windows routinely gives out conflicting addresses. A staff of 6 talented Windows admins couldn't get Dynamic DNS updates working in a pure Microsoft setup. Admin spent at least an hour a day forcing reissues and fixing conflicts. Time to issue addresses was 10-30 seconds each. DHCP server rebooted 2-3 times per week when it got hopelessly conflicted.
When we switched to Linux:
Linux DHCP server automatically detected IP conflicts and forced reissue of conficting addresses. Maintained by 1 person (me). Time to issue addresses is between 1-2 seconds each. Dynamic DNS updates configured in one hour (including time to research it since I'd never encountered it before). Rebooted only to physically relocate the machine (which required unplugging it). Never issues a conflicting dynamic address.
We experience similar patterns with most of our other Windows and Linux machines.
3) File+Print serving
This is where Windows is at its least worst, and actually performs somewhat respectably. While print issues are common when compared to Samba, they are managable.
In all cases, though, Samba does both much faster and more reliably. Unfortunately, Windows does this well enough that we haven't yet done any wholesale replacements.
Fortunately, we getting a couple more Linux machines to host additional services we're offering, and we have limited rack space. Management is going to want to consolidate servers, and the spare cycles on one of our Linux machines is likely going to be used to replace both the Windows print servers and the file servers.
It's completely laughable to suggest that Windows is faster than Linux. My experiences with fully patched and tweaked Windows installs versus mostly default installs of Linux (the main configuration being to disable unneeded services) is that Windows doesn't even come close. Linux usually outperforms Windows by a factor of 10.
Forget about asking the "community" to put up the money, it's not going to happen.
Don't be so sure about that. I'd be willing to contribute $200 to the development effort if the validity of the project can be authenticated (I don't know these people from a hole in the wall), so I can be sure my money is actually being used as advertised.
It only takes 5000 people donating this amount to raise $1M. Contrary to popular mythology, many of us use Free software not because it's free, but because it's Free.
Free software has allowed me to accomplish things that would have cost me many thousands of dollars if I had to use proprietary software. More realistically, I couldn't have accomplished those things at all without Free software. This cost savings given to me through software Freedom translated to equal cost savings for my clients.
Free (again, not free) PC compatible hardware can do the same for hardware manufacturers, which can thereby translate to increasing cost savings for their customers (like me).
If this card is fast enough to play Quake 3, a claim which the project's site makes, then it is a good enough start for a wide swath of uses. My work projects, for example, are mutating into providing 3D visualizations for business data. One of my Free projects is also moving from 2D to 3D.
Q3A-capable frame rates, with good quality texture maps, are easily enough to satisfy this kind of work. It's also good enough to play 3D games.
I'd consider a $200 donation towards development of a Free 3D card well worth the investment.
"...I wonder why the following comment is OK for open source projects and not close source?"
Here are the top two reasons:
1) Any motivated programmer can fix the Free Software problems, while we're stuck with what the closed source shops provide.
2) Free software is also gratis, while the closed source programs are expensive (usually outrageously expensive). If a company is going to charge an enormous fee, the product had better be damn near perfect (which it isn't).
When the product is gratis+libre, the developers deserve a pat on the back and a lot of leeway.
The number of database hits isn't the whole story, and is really not all that important. My web+database apps are LAPP driven, which provides some help with caching frequently used data (such as drop down lists).
Linux uses all otherwise unused memory for file caching. My database machines are loaded with 3-4GB of RAM each, so there is lots of memory used for caching.
PostgreSQL uses shared memory caches to increase performance (though I don't know the exact nature of its shared memory usage), and it works very well. Well constructed joins on multiple tables with millions of rows each, with reasonable filter criteria, return instantly.
My PHP applications populate (on average) 8 drop down lists per page, after determine access rights, user preferences, etc via other queries.
When accessed from our LAN, page construction is instantaneous. Rather, page construction is limited mainly by the speed with which Firefox (and Konqueror) can render HTML. For all intents and purposes, it's instantaneous.
Many lists frequently change, so caching at the application level is probably not going to provide any benefits. Multiple database hits aren't necessarily problematic if the database and operating system's internal caching already does a good job.
Re:Why isn't this already out?
on
Next Generation X11
·
· Score: 3, Insightful
Perhaps the reason the effects have gone unused on other platforms is because they weren't part of the platform. If every application is individually responsible for managing the effects, then of course few applications are going to use them.
If the effects are provided by the desktop environment independently and transparently (no pun intended) to the application developer, then everyone is going to use them.
That is the whole point of these effects. They are going to be part of the underlying desktop to provide more appealing visuals. It's much more appealing when switching from window to window to see the old window quickly tear apart or fold itself away, and the new window to quickly and smoothly slide into place than for the windows to just suddenly change.
It makes a lot more sense for the underlying window manager to be responsible for those effects than to burden individual applications with the responsibility.
Slashdot Mirror
[MySQL to Oracle bullshit snipped]
.001% of Oracle's power was even tested on, much less conditionally finalized for production with, MySQL is 100% crap. It's just not possible in the universe we inhabit. Anything for which Oracle is even a remote possibility precludes even the assessment of MySQL for the same job.
This is pure bullshit. To think that an application that uses even
Moreso, in any case where MySQL is suitable for the job, but the GPL precludes its use, PostgreSQL is the logical choice. Hell, PostgreSQL is the logical choice in ANY case that MySQL is a consideration.
Your story is either a complete fabrication, or your "third or fourth hand info" (yes, I read your prior post where you mentioned this before) is fabricated. The only thing that lends it any credibility at all is the fact that the MySQL guys have a very fuzzy understanding of the GPL, so them claiming to the company's management that connecting an application to MySQL requires the application to be GPLd wouldn't be that far-fetched if the whole MySQL-to-Oracle nonsense wasn't so laughable.
My first response to this article is, "no shit, since a direct comparison is never what people meant to begin with."
When we draw comparisons between computers and brains, it's in a sense of gross generalizations rather than one to one correspondence. No one is dumb enough to suggest that human brains process information in terms of 1s and 0s (though I may be mistaken, since there are people dumb enough to believe in gods, demons, and devils).
However, brains are segmented (if not always cleanly) into specialized segments -- parts of the brain handle vision, parts handle speech (and apparently music), etc. It is in this regard that big-picture parallels can be drawn between computers and brains.
These parallels are not by chance most of the time, as much human technology is inspired by knowledge of natural processes.
"(Not associated with TrollTech, just a satisfied customer)"
Another satisfied user/customer here. I even convinced my bosses to buy a commercial Windows license for 3.1 a couple years ago (which I'm still using, btw). The rest of my colleagues are using Borland's C++ Builder, though I am more productive with Qt/KDevelop than they are with Builder (with one possible exception).
Unfortunately, the entirety of Builder costs about as much as just the Qt license. Considering that, for my Windows-only counterparts, the cost of the Qt libraries alone equals or exceeds the cost of a Builder integrated Editor + Compiler + Debugger + GUI library, the Qt-as-a-standard argument was stillborn.
It made no sense to pay for Qt, and then have to spend an equal amount of additional money for a development environment where half its features would go unused. Despite the fact that Builder's GUI system is horrendously primitive compared to Qt, the very well integrated system that Builder provides outweighed everything else.
On the bright side, my productivity with Qt+KDevelop is high enough that they let me continue using it for all my applications. I think they're also hedging their bets that I will eventually arrive at a day when I've rewritten all our in-house stuff to be Linux enabled, therefore allowing us to give Microsoft the Great Big Middle Finger.
"...they can't say this thing has no value so I shouldn't pay for it; if it had no value they would not pirate it."
You are making the logical fallacies of Begging The Question and Circular Reasoning, as well as making a crucial economics error.
You are assuming that the people who illegally copy copyrighted materials would have still wanted those things if they weren't free. That is certainly true in some cases, but certainly not true in other cases. I'm not trying to address the morality of the former, but the assumption is simply incorrect in a substantial number of cases.
You are also assuming that just because it is used, it has market value. Your proof that it has market value is the fact that it is used. You have only to look at the pet rock idiocy of the early 80s to see the fallacy of that. Was it piracy to pick a rock from your local field rather than buying it from the store? Just because someone's selling and someone's buying doesn't make it valuable. It just means that P.T. Barnum was correct.
The economic error is the assumption that something with zero reproduction costs, and that can be trivially reproduced by anyone, fits into an economy of scarcity (the management of scarcity is the foundation of economics).
The (relative) scarcity of digital works exists solely in the initial creation of those works. This cost is the same whether no units are sold or a trillion units are sold. Reproduction cost is so low as to be essentially free. I'm intentionally not counting per-unit costs of manuals, CDs, etc. as those are not required for a successful reproduction of the digital works they accompany. While I think that producers of nontangible goods should be paid by those that use those goods, the problem here is not one that fits into an economic model of scarcity.
People see a distinction between stealing a car and copying music/software/ebooks/etc. for this reason. If you steal a car, you are costing the owner the per-unit cost needed to produce that car. This per-unit cost exist even after the car is designed and the initial production is completed. You are depriving the owner of real, tangible assets.
If you copy a song/program/book, the owner of the copyright loses no per-unit asset. The loss is purely theoretical in the sense that the copy consumed no additional production resource, incurred the copyright owner no additional loss of time or effort, or in any way involved the copyright owner.
That is the basic problem facing the creators of digital works. People consider stealing the disc that stores the music as wrong because that disc cost money to produce, but copying the bits on that disc as perfectly fine because making that copy didn't deprive the owner of a per-unit production cost.
[description of "standard" cookie snipped]
What you've just described is the current cookie system. Each of your 6 points is already implemented as the current standard.
There is nothing secret about the structure of cookies, as each and every field in fully documented and described. The only part of the cookie that varies is the payload value, but that's the way it has to be. Without a varying payload, cookies are useless.
That said, cookies have only one legitimate purpose: identifying a user to the web server. In my opinion, the cookie system could be banished completely and replaced with a standard mechanism that does nothing but that one function. It would not allow the web server to place arbitrary content on the computer. It would only allow two items:
1) The URL of the web server.
2) A hash, the calculation of which would be specified by the standard and verified by the browser, that identifies that user to the site.
"Batman turns (or look up) to robin and ask him to grab the Bat Shark Repelant off of his belt and hand it to him, Robin executes himself...."
If only...
"...yet few people have any qualms about paying bills online, using credit cards, or otherwise using money that they never see..."
Paying bills online is still using real money to buy real things. If I don't pay my power bill, my electricity goes off. Lots of bad things happen in the real world when the electicity goes off.
There is nothing wrong with paying a small fee for some intagible entertainment. That's the very nature of going to the theater or listening to a concert. Where people start rightfully ridiculing you is when you spend large amounts of money treating something completely fictitious and completely without tangible value as if it were real.
To answer another poster: paying $10,000 for an autographed baseball IS moronic. Its only redeeming value is that you may someday sell it to some other moron for more real money.
Aside from being able to find someone else dumb enough to pay you money for your fictitious mental image (virtual property), things have value because they are desirable and scarce. Virtual real estate is neither.
Economics 101: money is a medium of exchange. Money works because people know that other people will accept it in return for goods and services. Money represents your level of real power because the more money you have to give, the more things you can make people give you in return.
Credit is borrowing more real world power for immediate use than you have at that moment, with the expectation of returning to the creditor more real world power than it gave you. The more power you have (measured in dollars), the more real things you can get.
It's true that money is a completely artificial economic system, but it's what people will accept in exchange for giving you real things (such as food, clothing, and shelter). If all the people with real property all decided to no longer accept money, then the monetary exchange system would crumble and become no better than buying a mental image on someone's server.
If the time ever comes when people will generally accept a few megs of space on the hard drive of someone's computer in exchange for real houses and cars, then I'll stop ridiculing paying lots of real money for make believe property.
"Not stupid, but badly informed, because it is very easy to install new repositories...."
As much as I like Mandrake (I'm not yet using a Mandrive distribution, so I'm using the name of what I have), installing new repositories is not easy. In fact, it's pretty hard because you have to know too much esoteric information about where things are located on the mirrors.
An easy process would be something like this:
1) MCC automatically connects to the Mandrake/Mandrive site and downloads a list of verified mirrors that is then presented to the user.
2) The user highlights the mirrors to add to the repository list, and says OK.
Done. All the RPMs on the selected mirror sites are now available.
As it stands right now, you have to know the mirror location ahead of time, and you have to know EXACTLY not only where the RPMs are stored on the mirror site, but where the synthesis file is located relative the the RPMs (which is frequently not the same place the RPMs are stored). If you don't get both of those just right, then nothing works.
The quality of the mirrors also varies greatly, as their conformance to the Mandrake master list is not verified. More often than not, the mirror sites are painfully understocked and the dependencies are unresolvable. Even the Mandrake Club reserved mirrors are frequently out of sync or just broken.
When a well made mirror is finally found, urpmi works seamlessly. However, well made mirrors are the exception rather than the rule.
"Sure, Linux can probably do it, but do you really want to spend the next 8 hours walking your friend through downloading and compiling packages, kernel modules, or hunting around for software to accomplish the task?"
It's a stawman argument. You're inventing a point the original author didn't make, and then trying to tear it down.
If someone has a friend install Linux for him, then he's probably going to be making purchasing decisions based on that friend's recommendations. Said friend will have explained the pros and cons well enough for that person to know that off-the-shelf software isn't going to work.
I set my mom's Linux system up for her 5 years ago, and have had exactly 2 trouble calls. One was when her sound died, which was because her speakers died. The other was when her computer would spontaneously crash, and that was because the IDE cable was loose.
Over these last 5 years, I've fielded a few questions about using Mozilla, and a few about Abiword. Other than that, it's been hassle free for us both.
That is a BIG change from when she was using Windows; which would freak out sporadically, unpredictably, and repeatedly. She got so fed up with Windows that she insisted I replace it with Linux (I kid you not) since I was always commenting on how hassle-free it was once things were in place.
Getting a Linux machine running correctly is the same as getting a Mac machine running correctly. Based on Mac user testimonials, I'll assume that Macs are easy to setup. Having used Mandrake for 5 of the 6 years I've been using Linux exclusively, I know that Mandrake is child's play to setup.
With Mac, you have to have Mac-certified hardware (thereby known to work with Mac).
With Linux, you have to use hardware that is known to work (think of it as pseudo Mandrake-certification) with Linux:
1) Video card: NVidia since it just works. Mandrake sees it, configures it, done.
2) Sound Sound Blaster Live! since it just works. Mandrake sees it, configures it, done.
3) Network card. I never owned one that Mandrake didn't like. If another Mandrake is already on the network, the thing is auto-configured.
4) Mice/trackballs. Of the name-brands, I've only used Logitech USB. For simplicity, I rebooted after plugging it in. Mandrake saw my old trackball disappear, and automatically uninstalled its driver. It saw that I had a new trackball, and automatically installed the new driver.
Mandrake 9.1 had issues with sound sporadically not working. Mandrake 9.2 (which I'm still using) has had zero sound problems. I haven't had to edit a configuration file since Mandrake 9.1. XMMS, Konqueror, MPlayer, and Xine all work fine in every combination I have tried.
Either Jamie has an ulterior motive (such as being hired by Apple), is just trying to get people riled up, or he had a lobotomy. These are the only explanations for the things he complains about. The other possible explanation is that he's not using a desktop-oriented Linux, but I'm assuming he's smart enough to know better.
My typical post-install with Mandrake is under 2 minutes, and that's to tweak a few little things:
1) Set the time zone to Central.
2) Select KDE as my desktop. This could be better, as I have to select a desktop twice as part of the install/first-use procedure.
The whole thing is almost, but not quite, as easy as an operating system installation can possibly be. It's much easier than any Windows installation I've ever done.
Thanks, Batman. I want to make it clear that I wasn't proposing the idea as an advancement in the state of the art of software distribution, but rather as a way of improving Linux application software distribution.
As you said, Linux has, and has had for years, all the necessary components in place to make this happen. Unfortunately, no one else has taken the initiative to put them together.
I have been developing an application distribution system, which I call Linstall, that addresses all issues except where to place files (which is deferred to the underlying packaging system itself). My implementation assumes RPM, but distribution makers can easily modify it to use whatever packaging system they desire (deb, tar, etc).
The way it works is basically this:
1) The developer tells the packaging component which program is to be packaged.
2) The packaging component queries the application for all its dynamic dependencies, and walks the packager through the process of locating all the packages that were used in the development of the program.
3) The packaging component creates an ISO image just large enough to contain the application and its dependencies, places everything the program needs into the ISO image, then compresses it.
4) The compressed ISO image is then appended to an extractor stub program, and the resulting file is ready for the user to download.
5) The end-user downloads the file, makes it executable, and runs it.
6) The program extracts the ISO image, decompresses it, mounts it, then passes the correct command line to the packaging system to install the application.
7) The installer unmounts the ISO image, and exits.
Since all dependencies that are not part of the operating system are present in the distributed file, there should be no dependency problems. Since package managers are smart enough to not reinstall packages that are already present, there should be no Windows-like DLL hell.
Your natural first reaction might be that this could dramatically increase the size of the file the end user has to download, and in some cases that is true. In most cases, however, this will not be the case since the user would have to download at least that much during the process of tracking down all the dependencies anyway.
Given the option of downloading a larger package, but knowing that the application will install reliably, versus downloading a smaller file initially but having to spend time tracking down dependencies, most users would choose the former.
This is a logical fallacy called "fallacy by omission", and the specific technique employed was called "Stacking the Deck".
I presume you are familiar with the logical fallacy in your own response: Red Herring. For those just joining in, the Red Herring fallacy is one where someone starts arguing a point unrelated to the actual subject, usually in an attempt to draw attention away from weaknesses in that someone's arguments.
The original poster, like the KDE developer who made the initial complaint, wasn't saying Apple did anything wrong. They were both trying to explain for the bazillionth time that if KHTML trails Safari after Safari has gotten a new whiz-bang feature, don't start harping on the HTML developers. Integrating Apple's code is time consuming.
That's the whole point. Period. Everyone has gotten bent out of shape because they were unable to remember that one point when the KHTML developer went on to explain why that lead time is probably going to be substantial.
The KHTML developer's point about how Apple returns its contributions as huge tarballs with cryptic comments wasn't anger directed at Apple (though there was a strong odor of disappointment). It was an explanation of why KHTML would lag any new Safari feature, if those features got implemented at all. All the talk about Apple's CVS, its cooperation/noncooperation, adherence to license, etc. is all a big Red Herring and is mostly irrelevent to the original point.
The anger that was expressed by the developer was because people were assuming that the KHTML developers were being handed a drop-in gift from Apple, so if KHTML didn't provide the features that Apple placed in the returned code, it must be because the KHTML developers weren't up to snuff.
Zack (the KHTML developer) said that Apple was doing the bare minimum that was required, and he was fine with that. He was obviously not happy about it, but he accepted it as Apple's right.
I doubt Apple had any malevolent intentions, but rather was just caught off guard by the intensity of public expectations vs. years of internal policy.
"Consoles will take over PC gaming when they get the advantages of PC Gaming like bigger harddrives, better memory, better quality graphics..."
Most importantly, better controllers. No console currently sold has a controller better than the keyboard+trackball/mouse. The X-Box, PS/*, and Nintendo controllers all suck -- bad.
Once the consoles get all these things, you will have...wait for it...a personal computer.
To answer a few other posts: if you think that consoles will ever overtake PCs for gaming without some clever people finding effective and efficient ways of allow the casual gamer to copy their games, you need to do a little research about consumer software. It will always be copyable. The only question is how big a window the software providers have before it happens. However big the window, it will be short lived.
My opinion is that consoles will maintain a good, profitable market. But PCs for gaming are not going anywhere as long as there is a large PC market for non-gaming.
"On the one hand, successful open source development relies on the nature of man to contribute to a work without expecting a return - doing it just for the good of the community."
This is 100% false. Open Source relies upon the nature of markets: contributing to the market with the expectation of equal or greater returns.
Open Source isn't about altruism. Open Source functions because I have a need for software that doesn't exist, and I write that software (or portions of it). I expect my contribution to be used and improved on by others. Those improvements commonly occur in ways I either didn't expect, couldn't do myself, or simply didn't have the time to do. Those improvements may not even take place in the program that originated the code, but rather are implemented with pieces of my code that are put in unrelated software to which I later get access. Software that I wouldn't, or couldn't, have created myself is now available to me.
This expectation has been borne out unfailingly over the years.
That my contributions make the world a better place is a secondary concern. It's not that I don't care about making the world a better place, but normal rules of classical economics (i.e. the Invisible Hand) ensure that outcome. Which brings me to Free Software.
Even Free Software, which is driven by philosophy, isn't at all related to Communism. Free Software is driven by the idea that, with the unspoken assumption that software plays a central role in modern society, no one should be beholden to the providers of software. Free Software strives to make the world a better place, but it is no more Communism than the desire for political Freedom is Communism. Both Free Software and the desire for political Freedom draw from the same source (pun intended).
"So to me the question is: who's going to care enough about mundane, boring, business-rules based code to keep it up to date?"
There is no reason that FOSS has to be written by people without a profit motive. So who's going to write the boring business-rules code? The businesses who need those rules coded.
If there are X companies in the same business, it behooves each of them to contribute resources towards FOSS products to be used as the standard in that type of business. Each business benefits, while none of them get an unfair advantage over the others.
Licensing all contributions under the GPL keeps all those greedy little instincts in check and keeps everyone honest.
These guys crack me up when they scream about their so-called innovation. Did Larry invent the convept of source control systems? Hell no. He took the ideas of others and (apparently) improved upon them incrementally. That's not innovation. It's what we all do, regardless of how we license our software.
Most new ideas in software are incremental improvements in processing. There is little real innovation, ever. All improvements in software are inevitable. Someone, somewhere will get peeved enough with the status-quo to change how something is done, and the state of software will creep forward. That is the nature of having conscious thought.
Money is not going to create an idea. Nor will the absence of money destroy an idea. A programmer with a software idea will pursue the idea regardless of most circumstance.
What McVoy is really pissed about is the fact that he isn't all that creative, and he's watching the scientific process shatter his perfect little delusion.
Writing software is physically cheap, and has only one natural scarcity: time. All physical resources for writing software come at essentially no cost by comparison, and that is one of the reasons that software as a revenue generating product is not naturally sustainable in the long term. McVoy must be ignoring this to sustain his perfect little delusion.
The services model is a naturally sustaining model in the absence of artificial constraints such as software patents. People are lazy, and they don't want to know how to use their software. However, they know they have to have that same software to make their (non-software) operations run. More than not are perfectly willing to pay other people to keep that software in order. That is the whole impetus for maintenance subscriptions.
Open Source, however, addresses the one big issue people have with subscriptions to proprietary software: control.
People don't want to have to maintain their own software (and hardware, for that matter), but they also hate the overbearing cruelty imposed upon them by proprietary vendors. Open Source gives customers the best of both worlds. Someone else takes care of the headaches, while the customer retains all the power in the form of the ability to switch service providers. This keeps vendors honest.
None of this is a replacement for keeping knowledgable staff on the payroll, but it's the next best thing.
"Software Perfection" isn't the point the KHTML developers were making. They aren't accusing Apple of violating a license (how the hell did that thread get started????).
They are saying that, despite all the media to the contrary, Apple's work is of no use to the KHTML developers. This is because Apple has been providing its changes in huge blobs without providing any clues what those changes are for or how they relate the the rest of the KHTML renderer.
Apple is following the license, which was never in doubt, but is being mean-spirited about it. The KDE devs just want people to stop the nonsensical meme that Apple is somehow helping KHTML development.
As I understand the situation, it is somewhat like an editor of a large book returning to the author only the errors in the book, but without any type of markup or explanation, in no particular order, and in a foreign language the author doesn't know. While the editor was (strictly speaking) doing his job (which is to find the errors in the book), he wasn't being very helpful.
The code could be sorted out, given enough time, but it's just as productive to ignore Apple's changes and do it from scratch.
This has nothing to do with focusing on the needs of the users, and it has nothing to do with software perfection. It is purely an issue of Apple being credited with helping KHTML, when it is doing nothing of the sort.
I also run both at work. Lets run down the list:
1) Web serving.
Windows required 4 people to maintain one server. 1-5 reboots per day, several leaked gigs of RAM per day. 100% load with 4 browser connections, continuous and massive disk usage after running for less than an hour. Dead upon the 5th connection.
When we switch to Linux:
Red Hat maintained by 1 person (me). 1 reboot whenever a new kernel is released, never at any other time. Insignificant load (barely measurable) with 50 simultaneous connections. Most RAM still listed as unused. Hard drive largely inactive during even peak usage.
This is on the exact same machine.
2) DHCP+DNS
Windows routinely gives out conflicting addresses. A staff of 6 talented Windows admins couldn't get Dynamic DNS updates working in a pure Microsoft setup. Admin spent at least an hour a day forcing reissues and fixing conflicts. Time to issue addresses was 10-30 seconds each. DHCP server rebooted 2-3 times per week when it got hopelessly conflicted.
When we switched to Linux:
Linux DHCP server automatically detected IP conflicts and forced reissue of conficting addresses. Maintained by 1 person (me). Time to issue addresses is between 1-2 seconds each. Dynamic DNS updates configured in one hour (including time to research it since I'd never encountered it before). Rebooted only to physically relocate the machine (which required unplugging it). Never issues a conflicting dynamic address.
We experience similar patterns with most of our other Windows and Linux machines.
3) File+Print serving
This is where Windows is at its least worst, and actually performs somewhat respectably. While print issues are common when compared to Samba, they are managable.
In all cases, though, Samba does both much faster and more reliably. Unfortunately, Windows does this well enough that we haven't yet done any wholesale replacements.
Fortunately, we getting a couple more Linux machines to host additional services we're offering, and we have limited rack space. Management is going to want to consolidate servers, and the spare cycles on one of our Linux machines is likely going to be used to replace both the Windows print servers and the file servers.
It's completely laughable to suggest that Windows is faster than Linux. My experiences with fully patched and tweaked Windows installs versus mostly default installs of Linux (the main configuration being to disable unneeded services) is that Windows doesn't even come close. Linux usually outperforms Windows by a factor of 10.
Forget about asking the "community" to put up the money, it's not going to happen.
Don't be so sure about that. I'd be willing to contribute $200 to the development effort if the validity of the project can be authenticated (I don't know these people from a hole in the wall), so I can be sure my money is actually being used as advertised.
It only takes 5000 people donating this amount to raise $1M. Contrary to popular mythology, many of us use Free software not because it's free, but because it's Free.
Free software has allowed me to accomplish things that would have cost me many thousands of dollars if I had to use proprietary software. More realistically, I couldn't have accomplished those things at all without Free software. This cost savings given to me through software Freedom translated to equal cost savings for my clients.
Free (again, not free) PC compatible hardware can do the same for hardware manufacturers, which can thereby translate to increasing cost savings for their customers (like me).
If this card is fast enough to play Quake 3, a claim which the project's site makes, then it is a good enough start for a wide swath of uses. My work projects, for example, are mutating into providing 3D visualizations for business data. One of my Free projects is also moving from 2D to 3D.
Q3A-capable frame rates, with good quality texture maps, are easily enough to satisfy this kind of work. It's also good enough to play 3D games.
I'd consider a $200 donation towards development of a Free 3D card well worth the investment.
"...I wonder why the following comment is OK for open source projects and not close source?"
Here are the top two reasons:
1) Any motivated programmer can fix the Free Software problems, while we're stuck with what the closed source shops provide.
2) Free software is also gratis, while the closed source programs are expensive (usually outrageously expensive). If a company is going to charge an enormous fee, the product had better be damn near perfect (which it isn't).
When the product is gratis+libre, the developers deserve a pat on the back and a lot of leeway.
The number of database hits isn't the whole story, and is really not all that important. My web+database apps are LAPP driven, which provides some help with caching frequently used data (such as drop down lists).
Linux uses all otherwise unused memory for file caching. My database machines are loaded with 3-4GB of RAM each, so there is lots of memory used for caching.
PostgreSQL uses shared memory caches to increase performance (though I don't know the exact nature of its shared memory usage), and it works very well. Well constructed joins on multiple tables with millions of rows each, with reasonable filter criteria, return instantly.
My PHP applications populate (on average) 8 drop down lists per page, after determine access rights, user preferences, etc via other queries.
When accessed from our LAN, page construction is instantaneous. Rather, page construction is limited mainly by the speed with which Firefox (and Konqueror) can render HTML. For all intents and purposes, it's instantaneous.
Many lists frequently change, so caching at the application level is probably not going to provide any benefits. Multiple database hits aren't necessarily problematic if the database and operating system's internal caching already does a good job.
Perhaps the reason the effects have gone unused on other platforms is because they weren't part of the platform. If every application is individually responsible for managing the effects, then of course few applications are going to use them.
If the effects are provided by the desktop environment independently and transparently (no pun intended) to the application developer, then everyone is going to use them.
That is the whole point of these effects. They are going to be part of the underlying desktop to provide more appealing visuals. It's much more appealing when switching from window to window to see the old window quickly tear apart or fold itself away, and the new window to quickly and smoothly slide into place than for the windows to just suddenly change.
It makes a lot more sense for the underlying window manager to be responsible for those effects than to burden individual applications with the responsibility.
"How about by buying a Canon camera?"
And writing to both Canon and Nikon explaining your purchasing decision.
This whole subject comes from The Register, which is known to say things that are, shall we say, highly interpretive.
I'm take the whole thing with a large landfill of salt.