Hacker News Reader

Comment by BenoitEssiambre | Hacker News Reader

This is probably what Android should have been. I'm not a big fan of the Dalvik virtual machine layer on Android. It does drain device resources, especially RAM. I also think this type of architecture would have allowed convergence with Chrome OS more easily and cleanly.

I wonder if there is space left in the market for another open source OS though. Most people seem to think Android is open enough.

What gives me hope this could succeed is that the Ubuntu desktop is currently the desktop OS that is most user friendly and has the best user experience (IMO). Bringing Ubuntu's design team's superior skills to the mobile platform might give them the edge they need to become relevant in that space. I love my Ubuntu desktop. I really hope this takes off.

View on HN

When Nokia started working on Meego, and Microsoft had plans for WP7, I was hoping Nokia would be smart enough to hurry up and form alliances with other manufacturers to become the defacto alternative to Android for all companies who either didn't want to use Android (RIM, HP, themselves) and companies who wanted a second OS for leverage against Google (Samsung, LG, HTC, etc).

I think they could've done it if they didn't slack off so much with Meego, and were serious about it, but in the same time I also knew Nokia was way too arrogant for their own good back then, and even if they made Meego on time, they probably wouldn't have shared it with others. But that would've been a mistake, because as we can see no OS that depends on one company alone can succeed anymore. Heck, even the ones that depend on several companies are having a very hard time already (WP7/8).

And the reason I would've preferred Meego to become the Android alternative, was because it was also an open source OS, and I would've liked more competition between open source OS's, rather than have just an open source one fight against multiple proprietary ones (iOS, WP, WebOS - at the time).

So I think there may still be time left for Ubuntu to become that alternative to Android, especially if manufacturers stop relying on WP8 and even Windows 8, and start to focus more on Ubuntu phones and Ubuntu laptops instead. But it's very hard to see if it will actually happen, right now, and if it does happen, we won't see it until 2014-2015.

iOS is successful, is anyone making iOS devices other than Apple?

Exactly. That's because the large majority of customers just want a good phone, that works well and does everything it needs to do. My mom, for instance, doesn't care if it's Android, Ubuntu, iOS, whatever. She doesn't care about tech-politics either, or who makes it, how they make it and what partners they have. She only cares that it works, that has a good ecosystem of apps, and that she's happy to have bought it. Meego, WP8, WebOS would have been mainstream if they had achieved this somehow.

Users want a phone that works well and does everything they need it to do as well as being heavily and creatively marketed and praised by the technical elite. There have been several platforms come and go that succeed at the first two parts and fail at the second two. Marketing is in control of the company, approval from the would-be first adopters is much harder. Apple didn't need to work hard to impress people like us with the iPhone; we bought it because it was made by Apple in a time when they could do no wrong in our eyes. Windows Phone, for example, has massively impressed the tech press as a truly different experience compared to Android and iOS but failed to make an impact on the technical elite for one reason or another. WebOS was another "should have been bigger than Android" but we snubbed it due to what we deemed to be inferior hardware (exclusive carriers doesn't mean much when so many switched to AT&T just to get the iPhone even on EDGE).

I use "we" and "our" metaphorically, but I think the point still remains. The iPhone didn't become the defacto standard for the average customer without the approval of people like you and I. Bear in mind, the iPhone didn't have an app store to rely on until mid-2008.

> Apple didn't need to work hard to impress people like us with the iPhone; > we bought it because it was made by Apple in a time when they could do no wrong in our eyes.

Can you really argue that there were no significant technical advantages to the iPhone over phone OSes of the time? The iPhone was first true smartphone, with a workstation grade OS core and top of the line application development framework. By comparison Windows Mobile, Sybmian and Blackberry OS were hopelessly crippled, designed for an older resource-starved generation of hardware, and just couldn't scale. That's aside from the radical touch interface.

> WebOS was another "should have been bigger than Android"

Another myth. WebOS was a cobbled together compromise. Writing all your apps in javascript, running inside a browser session was never going to work efficiently. It was a desperation move to leverage web technologies when their attempt to develop a true native OS framework failed. The constraints of running everything in a browser rendering engine make the constraints of the Dalvik VM look like the freedom of open blue skies in comparison. Forget efficient memory or power management no matter what hardware you throw at it, just look at the battery life stats despite the modest hardware. And before anyone mentions it, no, it was nothing remotely like Firefox OS, which has a radically different architecture.

> The iPhone didn't become the defacto standard for the average customer without the approval of people like you and I. > Bear in mind, the iPhone didn't have an app store to rely on until mid-2008.

The iPhone was successful because it was a pleasure to use, in fact the first phone I ever used I didn't absolutely hate, and because developers flocked to it. By mid-2008 when the app store launched Apple had only sold about 5 million phones. Since then they've sold over 200 million.

>top of the line application development framework

Was this really a big seller of the first iPhones? The ones that came out a year before Apple started allowing native apps? Because before that it was just Javascript and HTML5, similar to WebOS.

>By mid-2008 when the app store launched Apple had only sold about 5 million phones. Since then they've sold over 200 million.

The point is that without the blessing of the metaphorical us, Apple wouldn't have sold 5 million in one year in 2007, and they surely would not have kept selling in even greater numbers. There are many systems just as good or better that have failed because they didn't capture developer mindshare.

>The iPhone was successful because... developers flocked to it

Glad to see we agree.

> There are many systems just as good or better that have failed because they didn't capture developer mindshare.

Ok, I'll bite. What were were these just as good or better systems available at or before the launch of the iPhone?

