Which is why Office XP is going to have a hard time making inroads in the market. Microsoft isn't going to let you install it without guaranteeing you paid for it, and no one is going to be interested in paying nearly $600 for an Office suite.
Sure, there will be "cracks" for Office, but the majority of folks aren't interested in actively stealing Office. They won't go out of their way. They will simply stick with what they have got.
Yes, but the article would have then become a useful comparison. As it now stands it's no different than me rounding up a bunch of Linux users and reporting that 9 out of 10 computer experts think Windows sucks.
A little table explaining methodology (was it a double blind test) and the bitrates for each sample would have at least been something.
You said that much better than I did, but that's pretty much what I meant. I certainly did not mean to infer that IBM "got it" back then when it came to open standards. They simply considered the PC a toy, and not worth the engineering effort to create from scratch.
And yes, they did all kinds of things to try and close the platform, but none of them worked, for the same reasons that Linux is still gaining ground despite everything Microsoft can do, and despite the fact that for some uses it really isn't a very good solution.
Customers like open standards, they are generally less expensive, and they allow freedom and flexibility. Basically customers will always choose the solution that is "good enough" at the lowest possible price. As Linux improves it is rapidly becoming "good enough" for a widening range of uses. Microsoft, as the market leader, can do what they want to try and stop this migration, but in the end the only feasible defense is to give their customers comparably priced and comparably open solutions. That is why.NET is based on open standards, Microsoft has to compete in this space with Free Software. Hopefully as Gnome, KDE, Mozilla, and OpenOffice improve these technologies will likewise force Microsoft's hand on the desktop.
It'll never happen. People think that Linux has a chicken and egg problem getting access to commercial applications. Any system that charges ISPs for access to content has a much larger problem. They have to sign up content providers that have content that a significant amount of an ISPs customers are willing to pay for, and then they have to convince that content provider that it is a better idea to sign up with their service (and pay the requisite commission) than to simply charge the end user themselves.
Fat chance of that happening.
Especially since many of the content providers already are access providers. AOL/Time Warner stands out as the best example. They are already using their "special" content as a hook to lure customers. Many of the other "large" ISPs have the same business model. One of their hooks is special proprietary information or tools. There is literally no chance that they are going to pay dues so that their subscribers can view their competitors for-pay sites, as they would rather have their customers see their own commercial sites. And without AOL's customers, and the customers from the non-complying normal ISPs the service will be severely limited in its market.
The fact of the matter is that once a product becomes a commodity, putting it back in the proprietary bag is nearly impossible. I am surprised this particular company isn't trying to charge for air and sunshine while they are at it.
Currently ISPs are running on razor thing margins. They aren't going to pay access fees for their users. Web companies are going to have to find a way to charge their customers directly, or they are going to have to find a way to show advertisers that their advertisements actually work. Micropayments isn't going to work, and macropayments are even less likely to work.
Sort of. IBM could have easily closed the entire IBM PC architecture. That way you would have had to buy all of your components from IBM or from IBM approved sources. But instead they put all of their eggs in the easily cloneable BIOS, and left the rest of the architecture open.
The reason that Compaq cloned the BIOS is that IBM had already created a large market for IBM PCs. This wasn't due to the fact that IBM PCs were very good, but rather that it was inexpensive to purchase nifty IBM PC add-ons (from whatever manufacturer you wanted). They realized it would be better to break into IBM's established market than to try and create a market for their own incompatible machine.
When Compaq opened up the IBM compatible market they simply amplified the original openness of the platform.
There are two problems with NuSphere's version of MySQL. The first is the trademark violation, and the second is the fact that they are distributing a proprietary extension statically linked to a GPLed product. Both of these actions are illegal, immoral, and contrary to what most Free Software advocates believe is the right thing to do.
If NuSphere took the source code from MySQL and released it as NuSQL (or something), and they released the source code to the Gemini extensions, then that would be a horse of a different color, and I personally wouldn't have a problem with their actions.
One of the Freedoms that Free Software advocates are fighting for is the right to fork the source code. This happens fairly often, and it is considered good form to rename the new project. In the case of a trademark dispute, it is not only good form, it is legally imperative. No one in the Free Software world gets excited about the Emacs/XEmacs split, or the Samba/Samba TNG split, or the now rectified gcc/egcs split. Individual developers might root for one side or the other, but that's about competition, and not disgust.
What NuSphere has done is illegal and disgusting. Pretending to cover over their greed with statements about the "community" is ridiculous at best. If they cared about the Free Software community they would follow the GPL and release their source code. If they had an ounce of integrity they would follow Free Software "tradition" and rename their project when they forked it. The fact that MySQL AB has to go to court to push the folks at NuSphere into doing what's right (and legally necessary) simply shows how far removed NuSphere is from the rest of the community.
You are absolutely correct about how the MySQL "benchmarks" work. MySQL's crufty benchmarks are a Perl script that simulates one user doing a whole lot of goofy things like dropping tables and dropping and creating connections. Quite frankly I can't think of a single benchmark that would be less useful for benchmarking a SMP system. I was actually surprised when the folks making up the benchmarks didn't simply add up the respective bogomips scores from each processor and call it a day.
I generally don't criticize benchmarking tests like these because I don't consider myself knowledgeable enough, but even I know that running one instance of the MySQL benchmark is not a good SMP test.
The PC industry is all about commodity hardware. There have been very few cases where a closed hardware specification has done well economically. In fact, IBM's effort to open their hardware was what guaranteed that the Macintosh didn't become the dominant PC computer architecture. Early Macs were a lot nicer machines than their IBM compatible counterparts, but the IBM compatible machines were cheaper (due to commodity hardware) and so they won out in the end.
Since then IBM tried unsuccessfully to corner the PC market with their MCA bus, and Rambus is currently learning that consumers (and more importantly memory manufacturers) aren't interested in their proprietary memory.
Hardware manufacturers that make it hard for their customers to actually use their hardware are only shooting themselves in the foot. They gain absolutely nothing by creating hardware that can't be hacked, and they lose potential sales from people that want to tweak their hardware.
The only folks that are concerned about the open nature of hardware are the folks who make their money from so-called "intellectual property." The RIAA and the MPAA don't want you to mess with your hardware because it might make it easier for you to copy their songs and movies. Microsoft doesn't want you to open up your computer because it makes it harder for them to keep you from copying their OS. Also open hardware specifications make it possible for alternative OSes to write drivers for the hardware. Microsoft would rather have Windows only hardware.
The hardware folks, however, don't really care if you are stealing songs, movies, or software. In fact, they would love for you to steal your software (that would give you more money to spend on hardware). They have something tangible to sell, and they know that their margins are tight enough that they had better not tick of their customers. They know that if they are quick to jump on the "closed hardware" bandwagon they will find that their customers are simply buying from their competitors, and that they have limited their own marketability simply to help someone else's business.
Fah! We might as well use a cannon instead of a pitcher as well. In fact, I am sure that with a little engineering we could get a supersonic fastball. We might need to replace the catcher, but that shouldn't be hard as you wouldn't need to worry about errant pitches. We should also consider arming the first basemen with battle-axes. That way if a hitter does manage to connect with the ball the first baseman can make sure that the poor fool doesn't make it to first base. Heck, why not just give all the players automatic weapons and see which team has the most players standing at the end of nine innings.
This is precisely the reason why there are rules to baseball. Everyone knows that you could have better pitchers just by letting them spit on the ball. But the point is the competition. Someone somewhere along the way decided that spitting on the balls was illegal (for whatever reason), and so now hitters don't have to worry about "spitballs." The rules may be strange (and sometimes fairly arbitrary), but folks like to watch and play baseball, and the rules allow the game to proceed fairly. Mixing in a robot pitcher may be great for hitting practice, but it would almost certainly be against the rules for competition, and since it wouldn't really be that fun to watch it almost certainly won't ever become legal.
I find the ads on sites like kuro5hin.org and slashdot are often quite helpful. I generally am actually interested in the things that get advertised on these sites. I would almost pay for more ads, and would certainly not be interested in seeing them removed. In that respect slashdot is no different from any other publication. They have the opportunity to market to a unique niche of people that they can pretty much guarantee is going to be interested in a certain set of products and services. Eventually advertisers are going to realize that this is the case and sites that are able to build large targetted audiences will be able to sell advertising without too much trouble.
Exactly. Of course not all transactions go through a bank. When I pay the neighbor kid to mow my lawn, there is a good chance that he spends it before he puts it in the bank (so that transaction would be transparent). Also with the current system there is no way for the bank to know how much change Subway gave you. Perhaps you just went in to get change for your $20. When that $20 shows up at the bank the bankers know who originally withdrew that bill, but they don't know anything about the transactions that might have happened since it left the bank.
I personally think this sort of device would be great if it were used as a way to stop counterfeiters. However, if they are going to use it to link people to transactions, well that's bad. Of course, in order to get that sort of information business would have to be required to share transaction information with the banks. I don't see that happening. That's pretty sensitive stuff.
Actually this is precisely why Microsoft wants to sell software as a service. Microsoft has finally realized that they are to the point where they can't coax users into upgrading by promising them a version of Windows without the major flaws. So instead the want to charge their users by the month whether they release new software or not.
Selling software as a product really isn't a very good fit, and has led to many of the abuses that we are currently subjected to. Of course, Microsoft's proprietary software would even be worse when sold as a service. Microsof would probably still not be too terribly interested in fixing bugs. I am sure that they would rather spend their time making sure they used their position to worm their way into every financial transaction.
Once QT was GPLed the Free Software Foundation ceased to have any problem with the license. Before that QT was released under a license that the FSF Lawyers felt was incompatible with the GPL. One of the cool things about the FSF is that they take the time to work out the legal issues first, and then they worry about the technical issues. This means that FSF projects are able to avoid tricky licensing issues like those found early on in the KDE project and more recently in the Python project. As a developer that isn't interested in performing my own legal audit I appreciate the efforts of the FSF to point out possible problems with software licenses. That way I can concentrate on developing, and not on stupid legal issues.
In your case, if you are interested in using QT with proprietary libraries then you basically have one of two choices. You can pay for the commercially licensed version of QT, or you can stop using QT. Blaming your inability to use the GPLed version of QT with commercial libraries on the FSF is ridiculous, Trolltech is the group that chose the license for QT, not the FSF. The FSF's widget set (GTK+) is licensed under the LGPL. You could use that library with Sybase's dblibrary without any problems at all.
I actually agree with you that GPLed libraries are problematic. Fortunately the FSF generally doesn't GPL their libraries. Commercial entities (like Trolltech), however, have a lot of incentive to GPL their libraries. That way they can get exposure for their toolkit among Free Software Developers while still charging commercial developers for the use of their software.
That's Trolltech's entire business model. Blaming the FSF or the GPL for your problems is ridiculous. It's Trolltech and Sybase that are trying to charge you money for their libraries. The FSF is simply giving you their expert legal advice as to the legality of distributing software that combines GPLed libraries and commercial libraries.
If I own the copyright I can release the software under as many different licenses as I want. To prove this point why don't you surf on over to www.trolltech.com and purchase the commercial version of QT. You will notice that while the GPLed version of QT does not allow you to create closed source commercial software linking with the QT widget set, the commercial version does not have this feature (which is why it is being used in Kylix).
In other words your software can be free for people who are willing to release their source, and commercial for those that do not (and are willing to pay the price).
BSD style licenses, on the other hand, do not allow you to use this trick. Everyone gets your software for free, no matter what they want to do with it.
Yes, many Free Software developers are more concerned with cloning commercial software than paying for it. That doesn't mean, however, that Oracle becomes GPLed when they release a Linux version of their software (which is what Microsoft is intimating with their goofy press releases).
Oh, and these same cloned products often show up running on BSD as well. There is plenty of GPLed software running on BSD systems, and there are even BSD projects that are basically cloning commercial software. This doesn't have anything to do with licensing issues.
If this is Microsoft's game then it is backfiring pitifully. Even mainstream economic news sources are weighing in against Microsoft on these issues. And while Microsoft is poised to spend a pile of money on XP, this does not necessarily mean that they are the only voice being heard. When Microsoft weighs in with ridiculous claims about the GPL it isn't a horde of GPL fanatics that are answering the absurd claims, it is PR flacks at organizations like HP or IBM (both of which have released software critical to their future success under the GPL).
Quite frankly, most CIOs I know of listen more to these companies than to Microsoft.
As for the rest of your rant, it's old, tired, and misspelled to boot (the word you are looking for is loser). I can read Word documents in my email (and Excel spreadsheets, and Powerpoint presentations, etc.). There was a time, however, when that wasn't the case, and yet Linux kept on growing despite the fact that it basically had no desktop type applications when I first started using it.
And the reason for that is simple. Linux is a useful, flexible, and cost effective way to solve problems. Not all problems (yet), but enough to make it worth tracking. And the list of problems that Linux solves acceptably grows every day. While Microsoft must upsell their customers to new versions of their software to keep their company afloat, Linux can easily survive with nothing more than its present installation base. Linux will continue to do just fine.
And who knows, maybe Windows XP will fail to catch on with consumers. Microsoft has certainly done their best to make it unpalatable to consumers.
I really don't see how the naming convention outlined in the LSB helps RPM users. The major benefit of Debian packaging system is that all of the packages comply with Debian's strict standards, and are then tested together. In a nutshell if someone packages up a Debian package they can safely guess that zip-2.30-3 is the same on every Debian install. Whereas RedHat and SuSE might have zip RPMs that install zip in drastically different incompatible locations (and they may even be based on different software).
Debian provides a safe, non-commercial base on which to build. RedHat, SuSE, Caldera, and the other RPM distributions each are basically separate entities, with no correlation at all even at the most basic level. The LSB has tried to remedy this by making the packager put their name in the filename (as opposed to the SPEC file).
The LSB tries to patch this up by providing standard instances of about 125 shell utilities and a couple dozen libraries. Big whoop. Only the simplest of applications will be able to get by on the libraries provided (and the libraries provided will soon be ridiculously old to boot).
In other words nearly any application is going to require a substantial amount of non-LSB packages to run. And many pieces of software won't ever be available as LSB packages because they rely on newer features of the libraries in question.
Just to give you an example as to how crazy this is let's imagine that Sun were to create a piece of Gnome application that they wanted to distribute. Since Gnome isn't part of the spec, they would not only have to package their own software as an LSB package, but they would have to package all of Gnome as well, (because they can't rely on vendor RPM packages). This would make their application very large, and they would basically guarantee that they would have to maintain their own packages for all of Gnome. These packages would probably be incompatible with the version you already had installed and the version that HP, IBM, and every other vendor was using for their LSB Gnome apps. After all, we have quite a bit of confusion right now with only a limited number of Linux distributors, if everyone who wanted to sell a Gnome application had their own version of Gnome it would be even worse than the current mess.
On the other hand, they could simply develop with RedHat version ?.? as their target and rely on RedHat to package Gnome for them. Anyone else wishing to run their application would have to have a RedHat compatible version of Gnome. That's sounds trick, but it would almost certainly be available from your distribution vendor. Since most Linux libraries are quite backwards compatible, installation would probably be as easy as getting the newest version of Gnome and installing it.
The folks working on the LSB could have easily made the reference platform first. In fact, early incarnations of the LSB were supposed to be binary reference platforms (based on Debian).
They could have used a subset of Debian stable as the reference platform, and simply documented what was available in their subset instead of creating an "imaginary" distribution (that is not installable and therefor not tested in real life) and then perhaps creating a distribution based on it after the fact.
Now they have got an old snapshot of several GNU/Linux libraries, and they hope to get developers to use those libraries instead of the fancier versions that come with any modern distribution.
On the other hand, if a developer chooses to use the newer libraries bundled with RedHat, he will be able to successfully target the largest part of the Linux market (RedHat), and he gets the benefits of using the more modern technology. Besides any non-RedHat users who wish to run his software can simply download the appropriate libraries. Linuxers have been doing this for some time now, and it really isn't that big a deal.
You apparently are confused as to what a reference platform is. A reference platform, in this case, would be a distribution with only the libraries that the LSB provides included. Then software that ran on the LSB reference platform would be guaranteed to run on any LSB compliant distribution. Caldera might be LSB compliant, but they aren't the LSB reference platform by any stretch of the imagination.
The tools included with the LSB make it possible to automate checking what libraries your application links, but they are not nearly as straightforward to use as simply having a reference platform.
Yahoo doesn't equal "market share." The fact of the matter is that FreeBSD, for all of it's many benefits, has something like an order of magnitude less installations than Linux. This doesn't make FreeBSD a bad OS, but it isn't nearly as popular as Linux (which is what market share measures).
Miguel is essentially right. There are no legal reasons why Microsoft couldn't release their software for Linux. Plenty of companies produce commercial software for Linux, and I don't see them handing out source code.
Microsoft chose FreeBSD because it isn't popular enough to really be a threat to Windows (yet). Not that their software is really going to be much of a gift. It is nothing more than a watered down implementation of their new language and runtime. Not only is it lacking the Forms and Database layers, but it is also missing the so-called "high performance" garbage collector and compiler.
Microsoft says that their reasoning behind this is that they don't like the GPL, but that's patently absurd. They simply don't like competition, and Linux is increasingly becoming direct competition to Windows. FreeBSD is good stuff, but it isn't being installed at near the rate that Linux is, and so Microsoft sees it as "safe" to port to.
Microsoft isn't interested in undermining the legality of the GPL because doing so would weaken copyright law. Since Microsoft relies on copyright law as the basis for their money making machine the last thing that they are likely to do is subvert the GPL.
Microsoft's response is dumb, but they really don't have much else they can do. They have tried ignoring Linux (that failed). They tried discrediting Linux (failed). They even tried cooking up some anti-Linux benchmarks. Many of the improvements in the 2.4 series of the kernel are directly attributable to Microsoft and the money they spent on Mindcraft benchmarks.
You can bet they won't do that again.
Microsoft can't embrace and extend GPLed software, and they can't buy enough Linux developers to make a difference, and so they are stuck with these crappy tactics (which are likewise bound to fail).
Yes, but this version of the LSB is so retarded that basically the developer is going to either have to ship every single library that it links (including glibc if it wants some of the new features found there), or the developer is going to have to say "Supports RedHat 7.? only."
Not to mention the fact that there is no reference platform for the LSB. Making it possible for the developer to create an application that they think is LSB compliant, but which still has bugs on LSB compliant distributions (which may still have different versions of the required libraries).
Fortunately since RedHat bases its distribution on open libraries it is easy for the end user (or the distribution makers) to simply include match RedHat's choice of libraries. It's a pain in the neck, but until the other distributions are willing to push for a competitive useable LSB RedHat will remain the de-facto standard.
I am not a RedHat user, and I wouldn't want to target the LSB, why should the developers that are currently using RedHat as a target make the switch?
Standards are good, but you wouldn't want to be stuck with these particular standards forever. The LSB talks about the libraries that are supposed to be included with a Linux distribution, and goes as far as to specifically state which versions they should be (although not which minor version). In other words you get things like ncurses 4 and 5 should be included, the tar included is GNU tar version (I don't know which version they specified) and the shell is bash version (whatever).
That's fine and dandy for now, but two years from now LSB version 1.0 is going to look pathetic. Developers aren't going to want to stick to it because the software available will be so much nicer. Heck, the software available now is nicer than what is specified in the LSB.
Not to mention the fact that their isn't an LSB reference platform. The only way to make sure that your package is LSB compliant is to do a code audit. If the commercial developers were willing to do this then they would already be making portable packages. The stuff listed in the LSB is not rocket science. In fact, every single distribution has had to solve all of the relevant problems. The LSB won't solve a thing.
The original plan for the LSB was to build a reference platform. This platform would probably have been the Debian base platform plus some other basic necessities. This way the commercial developer could have actually tested his application against the reference, and all the other distributions would have had to do was make sure they included at least an optional set of libraries that was precisely like the libraries included in the LSB reference. That would have been useful, and it would have allowed for the standard to migrate intelligently with time. Every time you got a major Debian stable rev (about once a year) the LSB would rev as well, and everyone would know ahead of time where the new standard was going (they just would have to participate in the Debian mailing lists.
All is not lost, however. Linux still has a standard. It's a de-facto standard, but it is also an open standard, and so it will do. That standard is the freely available bits in RedHat Linux. It will probably tick off Caldera, SuSE, and Mandrake that they will have to continue to track what the folks at RedHat are up to, but it is their own fault for making the LSB so unpaletable. None of the commercial Linux vendors wanted to do the right thing and create a standard that was actually competitive with their own distributions, and so they created a standard that is so unpalatable to developers that it will never get used.
The LSB is useless enough as it is. Your plan would basically tell the developer, "This platform is about as friendly as a rabid Komodo dragon, feel free to pay no attention to our specifications."
You need to remember the problem that the LSB is designed to solve. The LSB is designed to give commercial developers a reference platform that they can develop to and then be guaranteed that their software will run on every LSB compliant Linux distribution. Right now most commercial developers simply target RedHat, and then let the rest of us that don't use RedHat sort out how we are going to get the software to run on our platform o' choice. Sometimes, for various reasons, the commercial vendor will even admit to supporting several different distributions, but they don't like the work that this takes, especially considering the size of the market.
So the LSB folks put together a set of minimum requirements for a Linux distribution, and quite frankly, my guess is that they are too minimum to really be of any use.
You see, while you might be interested in the smallest Linux distribution possible, most people want the added features of GNU tar and bash, and you can bet that commercial developers are going to want a lot more than that. Unfortunately, since the LSB is not a distribution in itself they almost certainly will get more than that. They will continue to do precisely what they are doing now. They will develop their software on RedHat, using RedHat's cutting edge libraries, and when they are finished and want to see what it would take to make their distribution LSB compliant they will realize that it would take a significant amount of work. The LSB is like a snapshot of GNU/Linux frozen in time. It's sort of like running Debian Stable. It's chuck full of good stable software, but chances are the version that you really want to be running is not the one available. There are a lot of features that simply aren't available if you are only using the LSB libraries. If the LSB was a standalone distribution, then you could at least use it as a development platform. But since it's not, commercial developers will continue to do what they do now. They will target RedHat, and force the other distributions to follow RedHat's lead.
Oh well, I personally use Debian, but I can't help but think that we could certainly do worse than using RedHat as a de-facto standard. At least they are committed to Free Software. The standard at least will be an open standard.
That is perhaps one of the most insightful things that I have ever heard on Slashdot. That was the original reason that I set up an X terminal as well. A buddy of mine was using them in his small business, and he wanted to know if sound would be possible. So I dug up some old hardware and I tried it out (it is).
When I was done I found that I had something useful for myself as well. Being able to use my fancy computer while I wasn't in my fort was very nice. Being able to introduce my wife to Linux without forcing her to go out into my fort (which she would then require I clean), was even nicer.
But mostly I did it to see how to do it. Come to think of it that's probably the prime motivation for nearly every piece of software on my home LAN.
Thanks for the conversation. It seems that every time I despair that/. has gone to the dogs something like this happens and my faith is restored.
Slashdot Mirror
Which is why Office XP is going to have a hard time making inroads in the market. Microsoft isn't going to let you install it without guaranteeing you paid for it, and no one is going to be interested in paying nearly $600 for an Office suite.
Sure, there will be "cracks" for Office, but the majority of folks aren't interested in actively stealing Office. They won't go out of their way. They will simply stick with what they have got.
Yes, but the article would have then become a useful comparison. As it now stands it's no different than me rounding up a bunch of Linux users and reporting that 9 out of 10 computer experts think Windows sucks.
A little table explaining methodology (was it a double blind test) and the bitrates for each sample would have at least been something.
You said that much better than I did, but that's pretty much what I meant. I certainly did not mean to infer that IBM "got it" back then when it came to open standards. They simply considered the PC a toy, and not worth the engineering effort to create from scratch.
And yes, they did all kinds of things to try and close the platform, but none of them worked, for the same reasons that Linux is still gaining ground despite everything Microsoft can do, and despite the fact that for some uses it really isn't a very good solution.
Customers like open standards, they are generally less expensive, and they allow freedom and flexibility. Basically customers will always choose the solution that is "good enough" at the lowest possible price. As Linux improves it is rapidly becoming "good enough" for a widening range of uses. Microsoft, as the market leader, can do what they want to try and stop this migration, but in the end the only feasible defense is to give their customers comparably priced and comparably open solutions. That is why .NET is based on open standards, Microsoft has to compete in this space with Free Software. Hopefully as Gnome, KDE, Mozilla, and OpenOffice improve these technologies will likewise force Microsoft's hand on the desktop.
It'll never happen. People think that Linux has a chicken and egg problem getting access to commercial applications. Any system that charges ISPs for access to content has a much larger problem. They have to sign up content providers that have content that a significant amount of an ISPs customers are willing to pay for, and then they have to convince that content provider that it is a better idea to sign up with their service (and pay the requisite commission) than to simply charge the end user themselves.
Fat chance of that happening.
Especially since many of the content providers already are access providers. AOL/Time Warner stands out as the best example. They are already using their "special" content as a hook to lure customers. Many of the other "large" ISPs have the same business model. One of their hooks is special proprietary information or tools. There is literally no chance that they are going to pay dues so that their subscribers can view their competitors for-pay sites, as they would rather have their customers see their own commercial sites. And without AOL's customers, and the customers from the non-complying normal ISPs the service will be severely limited in its market.
The fact of the matter is that once a product becomes a commodity, putting it back in the proprietary bag is nearly impossible. I am surprised this particular company isn't trying to charge for air and sunshine while they are at it.
Currently ISPs are running on razor thing margins. They aren't going to pay access fees for their users. Web companies are going to have to find a way to charge their customers directly, or they are going to have to find a way to show advertisers that their advertisements actually work. Micropayments isn't going to work, and macropayments are even less likely to work.
Sort of. IBM could have easily closed the entire IBM PC architecture. That way you would have had to buy all of your components from IBM or from IBM approved sources. But instead they put all of their eggs in the easily cloneable BIOS, and left the rest of the architecture open.
The reason that Compaq cloned the BIOS is that IBM had already created a large market for IBM PCs. This wasn't due to the fact that IBM PCs were very good, but rather that it was inexpensive to purchase nifty IBM PC add-ons (from whatever manufacturer you wanted). They realized it would be better to break into IBM's established market than to try and create a market for their own incompatible machine.
When Compaq opened up the IBM compatible market they simply amplified the original openness of the platform.
There are two problems with NuSphere's version of MySQL. The first is the trademark violation, and the second is the fact that they are distributing a proprietary extension statically linked to a GPLed product. Both of these actions are illegal, immoral, and contrary to what most Free Software advocates believe is the right thing to do.
If NuSphere took the source code from MySQL and released it as NuSQL (or something), and they released the source code to the Gemini extensions, then that would be a horse of a different color, and I personally wouldn't have a problem with their actions.
One of the Freedoms that Free Software advocates are fighting for is the right to fork the source code. This happens fairly often, and it is considered good form to rename the new project. In the case of a trademark dispute, it is not only good form, it is legally imperative. No one in the Free Software world gets excited about the Emacs/XEmacs split, or the Samba/Samba TNG split, or the now rectified gcc/egcs split. Individual developers might root for one side or the other, but that's about competition, and not disgust.
What NuSphere has done is illegal and disgusting. Pretending to cover over their greed with statements about the "community" is ridiculous at best. If they cared about the Free Software community they would follow the GPL and release their source code. If they had an ounce of integrity they would follow Free Software "tradition" and rename their project when they forked it. The fact that MySQL AB has to go to court to push the folks at NuSphere into doing what's right (and legally necessary) simply shows how far removed NuSphere is from the rest of the community.
You are absolutely correct about how the MySQL "benchmarks" work. MySQL's crufty benchmarks are a Perl script that simulates one user doing a whole lot of goofy things like dropping tables and dropping and creating connections. Quite frankly I can't think of a single benchmark that would be less useful for benchmarking a SMP system. I was actually surprised when the folks making up the benchmarks didn't simply add up the respective bogomips scores from each processor and call it a day.
I generally don't criticize benchmarking tests like these because I don't consider myself knowledgeable enough, but even I know that running one instance of the MySQL benchmark is not a good SMP test.
The PC industry is all about commodity hardware. There have been very few cases where a closed hardware specification has done well economically. In fact, IBM's effort to open their hardware was what guaranteed that the Macintosh didn't become the dominant PC computer architecture. Early Macs were a lot nicer machines than their IBM compatible counterparts, but the IBM compatible machines were cheaper (due to commodity hardware) and so they won out in the end.
Since then IBM tried unsuccessfully to corner the PC market with their MCA bus, and Rambus is currently learning that consumers (and more importantly memory manufacturers) aren't interested in their proprietary memory.
Hardware manufacturers that make it hard for their customers to actually use their hardware are only shooting themselves in the foot. They gain absolutely nothing by creating hardware that can't be hacked, and they lose potential sales from people that want to tweak their hardware.
The only folks that are concerned about the open nature of hardware are the folks who make their money from so-called "intellectual property." The RIAA and the MPAA don't want you to mess with your hardware because it might make it easier for you to copy their songs and movies. Microsoft doesn't want you to open up your computer because it makes it harder for them to keep you from copying their OS. Also open hardware specifications make it possible for alternative OSes to write drivers for the hardware. Microsoft would rather have Windows only hardware.
The hardware folks, however, don't really care if you are stealing songs, movies, or software. In fact, they would love for you to steal your software (that would give you more money to spend on hardware). They have something tangible to sell, and they know that their margins are tight enough that they had better not tick of their customers. They know that if they are quick to jump on the "closed hardware" bandwagon they will find that their customers are simply buying from their competitors, and that they have limited their own marketability simply to help someone else's business.
Fah! We might as well use a cannon instead of a pitcher as well. In fact, I am sure that with a little engineering we could get a supersonic fastball. We might need to replace the catcher, but that shouldn't be hard as you wouldn't need to worry about errant pitches. We should also consider arming the first basemen with battle-axes. That way if a hitter does manage to connect with the ball the first baseman can make sure that the poor fool doesn't make it to first base. Heck, why not just give all the players automatic weapons and see which team has the most players standing at the end of nine innings.
This is precisely the reason why there are rules to baseball. Everyone knows that you could have better pitchers just by letting them spit on the ball. But the point is the competition. Someone somewhere along the way decided that spitting on the balls was illegal (for whatever reason), and so now hitters don't have to worry about "spitballs." The rules may be strange (and sometimes fairly arbitrary), but folks like to watch and play baseball, and the rules allow the game to proceed fairly. Mixing in a robot pitcher may be great for hitting practice, but it would almost certainly be against the rules for competition, and since it wouldn't really be that fun to watch it almost certainly won't ever become legal.
I find the ads on sites like kuro5hin.org and slashdot are often quite helpful. I generally am actually interested in the things that get advertised on these sites. I would almost pay for more ads, and would certainly not be interested in seeing them removed. In that respect slashdot is no different from any other publication. They have the opportunity to market to a unique niche of people that they can pretty much guarantee is going to be interested in a certain set of products and services. Eventually advertisers are going to realize that this is the case and sites that are able to build large targetted audiences will be able to sell advertising without too much trouble.
Exactly. Of course not all transactions go through a bank. When I pay the neighbor kid to mow my lawn, there is a good chance that he spends it before he puts it in the bank (so that transaction would be transparent). Also with the current system there is no way for the bank to know how much change Subway gave you. Perhaps you just went in to get change for your $20. When that $20 shows up at the bank the bankers know who originally withdrew that bill, but they don't know anything about the transactions that might have happened since it left the bank.
I personally think this sort of device would be great if it were used as a way to stop counterfeiters. However, if they are going to use it to link people to transactions, well that's bad. Of course, in order to get that sort of information business would have to be required to share transaction information with the banks. I don't see that happening. That's pretty sensitive stuff.
Actually this is precisely why Microsoft wants to sell software as a service. Microsoft has finally realized that they are to the point where they can't coax users into upgrading by promising them a version of Windows without the major flaws. So instead the want to charge their users by the month whether they release new software or not.
Selling software as a product really isn't a very good fit, and has led to many of the abuses that we are currently subjected to. Of course, Microsoft's proprietary software would even be worse when sold as a service. Microsof would probably still not be too terribly interested in fixing bugs. I am sure that they would rather spend their time making sure they used their position to worm their way into every financial transaction.
Once QT was GPLed the Free Software Foundation ceased to have any problem with the license. Before that QT was released under a license that the FSF Lawyers felt was incompatible with the GPL. One of the cool things about the FSF is that they take the time to work out the legal issues first, and then they worry about the technical issues. This means that FSF projects are able to avoid tricky licensing issues like those found early on in the KDE project and more recently in the Python project. As a developer that isn't interested in performing my own legal audit I appreciate the efforts of the FSF to point out possible problems with software licenses. That way I can concentrate on developing, and not on stupid legal issues.
In your case, if you are interested in using QT with proprietary libraries then you basically have one of two choices. You can pay for the commercially licensed version of QT, or you can stop using QT. Blaming your inability to use the GPLed version of QT with commercial libraries on the FSF is ridiculous, Trolltech is the group that chose the license for QT, not the FSF. The FSF's widget set (GTK+) is licensed under the LGPL. You could use that library with Sybase's dblibrary without any problems at all.
I actually agree with you that GPLed libraries are problematic. Fortunately the FSF generally doesn't GPL their libraries. Commercial entities (like Trolltech), however, have a lot of incentive to GPL their libraries. That way they can get exposure for their toolkit among Free Software Developers while still charging commercial developers for the use of their software.
That's Trolltech's entire business model. Blaming the FSF or the GPL for your problems is ridiculous. It's Trolltech and Sybase that are trying to charge you money for their libraries. The FSF is simply giving you their expert legal advice as to the legality of distributing software that combines GPLed libraries and commercial libraries.
If I own the copyright I can release the software under as many different licenses as I want. To prove this point why don't you surf on over to www.trolltech.com and purchase the commercial version of QT. You will notice that while the GPLed version of QT does not allow you to create closed source commercial software linking with the QT widget set, the commercial version does not have this feature (which is why it is being used in Kylix).
In other words your software can be free for people who are willing to release their source, and commercial for those that do not (and are willing to pay the price).
BSD style licenses, on the other hand, do not allow you to use this trick. Everyone gets your software for free, no matter what they want to do with it.
Nice try though. You almost had a point.
Yes, many Free Software developers are more concerned with cloning commercial software than paying for it. That doesn't mean, however, that Oracle becomes GPLed when they release a Linux version of their software (which is what Microsoft is intimating with their goofy press releases).
Oh, and these same cloned products often show up running on BSD as well. There is plenty of GPLed software running on BSD systems, and there are even BSD projects that are basically cloning commercial software. This doesn't have anything to do with licensing issues.
If this is Microsoft's game then it is backfiring pitifully. Even mainstream economic news sources are weighing in against Microsoft on these issues. And while Microsoft is poised to spend a pile of money on XP, this does not necessarily mean that they are the only voice being heard. When Microsoft weighs in with ridiculous claims about the GPL it isn't a horde of GPL fanatics that are answering the absurd claims, it is PR flacks at organizations like HP or IBM (both of which have released software critical to their future success under the GPL).
Quite frankly, most CIOs I know of listen more to these companies than to Microsoft.
As for the rest of your rant, it's old, tired, and misspelled to boot (the word you are looking for is loser). I can read Word documents in my email (and Excel spreadsheets, and Powerpoint presentations, etc.). There was a time, however, when that wasn't the case, and yet Linux kept on growing despite the fact that it basically had no desktop type applications when I first started using it.
And the reason for that is simple. Linux is a useful, flexible, and cost effective way to solve problems. Not all problems (yet), but enough to make it worth tracking. And the list of problems that Linux solves acceptably grows every day. While Microsoft must upsell their customers to new versions of their software to keep their company afloat, Linux can easily survive with nothing more than its present installation base. Linux will continue to do just fine.
And who knows, maybe Windows XP will fail to catch on with consumers. Microsoft has certainly done their best to make it unpalatable to consumers.
I really don't see how the naming convention outlined in the LSB helps RPM users. The major benefit of Debian packaging system is that all of the packages comply with Debian's strict standards, and are then tested together. In a nutshell if someone packages up a Debian package they can safely guess that zip-2.30-3 is the same on every Debian install. Whereas RedHat and SuSE might have zip RPMs that install zip in drastically different incompatible locations (and they may even be based on different software).
Debian provides a safe, non-commercial base on which to build. RedHat, SuSE, Caldera, and the other RPM distributions each are basically separate entities, with no correlation at all even at the most basic level. The LSB has tried to remedy this by making the packager put their name in the filename (as opposed to the SPEC file).
The LSB tries to patch this up by providing standard instances of about 125 shell utilities and a couple dozen libraries. Big whoop. Only the simplest of applications will be able to get by on the libraries provided (and the libraries provided will soon be ridiculously old to boot).
In other words nearly any application is going to require a substantial amount of non-LSB packages to run. And many pieces of software won't ever be available as LSB packages because they rely on newer features of the libraries in question.
Just to give you an example as to how crazy this is let's imagine that Sun were to create a piece of Gnome application that they wanted to distribute. Since Gnome isn't part of the spec, they would not only have to package their own software as an LSB package, but they would have to package all of Gnome as well, (because they can't rely on vendor RPM packages). This would make their application very large, and they would basically guarantee that they would have to maintain their own packages for all of Gnome. These packages would probably be incompatible with the version you already had installed and the version that HP, IBM, and every other vendor was using for their LSB Gnome apps. After all, we have quite a bit of confusion right now with only a limited number of Linux distributors, if everyone who wanted to sell a Gnome application had their own version of Gnome it would be even worse than the current mess.
On the other hand, they could simply develop with RedHat version ?.? as their target and rely on RedHat to package Gnome for them. Anyone else wishing to run their application would have to have a RedHat compatible version of Gnome. That's sounds trick, but it would almost certainly be available from your distribution vendor. Since most Linux libraries are quite backwards compatible, installation would probably be as easy as getting the newest version of Gnome and installing it.
The folks working on the LSB could have easily made the reference platform first. In fact, early incarnations of the LSB were supposed to be binary reference platforms (based on Debian).
They could have used a subset of Debian stable as the reference platform, and simply documented what was available in their subset instead of creating an "imaginary" distribution (that is not installable and therefor not tested in real life) and then perhaps creating a distribution based on it after the fact.
Now they have got an old snapshot of several GNU/Linux libraries, and they hope to get developers to use those libraries instead of the fancier versions that come with any modern distribution.
On the other hand, if a developer chooses to use the newer libraries bundled with RedHat, he will be able to successfully target the largest part of the Linux market (RedHat), and he gets the benefits of using the more modern technology. Besides any non-RedHat users who wish to run his software can simply download the appropriate libraries. Linuxers have been doing this for some time now, and it really isn't that big a deal.
You apparently are confused as to what a reference platform is. A reference platform, in this case, would be a distribution with only the libraries that the LSB provides included. Then software that ran on the LSB reference platform would be guaranteed to run on any LSB compliant distribution. Caldera might be LSB compliant, but they aren't the LSB reference platform by any stretch of the imagination.
The tools included with the LSB make it possible to automate checking what libraries your application links, but they are not nearly as straightforward to use as simply having a reference platform.
Yahoo doesn't equal "market share." The fact of the matter is that FreeBSD, for all of it's many benefits, has something like an order of magnitude less installations than Linux. This doesn't make FreeBSD a bad OS, but it isn't nearly as popular as Linux (which is what market share measures).
Miguel is essentially right. There are no legal reasons why Microsoft couldn't release their software for Linux. Plenty of companies produce commercial software for Linux, and I don't see them handing out source code.
Microsoft chose FreeBSD because it isn't popular enough to really be a threat to Windows (yet). Not that their software is really going to be much of a gift. It is nothing more than a watered down implementation of their new language and runtime. Not only is it lacking the Forms and Database layers, but it is also missing the so-called "high performance" garbage collector and compiler.
Microsoft says that their reasoning behind this is that they don't like the GPL, but that's patently absurd. They simply don't like competition, and Linux is increasingly becoming direct competition to Windows. FreeBSD is good stuff, but it isn't being installed at near the rate that Linux is, and so Microsoft sees it as "safe" to port to.
Microsoft isn't interested in undermining the legality of the GPL because doing so would weaken copyright law. Since Microsoft relies on copyright law as the basis for their money making machine the last thing that they are likely to do is subvert the GPL.
Microsoft's response is dumb, but they really don't have much else they can do. They have tried ignoring Linux (that failed). They tried discrediting Linux (failed). They even tried cooking up some anti-Linux benchmarks. Many of the improvements in the 2.4 series of the kernel are directly attributable to Microsoft and the money they spent on Mindcraft benchmarks.
You can bet they won't do that again.
Microsoft can't embrace and extend GPLed software, and they can't buy enough Linux developers to make a difference, and so they are stuck with these crappy tactics (which are likewise bound to fail).
It will be interesting to see what happens next.
Yes, but this version of the LSB is so retarded that basically the developer is going to either have to ship every single library that it links (including glibc if it wants some of the new features found there), or the developer is going to have to say "Supports RedHat 7.? only."
Not to mention the fact that there is no reference platform for the LSB. Making it possible for the developer to create an application that they think is LSB compliant, but which still has bugs on LSB compliant distributions (which may still have different versions of the required libraries).
Fortunately since RedHat bases its distribution on open libraries it is easy for the end user (or the distribution makers) to simply include match RedHat's choice of libraries. It's a pain in the neck, but until the other distributions are willing to push for a competitive useable LSB RedHat will remain the de-facto standard.
I am not a RedHat user, and I wouldn't want to target the LSB, why should the developers that are currently using RedHat as a target make the switch?
Standards are good, but you wouldn't want to be stuck with these particular standards forever. The LSB talks about the libraries that are supposed to be included with a Linux distribution, and goes as far as to specifically state which versions they should be (although not which minor version). In other words you get things like ncurses 4 and 5 should be included, the tar included is GNU tar version (I don't know which version they specified) and the shell is bash version (whatever).
That's fine and dandy for now, but two years from now LSB version 1.0 is going to look pathetic. Developers aren't going to want to stick to it because the software available will be so much nicer. Heck, the software available now is nicer than what is specified in the LSB.
Not to mention the fact that their isn't an LSB reference platform. The only way to make sure that your package is LSB compliant is to do a code audit. If the commercial developers were willing to do this then they would already be making portable packages. The stuff listed in the LSB is not rocket science. In fact, every single distribution has had to solve all of the relevant problems. The LSB won't solve a thing.
The original plan for the LSB was to build a reference platform. This platform would probably have been the Debian base platform plus some other basic necessities. This way the commercial developer could have actually tested his application against the reference, and all the other distributions would have had to do was make sure they included at least an optional set of libraries that was precisely like the libraries included in the LSB reference. That would have been useful, and it would have allowed for the standard to migrate intelligently with time. Every time you got a major Debian stable rev (about once a year) the LSB would rev as well, and everyone would know ahead of time where the new standard was going (they just would have to participate in the Debian mailing lists.
All is not lost, however. Linux still has a standard. It's a de-facto standard, but it is also an open standard, and so it will do. That standard is the freely available bits in RedHat Linux. It will probably tick off Caldera, SuSE, and Mandrake that they will have to continue to track what the folks at RedHat are up to, but it is their own fault for making the LSB so unpaletable. None of the commercial Linux vendors wanted to do the right thing and create a standard that was actually competitive with their own distributions, and so they created a standard that is so unpalatable to developers that it will never get used.
The LSB is useless enough as it is. Your plan would basically tell the developer, "This platform is about as friendly as a rabid Komodo dragon, feel free to pay no attention to our specifications."
You need to remember the problem that the LSB is designed to solve. The LSB is designed to give commercial developers a reference platform that they can develop to and then be guaranteed that their software will run on every LSB compliant Linux distribution. Right now most commercial developers simply target RedHat, and then let the rest of us that don't use RedHat sort out how we are going to get the software to run on our platform o' choice. Sometimes, for various reasons, the commercial vendor will even admit to supporting several different distributions, but they don't like the work that this takes, especially considering the size of the market.
So the LSB folks put together a set of minimum requirements for a Linux distribution, and quite frankly, my guess is that they are too minimum to really be of any use.
You see, while you might be interested in the smallest Linux distribution possible, most people want the added features of GNU tar and bash, and you can bet that commercial developers are going to want a lot more than that. Unfortunately, since the LSB is not a distribution in itself they almost certainly will get more than that. They will continue to do precisely what they are doing now. They will develop their software on RedHat, using RedHat's cutting edge libraries, and when they are finished and want to see what it would take to make their distribution LSB compliant they will realize that it would take a significant amount of work. The LSB is like a snapshot of GNU/Linux frozen in time. It's sort of like running Debian Stable. It's chuck full of good stable software, but chances are the version that you really want to be running is not the one available. There are a lot of features that simply aren't available if you are only using the LSB libraries. If the LSB was a standalone distribution, then you could at least use it as a development platform. But since it's not, commercial developers will continue to do what they do now. They will target RedHat, and force the other distributions to follow RedHat's lead.
Oh well, I personally use Debian, but I can't help but think that we could certainly do worse than using RedHat as a de-facto standard. At least they are committed to Free Software. The standard at least will be an open standard.
That is perhaps one of the most insightful things that I have ever heard on Slashdot. That was the original reason that I set up an X terminal as well. A buddy of mine was using them in his small business, and he wanted to know if sound would be possible. So I dug up some old hardware and I tried it out (it is).
When I was done I found that I had something useful for myself as well. Being able to use my fancy computer while I wasn't in my fort was very nice. Being able to introduce my wife to Linux without forcing her to go out into my fort (which she would then require I clean), was even nicer.
But mostly I did it to see how to do it. Come to think of it that's probably the prime motivation for nearly every piece of software on my home LAN.
Thanks for the conversation. It seems that every time I despair that /. has gone to the dogs something like this happens and my faith is restored.