Symbian Microkernel Finally Goes Open Source

ruphus13 writes "Symbian announced over a year ago that they were going to Open Source their code, and the industry has been patiently waiting for that to happen. Well, it finally has. According to news on Wednesday, 'Symbian has released its platform microkernel and software development kit as open source under the Eclipse Public License. The Symbian Foundation claims that it is moving quickly toward an open source model, which is questionable, but the release of the EKA2 kernel is a signal that Symbian still means business about adopting an open source model. Accenture, ARM, Nokia and Texas Instruments contributed software to the microkernel, Symbian officials said.'"

Comments

Maemo

[tsa]

But why would people want to develop software for Symbian now that there is Maemo? Maemo is much more of an adventure because it's new.

Re:Maemo

[BrokenHalo]

Maemo is much more of an adventure because it's new.

I guess it's only an adventure if you happen to have a Nokia device... :-|

Re:Maemo

[palegray.net]

Many people don't equate [adventure, new] with [proven, stable].

Re:Maemo

[Anonymous Coward]

How about because the hundred of millions of Symbian (uiq/s60/DoCoMo) devices are not going to disappear? Plus there is always a market for proven robust technologies such as this. Maemo will be important to Nokia but the bulk of sales will still be Symbian powered. There is even the possibility that S40 will be relegated to the rubbish bin and supplanted by whatever the Symbian Foundation releases.

Re:Maemo

[TheBishop]

But why would people want to develop software for Symbian now that there is Maemo?

Maemo's been out for years (N700, N800, N810, N810WIMAX) and nobody decided to develop anything of worth for it yet, why would they start now?

Oh, SyMbian...

[Dahamma]

Damn, at first I thought it was the *Sybian* microkernel... now THAT would be a fun kernel to hack...

Re:Oh, SyMbian...

[Anonymous Coward]

This joke is getting OLD!

Symbian

[QuoteMstr]

Ever look at a system and think to yourself, "every time the developers had a choice in designing this thing, they chose the wrong option"? I can think of a couple. Symbian is definitely in that class. It has:

• Drive letters. Enough said.
• Backslashes as directory separators
• Pervasive DRM, with code signing and a pay-us-to-access-more-OS-features capability model
• A bizarre and perplexing C++ API based on manual exception management, with too many kinds of string class to count
• "Active objects"
• Non-POSIX filesystem semantics
• A microkernel architecture for devices least able to afford the overhead
• Very strange application deployment consisting of several disparate directories with magical names

All in all, the sooner Symbian dies, the better off I am. I might have been slightly kinder if they hadn't tried to prevent my running my own code on my own machine. No, I'm never getting another Symbian device.

Re:Symbian

[walshy007]

being the owner of a nokia n95 (s60 symbian) I am puzzled at how you can not run your own code.. when running unsigned code it just tells me "warning: blah is not signed" just like ssh warns me when a key is changed or some such. Then I can install it anyway.

I have not yet found any kind of drm in the phone.. at all. I install what I like from wherever I like and it just works.

The rest of your post can be summaried as "it's different from unix, so I don't like it" which is your opinion to have, but it is an opinion. I agree having everything be like linux/bsd etc would make life as a developer a lot easier, nothing new to learn.

Re:Symbian

[RAMMS EIN]

``A microkernel architecture for devices least able to afford the overhead'' What overhead? The way I understand it, the overhead typically associated with microkernels comes two sources: overhead incurred when transferring control across process boundaries and inefficiency of the implementation. Inefficiency of the implementation (e.g. using a complex message-passing system that consumes many CPU cycles) is a problem, but it's not intrinsic to microkernels. Overhead incurred when transferring control across process boundaries depends on many factors, such as what your OS's idea of "process" is, how this is mapped to the constructs provided by the hardware, and how efficient the hardware implementation is. Long story short, implementing processes as tasks on x86 hardware and using the MMU to separate processes' address spaces is very inefficient. An implementation on an MMU-less system with an ARM CPU and all processes in the same address space would not be nearly as inefficient. In fact, on an ARM CPU, even with an MMU and processes in separate address spaces, one study (PDF) has measured the context switching overhead of Linux to be up to 0.25%. If Linux can do that, a microkernel can, too. Now, I don't know about you, but 0.25% isn't enough to keep me awake with worry all night. All in all, I think the reputation that microkernels have for introducing a lot of overhead is simply due to inefficient implementations on inefficient hardware. I also wonder how much kernel efficiency still matters these days; it seems that most programs seem to fall in one of 3 categories: 1) mostly sitting idle waiting for input (user input, disk reads, memory access) 2) bound mostly by the speed of the graphics card 3) spending most of their CPU cycles in their own code or libraries. System call overhead has little impact on these programs ...

