As for how long you think a malicious ad doing *anything* on a major network would survive, let's just say "not long".
It doesn't have to be long, that's the trick. This isn't a theoretical problem, it has actually happened multiple times with previous browser based exploits. One ad-based attack is estimated to have zombied over a million machines in the span of hours it was live for. This makes sense - ad networks serve millions of impressions per hour, and it can easily take several hours for them to respond and pull an ad, especially if it goes live in the middle of the night (or worse, the ad is designed to behave itself when loaded into the ad networks IP address range - I believe this has also happened).
In sum, the reason why this is interesting is because of the ubiquitousness of the Apple iSight on Apple laptops and the fact that it's ready for use. But, someone still has to visit a malicious site and run a malicious Java applet - user interaction: the hallmark of Mac OS X vulnerabilities!
Look, I know you like Macs, like Apple etc. It's a running theme whenever I see your posts. However, it's perfectly feasable to (say) buy a Flash advert slot on a widely used network then have the Flash movie inject an invisible java applet into the page using its DOM integration (if you even want to get that fancy). Java applets are designed to be loaded and run automatically, that's why they have this secure sandbox model that Apple went and violated in the classic fashion of integrating all its OS components with the web browser. If a Java applet can record what your camera sees that is a HUGE deal. It cannot simply be blown off like that!
Was it click-fraud or was it a poorly optimised site?
I'm not saying you're wrong, it might well have been a click fraud problem, but lots of people clicking through then leaving is not an uncommon problem for any advertising, not just on Googles network. People are impatient and busy, they have many things to do, which is why Google now focusses on landing page quality as an interesting thing to measure. Really improving the landing page for an advert can make a dramatic difference to the conversion rate. Google has lots of people who manage accounts and spend all day helping advertisers with this, it might be worth trying again with a small budget and contacting your AdWords rep to see if the conversion rate can be improved.
Of course if your adverts were converting really well from every site except this small handful, then it's a lot more suspicous. In that case as pointed out, you can block those sites.
It is far cheaper to buy a dedicated Mac with the Mac shake than buy the Linux version. It's equivalent to killing it completely. Apple are really no better than Microsoft when it comes to this stuff, so I suppose you could say I "hate" both equally (though I use both their products from time to time).
I would say a total inability to support out-of-tree drivers is a "fundamental design issue", wouldn't you? It does rather imply you can't release a piece of hardware and have people be able to use it on the same day. And who wants to buy hardware they won't be able to use for a year?
A register spec that says "Write the location of a compiled vertex shader to REGISTER_1234" is pretty useless, in my opinion. What does that block of memory contain? How do you create one yourself? This is where the going gets tough.
I'm afraid the days of drivers being programs that tweaked registers is long gone, my friend. Some of them include advanced optimizing compilers. There's a reason the nvidia driver is nearly the same size as the kernel itself - it's an extremely complex piece of code, with many clever things being done in software.
Yes, some apps preserve state but that's a per-app feature and not supported or tied into the operating system or UI. As far as Windows is concerned, there are applications and documents, and if an application happens to "remember" that it was last working on XYZ document that's nice but not anything it gets involved with. Tying them together is pretty central to the whole presence/collaboration work they have going on there - people share "activities" rather than apps or documents, and the details are sorted out in the background.
You are right that this isn't anything amazingly revolutionary. It's a nice cleanup from where we are today but people have been trying to head in that direction for a long time. Still there are plenty of other things about it that are more interesting.
I think you're reading too much into it. As far as I can tell, an "activity" is just a fusion of application+document. It means you don't have weird states like an application that's running but can't be used because it has no document loaded, or a document you can't open because you don't have the application. That's it. It's one of the less revolutionary things about Sugar, in fact, so I don't know why it was picked for the summary.
You can't permenantly brick the OLPC laptops, they are designed to have a hard reset function that wipes the system and restores it from the original image. The idea is you can play around with your hearts content but it's trivial to undo the damage if you do somehow temporarily brick it.
I made that (throwaway) comment because I had recently written about a few parts of the Mac GUI that annoyed me, and because the Mac is usually touted as being innovative in the UI space. I disagree, I don't think it's all that innovative compared to the OLPC, hence the comparison. Of course, the one sentence that mentioned the Mac got picked for the Slashdot front page and now the article itself is Slashdotted, nobody will read the full thing. C'est la vie;)
There are at least two reasons why GoogleBot isn't written in Python. Firstly it's a very large and complex piece of code. Anecdotally, for very large codebases a statically typed language like C++ seems to work better with respect to allowing many developers to work together, because it requires and allows you to specify interfaces in a checkable way. Secondly it's performance sensitive. Your suggestion of continuous/adaptive compilation doesn't work because the resources that are used to redundantly compile/optimise a program "in flight" many times for each machine/run of the program could be better used to, say, crawl the web. Generally, it's much more efficient to compile something once on a developers machine and let the compiler ponder the program as a whole, then upload the finished result to the machines.
What if your idea is one that would generate revenue other than by advertising?
That's fine. I'm working on something that doesn't make money via advertising. But advertising is effective enough and well established enough that if you can fund it that way, it's encouraged.
Would Google still back it?..and if they did and it was wildly successful revenue-generating wise would they setup some kind of profit sharing for you or would you just get a bonus and get back to work?
It would be backed, subject to the usual conditions of any other project. Profit sharing? I doubt it. I never heard of that. You are standing on the shoulders of giants, and many... many... people will be involved with the project by the time it goes live. Ideas are ironically both insanely valuable and insanely cheap - the right one can be worth millions, but everyone has millions. Execution is every bit as important. But who knows? The rules aren't set in stone.
I guess it all depends on those financial rewards you speak of.. and ultimately that comes down to the execs deciding how large a bone to toss you, right? From my personal experience - the people tossing the bone will always undervalue your contribution, and I don't mean 60/40 it's more like 95/5.
Depends on your ideas of wealth. This story gives a figure of $12 million. I didn't mention it before because I wasn't sure if it was public or not, but apparently it is so there you go. That may or may not sound like much, but notice the projects which were awarded didn't necessary make tons of money. They were just seen as important. Ultimately, Larry and Sergey are pretty fair and really want to reward innovation. If you invent the next AdWords I suspect they'll make sure you do OK. Look at it from their perspective - it's in their interests to have smart people effectively "rent" their business, as it means they not only take some kind of commission off the top but also get all the usual benefits of having good people work at your company.
Re:Complexity can be hidden, but there are costs.
on
The Case for OpenID
·
· Score: 1
Yes, I understand those things. And implementing user@host on top of a fixed mapping to http://host/openid/user or something would be fine. My point is one of usability - people understand and work with email addresses to represent a logical identity all the time. Why confuse the matter now simply for the sake of removing 5 lines from the spec?
I, for some reason (probably related to how horrible I find things like JSP), do not like web development at all (with the exception of web services that my good old fashioned thin/fat client can consume) when compared to C/C++, but that's just me.
You are not alone. I'm the same. Fortunately for you, many high profile "web apps" are in fact written in C++. Did you really think the Google search engine is written in PHP? Preferring C++ style coding should not put you off applying.
Google Earth is slightly interesting, but to be honest, it's a simple software problem just backed up by the enormous hardware capabilities of Google for serving. It still doesn't do much at all, it's just that nobody else does it really, not for free.
I work on Google Earth and I can assure you, while it's "simple" relative to, say, web search, there is far more magic going on behind the scenes than you probably realise. It's anything but a boring team to be on. Especially, the nice thing about Google Earth is people have a very emotional response to it... there are all kinds of human stories around what people do with it... which you will never get with some corp database product.
Yes, I think 20% time is pivotal here. I don't think the articles hypothesis is going to be a problem. 6 months ago I was thinking of forming my own company. Yesterday I was talking to an interview candidate about why he should come work for us instead of setting up his own business. The simplest thing was to tell the truth, to tell what I thought in his boots 6 months ago, so that's what I did.
Essentially, if you are thinking of forming your own company to write software, you need to weigh up the trade. If you work for Google then it's quite likely - assuming your idea is not totally stupid - you can work on it in 20% time. Not just for web apps either, but for pretty much the whole spectrum of software development. If you do this, you don't own your idea and you can't work on it full time. BUT you trade those downsides against the upsides:
You have access to the Google infrastructure and can build your program upon it. For me, this was a huge thing, because if my idea eventually takes off I want it to scale and I want it to have exposure to a large market. Solving scalability is not an easy thing. Look at how many companies suffered crippling scalability issues and either tanked or nearly tanked (Friendster springs to mind). I already knew Googles tech was impressive before I came here, because we have techtalks about it on Google Video and have published papers etc, but there are plenty of amazing technological nuggets we don't talk about. Time spent re-solving these (superhard) problems is time spent not implementing my idea.
You have the advantage of formal process and peer review from people who know what they're doing. Some people say Google is full of smart people. I think "smart" is too vague a word. Jeff Dean is smart, I'm not all that smart. I couldn't have invented MapReduce, and I'll probably not invent the best way to implement my idea. But if I want Jeffs thoughts, all I have to do is email him. Or Rob Pikes. Or Ken Thompsons. Or Vint Cerfs. That combining the brainpower of the organisation is smart and it's only possible when you have a very open internal culture like Google has.
There are, in fact, financial rewards available to people who make a significant contribution to the company (say by launching a wildly succesful new product). As big as founding your own company? Depends.... you won't be the next Bill Gates, but most startups don't make their founders billionaires anyway.
You personally shoulder much less of the risk.
From a rational perspective, for me it made sense to join the big G and work at my idea in my 20% time and spare time. That's because for this specific project I want to see it be built and deployed well more badly than I want to get rich (because I feel it will be strongly needed in future). Maybe if I was writing some AJAX wiki web 3 mashup or whatever I'd care more about getting rich and it'd make more sense to go it alone. Depends on your goals.
Anyway, it's sort of become fashionable lately to say Google isn't innovative anymore, or something like that, but I'm not seeing that on the inside. I'm seeing lots of innovation. Not all of it turns into a successful product of course, but that's true of business in general no matter what you do.
So. I say to you - if you are thinking of writing the next amazing killer app on your own, seriously, consider doing it with us. If you don't trust me on this, go read Joel Spolskis opinion on the same thing. Setting up a business is a lot of work and there are many ways to get it wrong. But whatever you do, make sure you enjoy doing it. That's the most important thing, I think.
Re:Complexity can be hidden, but there are costs.
on
The Case for OpenID
·
· Score: 1
That's the theory and it'd be nice if OpenID actually followed it. Unfortunately despite its many virtues the OpenID folks persist in thinking that URLs are a sensible way to identify people, because the guy who created it has spent too much time in the "blogosphere". People struggle with email addresses at times, do you really think they're going to be happy if you give them a username like http://some.name.some.provider/ or http://open.someprovider.com/somename - not only is that a hell of a lot to type, but it looks like a web site address, even though it is actually not.
This issue has been raised time and time again with them and no satisfactory answer has ever been forthcoming as to why they don't just put a standardised mangling layer on top of URLs to make it more familiar to people. The guy who founded the project just says "no, stfu" and that's the end of it. It doesn't give me a whole lot of confidence in the project, to be quite frank.
What makes you think they haven't been hacked? I've seen some quite impressive hacks of MacOS X including a very trivial piece of code that dumps every encrypted form submission from Safari (by sucking it out of the app before encrypted). When people say "my Macs don't get hacked" they mean "they don't get automatically hacked on a large detectable scale". That's completely different to "there is no exploit code out there", which is what you are implying.
The problem is that the typesafe languages are not realistic for writing desktop software in. Both Java and.NET are plagued with serious technical problems - which is why so few desktop apps are written using them. Even trivial optimisations like stack allocation cannot be done by the programmer in these languages, they take advanced analyses running inside complex optimizing compilers.... running on the users desktop.
Basically, you are right that using these languages would eliminate whole classes of vulnerabilities. But they would not eliminate all of them, and the costs are huge in terms of writing efficient, pleasant-to-use software. Stuff written in Java today is just uncompetitive, secure or not.
The problem is old versions of Windows had open ports. You don't need a VM to fix that, just close those open ports (which is what a firewall does, essentially). New versions don't have open ports, but to get an old version to be a new version, you have to download the update (or simply enable the firewall yourself - hardly rocket science). So not "too simple", just "too complicated".
The underlying problem at the system level (ie, not coutnting phishing, physical security problems, etc) is WINDOWS, period.
No. Just no.
I hate this sort of comparison, because it's bogus. It's a classic apples and oranges situation. You are comparing the security of Apache to IIS, not Linux to Windows. Modern versions of IIS are pretty good from what I hear, and besides it's not very hard to be secure when all you run is a firewall and a web server.
If you want to do a real comparison you should compare the Linux desktop to the Windows desktop. Your average Linux desktop is a security nightmare. Firstly there's no active security whatsoever, it's all passive. IE there are no virus scanners/anti-malware tools in common deployment. If the passive defences fail you are screwed, you cannot easily distribute signatures etc to clean up the mess. Secondly, the Linux security model is simply the UNIX security model, which was designed in the 70s for a totally different set of threats. Your average desktop is not a mainframe and does not need to protect users from one another - instead it's decayed into some kind of trivial black/white coarse grained security model in which "root" has absolute power and "users" have less power.
Unfortunately, Linux trains the user to enter their password all the time, given an essentially random set of situations. You have to enter your password to install software, remove software, configure hardware, set the system clock and worst of all to install security updates. The tasks that require root are to the average user totally unconnected. If you are a UNIX geek you can probably figure out why something might need root, but you're in the minority. So users are trained to just enter their password whenever they are asked to, making it trivial to phish it out of them.
Even if you can't get root - who cares? On a modern Linux desktop you can do anything you need without it. Want to crack bank details? Go right ahead, Firefox runs as user and you can ptrace() it to your hearts content. Want to hook into startup so you always run? KDE and GNOME will be happy to oblige. Want to "hide" yourself without modifying the kernel? No problem either, just inject yourself into the address space of each program as it starts and then hook the syscalls at the libc level. Childs play.
So to put it simply - you are dead wrong. The underlying problem at the system level is the system, which is basically the same regardless of whether you use Windows, MacOS or Linux. The UNIX/NT security model is incapable of solving the problem of malicious software, period.
Slashdot Mirror
It doesn't have to be long, that's the trick. This isn't a theoretical problem, it has actually happened multiple times with previous browser based exploits. One ad-based attack is estimated to have zombied over a million machines in the span of hours it was live for. This makes sense - ad networks serve millions of impressions per hour, and it can easily take several hours for them to respond and pull an ad, especially if it goes live in the middle of the night (or worse, the ad is designed to behave itself when loaded into the ad networks IP address range - I believe this has also happened).
See here for more details
Look, I know you like Macs, like Apple etc. It's a running theme whenever I see your posts. However, it's perfectly feasable to (say) buy a Flash advert slot on a widely used network then have the Flash movie inject an invisible java applet into the page using its DOM integration (if you even want to get that fancy). Java applets are designed to be loaded and run automatically, that's why they have this secure sandbox model that Apple went and violated in the classic fashion of integrating all its OS components with the web browser. If a Java applet can record what your camera sees that is a HUGE deal. It cannot simply be blown off like that!
Was it click-fraud or was it a poorly optimised site?
I'm not saying you're wrong, it might well have been a click fraud problem, but lots of people clicking through then leaving is not an uncommon problem for any advertising, not just on Googles network. People are impatient and busy, they have many things to do, which is why Google now focusses on landing page quality as an interesting thing to measure. Really improving the landing page for an advert can make a dramatic difference to the conversion rate. Google has lots of people who manage accounts and spend all day helping advertisers with this, it might be worth trying again with a small budget and contacting your AdWords rep to see if the conversion rate can be improved.
Of course if your adverts were converting really well from every site except this small handful, then it's a lot more suspicous. In that case as pointed out, you can block those sites.
... not to mention "economic boom"
It is far cheaper to buy a dedicated Mac with the Mac shake than buy the Linux version. It's equivalent to killing it completely. Apple are really no better than Microsoft when it comes to this stuff, so I suppose you could say I "hate" both equally (though I use both their products from time to time).
I would say a total inability to support out-of-tree drivers is a "fundamental design issue", wouldn't you? It does rather imply you can't release a piece of hardware and have people be able to use it on the same day. And who wants to buy hardware they won't be able to use for a year?
A register spec that says "Write the location of a compiled vertex shader to REGISTER_1234" is pretty useless, in my opinion. What does that block of memory contain? How do you create one yourself? This is where the going gets tough.
I'm afraid the days of drivers being programs that tweaked registers is long gone, my friend. Some of them include advanced optimizing compilers. There's a reason the nvidia driver is nearly the same size as the kernel itself - it's an extremely complex piece of code, with many clever things being done in software.
Real would disagree
Yes, some apps preserve state but that's a per-app feature and not supported or tied into the operating system or UI. As far as Windows is concerned, there are applications and documents, and if an application happens to "remember" that it was last working on XYZ document that's nice but not anything it gets involved with. Tying them together is pretty central to the whole presence/collaboration work they have going on there - people share "activities" rather than apps or documents, and the details are sorted out in the background.
You are right that this isn't anything amazingly revolutionary. It's a nice cleanup from where we are today but people have been trying to head in that direction for a long time. Still there are plenty of other things about it that are more interesting.
By the way, to whoever is modding every post I make down, go get a life.
I saw a demo of Sugar running on an actual laptop only last Thursday. It exists, therefore, it cannot be vapourware.
I think you're reading too much into it. As far as I can tell, an "activity" is just a fusion of application+document. It means you don't have weird states like an application that's running but can't be used because it has no document loaded, or a document you can't open because you don't have the application. That's it. It's one of the less revolutionary things about Sugar, in fact, so I don't know why it was picked for the summary.
You can't permenantly brick the OLPC laptops, they are designed to have a hard reset function that wipes the system and restores it from the original image. The idea is you can play around with your hearts content but it's trivial to undo the damage if you do somehow temporarily brick it.
I made that (throwaway) comment because I had recently written about a few parts of the Mac GUI that annoyed me, and because the Mac is usually touted as being innovative in the UI space. I disagree, I don't think it's all that innovative compared to the OLPC, hence the comparison. Of course, the one sentence that mentioned the Mac got picked for the Slashdot front page and now the article itself is Slashdotted, nobody will read the full thing. C'est la vie ;)
There are at least two reasons why GoogleBot isn't written in Python. Firstly it's a very large and complex piece of code. Anecdotally, for very large codebases a statically typed language like C++ seems to work better with respect to allowing many developers to work together, because it requires and allows you to specify interfaces in a checkable way. Secondly it's performance sensitive. Your suggestion of continuous/adaptive compilation doesn't work because the resources that are used to redundantly compile/optimise a program "in flight" many times for each machine/run of the program could be better used to, say, crawl the web. Generally, it's much more efficient to compile something once on a developers machine and let the compiler ponder the program as a whole, then upload the finished result to the machines.
That's fine. I'm working on something that doesn't make money via advertising. But advertising is effective enough and well established enough that if you can fund it that way, it's encouraged.
It would be backed, subject to the usual conditions of any other project. Profit sharing? I doubt it. I never heard of that. You are standing on the shoulders of giants, and many ... many ... people will be involved with the project by the time it goes live. Ideas are ironically both insanely valuable and insanely cheap - the right one can be worth millions, but everyone has millions. Execution is every bit as important. But who knows? The rules aren't set in stone.
Depends on your ideas of wealth. This story gives a figure of $12 million. I didn't mention it before because I wasn't sure if it was public or not, but apparently it is so there you go. That may or may not sound like much, but notice the projects which were awarded didn't necessary make tons of money. They were just seen as important. Ultimately, Larry and Sergey are pretty fair and really want to reward innovation. If you invent the next AdWords I suspect they'll make sure you do OK. Look at it from their perspective - it's in their interests to have smart people effectively "rent" their business, as it means they not only take some kind of commission off the top but also get all the usual benefits of having good people work at your company.
Yes, I understand those things. And implementing user@host on top of a fixed mapping to http://host/openid/user or something would be fine. My point is one of usability - people understand and work with email addresses to represent a logical identity all the time. Why confuse the matter now simply for the sake of removing 5 lines from the spec?
You are not alone. I'm the same. Fortunately for you, many high profile "web apps" are in fact written in C++. Did you really think the Google search engine is written in PHP? Preferring C++ style coding should not put you off applying.
I work on Google Earth and I can assure you, while it's "simple" relative to, say, web search, there is far more magic going on behind the scenes than you probably realise. It's anything but a boring team to be on. Especially, the nice thing about Google Earth is people have a very emotional response to it ... there are all kinds of human stories around what people do with it ... which you will never get with some corp database product.
Yes, I think 20% time is pivotal here. I don't think the articles hypothesis is going to be a problem. 6 months ago I was thinking of forming my own company. Yesterday I was talking to an interview candidate about why he should come work for us instead of setting up his own business. The simplest thing was to tell the truth, to tell what I thought in his boots 6 months ago, so that's what I did.
Essentially, if you are thinking of forming your own company to write software, you need to weigh up the trade. If you work for Google then it's quite likely - assuming your idea is not totally stupid - you can work on it in 20% time. Not just for web apps either, but for pretty much the whole spectrum of software development. If you do this, you don't own your idea and you can't work on it full time. BUT you trade those downsides against the upsides:
From a rational perspective, for me it made sense to join the big G and work at my idea in my 20% time and spare time. That's because for this specific project I want to see it be built and deployed well more badly than I want to get rich (because I feel it will be strongly needed in future). Maybe if I was writing some AJAX wiki web 3 mashup or whatever I'd care more about getting rich and it'd make more sense to go it alone. Depends on your goals.
Anyway, it's sort of become fashionable lately to say Google isn't innovative anymore, or something like that, but I'm not seeing that on the inside. I'm seeing lots of innovation. Not all of it turns into a successful product of course, but that's true of business in general no matter what you do.
So. I say to you - if you are thinking of writing the next amazing killer app on your own, seriously, consider doing it with us. If you don't trust me on this, go read Joel Spolskis opinion on the same thing. Setting up a business is a lot of work and there are many ways to get it wrong. But whatever you do, make sure you enjoy doing it. That's the most important thing, I think.
That's the theory and it'd be nice if OpenID actually followed it. Unfortunately despite its many virtues the OpenID folks persist in thinking that URLs are a sensible way to identify people, because the guy who created it has spent too much time in the "blogosphere". People struggle with email addresses at times, do you really think they're going to be happy if you give them a username like http://some.name.some.provider/ or http://open.someprovider.com/somename - not only is that a hell of a lot to type, but it looks like a web site address, even though it is actually not.
This issue has been raised time and time again with them and no satisfactory answer has ever been forthcoming as to why they don't just put a standardised mangling layer on top of URLs to make it more familiar to people. The guy who founded the project just says "no, stfu" and that's the end of it. It doesn't give me a whole lot of confidence in the project, to be quite frank.
What makes you think they haven't been hacked? I've seen some quite impressive hacks of MacOS X including a very trivial piece of code that dumps every encrypted form submission from Safari (by sucking it out of the app before encrypted). When people say "my Macs don't get hacked" they mean "they don't get automatically hacked on a large detectable scale". That's completely different to "there is no exploit code out there", which is what you are implying.
The problem is that the typesafe languages are not realistic for writing desktop software in. Both Java and .NET are plagued with serious technical problems - which is why so few desktop apps are written using them. Even trivial optimisations like stack allocation cannot be done by the programmer in these languages, they take advanced analyses running inside complex optimizing compilers .... running on the users desktop.
Basically, you are right that using these languages would eliminate whole classes of vulnerabilities. But they would not eliminate all of them, and the costs are huge in terms of writing efficient, pleasant-to-use software. Stuff written in Java today is just uncompetitive, secure or not.
The problem is old versions of Windows had open ports. You don't need a VM to fix that, just close those open ports (which is what a firewall does, essentially). New versions don't have open ports, but to get an old version to be a new version, you have to download the update (or simply enable the firewall yourself - hardly rocket science). So not "too simple", just "too complicated".
No. Just no.
I hate this sort of comparison, because it's bogus. It's a classic apples and oranges situation. You are comparing the security of Apache to IIS, not Linux to Windows. Modern versions of IIS are pretty good from what I hear, and besides it's not very hard to be secure when all you run is a firewall and a web server.
If you want to do a real comparison you should compare the Linux desktop to the Windows desktop. Your average Linux desktop is a security nightmare. Firstly there's no active security whatsoever, it's all passive. IE there are no virus scanners/anti-malware tools in common deployment. If the passive defences fail you are screwed, you cannot easily distribute signatures etc to clean up the mess. Secondly, the Linux security model is simply the UNIX security model, which was designed in the 70s for a totally different set of threats. Your average desktop is not a mainframe and does not need to protect users from one another - instead it's decayed into some kind of trivial black/white coarse grained security model in which "root" has absolute power and "users" have less power.
Unfortunately, Linux trains the user to enter their password all the time, given an essentially random set of situations. You have to enter your password to install software, remove software, configure hardware, set the system clock and worst of all to install security updates. The tasks that require root are to the average user totally unconnected. If you are a UNIX geek you can probably figure out why something might need root, but you're in the minority. So users are trained to just enter their password whenever they are asked to, making it trivial to phish it out of them.
Even if you can't get root - who cares? On a modern Linux desktop you can do anything you need without it. Want to crack bank details? Go right ahead, Firefox runs as user and you can ptrace() it to your hearts content. Want to hook into startup so you always run? KDE and GNOME will be happy to oblige. Want to "hide" yourself without modifying the kernel? No problem either, just inject yourself into the address space of each program as it starts and then hook the syscalls at the libc level. Childs play.
So to put it simply - you are dead wrong. The underlying problem at the system level is the system, which is basically the same regardless of whether you use Windows, MacOS or Linux. The UNIX/NT security model is incapable of solving the problem of malicious software, period.