I'm speaking in generalities, and not just specific to phones. The whole point of my post was that being the best isn't enough, a product also needs great marketing and approval from the technical community. What was just as good or better means nothing now, because hindsight can come up with any number of reasons why the status quo was better than the change required for Product X to take over.

Yes, my point was anyone else but Apple can't do it. And Apple was successful because it was the first mover in such a market. If you try to be like Apple with the 10th OS in the market, you won't succeed, unless you completely change the rules of the game again, and disrupt (not just compete with) both iOS and Android (and the others).

> I'm not a big fan of the Dalvik virtual machine layer on Android.

It provides a processor independent application format. It is obvious now that ARM has won, but not so several years ago. There are many technical benefits to an abstract format including bytecode verification, and the consequent ability to run multiple applications in the same address space because you can't create pointers. JIT/hotspot style execution can also provide better performance than C.

In any event providing a CPU neutral application format isn't a bad decision - others have done it too.

> It does drain device resources, especially RAM.

That claim needs to be substantiated. Is native code significantly denser than bytecode? The mobile vendors have all gone with GC. Mark and sweep style GC has more RAM in play by design than something like reference counting, but there is no requirement that mark/sweep is used - Dalvik could use reference counting. Again there are tradeoffs but calling them a drain seems a large stretch.

> The mobile vendors have all gone with GC.

It's a minor point, but Apple created ARC specifically as a streamlined reference counting alternative to GC, which was never used in iOS and is now deprecated in Mountain Lion.

I do count ARC as a form of GC. The test is if the developer has to manually litter their code with calls to release/free memory.

You do not need to do so in Android (Java), iOS (ObjC), Windows Phone (C#) etc.

These terms have basic meanings that are independent of what you seem to wish they meant. GC is not reference counting, and it would benefit you to put he difference in your memory.

I've always seen "garbage collector" used as a generic term for an automatic memory management system, not a reference to the specific algorithm used to do it. It could be a tracing garbage collector or it could be using reference counting. Where are you getting the definitions that parent would benefit so from committing to his memory?

While some people might say reference counting is just a form of garbage collection, this blurs the useful distinction when discussing the overhead involved. Automatic memory management schemes that impose a variable runtime cost to analyze the object graph are simply totally unlike schemes that have no analysis step and thus no performance headaches. When people talk about GC being unacceptable for real time systems, they are not saying reference counting is unacceptable as well, they are simply saying that any system with a garbage collection phase are unacceptable. So that seems like a pretty clear split.

Reference-counting schemes don't have the same performance headaches as GC's with an analysis step, they have different ones:

* their own form of pause (when the last reference to a large tree of object disappears) -- this can rule out RC for real-time systems, while there are real-time GCs (though rare)

* a non-local memory access per reference creation (whereas in other types of GC, the cost of allocation can be reduced to a single increment and compare of a value probably stored in a register)

* none of the locality advantages of copying/compacting collectors

Personally I tend to see it as down to whether or not the developer is involved (which dovetails nicely with your reference to automatic memory management).

GC can be implemented via reference counting. But in my opinion, if the developer has to explicitly manage reference counting (e.g. by using "smart pointers" explicitly in C++) I tend to see it as distinct from GC.

Garbage collection seems to be a synonym for automatic memory management for many people. Some even see RAII in C++ as GC. I guess GC is so meaningful for many programmers as it is really convenient, that it has become the main word for AMM; as Google is to searching the web.

http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc...

I am aware of the Wikipedia link. It also has no references, and is marked as being original content.

What term should we use to discuss garbage collection schemes that impose a real time overhead (those systems virtually everyone means when they say they dislike GC) and memory management schemes that involve no runtime overhead?

You're right. But on iOS, we still have to think about it a little bit. Maybe not with malloc and free (or retain/release, actually), but in terms of object graph (we can't have "retain cycles", or "strong reference cycles", as they are called in ARC).

It's a minor point and I agree with what you said, but I wanted it addressed in case someone who've not familiar with ARC gets the wrong impression :)

I agree: within the Android ecosystem and even within the ARM family, bytecode provides portability: you don't have to compile and distribute apps for different versions of the ARM architecture.

It's paradoxical however that to increase the portability of certain types of apps across mobile ecosystems, eg. iOS and Android, and now Ubuntu, your best bet can be to write the portable part in native C or C++, bypassing the Dalvik layer using JNI/NDK. This is apparently the common way to make cross-platform mobile games.

On memory consumption: I haven't made any measurements, but the Android .dex bytecode format has been designed with low space requirements in mind. See http://www.youtube.com/watch?v=ptjedOZEXPM . However, all apps run in their own VM process, with lots of common structures shared with them using an initial shared VM process and clever forking.

I always thought one of the main original motivations to use Java was because it's so well spread among developers. Since in the early days before the JIT compiler, there must have been a really obvious overhead even with the interpreter hand-coded in assembly. But they must have wanted to use a well known higher level language with good IDE support etc.

Ubuntu mobile apparently uses Qt: "It uses QML to give you a really slick, easy development experience for native apps with engines in C or C++, and JavaScript for UI glue that isn’t performance critical. We also give you full native OpenGL, which the top games companies are using to make incredible games." It seems actually pretty nice for developers: http://developer.ubuntu.com/get-started/gomobile/

ARM is currently dominating, but Intel has not given up yet. A high-level representation is still a good idea in my opinion.

MIPS is still around on Android, too.

  Ubuntu desktop is currently the desktop OS that is most user friendly and has the best user experience (IMO). Bringing Ubuntu's design team's superior skills

This is debatable.

Reply on news.ycombinator.com