Re:Symbian

[zullnero]

I kinda agree. From an outside perspective, Symbian is conceptually a solid concept...but once you hunker down and try to do something for it, you find yourself pulling your hair out non-stop. I also have to say, at the time when the Symbian guys came up with them, Active Objects were a pretty cool idea. No one else was doing stuff like that for mobile devices, and if it had been done less insanely, it really would have been like buffed up widgets.

Yeah, it has a goofy API. I totally agree. But I can work with it, and get stuff done...that's fine. I don't mind the microkernel...if you write your code reasonably efficiently, you can deal with that. Memory management, while necessary to make that code efficient, is clumsy and annoying. I didn't really run into the "pay for more access" nonsense, though I certainly hated that sort of stuff about Brew, too. But once you've been stuck jumping over all those hurdles, you never want to deal with it again. A smart company, designing a platform, should put third party developers above everything. Making your platform easy to develop for should always take precedence over anything else, no matter how much temptation it is to try and nickel and dime developers in order to farm cash flow out of them. The more hurdles you put up, the less chance your OS will compete in the application market, and that generates the demand that makes the carriers interested in putting your OS on their phones.

I can think of a number of OS's offhand that greatly outlived their lifetime expectations simply because they're easy to develop for and the toolchain is flexible (and free). I have Symbian development on my resume...even though it's obviously been 5 years since I did it seriously, I still get headhunters contacting me non-stop from all over the place simply because, and no offense if someone reading this does like Symbian development, it's a big time headache to deal with.

Making it open source isn't going to save it. There are too many far better mobile options out there already. webOS, Android, and Moblin are already built on open source, reasonably standardized platforms. There are more on the way. No one is going to want to fight with Symbian weirdness and 1990's style C++ when they could be doing AJAX on webOS or Java on Android.

Re:Symbian

[BasilBrush]

Drive letters. Enough said.
Backslashes as directory separators
Non-POSIX filesystem semantics

In other words, standard FAT file path conventions. The most used file system in the world. As used by about 90% of people's desktop computers.

Pervasive DRM, with code signing and a pay-us-to-access-more-OS-features capability model

Doing what your customers ask and pay you for is never a bad decision for development. SymbianOS customers being handset manufacturers.

A bizarre and perplexing C++ API based on manual exception management, with too many kinds of string class to count

Symbian exceptions predated the introduction of exceptions to C++. So it wasn;t a choice not to go with the standard, rather that Symbian was a pioneer. Symbian does have several descriptor classes, and that is confusing. But they are there for reasons of memory efficiency on what were devices with tiny memories. Properly written Symbian code will do string storage and manipulation with less memory than any other API I know.

"Active objects"

Again, pioneering stuff. The responsiveness of multi-threaded applications without the overhead of multi-threading.

A microkernel architecture for devices least able to afford the overhead

Symbian was originally written for a device with 16Mhz ARM chip. If a microkernal was OK for that, it's OK for the far more beefy specs of today's smartphones. The problem isn't with the reality of Symbian OS, it's with your entirely imagined notion of what the requirements of a microkernel are. It's a microkernel chiefly because embedded devices such as phones have to run reliably for long period of time. That's more important than marginal speed differences.

Very strange application deployment consisting of several disparate directories with magical names

Strange = different from what you're used to.

You complaints are a mixture of not knowing the perfectly sound reasons for engineering design decisions, and your arbitrary view that Unix is the one true way.

Re:Symbian

[drinkypoo]

hahaha moblin *snort* Moblin is designed to work only on intel devices, so most of their customization has been ripping out other stuff, and cramming in intel drivers. In order to expand moblin's popularity you'd have to undo most of what intel has done. Meanwhile you'll be able to slap their same interface on top of UNR (or possibly onto the OpenGL ES-based Android, using the NDK... but be prepared to build a lot of drivers) and certainly by using Angstrom... if you can get it to build, ha ha. OpenEmbedded my ass. Er, wait... Android is probably the most credible thing going right now, and the fact that it's a big slow on PCs right now is not too relevant because it's fast on OMAPs and that's where the magic is happening right now. People can afford a cellphone, especially if they don't have to pay up front :)

