Sure they can, if they disable the forward locking. The DRM on paid apps is optional and is implemented by using filesystem permissions, so obviously a rooted phone and such apps don't mix. By the way, you don't need a Developer Phone to develop apps. You only need to use such a phone if you want to reflash a custom OS build.
In no way is Android "holy crap hard". And the Java used is 1.5, doesn't get more standard than that. If you mean it's not using Swing then, well, yeah... what did you expect? It's a phone!
Well, you're close to hitting the nail on the head but not quite there.
You need to consider the difference between running on a non-x86 device, and running well on a non-x86 device. Let's say you write a Photoshop killer as a web app using NaCl. Do you really lose because NaCl is x86-specific? No. Even if there was some platform independent bytecode layer it would not help you. It'd just convert a webapp that didn't run at all on your iPhone to one that ran unusably slowly.
Phones and desktops/laptops are just different devices - hardware is just an order of magnitude less powerful. That's the kind of difference that requires you to rewrite your app from scratch. No bytecode party trick is going to solve that one for you. Nobody is going to start retouching their photos on their iPhone because your webapp runs on it. They're going to wait for a mobile-optimized app to come along, just like how companies serious about mobiles write separate versions of their site for iPhone/Android today.
So we've established that you'll need to rewrite your app for ARM anyway, regardless of what NaCl does. This leaves PowerPC as the only other architecture that matters. PPC is only used on games consoles though, and nobody browses the web from a games console, thus we can conclude that x86 is the only architecture that matters for performance sensitive web apps and this is likely to remain the case for the foreseeable future.
Java has a few problems NaCl doesn't, which is why NaCl has a chance at success and Java didn't:
Java was massive in every aspect. It took ages to download, install, and start. It nagged the user to update itself. This led to a very poor user experience. Nobody enjoyed accidentally visiting a web page that used a Java applet because your entire system would grind to a halt for 10 seconds whilst the JVM would heave its bloated carcass into RAM. I am told the very latest versions of Java fix this, but I care not - Java comprehensively blew its chances 10 years ago for this reason alone. NaCl is tiny and has almost no startup time. Google Updater does not nag for updates, it just does it in the background. The user experience is invisible - as it should be.
Java was so big it was impossible to secure. Mathematically it was impossible to break, but practically big parts of the JVM were written in native code, and were repeatedly exploited for fun and profit. NaCls "trusted code base" weighs in at a few hundreds kilobytes of code. It's actually feasible to hammer out all the bugs in such a codebase. JVM it's not possible. And anyway, Googles approach to security updates is to do them silently, in the background, enabled by default. Thus NaCl is secure and JVM is not.
Java is slow. Yes it is. When Java came out it used tons of memory and tons of CPU to do fuck all. Everyone criticized Java for being slow, so Sun decided to make it fast. And they did... sorta... but they spent a decade making it fast cpu-wise and no time at all making it memory efficient. On multi-tasking desktops memory usage is death. You push the machine into swap, and you are dead in the water. Try looking at the memory usage of the string "hello world" in Java vs C++ some time, and then try and come up with ways to fix it, to see why Java never had a chance. I run Eclipse on a dual core MacBook Pro with a gig of RAM and every so often it just "goes away" for 15-30 seconds whilst it garbage collects. What the fuck? NaCL is small and people know how to write C++ code that is efficient in both time and space. Manual memory management is awful but it plays nicely with swapped virtual memory, and that matters.
Java required you to rewrite all your code in Java. Tons of useful and well debugged code had already been written in C and C++ but Java only had weak support for it (jni is awful), and of course there was no internet deployment system for jni. NaCL lets you reuse your investment in existing native code.
Eh? It's trivial to demonstrate it's morally bad. What would happen if everybody downloaded crap without paying for it? Well, there'd be virtually no new content created by paid professionals. This is Kants categorical imperative - basic stuff.
I think anybody who isn't ideologically committed to the Power Of The Amateur can see that this would be a bad thing. Children can understand this, why have you rationalized your way into such a ridiculous mental box?
No, it's an example of the power of consistency, which is best obtained by sourcing from a single supplier. I highly doubt these warships had cannons from a variety of manufacturers made to detailed open specifications. More likely, navy smiths made all the cannons themselves, with the same tools and same people each time. In a modern context, it'd mean the navy standardising on one technology from one supplier - ie, Microsoft. Nice try though.
SSL is flawed, at least for the web. Usability studies have shown time and time again that the vast majority of people do not understand and will ignore the bad cert error dialogs. That's a pretty fundamental problem, and why Firefox now makes it really hard to bypass them, but all it's doing is putting a sticking plaster on a bullet wound.
Eh, I have one. It's really not that bad. Anyway, you neglect to mention that the G1 has only been available for 4 months, and in two countries - contrast with the iPhone which has been around since 2007 and has had international presence for much longer.
There are no optimizations in Wine for Office. Office (and IE) start faster than their native equivalents because Microsoft puts a high degree of importance on startup time, and uses sophisticated toolchains to reduce (amongst other things) the number of disk seeks required to bring the app up. OpenOffice doesn't care about this at all, and it shows. Wine imposes some hefty startup overhead itself, yet Word is still faster to start - that should tell you just how far ahead Microsoft is in this department.
Windows uses about as many shared libraries as Linux does, although it has a more efficient design. So you need to look elsewhere for the problem sorry.
Actually he's right but in the wrong direction. On Wine many things that would be pure syscalls on Windows do force a context switch into the wineserver, because the emulated "kernel" is actuall a separate process. For instance opening a file involves an RPC to the wineserver on Wine, whereas it simply switches into kernel mode on Windows and there's no TLB flush overhead. The fact that Firefox is still faster under Wine than native suggests a serious bottleneck somewhere rather than a general problem - if I had to choose, I'd pick text rendering as my first guess.
And for those who wonder where the BeOS team are now, go look at Android - large parts of the Be team went on to continue writing operating systems and nowadays work for the big G. The successor to BeOS is really Android, not Haiku.
It uninstalls itself when the apps it exists to update are uninstalled (you may have to give it a few hours to wake up and realize the apps are gone). No registry hacking needed.
What I'm seriously asking for is a point of contact who can at least enlighten me as to why some areas are updated on what appears to be a monthly basis when there are so many areas that are woefully out of date.
I am not in the PR team here at Google, so this is not an official, accurate answer but I'll do the best I can. If these answers aren't quite accurate, well, tough noogies, it's Slashdot. That said, here are some answers to your questions:
Some areas of the world are just easier to take photos of than other areas, for instance, it's quite hard to take satellite pictures of the north of the UK because it's always cloudy there, so you need to do it all via aircraft.
Some areas are updated more frequently because lots of people live there, so they're more interesting areas to refresh.
Some imagery is donated by, eg, local government.
You cannot "get on the satellite schedule" sorry. The fastest way to get clear imagery in Google Earth is to pay for it, and then donate it. However there are quality bars that the imagery must meet before it's included. Yes it's amazingly expensive. Why do you think Google Earth was so revolutionary when it came out? A large part of it was that Google spent mind-boggling amounts of money on buying up imagery, then let people look at it for free.
For goodness sake. Am I the only one that likes the Google Updater?
Let's review the benefits it has:
Apps are upgraded silently, with no notification. Yes this is a benefit. If you have a Mac you'll know what a pain in the ass it is that every app you start feels the need to dump an assload of ChangeLog in your face every other week. Do I really care that Adium updated to the latest libpurple? What does that even mean to me? 99.9% of the time I can't tell any difference. I trust the Adium developers, I wish they'd just do their job and let me use their app without bugging me. Of course replace Adium with any other modern app for the Mac. Except iTunes which is just as annoying except you don't even get a changelog.
Updates are downloaded as binary deltas, and on Windows it's done in such a way that it only uses the connection when idle (Windows Update does the same thing). So it's not intrusive.
The updater goes away if you uninstall all the apps which use it, so there's no problem there.
It takes about 500k of RAM and virtually no CPU, but it ensures I get security updates in a timely manner. For instance if there's an exploit discovered in Chrome, the wrong time to apply that update is at the end of my next session, by which time it's too late. The right time to apply it is when my computer is idle, before I start using Chrome again.
I think people overestimate the resource drain this app has. Really, this should be a core part of Windows. I'd much rather desktop apps behave like web apps and just get silently better instead of expecting me to give a rats ass about the existence of a 0.0.1 point release.
You'd think so wouldn't you. Actually it doesn't work like that.
The first problem with their approach is that they actually implemented the whole OS shell in Python. Now I dunno about the Commodore 64, but I remember the BBC Basic and I can assure you, the OS and most apps were not written in BASIC. They were written in assembler because that was the only way to make non-sucky software. Fast-forward to 2009 and it's the same thing - Python is an awful language to make performant, robust software in. And an operating system shell needs to be both fast and solid. Sugar is neither.
But maybe (maybe) if it was actually feasible for a child to press a key and get exploring, that'd be a price worth paying for the rest. Except it's not. Have you actually read the Sugar code? It's awful. I did a spot-check on this whole claim when Sugar first came out and found it bogus.
I took the Block Party game (seeing as games are what kids like) and looked at the code. The first problem is the code is completely uncommented. Seriously. The only comments are the license boilerplate at the top. The second problem is the code isn't simple like BASIC used to be. It's object-oriented event-handling GUI code that uses containment based layout, multiple libraries, sound servers, uses magic numbers etc. It'd be hard to figure out for an adult, let alone somebody new to programming. There's no 10 PRINT HELLO WORLD 20 GOTO 10 there.
So they managed to make a flaky, incredibly resource intensive environment on the grounds that "it's python and kids will love learning programming by reading python" except the code is crap and impenetrable. Fail.
I would bet a lot of money that won't happen. Any failure like this one has many sides to it and responsibility will always be distributed over multiple people. The result of this will be a detailed post mortem, better processes, tools, and software, to ensure that something like it does not happen again.
This is the first Google effective downtime in my memory.. Were there other ones that anyone can think of?
google.com stopped resolving back in 2005 for 15 minutes. Nobody got fired.
This executive order is basically the same one that was created post-Watergate to try and ensure Presidential records were published and archived for posterity. Bush revoked it in a widely criticised move, Obamas EO revokes the revocation and is otherwise identically worded, except that it also now covers the Vice President, which can only be an improvement. So basically on day 1 of his new Presidency Obama is already undoing some of the damage Bush caused:)
Steve Jobs health is perceived to be connected to the long term health of the company.
Free markets require the participants to have accurate information to work well. Corporations aren't allowed to lie about things that actually affect their value significantly, capitalism just can't work like that.
It's possible to credibly accuse Apple of playing fast and loose with the facts around Jobs' health. Thus it's entirely correct that the SEC investigates. This is not what is wrong with America or capitalism - this is what's right: a ready supply of accurate information is valued. Apple doesn't get a free pass with the truth just because it's a mans health we're talking about. If people make bad investment decisions based on half truths, that's bad for them too!
C++ only does that if you are trying to pass classes by value, which is almost always a bad idea. I agree it's unintuitive but then a lot of C++ is, you don't lose anything if you simply never pass subclasses by value. If you use references the whole problem disappears.
Slashdot Mirror
Sure they can, if they disable the forward locking. The DRM on paid apps is optional and is implemented by using filesystem permissions, so obviously a rooted phone and such apps don't mix. By the way, you don't need a Developer Phone to develop apps. You only need to use such a phone if you want to reflash a custom OS build.
In no way is Android "holy crap hard". And the Java used is 1.5, doesn't get more standard than that. If you mean it's not using Swing then, well, yeah ... what did you expect? It's a phone!
You could compile it with gcj, but you still have the problem of the giant runtime library. BTW get back to work dude, what if Gary sees you :-)
Well, you're close to hitting the nail on the head but not quite there.
You need to consider the difference between running on a non-x86 device, and running well on a non-x86 device. Let's say you write a Photoshop killer as a web app using NaCl. Do you really lose because NaCl is x86-specific? No. Even if there was some platform independent bytecode layer it would not help you. It'd just convert a webapp that didn't run at all on your iPhone to one that ran unusably slowly.
Phones and desktops/laptops are just different devices - hardware is just an order of magnitude less powerful. That's the kind of difference that requires you to rewrite your app from scratch. No bytecode party trick is going to solve that one for you. Nobody is going to start retouching their photos on their iPhone because your webapp runs on it. They're going to wait for a mobile-optimized app to come along, just like how companies serious about mobiles write separate versions of their site for iPhone/Android today.
So we've established that you'll need to rewrite your app for ARM anyway, regardless of what NaCl does. This leaves PowerPC as the only other architecture that matters. PPC is only used on games consoles though, and nobody browses the web from a games console, thus we can conclude that x86 is the only architecture that matters for performance sensitive web apps and this is likely to remain the case for the foreseeable future.
64bit doesn't offer any compelling advantages to most end users, so the ability to run 32 bit code isn't going away anytime soon.
That's too slow for many classes of apps though. For instance, good luck making Mirrors Edge run as a web app with that technique ...
You should read the paper before saying things that are provably false.
Java has a few problems NaCl doesn't, which is why NaCl has a chance at success and Java didn't:
Java was massive in every aspect. It took ages to download, install, and start. It nagged the user to update itself. This led to a very poor user experience. Nobody enjoyed accidentally visiting a web page that used a Java applet because your entire system would grind to a halt for 10 seconds whilst the JVM would heave its bloated carcass into RAM. I am told the very latest versions of Java fix this, but I care not - Java comprehensively blew its chances 10 years ago for this reason alone. NaCl is tiny and has almost no startup time. Google Updater does not nag for updates, it just does it in the background. The user experience is invisible - as it should be.
Java was so big it was impossible to secure. Mathematically it was impossible to break, but practically big parts of the JVM were written in native code, and were repeatedly exploited for fun and profit. NaCls "trusted code base" weighs in at a few hundreds kilobytes of code. It's actually feasible to hammer out all the bugs in such a codebase. JVM it's not possible. And anyway, Googles approach to security updates is to do them silently, in the background, enabled by default. Thus NaCl is secure and JVM is not.
Java is slow. Yes it is. When Java came out it used tons of memory and tons of CPU to do fuck all. Everyone criticized Java for being slow, so Sun decided to make it fast. And they did ... sorta ... but they spent a decade making it fast cpu-wise and no time at all making it memory efficient. On multi-tasking desktops memory usage is death. You push the machine into swap, and you are dead in the water. Try looking at the memory usage of the string "hello world" in Java vs C++ some time, and then try and come up with ways to fix it, to see why Java never had a chance. I run Eclipse on a dual core MacBook Pro with a gig of RAM and every so often it just "goes away" for 15-30 seconds whilst it garbage collects. What the fuck? NaCL is small and people know how to write C++ code that is efficient in both time and space. Manual memory management is awful but it plays nicely with swapped virtual memory, and that matters.
Java required you to rewrite all your code in Java. Tons of useful and well debugged code had already been written in C and C++ but Java only had weak support for it (jni is awful), and of course there was no internet deployment system for jni. NaCL lets you reuse your investment in existing native code.
Eh? It's trivial to demonstrate it's morally bad. What would happen if everybody downloaded crap without paying for it? Well, there'd be virtually no new content created by paid professionals. This is Kants categorical imperative - basic stuff.
I think anybody who isn't ideologically committed to the Power Of The Amateur can see that this would be a bad thing. Children can understand this, why have you rationalized your way into such a ridiculous mental box?
No, it's an example of the power of consistency, which is best obtained by sourcing from a single supplier. I highly doubt these warships had cannons from a variety of manufacturers made to detailed open specifications. More likely, navy smiths made all the cannons themselves, with the same tools and same people each time. In a modern context, it'd mean the navy standardising on one technology from one supplier - ie, Microsoft. Nice try though.
SSL is flawed, at least for the web. Usability studies have shown time and time again that the vast majority of people do not understand and will ignore the bad cert error dialogs. That's a pretty fundamental problem, and why Firefox now makes it really hard to bypass them, but all it's doing is putting a sticking plaster on a bullet wound.
Eh, I have one. It's really not that bad. Anyway, you neglect to mention that the G1 has only been available for 4 months, and in two countries - contrast with the iPhone which has been around since 2007 and has had international presence for much longer.
There are no optimizations in Wine for Office. Office (and IE) start faster than their native equivalents because Microsoft puts a high degree of importance on startup time, and uses sophisticated toolchains to reduce (amongst other things) the number of disk seeks required to bring the app up. OpenOffice doesn't care about this at all, and it shows. Wine imposes some hefty startup overhead itself, yet Word is still faster to start - that should tell you just how far ahead Microsoft is in this department.
Windows uses about as many shared libraries as Linux does, although it has a more efficient design. So you need to look elsewhere for the problem sorry.
Actually he's right but in the wrong direction. On Wine many things that would be pure syscalls on Windows do force a context switch into the wineserver, because the emulated "kernel" is actuall a separate process. For instance opening a file involves an RPC to the wineserver on Wine, whereas it simply switches into kernel mode on Windows and there's no TLB flush overhead. The fact that Firefox is still faster under Wine than native suggests a serious bottleneck somewhere rather than a general problem - if I had to choose, I'd pick text rendering as my first guess.
And for those who wonder where the BeOS team are now, go look at Android - large parts of the Be team went on to continue writing operating systems and nowadays work for the big G. The successor to BeOS is really Android, not Haiku.
It uninstalls itself when the apps it exists to update are uninstalled (you may have to give it a few hours to wake up and realize the apps are gone). No registry hacking needed.
I am not in the PR team here at Google, so this is not an official, accurate answer but I'll do the best I can. If these answers aren't quite accurate, well, tough noogies, it's Slashdot. That said, here are some answers to your questions:
For goodness sake. Am I the only one that likes the Google Updater?
Let's review the benefits it has:
I think people overestimate the resource drain this app has. Really, this should be a core part of Windows. I'd much rather desktop apps behave like web apps and just get silently better instead of expecting me to give a rats ass about the existence of a 0.0.1 point release.
You'd think so wouldn't you. Actually it doesn't work like that.
The first problem with their approach is that they actually implemented the whole OS shell in Python. Now I dunno about the Commodore 64, but I remember the BBC Basic and I can assure you, the OS and most apps were not written in BASIC. They were written in assembler because that was the only way to make non-sucky software. Fast-forward to 2009 and it's the same thing - Python is an awful language to make performant, robust software in. And an operating system shell needs to be both fast and solid. Sugar is neither.
But maybe (maybe) if it was actually feasible for a child to press a key and get exploring, that'd be a price worth paying for the rest. Except it's not. Have you actually read the Sugar code? It's awful. I did a spot-check on this whole claim when Sugar first came out and found it bogus.
I took the Block Party game (seeing as games are what kids like) and looked at the code. The first problem is the code is completely uncommented. Seriously. The only comments are the license boilerplate at the top. The second problem is the code isn't simple like BASIC used to be. It's object-oriented event-handling GUI code that uses containment based layout, multiple libraries, sound servers, uses magic numbers etc. It'd be hard to figure out for an adult, let alone somebody new to programming. There's no 10 PRINT HELLO WORLD 20 GOTO 10 there.
So they managed to make a flaky, incredibly resource intensive environment on the grounds that "it's python and kids will love learning programming by reading python" except the code is crap and impenetrable. Fail.
I work for Google.
I would bet a lot of money that won't happen. Any failure like this one has many sides to it and responsibility will always be distributed over multiple people. The result of this will be a detailed post mortem, better processes, tools, and software, to ensure that something like it does not happen again.
google.com stopped resolving back in 2005 for 15 minutes. Nobody got fired.
OK, good start ...
It's alright, we can let bygones be bygones.
D'oh, you fail it. Employers of the world, don't let cayenne8 near your secretaries.
This executive order is basically the same one that was created post-Watergate to try and ensure Presidential records were published and archived for posterity. Bush revoked it in a widely criticised move, Obamas EO revokes the revocation and is otherwise identically worded, except that it also now covers the Vice President, which can only be an improvement. So basically on day 1 of his new Presidency Obama is already undoing some of the damage Bush caused :)
The following are facts:
C++ only does that if you are trying to pass classes by value, which is almost always a bad idea. I agree it's unintuitive but then a lot of C++ is, you don't lose anything if you simply never pass subclasses by value. If you use references the whole problem disappears.