This browser based app must bring something new to the table to be relevant. My guess is that it will greatly simplify multiple people collaborating on the same project. Solutions already exist but they are not nearly as seamless as they could be. I still remember seeing Smultron for the first time and being very impressed. As far as text editors go, it's nothing special but the ability for several people to edit the same file at the same time was (and still is) impressive.

No one knows exactly how this project will turn out but you can bet Google has their reasons for funding it. I'll take a wait and see approach before passing judgement. It is probably not for me (or you) but will be perfect for others. And if it requires all of these layers to accomplish it's goals then it is not a waste.

I assume there are constraints on continuous battery output for electric vehicles. Batteries will eventually overheat unless specifically designed otherwise. So while the Model S has 416hp available to it, it will only be accessible for a short period of time. Makes passing and accelerating very comfortable but does not necessarily translate to a higher top speed. No doubt this could change with firmware changes and cooling mods.

What is impressive is that the 5s is a dual core 1.3GHz processor while the LG uses a 2.3GHz quad core CPU. The A7 processor appears to be very well designed. I wonder how much power it uses when compared to the snapdragon 800.

I remember attending labs in CompSci only to hear people complain about how the Solaris machines sucked because their compiler had bugs. They would program at home on their x86 Windows box using Visual C++ and then complain when GCC for SPARC didn't like their code. Funny to hear in second year but when you hear it in 4th year it becomes a little disturbing.

This served as an excellent example as to why cross-platform code is almost always better. If code can not compile on a different platform then there is something wrong with your code and it should be fixed.

There is no way to support enforcement without mandatory licensing. And in regards to the bike advocacy groups, they all shame the bad apples. But you have to understand that they were established for other reasons so shaming the bad apples will not be their priority.

A solution to this problem would be to require licensing for those who want to ride on bike lanes located on public streets. Licensing not required in parks, sidewalks, or off road - only when biking with traffic on specified bike lanes.

The license requirement would guarantee that everyone at least knows the rules of the road. They would know exactly how they are supposed to behave and how they are expected to interact with drivers. Proper lighting can then be mandated along with safety gear (helmets*). Those "bad apples" can be ticketed just like a driver would be - a few police "bike lane checks" and those bikers will change their ways in no time.

Riding on existing roads should not require a license so the impact would initially be minimal. But as infrastructure is updated and more bike lanes are created, the improved infrastructure along with more law abiding cyclists will help generate an atmosphere with drivers that makes cycling safer and more attractive to new cyclists. In the end, everyone wins.

*helmets - In BC, all cyclists require helmets by law - unless you wear a turban. I hate this law because it affects far more people then it should. Limit it to bike lanes I say...

This is true if you are talking about a 100" screen. On a 9.7" screen the issue is mute.

If you want to be able to ask someone for help then it would be best to use the same tools they use. The point is that any programming language will work. Some languages are easier then others but the difference is negligible compared to the advantage of being able to ask your piers for assistance.

I would say you are being way too optimistic. We are still at the stage where we are trying to prove the theory can be made real. Have not even thought about designing a usable reactor nor do we know how big such a reactor would be. All we know for sure is that it will be so bloody expensive that failure is not an option - which is why there are doing these far cheaper tests.

In the initial stages the iPhone was hidden from most Apple employees. Even those that worked specific parts of the software design would not know how it was supposed to come together. To bring all the employees inline with development would inevitably result in the design being leaked before the big announcement. As it stands, rumors of it existed but people only had basic ideas of how it might look and operate.

The final announcement greatly preceded the launch - something that is very rare for Apple. You can bet it was announced early partly so that Apple could bring in more employees and distribute prototypes without spoiling the presentation. But you are quite right in that 6 months is not much time to get if working right. But considering how inflexible the first version of the OS was, not impossible.

8MB is plenty for a compressed Linux distro such as OpenWRT. The availability of an SD slot makes the limited memory irrelevant. It has enough to boot even when an SD is not present. And assuming they are using high speed FLASH on a parallel bus -- booting will be much faster then if booting directly from the SD.

Does it not make more sense to use clean, filtered water to transfer the heat out into the ocean? The heat exchanger can sit in the ocean to facilitate removing heat without the worry of having jellyfish clogging filters. Effective cooling capacity might be reduced without an active water stream going over the heat exchanger, but this can be compensated for by using a larger one.

The only possible problem I can see is the build-up of aquatic life on the head exchanger. They would require periodic cleaning. But unlike filters, you would not have to shut down the cooling system to do so. In addition, you don't have to worry about there being any sudden changes in the cooling capacity of the system so it should be much easier to plan and perform the cleaning.

It was reported that Apple works is a similar fashion - small groups of engineers working on specific projects. When you bring too many engineers in on a project the management overhead becomes immense. The difference was likely with the quality and style of management. The fact that Jobs was a control freak, semi-tech savvy, and personally interested in the products likely worked in Apple's favor. No bickering between different divisions of management when they know Jobs will send them packing - being the ass he reportedly could be. RIMs downfall likely comes down to poor coordination between different sections of management. They had plenty of good engineers at their disposal, but they were not utilized correctly.

One has to give Jobs some credit - he was obviously not in it for money or politics, he wanted to make stuff he thought was great. (And fortunately for Apple, other people also shared in his sense of style.) This differs from other CEOs I've read about in that they appear to be more interested in playing politics to their own benefit. They don't appear to be interested in making anything let alone doing what is best for the company. The next quarter stock price - that is the only thing that is important. (But one tends to only hear about the bad ones so this is probably is not an accurate generalization - although reading SlashDot sure gives one this impression.)

The new AMD flat memory model for GPU / CPU is very interesting. I assume this is what will be used in the upcoming consoles. But you have to realize that the console and PC markets are currently being crushed by the newly created portable market (Android / iOS). The larger market of iOS users combined with the App Store model that limits piracy has game developers making more money with their stupid little Apps then they do with their much more impressive console games. The Android market is also growing and, despite being limited by piracy, will eventually catch up with regards to developer profits.

AMD looks like it's making some impressive products when it comes to GPU / CPU integration. If they could catch up to Intel fabs (now at 14nm) they would be doing great in the market. They might also bring their flat memory model to mobile ARM CPU/GPU chips which would be quite interesting. But the reality is that AMD is not going to dominate the market anytime soon. Those who think otherwise have been drinking too much AMD Koolaid. These changes take time and we don't even know how Intel / Nvidia plan on responding - and they will respond.

Filtering should be performed by the client so there is no uploading of personal data. The server must send clients the filters for various different alert types. The user would then have the option of editing the filters should they not like the default values.

I'm with you on that one.

Alerts are fine so long as filters can be applied to minimize the number of people that receive them. For example, GPS coordinates could be effective at limiting the number of recipients. Add to that accelerometer data to determine if the person is moving or possibly asleep - also helpful.

Alerts must be minimized or else people will start ignoring them. It is similar to how people would just click "Allow" whenever Vista prompted them with a security warning - most people would not even read the message after seeing so many prompts. So use some intelligent filters along with sensor data to minimize the number of alerts or risk all alerts being ignored.