It's not a comparison of speed, it supposed to generally indicate how well designed the processor is.
But it doesn't indicate that at all. It just indicates that a processor is designed to achieve its performance via higher clock speeds rather than higher IPC. This is not an inherently bad thing, it's just a different design.
Back in the 90s one of the fastest processors around was the DEC Alpha. Relatively speaking, it also had a very high clock speed. Unsurprisingly, there wasn't this same bullshit about "high clock speed -> poor design" floating around then. I say unsurprisingly because at the time Apple's marketing department were busily touting "RISC technology" - RISC's primary superiority supposedly being how easy it was to improve performance by ramping up the clock speed (it's also worth pointing out at this stage that the whole design philosophy behind RISC is to do *less* work per clock and ramp the clock speed - the irony when Apple started their "Mhz Myth" campaign was thick enough to cut with a knife).
Of course, when the RISC G4s didn't deliver the clock speed improvements while the "inferior" x86 powered on towards the Ghz mark, Apple came out with that breathtakingly deceptive (but unquestionably successful) "Mhz Myth" advertising campaign, all the amateur CPU critics suddenly decided that the mark of a better CPU was its ability to do X amount of work at a relatively low clockspeed - even if the same design that made it possible resulted in actual CPU performance not improving for ~18 months because the clock speed couldn't ramp.
It's like comparing a 911 with a 300hp engine to a Mustang with a 600hp engine, both may get sub 4 0-60 times, but clearly those German engineers made a better designed automobile, and could make it even faster easier than the Mustang hackers.
Judging a car's "engineering" based solely on its 0-60 time makes about as much sense as judging a CPU's "engineering" based solely on its clock speed. There's a hulluva lot more to good vehicle engineering than beating everyone at the lights.
If the G5 ever ramps to contemporary-P4-comparable clock speeds your "better design" argument might carry some weight. Until then, it's nothing more than a regurgitation of deceptive Apple marketing. The same things that give some CPUs better performance at a given clock speed also tends to make their clock speed harder to ramp up.
There are a large number of people who haven't heard of Gmail. These are people who use the Internet to casually browse, and who check their email every other day. Hanging out in the geek community, its hard to believe people don't know their alternatives - but its true!
A lot of people in the "Geek community" seem to have forgotten GMail is still *invitation only*. Unless you know someone who can invite you it's not even an option that _can_ be considered.
To them, its a huge pain in the arse to switch addresses. Its almost unthinkable.
To anyone with an established email address it's a massive pain to change email addresses. If Google were to start charging $50pa tomorrow for access, I'd prefer to pay that rather than try and change email addresses.
The reverse though, running Mac OS X on PCs, now there's a subject they probably worry about a lot:-D
Not really. All they've got to do is make it more difficult that simply dropping an OS X CD into a PC and they'll have stopped 99% of casual users who want to try an illegitimate version of OS X.
People prepared to actually expend effort (compiling custom Darwin layers, remastering install CDs, etc) getting OS X to run on their beige box do not really represent a lost sale to Apple.
BIOS: Windows/DOS/Linux translates a lot of system calls into BIOS calls (including for translating HD sectors, interrupt handling, PCI assignments etc.
Not once they've gotten past the bootloader, they don't.
The day Microsoft releases an OSX emulation layer will be the day they've conceded defeat. It will happen.
So what motivation will developers have to create OS X-native applications when users can just run Windows applications in the OS X emulation layer ?
Exactly how has Microsoft "lost" if they're selling a compatibility layer for the same cost as Windows and everybody is still running Office, etc on OS X in the emulation layer ?
And all of that will require processing power. All of those objects have to be converted each and every time they get passed. Even the conversion to text will take cycles.
And I'm sure all the people running XP on their 150Mhz Pentium will be very concerned about that.
In case you hadn't noticed, most computers for the last 5 - 10 years have had CPU cycles to burn. Personally I consider improving the user interface to be a vastly better use for them than Seti@Home.
Add to this simple but bizarro example the poorly documented quoting/escaping voodoo required for anything more than the trivial execution of a single command [...]
The folks at Microsoft have no concept how to use the command-line, and if the wildly varying command syntax constructed from a tortured mix of spaces, slashes, dashes, colons and backslashes is any indication [...]
I hope you're not trying to suggest the Unix commandline is at all consistent, logical or intuitive ?
Worms that take over machines with no user intervention required use up more bandwidth on the internet between propagation and DoS attacks than ones that require user intervention. (At least over the last day and over the last month according to the reports I have in front of me.)
This is not relevant to what I said. I said remote takeovers are relatively rare. As in, there are far more exploits out there that require user interaction to install than those that can remotely install themselves.
The way to stop automated worms and exploits is simple, fix the vulnerabilities and make sure that fix reaches all users. The hard part is providing users with the tools and information they need to deal with an event that may be a phishing attack or may be a valid application/message/attachement/file.
Actually the hard parts are a)getting people to patch their software and b) programatically (and generically) detecting the difference between ligitimate and malicious code.
The "information" necessary to figure out whether something is legitimate or malicious is not difficult to obtain and is mostly common sense. The problem is most people simply can't be bothered acquiring the information and can't be bothering thinking about it.
That all depends upon the application. For example, if my OS were to sandbox, by default all incoming attachments on mail messages and allow them access to nothing except themselves unless the user explicitly allowed it, the vast majority of e-mail worms would fail.
It would also result in a *massive* usability hit. I doubt people are going to want to go back to the days of having to manually save things like jpegs and PDFs off to another directory somewhere just so they can have a quick look at it.
The tiny percentage of people who receive programs via e-mail and want those programs to be able to access either the internet or their files would have to deal with clicking another button. I'd say that is pretty reasonable wouldn't you?
I'd say it's identical to the situation that exists now where a dialog box pops up - defaulting to the equivalent of "No" - whenever a user tries to open a "risky" attachment. Certainly, that's been a rousing success.
So when a user downloads a game and installs it the OS should default to installing it with a given ACL and allow the user to easily change it. Select (game) (internet game) (office application) (other). The first can access only its own files, the second its own files and the internet [...]
Where do save games go ? User preferences ? How can the game taked advantage of OS capabilities like DirectX if it can't access anything except its own files ?
[...] , the third your documents, its own files but not the internet, and the last you'd have to specify.
Which brings us to the main problem. Users don't know WTF they're doing *NOW*. How do you think they're going to deal with having to make more decisions when neither the request itself nor the ramifications are within their understanding ?
Your system still relies on ignorant users becoming less ignorant to work. Therefore, it is no different to existing systems and will not change anything.
What it needed were the options (open and run macros) and (open but don't let it fuck up anything on my system). I know people who would gladly have paid thousands of dollars for such an option.
How is the software supposed to know what "don't fuck up my system" encompasses ?
That is a big, big problem. There needs to be a third, sane option.
If you can a) define that option, b) come up with some algorithms to make it work and c) come up with a user friendly, intuive interface to make it usable, you'll be a rich man.
This is _not_ an easy problem to solve. Indeed, I'd nearly go so far as to make it impossible. To give an application the ability to legitimately access and/or modify your data, you must also give it t
Then how, exactly, does spyware make its way onto my machine with IE installed on it?
Same way it would if it exploited a Firefox vulnerability.
"No greater ability" my shiny metal ass.
IE runs in user space just like Firefox. If you're not running as an Admin, most (if not all) malware crashes and burns. If you are running as an Admin, running firefox won't help you if a similar vulnerability exists in Firefox.
IE does not have magical powers. It does not have mysterious hooks into the NT kernel. It does not run with special permissions. It has no more (or less) ability to damage your system than Firefox does.
But the problem is, nothing in the arquitecture of how the drivers works has change, as long as I see in the changelog, so why should that driver not work?
Because unlike every other remotely mainstream OS out there, Linux makes no attempt to preserve binary compatibility across kernel releases.
Indeed it did, however, IE's major boom time was the ~12 months *before* Windows 98 was released, when IE4 was only available for download. This was the real bloodbath for Navigator, when their marketshare dropped from something like 90%+ to less than 50%. Going back a bit further, IE's marketshare was basically nonexistant until IE3 was released, when it captured about 10% of the market off Navigator, without being bundled with Windows.
If you ask people why they have used and still use IE, I'm sure that the vast majority of people will say that "it came with the operating system", not that it was better or worse.
Which might work except during the biggest period of IE's growth, the relevant versions (3.x and 4.x) weren't actually bundled with Windows - they had to be downloaded separately.
Some of this blame has to go to MS for making an operating system on which not even the administrator can delete a file. It seems like windows presumes that even it's administrators can't be trusted fully.
No, it's simply the result of a more capable permissions system.
Re:Can We Get Firefox Developers To Do This, Too?
on
Hackers, Meet Microsoft
·
· Score: 2, Insightful
Firefox is not comparable because firefox is not a component of the OS. It is not, as is IE, an application front end, but a standard stand alone web browser. The critical nature of firefox bugs cannot reach that of IE becuase they are not, by definition, OS level faults.
IE has no greater ability to do damage to the system than Firefox does.
It would not supprise me to see Microsoft doing a Apple after Longhorn of creating a new Windows OS from scratch and praying that LH will hold untill it comes out.
Apple didn't create a new OS from scratch, they bought an existing one - NeXT (although many will argue Apple bought Steve Jobs and NeXT was a nice bonus).
Moreover, since NeXT was actually released for the first time way back in 1989, OS X's codebase is actually around 4 years *older* than Windows NT's.
Apple didd this when small and surivived. And MS can do it now but cant pospone much longer.
Microsoft will not create another from-scratch OS in the forseeable future. There is simply no need. Technically and architecturally NT is just as good as any of its contemporaries. 99% of problems in Windows come from legacy support (being phased out with.NET, x86-86 also providing a convenient excuse) and less than ideal default settings (hopefully on the way out with LH).
[...] but at that same time most computers should be much, much, much, much, much harder to remotely take over and turn into a zombie.
No, the problem isn't *remote takeovers* - they're quite rare (relatively speaking). The problem is users deliberately (albeit usually in ignorance) installing software locally.
I agree that there will always be really stupid users that will get their machines taken over and agree to the most ridiculous risks to see the little bunny cartoon, but at least make the user click a button that says "Let this program do anything it wants to my computer" right next to the "run it in a sandbox and give it no access to the internet or my files" button.
How useful do you think a piece of software is going to be if it can neither access data on the local machine nor make network connections ?
Security and usability are inversely proportioned. Increase one and you reduce the other.
Indeed, but will Microsoft still have a monopoly for "desktop operating systems for x86 processors" once the Intel Macs are released?;-) I could see Microsoft asking for the monopoly ruling to be reversed (I think that Windows' monopoly status is scheduled to be re-reviewed every so often anyway).
Personally, I think the court - unlike the industry - not considering MacOS a competitor/alternative to Windows in the first place was ridiculous (and the main reason I disagree with the monopoly ruling).
Slashdot Mirror
But it doesn't indicate that at all. It just indicates that a processor is designed to achieve its performance via higher clock speeds rather than higher IPC. This is not an inherently bad thing, it's just a different design.
Back in the 90s one of the fastest processors around was the DEC Alpha. Relatively speaking, it also had a very high clock speed. Unsurprisingly, there wasn't this same bullshit about "high clock speed -> poor design" floating around then. I say unsurprisingly because at the time Apple's marketing department were busily touting "RISC technology" - RISC's primary superiority supposedly being how easy it was to improve performance by ramping up the clock speed (it's also worth pointing out at this stage that the whole design philosophy behind RISC is to do *less* work per clock and ramp the clock speed - the irony when Apple started their "Mhz Myth" campaign was thick enough to cut with a knife).
Of course, when the RISC G4s didn't deliver the clock speed improvements while the "inferior" x86 powered on towards the Ghz mark, Apple came out with that breathtakingly deceptive (but unquestionably successful) "Mhz Myth" advertising campaign, all the amateur CPU critics suddenly decided that the mark of a better CPU was its ability to do X amount of work at a relatively low clockspeed - even if the same design that made it possible resulted in actual CPU performance not improving for ~18 months because the clock speed couldn't ramp.
It's like comparing a 911 with a 300hp engine to a Mustang with a 600hp engine, both may get sub 4 0-60 times, but clearly those German engineers made a better designed automobile, and could make it even faster easier than the Mustang hackers.
Judging a car's "engineering" based solely on its 0-60 time makes about as much sense as judging a CPU's "engineering" based solely on its clock speed. There's a hulluva lot more to good vehicle engineering than beating everyone at the lights.
If the G5 ever ramps to contemporary-P4-comparable clock speeds your "better design" argument might carry some weight. Until then, it's nothing more than a regurgitation of deceptive Apple marketing. The same things that give some CPUs better performance at a given clock speed also tends to make their clock speed harder to ramp up.
A lot of people in the "Geek community" seem to have forgotten GMail is still *invitation only*. Unless you know someone who can invite you it's not even an option that _can_ be considered.
To them, its a huge pain in the arse to switch addresses. Its almost unthinkable.
To anyone with an established email address it's a massive pain to change email addresses. If Google were to start charging $50pa tomorrow for access, I'd prefer to pay that rather than try and change email addresses.
No, it's FUD.
Not really. All they've got to do is make it more difficult that simply dropping an OS X CD into a PC and they'll have stopped 99% of casual users who want to try an illegitimate version of OS X.
People prepared to actually expend effort (compiling custom Darwin layers, remastering install CDs, etc) getting OS X to run on their beige box do not really represent a lost sale to Apple.
Ironic you should use such an example when OS X is so bloody slow.
Not once they've gotten past the bootloader, they don't.
Why would you compare "clock for clock" ? That's about as relevant as comparing "bogoMIP for bogoMIP".
So what motivation will developers have to create OS X-native applications when users can just run Windows applications in the OS X emulation layer ?
Exactly how has Microsoft "lost" if they're selling a compatibility layer for the same cost as Windows and everybody is still running Office, etc on OS X in the emulation layer ?
OS X is _not_ "fast".
And I'm sure all the people running XP on their 150Mhz Pentium will be very concerned about that.
In case you hadn't noticed, most computers for the last 5 - 10 years have had CPU cycles to burn. Personally I consider improving the user interface to be a vastly better use for them than Seti@Home.
The folks at Microsoft have no concept how to use the command-line, and if the wildly varying command syntax constructed from a tortured mix of spaces, slashes, dashes, colons and backslashes is any indication [...]
I hope you're not trying to suggest the Unix commandline is at all consistent, logical or intuitive ?
This is not relevant to what I said. I said remote takeovers are relatively rare. As in, there are far more exploits out there that require user interaction to install than those that can remotely install themselves.
The way to stop automated worms and exploits is simple, fix the vulnerabilities and make sure that fix reaches all users. The hard part is providing users with the tools and information they need to deal with an event that may be a phishing attack or may be a valid application/message/attachement/file.
Actually the hard parts are a)getting people to patch their software and b) programatically (and generically) detecting the difference between ligitimate and malicious code.
The "information" necessary to figure out whether something is legitimate or malicious is not difficult to obtain and is mostly common sense. The problem is most people simply can't be bothered acquiring the information and can't be bothering thinking about it.
That all depends upon the application. For example, if my OS were to sandbox, by default all incoming attachments on mail messages and allow them access to nothing except themselves unless the user explicitly allowed it, the vast majority of e-mail worms would fail.
It would also result in a *massive* usability hit. I doubt people are going to want to go back to the days of having to manually save things like jpegs and PDFs off to another directory somewhere just so they can have a quick look at it.
The tiny percentage of people who receive programs via e-mail and want those programs to be able to access either the internet or their files would have to deal with clicking another button. I'd say that is pretty reasonable wouldn't you?
I'd say it's identical to the situation that exists now where a dialog box pops up - defaulting to the equivalent of "No" - whenever a user tries to open a "risky" attachment. Certainly, that's been a rousing success.
So when a user downloads a game and installs it the OS should default to installing it with a given ACL and allow the user to easily change it. Select (game) (internet game) (office application) (other). The first can access only its own files, the second its own files and the internet [...]
Where do save games go ? User preferences ? How can the game taked advantage of OS capabilities like DirectX if it can't access anything except its own files ?
[...] , the third your documents, its own files but not the internet, and the last you'd have to specify.
Which brings us to the main problem. Users don't know WTF they're doing *NOW*. How do you think they're going to deal with having to make more decisions when neither the request itself nor the ramifications are within their understanding ?
Your system still relies on ignorant users becoming less ignorant to work. Therefore, it is no different to existing systems and will not change anything.
What it needed were the options (open and run macros) and (open but don't let it fuck up anything on my system). I know people who would gladly have paid thousands of dollars for such an option.
How is the software supposed to know what "don't fuck up my system" encompasses ?
That is a big, big problem. There needs to be a third, sane option.
If you can a) define that option, b) come up with some algorithms to make it work and c) come up with a user friendly, intuive interface to make it usable, you'll be a rich man.
This is _not_ an easy problem to solve. Indeed, I'd nearly go so far as to make it impossible. To give an application the ability to legitimately access and/or modify your data, you must also give it t
Same way it would if it exploited a Firefox vulnerability.
"No greater ability" my shiny metal ass.
IE runs in user space just like Firefox. If you're not running as an Admin, most (if not all) malware crashes and burns. If you are running as an Admin, running firefox won't help you if a similar vulnerability exists in Firefox.
IE does not have magical powers. It does not have mysterious hooks into the NT kernel. It does not run with special permissions. It has no more (or less) ability to damage your system than Firefox does.
Because unlike every other remotely mainstream OS out there, Linux makes no attempt to preserve binary compatibility across kernel releases.
No, that's $670,000 _once_. You don't have to "renew" Exchange CALs yearly.
Indeed it did, however, IE's major boom time was the ~12 months *before* Windows 98 was released, when IE4 was only available for download. This was the real bloodbath for Navigator, when their marketshare dropped from something like 90%+ to less than 50%. Going back a bit further, IE's marketshare was basically nonexistant until IE3 was released, when it captured about 10% of the market off Navigator, without being bundled with Windows.
Not when I'm responding to this:
And not whatever you thought I was responding to.
That's lousy my friend. That's a bug. So tell me what wonderful permission is preventing me from deleting this directory?
You are describing an entirely different scenario to the one I was responding to. Check your aim next time, before you fire.
Which might work except during the biggest period of IE's growth, the relevant versions (3.x and 4.x) weren't actually bundled with Windows - they had to be downloaded separately.
What is this "invisible value" you speak of ?
No, it's simply the result of a more capable permissions system.
IE has no greater ability to do damage to the system than Firefox does.
Apple didn't create a new OS from scratch, they bought an existing one - NeXT (although many will argue Apple bought Steve Jobs and NeXT was a nice bonus).
Moreover, since NeXT was actually released for the first time way back in 1989, OS X's codebase is actually around 4 years *older* than Windows NT's.
Apple didd this when small and surivived. And MS can do it now but cant pospone much longer.
Microsoft will not create another from-scratch OS in the forseeable future. There is simply no need. Technically and architecturally NT is just as good as any of its contemporaries. 99% of problems in Windows come from legacy support (being phased out with .NET, x86-86 also providing a convenient excuse) and less than ideal default settings (hopefully on the way out with LH).
No, the problem isn't *remote takeovers* - they're quite rare (relatively speaking). The problem is users deliberately (albeit usually in ignorance) installing software locally.
I agree that there will always be really stupid users that will get their machines taken over and agree to the most ridiculous risks to see the little bunny cartoon, but at least make the user click a button that says "Let this program do anything it wants to my computer" right next to the "run it in a sandbox and give it no access to the internet or my files" button.
How useful do you think a piece of software is going to be if it can neither access data on the local machine nor make network connections ?
Security and usability are inversely proportioned. Increase one and you reduce the other.
Because - unlike OS X - no-one wants to buy a machine with Linux on it.
Personally, I think the court - unlike the industry - not considering MacOS a competitor/alternative to Windows in the first place was ridiculous (and the main reason I disagree with the monopoly ruling).