Symbian Microkernel Finally Goes Open Source 97
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.'"
Re:Maemo (Score:2, Insightful)
I guess it's only an adventure if you happen to have a Nokia device...
Re:Maemo (Score:3, Insightful)
Re:Maemo (Score:2, Insightful)
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:Oh, SyMbian... (Score:3, Insightful)
The first step in the right direction. (Score:2, Insightful)
Re:Symbian (Score:3, Insightful)
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 (Score:5, Insightful)
Thank you, Android (Score:5, Insightful)
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 ?
Re:Maemo (Score:3, Insightful)
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?
Re:Symbian (Score:5, Insightful)
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.
Doing what your customers ask and pay you for is never a bad decision for development. SymbianOS customers being handset manufacturers.
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.
Again, pioneering stuff. The responsiveness of multi-threaded applications without the overhead of multi-threading.
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.
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 (Score:3, Insightful)
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:Market Share (Score:2, Insightful)
Maybe this handy pie chart [wikipedia.org] 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!!
Re:Symbian (Score:3, Insightful)
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.