Competitor? That must be why almost everything in OS/2 was covered with Microsoft copyright notices.
Microsoft and IBM's partnership dissolved not long after the release of Windows 3.0. There were a few little articles about it here and there in various low-profile computer rags of the day. You might remember it, if you were around at the time.
However, having spent a considerable amount of time working with Citrix when it came out and lots of time on the phone with their support organization and software engineers, I would completely disagree with your assertion that "Windows NT was designed and build from the ground up as a multiuser OS". I was an MCSE - Microsoft's targetted audience at that time, someone who already had a couple of years time-in-grade supporting MS products (NT 3.51, 3.51 with newshell, and NT 4.0) and intimately familiar with the functioning of 'normal' NT. The engineers at Citrix certainly disagree with you, and I can't really challenge them since they had the source code. I know that there were constant problems related to things such as the decision to run the GDI as a privileged user, and the fact that many processes must run as the privileged user and cannot run multiple times.
You are referring to the GUI layer, not the "OS" (where "OS" is being used in the academic, rather than marketing, sense). Remember, NT was not originally built to have the Windows GUI laid on top of it. It's quite possible to have a multiuser OS, then stick a single user GUI on top of it (OS X is another example). Just because the GUI layer can't handle multiple interactive users, doesn't mean the OS itself isn't multiuser.
Perhaps the distinction is that MS meant "usable by multiple sequential logins" and Unix is "usable by multiple concurrent logins" - an important distinction (as Citrix would testify)
"Multiuser" means the ability to run processes in separate user contexts. NT could do this, even though it could not handle multiple interactive GUI sessions without the work Citrix did. This does not make NT any less multiuser, any more than the hacks to Windows 9x and DOS that allowed multiple interactive users turned them from single-user into multiuser OSes. Ironically, with it's lack of a superuser concept, if anything NT is *more* multiuser than unix (until equivalents on unix started appearing recently).
Note that multiple non-GUI logins on Windows (eg: with a telnet server) have always been possible, as have non-interactive services running in separate user contexts. The problems you are describing are limited solely to the GUI layer.
Also, this whole issue has become null and void since Windows 2000 (? I think - might have been XP) when any GUI logon to NT became a terminal server session. Windows 2000 was quite some time ago.
More of what you said has the ring of relevance, but I'm not ready to call it 'true'. I'll grant that there is nothing an OS can do to protect one from 'trojans', but I contest your assertion about viruses and worms.
The vast, vast majority of "viruses", "worms" and "spyware" are, strictly speaking, trojans. "Real" worms - that use unpatched remote exploits and spread automatically - are very uncommon on Windows, as they are on all other platforms. Anything that requires user interaction to kick off - which covers nearly all browser and email vectors - is, strictly speaking, a "trojan".
Also, obviously, anything exploiting and already patched vulnerability cannot be counted as "current".
I browsed Sophos' virus database for a while, and a large number of them use exploits to system services that run as privileged users, others jigger holes in the file system security of windows, and various other nefarious things that would be (have in fact proven to be) more difficult in various *nix environments - far from 'failing' if run as a non-privileged user.
I've no doubt they exist - my point is they're relatively uncommon.
Sorry, but I have to disagree; software RAID is potentially slower and less reliable.
Benchmarks almost always show (modern) software RAID to be faster than hardware RAID, in the common case.
Soft-RAID systems typically store the RAID metadata on the disks themselves, thus they're vulnerable to damage/destruction if someone screws up a format operation. Hard-RAID systems are going to store this metadata on separate, battery backed, storage.
Are you seriously trying to argue moving from multiple points of failure (multiple drives) to a single point of failure (the RAID controller) is going to provide a more reliable system ?
There's a reason why good hardware RAID controllers store the array metadata on the physical drives and it's the same reason software RAID does it.
I can't speak to HP controllers being underpowered, I only have experience with SUN and IBM. I get the impression that you're used to running soft-RAID on small, non-critical systems?
Unless you're dealing with large numbers (10+) of drives, combined with limited bus bandwidths and extremely high-end RAID controllers with gigabytes of cache, software RAID is almost always going to be faster than hardware RAID. Even then, the extra flexibility of software RAID will probably make it the better overall choice.
This is not to say hardware RAID isn't useful even when "slower" - the abstraction of only having to deal with a single device at the OS level can be very handy.
Why was Microsoft pushing Win32s and other technology that was incompatible with OS/2?
Gee, I don't know, maybe because it was *better* than Win16 ? The upgrade path to Win32 ?
Do you think that could be it ? Can you imagine a software company promoting a newer, better product over an older, less capable, *competitor's* product ? Like Apple did with Cocoa over Carbon ? Was that a similar moral outrage for you ?
For saftey's sake, I just used 6 hard drives with 2 pairs striped and then had those drives mirror each other with 2 extra that would go to a drive when one failed.
You are describing RAID 0+1 (mirrors over stripes). RAID 1+0/10 (stripes over mirrors) is more reliable as it potentially allows more drives to fail before data is lost and takes less time for replaced drives to resync.
(Although with only four drives there is no difference.)
You really think a 6.8 Gbps stream will take a "fraction of a single percentage" of a CPU. Lets look at this... Round down to 800MBytes/Sec. How many instructions do you think have to be spent processing EACH byte. Realize that there will at least three read, a XOR, and a write operation for each word. lets make it an even four to keep the math simple so there are 800M operations that need to be performed every second on a stream of this size. Lets say a Nice 4GHz processor, running with 2 IPC (heck, lets make it four with dual core) and that is 5% right there.
[...]
Now that we have gotten over the fraction of a single CPU myth... try again.
A 2.8 Ghz Pentium 4 has a RAID5 checksumming throughput of around 3.5GBytes/sec. So your 800MBytes/sec (which is a truly massive amount of data to writing to disk - nearly 50 gigs a minute) will use around 22% of it.
There *are* scenarios where hardware RAID can do a faster job than (modern) software RAID - but they're few, far between, specialised and very expensive.
Because it's often slower to do so. We ran tests on a good Adaptec u320 raid controler about a year back and though cpu usage was good. We got much better performance out of Linux softraid5. I would suspect this was because the host cpu was faster than that on the controler.
It's got nothing to do with CPU power. It's because the OS almost certainly has vastly more memory available (how much RAM in the system vs on the controller ?) and is able to better utilise that to cache data and avoid physical disk activity.
The (relative) slowness of RAID 5 does *NOT* come from calculating parity, it comes from the additional physical disk activity getting the data to caclulate the parity (and the subsequent disk activity to update parity and/or data blocks on disk) entails.
That's because you can do RAID 0, 1 or any combination of 0 and 1 without needing parity data. The performance killer on RAID 5 (and any other form of RAID that requires parity) is in the XOR operations used to compute and verify the parity information. In order for RAID 5 to perform at a satisfactory rate and not totally bog down your CPU, the XOR calculations should be handled on a dedicated hardware controller, not in software.
No, no, no, no. The processing overhead of parity calculations is miniscule on any remotely modern CPU (even a paltry 300Mhz Pentium 2 has a parity throughput of ~700M/sec).
The performance killer on parity-based RAID configuration is the additional disk reads required to calculate the parity, *not* the parity calculations themselves. Which is why modern software RAID is typically faster than hardware RAID until you get into larges numbers of disks and/or machines with limited bus bandwidth.
This "RAID 5 is slow because of parity calculations" meme must die (although, admittedly, it's a good indicator of whether or not someone really understands what's going on).
Is not like microsoft never did that kind of things. I think that was 3.1 the Windows version that had an specific check to avoid being run under DrDOS.
There was no such thing. There was a *beta* of Windows 3.x which would display a warning during installation if it detected a non-Microsoft DOS clone. It didn't stop it actually running, and it was never present in any release version of Windows 3.x.
Not to mention, there are perfectly valid technical reasons why not running under non-Microsoft DOSes was justifiable.
I used OS/2 extensively. Indeed, I've still got my original media for several versions at home.
Microsoft went out of their way to sabotage OS/2 by "enhancing" Windows in ways that would be difficult or impossible for IBM to emulate.
No, they didn't. You have no idea what you're talking about (or think you are).
IBM didn't "emulate" Windows in OS/2, they used their licensed source code for the Win16 API. Later releases (when the code licensing no longer applied) required the user to provide their own copy of Windows, which was used to run Windows software.
OS/2 ran Windows 3.x software as well as - many would say better - than Windows 3.x did. It was never "broken" at all.
Now, let's have a quick look at what the original poster was suggesting. He's saying that if Apple manage to come out with a 100% (or close to it) compatible implementation of Win32, Microsoft will modify the Win32 API to deliberately "break" it, thus rendering it useless. There are a few fundamental problems here that indicate he hasn't thought this dastardly plan all the way through:
* First and foremost, Microsoft won't make any changes that breaks existing software on a large scale (they're reluctant enough to do it just on a small scale). So the scope of any such "API sabotage" is limited to software released after any such change was made (which, realistically, is going to be *at least* 12 months down the track).
* Microsoft would have to convince developers to modify their software to use the new API changes. Given the lack of interest most developers show in changing their software for _good_ reasons (Exhibit A: the plethora of software that needlessly requires Administrator privileges) I can't see many of them doing it for bad ones.
* Microsoft have no reliable way of retroactively modifying existing Windows installations.
* The extremely marginal benefits wouldn't even come close to outweighing the legal risks.
These roadblocks _alone_ (and there are more) make even the suggestion that Microsoft will just change their API willy-nilly to break an OS X/win32 make the whole proposal laughable. It's pretty clear the original poster hadn't put any more thought into it than it takes to come up with "Micro$oft is t3h suxx0r" (which, not coincidentally, applies to most criticisms on Slashdot about Microsoft).
If Apple reverse engineered the Windows API, Microsoft would probably make "improvements" to it out of spite, to cause things to break when run on the Mac's reverse-engineered API.
Did you even stop for a second to think how idiotic - not to mention unlikely, bordering on impossible - this idea is ?
Windows has always been a multi-user kluge on top of a kernel that's really a single user kernel at heart.
False. Windows NT was designed and build from the ground up as a multiuser OS.
Many of the 'problems' that Windows has dealt with over the years are directly related to that issue. Until the most recent versions of windows, "Privilege Escalation" attacks were nigh on trivial; most viruses and worms and many trojans rely on just such attacks to work.
No, most viruses, worms and trojans rely on the fact most users already run as a highly privileged user (Administrator). Far from even attempting any privilege escalation attacks, the vast majority simply fail outright if the user running them has insufficient privileges.
The lack of malware on *nix in general has a lot to do with the relative ( compared to Windows, specifically ) difficulty of that same privilege escalation.
The lack of malware on unixes is largely due to its user demographics. The average unix user isn't going to fall for the "let this screensaver run as root" trick, nor do they typically run as a user with elevated privileges - and that's assuming they're even in the position to download and run arbitrary code.
With that said, there's little the typical piece of malware would want to do, that it couldn't do from a standard unix user account - *especially* on single user desktop unix machines.
It's specious to suggest that malware authors have not targeted *nix; if you think that, you should spend some time watching firewalls behind which are *nix boxen that do something - like move money, or other valuable asset.
There is a vast gulf of difference between the generic, automated malware that infests desktop Windows systems from things like chain-letter emails and porn sites, and active, specifically targeted intrusion attempts towards high profile targets like banks. To state otherwise is naivety at best, deliberate disingenuity at worst.
"Malware authors" _haven't_ targeted unixes - to suggest otherwise is silly, given the lack of even anecdotal evidence. Why would they when the chances of success are so minimal, since the typical unix "end user" is either highly technically competent or in a centrally managed, monitored and secured environment ? Completely and utterly independent of any OS vulnerabilities, the chances of any serious malware infestation or propogation on the typical unix platform are slim at best.
There is a fundamental difference between single-user desktops (regardless of what OS they're running - be it Windows, OS X, Linux or something else) and centrally managed multiuser systems (be they unix based or otherwise). You can't compare the security of one by the same standards of the other, nor can you really use similar methods to "secure" them.
except, on a Mac, before it does anything vicious you have to give your login password to the sudo command window.
Pretty much everything any piece of malware might want to do, it can do on an OS X machine without prompting for a password, assuming a default configuration.
Wait a second! You think it is too much security to notify a user when a worm is trying to access their personal files? You think accurate information and options are excessive?
No. Leave that poor straw man alone.
All I'm pointing out is when users getting multiple exposures to malware every day, are going to get bombarded with dialog boxes, which are subsequently going to have any positive effect they might have had, dramatically reduced.
Also, if they ignore them, fine, they will have a pile of open dialogue boxes and the worms will fail to compromise their system. That is a win.
But they won't ignore them, they'll choose the options that let the spyware in.
Thus, in the worst case this will stop 50% of existing worm propagation at the same time as enabling knowledgeable users to be secure.
This 50% figure comes from where ?
Autoload should spawn a dialogue, but all the others have no need to unless the developer feels like it (just like now).
Really ? You're just going to let a program installer spew files wantonly all over the system ? Or, you're not going to let third parties modify any aspect of the system software at all ?
Not so. Talking to the internet or other programs is easy to understand. reading and writing files is easy to understand. What exactly do you think can't be explained?
What metaphor are you going to use to explain why writing to certain files is ok or not ok ?
First, most users will balk if they realize it is not pictures, but a program.
Oh, come on, use your imagination. Of course any such program would *also* display a few pictures to allay any user suspicions.
Second, even the most dimwitted user will associate their address book with the people in it with naked pictures and realize that the possibility of their mom getting naked pictures from them is not worth the risk of allowing access.
Try to think a little outside the square. How about pictures of cars, clothes or ponies ?
Third, it is easier to educate people that pictures don't need to access anything let alone your address book than it is to educate them as to what a file extension is.
Agreed. But if they REALLY REALLY want to look at the pictures and the only way is to click the "grant access to address book" button, what do you think is going to give first ?
Fourth, for those users who don't care at all and want to see naked pictures at any cost, they can still tell it to deny access and the program will still run the same because the OS can hand the program a bunch of dummy addresses.
Ah, now we're getting into some good ideas. Might produce some interesting failure scenarios, though, when the user accidentally clicks the wrong button trying to allow genuine access. Not to mention it will be ineffective once the list of "dummy addresses" and/or the algorithm to generate them, becomes widely known.
Gee, I haven't read, "history and experience" can you send me an URL? Just read a decent book on security theory already.
I've yet to see a single example where the "more secure" path is also the easier one. From you or anyone else.
Assuming there is a game, both actions will let them play, since the malware doesn't know whether they have real addresses or fake.
And just how long do you think this "fake address" thing will be a decent defense ?
From the UI perspective, I disagree, since neither letting it read or not letting it read e-mail addresses is in any way related to playing the game.
"To automatically tell your friends about how well you're doing in this game, or to share save game points with them [...]".
Why would they think either option would effect the outcome?
Because when they click the option that doesn't give the malware what it wants, the outcome *is* affected when the little game doesn't run.
Old Warren is giving them a friendly tap on the nose to the effect of "you call THAT being charitable? Try this for size--and I'm not giving it to anything with my name on it, either. THAT'S charity."
If he'd done that, we wouldn't be reading about it on Slashdot, would we ?
To recap, I said I don't trust the Foundation to do what the masses would want, ie, if put to a vote what would The People opt to do with such collossal resources?
The People (tm) would vote for fuel subsidies and tax cuts. Just like they do every time they can.
I already "donated" several times by buying copies of Windows.
Purchase != Donation.
As it happens I also give every month to Concern Worldwide via direct debit and to put it bluntly, I would rather I was able to allocate my wealth to charities of my choosing rather than letting Gates do it for me....
Then do that. But don't be hypocritical and criticise him for not letting you choose where your "wealth to charities" can go while simultaneously saying you should be able to dictate to him where his "wealth to charities" is apportioned.
The OS was sold, and IE was tied to the OS. Please read what I said.
Everything that comes with Windows is "tied to the OS". Yet no-one seems to care about all those other things.
Effectively, you are saying Microsoft cannot add new functionality to Windows. If you cannot see the fundamental flaw in that position, then there's a serious problem.
Name one other OS that does.
OS X, any Linux distribution that includes KDE and/or GNOME. I think BeOS did, although I'm not 100% on its architecture without going back and reminding myself.
You can use/remove/change the browser on Linux/Mac OS X.You might be thinking of Konqueror, which comes with KDE, but you can remove KDE and you can remove konqueror and keep the rest of KDE.
You cannot remobe WebCore/WebKit from OS X. Nor can you remove khtml and gtkhtml from KDE and GNOME, respectively. At least not without hbreaking things that use them.
They weren't a monopoly at the time they were writting their GUI/file manager and networking stack (TCP/IP might have come at the point where you could argue they were a monopoly, but I'm not sure).
That you would even consider Microsoft not being allowed to incorporate such basic functionality as a network stack and file manager, because of "monopoly" status, is ridiculous.
And those components were integrated into other OSes before MS did it. Both of which are a big deal legally.
It's quite arguable that Apple did it first with Cyberdog and co. Although both projects were created at basically the same time, so it's hard to say for sure. If you just want to talk about bundling of standalone applications (like the first two versions of IE), OS/2 did it before Windows.
However, the simple fact is Microsoft weren't the only company at the time componentising and integrating a web browser. An architecture which has since been duplicated on every major platform.
I assume you are young, or in a small company.
No.
Because in large businesses the execs sure as hell should have known about illegal tying...
It's difficult to see why a web browser would be any different to the myriad other pieces of functionality that have moved from the purvue of 3rd party application to OS-included in the 15-odd years beforehand.
and deliberatley breaking the law isn't nearly as common as you suggest. Writting down that you intend to break the law and then doing it, even less so.
That wasn't what I was suggesting. What gets Slashdot readers upset is the language - like "killing them" is someone an uncommon phrase in management meetings and actually means something like assassination.
See the way criminal tying works is that you have a monopoly on something that people want (like, say, and OS), and you tie the sale of that thing with something unrelated (like, say, a browser).
Right. So no product created by a company considered a monopoly can be improved if a competitor already offers that functionality in another product.
You seem to be ignoring the facts that IE was never sold and the technical aspect of a shared browser component is a perfectly valid piece of functionality for an OS to include (and has since become commonplace).
Funny how people never seem to get their knickers in a twist about Windows including a TCP/IP stack, GUI and file manager. I've never been able to figure out if they simply can't see the hypocrisy or just ignore it.
Or, simply, it would be fine if Apple execs wanted to "kill MS" and they could do a lot of things to try to make that happen (like, say, "tying" their browser to their OS)... however MS are held to a higher legal std., because they are a _monopoly_ so for instance stopping development of MS Office for Mac OS X would probably be not so clever.
The outrage from Slashdot readers comes from the idea that managers and execs in Microsoft are saying they want to "kill" the competition. This is largely because most of them have never been anywhere near an upper-level management meeting and hence don't realise that colourful language like that is commonplace and harmless. Much like a sports coach telling his players to go out and "kill" the other team isn't speaking literally - although the average Slashdot reader would probably be unfamiliar with that scenario as well.
Once, per program, per action that is outside of the norm.
"Norm" is notoriously difficult to initially define and even harder to maintain over time (programmatically).
For example, how often will a user be alerted when a program wants to read their e-mail address book, or IM buddy list (excluding the app that made them)? About once per worm, with the possible false positive if a user installs a new IM client or e-mail application, in which case they will find such a request pretty normal.
If they get a request every other day from whichever worm has piggybacked itself onto an email attachment or the latest flash game, those prompts are going to be considered pretty normal, and will be ignored.
OS X has this problem. The graphical sudo prompt appears reasonably frequently and most users happily type in their password neither pause nor forethought. Why ? Because they lack both the knowledge necessary and the incentive to determine whether or not the obligatory "Are you sure" prompt is a) expected and b) reasonable. All they understand is that they need to type in their password to run that program, or complete that task.
The typical end user simply doesn't have the ability to determine whether or not $PROGRAM wanting to access their address book is reasonable - and that's an incredibly simple example. Move onto more complex things like installing software, modifying system files and inbound/outbound network connections and the picture becomes even more grim.
Did you read the examples I presented? Which button on those do you click to "make it go away?" People will have to read them or pick randomly.
Which they will. They will click on the buttons until they find the one that allows them to complete whatever higher-level task it was that triggered the dialog.
Since they should only show up in rare instances, so users will not be used to seeing them. The rarity will make them seem more important and more likely to be read.
When people are receiving and executing malware daily, those prompts will not be rare.
Most users can read English and understand the basic metaphors employed by the computer.
Maybe. But the trouble with metaphors is they're only suitable for high-level general explanations, not the low-level fine-grained decisions that need to be made for security purposes.
Any user can understand, "the program 'naked_pictures' would like to read your e-mail address book. (Stop it from reading the e-mail addresses)(Let it read them once)(Always let it read the e-mail address book)(Advanced Options)." That dialogue box, by itself, would stop most e-mail worms today and make it a difficult instead of trivial vector.
No, it won't, because people will happily let it read their address book so they can look at the naked pictures.
"After all, what harm could it do ?"
Most software should have zero.
Most software will require *at least* one dialog, during installation. Probably several, as it does things like add itself to a common user desktop, create start menu entries, insert itself into autoload lists, etc.
Assuming you're applying this on top of Windows, take a look at the mess that is Vista beta. It will certainly be fewer dialogue boxes.
I haven't been able to use Vista myself, and I'm not going to pass judgement based on a few screenshots.
Also, IE, outlook, and a dozen other programs already show warnings when you download any executable, regardless of it is violating a sandbox or not. These can be eliminated, along with dozens of other useless warnings that don't provide real options.
Not letting questionable code onto the system in the first place is an important step. It avoids both system-level exploits and bad user decisions ever happening.
Because MS has not provided incentive for developers to make their software behave. Their dev tools don't make it work by default and critical apps MS d
It may not be possible to define malicious, "but it is possible to programmatically define "uncommon" and "without asking the user."
If you are going to prompt the user for every potentially malicious action, then you are again proposing the "dialog box storm" method.
Dialog boxes warning about security don't work. They don't work because, primarily, most people are too lazy to even bother reading them, and just click whichever buttons makes them disappear and get the desired result. The other big reason they don't work is because most people don't have sufficient knowledge to make an educated decision, and typically acquiring a sufficient level of knowledge is a non-trivial task most of them have zero interest in.
Making dialog boxes easier to read, will not make people less lazy.
Reasonable default permissions should result in fewer, not more dialogue boxes than a user is subjected to today.
Unlikely. Even the default "restricted" user has more than enough privileges to do the things 99% of malware wants to do. So existing systems need to be locked down even tighter before they can start being "secure". This is certainly going to result in more "security warnings", not less.
The only reason most malware breaks today outside of non-Admin accounts is because it's as badly written as most other Windows software.
First, users have never been given the information or the level of control needed.
Yes, they have (well, I'll agree the "control" aspect could be better, but it's far from nonexistant). Now, certainly today that knowledge isn't spoon-fed them in school, but it's definitely out there and not particularly difficult to find. Not to mention the vast majority of scams don't need any sort of specialised knowledge to identify, they are *obviously* scams. Yet people who would never even consider the actions necessary to fall victim to a scam in the "real world" regularly do so when using computers.
Personally, I blame the invention of the undo button. Everyone thinks anything they do on a computer can just be undone with the click of a button - that's it's not really real - and that nothing actually happens out in "meatspace" until some other person actually does it. I'd be willing to bet a frighteningly large proportion of people think internet banking transactions are actually printed out at the bank and processed each evening by tellers.
Until then, branding them as "lazy" or "ignorant" is absurd. A user should not need a PhD to operate an everyday tool, which is about equivalent to the level of knowledge required to actually work around all the security holes and poor design decisions of most OS's today. It is the job of the OS to give them the information and the present them with choices.
You will get no argument from me that users should not need in-depth knowledge of a computer to be able to use it.
I will, however, strongly disagree with your implication that the necessary knowledge to make reasonable decisions regarding granting arbitrary levels of access to arbitrary parts of the system can be effectively distilled into an "idiot-proof" dialog box.
Even with a PhD, it is nearly impossible so safely run an untrusted binary [...]
Note that introducing a dozen dialogs at various points of the execution process ("Do you want to let the program access this file ?" "How about this one ?" "Do you want to let the program open a network connection to $WEBSITE ?" "Do you want to allow the program to write this file ?") will not help the situation greatly. The user is not interested in reading dialog boxes, they want to play their game. They *will* take the path of least resistance (and, hence, least security) trying to achieve their goal.
Until the average user can easily and safely run random programs, we will always be at risk from trojans, since users will sacrifice security, for functionality... a choice they should never have to make.
They want to run any damn thing they please, but they want the OS to stop it from doing anything malicious.
These two goals are fundamentally in conflict, since "malicious" cannot be objectively and programmatically defined.
I've said it before... new software on Windows should be running in a jail or sandbox or VM or something and by default should not be allowed to touch anything without the user being informed in real English and given the option to granularly deny the software, without stopping that software from running in most cases. This would solve the vast majority of Window's and IE's security problems.
No, it wouldn't. You have proposed the standard "dialog box storm" solution to security, and it doesn't work. Primarily because users are lazy, but also because they're ignorant and simply uninterested in acquiring sufficient knowledge to make educated decisions.
Asking the user "are you sure" three times is not more secure than asking them "are you sure" twice.
As long as lazy, ignorant and downright stupid end users are able to execute arbitrary code on their computers, the malware problem will not - and can not - be solved.
Slashdot Mirror
But it couldn't, back in the days of NT 3.x and 4.x.
Microsoft and IBM's partnership dissolved not long after the release of Windows 3.0. There were a few little articles about it here and there in various low-profile computer rags of the day. You might remember it, if you were around at the time.
You are referring to the GUI layer, not the "OS" (where "OS" is being used in the academic, rather than marketing, sense). Remember, NT was not originally built to have the Windows GUI laid on top of it. It's quite possible to have a multiuser OS, then stick a single user GUI on top of it (OS X is another example). Just because the GUI layer can't handle multiple interactive users, doesn't mean the OS itself isn't multiuser.
Perhaps the distinction is that MS meant "usable by multiple sequential logins" and Unix is "usable by multiple concurrent logins" - an important distinction (as Citrix would testify)
"Multiuser" means the ability to run processes in separate user contexts. NT could do this, even though it could not handle multiple interactive GUI sessions without the work Citrix did. This does not make NT any less multiuser, any more than the hacks to Windows 9x and DOS that allowed multiple interactive users turned them from single-user into multiuser OSes. Ironically, with it's lack of a superuser concept, if anything NT is *more* multiuser than unix (until equivalents on unix started appearing recently).
Note that multiple non-GUI logins on Windows (eg: with a telnet server) have always been possible, as have non-interactive services running in separate user contexts. The problems you are describing are limited solely to the GUI layer.
Also, this whole issue has become null and void since Windows 2000 (? I think - might have been XP) when any GUI logon to NT became a terminal server session. Windows 2000 was quite some time ago.
More of what you said has the ring of relevance, but I'm not ready to call it 'true'. I'll grant that there is nothing an OS can do to protect one from 'trojans', but I contest your assertion about viruses and worms.
The vast, vast majority of "viruses", "worms" and "spyware" are, strictly speaking, trojans. "Real" worms - that use unpatched remote exploits and spread automatically - are very uncommon on Windows, as they are on all other platforms. Anything that requires user interaction to kick off - which covers nearly all browser and email vectors - is, strictly speaking, a "trojan".
Also, obviously, anything exploiting and already patched vulnerability cannot be counted as "current".
I browsed Sophos' virus database for a while, and a large number of them use exploits to system services that run as privileged users, others jigger holes in the file system security of windows, and various other nefarious things that would be (have in fact proven to be) more difficult in various *nix environments - far from 'failing' if run as a non-privileged user.
I've no doubt they exist - my point is they're relatively uncommon.
Benchmarks almost always show (modern) software RAID to be faster than hardware RAID, in the common case.
Soft-RAID systems typically store the RAID metadata on the disks themselves, thus they're vulnerable to damage/destruction if someone screws up a format operation. Hard-RAID systems are going to store this metadata on separate, battery backed, storage.
Are you seriously trying to argue moving from multiple points of failure (multiple drives) to a single point of failure (the RAID controller) is going to provide a more reliable system ?
There's a reason why good hardware RAID controllers store the array metadata on the physical drives and it's the same reason software RAID does it.
I can't speak to HP controllers being underpowered, I only have experience with SUN and IBM. I get the impression that you're used to running soft-RAID on small, non-critical systems?
Unless you're dealing with large numbers (10+) of drives, combined with limited bus bandwidths and extremely high-end RAID controllers with gigabytes of cache, software RAID is almost always going to be faster than hardware RAID. Even then, the extra flexibility of software RAID will probably make it the better overall choice.
This is not to say hardware RAID isn't useful even when "slower" - the abstraction of only having to deal with a single device at the OS level can be very handy.
Gee, I don't know, maybe because it was *better* than Win16 ? The upgrade path to Win32 ?
Do you think that could be it ? Can you imagine a software company promoting a newer, better product over an older, less capable, *competitor's* product ? Like Apple did with Cocoa over Carbon ? Was that a similar moral outrage for you ?
You are describing RAID 0+1 (mirrors over stripes). RAID 1+0/10 (stripes over mirrors) is more reliable as it potentially allows more drives to fail before data is lost and takes less time for replaced drives to resync.
(Although with only four drives there is no difference.)
[...]
Now that we have gotten over the fraction of a single CPU myth... try again.
A 2.8 Ghz Pentium 4 has a RAID5 checksumming throughput of around 3.5GBytes/sec. So your 800MBytes/sec (which is a truly massive amount of data to writing to disk - nearly 50 gigs a minute) will use around 22% of it.
There *are* scenarios where hardware RAID can do a faster job than (modern) software RAID - but they're few, far between, specialised and very expensive.
It's got nothing to do with CPU power. It's because the OS almost certainly has vastly more memory available (how much RAM in the system vs on the controller ?) and is able to better utilise that to cache data and avoid physical disk activity.
The (relative) slowness of RAID 5 does *NOT* come from calculating parity, it comes from the additional physical disk activity getting the data to caclulate the parity (and the subsequent disk activity to update parity and/or data blocks on disk) entails.
No, no, no, no. The processing overhead of parity calculations is miniscule on any remotely modern CPU (even a paltry 300Mhz Pentium 2 has a parity throughput of ~700M/sec).
The performance killer on parity-based RAID configuration is the additional disk reads required to calculate the parity, *not* the parity calculations themselves. Which is why modern software RAID is typically faster than hardware RAID until you get into larges numbers of disks and/or machines with limited bus bandwidth.
This "RAID 5 is slow because of parity calculations" meme must die (although, admittedly, it's a good indicator of whether or not someone really understands what's going on).
...Was an urban myth. Even people working at Lotus either hadn't heard of it or thought it was ridiculous.
There was no such thing. There was a *beta* of Windows 3.x which would display a warning during installation if it detected a non-Microsoft DOS clone. It didn't stop it actually running, and it was never present in any release version of Windows 3.x.
Not to mention, there are perfectly valid technical reasons why not running under non-Microsoft DOSes was justifiable.
I used OS/2 extensively. Indeed, I've still got my original media for several versions at home.
Microsoft went out of their way to sabotage OS/2 by "enhancing" Windows in ways that would be difficult or impossible for IBM to emulate.
No, they didn't. You have no idea what you're talking about (or think you are).
IBM didn't "emulate" Windows in OS/2, they used their licensed source code for the Win16 API. Later releases (when the code licensing no longer applied) required the user to provide their own copy of Windows, which was used to run Windows software.
OS/2 ran Windows 3.x software as well as - many would say better - than Windows 3.x did. It was never "broken" at all.
Now, let's have a quick look at what the original poster was suggesting. He's saying that if Apple manage to come out with a 100% (or close to it) compatible implementation of Win32, Microsoft will modify the Win32 API to deliberately "break" it, thus rendering it useless. There are a few fundamental problems here that indicate he hasn't thought this dastardly plan all the way through:
* First and foremost, Microsoft won't make any changes that breaks existing software on a large scale (they're reluctant enough to do it just on a small scale). So the scope of any such "API sabotage" is limited to software released after any such change was made (which, realistically, is going to be *at least* 12 months down the track).
* Microsoft would have to convince developers to modify their software to use the new API changes. Given the lack of interest most developers show in changing their software for _good_ reasons (Exhibit A: the plethora of software that needlessly requires Administrator privileges) I can't see many of them doing it for bad ones.
* Microsoft have no reliable way of retroactively modifying existing Windows installations.
* The extremely marginal benefits wouldn't even come close to outweighing the legal risks.
These roadblocks _alone_ (and there are more) make even the suggestion that Microsoft will just change their API willy-nilly to break an OS X/win32 make the whole proposal laughable. It's pretty clear the original poster hadn't put any more thought into it than it takes to come up with "Micro$oft is t3h suxx0r" (which, not coincidentally, applies to most criticisms on Slashdot about Microsoft).
Did you even stop for a second to think how idiotic - not to mention unlikely, bordering on impossible - this idea is ?
False. Windows NT was designed and build from the ground up as a multiuser OS.
Many of the 'problems' that Windows has dealt with over the years are directly related to that issue. Until the most recent versions of windows, "Privilege Escalation" attacks were nigh on trivial; most viruses and worms and many trojans rely on just such attacks to work.
No, most viruses, worms and trojans rely on the fact most users already run as a highly privileged user (Administrator). Far from even attempting any privilege escalation attacks, the vast majority simply fail outright if the user running them has insufficient privileges.
The lack of malware on *nix in general has a lot to do with the relative ( compared to Windows, specifically ) difficulty of that same privilege escalation.
The lack of malware on unixes is largely due to its user demographics. The average unix user isn't going to fall for the "let this screensaver run as root" trick, nor do they typically run as a user with elevated privileges - and that's assuming they're even in the position to download and run arbitrary code.
With that said, there's little the typical piece of malware would want to do, that it couldn't do from a standard unix user account - *especially* on single user desktop unix machines.
It's specious to suggest that malware authors have not targeted *nix; if you think that, you should spend some time watching firewalls behind which are *nix boxen that do something - like move money, or other valuable asset.
There is a vast gulf of difference between the generic, automated malware that infests desktop Windows systems from things like chain-letter emails and porn sites, and active, specifically targeted intrusion attempts towards high profile targets like banks. To state otherwise is naivety at best, deliberate disingenuity at worst.
"Malware authors" _haven't_ targeted unixes - to suggest otherwise is silly, given the lack of even anecdotal evidence. Why would they when the chances of success are so minimal, since the typical unix "end user" is either highly technically competent or in a centrally managed, monitored and secured environment ? Completely and utterly independent of any OS vulnerabilities, the chances of any serious malware infestation or propogation on the typical unix platform are slim at best.
There is a fundamental difference between single-user desktops (regardless of what OS they're running - be it Windows, OS X, Linux or something else) and centrally managed multiuser systems (be they unix based or otherwise). You can't compare the security of one by the same standards of the other, nor can you really use similar methods to "secure" them.
All of which apply equally, regardless of platform.
The "problems" in Windows have nothing to do with its core.
Likewise, the lack of malware on OS X, has SFA to do with its "UNIX core".
Pretty much everything any piece of malware might want to do, it can do on an OS X machine without prompting for a password, assuming a default configuration.
No. Leave that poor straw man alone.
All I'm pointing out is when users getting multiple exposures to malware every day, are going to get bombarded with dialog boxes, which are subsequently going to have any positive effect they might have had, dramatically reduced.
Also, if they ignore them, fine, they will have a pile of open dialogue boxes and the worms will fail to compromise their system. That is a win.
But they won't ignore them, they'll choose the options that let the spyware in.
Thus, in the worst case this will stop 50% of existing worm propagation at the same time as enabling knowledgeable users to be secure.
This 50% figure comes from where ?
Autoload should spawn a dialogue, but all the others have no need to unless the developer feels like it (just like now).
Really ? You're just going to let a program installer spew files wantonly all over the system ? Or, you're not going to let third parties modify any aspect of the system software at all ?
Not so. Talking to the internet or other programs is easy to understand. reading and writing files is easy to understand. What exactly do you think can't be explained?
What metaphor are you going to use to explain why writing to certain files is ok or not ok ?
First, most users will balk if they realize it is not pictures, but a program.
Oh, come on, use your imagination. Of course any such program would *also* display a few pictures to allay any user suspicions.
Second, even the most dimwitted user will associate their address book with the people in it with naked pictures and realize that the possibility of their mom getting naked pictures from them is not worth the risk of allowing access.
Try to think a little outside the square. How about pictures of cars, clothes or ponies ?
Third, it is easier to educate people that pictures don't need to access anything let alone your address book than it is to educate them as to what a file extension is.
Agreed. But if they REALLY REALLY want to look at the pictures and the only way is to click the "grant access to address book" button, what do you think is going to give first ?
Fourth, for those users who don't care at all and want to see naked pictures at any cost, they can still tell it to deny access and the program will still run the same because the OS can hand the program a bunch of dummy addresses.
Ah, now we're getting into some good ideas. Might produce some interesting failure scenarios, though, when the user accidentally clicks the wrong button trying to allow genuine access. Not to mention it will be ineffective once the list of "dummy addresses" and/or the algorithm to generate them, becomes widely known.
Gee, I haven't read, "history and experience" can you send me an URL? Just read a decent book on security theory already.
I've yet to see a single example where the "more secure" path is also the easier one. From you or anyone else.
Assuming there is a game, both actions will let them play, since the malware doesn't know whether they have real addresses or fake.
And just how long do you think this "fake address" thing will be a decent defense ?
From the UI perspective, I disagree, since neither letting it read or not letting it read e-mail addresses is in any way related to playing the game.
"To automatically tell your friends about how well you're doing in this game, or to share save game points with them [...]".
Why would they think either option would effect the outcome?
Because when they click the option that doesn't give the malware what it wants, the outcome *is* affected when the little game doesn't run.
This is an obvious fallacy.
If he'd done that, we wouldn't be reading about it on Slashdot, would we ?
The People (tm) would vote for fuel subsidies and tax cuts. Just like they do every time they can.
I already "donated" several times by buying copies of Windows.
Purchase != Donation.
As it happens I also give every month to Concern Worldwide via direct debit and to put it bluntly, I would rather I was able to allocate my wealth to charities of my choosing rather than letting Gates do it for me ....
Then do that. But don't be hypocritical and criticise him for not letting you choose where your "wealth to charities" can go while simultaneously saying you should be able to dictate to him where his "wealth to charities" is apportioned.
Everything that comes with Windows is "tied to the OS". Yet no-one seems to care about all those other things.
Effectively, you are saying Microsoft cannot add new functionality to Windows. If you cannot see the fundamental flaw in that position, then there's a serious problem.
Name one other OS that does.
OS X, any Linux distribution that includes KDE and/or GNOME. I think BeOS did, although I'm not 100% on its architecture without going back and reminding myself.
You can use/remove/change the browser on Linux/Mac OS X.You might be thinking of Konqueror, which comes with KDE, but you can remove KDE and you can remove konqueror and keep the rest of KDE.
You cannot remobe WebCore/WebKit from OS X. Nor can you remove khtml and gtkhtml from KDE and GNOME, respectively. At least not without hbreaking things that use them.
They weren't a monopoly at the time they were writting their GUI/file manager and networking stack (TCP/IP might have come at the point where you could argue they were a monopoly, but I'm not sure).
That you would even consider Microsoft not being allowed to incorporate such basic functionality as a network stack and file manager, because of "monopoly" status, is ridiculous.
And those components were integrated into other OSes before MS did it. Both of which are a big deal legally.
It's quite arguable that Apple did it first with Cyberdog and co. Although both projects were created at basically the same time, so it's hard to say for sure. If you just want to talk about bundling of standalone applications (like the first two versions of IE), OS/2 did it before Windows.
However, the simple fact is Microsoft weren't the only company at the time componentising and integrating a web browser. An architecture which has since been duplicated on every major platform.
I assume you are young, or in a small company.
No.
Because in large businesses the execs sure as hell should have known about illegal tying ...
It's difficult to see why a web browser would be any different to the myriad other pieces of functionality that have moved from the purvue of 3rd party application to OS-included in the 15-odd years beforehand.
and deliberatley breaking the law isn't nearly as common as you suggest. Writting down that you intend to break the law and then doing it, even less so.
That wasn't what I was suggesting. What gets Slashdot readers upset is the language - like "killing them" is someone an uncommon phrase in management meetings and actually means something like assassination.
Right. So no product created by a company considered a monopoly can be improved if a competitor already offers that functionality in another product.
You seem to be ignoring the facts that IE was never sold and the technical aspect of a shared browser component is a perfectly valid piece of functionality for an OS to include (and has since become commonplace).
Funny how people never seem to get their knickers in a twist about Windows including a TCP/IP stack, GUI and file manager. I've never been able to figure out if they simply can't see the hypocrisy or just ignore it.
Or, simply, it would be fine if Apple execs wanted to "kill MS" and they could do a lot of things to try to make that happen (like, say, "tying" their browser to their OS) ... however MS are held to a higher legal std., because they are a _monopoly_ so for instance stopping development of MS Office for Mac OS X would probably be not so clever.
The outrage from Slashdot readers comes from the idea that managers and execs in Microsoft are saying they want to "kill" the competition. This is largely because most of them have never been anywhere near an upper-level management meeting and hence don't realise that colourful language like that is commonplace and harmless. Much like a sports coach telling his players to go out and "kill" the other team isn't speaking literally - although the average Slashdot reader would probably be unfamiliar with that scenario as well.
"Norm" is notoriously difficult to initially define and even harder to maintain over time (programmatically).
For example, how often will a user be alerted when a program wants to read their e-mail address book, or IM buddy list (excluding the app that made them)? About once per worm, with the possible false positive if a user installs a new IM client or e-mail application, in which case they will find such a request pretty normal.
If they get a request every other day from whichever worm has piggybacked itself onto an email attachment or the latest flash game, those prompts are going to be considered pretty normal, and will be ignored.
OS X has this problem. The graphical sudo prompt appears reasonably frequently and most users happily type in their password neither pause nor forethought. Why ? Because they lack both the knowledge necessary and the incentive to determine whether or not the obligatory "Are you sure" prompt is a) expected and b) reasonable. All they understand is that they need to type in their password to run that program, or complete that task.
The typical end user simply doesn't have the ability to determine whether or not $PROGRAM wanting to access their address book is reasonable - and that's an incredibly simple example. Move onto more complex things like installing software, modifying system files and inbound/outbound network connections and the picture becomes even more grim.
Did you read the examples I presented? Which button on those do you click to "make it go away?" People will have to read them or pick randomly.
Which they will. They will click on the buttons until they find the one that allows them to complete whatever higher-level task it was that triggered the dialog.
Since they should only show up in rare instances, so users will not be used to seeing them. The rarity will make them seem more important and more likely to be read.
When people are receiving and executing malware daily, those prompts will not be rare.
Most users can read English and understand the basic metaphors employed by the computer.
Maybe. But the trouble with metaphors is they're only suitable for high-level general explanations, not the low-level fine-grained decisions that need to be made for security purposes.
Any user can understand, "the program 'naked_pictures' would like to read your e-mail address book. (Stop it from reading the e-mail addresses)(Let it read them once)(Always let it read the e-mail address book)(Advanced Options)." That dialogue box, by itself, would stop most e-mail worms today and make it a difficult instead of trivial vector.
No, it won't, because people will happily let it read their address book so they can look at the naked pictures.
"After all, what harm could it do ?"
Most software should have zero.
Most software will require *at least* one dialog, during installation. Probably several, as it does things like add itself to a common user desktop, create start menu entries, insert itself into autoload lists, etc.
Assuming you're applying this on top of Windows, take a look at the mess that is Vista beta. It will certainly be fewer dialogue boxes.
I haven't been able to use Vista myself, and I'm not going to pass judgement based on a few screenshots.
Also, IE, outlook, and a dozen other programs already show warnings when you download any executable, regardless of it is violating a sandbox or not. These can be eliminated, along with dozens of other useless warnings that don't provide real options.
Not letting questionable code onto the system in the first place is an important step. It avoids both system-level exploits and bad user decisions ever happening.
Because MS has not provided incentive for developers to make their software behave. Their dev tools don't make it work by default and critical apps MS d
If you are going to prompt the user for every potentially malicious action, then you are again proposing the "dialog box storm" method.
Dialog boxes warning about security don't work. They don't work because, primarily, most people are too lazy to even bother reading them, and just click whichever buttons makes them disappear and get the desired result. The other big reason they don't work is because most people don't have sufficient knowledge to make an educated decision, and typically acquiring a sufficient level of knowledge is a non-trivial task most of them have zero interest in.
Making dialog boxes easier to read, will not make people less lazy.
Reasonable default permissions should result in fewer, not more dialogue boxes than a user is subjected to today.
Unlikely. Even the default "restricted" user has more than enough privileges to do the things 99% of malware wants to do. So existing systems need to be locked down even tighter before they can start being "secure". This is certainly going to result in more "security warnings", not less.
The only reason most malware breaks today outside of non-Admin accounts is because it's as badly written as most other Windows software.
First, users have never been given the information or the level of control needed.
Yes, they have (well, I'll agree the "control" aspect could be better, but it's far from nonexistant). Now, certainly today that knowledge isn't spoon-fed them in school, but it's definitely out there and not particularly difficult to find. Not to mention the vast majority of scams don't need any sort of specialised knowledge to identify, they are *obviously* scams. Yet people who would never even consider the actions necessary to fall victim to a scam in the "real world" regularly do so when using computers.
Personally, I blame the invention of the undo button. Everyone thinks anything they do on a computer can just be undone with the click of a button - that's it's not really real - and that nothing actually happens out in "meatspace" until some other person actually does it. I'd be willing to bet a frighteningly large proportion of people think internet banking transactions are actually printed out at the bank and processed each evening by tellers.
Until then, branding them as "lazy" or "ignorant" is absurd. A user should not need a PhD to operate an everyday tool, which is about equivalent to the level of knowledge required to actually work around all the security holes and poor design decisions of most OS's today. It is the job of the OS to give them the information and the present them with choices.
You will get no argument from me that users should not need in-depth knowledge of a computer to be able to use it.
I will, however, strongly disagree with your implication that the necessary knowledge to make reasonable decisions regarding granting arbitrary levels of access to arbitrary parts of the system can be effectively distilled into an "idiot-proof" dialog box.
Even with a PhD, it is nearly impossible so safely run an untrusted binary [...]
Note that introducing a dozen dialogs at various points of the execution process ("Do you want to let the program access this file ?" "How about this one ?" "Do you want to let the program open a network connection to $WEBSITE ?" "Do you want to allow the program to write this file ?") will not help the situation greatly. The user is not interested in reading dialog boxes, they want to play their game. They *will* take the path of least resistance (and, hence, least security) trying to achieve their goal.
Until the average user can easily and safely run random programs, we will always be at risk from trojans, since users will sacrifice security, for functionality... a choice they should never have to make.
Of course t
These two goals are fundamentally in conflict, since "malicious" cannot be objectively and programmatically defined.
I've said it before... new software on Windows should be running in a jail or sandbox or VM or something and by default should not be allowed to touch anything without the user being informed in real English and given the option to granularly deny the software, without stopping that software from running in most cases. This would solve the vast majority of Window's and IE's security problems.
No, it wouldn't. You have proposed the standard "dialog box storm" solution to security, and it doesn't work. Primarily because users are lazy, but also because they're ignorant and simply uninterested in acquiring sufficient knowledge to make educated decisions.
Asking the user "are you sure" three times is not more secure than asking them "are you sure" twice.
As long as lazy, ignorant and downright stupid end users are able to execute arbitrary code on their computers, the malware problem will not - and can not - be solved.