Um, why? You don't need root to send mail, and Firefox has had its fair share of instant execution vulnerabilities. You can trivially hook yourself into the shell or session manager on Linux or MacOS X so you are always loaded at startup, and hax0ring Safari to steal encrypted form data is likewise scarily easy.
Techniques like SELinux or AppArmor can stop this but they aren't integrated with most distros, it's still experimental stuff, and MacOS doesn't have anything like it.
So, I don't see any logical reason spambots would not be technically possible on these operating systems. Please enlighten me.
You're reading the responses correctly. Except actually code signing is hardly important, phones are secure even with unsigned apps that anybody can write and distribute. I wrote an article on j2me security for those who want to learn more. Not all phones use it of course, for instance, you can write programs that can do pretty much anything AFAIK for older Symbians (which were modelled internally sort of like DOS/Win9x security-wise).
Now it turns out I was wrong, there HAS been a problem with J2ME in the past, there was a bug in the bytecode verifier (written in C/C++....) which allowed a malicious Java program to take control of the phone. But the issue for the attacker is, once you are running on the chip - now what? The guy who found this vulnerability (which I would hope is fixed in new phones!!) said it took him 4 months to reverse engineer the OS on his Nokia phone. And that's just for one model of one phone. Good luck making that sort of hack spread quickly.
The basic point is that Java itself (which is all most phones allow) is safe. The parts of a phone that aren't safe are the parts written in C or C++ or assembly: for instance, BlueTooth stacks, the JVM itself, maybe parts of the OS can be attacked by creating gui elements with really long names or something. But the basic scheme is secure (unlike on desktop machines), and the attack surface is much smaller than full computers. And even if you do somehow manage to hack a phone via its unsafe parts, the diversity in the market acts as a protection against epidemics.
The native security features of today's mobile devices are not capable of protecting against attacks like this, so it would be trivial to infect, say, an entire coffee shop full of Bluetooth phones in just a few minutes.
Says somebody who has clearly never programmed a mobile phone.
The vast, vast majority of consumer phones are not the so-called "smartphones" that run traditional operating systems like Symbian or Windows, they run proprietary operating systems that have no publically known names and do not export any APIs, except for J2ME or possibly BREW.
As an aside, J2ME consumer phones are often just as "smart" as larger, more powerful phone/PDA hybrids... my own does calendaring, web access, has an IMAP client built in, is themable, plays music and videos, and has a 500mb flash storage facility amongst other capabilities. Yet by the standard definition it is not "smart".
Anyway, J2ME has many flaws, but security is not one of them. If somebody finds a programmatic way to compromise a J2ME phone in the next 5 years then I will be very surprised. These things have no concept of processes or users, which is great, because this sort of security confuses the crap out of pretty much anybody who isn't steeped in UNIX security lore. Instead they rely on constructing (with a bit of help) a mathematical proof that the Java programs they're running don't compromise type safety, and then either interpret them or on Jazelle-based phones run them direct on the chip. This is safe and allows for a very flexible and intuitive form of security.
The absolute best you can do on these things is social engineering or exploiting piss-poor UI (which is what Cabir does). To claim you could "infect a cafe full of phones" is ludicrous: most people don't even have Bluetooth switched on as many phones disable it by default.
That sucks. I don't have my final grades yet, but I'm in the same boat - they approached me, so far I've done 2 interviews and they want another 5 in an on-site day. I'll be pissed off if I get my final grades and they decide it's not good enough.
There is a silver lining though - look at it this way, if you got through so many interviews and it took them so long to decide, I bet you were really close to getting it. A lot of people don't make it through the first 2 or so I hear - probably it was something as dumb as "We have two great candidates, neither is obviously better than the other, but one has a higher college grades than the other. We've got to decide somehow, that might as well be it".
Are you sure about that? I'm interviewing with them right now and I don't have a degree at all (yet)... also I'm pretty sure that it's not required. Certainly a GPA was never mentioned, not least of which because I'm European.
Maybe, if you do want to work there, you need to make yourself valuable in some other way... specialise in something they need maybe.
Programs like ZoneAlarm are worthless, injecting the code you want to run into a program guaranteed to have access, like IE or Firefox, can be done in about a screenful of code. Examples of it are easily found on the net.
Basically, I always groan when I see somebody has ZoneAlarm and usually tell them to scrap it. Firewalls shouldn't ever be necessary on a well designed system - on Windows they are simply because of the RPC crap, but I'd rather selectively deny that and allow everything else (remember malware programs can easily reconfigure the firewall themselves anyway).
Heya Quinn;) Yeah, I don't mind single player cheats, I was thinking of multiplayer online cheats... if everybody involved is happy with the new rules then why not ?
Nothing stops you writing an application that downloads encrypted media and plays it back on Linux today. It just wouldn't be very secure.
If the audio is decrypted inside the app and then sent direct to the sound card, bypassing the operating system entirely, then you can't just dump the audio to a file with an LD_PRELOAD or kernel patch. You'd have to reverse engineer the internals of the application itself, rather difficult, and something which LaGrande makes even more difficult anyway.
I'm not sure what part of this you aren't understanding, the technology isn't _that_ complicated. It's A-OK for data to pass through the kernel as it comes off the network card or disk controller because it's encrypted. It's once the player has decrypted it that things get sensitive and the kernel can't be involved anymore.
The kernel manages DMA today because that's what the hardware design requires. Obviously the kernel driver would still be doing the bulk of the work (set up and so on) but there's nothing stopping hardware vendors from supporting a special mode in which the kernel allows a userspace app and hardware to negotiate a secure dma channel by using a new instruction set.
Or by allowing apps to bypass the kernel for data transfer directly, by having a secure form of DMA. It's still not going to make people happy but it does get the kernel out of the way.
a) If your machine is rooted, it's trivial to tap the keyboard. Process "iexplore.exe" getting a number that looks like a CC#?
I'd be interested to see an actual implementation of that. But anyway, this is why LaGrande/Cell Security include "measured boot", so the program can check that the system hasn't been rooted.
b) If you are running Windows, you still won't know. The chain of trust runs downwards, your apps trust Windows which again trusts the TCPA. Whatever Windows does, you'll never know. And if you don't run Windows, then it's pretty hard to hide something in plain sight code.
That's not how it works. Your app trusts some piece of hardware (for instance, the TPM, or some Cell specific thing) and asks it for a "measurement" which proves cryptographically that a "trusted" operating system is running. Once the app has checked that it trusts the operating system it sends the data downwards.
c) I'd wager more on the ubiquitousness of piracy to change things.
That'll provide the incentive to change, it won't provide the solution. The only solution that is being credibly pushed right now is ubiquitous DRM. Other schemes like tip jars and so on have not really taken off.
I'd really like to see a credible economic solution - a programmer would call copyright a "hack" because it kludges supply and demand on top of stuff that fundamentally doesn't obey those rules, simply because that's all capitalism can deal with. But I'm not an economist and if there is any research being done in this field, I'm not aware of it.
So, how to you intend to access the output device?
If you read the article then you can see the way it's intended to be used... the SPEs decrypt data then either re-encrypt it (eg for multiplayer network packets) or use DMA to move it directly to the output device. The operating system is not involved. I don't know how LaGrande works but it's likely to be either by having "trusted" operating systems that effectively promise not to reroute the audio elsewhere, or by having some similar kind of DMA scheme and sound/video cards that can decrypt video data directly.
There's a third possibility you ignore: that DRM reduces software sales.
It's true I ignored this possibility. The only hard statistics I've seen on this have been done by (drumroll) copy protection vendors, nonetheless, they are at least somewhat pseudo-scientific which is more than the purely anecdotal evidence I've seen to support the opposing view. Essentially copy protection vendors claim that the sales you lose through piracy drop off as time goes by, so for instance if a crack is developed a year after the game comes out nobody really cares (partly because sales are much lower then anyway), but if one comes out a week after it's launched that'll have a big impact. The idea is some people wait for a crack and if one doesn't appear they will "crack" themselves and go buy it.
Trustworthy source? Of course not. But it makes intuitive sense and these appear to be the only repeatable studies done so far.
Alternatively you can also trust the market. Copy protection costs money to implement, presumably after 20 years of widespread software distribution if it was really a dead cost somebody would have realised by now and trailblazed their way across the market with their no-copy-protection policy. I don't see many vendors doing that.
I know that there are albums I plan to buy from the iTunes Music Store, but only if JHymn is fixed to allow me to strip the DRM.
I'm the same! I don't buy things from iTMS because I use Linux and my phone rather than an iPod for portable music.
So I do things the old way and buy CDs instead. Believe me, I don't like todays DRM either, but given a choice between FairPlay/Windows Media being the de-facto standards or having some kind of openly published system that doesn't rely on obscurity (which is what this sort of technology might provide) then I'll go for the latter any day.
As for the PS3, if it's secure enough to prevent cheat systems like Action Replay Max, that's going to have an impact on sales.
You're implying anti-cheat technology reduces sales? I'd be surprised if that was true, most people I know hate game cheats.
As to your final point - PS2 didn't have network access. PS3 does.
The fact that software is malleable is a two-sided coin: most people who end up with their machine modified in the ways this technique helps deal with are the victims of malware and viruses.
Regardless of what you believe it was designed for, the only things that actually matter are what it actually does. It's like saying that asymmetric crypto was designed so the military could hide secrets from civilians. Sure they use it for that, does that mean cryptography is bad? No.
Likewise, look at it from the perspective of the average gamer. This technology could easily be used to shield games from cheats with far greater effectiveness than now. You only have to play Counter Strike for half an hour to see how destructive cheaters can be - even if everybody is totally legit it won't be long until somebody is accusing somebody else of wallhacking. A game service that suffers trace levels of cheating would be enjoyed more by everybody, despite the software being less malleable as a result.
If you had RTFA you'd know this isn't about mod chips - the article explicitly states that this kind of protection is not about resisting hardware attacks and only concerns software.
WHY are you implementing it on a GAME CONSOLE?
Maybe because the Cell is designed to be used for more things than just the PlayStation?
Yes, it can make slightly more effective DRM because an application no longer needs to trust the operating system. But this isn't a black and white issue (realistically, outside of Slashdot groupthink, DRM is never black and white).
For instance, consider this:
It can make more effective DRM, but it can also make more effective encryption. How do you know your operating system is secure, really? Root kits are not at all uncommon even on desktop machines these days. Have you seen how easy it is to dump form data from Safari before it's encrypted? It's not quite as easy for IE or Firefox because they're written in C++ rather than Objective-C, but it's still possible.
Personally I wouldn't trust my CC number to an unknown Windows machine these days. SSL/TLS wire security just isn't secure anymore when it's so easy to intercept the data before it's ever encrypted.
Afraid the government is spying on you? What wasthat NSAKEY symbol in the Windows crypto libraries anyway? It'd be a LOT harder to put Big Brother style tech into a CPU than an operating system simply because the CPU has much less information to work with. So crypto programs can shield themselves from possibly malicious software in another way.
DRM exists, a lot of digital media is protected using it, and unless piracy suddenly becomes as unacceptable as murder or somebody invents a new kind of economic system to replace copyright it'll probably be around for a long time to come. Simply saying "we won't accept that" won't cut it with a lot of people, some geeks included (who do you think designs all this DRM anyway? magic programming pixies?).
Consider - hardware process protection would theoretically allow for Linux-compatible DRM. Right now Windows Media DRM uses the "secure audio path" to try and prevent people using malicious audio drivers to trivially dump the decrypted audio out of the player. Linux has no equivalent, fundamentally cannot, however these kind of hardware features could allow it to get such a thing without breaking the GPL (because the operating system can be GPLd and therefore "untrusted" but the player would not have to trust it to work...)
Anyway, like most technologies, it cuts both ways. It has uses you'll disagree with and others you will want. Just deal with it.
For comparison, the Intel equivalent to this technique (allowing processes to shield themselves even from the kernel) is called LaGrande Technology.
I'm not really a fan of this sort of design - it seems to duplicate the purpose of the existing kernel/userspace security architecture, but I can appreciate the pickle we're in with de-facto standard kernels that allow anything to be loaded into them. Windows Vista 64 bit requires all kernel drivers to be signed: correctly so, in my opinion, but this doesn't help the huge 32 bit userbase today.
Well, I never said theoretical CS wasn't useful, just that it doesn't overlap with most jobs.
In the first example you cited, I wouldn't have done things that way because I already know of some XML diffing tools that will do the job for you and are flexibly licensed. Validation and transformation can be done using off the shelf tools and a language like XSL:T as well. So in this case I wouldn't have used my graph theory knowledge because as it happens, I think it would have been easier to reuse code that was already written. Maybe it doesn't apply to your scenario, I don't know.
In the second example, that's certainly a valid example of overlap as most CS courses would contain something on grammars I'd hope, but you don't need to understand how to convert a NFA into a DFA to write a grammar or parser (though it might help).
I guess I came off as too harsh on CS degrees. Partly due to frustration with my own, which is not very good (imho).
Like all knowledge, theoretical CS can be of use at times, however given the stringent time limits available (really only 6 terms worth of proper teaching in most 3 year courses) a stronger priority should be put on practical skills and knowledge. This is not "technical trivia", it's the difference between your product sucking or not sucking.
Because realistically most students who stay in computing will work in software, it's not good enough anymore to blow it off as "we teach the fundamentals" - when students are getting into massive debt and society expects them to get high paying jobs to pay it off with, a good match between the skills they learn at university and the skills they need at work is essential.
I find it extremely sad that in the final year of the course I'm on we have covered SAT solvers twice but many students still use the BlueJ training-wheels tool. Debugger? Stack? Profiler? What's that?
Learning technical trivia is easy; anyone can do it. It doesn't take a genius to change an oil any more than it takes a genius to administrate a small network. However, understanding the deeper concepts (CSMA/CD!) and other principles is very useful if you are a computer scientist.
I've seen this sort of view a lot, and I find it rather disturbing. It is, put simply, the academic view that theoretical knowledge is universally superior to practical experience.
My actual experience both of doing a very theoretical CS course and working in many different software/computing related jobs is that this is not true, and actually practical experience is equally if not more important. Unless you intend to become a researcher or go into a very specialised area (eg compiler design), the contents of most theoretical CS courses are largely irrelevant to the day to day work people working with computers find themselves in.
Case in point:
I can attack problems of compiler theory, networks, operating systems, programming language theory, etc
That's great. As it happens compilers (specifically optimization techniques) interest it, but how much time do you spend writing compilers and designing new programming languages? I don't do it much. Whilst inventing "mini languages" along with the tools to work with them can be useful, in practice it's often discouraged for the same reasons C preprocessor abuse is discouraged: inventing your own tools and languages over using standard ones can cause problems for future programmers who have to maintain the system. Witness the conversion of the Yahoo! Store from Lisp to C++ for instance.
The fact is that theoretical CS courses don't teach "fundamentals". They teach theoretical CS, which overlaps somewhat but not entirely with what people usually get paid to do in industry. People who think they're going to walk into their first job and spend all day implementing graph algorithms will get a nasty shock when their first task is to diagnose why XYZ App crashes on Korean versions of Windows, or speed up a test harness by making it use IO multiplexing vs a fixed number of threads (a real situation I had to talk about in a recent interview).
In 20 years, the tools you use will have changed dozens of times.
This isn't really correct. The names of those tools have changed - in practice mainstream C/C++/Java/C# style languages are all very similar and have evolved quite slowly. If you knew C++ 15 years ago you would not have much new to learn to tackle most existing codebases today. And those 15 years of experience would put you in a much better position than somebody who had read a lot of textbooks but never actually debugged a race condition.
Anyhow, to get back to the original topic, I'm not sure you can extrapolate anything useful from the facts here.... maybe fewer programmers are competing in the ACM competition because they're busy working on their startups? I find it hard to believe America has a serious shortage of tech talent when nearly all the jobs I'm interested in currently are with American companies. I say that as a Brit who is not really enamoured with American culture or administration, but ultimately, the Googles and Linden Labs and Red Hats of the world are not based in London. They're based in America.
World of Warcraft is not in most distros, is it low quality? Compared to say, bzFlag?
Don't get me wrong, I love a good game of bzFlag, but saying "If a Linux distro is unwilling to do this, why should I use it in the first place since it is obiously of low quality?" isn't going to fly with most people...
The standards in question are things like "how do I install a menu item in a way that works across distributions" and "how do I distribute C++ apps in ways that don't randomly crash" and "what libraries can I expect a Linux system to have".
The whole "as long as the runtime libraries are there" catch is what it's all about. It's not reasonable to expect people to deal with dependencies.
Biggest problem with some commercial apps is they insist on using C++ and all the bleeding edge features of GCC 4.x.y.
GCC 4.x has been out hardly a year, almost no commercial apps "depend" on it. C++ on Linux is generally riddled with problems anyway but it's not the fault of people who use C++, it's the fault of the people behind the compilers and low level binary formats/tools...
Repository based installation is NOT the way to go. Autopackage is just a pretty frontend around the same problem.
Well, autopackage was designed to deal with many of the problems repository based distribution has, so, I would strongly disagree with the notion that it's just "a pretty frontend around the same problem". We've put many, many times more effort into things like reliable/easy installs than making it pretty (though there is still much to do).
Without this ease of use, there's no chance. I still laugh at people who say linux is ready, whilst at the same time they can't install the latest firefox on their box because it depends on the latest gtk which depends on the latest glib, which depends on....
This problem affects any OS. You can't install Safari on MacOS X 10.1 either, if I remember correctly. It's true that Linux suffers this problem worst of all though, because there's no unified platform, and because there's no profit motive so little incentive for developers to go "the extra mile" to reduce system requirements. But it's a separate (though related) problem to how you install software.
That was then, this is now. The Times reported today a huge drop in iPod sales. Steve Jobs was quoted as saying "To be honest, nobody ever sold 8.5 million music players in a quarter before anyway".
Slashdot Mirror
Techniques like SELinux or AppArmor can stop this but they aren't integrated with most distros, it's still experimental stuff, and MacOS doesn't have anything like it.
So, I don't see any logical reason spambots would not be technically possible on these operating systems. Please enlighten me.
Now it turns out I was wrong, there HAS been a problem with J2ME in the past, there was a bug in the bytecode verifier (written in C/C++ ....) which allowed a malicious Java program to take control of the phone. But the issue for the attacker is, once you are running on the chip - now what? The guy who found this vulnerability (which I would hope is fixed in new phones!!) said it took him 4 months to reverse engineer the OS on his Nokia phone. And that's just for one model of one phone. Good luck making that sort of hack spread quickly.
The basic point is that Java itself (which is all most phones allow) is safe. The parts of a phone that aren't safe are the parts written in C or C++ or assembly: for instance, BlueTooth stacks, the JVM itself, maybe parts of the OS can be attacked by creating gui elements with really long names or something. But the basic scheme is secure (unlike on desktop machines), and the attack surface is much smaller than full computers. And even if you do somehow manage to hack a phone via its unsafe parts, the diversity in the market acts as a protection against epidemics.
Says somebody who has clearly never programmed a mobile phone.
The vast, vast majority of consumer phones are not the so-called "smartphones" that run traditional operating systems like Symbian or Windows, they run proprietary operating systems that have no publically known names and do not export any APIs, except for J2ME or possibly BREW.
As an aside, J2ME consumer phones are often just as "smart" as larger, more powerful phone/PDA hybrids ... my own does calendaring, web access, has an IMAP client built in, is themable, plays music and videos, and has a 500mb flash storage facility amongst other capabilities. Yet by the standard definition it is not "smart".
Anyway, J2ME has many flaws, but security is not one of them. If somebody finds a programmatic way to compromise a J2ME phone in the next 5 years then I will be very surprised. These things have no concept of processes or users, which is great, because this sort of security confuses the crap out of pretty much anybody who isn't steeped in UNIX security lore. Instead they rely on constructing (with a bit of help) a mathematical proof that the Java programs they're running don't compromise type safety, and then either interpret them or on Jazelle-based phones run them direct on the chip. This is safe and allows for a very flexible and intuitive form of security.
The absolute best you can do on these things is social engineering or exploiting piss-poor UI (which is what Cabir does). To claim you could "infect a cafe full of phones" is ludicrous: most people don't even have Bluetooth switched on as many phones disable it by default.
There is a silver lining though - look at it this way, if you got through so many interviews and it took them so long to decide, I bet you were really close to getting it. A lot of people don't make it through the first 2 or so I hear - probably it was something as dumb as "We have two great candidates, neither is obviously better than the other, but one has a higher college grades than the other. We've got to decide somehow, that might as well be it".
Maybe, if you do want to work there, you need to make yourself valuable in some other way ... specialise in something they need maybe.
Basically, I always groan when I see somebody has ZoneAlarm and usually tell them to scrap it. Firewalls shouldn't ever be necessary on a well designed system - on Windows they are simply because of the RPC crap, but I'd rather selectively deny that and allow everything else (remember malware programs can easily reconfigure the firewall themselves anyway).
Heya Quinn ;) Yeah, I don't mind single player cheats, I was thinking of multiplayer online cheats ... if everybody involved is happy with the new rules then why not ?
Nothing stops you writing an application that downloads encrypted media and plays it back on Linux today. It just wouldn't be very secure.
If the audio is decrypted inside the app and then sent direct to the sound card, bypassing the operating system entirely, then you can't just dump the audio to a file with an LD_PRELOAD or kernel patch. You'd have to reverse engineer the internals of the application itself, rather difficult, and something which LaGrande makes even more difficult anyway.
I'm not sure what part of this you aren't understanding, the technology isn't _that_ complicated. It's A-OK for data to pass through the kernel as it comes off the network card or disk controller because it's encrypted. It's once the player has decrypted it that things get sensitive and the kernel can't be involved anymore.
The kernel manages DMA today because that's what the hardware design requires. Obviously the kernel driver would still be doing the bulk of the work (set up and so on) but there's nothing stopping hardware vendors from supporting a special mode in which the kernel allows a userspace app and hardware to negotiate a secure dma channel by using a new instruction set.
Or by allowing apps to bypass the kernel for data transfer directly, by having a secure form of DMA. It's still not going to make people happy but it does get the kernel out of the way.
I'd be interested to see an actual implementation of that. But anyway, this is why LaGrande/Cell Security include "measured boot", so the program can check that the system hasn't been rooted.
That's not how it works. Your app trusts some piece of hardware (for instance, the TPM, or some Cell specific thing) and asks it for a "measurement" which proves cryptographically that a "trusted" operating system is running. Once the app has checked that it trusts the operating system it sends the data downwards.
That'll provide the incentive to change, it won't provide the solution. The only solution that is being credibly pushed right now is ubiquitous DRM. Other schemes like tip jars and so on have not really taken off.
I'd really like to see a credible economic solution - a programmer would call copyright a "hack" because it kludges supply and demand on top of stuff that fundamentally doesn't obey those rules, simply because that's all capitalism can deal with. But I'm not an economist and if there is any research being done in this field, I'm not aware of it.
If you read the article then you can see the way it's intended to be used ... the SPEs decrypt data then either re-encrypt it (eg for multiplayer network packets) or use DMA to move it directly to the output device. The operating system is not involved. I don't know how LaGrande works but it's likely to be either by having "trusted" operating systems that effectively promise not to reroute the audio elsewhere, or by having some similar kind of DMA scheme and sound/video cards that can decrypt video data directly.
It's true I ignored this possibility. The only hard statistics I've seen on this have been done by (drumroll) copy protection vendors, nonetheless, they are at least somewhat pseudo-scientific which is more than the purely anecdotal evidence I've seen to support the opposing view. Essentially copy protection vendors claim that the sales you lose through piracy drop off as time goes by, so for instance if a crack is developed a year after the game comes out nobody really cares (partly because sales are much lower then anyway), but if one comes out a week after it's launched that'll have a big impact. The idea is some people wait for a crack and if one doesn't appear they will "crack" themselves and go buy it.
Trustworthy source? Of course not. But it makes intuitive sense and these appear to be the only repeatable studies done so far.
Alternatively you can also trust the market. Copy protection costs money to implement, presumably after 20 years of widespread software distribution if it was really a dead cost somebody would have realised by now and trailblazed their way across the market with their no-copy-protection policy. I don't see many vendors doing that.
I'm the same! I don't buy things from iTMS because I use Linux and my phone rather than an iPod for portable music.
So I do things the old way and buy CDs instead. Believe me, I don't like todays DRM either, but given a choice between FairPlay/Windows Media being the de-facto standards or having some kind of openly published system that doesn't rely on obscurity (which is what this sort of technology might provide) then I'll go for the latter any day.
You're implying anti-cheat technology reduces sales? I'd be surprised if that was true, most people I know hate game cheats.
As to your final point - PS2 didn't have network access. PS3 does.
Regardless of what you believe it was designed for, the only things that actually matter are what it actually does. It's like saying that asymmetric crypto was designed so the military could hide secrets from civilians. Sure they use it for that, does that mean cryptography is bad? No.
Likewise, look at it from the perspective of the average gamer. This technology could easily be used to shield games from cheats with far greater effectiveness than now. You only have to play Counter Strike for half an hour to see how destructive cheaters can be - even if everybody is totally legit it won't be long until somebody is accusing somebody else of wallhacking. A game service that suffers trace levels of cheating would be enjoyed more by everybody, despite the software being less malleable as a result.
Maybe because the Cell is designed to be used for more things than just the PlayStation?
For instance, consider this:
Personally I wouldn't trust my CC number to an unknown Windows machine these days. SSL/TLS wire security just isn't secure anymore when it's so easy to intercept the data before it's ever encrypted.
Consider - hardware process protection would theoretically allow for Linux-compatible DRM. Right now Windows Media DRM uses the "secure audio path" to try and prevent people using malicious audio drivers to trivially dump the decrypted audio out of the player. Linux has no equivalent, fundamentally cannot, however these kind of hardware features could allow it to get such a thing without breaking the GPL (because the operating system can be GPLd and therefore "untrusted" but the player would not have to trust it to work...)
Anyway, like most technologies, it cuts both ways. It has uses you'll disagree with and others you will want. Just deal with it.
I'm not really a fan of this sort of design - it seems to duplicate the purpose of the existing kernel/userspace security architecture, but I can appreciate the pickle we're in with de-facto standard kernels that allow anything to be loaded into them. Windows Vista 64 bit requires all kernel drivers to be signed: correctly so, in my opinion, but this doesn't help the huge 32 bit userbase today.
In the first example you cited, I wouldn't have done things that way because I already know of some XML diffing tools that will do the job for you and are flexibly licensed. Validation and transformation can be done using off the shelf tools and a language like XSL:T as well. So in this case I wouldn't have used my graph theory knowledge because as it happens, I think it would have been easier to reuse code that was already written. Maybe it doesn't apply to your scenario, I don't know.
In the second example, that's certainly a valid example of overlap as most CS courses would contain something on grammars I'd hope, but you don't need to understand how to convert a NFA into a DFA to write a grammar or parser (though it might help).
I guess I came off as too harsh on CS degrees. Partly due to frustration with my own, which is not very good (imho).
Like all knowledge, theoretical CS can be of use at times, however given the stringent time limits available (really only 6 terms worth of proper teaching in most 3 year courses) a stronger priority should be put on practical skills and knowledge. This is not "technical trivia", it's the difference between your product sucking or not sucking.
Because realistically most students who stay in computing will work in software, it's not good enough anymore to blow it off as "we teach the fundamentals" - when students are getting into massive debt and society expects them to get high paying jobs to pay it off with, a good match between the skills they learn at university and the skills they need at work is essential.
I find it extremely sad that in the final year of the course I'm on we have covered SAT solvers twice but many students still use the BlueJ training-wheels tool. Debugger? Stack? Profiler? What's that?
That should read "compilers and optimization techniques interest me" not it, sorry ...
I've seen this sort of view a lot, and I find it rather disturbing. It is, put simply, the academic view that theoretical knowledge is universally superior to practical experience.
My actual experience both of doing a very theoretical CS course and working in many different software/computing related jobs is that this is not true, and actually practical experience is equally if not more important. Unless you intend to become a researcher or go into a very specialised area (eg compiler design), the contents of most theoretical CS courses are largely irrelevant to the day to day work people working with computers find themselves in.
Case in point:
That's great. As it happens compilers (specifically optimization techniques) interest it, but how much time do you spend writing compilers and designing new programming languages? I don't do it much. Whilst inventing "mini languages" along with the tools to work with them can be useful, in practice it's often discouraged for the same reasons C preprocessor abuse is discouraged: inventing your own tools and languages over using standard ones can cause problems for future programmers who have to maintain the system. Witness the conversion of the Yahoo! Store from Lisp to C++ for instance.
The fact is that theoretical CS courses don't teach "fundamentals". They teach theoretical CS, which overlaps somewhat but not entirely with what people usually get paid to do in industry. People who think they're going to walk into their first job and spend all day implementing graph algorithms will get a nasty shock when their first task is to diagnose why XYZ App crashes on Korean versions of Windows, or speed up a test harness by making it use IO multiplexing vs a fixed number of threads (a real situation I had to talk about in a recent interview).
This isn't really correct. The names of those tools have changed - in practice mainstream C/C++/Java/C# style languages are all very similar and have evolved quite slowly. If you knew C++ 15 years ago you would not have much new to learn to tackle most existing codebases today. And those 15 years of experience would put you in a much better position than somebody who had read a lot of textbooks but never actually debugged a race condition.
Anyhow, to get back to the original topic, I'm not sure you can extrapolate anything useful from the facts here .... maybe fewer programmers are competing in the ACM competition because they're busy working on their startups? I find it hard to believe America has a serious shortage of tech talent when nearly all the jobs I'm interested in currently are with American companies. I say that as a Brit who is not really enamoured with American culture or administration, but ultimately, the Googles and Linden Labs and Red Hats of the world are not based in London. They're based in America.
Don't get me wrong, I love a good game of bzFlag, but saying "If a Linux distro is unwilling to do this, why should I use it in the first place since it is obiously of low quality?" isn't going to fly with most people ...
Hidden renamed symbols is a new one to me, do you have any more details about this specific issue?
The whole "as long as the runtime libraries are there" catch is what it's all about. It's not reasonable to expect people to deal with dependencies.
GCC 4.x has been out hardly a year, almost no commercial apps "depend" on it. C++ on Linux is generally riddled with problems anyway but it's not the fault of people who use C++, it's the fault of the people behind the compilers and low level binary formats/tools ...
Well, autopackage was designed to deal with many of the problems repository based distribution has, so, I would strongly disagree with the notion that it's just "a pretty frontend around the same problem". We've put many, many times more effort into things like reliable/easy installs than making it pretty (though there is still much to do).
This problem affects any OS. You can't install Safari on MacOS X 10.1 either, if I remember correctly. It's true that Linux suffers this problem worst of all though, because there's no unified platform, and because there's no profit motive so little incentive for developers to go "the extra mile" to reduce system requirements. But it's a separate (though related) problem to how you install software.
That was then, this is now. The Times reported today a huge drop in iPod sales. Steve Jobs was quoted as saying "To be honest, nobody ever sold 8.5 million music players in a quarter before anyway".