I would say that the blame is more like 70% developers, 30% Microsoft.
I fail to see how Microsoft can be deserving of one iota of blame since least five years ago, let alone today.
Yes, it's been easy to write software for Windows that works properly in a multi-user, non admin scenario. But without any real guidelines (until the Windows Logo program, which didn't debut until long after the XP launch), and without any serious push from Microsoft, developers had little reason to do so.
Microsoft have been telling developers to write LUA-friendly apps - and how to do so - for *at least* five years (really, closer to ten). It only became a _requirement_ for the Windows Logo with the release of XP, but they'd been doing it long before then.
Even if that weren't true, the lack of a "requirement" from Microsoft does not in any way justify or excuse lazy and/or incompetent development and testing practices.
Microsoft has to take some of the blame. They're so good at getting developers to go with the flow in other areas, but not this one.
Short of deliberately breaking non-LUA-friendly applications, there's little else Microsoft could (or can) do. Given the outrage that usually ensues when Microsoft inadvertently, and for good reason, breaks software, I'm sure you can imagine why they weren't very keen to do it deliberately.
Therefore, in order to develop COM components - i.e. in order to do any serious Windows development - you _needed_ to run as roo^H^H^HAdministrator.
Or you could just use "Run As" for those times you need to actually install a COM component.
The trouble is, if you're running as Administrator, you don't notice if you end up doing other things that also require Administrator privs. Like writing to other parts of HKLM, or the Program Files (or even System32) folder. None of that fails on your system, as you're Admin, so you never pick up on it.
This is not an excuse for fundamentally bad development practices. If you're storing run-time or per-user data in system areas, you're either lazy or incompentent. "But it works for me" is not justification for doing something even a first-year software engineering student should be able to tell you is the wrong way to do it.
Your code goes to testing. In order to install your COM components, the testers need to at least install as Administrator. If they forget to test as a limited user, they'll never notice that either.
Nor is it an excuse for poor testing procedures.
No developer has had any reasonable excuse for not writing LUA-friendly Windows software for ~7-8 years. Arguably, it's more like ~10 years, since NT4 was released, but I'm prepared to cut some slack.
Yes, but the program cannot make itself run automatically at bootup as this would require changing files which are owned by root
Most desktops are only used by one person. Starting from that users "Startup" folder (or equivalent) is effectively the same thing as starting at system boot.
So basically it will die at next reboot. It might be able to start when that same user logs in, but this can be fixed by forcing all config changes to come from root (Admin or whatever)
A solution completely unworkable for the majority of desktop PCs.
Apart from one, it would cost MS a fortune to rewrite office, and they would lose the edge which office has over the competition (all the private hooks into the OS it uses which they dont publicise to other developers)
I see the good old "hidden APIs" myth still exists, despite the complete and utter lack of any actual evidence supporting it.
Tell us, just what "advantages" do you think these supposed "private hooks" engender to a *word processor* or *spreadsheet* program ?
These applications all assumed they were running as admin, and for good reason... they were! It wasn't until just 5 years ago that Microsoft finally made the push to get consumers on to the NT kernel, with all its nice security features and the new world of multiple users with varying permissions.
It's important to remember that if developers had been writing their software *properly*, then pretty much any application written after about 1998 should work without a problem in a non-Administrator account.
Microsoft have made life for developers "migrating" their software from DOS-based Windows to NT-based Windows about as easy as humanly possible. Multiuser Windows NT has been in the marketplace for *13 years*. The necessary APIs to handle per-user data stores have been present in every version since Windows 98. The blame for applications that needlessly require Administrator privileges lies 100% at the feet of the people that write such software.
The problem is that the Windows core was never designed to be connected to other computers.
Yes, it was. Windows NT was designed from day one to be a multiuser, networked OS.
LAN's and then the Internet came later and Microsoft injected the necessary code to handle either of those new networking technologies in a quick and (very) dirty fashion.
Wrong.
When saddens me the most is the statement in the original post that Vista can be subject to a rootkit attack. What did they really learn?
All OSes can be subject to a rootkit attack. What point are you trying to make ?
It can as well be extended to support vista features (and as we've seen, Vista still has a lot of the XP kernel code).
Of course it does. XP is Windows NT 5.1. Vista is Windows NT 6.0.
While Vista was built from Windows 2003 (NT 5.2), not Windows XP, it's still just the latest major release of Windows NT. Vista is to XP, roughly, as Linux 2.6 is to Linux 2.4. (A more accurate comparison might be RHEL3 to RHEL4.)
And with the ghost of Genuine Advantage approaching, i think ReactOS will make its debut just in time. When it's finished, the people who are using pirated copies of XP will probably switch instantly.
I'd say by ca. 2010, any "verification" processes that Vista might be using will have been well and truly cracked, for the tiny proportion of people who don't just end up with a copy of Vista by default when they buy their new PCs.
ReactOS is interesting from an academic perspective, but it's relevance to the real world is small, and not getting any bigger.
Agreed, but most anyone can crank out a short document, poster, etc. faster in LaTeX than some else pointing and clicking their way using Word. Long articles and books doubly so.
I don't believe the words "most anyone" mean what you think they mean.
I find it highly amusing that the "server" versions of windows all ship with a complete copy of directx (including direct3d, and support for various gaming-related networking protocols and joysticks etc)... And you can't remove it... WHY?
Why not ?
Maybe they're admitting what a mickey mouse excuse for a server their OS is, and that i should be playing games on it instead.
Maybe they're doing it to annoy the anal-retentive types who get their knickers in a twist about such silly little irrelevancies...
Then Windows for Workgroups 3.11 - which ultimately ended up becoming Windows NT. WFW was just Windows 3.0 with networking added. Windows NT was just WFW with a ton of bug fixes (and that's a lot; individual bits don't weigh much).
If you think this, I suggest you try loading some binary kernel modules from different minor kernel releases into a running kernel.
And even still it changes FOR THE BETTER.
The point is, would specifying a stable kernel ABI *stop* it from changing "FOR THE BETTER" ? Everyone else manages to do it, why can't Linux ?
Where the win32 kernel doesn't change and you have to work around one failure after another the Linux kernel is more agile and these things can be planned for.
What "failures" are you thinking about that need to be worked around ?
This issue is pretty much unique to Linux. The *BSDs don't suffer from it, nor does Windows or OS X (in all fairness, OS X's stability in this regard is a relatively recent development, but OS X is still a fairly young platform so it is excusable). On other platforms, binary compatibility between minor revisions is a given, and even between relatively major revisions not especially uncommon. Only Linux requires things to be recompiled just because you went from kernel a.b.c.d to kernel a.b.c.d+1. (This attitude is pervasive throughout the entire Linux development community - it's not uncommon for userspace software to break binary compatibility from non-major version changes, as well).
Well Nvidia doesn't seem to have a problem with this.
Yes, they do. Every minor kernel revision requires either a) new precompiled kernel modules or b) recompiling the "compatibility layer" that sits between Nvidia's actual drivers and the kernel.
What I don't understand is why all the big computer makers don't say "Up yours, Microsoft" and just start throwing a nice RedHat or Ubuntu installation on their new machines. It would even make the customers' purchase price lower because they don't have to tack on the $100 license fee.
1. People wouldn't buy them.
2. It would cost a lot to reconfigure their production lines and recertify their hardware.
3. Big OEMs don't pay anything close to $100 for a Windows license.
You see, people have known for a long time that Microsoft Windows has been/is an unsecure operating system. It was initially designed for single-user multitasking on non-networked personal computers.
False. Windows NT was designed and built from day one to be a multiuser, networked OS.
What's your secret for keeping a Windows box running for more than a week with no issues? I ask in all honesty because it seems that 99% of Windows users are, by your definition, raging idiots.
There is no secret. The vast majority of Windows users don't have anywhere near the amount of trouble Slashdot FUDsters think they do - and most of the trouble they do have, they'd have regardless of platform.
However, I don't see how that could be a major factor. If I do a random read and that data is cached on the system, I get it from cache regardless of whether I am using softraid or hardware. Same for a write, it's gonna use system ram for a bit and flush it out when it's good and ready regardless of the underlying hardware.. In otherwords, the raid should still benefit from the 2gb of ram even in a hardware raid configuration.
The advantage comes from fewer disk reads necessary to do parity calculations during disk writes. With more cache, there's more chance all the disk blocks that would otherwise need to be read and/or updated, are already in the cache. So, when your system has 16x as much RAM as your disk controller, it's far, far more likely the software RAID won't need to do as many physical disk operations due to the disk blocks necessary for updating parity already being cached.
It's not the data on the filesystem level being cached that's delivering the benefit (although that is somewhat relevant, as software RAID can use knowledge of the filesystem to improve caching, whereas hardware cannot), it's the data on the disk block level.
You would be surprised how much difference this can make. One of the main reason SANS and (good) NASes are so fast (relatively speaking) is because of the massive amounts of cache memory they have in them negating the additional disk activity inherently required for parity-based RAID configurations.
There is a difference with only four drives. A stripe of mirrors, RAID 1+0/10, can sustain two failed drives provided the second drive is part of the second pair. The result of the two drive failure is a stripe of two drives. A mirror of stipes, RAID 0+1, can only survive a single drive failure. When a single drive fails the result is a stripe of two drives and a third drive doing nothing. Draw a picture and it will make sense.
I've drawn many pictures teaching others. You can sustain two drive failures with a RAID 0+1, as long as both drives are the same stripe pair. I can see your argument that the second drive in a stripe is pointless once its partner dies, but it's still not a failure of a physical disk.
Maybe I should have been more specific:). In terms of physical disk failures, there's no difference between a four drive RAID 0+1 and a four drive RAID 10. Both can sustain two failed drives, although the chance of the second drive taking down the entire array is substantially higher than it is with >4 drives.
With four drives - if write performance is not critical - you're better off with RAID6, or to a lesser degree RAID5 with a hot spare.
Slashdot Mirror
I fail to see how Microsoft can be deserving of one iota of blame since least five years ago, let alone today.
Yes, it's been easy to write software for Windows that works properly in a multi-user, non admin scenario. But without any real guidelines (until the Windows Logo program, which didn't debut until long after the XP launch), and without any serious push from Microsoft, developers had little reason to do so.
Microsoft have been telling developers to write LUA-friendly apps - and how to do so - for *at least* five years (really, closer to ten). It only became a _requirement_ for the Windows Logo with the release of XP, but they'd been doing it long before then.
Even if that weren't true, the lack of a "requirement" from Microsoft does not in any way justify or excuse lazy and/or incompetent development and testing practices.
Microsoft has to take some of the blame. They're so good at getting developers to go with the flow in other areas, but not this one.
Short of deliberately breaking non-LUA-friendly applications, there's little else Microsoft could (or can) do. Given the outrage that usually ensues when Microsoft inadvertently, and for good reason, breaks software, I'm sure you can imagine why they weren't very keen to do it deliberately.
And your evidence supporting the claim that Microsoft won't reactive your Vista (or XP for that matter) install after a hardware failure would be...?
Or you could just use "Run As" for those times you need to actually install a COM component.
The trouble is, if you're running as Administrator, you don't notice if you end up doing other things that also require Administrator privs. Like writing to other parts of HKLM, or the Program Files (or even System32) folder. None of that fails on your system, as you're Admin, so you never pick up on it.
This is not an excuse for fundamentally bad development practices. If you're storing run-time or per-user data in system areas, you're either lazy or incompentent. "But it works for me" is not justification for doing something even a first-year software engineering student should be able to tell you is the wrong way to do it.
Your code goes to testing. In order to install your COM components, the testers need to at least install as Administrator. If they forget to test as a limited user, they'll never notice that either.
Nor is it an excuse for poor testing procedures.
No developer has had any reasonable excuse for not writing LUA-friendly Windows software for ~7-8 years. Arguably, it's more like ~10 years, since NT4 was released, but I'm prepared to cut some slack.
Most desktops are only used by one person. Starting from that users "Startup" folder (or equivalent) is effectively the same thing as starting at system boot.
So basically it will die at next reboot. It might be able to start when that same user logs in, but this can be fixed by forcing all config changes to come from root (Admin or whatever)
A solution completely unworkable for the majority of desktop PCs.
Apart from one, it would cost MS a fortune to rewrite office, and they would lose the edge which office has over the competition (all the private hooks into the OS it uses which they dont publicise to other developers)
I see the good old "hidden APIs" myth still exists, despite the complete and utter lack of any actual evidence supporting it.
Tell us, just what "advantages" do you think these supposed "private hooks" engender to a *word processor* or *spreadsheet* program ?
It's important to remember that if developers had been writing their software *properly*, then pretty much any application written after about 1998 should work without a problem in a non-Administrator account.
Microsoft have made life for developers "migrating" their software from DOS-based Windows to NT-based Windows about as easy as humanly possible. Multiuser Windows NT has been in the marketplace for *13 years*. The necessary APIs to handle per-user data stores have been present in every version since Windows 98. The blame for applications that needlessly require Administrator privileges lies 100% at the feet of the people that write such software.
Yes, it was. Windows NT was designed from day one to be a multiuser, networked OS.
LAN's and then the Internet came later and Microsoft injected the necessary code to handle either of those new networking technologies in a quick and (very) dirty fashion.
Wrong.
When saddens me the most is the statement in the original post that Vista can be subject to a rootkit attack. What did they really learn?
All OSes can be subject to a rootkit attack. What point are you trying to make ?
Of course it does. XP is Windows NT 5.1. Vista is Windows NT 6.0.
While Vista was built from Windows 2003 (NT 5.2), not Windows XP, it's still just the latest major release of Windows NT. Vista is to XP, roughly, as Linux 2.6 is to Linux 2.4. (A more accurate comparison might be RHEL3 to RHEL4.)
And with the ghost of Genuine Advantage approaching, i think ReactOS will make its debut just in time. When it's finished, the people who are using pirated copies of XP will probably switch instantly.
I'd say by ca. 2010, any "verification" processes that Vista might be using will have been well and truly cracked, for the tiny proportion of people who don't just end up with a copy of Vista by default when they buy their new PCs.
ReactOS is interesting from an academic perspective, but it's relevance to the real world is small, and not getting any bigger.
Why would companies "not wanting" to switch to Vista, "want" to switch to ReactOS ? Where's the advantage ?
I don't believe the words "most anyone" mean what you think they mean.
Why not ?
Maybe they're admitting what a mickey mouse excuse for a server their OS is, and that i should be playing games on it instead.
Maybe they're doing it to annoy the anal-retentive types who get their knickers in a twist about such silly little irrelevancies...
I think you're vastly overestimating the proportion of machines that use Windows Update.
"Stable" != "static".
This is about as wrong as you can get.
If you think this, I suggest you try loading some binary kernel modules from different minor kernel releases into a running kernel.
And even still it changes FOR THE BETTER.
The point is, would specifying a stable kernel ABI *stop* it from changing "FOR THE BETTER" ? Everyone else manages to do it, why can't Linux ?
Where the win32 kernel doesn't change and you have to work around one failure after another the Linux kernel is more agile and these things can be planned for.
What "failures" are you thinking about that need to be worked around ?
This issue is pretty much unique to Linux. The *BSDs don't suffer from it, nor does Windows or OS X (in all fairness, OS X's stability in this regard is a relatively recent development, but OS X is still a fairly young platform so it is excusable). On other platforms, binary compatibility between minor revisions is a given, and even between relatively major revisions not especially uncommon. Only Linux requires things to be recompiled just because you went from kernel a.b.c.d to kernel a.b.c.d+1. (This attitude is pervasive throughout the entire Linux development community - it's not uncommon for userspace software to break binary compatibility from non-major version changes, as well).
Yes, they do. Every minor kernel revision requires either a) new precompiled kernel modules or b) recompiling the "compatibility layer" that sits between Nvidia's actual drivers and the kernel.
Which products ?
This is essentially what MS did with DR-DOS.
How ?
Cartels exist because they're the only logical conclusion of a free market. The freer the market, the quicker it's dominated by cartels.
With that said, I'm all for abolishing copyright. The production of creative works should be a service, not a product.
Works fine.
1. People wouldn't buy them.
2. It would cost a lot to reconfigure their production lines and recertify their hardware.
3. Big OEMs don't pay anything close to $100 for a Windows license.
False. Windows NT was designed and built from day one to be a multiuser, networked OS.
There is no secret. The vast majority of Windows users don't have anywhere near the amount of trouble Slashdot FUDsters think they do - and most of the trouble they do have, they'd have regardless of platform.
Because Linux's unstable kernel ABI makes writing a (non-OSS) driver difficult.
Every other OS manages to not break drivers between minor (and even major) revisions as a matter of course. Why can't Linux ?
Any modern IDE drive (40G+) should be able to sustain 40 - 50M/s for sequential reads and writes.
The advantage comes from fewer disk reads necessary to do parity calculations during disk writes. With more cache, there's more chance all the disk blocks that would otherwise need to be read and/or updated, are already in the cache. So, when your system has 16x as much RAM as your disk controller, it's far, far more likely the software RAID won't need to do as many physical disk operations due to the disk blocks necessary for updating parity already being cached.
It's not the data on the filesystem level being cached that's delivering the benefit (although that is somewhat relevant, as software RAID can use knowledge of the filesystem to improve caching, whereas hardware cannot), it's the data on the disk block level.
You would be surprised how much difference this can make. One of the main reason SANS and (good) NASes are so fast (relatively speaking) is because of the massive amounts of cache memory they have in them negating the additional disk activity inherently required for parity-based RAID configurations.
I've drawn many pictures teaching others. You can sustain two drive failures with a RAID 0+1, as long as both drives are the same stripe pair. I can see your argument that the second drive in a stripe is pointless once its partner dies, but it's still not a failure of a physical disk.
Maybe I should have been more specific :). In terms of physical disk failures, there's no difference between a four drive RAID 0+1 and a four drive RAID 10. Both can sustain two failed drives, although the chance of the second drive taking down the entire array is substantially higher than it is with >4 drives.
With four drives - if write performance is not critical - you're better off with RAID6, or to a lesser degree RAID5 with a hot spare.