Uhh.. most of what you're asking for is already there. I suppose you can't be bothered to find that out first, though.
For example, MS provides the Software Update Services as a free download to Windows Server that provides a local patch server. Also, you can set Windows Update to download and install your patches at 3am or whever you want and reboot automatically.
Having read the article, I have to wonder how anyone could claim that a DNS client isn't required for a home machine, or a DHCP client for that matter, or file sharing (many many users have small home networks, and many small businesses use the "home" edition)
I think you're making a few assumptions. There are several viable methods of handling the common functionality that would not require a user process to handle it. For example, if your drawing libraries can communicate with each other to negotiate resource access,clip lists, etc.. then this is handled in the applications thread. This is how it works on older versions of Windows, for instance (not that i'm advocating Windows approach, but that doesn't mean everything they do is bad).
Another way would would be handle this as a device driver. This would effectively put this code in the kernel, but if it's small enough and tested well enough that shouldn't be much of a reliability problem, especially if all it's doing is handling clip lists, ipc, and message passing from input devices.
The part your missing is that the GPL expressly forbids the distribution of software if there is a patent encumbrence. While you're correct that I can make an agreement with the patent holder, that doesn't change the fact that I cannot legally use the GPL'd software even if I have a copy and a right to use the patented work.
The problem is that unless the author of the software a) adds an exception clause to their work excluding the patent clauses, b) acquires a right to use the patented work, or c) relicenses under a different license then any copy you recieve is in violation of the GPL, even if YOU have the right to use the patented work.
The GPL is the only thing that gives you the right to obtain and use the software. If the license precludes it's distribution due to patent encumbrence, you can't legally obtain it, thus you don't legally have a license, thus you can't legally use it even if you have a right to use the patent.
That may seem like "nit picking" or being overly anal about the interpreation, but the license is explicit in this matter.
From the GPL:
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
There are several problems with your pre-ordering scenario.
It takes so long to develop software, that you're not going to find 10,000 people to fork over a significant amount of money 1-2 years before they receive the product sight unseen. On top of that, it would also likely violate commerce laws.
Apache does NOT have vastly more installs. It simply has vastly more hosts being serviced by it.
There are actually far more Windows boxes serving web sites out there than Apache boxes, but most of the Windows boxes are single (or relatively few) sites, while there are far more large virtual hosted sites on Apache (mostly ISP's).
Sorry, but the "after the sale" argument has already been tested in court. See ProCD v. Zeidenberg. In this case, it was ruled that even though the license was not available to read (and thus agree to) until after the sale, it was still valid because the vendor offered a way to return the product for a full refund.
Now some people might want to claim that they can't return OEM copies (but that doesn't effect retail copies, which you are talking about), even though those copies CAN be returned, they simply have to be returned with the hardware they were bought with.
You could eliminate dependency by simply writing everything as straight in-line code -- no subroutines or macros.
????
First you talk about factoring, then you talk about inlining? They're essentially mutually exclusive.
This further bloats the code as wellas making it much more difficult to update. If you want to update something, you have to update each executable rather than a single shared library. That's bad. It also is more error prone, since you now have situations where some code gets updated while other code may not.
You can't possibly be suggesting that shared libraries are "bad factoring"?
Factoring is not the issue. The issue is dependancy. Higher factoring actually creates more dependancy.
The problem is that so much of Windows is dependant upon IE (the help system, for instance), and so many third party apps depend on IE (Quicken, AOL, etc..). I'm not just talking about rendering web pages, but API level integration.
I think this whole "OS Integration" boondoggle is just a red herring anyways. It's not the integration with the OS that's causing the problems. It's a lack of basic security on dangerous functions.
As an example, even Mozilla recently suffered from a typical IE flaw, even though Mozilla isn't integrated. It simply had no security on default shell handlers. That was bad. It's like not putting security on a java appliet.
While all the reasons you give for corporate users are true, they ignore the other problems corporate users have with switching to Linux. Namely, legacy applications. Many of these companies are running specialized appliations that either they wrote (which they could port, but would cost a lot of money), or someone else wrote (and they may not be sure if they can get a port).
Then there's the file format issue. Many companies don't want to risk alienating customers by having file format conversion issues.
Finally, there's the issue of retraining. Many of these people have been using Excel for a decade and know it inside and out. Retraining them to the same level of knowledge on a new system (even one that is substantially similar) is very costly. What's worse, the rapid pace of development in Linux can make such training obsolete very quickly.
Now, that's not to say that it might not be worth the cost, effort, and frustration of a change, but that kind of thing is VERY hard to justify when the current system is "good enough".
Not really relevant. These are things most people have no other viable choice for. They simply must go to work if they want money. They simply must change the diapers if they don't want the baby to scream all the time (or get hauled off by CPS). They simply must watch commercials if they want to watch TV (not barring TiVo time slip and the like).
They have the choice of using Windows or Linux. If Linux is more frustrating, they'll continue using Windows.
Oh, and Tim Patterson, the author of QDOS was indeed paid a "pittance" initially, but as soon as MS got the IBM contract, they hired Patterson and he became one of the first "Microsoft Millionaires".
Have you even made a cursury examination of the events you seem so certain about?
Umm.. how exactly would the guts of Dartmouth Basic (a compiled language, written for the PDP processor composing hundreds of K of source) help MS create Altair Basic (an interpreted language, in 8080 assembly that was less than 4k in size and was only barely similar to DM Basic)?
Methinks you've been listening to too many urban myths and jumping to conclusions.
I have read a comment from gates in which he admits to dumpster diving for operating system listings to understand how others wrote code, but nothing that says he used Dartmouth Basic listings as his basis for BASIC. Are you going to suggest that looking at the Linux kernel formed the basis of Slashcode?
Those points are left out because they're not true.
First, MS was declared to be a monopoly, only for desktop intel based PC's (effectively removing Apple and servers from the market). This was explicit on the part of Judge Jackson and the DOJ to make MS's monopoly percentages seem even larger.
This would be equivelent to saying 95%+ of all light duty truck and consumer auto sales based on non-deisel 3.5L and less engines.
Next, this was only a recent occurance, and certainly would not change what has happened prior to this event.
Next, the case is effectively nullfied since the DOJ and MS reached a settlement agreement.
Next, Very few of the software titles (gas) sold in most computer stores are protected by patents. And many (far more than 5%) of such stores sell Mac software as well.
Next, most of the periphials (tires) sold in computer stores are OS agnostic, even if they might have logo's on them indicating they're made for a specific OS.
Next, most of the service centers are trained only in Windows. If you're lucky they might have MacOS training, but you typically have to bring your Mac to an authorized service center. The hardware support is OS agnostic though, and a tech should care less if it's Linux or Windows if the CPU dies or it needs more memory.
The fact is, you're analogies are not only flawed, they're not even close to being illustrative.
That's because Apple is most likely bound by contract with MS to include IE (remember that $150 "investment" MS made in Apple a few years ago?). If this weren't the case, I doubt apple would be including IE.
My system goes from POST to useable desktop in under 35 seconds. It takes KDE alone longer than that to start on the same system.
One caveat, certain antivirus program do deliberately inhibit your use of the desktop until the antivirus application is fully running, which can make it seem like XP is useless after logging in. This is a side effect of the way the virus software works and not a problem with XP itself (unless you want to consider the need of a virus checker a problem, which most people do).
XP does a lot of things, besides delayed services, to speed up booting. These including real-time disk optimized layouts that move blocks of data around to reduce head chatter during boot, optimized driver initialization, prefetch, and yes... delay loading of some services, but those services generally do not interfere with using the system for most people.
Compare this to a typical Windows 2000 boot which can take over 2 minutes and you see the difference, and Win2k *STILL* makes you wait at the desktop.
XP runs fine on PII's, and i have several of them doing just that. They need more memory, but that's cheap.
There are literally 10's of millions of people out there still using Windows 98 on P1's and early PII's.
Also, i'd disagree that 333Mhz G3's run OS X "just fine". I've used earlier versions of OS X on imac's of that era and found it to be sluggishly hostile.
Slashdot Mirror
Even dialup users need DNS resolution.
Uhh.. most of what you're asking for is already there. I suppose you can't be bothered to find that out first, though.
For example, MS provides the Software Update Services as a free download to Windows Server that provides a local patch server. Also, you can set Windows Update to download and install your patches at 3am or whever you want and reboot automatically.
So you're actually suggesting that having a DNS or DHCP client is "insecure stuff"?
Having read the article, I have to wonder how anyone could claim that a DNS client isn't required for a home machine, or a DHCP client for that matter, or file sharing (many many users have small home networks, and many small businesses use the "home" edition)
I think you're making a few assumptions. There are several viable methods of handling the common functionality that would not require a user process to handle it. For example, if your drawing libraries can communicate with each other to negotiate resource access,clip lists, etc.. then this is handled in the applications thread. This is how it works on older versions of Windows, for instance (not that i'm advocating Windows approach, but that doesn't mean everything they do is bad).
Another way would would be handle this as a device driver. This would effectively put this code in the kernel, but if it's small enough and tested well enough that shouldn't be much of a reliability problem, especially if all it's doing is handling clip lists, ipc, and message passing from input devices.
The part your missing is that the GPL expressly forbids the distribution of software if there is a patent encumbrence. While you're correct that I can make an agreement with the patent holder, that doesn't change the fact that I cannot legally use the GPL'd software even if I have a copy and a right to use the patented work.
The problem is that unless the author of the software a) adds an exception clause to their work excluding the patent clauses, b) acquires a right to use the patented work, or c) relicenses under a different license then any copy you recieve is in violation of the GPL, even if YOU have the right to use the patented work.
The GPL is the only thing that gives you the right to obtain and use the software. If the license precludes it's distribution due to patent encumbrence, you can't legally obtain it, thus you don't legally have a license, thus you can't legally use it even if you have a right to use the patent.
That may seem like "nit picking" or being overly anal about the interpreation, but the license is explicit in this matter.
From the GPL:
7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.
There are several problems with your pre-ordering scenario.
It takes so long to develop software, that you're not going to find 10,000 people to fork over a significant amount of money 1-2 years before they receive the product sight unseen. On top of that, it would also likely violate commerce laws.
Actually, for ASP.NET development, you should use ASP.NET WebMatrix. SharpDevelop is more suited towards app development than web development.
http://www.asp.net/webmatrix/
You might want to look at WebMatrix, which Microsoft offers for free.
http://www.asp.net/webmatrix/
SharpDevelop is designed for application development because WebMatrix works so well already.
However, I stand by the word, pro-active, because there is a proactive approach now.
Hmm.. perhaps you or I are not understanding the meaning of the word pro-active.
Responding to a discovered flaw after the fact is not PRO-active. It's RE-active.
Consider this:
Apache does NOT have vastly more installs. It simply has vastly more hosts being serviced by it.
There are actually far more Windows boxes serving web sites out there than Apache boxes, but most of the Windows boxes are single (or relatively few) sites, while there are far more large virtual hosted sites on Apache (mostly ISP's).
Because whatever the EULA says must be the law?
No, but if the EULA isn't valid, then copyright law would take over, which would give you no right to use the product at all.
Sorry, but the "after the sale" argument has already been tested in court. See ProCD v. Zeidenberg. In this case, it was ruled that even though the license was not available to read (and thus agree to) until after the sale, it was still valid because the vendor offered a way to return the product for a full refund.
Now some people might want to claim that they can't return OEM copies (but that doesn't effect retail copies, which you are talking about), even though those copies CAN be returned, they simply have to be returned with the hardware they were bought with.
You could eliminate dependency by simply writing everything as straight in-line code -- no subroutines or macros.
????
First you talk about factoring, then you talk about inlining? They're essentially mutually exclusive.
This further bloats the code as wellas making it much more difficult to update. If you want to update something, you have to update each executable rather than a single shared library. That's bad. It also is more error prone, since you now have situations where some code gets updated while other code may not.
You can't possibly be suggesting that shared libraries are "bad factoring"?
Factoring is not the issue. The issue is dependancy. Higher factoring actually creates more dependancy.
The problem is that so much of Windows is dependant upon IE (the help system, for instance), and so many third party apps depend on IE (Quicken, AOL, etc..). I'm not just talking about rendering web pages, but API level integration.
I think this whole "OS Integration" boondoggle is just a red herring anyways. It's not the integration with the OS that's causing the problems. It's a lack of basic security on dangerous functions.
As an example, even Mozilla recently suffered from a typical IE flaw, even though Mozilla isn't integrated. It simply had no security on default shell handlers. That was bad. It's like not putting security on a java appliet.
While all the reasons you give for corporate users are true, they ignore the other problems corporate users have with switching to Linux. Namely, legacy applications. Many of these companies are running specialized appliations that either they wrote (which they could port, but would cost a lot of money), or someone else wrote (and they may not be sure if they can get a port).
Then there's the file format issue. Many companies don't want to risk alienating customers by having file format conversion issues.
Finally, there's the issue of retraining. Many of these people have been using Excel for a decade and know it inside and out. Retraining them to the same level of knowledge on a new system (even one that is substantially similar) is very costly. What's worse, the rapid pace of development in Linux can make such training obsolete very quickly.
Now, that's not to say that it might not be worth the cost, effort, and frustration of a change, but that kind of thing is VERY hard to justify when the current system is "good enough".
Not really relevant. These are things most people have no other viable choice for. They simply must go to work if they want money. They simply must change the diapers if they don't want the baby to scream all the time (or get hauled off by CPS). They simply must watch commercials if they want to watch TV (not barring TiVo time slip and the like).
They have the choice of using Windows or Linux. If Linux is more frustrating, they'll continue using Windows.
Oh, and Tim Patterson, the author of QDOS was indeed paid a "pittance" initially, but as soon as MS got the IBM contract, they hired Patterson and he became one of the first "Microsoft Millionaires".
Have you even made a cursury examination of the events you seem so certain about?
Umm.. how exactly would the guts of Dartmouth Basic (a compiled language, written for the PDP processor composing hundreds of K of source) help MS create Altair Basic (an interpreted language, in 8080 assembly that was less than 4k in size and was only barely similar to DM Basic)?
Methinks you've been listening to too many urban myths and jumping to conclusions.
I have read a comment from gates in which he admits to dumpster diving for operating system listings to understand how others wrote code, but nothing that says he used Dartmouth Basic listings as his basis for BASIC. Are you going to suggest that looking at the Linux kernel formed the basis of Slashcode?
Those points are left out because they're not true.
First, MS was declared to be a monopoly, only for desktop intel based PC's (effectively removing Apple and servers from the market). This was explicit on the part of Judge Jackson and the DOJ to make MS's monopoly percentages seem even larger.
This would be equivelent to saying 95%+ of all light duty truck and consumer auto sales based on non-deisel 3.5L and less engines.
Next, this was only a recent occurance, and certainly would not change what has happened prior to this event.
Next, the case is effectively nullfied since the DOJ and MS reached a settlement agreement.
Next, Very few of the software titles (gas) sold in most computer stores are protected by patents. And many (far more than 5%) of such stores sell Mac software as well.
Next, most of the periphials (tires) sold in computer stores are OS agnostic, even if they might have logo's on them indicating they're made for a specific OS.
Next, most of the service centers are trained only in Windows. If you're lucky they might have MacOS training, but you typically have to bring your Mac to an authorized service center. The hardware support is OS agnostic though, and a tech should care less if it's Linux or Windows if the CPU dies or it needs more memory.
The fact is, you're analogies are not only flawed, they're not even close to being illustrative.
That's because Apple is most likely bound by contract with MS to include IE (remember that $150 "investment" MS made in Apple a few years ago?). If this weren't the case, I doubt apple would be including IE.
I didn't say it was revolutionary, I simply said it wasn't an illusion.
XP's faster boot time is not an illusion.
My system goes from POST to useable desktop in under 35 seconds. It takes KDE alone longer than that to start on the same system.
One caveat, certain antivirus program do deliberately inhibit your use of the desktop until the antivirus application is fully running, which can make it seem like XP is useless after logging in. This is a side effect of the way the virus software works and not a problem with XP itself (unless you want to consider the need of a virus checker a problem, which most people do).
XP does a lot of things, besides delayed services, to speed up booting. These including real-time disk optimized layouts that move blocks of data around to reduce head chatter during boot, optimized driver initialization, prefetch, and yes... delay loading of some services, but those services generally do not interfere with using the system for most people.
Compare this to a typical Windows 2000 boot which can take over 2 minutes and you see the difference, and Win2k *STILL* makes you wait at the desktop.
Even worse, the old systems ran only at 66Mhz. Besides, 400Mhz G3's are only a few years old, compared to a PII which is about 8 years old.
XP runs fine on PII's, and i have several of them doing just that. They need more memory, but that's cheap.
There are literally 10's of millions of people out there still using Windows 98 on P1's and early PII's.
Also, i'd disagree that 333Mhz G3's run OS X "just fine". I've used earlier versions of OS X on imac's of that era and found it to be sluggishly hostile.