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

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

[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.

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.

Market Share

[SpooForBrains]

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