Not really. Linux has more share than any single other vendor, but they still have less than 50% of the market. I misspoke earlier when I said "an embedded OS" i meant other embedded OS's account for more share, and that doesn't even include the devices that don't use a general purpose OS.
Then you get into problems where some apps override the default settings, using pixel measurements instead of twips or tweens or points or whatever measurement is hip this week.
Russinovich is talking about design from a purely architectural standpoint, which is something you can do when your average machine will be 4GB of RAM and a quad core processor with 1TB of hard disk (which is about the average machine in about 2 or 3 years).
If you read other parts of the article, it talks about the fact that api's were included in DLL's for performance reason, not architectural ones.
And no, it wasn't bad design, because it achieved the goals it was trying to accomplish at the time. It's only "bad design" from an architectural purist standpoint. That's the point of view where architecture trumps performance, as in most Microkernel OS's.
His comments about not understanding the dependancies doesn't mean nobody understands them, just that they aren't logical because of the performance optimizations necessary for 386 computers with 4MB of memory.
This is all about modernizing the OS because we now have hardware that can run modern designs.
"without special package installation requirements" What does this mean? Does that mean that the distribution is bloated out with extra stuff that only a few users need? Why is this an advantage?
It means "doesn't need version blah.x.01.pre-something-or-other" with "foobar support compiled in" while another app requires the same version without foobar support compiled in.
It's a common myth that Linux doesn't have shared-library hell, and 99% of the time Linux handles multiple versions of the same library just fine, but there are times when two apps need the same version of a shared library configured in different ways and won't work with the others configuration.
Video resolution? Huh? Really who runs their monitor at less than the max? I'm running at 1920x1200 and there is NO reason to use anything else.
Ever tried using a 15" laptop with 1600x1200 resolution? The text is impossible to read. Most people run these at much lower resolutions than the hardware is capable of running at. The same is true of people with poor eyesight.
You're a classic example of why Linux has problems, claiming there is "NO reason" for something shows a lack of foresight or even imagination. Too many Linux developers feel the same. Because they don't have a problem with something, they firmly believe nobody should have a problem with something, and refuses to support it.
It aint Linux either. Yes, it's used on *some* consumer electronic devices, but nowhere near "most". "most" would be an embedded OS, like VXWorks or even just a microcontroller OS.
I think you will have precisely the same problems with an 8 year old Linux distro as well. SATA won't be supported, newer NIC that don't have an emulation mode won't be supported. Newer video cards won't be supported by X, etc... Now, granted, once you get the basics working you should be able to update but you will still have most of those same issues.
Does the distro recognize and auto-configure multiple monitors correctly (including 3d and compositing), even if the monitors are of different sizes and resolutions? Does the distro work well with KVM switchers?
Yeah, unfortunately, Vista/7's folder virtualization has made it so apps can continue to be stupid and not fail, so many developers developing on those systems don't notice when they do this. It's only on XP or 2000 when this beocomes noticable because they don't have folder virtualization.
I'm not sure you actually understood what that article was about. It wasn't about "the old way sucks". It was "The old way was efficient in the past, but now the efficiencies are different, and a new design is called for".
This is like an argument about a microkernel being better than a monolithic kernel. Each has tradeoffs and works better with different assumptions and different envionrments. That's why Linux is *still* a monolithic kernel. A modular one, to be fair, but still monolithic at runtime.
The environment is different today than it was in 1987 when NT was being designed. If NT were being designed today it would be a very different OS. That doesn't mean the choices they made 20 years ago were bad for the time.
Your theory was that there were fundamental design flaws in XP's design, and Vista sucked because of this... yet 7 is just a slightly more mature Vista and is an order of magnatude more well accepted.
The problem with Longhorn that caused a "reset" had little to do with design, and everything to do with the fact that all the experienced programmers were working on XP SP2 and 2003 SP1, leaving pretty much unexperienced programmers to build Vista. Once the experienced developers moved back to Vista development, it was realized that they couldn't ship the hodge podge of technolgies that had been developed and they did a 'reset' starting over from the XPSP2/2003SP1 codebase.
Sell an operating system that didn't exist? What are you talking about? QDOS, what MS-DOS was based on, did exist, and Microsoft knew they could get it for s song. That's not the same thing as selling something that doesn't exist.
And IBM had their own version of DOS since, virtually, the beginning. Nothing stopped them from improving the technology, but they chose to let Microsoft lead the way.
The fact was, DOS filled a niche, at a price point more superior OS's couldn't match. And no.. what microsoft did in those days was not anti-compatitive, as in order to be anti-competitive, they had to be a monopoly, and there were numerous OS's available for the IBM PC (including CP/M) but they were significantly more expensive.
it wasn't until the 90's that Microsoft really had anything close to monopoly power to control things, 10 years later.
And i'm not sure why you don't think Linus doesn't use the embrace and extend philosophy. Linux *IS* a case of embracing and extending, and extinguishing commercial Unix.
Your definition of "problem" may be different from theirs. For instance, perhaps they want to run a specic fantasy football windows app on their netbook while at the bar... That's a problem if it can't run on their linux netbook. I use that example because I had a friend in just that situation. He bought the netbook so he could keep track of stats and what not while out at the bar with buddies... That was fine as long as he needed only web access, but then he started wanting to do more, and run windows specific apps.
The problem with your theory is that 7 is virtually the same design as Vista, just more mature. All it shows is that Vista shipped too early, and that was because of the intense OEM pressure to get a new OS out the door to sell more new computers. Yeah, one can make snarky comments about 5 years being "too early" but in reality, Vista as we know it was less than 2 years of work.
There's also a case to be made for "pulling the plug". Vista enforced a lot of new rules on applications and drivers, and they knew it was going to be painful. So get something out there, no matter how crappy, to get developers writing code to the new system so that in another 2 years, you can release the "real" new system.
strcpy, and memcpy and such are only the most obvious ways for buffer overflows to occur.. there always seems to be new kinds of buffer overflows, these can result from integer parsing errors, numerical overflows, hand optimized byte buffer loops, etc.. i'd wager that there are more ways to over flow a buffer than there are programmers.
Yes, in fact this incident could very well support microsoft's "cancer" or "virus" claims, and help to reinforce the fears that the GPL must be avoided in corporations at all costs.
The primary value I personally derive from licensing my software under the GPL is the feature enhancements and bug fixes I receive back whenever someone makes changes and re-releases my code. That has very real economic value
I'd be careful about going down that road. Did you know that most tax authorities view any kind of economic value as taxable? Including barter? Do you really want to give the IRS fuel in taxing Free Software because of it's "economic value" with a gift tax or barter tax?
We have no reason to believe that Microsoft is being honest of their own accord here because their track record speaks for itself. If what Microsoft did to the ISO committees on OOXML and ODF isn't illegal, it's downright dishonest and unethical.
You seem to forget that what MS may have done in OOXML pales in comparison to what IBM and Sun did. IBM and Sun stacked more comittees, wrote more responses for said committees, paid astroturfers, got employees to blog against it while all but hiding their identities and connections... Do you REALLY think the controversy got stirred up to the froth it was organically? No, 95% of it was fueld by IBM and Sun employees, or people compensated indirectly by them.
For example, did you know the Kenyan response to OOXML was written by an IBM employee? The malaysian response was written by IBM Employee? That it was, in fact, the same employee that wrote both?
The fact of the matter is that OOXML is a non-issue, except to the financial concerns of Sun, IBM, Oracle, and a number of others. OOXML being a standard does not detract from ODF being a standard, but one would think that OOXML was being proposed as ODF version 2. If you don't like OOXML, don't use it. If it's such a bad standard, it will die by itself. And, if this whole issue had not been pushed by financial concerns on both sides, it would have simply occurred that way.
ODF and OOXML are designed for different purposes, and ODF cannot, and never will be able to fulfil the requirements that OOXML was intended to fill, namely the ability to losslessly represent legacy MS Office documents in a format that makes them interoperable with other tools. IBM and Sun's refusal to accept proposals to ODF by its committee members for features that would make it more interoperable with Office ensures that.
Make no mistake, both ODF and OOXML have serious failures, and serious political muscle behind them, and serious bullheadedness of it's proprieters. The open source community just got duped into believing this was a freedom issue, when in fact it was nothing of the kind.
My point with this rant, is simply to point out that using the example of OOXML and ODF relating to ethics is a serious FAIL, because there was a gigantic lack of ethics on both sides.
Your view is very narrow. Consider, for example, that many of the things Microsoft did were only illegal if done by a monopoly. Many of it's competitors (including Apple) do many of the the same things or worse. This means that Microsoft would have had to be aware that it was considered a legal monopoly, and frankly until a judge makes that decision, you can't know when that is the case. It's a case of slow-boiling a frog.
Under a microscope, many actions seem bad, but in the process of doing business, they look like normal everyday business decisions. I mean, many open source advocates seem to be ok with doing many of the same things MS does if they are done to MS. For example, many open source advocates are in favor of denying microsoft access to open source code (basically, same as API's), but if MS did that it would be the next exhibit in comes v. microsoft.
And how about Mono? There is a gigantic push by open source advocates to get Mono excluded from everything, but if MS were trying to exclude, say, OpenOffice out of something it would be 1 step short of the holocaust.
My point is, things are seldom as black and white as most people want them to be.
Microsoft has been intentionally stifling the advancement of technology from the very start when it intentionally sold an inferior system to run on IBM.
That's a pretty bizarre comment. By that logic, Linus has been intentionally stifling the advancement of technology from the very start when it intentionally released an inferior clone of Unix to run on IBM.
Seriously, How can you think that because a company releases a scaled down version of something else, it's "intentionally stifling the advancement of technology"? It just means they didn't have the resources to make the full blown thing right away.
Microsoft did not kill Stac, Seagate, Maxtor, and Western Digital did. Gigantic Hard drives for pennies a Gigabyte made disk compression largely useless.
Then you'd be wrong. Stac v. Microsoft was a patent suit, not a copyright infringement suit. You know.. Software Patents... those things most people here on Slashdot say are evil.
Also, most people forget that Stac lost a countersuit as well, which means both sides infringed each others IP.
A security vulnerability is incorrect code. It conforms to that definition. Time passing causes more information about the correctness of the code to be revealed, which is akin to rot.
Slashdot Mirror
Not really. Linux has more share than any single other vendor, but they still have less than 50% of the market. I misspoke earlier when I said "an embedded OS" i meant other embedded OS's account for more share, and that doesn't even include the devices that don't use a general purpose OS.
No, make them slightly more obscure perhaps, but not "hide" them. The folders exist and are visible in your user profile.
Then you get into problems where some apps override the default settings, using pixel measurements instead of twips or tweens or points or whatever measurement is hip this week.
Installing a copy of XP is *EXACTLY* like installing a copy of Linux that has been in a time capsule for 8 years. Pay has nothing to do with it.
Russinovich is talking about design from a purely architectural standpoint, which is something you can do when your average machine will be 4GB of RAM and a quad core processor with 1TB of hard disk (which is about the average machine in about 2 or 3 years).
If you read other parts of the article, it talks about the fact that api's were included in DLL's for performance reason, not architectural ones.
And no, it wasn't bad design, because it achieved the goals it was trying to accomplish at the time. It's only "bad design" from an architectural purist standpoint. That's the point of view where architecture trumps performance, as in most Microkernel OS's.
His comments about not understanding the dependancies doesn't mean nobody understands them, just that they aren't logical because of the performance optimizations necessary for 386 computers with 4MB of memory.
This is all about modernizing the OS because we now have hardware that can run modern designs.
"without special package installation requirements" What does this mean? Does that mean that the distribution is bloated out with extra stuff that only a few users need? Why is this an advantage?
It means "doesn't need version blah.x.01.pre-something-or-other" with "foobar support compiled in" while another app requires the same version without foobar support compiled in.
It's a common myth that Linux doesn't have shared-library hell, and 99% of the time Linux handles multiple versions of the same library just fine, but there are times when two apps need the same version of a shared library configured in different ways and won't work with the others configuration.
Video resolution? Huh? Really who runs their monitor at less than the max? I'm running at 1920x1200 and there is NO reason to use anything else.
Ever tried using a 15" laptop with 1600x1200 resolution? The text is impossible to read. Most people run these at much lower resolutions than the hardware is capable of running at. The same is true of people with poor eyesight.
You're a classic example of why Linux has problems, claiming there is "NO reason" for something shows a lack of foresight or even imagination. Too many Linux developers feel the same. Because they don't have a problem with something, they firmly believe nobody should have a problem with something, and refuses to support it.
It aint Linux either. Yes, it's used on *some* consumer electronic devices, but nowhere near "most". "most" would be an embedded OS, like VXWorks or even just a microcontroller OS.
I think you will have precisely the same problems with an 8 year old Linux distro as well. SATA won't be supported, newer NIC that don't have an emulation mode won't be supported. Newer video cards won't be supported by X, etc... Now, granted, once you get the basics working you should be able to update but you will still have most of those same issues.
A few more:
Does the distro recognize and auto-configure multiple monitors correctly (including 3d and compositing), even if the monitors are of different sizes and resolutions?
Does the distro work well with KVM switchers?
Yeah, unfortunately, Vista/7's folder virtualization has made it so apps can continue to be stupid and not fail, so many developers developing on those systems don't notice when they do this. It's only on XP or 2000 when this beocomes noticable because they don't have folder virtualization.
I'm not sure you actually understood what that article was about. It wasn't about "the old way sucks". It was "The old way was efficient in the past, but now the efficiencies are different, and a new design is called for".
This is like an argument about a microkernel being better than a monolithic kernel. Each has tradeoffs and works better with different assumptions and different envionrments. That's why Linux is *still* a monolithic kernel. A modular one, to be fair, but still monolithic at runtime.
The environment is different today than it was in 1987 when NT was being designed. If NT were being designed today it would be a very different OS. That doesn't mean the choices they made 20 years ago were bad for the time.
Your theory was that there were fundamental design flaws in XP's design, and Vista sucked because of this... yet 7 is just a slightly more mature Vista and is an order of magnatude more well accepted.
The problem with Longhorn that caused a "reset" had little to do with design, and everything to do with the fact that all the experienced programmers were working on XP SP2 and 2003 SP1, leaving pretty much unexperienced programmers to build Vista. Once the experienced developers moved back to Vista development, it was realized that they couldn't ship the hodge podge of technolgies that had been developed and they did a 'reset' starting over from the XPSP2/2003SP1 codebase.
Sell an operating system that didn't exist? What are you talking about? QDOS, what MS-DOS was based on, did exist, and Microsoft knew they could get it for s song. That's not the same thing as selling something that doesn't exist.
And IBM had their own version of DOS since, virtually, the beginning. Nothing stopped them from improving the technology, but they chose to let Microsoft lead the way.
The fact was, DOS filled a niche, at a price point more superior OS's couldn't match. And no.. what microsoft did in those days was not anti-compatitive, as in order to be anti-competitive, they had to be a monopoly, and there were numerous OS's available for the IBM PC (including CP/M) but they were significantly more expensive.
it wasn't until the 90's that Microsoft really had anything close to monopoly power to control things, 10 years later.
And i'm not sure why you don't think Linus doesn't use the embrace and extend philosophy. Linux *IS* a case of embracing and extending, and extinguishing commercial Unix.
Your definition of "problem" may be different from theirs. For instance, perhaps they want to run a specic fantasy football windows app on their netbook while at the bar... That's a problem if it can't run on their linux netbook. I use that example because I had a friend in just that situation. He bought the netbook so he could keep track of stats and what not while out at the bar with buddies... That was fine as long as he needed only web access, but then he started wanting to do more, and run windows specific apps.
The problem with your theory is that 7 is virtually the same design as Vista, just more mature. All it shows is that Vista shipped too early, and that was because of the intense OEM pressure to get a new OS out the door to sell more new computers. Yeah, one can make snarky comments about 5 years being "too early" but in reality, Vista as we know it was less than 2 years of work.
There's also a case to be made for "pulling the plug". Vista enforced a lot of new rules on applications and drivers, and they knew it was going to be painful. So get something out there, no matter how crappy, to get developers writing code to the new system so that in another 2 years, you can release the "real" new system.
strcpy, and memcpy and such are only the most obvious ways for buffer overflows to occur.. there always seems to be new kinds of buffer overflows, these can result from integer parsing errors, numerical overflows, hand optimized byte buffer loops, etc.. i'd wager that there are more ways to over flow a buffer than there are programmers.
Yes, in fact this incident could very well support microsoft's "cancer" or "virus" claims, and help to reinforce the fears that the GPL must be avoided in corporations at all costs.
The primary value I personally derive from licensing my software under the GPL is the feature enhancements and bug fixes I receive back whenever someone makes changes and re-releases my code. That has very real economic value
I'd be careful about going down that road. Did you know that most tax authorities view any kind of economic value as taxable? Including barter? Do you really want to give the IRS fuel in taxing Free Software because of it's "economic value" with a gift tax or barter tax?
We have no reason to believe that Microsoft is being honest of their own accord here because their track record speaks for itself. If what Microsoft did to the ISO committees on OOXML and ODF isn't illegal, it's downright dishonest and unethical.
You seem to forget that what MS may have done in OOXML pales in comparison to what IBM and Sun did. IBM and Sun stacked more comittees, wrote more responses for said committees, paid astroturfers, got employees to blog against it while all but hiding their identities and connections... Do you REALLY think the controversy got stirred up to the froth it was organically? No, 95% of it was fueld by IBM and Sun employees, or people compensated indirectly by them.
For example, did you know the Kenyan response to OOXML was written by an IBM employee? The malaysian response was written by IBM Employee? That it was, in fact, the same employee that wrote both?
The fact of the matter is that OOXML is a non-issue, except to the financial concerns of Sun, IBM, Oracle, and a number of others. OOXML being a standard does not detract from ODF being a standard, but one would think that OOXML was being proposed as ODF version 2. If you don't like OOXML, don't use it. If it's such a bad standard, it will die by itself. And, if this whole issue had not been pushed by financial concerns on both sides, it would have simply occurred that way.
ODF and OOXML are designed for different purposes, and ODF cannot, and never will be able to fulfil the requirements that OOXML was intended to fill, namely the ability to losslessly represent legacy MS Office documents in a format that makes them interoperable with other tools. IBM and Sun's refusal to accept proposals to ODF by its committee members for features that would make it more interoperable with Office ensures that.
Make no mistake, both ODF and OOXML have serious failures, and serious political muscle behind them, and serious bullheadedness of it's proprieters. The open source community just got duped into believing this was a freedom issue, when in fact it was nothing of the kind.
My point with this rant, is simply to point out that using the example of OOXML and ODF relating to ethics is a serious FAIL, because there was a gigantic lack of ethics on both sides.
Your view is very narrow. Consider, for example, that many of the things Microsoft did were only illegal if done by a monopoly. Many of it's competitors (including Apple) do many of the the same things or worse. This means that Microsoft would have had to be aware that it was considered a legal monopoly, and frankly until a judge makes that decision, you can't know when that is the case. It's a case of slow-boiling a frog.
Under a microscope, many actions seem bad, but in the process of doing business, they look like normal everyday business decisions. I mean, many open source advocates seem to be ok with doing many of the same things MS does if they are done to MS. For example, many open source advocates are in favor of denying microsoft access to open source code (basically, same as API's), but if MS did that it would be the next exhibit in comes v. microsoft.
And how about Mono? There is a gigantic push by open source advocates to get Mono excluded from everything, but if MS were trying to exclude, say, OpenOffice out of something it would be 1 step short of the holocaust.
My point is, things are seldom as black and white as most people want them to be.
Microsoft has been intentionally stifling the advancement of technology from the very start when it intentionally sold an inferior system to run on IBM.
That's a pretty bizarre comment. By that logic, Linus has been intentionally stifling the advancement of technology from the very start when it intentionally released an inferior clone of Unix to run on IBM.
Seriously, How can you think that because a company releases a scaled down version of something else, it's "intentionally stifling the advancement of technology"? It just means they didn't have the resources to make the full blown thing right away.
Microsoft did not kill Stac, Seagate, Maxtor, and Western Digital did. Gigantic Hard drives for pennies a Gigabyte made disk compression largely useless.
Then you'd be wrong. Stac v. Microsoft was a patent suit, not a copyright infringement suit. You know.. Software Patents... those things most people here on Slashdot say are evil.
Also, most people forget that Stac lost a countersuit as well, which means both sides infringed each others IP.
A security vulnerability is incorrect code. It conforms to that definition. Time passing causes more information about the correctness of the code to be revealed, which is akin to rot.