Submitted by Ahead of schedule, the Symbian Foundation has released the source code to Symbian’s EKA2 real-time, multitasking, SMP microkernel, under the Eclipse Public License. It comes with a complete development kit, free of charge. The Foundation’s plan is to open up the entire platform, and this is of course a very important milestone in that process.
The Foundation claims that the opening up of the kernel source code is nine months ahead of schedule, which is pretty awesome. Sixteen our of the 134 platform packages have now had their source code opened up; this process started in April 2009 under guidance of the Symbian Foundation.
“The release of the microkernel demonstrates three vital, guiding principles of the foundation: first, the commitment of many community members to the development of the platform – in this case, Accenture, ARM, Nokia and Texas Instruments Incorporated all made contributions; second, progress in fulfilling our commitment to a complete open source release of Symbian; and third, a tangible example of providing the most advanced mobile platform in the world,” said Lee Williams, Executive Director of the Symbian Foundation, in the press release.
The kit includes the following items:
- Open source kernel and other complementary packages
- High performance ARM compiler toolchain (RVCT4.0): free to developers and companies of less than 20 employees
- Open source simulation environment based on QEMU
- Open source base support package for the low cost Beagle Board
- Supporting binaries
- Hardware execution environment
You all know what this means, right? Not only is the smartphone market a very competitive one, with several different offerings competing with one another, but it is also almost completely open source.
Well, the kernels, that is. Android and webOS are based on Linux, Symbian’s is open too now, and Windows Phone is based on Windows CE, and the Windows CE code is available under one of those semi-open initiatives that allow you to look at and sightly modify the code. The iPhone is of course built on top of Darwin, which is open source too. I believe that of the major players, only RIM is lagging behind – the BlackBerryOS is still fully closed.
Rather surprising, isn’t it? Symbian owns about 50% of the smartphone space, and now it’s got a fully open source kernel. Who would’ve thought that the mobile space was where open source would really take off.
Though the OS is open sourced the drivers aren’t. If the devs could also get the drivers as part of the package, it would be of great use. I for one would like to be able to replace the crap Samsung Symbian firmware on the i8910.
Unlike Nokia phones, there are some “cooked ROMs” for the i8910HD already. I think it’s because of the more openly available bootloader and flashing tools.
See here for an example: http://bit.ly/2aC2WQ
Edited 2009-10-23 20:04 UTC
These ROMs are merely mods. I would like to add a better keyboard and a missing mini qwerty implementation. Without the drivers released it would be very hard for custom firmwares to work reliably on the device.
Hell freezes over when Nokia and Samsung release their telephony layer and other drivers.
i think symbian sucks, but the more open source code, the merrier
Hi there,
Feel free to come over to http://developer.symbian.org in the forums and tell us why we suck as we are listening to people in setting our roadmaps. We are open in process as well as open in code.
Ian McDonald, Head of IT, Symbian Foundation
It’s nice to see progress in the whole “moving to open source” thing. ATM, Symbian is really lagging as a platform, but with the move to open source and the shift to Qt for app development, things just might pick up for it.
Symbian is the most advanced OS for mobile hardware today. Maemo is cool but it has a long way to go before it reaches the level of Symbian. It doesn’t even support J2ME yet. Android does but it is still not up to the level of Symbian. Now that Symbian is Open source, it raises the bar even higher; The FSF even consider the Eclipse license to be free.
Yeah and pigs fly. Seriously Symbian OS is probaply one of the worst around, it’s memory management has been joke for ages since any program can crash whole phone like Windows 95. It was one of the poorliest documented for long time, probaply still is, so coders hit walls all time and made crap.
It has been mostly designed and coded by company that had experience on rubber boots before starting it and it shows. The plain fact is that Symbian OS is relic that even Nokia is planning to let go in future since they just can’t get it work on modern smartphones. This is why Maemo will be future OS of Nokia smartphones ones it matures bit more.
I see this move more an outcry for better support, they want to see if enough people are intrested on moving Symbian OS since they aren’t. Oh and before you call me fanboy of some other group I own almost 10 Nokia phones and they are probaply best phones in world for texting and calling but doing anything modern is just masochistic.
I don’t have any problem with Symbian, it works well and its fast even do I multi-task a lot, and no program has ever crashed.
But its good that they move to Maemo 5 and 6, its more powerful and modern. I would say that Maemo is pretty mature the first version came out 2005.
I will buy probably the N900 as my next phone, as I have seen it in action.
And the J2ME is useless it already support real Java.
Right, but what you call the real java (J2SE I suppose) does not support mobile features like SMS, bluetooth, GSM, 3G, touchscreens and so on. J2ME is what you want on a mobile.
I don’t think they use Java for those functions, in high-end segment. Java is just for apps.
They use Jalimo JVM and probably J2SE
I didn’t mean that they use J2ME for sending SMS. I meand that J2ME apps can send SMS. You can’t send SMS with J2SE. You could add all the J2ME libraries into J2SE but then J2SE would become J2ME. With J2ME, you can send SMS, use bluetooth and do everything you need on a mobile. With J2SE, you can’t.
Have you checked on Android yet?
It’s a modern Java environment with telephony APIs all around, without being as retarded as Java ME. I dare say even Symbian’s only advantage over it is that the apps are running natively.
I don’t get it. What is so wrong about J2ME? People keep bad mouthing J2ME but I’ve seen no argument against it yet. J2ME is java with mobile dedicated libraries. It’s a standard set of libraries with MIDP profiles. The main advantage of J2ME over J2SE is that you are guaranteed to have access to the libraries you need on the mobile on most systems and hardware. You can’t argue that is is less modern than J2SE, it was created years after J2SE. Also, running applications natively is a bad idea on the mobile phone in my opinion. First off, ARM processors implement jazelle so java is run in hardware. Java is secure as it makes sure your application does not crash the phone or do nasty things your don’t want it to do. I really don’t see what you can’t do with java that you can do natively.
Anyway, Android is really nice and I like it, but it has the same problem as Maemo: it doesn’t scale to small devices (yet). It’s nice for touchscreen phones for people who need a PDA and a GPS, but for 99% of the people who want something that they can put in their pocket along with their keys, something small and reliable that can make phone calls, send SMS, take pictures and run apps, for those people Android is still not ready.
I’m glad you asked…
1) There’s the MIDP standard, but it’s vague in many places, and leaves a lot of free space to the manufacturers. Therefore the resulting system is horribly inconsistent, while the standard and the marketing says that you get the same environment on all of the compliant phones, that’s far from the truth.
Example 1: the PIM API. An implementation is compliant to the standard if it implements at least one of the following interfaces: ContactList, EventList, ToDoList. It doesn’t have to do all of them, and doesn’t have to be correct, or in any way connected to the phone’s internal applications!
Example 2: the UI. Some Sony-Ericsson low-end phone supports MIDP2, but behaves erratically when using a secure TextField. It’s insane.
Sidenote: IIRC, there was an interview with the staff working on Opera Mini, and they noted that in order to support every phone out there, they have to test the software on every single phone.
2) It’s Java 1.3 for god’s sake! I don’t know about you, but I really enjoy boxing and generic classes (as opposed to casting all the time). And there’s no double support, even if today’s phones are getting FPUs built in… (Okay, not Nokias).
3) Retarded permission system. It’s bad for the user (“why is this POS asking me all the time?!)” and the developer alike.
4) It’s nowhere near native code in performance, neither in capabilities. I could go into examples again, but my post is getting long and boring.
5) You can’t know if the Jazelle is actually used. It’s up to the virtual machine’s implementors, which most of us has no insight on. It’s supposed to be transparent by design.
I think this is enough for one round. Java ME is for simple phones (which you adore as your other comments suggest), for simple games and simple applications.
Edited 2009-10-24 16:35 UTC
Well, I agree native applications have their place, but for all its shortcomings, there is nothing as portable as J2ME. And frankly, 95% of apps do not need more than what J2ME offers. I don’t know about you, but a quick look at all the apps people around me use on their phone run fine or could run fine with J2ME. It has many advantages over native apps, the first being binary portability, which is no small advantage when you see the status of the phone market.
Edited 2009-10-24 17:20 UTC
Judging by the success of iPhone, binary compatibility is not all that big a deal.
Come on, I’m sure you love the iPhone and it’s a nice phone, but try to think beyond that. The iPhone is popular and I’m sure almost 1% of the mobiles are iPhones. But as a developer, can you afford to ignore 99% of your potential customers? When you take into account the rest of the world that revolves around the iPhone, it looks like a very small niche actually.
Did you actually read my post?
And you seem to be ignoring one thing: just because MIDP2 is available on 99% of the phone, they aren’t potential customers!
It’s confusing because this was not a reply to your post.
I honestly think the future of CLDC/MIDP is, in the long run, a dead end. JavaFX Mobile will not be supported on it AFAIK, it will only on CDC-capable (i.e. Smartphones and Set-top-box) devices. And within a few years every device will be so capable from a hardware perspective that CLDC will be rendered unnecessary.
(For those who don’t know what I’m talking about, take a look at the diagram of Java platforms in this link:)
http://java.sun.com/javame/technology/index.jsp
Of course there are still *way* more apps out right now targeted at MIDP than at CDC, and MIDP’s shininess and ease of use is getting a major boost from the Lightweight UI Toolkit project:
http://java.sun.com/developer/technicalArticles/javame/lwuit_intro/
But I think that in the next few years the smartphone segment will overtake the feature phone segment, to the point where 90% of phones are smartphones (and run at minimum Symbian, Windows Mobile, Android, or some other form of mobile Linux). These devices might still support MIDP, but it will no longer be the cutting edge. With CDC or maybe even SE available on these mobile devices, developers will have no reason to constrain themselves to the lowest common denominator anymore.
Edited 2009-10-25 10:30 UTC
Well, I don’t see it like that. It’s not about constraints, but about what your application need to function. For instance, if you are doing a calculator there is really no reason why you would not want it to work on 99% of the phones. I believe the real question to ask is this one: What does my application need and on which CDC/CLDC/MIDP/JSR is it available? If you are doing a calculator, then MIDP 1.0 is fine. If your calculator need 3D effects, then you must add JSR 184, OpenGL ES or regular OpenGL, depending on how you want to di it.
This statement is just dumb. Symbian was based on EPOC, which was developed by Psion, a highly innovative and forward-thinking mobile device manufacturer. At the time EPOC came out (1997), the 32-bit, multi-threaded, object-oriented platform it offered was cutting edge. Also, Nokia had had years of experience making some of the best, most useable mobile phones out there before they started working on Symbian (with help from Psion).
Of course you are right, as EPOC32’s history goes back to 1997, but then by that measure the current versions of Linux, Windows and Mac OS X are even bigger relics, since the origins of their codebases are all significantly older. The best comparison to Symbian is Windows Mobile, as the first version of Windows CE was released at around the same time as the first version of EPOC32.
Admittedly both Symbian and Windows Mobile are hampered by the fact that they were designed at a time when 1GHz CPUs, powerful 3D graphics, gobs of memory, and multitouch on a mobile device were unthinkable. So of course they have a disadvantage in some respects. However, I don’t think this means they are beyond hope, especially as in the case of Symbian, Qt will become the top-level API.
Edited 2009-10-24 08:57 UTC
Nokia has been involved in telecommunication since the 60-70’s, and their past as conglomerate is irrelevant as most large companies in Finland has during most of the 90’s been a conglomerate.
I find Symbian to be pretty cutting edge still today, and much of the short comings will be dealt with in next release.
I don’t care about RAM, graphics, memory or multitouch, but Symbian did suffer a lot because of the “if it’s not broken, don’t fix it attitude”, that left us with a crappy development environment and libraries.
I think almost every developer feels a sense of “yuck” when having to work with Symbian, at least for initial 4 years. After that, it’s a smoother ride, as you’ll have developed a certain cynical apathy that takes off some of the edge.
That being said, Qt will fix most of that. Now they just need to remove the slow emulator (as opposed to Maemo, where you can just run the whole thing on Linux inside scratchbox & xephyr).
I’m not an expert in this area – there are lots of experts on forums at http://developer.symbian.org but we are working hard on improving the developer experience.
You can use almost standard C++ now and QEMU for debugging. See:
http://developer.symbian.org/wiki/index.php/Open_C_and_Open_C%2…
http://developer.symbian.org/wiki/index.php/SYBORG/QEMU
Keep watching our site as there is a whole lot of stuff coming in the next week as we have our main announcements at SEE 09 trade show.
Debugging what, exactly?
How is QEMU going to help us, current S60 developers, working on today’s phones?
Right, it’s not perfect, but which OS is better than Symbian for mobiles right now? Don’t tell me Maemo. Maemo is promizing and I really like it, but it’s not as mature and feature full as Symbian RIGHT NOW. The UI is not designed for and not usable on small screens right now. It does not scale well, although I’m pretty sure it will. It’s nice for big smart phones though, but most people want their mobile device to be small.
Edited 2009-10-24 10:55 UTC
While it might be nice to have more open source software, I don’t think people will in general benefit from it.
The moment you buy your symbian phone today is about as current as your firmware will get. I think in 99% of the cases, there aren’t any major updates for the phone owners.
Take e.g. the E71. The E71x has the same hardware and has S60 3rd edition feature pack 2. The E71 only has feature pack 1.
So while the software seems to exist and the hardware is exactly the same, I don’t see the new features of FP2 ever coming to my regular E71…
Open Source is fine, but actually having the firmware not only “fixed” but actually updated would be a great thing
Let’s face it.
A proprietary software product being open sourced after a long time typically indicates that it is at the end of its life cycle.
Usually they take this step at too late a point in time for it to breathe new life into the product.
Will be interesting to see what happens here.