It's M$ not because they "want to make money", but because they place the accumulation of money ahead of actual innovation and leadership in the market.
It would not be M$ if they competed fairly and won in the marketplace because they had the best product. It is M$ because they feel it is more important to lock their competitors out of their APIs and file formats so they can make more monopoly money through controlling consumer migration, instead of creating interoperable and high quality software and advancing the state of the art in computing.
Being a monopoly does not mean that you have 100% market share. A monopoly is defined as being the producer of a product for which there are no substitutes. In order to substitute (say) a Linux distribution for Windows, it would have to read NTFS, open your document formats, participate on your Samba/Active Directory network, etc. If it cannot do those things, it is not a substitute.
Some functionality along these lines has been attained by reverse engineering, but the fact of the matter is that Microsoft does everything it can to keep competitors from producing software which interoperates with the Windows platform. In the end, what this accomplishes is to prevent competitors from developing substitutes to Windows. Thus, such behavior fits the definition of conspiring to monopolize a market.
Note that just because a substitute product to Windows *could* be developed, doesn't imply that it *would* be developed (though there is strong evidence to suggest that it would). Regardless of whether or not a substitute _would_ be developed in the case that Microsoft didn't try to prevent it from being developed, the key issue here is the fact that Microsoft is _attempting_ to prevent substitutes from being developed, through its hidden APIs, secret file formats and protocols, and software patents.
Attempting to gain a monopoly in a market is also an antitrust crime under the Sherman Act. Abusing a monopoly one has already gained is wholly separate from that.
Every person who shall monopolize, or attempt to monopolize, or combine or conspire with any other person or persons, to monopolize any part of the trade or commerce among the several States, or with foreign nations, shall be deemed guilty of a felony, and, on conviction thereof, shall be punished by fine not exceeding $10,000,000 if a corporation, or, if any other person, $350,000, or by imprisonment not exceeding three years, or by both said punishments, in the discretion of the court.
I did not advocate "putting a stop to Microsoft". Neither is the EU, apparently. They have given Microsoft a slap-on-the-wrist fine that goes no further than being symbolic, and will hardly sink their business. The most important part of this deal is that people who wish to untrench Microsoft will finally have the technical information necessary to fully interoperate with Microsoft systems. That is the key to competition in the software industry; you must first interoperate with existing products, before you can even dream of replacing them.
It comes down to the principle of substitutes. If you don't or can't interoperate with existing infrastructure, very few consumers will consider your product because it does not qualify as a substitute for the existing product. The requirement of Microsoft to divulge technical information to potential competitors will ensure that Microsoft's products must compete against substitutes on their merits, and not because they have the legal framework in place to prevent would-be competitors from designing substitutes for their products.
Like I indicated in another post, there is nothing to stop Microsoft from having their own "windows-only" forked version of Java. And nothing to stop from the GNU/Debian crowd to have their own "puritanical" version. And nothing to stop from IBM to have their own "enterprise-ready" version of Java.
Java is a trademark. What will stop these gratutious forks is that they can not call it Java if they have modified and redistributed Sun's codebase on their own.
People choose Microsoft because it offers benefits that they consider worthwhile, and as Microsoft's success as a business shows, people are willing to pay for these benefits.
People paying money for products is only one half of a healthy market. Innovation by the capitalists is the other half.
Microsoft is not innovating because it doesn't have to. It has an extremely solid framework in place ranging from software interoperability trade secrets to software patents to vendor lock-in contracts, all to ensure that no one will be able to compete with them legally or that the cost of starting up will be so great that no one will bother.
Their entire business foundation is placed upon a government intervention known as copyright, which has also not served the market. If it were 14 years and if software copyrights required registration of the machine-readable source code with the copyright office, we would already be benefiting from the Windows code of NT 3.1 vintage to serve interoperability efforts, even when they are unwilling to provide interoperability details themselves. However, instead, they are allowed to retain a perpetual monopoly on their software legacy, and any interoperability must be attained through reverse engineering. That is not a good formula for competition.
Without competition, innovation is not happening at the rate that it would in a healthy competitive market. You can sit there and argue all day that Microsoft deserves to reap the riches of their monopoly position without government interference, but every day they sit on their haunches deciding whether it's worth bothering to improve their products, progress in the state of software engineering and the leading edge for users is being held back. I don't know what dogma you subscribe to, but economists seem to have a pretty good formula for improving society, and competition is a fundamental basis of it. Where competition does not naturally exist, it is government's job to try to stimulate it as part of a successful economic policy.
It is utterly ridiculous that we have to depend on open source loving hobbyists and small businesses for the little innovation that comes out of the software industry today. Microsoft may be a monopoly, but they are no market leader. They are a disgrace to the computing industry. I hope this decision changes them permanently for the better.
Slashdot readers (tm) support open standards: Ogg Vorbis, MP3, MPEG-4, FLAC.
Are you fucking kidding me? Half of your list is nowhere near "open standards". Maybe you think MP3 and MPEG-4 are "open" because you have software that can utilize them, but each of them has patent owners who would very much like to take you or the author of the software to court, for not paying the requisite licensing fees.
There are things Microsoft has done that I don't think were right, but bundling software with the OS isn't one of them.
You're right, because bundling isn't the problem. Product _tying_ is the problem.
It is much different to say:
"We are giving you product X with the purchase of product Y, whether you want it or not"
than to say:
"We are giving you product X with the purchase of product Y, and not only can you not remove product Y from your machine (as it is an integral part of the operating system), but we have taken special precautions to make sure that only product Y has access to features of product X that make it particularly useful; and by the way, your system provider signed a contract stating that they would not install product Z on this machine, so you're on your own if you want to install it. And don't complain to us if it is mysteriously disabled every now and then."
Linux distributions don't even compare. Yes, Mozilla is bundled, but if I want to get rid of it and use something else, it's nothing more than a dpkg --purge.
Bundling is not illegal. Product tying is legal too, except that it is a common technique by which a monopoly position is frequently abused, so it is something that frequently comes up in these cases when you are trying a company for abusing a monopoly position.
I was recently threatened with a lawsuit because the BSA found a copy of Watcom C++ 10 on my web server. You can find more details at the Open Watcom newsgroup from a few weeks back, under a thread about library licensing.
I was absolutely dumbstruck that they would spend the time and money to search out and C&D me on such an inconsequential item, an 8 year old compiler. Even more ludicrous is that this compiler was released as open source not too long ago. It is possible that people whose code was not included in the open source release might not like it to be distributed without permission, but they claimed to be acting on behalf of Sybase. The people who open sourced Watcom in the first place!
I removed the file after an fruitless email exchange and several calls from my ISP. It's just not worth the bother to fight the copyright cops, no matter how illogical their actions are.
When are we going to see some action on Jeff Merkey's NWFS driver? The legal status of that code has been up in the air for years now, and as each day goes by, it will become harder and harder to bring it back up to sync with a modern kernel.
I had to rescue data from a Novell fileserver that had become corrupt, and NWFS was invaluable in doing so. But, I had to compile an ancient kernel specifically for that purpose.
If Novell really is committed to Linux, perhaps they can shed some light on this murky topic.
(1) question: does the GPL or BSD license have to be agreed to for simply executing a binary created by source code released under the GPL or BSD license? naively I assume it does not need to be agreed to, only if you redistribute.
Of course not. They are licenses, not contracts (EULAs). You can reject the license and continue to use the software. However, you are not allowed to make more than the one backup copy allowed by copyright law, and you are not allowed to redistribute the software without obtaining permission from the copyright holder.
Here is a good start.JACK clients are amazingly simple considering the power of the system. JACK is essentially a sound multiplexer server with extremely low latency (depending on the hardware). It doesn't do any of the nifty sample rate conversion or file loading that the sound servers do, which is why it makes sense to have the sound servers around. But if the sound servers were written against JACK, they would co-operate not only with each other, but with any other JACK clients on the system as well.
Take the sound servers and throw them out the door.
Better yet, persuade the developers of these sound servers to make their servers output sound via JACK instead of opening/dev/dsp directly. Sound servers are convenient, but they are completely unusable when they claim the sound device for themselves. Making the sound servers into JACK clients would allow them to all get along while allowing other JACK applications to run at the same time.
For stupid applications that insist on using ALSA PCM interface or/dev/dsp directly for trivial sound outputs, use a wrapper in similar design to aoss to redirect the output to JACK.
I manually looked through thousands of the held messages and found no false positives, so now anything that ClamAV scans goes directly to/dev/null.
Be careful. You might lose some messages you actually want, if anything ClamAV scans goes directly to/dev/null.
Joking aside, be careful that you check the exact exit code that you need to determine whether ClamAV found a virus or not. I was using a script called clamfilter.pl that someone else wrote. Since I was in a hurry, I went ahead and stuck it in my procmailrc without checking into it much. It seemed to work for quite a while. When one of the MS virus storms hit, I started sending all the viruses to/dev/null like you are. This turned out to be a mistake.
At some later point, we had a hard drive disaster that left most of/usr unreadable. However, the mail server was still running, and still using clamav to filter mail. Due to one of clamav's files becoming unreadable, clamav started exiting with a nonzero exit code, but not because it was finding a virus in the mail. Hence ALL mail went to/dev/null for a few days while the system was being rebuilt, and we didn't discover it until afterwards. I filed a bug with the clamfilter forum, but up till now the author hasn't fixed his (IMO dangerous) code that he is offering for general use.
The moral of the story is, if you are sending mail to/dev/null in ANY case, be damn sure that you are properly checking clamscan's exit code.
If the GPL can legally claim that anything linked with something already GPL'd MUST inherit the GPL regardless of whose work it is because that makes it a derived work, then SCO can make the same claim that anything developed to be linked against something with their copyright/license must inherit that.
You are completely wrong. It would be like claiming that if I took a piece of code I wrote myself (FooShell) and linked it against Readline, creating a GPL-licensed combined work, then FooShell itself would be permanently under the GPL, even if I found a non-GPL Readline alternative later.
SCO's claim is actually even more illogical than that. They claim that derived works become their property. So in the above scenario, FooShell would not only be permanently under the "infectious" license (the GPL), but the FSF would own the copyright on it too, and be able to dictate to me the terms under which I can use it.
Again, the GPL/SCO comparison is utterly bogus. A work combined with a GPL work requires the whole of the combined work to be covered under the GPL, not the individual components, and it certainly doesn't give anyone else authority to dictate how your part of the combined work may be used in other pursuits. That is, however, exactly what SCO is trying to do with respect to IBM's JFS code.
That's nice wishful thinking, but it doesn't change the fact that whoever is distributing the file to you, if they do not have the permission of the copyright holder to do so, is committing copyright infringement. Furthermore, if you know that they are doing so without the permission of the copyright holder and engage in the download anyway, you are probably guilty of conspiracy or contributory infringement.
Don't get me wrong, I think the user should have every right to replace his legally obtained copy if the media fails and the company refuses to do so. But nothing in current copyright law supports such behavior. Only activism will change that; wishful thinking only propagates myths.
Actually, the new capability is to set execute permissions on a per-page basis in hardware. IA-32 already had an execute permission bit on segments. No 32-bit IA-32 OS that I know of uses a segmented model though, preferring a flat memory model, which means we only get read and write permissions in hardware.
Thanks to this minor oversight in the design of IA-32, we have gone a long time without the benefit of hardware execute protection. There are software kludges that try to work around this (like working around the 386 bug with page write protection), but a hardware solution will be more robust and speedy.
I'd rather be encouraging some crap inventors simply so that the truly talented ones could be spending the majority of their time doing what they're best at.
Yep. As long as the "crap" inventors don't use the incentive we gave them as leverage to sue the "truly talented" ones into poverty. Is that better or worse than simply not providing incentive to begin with?
It almost seems like anti-incentive, to know that I could get sued for reverse engineering an API to implement a program that works with it, or by independently developing software code which happen to be covered by non-specific patents. Having that fear in the back of my mind is frequently enough to quash any self-generated incentive that I would have had in the first place. Without intervention, the other party's crap product wouldn't have been produced, and I would have been free to produce mine without being cowed by vague IP claims.
He's full of shit. XGI released no programming docs. They are a conglomeration of SIS and Trident folks, neither of which have provided any programming information for their products for the last few years. Hence, the near complete lack of support in XFree86 and the DRI for their products.
Yeah, in addition to that sometimes you can tell if a drive is starting to have problems just by the fact that it is getting slower and noisier under regular use when nothing else has changed, due to the drive having to seek way out of its way to the spare sector pool to fetch a sector that would have been part of the file it was reading.
It's like fragmentation, only at a hardware level.
Actually Celerons with L2 are more similar to Mobile PII than PII "Deschutes". They have on-die L2 cache running at full clock speed, whereas the Deschutes (and Klamath) had off-die L2 running at 1/2 clock speed.
Why is this a good thing? What kind of user would be clueless enough to install a virus on their machine AND demand that their port 25 be unblocked so that they can run their own mail server? Why not just have the customer give a good reason and put it on file, like my ISP does?
You can argue from authority all day long, but you're still wrong. The Surfboard series (at least those manufactured up until 2002) were vulnerable to an ARP poisoning attack.
I verified this myself. Set up a TFTP server on an interface with the same IP address as the headend. Then as you reboot the modem, be constantly pinging the modem's HFC IP address through the spoofed interface you created. The cable modem, when it comes up, will then try to TFTP its config file from YOUR machine and not the headend, because you have injected your MAC address into its ARP table for that IP address.
The encryption on the configuration file wasn't a big deal either, because you could get most of the needed information via SNMP IIRC. Most ISPs now disable SNMP and have bots scanning for connections where the actual speed doesn't match the account information.
Slashdot Mirror
It would not be M$ if they competed fairly and won in the marketplace because they had the best product. It is M$ because they feel it is more important to lock their competitors out of their APIs and file formats so they can make more monopoly money through controlling consumer migration, instead of creating interoperable and high quality software and advancing the state of the art in computing.
Some functionality along these lines has been attained by reverse engineering, but the fact of the matter is that Microsoft does everything it can to keep competitors from producing software which interoperates with the Windows platform. In the end, what this accomplishes is to prevent competitors from developing substitutes to Windows. Thus, such behavior fits the definition of conspiring to monopolize a market.
Note that just because a substitute product to Windows *could* be developed, doesn't imply that it *would* be developed (though there is strong evidence to suggest that it would). Regardless of whether or not a substitute _would_ be developed in the case that Microsoft didn't try to prevent it from being developed, the key issue here is the fact that Microsoft is _attempting_ to prevent substitutes from being developed, through its hidden APIs, secret file formats and protocols, and software patents.
Every person who shall monopolize, or attempt to monopolize, or combine or conspire with any other person or persons, to monopolize any part of the trade or commerce among the several States, or with foreign nations, shall be deemed guilty of a felony, and, on conviction thereof, shall be punished by fine not exceeding $10,000,000 if a corporation, or, if any other person, $350,000, or by imprisonment not exceeding three years, or by both said punishments, in the discretion of the court.
It comes down to the principle of substitutes. If you don't or can't interoperate with existing infrastructure, very few consumers will consider your product because it does not qualify as a substitute for the existing product. The requirement of Microsoft to divulge technical information to potential competitors will ensure that Microsoft's products must compete against substitutes on their merits, and not because they have the legal framework in place to prevent would-be competitors from designing substitutes for their products.
Microsoft is not innovating because it doesn't have to. It has an extremely solid framework in place ranging from software interoperability trade secrets to software patents to vendor lock-in contracts, all to ensure that no one will be able to compete with them legally or that the cost of starting up will be so great that no one will bother.
Their entire business foundation is placed upon a government intervention known as copyright, which has also not served the market. If it were 14 years and if software copyrights required registration of the machine-readable source code with the copyright office, we would already be benefiting from the Windows code of NT 3.1 vintage to serve interoperability efforts, even when they are unwilling to provide interoperability details themselves. However, instead, they are allowed to retain a perpetual monopoly on their software legacy, and any interoperability must be attained through reverse engineering. That is not a good formula for competition.
Without competition, innovation is not happening at the rate that it would in a healthy competitive market. You can sit there and argue all day that Microsoft deserves to reap the riches of their monopoly position without government interference, but every day they sit on their haunches deciding whether it's worth bothering to improve their products, progress in the state of software engineering and the leading edge for users is being held back. I don't know what dogma you subscribe to, but economists seem to have a pretty good formula for improving society, and competition is a fundamental basis of it. Where competition does not naturally exist, it is government's job to try to stimulate it as part of a successful economic policy.
It is utterly ridiculous that we have to depend on open source loving hobbyists and small businesses for the little innovation that comes out of the software industry today. Microsoft may be a monopoly, but they are no market leader. They are a disgrace to the computing industry. I hope this decision changes them permanently for the better.
It is much different to say:
"We are giving you product X with the purchase of product Y, whether you want it or not"
than to say:
"We are giving you product X with the purchase of product Y, and not only can you not remove product Y from your machine (as it is an integral part of the operating system), but we have taken special precautions to make sure that only product Y has access to features of product X that make it particularly useful; and by the way, your system provider signed a contract stating that they would not install product Z on this machine, so you're on your own if you want to install it. And don't complain to us if it is mysteriously disabled every now and then."
Linux distributions don't even compare. Yes, Mozilla is bundled, but if I want to get rid of it and use something else, it's nothing more than a dpkg --purge.
Bundling is not illegal. Product tying is legal too, except that it is a common technique by which a monopoly position is frequently abused, so it is something that frequently comes up in these cases when you are trying a company for abusing a monopoly position.
I was absolutely dumbstruck that they would spend the time and money to search out and C&D me on such an inconsequential item, an 8 year old compiler. Even more ludicrous is that this compiler was released as open source not too long ago. It is possible that people whose code was not included in the open source release might not like it to be distributed without permission, but they claimed to be acting on behalf of Sybase. The people who open sourced Watcom in the first place!
I removed the file after an fruitless email exchange and several calls from my ISP. It's just not worth the bother to fight the copyright cops, no matter how illogical their actions are.
I had to rescue data from a Novell fileserver that had become corrupt, and NWFS was invaluable in doing so. But, I had to compile an ancient kernel specifically for that purpose.
If Novell really is committed to Linux, perhaps they can shed some light on this murky topic.
Andre Hedrick's concerns
Netware Utils
Kernel patches for 2.4.15
For stupid applications that insist on using ALSA PCM interface or /dev/dsp directly for trivial sound outputs, use a wrapper in similar design to aoss to redirect the output to JACK.
Joking aside, be careful that you check the exact exit code that you need to determine whether ClamAV found a virus or not. I was using a script called clamfilter.pl that someone else wrote. Since I was in a hurry, I went ahead and stuck it in my procmailrc without checking into it much. It seemed to work for quite a while. When one of the MS virus storms hit, I started sending all the viruses to /dev/null like you are. This turned out to be a mistake.
At some later point, we had a hard drive disaster that left most of /usr unreadable. However, the mail server was still running, and still using clamav to filter mail. Due to one of clamav's files becoming unreadable, clamav started exiting with a nonzero exit code, but not because it was finding a virus in the mail. Hence ALL mail went to /dev/null for a few days while the system was being rebuilt, and we didn't discover it until afterwards. I filed a bug with the clamfilter forum, but up till now the author hasn't fixed his (IMO dangerous) code that he is offering for general use.
The moral of the story is, if you are sending mail to /dev/null in ANY case, be damn sure that you are properly checking clamscan's exit code.
SCO's claim is actually even more illogical than that. They claim that derived works become their property. So in the above scenario, FooShell would not only be permanently under the "infectious" license (the GPL), but the FSF would own the copyright on it too, and be able to dictate to me the terms under which I can use it.
Again, the GPL/SCO comparison is utterly bogus. A work combined with a GPL work requires the whole of the combined work to be covered under the GPL, not the individual components, and it certainly doesn't give anyone else authority to dictate how your part of the combined work may be used in other pursuits. That is, however, exactly what SCO is trying to do with respect to IBM's JFS code.
Don't get me wrong, I think the user should have every right to replace his legally obtained copy if the media fails and the company refuses to do so. But nothing in current copyright law supports such behavior. Only activism will change that; wishful thinking only propagates myths.
Thanks to this minor oversight in the design of IA-32, we have gone a long time without the benefit of hardware execute protection. There are software kludges that try to work around this (like working around the 386 bug with page write protection), but a hardware solution will be more robust and speedy.
It almost seems like anti-incentive, to know that I could get sued for reverse engineering an API to implement a program that works with it, or by independently developing software code which happen to be covered by non-specific patents. Having that fear in the back of my mind is frequently enough to quash any self-generated incentive that I would have had in the first place. Without intervention, the other party's crap product wouldn't have been produced, and I would have been free to produce mine without being cowed by vague IP claims.
Do you know the difference between criminal and civil violations?
Buy something else.
It's like fragmentation, only at a hardware level.
I verified this myself. Set up a TFTP server on an interface with the same IP address as the headend. Then as you reboot the modem, be constantly pinging the modem's HFC IP address through the spoofed interface you created. The cable modem, when it comes up, will then try to TFTP its config file from YOUR machine and not the headend, because you have injected your MAC address into its ARP table for that IP address.
The encryption on the configuration file wasn't a big deal either, because you could get most of the needed information via SNMP IIRC. Most ISPs now disable SNMP and have bots scanning for connections where the actual speed doesn't match the account information.