If you have anything more sophisticated then a Westell UltraLine Series3 router, you are not affected.
The XSS uses the factory default router IP 192.168.1.1 to send HTTP requests to your router.
Nowadays, journalism is something you do in 144 characters or less.
People don't complain when Cisco, Juniper, etc integrate their routing/switching/firewall features with ASICs.
Why should databases be different?
Given the hardware prices and wide interest in FIPS-type security requirements, Oracle might as well be selling appliances. It will come to this sooner or later.
Who says you have to make GSM phone calls?
T-Mobile G1 can do VoIP just fine.
Most of these discussions/arguments about Java are strictly concerning performance, like whether or not Java is bloated and slow. Your post there is one of the first I've seen that neatly answers the question of "why Java?" If it is as you say, then that's a highly desirable feature. That's especially when you consider the volume of personal information that's usually contained on a mobile phone, which I'd imagine would make it an attractive target for malware.
For better or worth, software development is nothing like video games. Performance, the topic of obsession for video gamers, is oftentimes an afterthought in industrial software development. Security, reliability, maintainability, computability, clarity receive higher priority almost each and every time. In order to understand this, of course, you have to spend a few too many years in software development. The truth about performance is rarely taught in CS university course, and almost never understood by CS students. I too was a fresh CS grad over a decade ago (I actually remember the time when Slashdot was popular) and despised, if not hated, Java. I adored C, optimized parts of the code in assembly, and though I knew everything there is to know. Boy was I silly. I was forced by my employer to deal with Java parts in a huge mixed codebase in 2000. I accepted Java in 2003 when it finally started producing decent benchmarks on the brand new Linux test equipment. Since then, I worked on many diverse problems, broadened my software architecture experience, and came to appreciate Java's design. I don't think I can design a better platform myself. I know that James Gosling is a freaking generous because I remember when I though he was a fool. Software design should never focus on fixed performance cost factors. Moore's law will marginalize fixed performance factors in a matter of years no matter how high in absolute value these fixed factors are.
But don't take my word for it. Listen to my elder colleague Charles E. Leiserson from MIT - Why study algorithms and performance?
I don't know much about Java but this got me curious. What does Java offer here that would be difficult (or impractical/impossible) to achieve with using syscall restrictions and other devices to sandbox the apps? With virtual memory and appropriate syscall restrictions that sounds like it should work too, and would make it easier to run native code, yet I don't hear of devices that use such an approach. Is it that both methods are equally viable, only with Java someone has already created an implementation that is useful for mobile phones so why reinvent the wheel? Or is Java's approach inherently superior in some way?
Unfortunately, writing a program that would validate system calls is much much easier said than done. It takes no time what so ever to say it. If you actually start writing a program like that, you will quickly realized that this will be The most complicated problem of your life. Take a look at the NSA SELinux codebase. SELinux actually implements an extremely limited functionality to validate system calls. SELinux configuration cannot be controlled from the user space, so it is useless in any environment where you actually want to leave some security decisions to users. Also remember, if you create a workaround to give users some control over SELinux configuration, nothing will stop a malicious program run by a user from using the workaround you created without the user's knowledge. You need at least 3-tier architecture to implement a usable security. Moreover, you will have to analyze sequences of system calls in bundles and not just do an analysis call by call. Solving problem after problem, you will end up writing a virtual machine in pretty much the same way it is written for Java. It took more than 10 years for Java developers to implement their virtual machine solution - they started around 1992 and the most functional J2SE 1.4 appeared in 2002. It makes no sense what so ever to write a virtual machine yourself.
MySpace generation needs mobile communication devices to be promiscuous with. Security is one of the top design priorities, and Google just hit a jackpot with Android.
There is nothing simple about solving the system call validation problem. You actually end up writing a VM.
You are also forgetting about the problem of arbitrary memory pointers. You don't have to break into the privileged kernel mode in order to break security. All you have to do is to read or write what you are not allowed to access.
Native code is not officially supported. The Android-SDK gave me Java last time I tried.
Crosscompile your application for ARM and push it on your Android phone with adb.
The trick of native code is that you do not need to buy expensive hardware to run you application at decent speed. You can run your server even on ARM Cortex while Java needs some expensive hardware to be even considered. Cost saving, green technology, etc. that is what native code enables. While Java is designed to sell pricey hardware from day one.
The trick with mobile devices is that users want to run hundreds of thousands of untrusted programs from application markets. Native code leads to viruses, trojan horses, keyloggers and all kinds of nasty things. Users have to have a protection mechanism. Java with its multilayer security is perfect for mobile applications.
If you are talking about servers, I have a newsflash for you. The majority of servers hardly use even 50% of their processing capacity on average. Java overhead at this stage of CPU development is negligible. Green movement will benefit more from saving the resources spent on development and maintenance of native code.
Ah, that's very unfortunate for AMD/ATI. ATI exists the mobile graphics market right at the moment when it starts heating up.
Does the sale preclude ATI from developing new mobile graphics platform in the near future?
AMD owns ATI. Thus, it is technically AMD/ATI.
Have you ever hear of NVidia (besides the Tegra we have yet to see) being paired with hand-held devices?
It is coming. New batteries, more efficient chips, more powerful cellphones. Everyone who's someone will be in that market
You are talking pure nonsense.
First, for many devices it is not about speed, it is about security. Java provides a very robust security framework to run untrusted code. If you were to make a similar security framework for C/C++, you would end up with Java.
Second, if Java runs too slow for you - buy a better CPU.
Third, I doubt you realize how many productions systems are running Java. My department alone is running a multi-million dollar platform all on Java.
Last, you actually can run C/C++ code on Android. You can run ARM assembly, C-Sharp, and Python too. But don't tell anyone.
If NVidia does not want a piece of Android business, it is NVidia's loss.
And AMD/ATI gain.
My money is on the Linux community figuring out how to incorporate NVidia support into Android with or without NVidia's corporate blessing. Heck, a few of NVidia engineers belong to Linux community too.
"Say yur prayers, yuh flea-pickin' varmint!" -- Yosemite Sam