Re:Symbian

[npsimons]

Drive letters. Enough said.
Backslashes as directory separators
Non-POSIX filesystem semantics

In other words, standard FAT file path conventions. The most used file system in the world. As used by about 90% of people's desktop computers.

Damn, I'm out of mod points, otherwise I'd have modded you troll and moved on. Suffice to say, the idiocy of this first line alone is all I'm willing to deal with, so I will attempt to enlighten you, then move on.

Do you even know WTF you're talking about? Have you ever actually *written* any software that opens files? I mean, yeah, FAT is very widespread, used everywhere. But last I checked, none of Linux, FreeBSD, NetBSD, OpenBSD, VxWorks or MacOSX (to name just a few OSes that have FATFS support) have drive letters or backslashes as directory separators. They also all support POSIX file semantics, even on FATFS. Drive letters, backslashes and non-POSIX filesystem semantics are *NOT* FAT file path conventions. To anyone who has ever even dabbled in system administration or programming on systems that have these "features" it is obvious what they are: bad design decisions that are only being held onto because of backwards compatibility.

Is this in time to actually matter?

[Shag]

WebOS, Android and iPhone OS look to be fixin' to eat Symbian's lunch... will open-sourcing things make a difference?

The first step in the right direction.

[Comp_Lex86]

Now people can rewrite the entire OS in "normal" C++ without all the awkward stuff like Active Objects, 10000 kinds of string "descriptors", CleanupStack and the weird API.

Reality check

[sznupi]

- Symbian chips on slighly more than half of smartphones (which is another way of saying "it ships more devices than all other players combined")
- vast majority of phones sold all over the world aren't smartphones, but feature phones (for example with Nokia S30 or S40)
- Nokia seems to be pushing Symbian into the place of S40 (I guess Maemo wil be at the top)

Symbian isn't going anywhere. It will grow bigtime. Out of OSes you list only Android, IMHO, has similar potential (it also seems to be coming to cheap devices). They won't even really have to compete with each other, with such huge market for the taking.

Re:Maemo (QT)

[GNious]

If I understand correctly, developing for Maemo or Symbian doesn't exclude developing for the other platform - QT should exist on both platforms soon, allowing you to target both fairly trivially. /G

Symbian's Kernel has it where it counts

[thaig]

I am biased because I worked for Symbian and now Nokia. What I say is entirely my personal opinion.

There's a lot to be dissatisfied with in Symbian but the kernel is good. It works on a lot of different hardware and is very economical with power. It's also extremely reliable. For all that it is a microkernel-based OS, it needs very little in the way of hardware It isn't like Linux or Darwin because they were originally made under the assumption of all sorts of nice things like having a power socket all the time. They catch up but they aren't there yet.

It's also written in pretty simple C++ without the warts that the user-side APIs. Since the user-side stuff is being supplanted by QT and the STL I think that there is hope there. It's also getting some fairly serious SMP support which is well suited to the mobile world (having more less powerful CPUs is good for power consumption if you can switch them on and off).

I work on another thing that's about to be open sourced and I must be a good boy and wait for the SEE next week (what used to be the Smartphone show) before talking about it. But a lot is being done and by people who are just as unhappy or more so about the status quo.

It will be interesting to see how other OSes fare when they try to tackle the problems associated with scale and numbers of different models.

BTW, I use Linux on my desktop and I am a big fan of it.

Thank you, Android

[obarthelemy]

This issue is clearly being pushed forward by open-source Android. Smarter - and, maybe, weaker- competitors realize they must match Android's flexibility and openness.

Windows Mobile will either have to offer an extremely compelling experience, Apple-like, or will be FOSSed into oblivion ? I'm taking bets, but only one way ^^

Dream scenario: Smartphones -> Tablets/ebooks -> Netbooks -> PCs.

Well, in the long run S60 it probably not the one to do that. But Maemo or Android, in a "bigger" version ?

Market Share

[SpooForBrains]

Maybe this handy pie chart will enlighten you. Hint: Maemo is in the grey slice.

Re:Market Share

[hercubus]

Maybe this handy pie chart will enlighten you. Hint: Maemo is in the grey slice.

Symbian phones belong in a "Not-that-smart-phone" category separate from the newer platforms. Sure, it was a great platform and is still useful, but it's legacy. We all know how newly-minted developers feel about legacy: junk/cruft/bloat -- throw it all away and build something new!!