Symbian Source Code(github.com)
github.com
Symbian Source Code
https://github.com/SymbianSource
198 comments
One of my colleagues in Nokia Research Center actually created and maintained the python port to symbian. He was dealing with some crazy stuff. NRC actually ported quite a bit of oss to Symbian. You could actually run a webserver on the device which you could share to the internet with a reverse proxy. So, you could host your own photos from your device or use it as a webcam. Php, apache, mysql were part of this effort if I remember correctly. Another team in the same lab was responsible for porting Webkit to Symbian. This actually shipped when the iphone was nothing but a rumor. Ajax websites running on a smart phone. In 2005 when Ajax was still a new thing. Amazing stuff.
Of course all of this was labelled as research and wasn't taken too serious by the business units until it was too late. A pity, because a lot of the stuff that NRC produced wasn't bad. There was a thing called friendview that existed before foursquare was a thing where you could share your location on a map with friends. The team that did that also did another app that allowed people to share photos. Instagram was not a thing yet back then. Another team was doing a thing called sports tracker. These were tiny teams doing amazing things. Sports tracker basically was allowed to take their software outside of Nokia and create a company around it. Nokia shipped a lot of stuff like this via Nokia Betalabs. A lot of that stuff came from teams in Nokia Research Center.
Of course all of this was labelled as research and wasn't taken too serious by the business units until it was too late. A pity, because a lot of the stuff that NRC produced wasn't bad. There was a thing called friendview that existed before foursquare was a thing where you could share your location on a map with friends. The team that did that also did another app that allowed people to share photos. Instagram was not a thing yet back then. Another team was doing a thing called sports tracker. These were tiny teams doing amazing things. Sports tracker basically was allowed to take their software outside of Nokia and create a company around it. Nokia shipped a lot of stuff like this via Nokia Betalabs. A lot of that stuff came from teams in Nokia Research Center.
I was working on the mobile web server project. The project was heavily subcontracted to a company in Oulu, Finland, where I worked by the time before starting a career in open source and Python consultancy. Mobile web server was a Series 60 web server, based on Apache, some glue and reverse proxy gateway (written in Java). You could deploy your own “apps” that could be accessed by anyone, running on your mobile phone.
Unfortunely, the project did not have a real business use case. People believed that peer-to-peer is a thing (XMPP, BitTorrent, IRC) and this would drive mobile-to-mobile interactions. Unfortunately, it turned out not to be true.
Later me and my friend ported Python to Series 60 with our own rewrite, as Nokia’s official port had many issues. Unfortunately by this time Series 60 was already losing market share for iPhone and Android. Furthermore we found that because of module import delay, Python will never be a good run-time for mobile applications, unless you do some sort of a binary dump/prewarmed up interpreter.
Unfortunely, the project did not have a real business use case. People believed that peer-to-peer is a thing (XMPP, BitTorrent, IRC) and this would drive mobile-to-mobile interactions. Unfortunately, it turned out not to be true.
Later me and my friend ported Python to Series 60 with our own rewrite, as Nokia’s official port had many issues. Unfortunately by this time Series 60 was already losing market share for iPhone and Android. Furthermore we found that because of module import delay, Python will never be a good run-time for mobile applications, unless you do some sort of a binary dump/prewarmed up interpreter.
Binary dump / prewarmed up Python interpreter would be amazing even today. Could enable a lot use cases with Python.
youtube-dl/yt-dlp (Python) is a full second slower than youtubedr (Go) or youtube.com (JS) to download YouTube videos, and I think a lot of that is due to interpreter warmup (though I don't know exactly why). Sadly mpv only supports youtube-dl/yt-dlp for watching videos, and youtubedr doesn't have the vast plugin ecosystem of yt-dlp for non-YouTube websites.
The above mentioned Python’s import delay. This is a notorious behavior in high performance situation (including your cli startup time example). Essentially the import process is IO intensive. This comes up in massive parallel applications as at launch each process is importing the same stuffs. It is briefly mentioned for example in https://docs.nersc.gov/development/languages/python/
If you really care about the startup time, you could pre-compile it. Nuitka and Cython could do this with different limitations.
If you really care about the startup time, you could pre-compile it. Nuitka and Cython could do this with different limitations.
I've run into the import issue as well, it's especially painful if something imported is doing work using a slow library (e.g. a config module loading a HOCON config using pyhocon a.k.a slowasmolasseshocon)
That will be another slow down happening at import stage. But even if ideally everything you import only does import with not much work, the import overhead mentioned above still exists. But frankly I’m not sure how significant it is on a typical personal computer with SSD, especially when the OS may cache recently used files already.
The problem you mention can be significant because some design patterns in Python encourages this. Eg function arg with a default that’s expensive. Unfortunately this whole speeds up repeatedly calling the func, the cost is paid at first import.
The problem you mention can be significant because some design patterns in Python encourages this. Eg function arg with a default that’s expensive. Unfortunately this whole speeds up repeatedly calling the func, the cost is paid at first import.
Unless your 1) execution environment (CPU, dlls) or 2) Python source code files change, you can use “unexec” strategies like Emacs
https://news.ycombinator.com/item?id=21394916
https://news.ycombinator.com/item?id=21394916
Confirming that I was able to run a webserver on my Nokia 3650 https://en.wikipedia.org/wiki/Nokia_3650 back in 2004. Those were the days when T-Mobile USA actually gave you a public IP address! It was pretty awesome to be able to download photos from the phone via the web - even if only at GPRS speeds.
Sports Tracker was awesome. I used it for years before it stopped being competitive with Strava and more modern offerings.
> a windows port of the GNU toolchain, so it would only work on windows. But even on windows it had a lot of warts (because these tools were build for unix in the first place, so e.g. drive letters and back slashes were problematic).
About a decade ago I worked on a project for a South Korean cellphone vendor whose name I'll not cite for somewhat obvious reasons. The build system was similar to what you describe: a poor port of unix tools for windows that required windows xp which was already obsolete in 2011. I asked why don't we use linux since the build was probably more adequate for that environment. The answer was something like "because they spent a lot of money and time to make this port so we can use windows." Korea was mostly a windows-only country at the time. They had to change because of android, but for them it seemed already too little too late.
About a decade ago I worked on a project for a South Korean cellphone vendor whose name I'll not cite for somewhat obvious reasons. The build system was similar to what you describe: a poor port of unix tools for windows that required windows xp which was already obsolete in 2011. I asked why don't we use linux since the build was probably more adequate for that environment. The answer was something like "because they spent a lot of money and time to make this port so we can use windows." Korea was mostly a windows-only country at the time. They had to change because of android, but for them it seemed already too little too late.
Is Odin still a thing?
I don't know. Last time I re-imaged a Samsung phone, I used Heimdall[1]. It is open source and runs on linux.
[1] https://github.com/Benjamin-Dobell/Heimdall
[1] https://github.com/Benjamin-Dobell/Heimdall
It works well, compiled and used it last week.
LineageOS said it was out of date, but it worked for me on Ubuntu 22.04.
LineageOS said it was out of date, but it worked for me on Ubuntu 22.04.
Yep, but a bit out of date...
https://www.odinflash.com/odinchangelog
https://www.odinflash.com/odinchangelog
I would claim that something 50% of the application developers writing code for Nokia (internal or contractors) could not handle strings correctly. It was in theory C++ code, but because compilers were not very good at the time when EPOC32 was developed and memory was pretty limited there were special implementations to work around all the limitations. Programming was not easy, productivity was low, and buggy application code was the norm.
I vaguely remember in the very late days there might have been some simplifications, but the train had gone already at that time.
I vaguely remember in the very late days there might have been some simplifications, but the train had gone already at that time.
Didn’t Symbian Ed up using a version of CodeWarrior? Unfortunately, a Windows version of memory serves.
They did for a long time, but they eventually switched to an Eclipse based system. I believe there was a Nokia team in Dallas that built that.
That was Carbide IIRC: https://en.wikipedia.org/wiki/Carbide.c%2B%2B
You could always tell who was using it in the office because their laptop fans would be at full blast.
You could always tell who was using it in the office because their laptop fans would be at full blast.
First it was Visual Studio, second CodeWarrior and then obviously Eclipse (I probably never used the latter, jumped ship a couple of years before the infamous burning platform.) So every 3-5 years they changed the development environment. Can probably also seen as a sign that Symbian development was tedious and not much fun.
There were, alongside the Qt efforts they ported POSIX into Symbian, PIPS.
> The whole thing was a pretty frustrating experience. And we haven't talked about the libraries, the OS (cooperative multi tasking, everything is a callback) or memory management ('descriptors' that made trivial string operations a pain).
My understanding, as someone who was peripherally in contact with Symbian in 2007-2011, is that the multitasking concepts were based on the Actor model [1]. This is indeed a kind of callback-based cooperative multi-tasking, but it fits very well in Symbian's tasks-as-C++-objects concept.
C/C++ strings are a nightmare from a memory-management and reliability perspective, so I can't blame them for doing it differently. However their tooling was indeed not up to the challenge.
[1] https://en.wikipedia.org/wiki/Actor_model
My understanding, as someone who was peripherally in contact with Symbian in 2007-2011, is that the multitasking concepts were based on the Actor model [1]. This is indeed a kind of callback-based cooperative multi-tasking, but it fits very well in Symbian's tasks-as-C++-objects concept.
C/C++ strings are a nightmare from a memory-management and reliability perspective, so I can't blame them for doing it differently. However their tooling was indeed not up to the challenge.
[1] https://en.wikipedia.org/wiki/Actor_model
C++ strings might be problematic, but the solution that EPOC came up with and then Symbian inherited was terribly bad. Symbian didn't really just have a single string type (as I'm sure you remember), but a set of different types for different scenarios. And actually this wasn't only strings, but, IIRC all allocated memory. But for strings it had types like e.g. zero terminated string on heap, zero terminated string on stack, non-zero terminated strings, i.e. ones that had a length (for both locations). The main issue being that you ended up having to remember all these different types, sometimes having to convert between them (APIs/library functions, of course would have different versions accepting different types). Conversion would then end up making the apps slow, as manipulation was hard and require a lot of code, people would end up overrallocating memory, etc. (while the whole idea behind these was efficiency).
I remember that concatenating a string to print a log message required several lines of code. (And I mean something simple like: `print("Request took", length, "seconds")`.)
It may have been OK or maybe an absolute necessity for EPOC, when it was running on PSION PDAs with 64-128k of RAM. It was also probably even manageable, because the apps must have been of a smaller code base.
The 3650 was the first S60 phone, IIRC. It came with 4MB of RAM. A decade or so earlier one could run Linux with a GUI on a similar machine and without the insane memory management tricks. And I'd say that the 3650 was still OK, nobody knew whether it would be problematic to develop software for this OS or whether even if people would really use apps. But it was apparent after a few years that Symbian was very constraining and that it would cause serious issues in the future and Nokia did (would) have the time to act and maintain a healthy market share. It would have been risky, of course, but inaction proved fatal.
I remember that concatenating a string to print a log message required several lines of code. (And I mean something simple like: `print("Request took", length, "seconds")`.)
It may have been OK or maybe an absolute necessity for EPOC, when it was running on PSION PDAs with 64-128k of RAM. It was also probably even manageable, because the apps must have been of a smaller code base.
The 3650 was the first S60 phone, IIRC. It came with 4MB of RAM. A decade or so earlier one could run Linux with a GUI on a similar machine and without the insane memory management tricks. And I'd say that the 3650 was still OK, nobody knew whether it would be problematic to develop software for this OS or whether even if people would really use apps. But it was apparent after a few years that Symbian was very constraining and that it would cause serious issues in the future and Nokia did (would) have the time to act and maintain a healthy market share. It would have been risky, of course, but inaction proved fatal.
In fact, Symbian was using an "active object" design: https://en.wikipedia.org/wiki/Active_object_(Symbian_OS)
I probably know you, or some of your colleagues. Worked in Mountain View during the late 2000s. I really hated Symbian with a passion, and I was on the Java (and then Qt) side of it. It was embarrassing to try to sell that thing to external developers, but that was part of my job. I was a good soldier though, and ended up writing a few chapters in the worst computer programming book of all time, on how to do JavaME development on Symbian. That does NOT go on my resume.
I bought this book and tried my first mobile programs based on it! I thought it was well written. It was a big hit back then, if I recall correctly.
I’ve continued being a server-side programmer though :)
I’ve continued being a server-side programmer though :)
I worked in Budapest and didn't have connection with the Mountain View site, but I remember some of my direct colleagues talking about it. I think one or maybe two of them did visit it too, so I guess they did work with people from over there.
The build system sounds eerily familiar to one I used at a previous job.
There was a "gmake" and "cmake", one of them written in Perl and one written in shell, which wrapped make on a Windows port of the GNU toolchain, and the makefiles were generated (as far as I can tell) using Make as a scripting language. Hard-coded drive letters, company-internal packaging systems, Cygwin mount points, multiple terminal windows, etc. The build system dated back a couple decades and was ported from Unix.
If you tracked down the actual rules that Make executed, you'd find something like this:
I have no idea of the actual history for this software. Few teams used it. I can only imagine that it was slowly modified, over decades, by people who did not understand the system that they were modifying. By this point in history computers were plenty fast and had plenty of memory, so I can only imagine how much of a pain it must have been to work with back in the 1990s. During the short time I was there, I managed to reduce the build time by a factor of about 100x, there were so many easy opportunities for improvement. I heard from someone who still works there that my improvements were removed, which doesn't surprise me at all--after all, I wasn't there to support those improvements.
At some point I realized that I was cleaning up bugs introduced by other members of the team, and I was on the losing side. My direct manager had almost zero knowledge of software engineering, as far as I could tell (only seniority & some domain expertise). Some other people on the team were figuring out how to provide proper support, and a couple others were doing stuff with Node.js.
There was a "gmake" and "cmake", one of them written in Perl and one written in shell, which wrapped make on a Windows port of the GNU toolchain, and the makefiles were generated (as far as I can tell) using Make as a scripting language. Hard-coded drive letters, company-internal packaging systems, Cygwin mount points, multiple terminal windows, etc. The build system dated back a couple decades and was ported from Unix.
If you tracked down the actual rules that Make executed, you'd find something like this:
$(TARGET_1): $(DEPS_1)
$(RECIPE_1)
I have no idea of the actual history for this software. Few teams used it. I can only imagine that it was slowly modified, over decades, by people who did not understand the system that they were modifying. By this point in history computers were plenty fast and had plenty of memory, so I can only imagine how much of a pain it must have been to work with back in the 1990s. During the short time I was there, I managed to reduce the build time by a factor of about 100x, there were so many easy opportunities for improvement. I heard from someone who still works there that my improvements were removed, which doesn't surprise me at all--after all, I wasn't there to support those improvements.
At some point I realized that I was cleaning up bugs introduced by other members of the team, and I was on the losing side. My direct manager had almost zero knowledge of software engineering, as far as I could tell (only seniority & some domain expertise). Some other people on the team were figuring out how to provide proper support, and a couple others were doing stuff with Node.js.
I was on the Networks side between 2004 and 20011.
I painfully remember all the hoops that Symbian went through during those years until the last days of Carbide.
Yet, sometimes I still miss it when comparing with NDK development experience on Android.
I painfully remember all the hoops that Symbian went through during those years until the last days of Carbide.
Yet, sometimes I still miss it when comparing with NDK development experience on Android.
> No wonder it couldn't keep up with android and ios.
I remember my first few years of Android/iOS, There would occasion where the 'old Nokia(Symbian) could do it better'; On Android it was largely limited to battery management(similar screen size), Multitasking and on iOS it was everything from SMS forwarding to bluetooth sharing.
I remember my first few years of Android/iOS, There would occasion where the 'old Nokia(Symbian) could do it better'; On Android it was largely limited to battery management(similar screen size), Multitasking and on iOS it was everything from SMS forwarding to bluetooth sharing.
Symbian did everything better than iOS and most things better than android. At least it could do a lot more than any of these. Symbian had 'push' email (i.e. email that would just arrive, like it does now), whereas at least with iOS you had to check for it, it had MMS (I think neither iOS or Android had it), backrgound apps, tethering, data connection over Bluetooth and in general, BT could be accessed from 3rd party apps for whatever purposes you wanted (this took quite a while for iOS), etc.
Except for two critically important features: user experience and developer experience. (Actually, the first version iOS/iphones didn't even allow 3rd party apps.)
It was a classic case of market disruption: a product (well, two products) inferior to the dominant, incumbent product in almost every respect gets a few things right while missing the mark on just about everything else. And the funny thing is that we'd bean hearing the term "disruption" for years from managers when they talked about strategy. In just about every meeting. They kept quoting Christensen, saying "we have to be disruptive" and even that didn't prevent the company from being disrupted big time. Now don't ask me how we would have been supposed to "disrupt" as the largest incumbents, the market leaders, but it was obvious that the management was not willing to take the required chances. (Hence they stuck with Symbian, despite what should have been obvious to anyone with a decent knowledge of software development.)
Except for two critically important features: user experience and developer experience. (Actually, the first version iOS/iphones didn't even allow 3rd party apps.)
It was a classic case of market disruption: a product (well, two products) inferior to the dominant, incumbent product in almost every respect gets a few things right while missing the mark on just about everything else. And the funny thing is that we'd bean hearing the term "disruption" for years from managers when they talked about strategy. In just about every meeting. They kept quoting Christensen, saying "we have to be disruptive" and even that didn't prevent the company from being disrupted big time. Now don't ask me how we would have been supposed to "disrupt" as the largest incumbents, the market leaders, but it was obvious that the management was not willing to take the required chances. (Hence they stuck with Symbian, despite what should have been obvious to anyone with a decent knowledge of software development.)
Wow making an employee sign an NDA! How did they realize that the employment contract probably already covered all of the legal angles? Seems like pointless internal gatekeeping and infighting. No wonder the project was crushed by Android.
He was not allowed to share the stuff (and the information) he had even with us. But yep, super crazy. That was the time before if was obvious that you do want to give access to all code being written to all of your developers. (And eventually to put extra effort into making it as painless as possible.)
Nokia really had to open source 15 years earlier at least
Maybe I'm remembering wrong but didn't the iPhone not have multitasking for apps for a long time as well. I recall that essentially the OS did something like a snapshot of every app when one switched.
The iPhone always had multitasking. What it didn’t allow was background processing. When selected again, your app would be suspended and allowed to run again or be launched fresh based on memory pressure.
As someone else said Symbian also was capable of multitasking, it was the frameworks that did not allow is. Can someone explain the practical difference for someone programming an app between the iphone and symbian limitations?
Now that nobody cares about this crap anymore, they release the source code.
Symbian was open sourced in 2010. https://www.wired.com/2010/02/symbian-operating-system-now-o...
It is odd to see people talking about how Symbian was so early on, in the smartphone era.
It's considerably more mature than that. :-) (For the avoidance of doubt: this is a good thing.)
Symbian was a rebrand of the Psion 5 and 5MX OS, which was called EPOC32. It also ran on some other hardware, including the Ericsson MC218, Oregon Scientific Osaris, and Geofox One.
The first EPOC32 device was the Psion 5 in 1997:
http://www.computinghistory.org.uk/det/5300/Psion-Series-5/
Succeeded by the 5MX:
https://uxdesign.cc/psion-pda-how-does-it-look-today-327e01b...
https://thenewstack.io/retrocomputing-in-modern-times-redisc...
In other words, this OS was out there in the real world, in use by hundreds of thousands of people, five years before the first Symbian device (Nokia 7650).
It's considerably more mature than that. :-) (For the avoidance of doubt: this is a good thing.)
Symbian was a rebrand of the Psion 5 and 5MX OS, which was called EPOC32. It also ran on some other hardware, including the Ericsson MC218, Oregon Scientific Osaris, and Geofox One.
The first EPOC32 device was the Psion 5 in 1997:
http://www.computinghistory.org.uk/det/5300/Psion-Series-5/
Succeeded by the 5MX:
https://uxdesign.cc/psion-pda-how-does-it-look-today-327e01b...
https://thenewstack.io/retrocomputing-in-modern-times-redisc...
In other words, this OS was out there in the real world, in use by hundreds of thousands of people, five years before the first Symbian device (Nokia 7650).
The first Symbian based Nokia device was the 9210.
I helped integrate the fax functionality - was amazing to see the first faxes sent and received :)
Fair enough! I defer to your superior wisdom.
So, four years earlier, not five. :-)
I have seen comments from people who worked at Accenture in the last days of Symbian, about the difficulty of putting together the build system today. Apparently bits need a specific MS C++ compiler that only runs on WinXP.
I think it would be wonderful to see this resurrected and ported to the RasPi or something. Symbian was capable of SMP, and there were a lot of 3rd party apps back in the day.
One of the things that crippled Symbian in the market was the range of UIs, all incompatible. I owned devices running Series 90 (Nokia 7710), Series 60 (E90 Communicator), and UIQ (Sony-Ericsson P910i). There was also Series 80 (earlier Communicators), and MOAP and OPP in Japan only.
AIUI all needed different programming tools and apps from one couldn't run on the other.
Frankly, none of that matters any more. Whatever is in this FOSS release and can be used with modern FOSS tooling is all that matters. Nobody needs early-noughties phone apps on a RasPi. Just something that can be used on a desktop with a mouse and keyboard.
I suspect a few old Psion and Symbian enthusiasts would appear and enjoy modernising their own apps to get them working again. It's not that long ago.
EPOC32 and Symbian were great OSes to use: fast as hell, stable, and low-resource. On a RasPi 4 I think it'd stomp all over Linux, and it's vastly more modern than RISC OS.
C++ has come a long way, too, since Psion chose it. The rough edges have been smoothed away.
So, four years earlier, not five. :-)
I have seen comments from people who worked at Accenture in the last days of Symbian, about the difficulty of putting together the build system today. Apparently bits need a specific MS C++ compiler that only runs on WinXP.
I think it would be wonderful to see this resurrected and ported to the RasPi or something. Symbian was capable of SMP, and there were a lot of 3rd party apps back in the day.
One of the things that crippled Symbian in the market was the range of UIs, all incompatible. I owned devices running Series 90 (Nokia 7710), Series 60 (E90 Communicator), and UIQ (Sony-Ericsson P910i). There was also Series 80 (earlier Communicators), and MOAP and OPP in Japan only.
AIUI all needed different programming tools and apps from one couldn't run on the other.
Frankly, none of that matters any more. Whatever is in this FOSS release and can be used with modern FOSS tooling is all that matters. Nobody needs early-noughties phone apps on a RasPi. Just something that can be used on a desktop with a mouse and keyboard.
I suspect a few old Psion and Symbian enthusiasts would appear and enjoy modernising their own apps to get them working again. It's not that long ago.
EPOC32 and Symbian were great OSes to use: fast as hell, stable, and low-resource. On a RasPi 4 I think it'd stomp all over Linux, and it's vastly more modern than RISC OS.
C++ has come a long way, too, since Psion chose it. The rough edges have been smoothed away.
> One of the things that crippled Symbian in the market was the range of UIs, all incompatible
I disagree. All of them were used on different devices, with S60 being the most popular and used on most phones, just regular market differentiation.
I disagree. All of them were used on different devices, with S60 being the most popular and used on most phones, just regular market differentiation.
Well, of course, you are free to do so, but it was a widely-held opinion at the time.
For example: https://www.theregister.com/2011/01/12/symbian_history_part_...
(From my employers, but not by me and before I worked there.)
This whole series is well worth a read.
For example: https://www.theregister.com/2011/01/12/symbian_history_part_...
(From my employers, but not by me and before I worked there.)
This whole series is well worth a read.
I loved UIQ3. My M600i is still my second-favourite smartphone, only overtaken by the Nokia N9 running Maemo/Meego
I had 3 different Symbian devices with different UIs.
All of them were good. I'm not arguing about the pros and cons of any particular UI.
The problem was that there were about half a dozen different Symbian UIs, and the devices were totally incompatible. You couldn't run an app from one UI on another device with the same OS version but a different UI.
Apps even had to be developed with different toolchains. Some GUI toolkits were entirely proprietary, some used Qt, some used Java. Apps weren't even portable between UIs!
That was disastrous.
Under the skin, Symbian was quite remarkably good in some ways. For instance it was the only phone OS where the main CPU could also run the GSM comms stack: its realtime support and multitasking made this viable. Every other smartphone dedicates a separate, loosely-couple CPU with its own OS to running the comms.
Symbian devices with say a 16MHz ARM and 8MB of RAM were entirely usable. That is unachievable with any UNIX-based smartphone OS.
No, it doesn't matter any more in efficiency terms, when a $5 computer has a gig of RAM and 4 cores. (I am thinking of the Raspberry Pi Zero W here, for clarity.)
But think of attack surfaces. Think of size of stack to be ported to a new platform. Think of the amount of code to learn before making changes. Think of amount of code to verify. Think of the rebuild time. Think of team sizes. Think of there being any chance that a small team can study and learn the entire codebase.
This is meaningfully impossible with any modern xNix-based OS. It's too vast. It would take a lifetime to study the whole source tree.
Whereas Symbian was built by a tiny team in a few years, in a then-new state-of-the-art language, and it scaled from a single-CPU machine with 1 core in the double-digit MHz and a few megabytes of RAM, and a decade later, it was still competitive against machines with multiple gigahertz-class cores and hardware 3D processors running a truecolour GUI, using a desktop OS sized in the gigabytes developed by teams of hundreds of thousands of coders.
That is a remarkable achievement.
It's remarkable not that it died, but that it lasted so long and held up so well.
All of them were good. I'm not arguing about the pros and cons of any particular UI.
The problem was that there were about half a dozen different Symbian UIs, and the devices were totally incompatible. You couldn't run an app from one UI on another device with the same OS version but a different UI.
Apps even had to be developed with different toolchains. Some GUI toolkits were entirely proprietary, some used Qt, some used Java. Apps weren't even portable between UIs!
That was disastrous.
Under the skin, Symbian was quite remarkably good in some ways. For instance it was the only phone OS where the main CPU could also run the GSM comms stack: its realtime support and multitasking made this viable. Every other smartphone dedicates a separate, loosely-couple CPU with its own OS to running the comms.
Symbian devices with say a 16MHz ARM and 8MB of RAM were entirely usable. That is unachievable with any UNIX-based smartphone OS.
No, it doesn't matter any more in efficiency terms, when a $5 computer has a gig of RAM and 4 cores. (I am thinking of the Raspberry Pi Zero W here, for clarity.)
But think of attack surfaces. Think of size of stack to be ported to a new platform. Think of the amount of code to learn before making changes. Think of amount of code to verify. Think of the rebuild time. Think of team sizes. Think of there being any chance that a small team can study and learn the entire codebase.
This is meaningfully impossible with any modern xNix-based OS. It's too vast. It would take a lifetime to study the whole source tree.
Whereas Symbian was built by a tiny team in a few years, in a then-new state-of-the-art language, and it scaled from a single-CPU machine with 1 core in the double-digit MHz and a few megabytes of RAM, and a decade later, it was still competitive against machines with multiple gigahertz-class cores and hardware 3D processors running a truecolour GUI, using a desktop OS sized in the gigabytes developed by teams of hundreds of thousands of coders.
That is a remarkable achievement.
It's remarkable not that it died, but that it lasted so long and held up so well.
[deleted]
Worth mentioning the N-Gage, which got a Wordle port recently, powered by SDL2:
https://hackaday.com/2022/04/08/wordle-comes-to-the-nokia-n-...
I remember the N-Gage being lambasted when it came out, but recently I realized that those same people also lambasted the iPod, and maybe I can't trust those people's judgment about tech. You know, the Slashdot crowd.
Maybe it was a good system that was just poorly positioned in the market against the Game Boy Advance. $200 for a phone + gaming system doesn't sound so bad, and the more recent comments I've heard about it are along the lines of "underrated system that was ahead of its time". It was competing against a $100 Game Boy Advance, though.
https://hackaday.com/2022/04/08/wordle-comes-to-the-nokia-n-...
I remember the N-Gage being lambasted when it came out, but recently I realized that those same people also lambasted the iPod, and maybe I can't trust those people's judgment about tech. You know, the Slashdot crowd.
Maybe it was a good system that was just poorly positioned in the market against the Game Boy Advance. $200 for a phone + gaming system doesn't sound so bad, and the more recent comments I've heard about it are along the lines of "underrated system that was ahead of its time". It was competing against a $100 Game Boy Advance, though.
The original N-Gage made a few astoundingly bad industrial design decisions that came up in literally every review.
* They put the phone microphone and speaker on the side of the device, which meant holding the top of the gadget to your head if you wanted to use it as a phone without a headset -- this was both awkward physically and looked phenomenally stupid.
* You had to remove the battery to get to the game cartridge slot! Again, really awkward. Really, the ergonomics overall were kind of baffling.
* It had a portrait orientation screen that was slightly lower resolution than the Game Boy's, which made doing ports of games designed for the landscape orientation more common everywhere else more difficult.
The updated "QD" version fixed a lot of the weirdness, and it's possible that if it had been the original N-Gage, things might have gone a lot differently.
Of course, that's kind of a theme in the Nokia story in the mid-to-late 2000s, I think -- they got really good at shipping terrific products just a couple years later than they should have. If Symbian^3 and the N8 had come out in 2008 instead of 2010, Nokia's fate might have been pretty different. (Emphasis on "might," to be sure.)
* They put the phone microphone and speaker on the side of the device, which meant holding the top of the gadget to your head if you wanted to use it as a phone without a headset -- this was both awkward physically and looked phenomenally stupid.
* You had to remove the battery to get to the game cartridge slot! Again, really awkward. Really, the ergonomics overall were kind of baffling.
* It had a portrait orientation screen that was slightly lower resolution than the Game Boy's, which made doing ports of games designed for the landscape orientation more common everywhere else more difficult.
The updated "QD" version fixed a lot of the weirdness, and it's possible that if it had been the original N-Gage, things might have gone a lot differently.
Of course, that's kind of a theme in the Nokia story in the mid-to-late 2000s, I think -- they got really good at shipping terrific products just a couple years later than they should have. If Symbian^3 and the N8 had come out in 2008 instead of 2010, Nokia's fate might have been pretty different. (Emphasis on "might," to be sure.)
> They put the phone microphone and speaker on the side of the device.
I have no idea why they engineered the device like that. It would have been easier to just put a grill right where I drilled my holes.
Obligatory: https://sidetalking.com/page-1.html
>and the more recent comments I've heard about it are along the lines of "underrated system that was ahead of its time".
It always had a following, but the thing flopping wasn't because of the Slashdot crowd, it's because it just wasn't very good out of the gate.
The N-Gage has an awful form factor that made it suck both as a gaming device and as a phone. Game cartridges were hidden behind the battery, button placement was awkward, and sidetalking became an early internet meme for very good reason.
Nokia fixed a lot of the problems with a second generation release, but at that point the brand was largely poisoned.
It always had a following, but the thing flopping wasn't because of the Slashdot crowd, it's because it just wasn't very good out of the gate.
The N-Gage has an awful form factor that made it suck both as a gaming device and as a phone. Game cartridges were hidden behind the battery, button placement was awkward, and sidetalking became an early internet meme for very good reason.
Nokia fixed a lot of the problems with a second generation release, but at that point the brand was largely poisoned.
I think they changed that with Ngage QD next gen ngage loved that phone. Quite stable and powerful for an symbian os.
Do you think there is anything useful for modern day programmer in the codebase? Any value on this code for anyone, anymore?
Or do we have better alternatives and rewrites for everything that can be found in this repo?
Or do we have better alternatives and rewrites for everything that can be found in this repo?
Very much yes.
There are only a handful of C++ OSes out there.
• EPOC32/Symbian.
• BeOS (now lost somewhere inside of Access) and Haiku, its FOSS recreation.
• Genode (still in prototype stage, really)
• Serenity OS (not yet self-hosting, & barely able to run on bare metal.)
Symbian is by far the most successful, long-lived, best-selling C++ there has ever been.
By 21st century standards, it is tiny, simple, low-resource, fast, and stable. It is SMP-aware and multimedia-friendly, yet realtime-capable.
Symbian, in a way, is what many next-gen OS projects have been aspiring to be for decades.
It also uses standard filesystems, ran on a wide variety of industry-standard hardware, and was built using fairly standard PC tooling: Windows, C++ etc.
If there is nothing to be learned from this, we may as well all give up and go home, because computing is over.
There are only a handful of C++ OSes out there.
• EPOC32/Symbian.
• BeOS (now lost somewhere inside of Access) and Haiku, its FOSS recreation.
• Genode (still in prototype stage, really)
• Serenity OS (not yet self-hosting, & barely able to run on bare metal.)
Symbian is by far the most successful, long-lived, best-selling C++ there has ever been.
By 21st century standards, it is tiny, simple, low-resource, fast, and stable. It is SMP-aware and multimedia-friendly, yet realtime-capable.
Symbian, in a way, is what many next-gen OS projects have been aspiring to be for decades.
It also uses standard filesystems, ran on a wide variety of industry-standard hardware, and was built using fairly standard PC tooling: Windows, C++ etc.
If there is nothing to be learned from this, we may as well all give up and go home, because computing is over.
Windows is slowly moving into to C++ since Vista, nowadays you have the WIL template library that is being used there as well. One doesn't steer that ship in one release.
macOS uses C++ as driver and Metal subsystem.
IBM mainframes usually get to write new modules in C++, alongside their classical languages (PL/I dialects and such).
ARM mbed also makes use of C++.
Although not an OS proper, the Arduino bare metal libraries are C++.
macOS uses C++ as driver and Metal subsystem.
IBM mainframes usually get to write new modules in C++, alongside their classical languages (PL/I dialects and such).
ARM mbed also makes use of C++.
Although not an OS proper, the Arduino bare metal libraries are C++.
Who is using Symbian today?
Thank you for that summary (and I have an email in my drafts folder for you! will send it soon, honest :-))
My MC218 still works, pretty crazy. I had the IR modem for it too but lost it somewhere.
I have a heavily used MC218 sitting next to me. I tinker around with it occasionally (after all it runs Linux), but any productive uses have long been replaced by other devices. The device was great for it's time and even I kept it alive for a lot longer, maybe until the first iPhone arrived. Nowadays it's limited by not having Bluetooth or WiFi. This makes connecting this device to anything really awkward. Also, in comparison to modern screens the LCD screen is very hard to read an needs good lighting conditions to shine.
I miss the form factor though. Typing this text on a virtual keyboard feels like something is amiss. A real keyboard IMHO just can't be replaced by an on screen keyboard.
I miss the form factor though. Typing this text on a virtual keyboard feels like something is amiss. A real keyboard IMHO just can't be replaced by an on screen keyboard.
If anyone's interested here's [0] a Mediafire archive of Symbian developer sources of all kinds, from compilers and SDKs to manuals.
[0] https://www.mediafire.com/folder/79jhy594xb3uk/Symbian_Devel...
[0] https://www.mediafire.com/folder/79jhy594xb3uk/Symbian_Devel...
Thank you, this is gold. I have discovered a couple of nokia phones in my drawer and I was wondering how the hell I could develop on them. Since then I have discovered the whole "cooked ROM" scene, which has of course died in the meantime. I hope that archive will answer my questions.
Btw, if anyone knows, is a special piece of hardware needed to flash the firmware of a nokia symbian phone?
Symbian devs had their own flashing stations/cradles but at some point it became possible to flash newer phones over USB. The software tool was called Phoenix and used regularly be leaked.
Thanks. I wish I knew about these back to high school days 2001.
Instead, I learnt J2ME and.... weill still a Java dev until today :p
For what it's worth, I took a mobile software dev course in University, and it targeted mainly Symbian. I learned that I definitely do not want to do that. It was a painful experience.
I ended up doing mobile development anyway, but not until Qt was a viable option for Symbian.
I ended up doing mobile development anyway, but not until Qt was a viable option for Symbian.
Any way to get those onto archive.org?
The same set files seem to be mirrored at https://katastrophos.net/symbian/mirrors/delight/. Probably more wget-friendly than Mediafire.
Also, «Symbian Archive»[0,1] project has a lot of mirrors of Symbian source & software.
Here is a list of active Symbian software developers* (+ links to its projects).[2]
P.S. I'm luckily archived/mirrored LCG's X-plore[3] & ProfiMail[4] apps source repos in time when it was released into Public Domain by LonelyCatGames* team (now official repos is disabled).
[0] https://mrrosset.github.io/Symbian-Archive/index.html
[1] https://github.com/mrRosset/Symbian-Archive
[2] https://github.com/mrRosset/Symbian-Archive/issues/10
[3] https://github.com/Symbian9/X-plore_free
[4] https://github.com/Symbian9/ProfiMail_free
Here is a list of active Symbian software developers* (+ links to its projects).[2]
P.S. I'm luckily archived/mirrored LCG's X-plore[3] & ProfiMail[4] apps source repos in time when it was released into Public Domain by LonelyCatGames* team (now official repos is disabled).
[0] https://mrrosset.github.io/Symbian-Archive/index.html
[1] https://github.com/mrRosset/Symbian-Archive
[2] https://github.com/mrRosset/Symbian-Archive/issues/10
[3] https://github.com/Symbian9/X-plore_free
[4] https://github.com/Symbian9/ProfiMail_free
Don't forget to `abld reallyclean`!
Symbian was the era that trains you to never be afraid of debugging the hardest problems and understand how big of a blessing documentation is.
A few examples of my childhood experiences making a game for Symbian:
1) Debugging that one problem which would cause the whole OS to crash
The crash log didn't help cause it wouldn't flush the logs to disk in time. My under developed concepts of multi-threading didn't help much either not that I know much more today 10 years later.
2) Overriding OS memory safety to read accelerometer data from memory in phones that didn't have APIs for it
The patience and creative thinking you learn tackling with such high levels of uncertainty and painful problems is incredible.
I am not aware of how engineers learn engineering (I am self taught) but this kind of patience and endurance does shape a lot of my engineering skills today.
A few examples of my childhood experiences making a game for Symbian:
1) Debugging that one problem which would cause the whole OS to crash
The crash log didn't help cause it wouldn't flush the logs to disk in time. My under developed concepts of multi-threading didn't help much either not that I know much more today 10 years later.
2) Overriding OS memory safety to read accelerometer data from memory in phones that didn't have APIs for it
The patience and creative thinking you learn tackling with such high levels of uncertainty and painful problems is incredible.
I am not aware of how engineers learn engineering (I am self taught) but this kind of patience and endurance does shape a lot of my engineering skills today.
Earlier Windows versions shipped with the same wonderful developer experience. My favourite was a bool API function returning 2 under certain circumstances that you’d better be aware of.
And by “earlier” I mean from Win 3.1 and up to W8 era or thereabouts, when the documentation finally started to improve.
And by “earlier” I mean from Win 3.1 and up to W8 era or thereabouts, when the documentation finally started to improve.
Anyone else feel sad coming across something like this? So many hours spent for a product that is largely forgotten. Glad to see the pieces out in the open though.
Symbian, the Ozymandias of smartphone operating systems.
They had a lot of the right ideas very early. They started building a high-resolution graphical mobile OS for 32-bit ARM in the mid-1990s, when most phones barely could display two lines of text and receive an SMS. Many concepts in iOS and Android today were pioneered by Symbian.
IMO, the biggest failing of Symbian was to disown the UI and focus on the lower layers of the operating system. Symbian's licensees like Nokia, Motorola and SonyEricsson wanted to control the GUI layer themselves, so they had annoyingly incompatible GUI libraries for Symbian. The platform was already hard to develop for, and then you had multiple vendors piling gunk on top like Nokia's Series 60 which was a terrible piece of work.
In a parellel universe Symbian would have acquired the BeOS team in 2003 and kept them in Silicon Valley, tasked with building a truly excellent mobile GUI on a five-year time horizon independent of Nokia's meddling. A well-designed high-level UI framework in a reasonable language could have made the embedded C++ underpinnings of Symbian mostly irrelevant — basically shipping Android a couple of years before the fact.
They had a lot of the right ideas very early. They started building a high-resolution graphical mobile OS for 32-bit ARM in the mid-1990s, when most phones barely could display two lines of text and receive an SMS. Many concepts in iOS and Android today were pioneered by Symbian.
IMO, the biggest failing of Symbian was to disown the UI and focus on the lower layers of the operating system. Symbian's licensees like Nokia, Motorola and SonyEricsson wanted to control the GUI layer themselves, so they had annoyingly incompatible GUI libraries for Symbian. The platform was already hard to develop for, and then you had multiple vendors piling gunk on top like Nokia's Series 60 which was a terrible piece of work.
In a parellel universe Symbian would have acquired the BeOS team in 2003 and kept them in Silicon Valley, tasked with building a truly excellent mobile GUI on a five-year time horizon independent of Nokia's meddling. A well-designed high-level UI framework in a reasonable language could have made the embedded C++ underpinnings of Symbian mostly irrelevant — basically shipping Android a couple of years before the fact.
Before the iPhone, mobile device companies were held ransom by wireless carriers. Carriers dictated everything about the phones, down the Verizon demanding Bluetooth file transfer was disabled to force people to use data minutes to send pictures.
This is one of the things that I think modern techies have forgotten. No matter what you think of Apple, they were the only ones with enough market power to force carriers out of that position (Apple having been newly minted at the king of digital music) . It’s why the iPhone was exclusive to AT&T — because Verizon was the market leader and AT&T had to make the deal to get the iPhone. And Jobs wouldn’t make the deal with any carrier that insisted on adding crapware to the phone.
This is one of the things that I think modern techies have forgotten. No matter what you think of Apple, they were the only ones with enough market power to force carriers out of that position (Apple having been newly minted at the king of digital music) . It’s why the iPhone was exclusive to AT&T — because Verizon was the market leader and AT&T had to make the deal to get the iPhone. And Jobs wouldn’t make the deal with any carrier that insisted on adding crapware to the phone.
This was true in the US. I don’t know about Europe. But it wasn’t true anywhere else. Even in the US it was dominated by Motorola (and BB) as a result. Motorola didn’t have much success outside of Razr in the rest of the world and Nokia and Sony didn’t have much success in the US. So it was really a tale of two worlds. I really liked the Sonys and Nokias of the era.
Symbian didn’t screw up the UI and it certainly was “too open”. It was so common to have malware and viruses on nokia phones. Bluetooth was scary.
The biggest issue of all was the incompatible app ecosystem. Each phone and OS and sometimes even models were different. Some were Java, others were Symbian and then the whole world of blackberries and windows.
Symbian didn’t screw up the UI and it certainly was “too open”. It was so common to have malware and viruses on nokia phones. Bluetooth was scary.
The biggest issue of all was the incompatible app ecosystem. Each phone and OS and sometimes even models were different. Some were Java, others were Symbian and then the whole world of blackberries and windows.
It was not true in Europe either. You could of course use any device, and in many countries bundling a device with a phone contract was even expressly forbidden. Carriers had no control at all.
Insert the usual disclaimer that Europe has a lot of countries with different legislation, but the carrier stranglehold was a US specific problem.
Insert the usual disclaimer that Europe has a lot of countries with different legislation, but the carrier stranglehold was a US specific problem.
I've been working for a carrier in Italy in the first half of 2000s. We designed some phones with manufacturers but any phone could work on our network AFAIK. There was not much choice at the beginning because we only had a 3G network and there were very few 3G phones (only one at launch.)
This was very true in Japan where most of phone supported limited internet access even in 2001. Careers ordered phone manufacturer to what to develop, and most phones have zero compatibility for other career feature because every phones were locked.
> was so common to have malware and viruses on nokia phones
I never experienced that and don’t know anyone who did. Was it really a thing?
I never experienced that and don’t know anyone who did. Was it really a thing?
I don’t think this is true. I worked extensively in the mobile industry back in the day and all Nokia apps had more painful signing process than iOS apps have today.
No, It's true, most my fiends who used to install pirated application (.sis file) from internet got affected by these viruses and at that time most popular antivirus companies (McAfee, Kaspersky, f-secure) had Symbian versions of their antivirus programs.
https://en.wikipedia.org/wiki/Cabir_(computer_worm) https://en.wikipedia.org/wiki/Commwarrior
https://en.wikipedia.org/wiki/Cabir_(computer_worm) https://en.wikipedia.org/wiki/Commwarrior
I'm not sure what you expect here. Is it the manufacturer's fault if you sideload virus infested applications?
Note that these are not computer virii by the definition, as they cannot spread independently. User always need to download the application somewhere and install it themself. The closest analogue would be Remote Access Trojan (RAT) infected Windows PC pirated software.
It was half true in the mid 2000s in Australia. While you could put basically any device on to the network, Telstra and Optus definitely held a some sway over manufacturers.
There are different markets than US and phones aren't only sold by carriers. Even admitting what you say in US is true, it definitely was not in Europe or Asia thus I doubt any of your analysis of carriers impacting the tech.
You obviously didn't live at this age or were too young. Most people in the late 90s and the early 2000s got their phones subsidized by a carrier.
There was a time when the carriers were the most important channel for selling phones and this was not only in the US.
It was a huge problem in Japan, South Korea and to lesser extent, the US. Japanese phone industry conformed to it but bled to death soon after iPhone happened.
I think as long as it was companies like nokia who liked to create smartphones that where primarily phones with texting first and computers a very distant second Symbian did not have a chance.
I know that they made stuff like the 9x00 communicators but they where never intended as mass market products.
Nokia was never able to craft a desirable product that brought applications to the mainstream user, most people who got their smartphones only used them as phones.
I know that they made stuff like the 9x00 communicators but they where never intended as mass market products.
Nokia was never able to craft a desirable product that brought applications to the mainstream user, most people who got their smartphones only used them as phones.
Third-party apps for Symbian may not have been mainstream, but third-party games definitely were. Even before that, Java ME games were popular on feature phones.
Also one of several instances where the Breaking Bad writers put a lot of thought into amazing episode themes and titles: https://en.wikipedia.org/wiki/Ozymandias_(Breaking_Bad)
I love your post.
NB tho, Symbian already knew (see 1998) how to make a "truly excellent mobile GUI" - sure, it was a PDA, but we were already making phone UIs with phone licensees then, and could happily have made a "well-designed high-level UI framework".
I'd've loved that "parallel universe".
Alas, the Symbian deal nixed it, and our new owners simply wanted us to make their kind of phone platforms for them: four whole new ones, in 18 months (heh right), mainly to their specs, while recruiting 100 new devs and 10 new designers.
So I feel it's a little harsh to say "the biggest failing of Symbian was to disown the UI" -- we never had the option to keep control of it. (It was a major failing of the Symbian deal itself, sure.)
NB tho, Symbian already knew (see 1998) how to make a "truly excellent mobile GUI" - sure, it was a PDA, but we were already making phone UIs with phone licensees then, and could happily have made a "well-designed high-level UI framework".
I'd've loved that "parallel universe".
Alas, the Symbian deal nixed it, and our new owners simply wanted us to make their kind of phone platforms for them: four whole new ones, in 18 months (heh right), mainly to their specs, while recruiting 100 new devs and 10 new designers.
So I feel it's a little harsh to say "the biggest failing of Symbian was to disown the UI" -- we never had the option to keep control of it. (It was a major failing of the Symbian deal itself, sure.)
Especially if it's something you used and liked. But yes, I'm a big fan of releasing these things to the public, for archival and for the curious. It's crazy how even big companies lose source code of old software, or at least only have it accessible in a completely chaotic state, with a missing build system, missing instructions, etc. Recent example would be 3D Movie Maker by Microsoft. People got it to compile eventually, but it apparently was a wild undertaking:
https://www.youtube.com/watch?v=gqXTzlDZmhU https://www.youtube.com/watch?v=mjtKHPwTWsc
https://www.youtube.com/watch?v=gqXTzlDZmhU https://www.youtube.com/watch?v=mjtKHPwTWsc
Quite a few of those hours were wasted and contributed to Nokia's demise. They should have switched away from Symbian waaay sooner. I think clinging to it is a classic case of the sunken cost fallacy. By ~2005-2006 it was obvious, at least for some of us, developers, that continuing to invest in Symbian is a huge mistake.
By then, Nokia had been working on a Linux based OS for years. (That would become Meego.) But, if I'm not mistaken, at least a thousand people were working on Symbian and Symbian based products. So switching away from it was simply out of question. It would have been too bold a move. (Especially, since Nokia was dominating the market and these products brought in a very nice profit.)
By then, Nokia had been working on a Linux based OS for years. (That would become Meego.) But, if I'm not mistaken, at least a thousand people were working on Symbian and Symbian based products. So switching away from it was simply out of question. It would have been too bold a move. (Especially, since Nokia was dominating the market and these products brought in a very nice profit.)
Its such a shame too, because Meego and the UI they built for the Nokia N9 was still ahead of it's time, and absolutely excellent to use. But it was dead on arrival, aside from us geeks who loved the idea of Debian on a phone :)
wasnt this pain the premise of the infamous "burning platform" memo [1] and the eventual switch to Windows Phone as an OS?
[1] https://www.alexanderjarvis.com/memo-nokia-ceo-stephen-elops...
[1] https://www.alexanderjarvis.com/memo-nokia-ceo-stephen-elops...
Maybe. But by then (2011 IIRC) it was way too late, sales had been going South, so one wouldn't need too much of a genius to figure out that Symbian was dead.
The problem was that in the mid 2000s things were going just too good and management didn't want to see how it could become problematic, or at least take the risk. We were selling smart phones, that weren't really phones anymore (heck, we called them mobile terminals!) but it was pretty hard and painful to develop software for these. This made hard to convince external, indie/hobbist developers (they ended up creating most of the apps for ios and android) and, of course made internal development pretty expensive. Worse, it must have made experimenting and thus innovation slow. Hence the UI was stuck. Not as if Nokia ever put too much effort into innovating the UI. Touch screens were somewhat frowned upon. Though that may in part have related to the existing UI, the effort needed to try out something new and the fact that those touch screens were still resistive back then. Which is really not a great UX.
Though I remember once trying a prototype phone at an internal conference with a touch screen providing haptic feedback (through some piezo efect). So you could kind of feel the on-screen buttons.
The problem was that in the mid 2000s things were going just too good and management didn't want to see how it could become problematic, or at least take the risk. We were selling smart phones, that weren't really phones anymore (heck, we called them mobile terminals!) but it was pretty hard and painful to develop software for these. This made hard to convince external, indie/hobbist developers (they ended up creating most of the apps for ios and android) and, of course made internal development pretty expensive. Worse, it must have made experimenting and thus innovation slow. Hence the UI was stuck. Not as if Nokia ever put too much effort into innovating the UI. Touch screens were somewhat frowned upon. Though that may in part have related to the existing UI, the effort needed to try out something new and the fact that those touch screens were still resistive back then. Which is really not a great UX.
Though I remember once trying a prototype phone at an internal conference with a touch screen providing haptic feedback (through some piezo efect). So you could kind of feel the on-screen buttons.
That memo made many people angry, I was at Espoo location the week after and not many happy faces around.
The Symbian teams had finally managed to bring app developers along with platform improvements on Carbide, Qt integration, better POSIX support via PIPS, Symbian was finally looking more modern and then management dropped the bomb.
Naturally it was the last drop for many of those small app developers that had enough of the Symbian SDK changes from the last set of years, now being asked to drop C++ and Java, and rewrite everything into Silverlight/XNA for WP7.
Instead of adopting WP7, most decided it was time to go elsewhere.
The Symbian teams had finally managed to bring app developers along with platform improvements on Carbide, Qt integration, better POSIX support via PIPS, Symbian was finally looking more modern and then management dropped the bomb.
Naturally it was the last drop for many of those small app developers that had enough of the Symbian SDK changes from the last set of years, now being asked to drop C++ and Java, and rewrite everything into Silverlight/XNA for WP7.
Instead of adopting WP7, most decided it was time to go elsewhere.
I vaguely recall Symbian being adopted/developed(?) by Nokia. It's incredible how early Symbian was, but what's most remarkable is that it wasn't even Nokia's only shot at a smartphone OS, they also had Maemo.
It's a shame Nokia is now throwing away everything they know about Symbian. The new nokia OS is shockingly crap. Some functions straight out don't work and other functions such as T9 text are awful. It's a shame when you realise that their old Symbian phones work perfectly well and there was no need to change it.
Nokia hasn't been making phones for a long time. They license the name for HMD Global and the modern devices have nothing to do with Nokia itself.
The even older DCT3 generation of Nokia phones worked much better than Symbian ever did. Nokia 6210 is still a great phone if you only need to call and receive SMS. But anything with a color display from that era is really showing its age by now.
Nokia earned billions from this code. I bet those hours were paid back many times over.
No, they probably didn't earn billions from that code. Their biggest cash cows were feature phones (non-Symbian) that sold 10-50 times as many as Symbian phones and were developed with many times smaller budgets. While some Symbian phones were pretty good for their area, there were probably at least as many failed projects as successful ones.
I don't have any data to back this up, but I think they sold hundreds of millions of high end (and expensive for the time) smartphones running Symbian. Remember the N line? The E line? Communicators? All running Symbian, all bestsellers for years.
No, I remember attending parties when 1 or 2 millions of a model had been sold. At the same time Nokia sold over 100 million of feature phones a year.
Edit:
As you write they were expensive. So while Nokia was the undisputd leader in the segment for a couple of years the absolute numbers were not that big. I remember some year the worldwide phone market was 400 million a year. Nokia had over 100 million of them, but smart phones (Symbian) only single digit millions.
Edit:
As you write they were expensive. So while Nokia was the undisputd leader in the segment for a couple of years the absolute numbers were not that big. I remember some year the worldwide phone market was 400 million a year. Nokia had over 100 million of them, but smart phones (Symbian) only single digit millions.
One model, N95, sold 10 million units. It was priced at around $500. That's 5 billion revenue from one model alone. I'm sure feature phones sold a lot more, but that's irrelevant.
Yes, 10 millions for the N95 sound possible to me. But that was after 10 years of development with many 1000 developers. Revenue is not earnings. The orginal claim was that they earned billions.
Just before the iPhone, I think Nokia were shipping about 70 million Symbian phones a 1/4 and had about 50% of the market profit. Then, it didn’t
Indeed. Every time someone builds a walled garden, effort is duplicated needlessly, both in building it, and in using it.
It is the destiny for most code written.
Anyone who has been in this business for any length of time will look back at a long legacy of retired, obsolete projects. Very little in this space lasts. The high profile, long lived projects we see are just an tiny fraction of the software that's created, used, forgotten, and deleted.
I like to look back and note some of the companies I helped in that little window of time I could contribute, but those contributions are long gone.
We don't build bridges in this business, thats for sure.
I like to look back and note some of the companies I helped in that little window of time I could contribute, but those contributions are long gone.
We don't build bridges in this business, thats for sure.
I have friends who ask me how to set their kids on a path to a tech career like mine. I tell them they may not want that at all. This is a good job, today. But I don't think it is so different from building pickup trucks in Detroit in the 1960s. Nothing lasts forever. Including those trucks, and those jobs. We can't know the future, only that change is inevitable.
Software Manufacturing is a term that best captures my impression of the industry today.
Software Manufacturing is a term that best captures my impression of the industry today.
Not really... it had its use. Code vanishes so quickly.
[deleted]
im still using workbench.
There's a great (and insanely detailed) book on the rise and fall of Symbian by a guy who was there for most, if not all, of the journey:
https://www.amazon.co.uk/Smartphones-beyond-Lessons-remarkab...
When I say detailed, I mean detailed... David Wood seems to have copies of every email and memo he ever wrote when he was there... and he doesn't hold back when it comes to sharing them.
Required reading for anybody seeking to build a platform business.
https://www.amazon.co.uk/Smartphones-beyond-Lessons-remarkab...
When I say detailed, I mean detailed... David Wood seems to have copies of every email and memo he ever wrote when he was there... and he doesn't hold back when it comes to sharing them.
Required reading for anybody seeking to build a platform business.
Find the post in that article by Dennis May. It explains Nokia. The atmosphere in Symbian/Nokia towards the end was really bad.
El Reg has an in-depth review of the book, FWIW.
Here is the single-page view:
https://www.theregister.com/Print/2014/09/12/blockbuster_boo...
Here is the single-page view:
https://www.theregister.com/Print/2014/09/12/blockbuster_boo...
Well, he was a good talker and he seemed a very decent man but I'm not sure he can be divorced from the problems that it had.
I have to cite Nokia N8 [1]. It had USB otg, mini hdmi, FM receiver, FM transmitter, MicroSD memory card, TV out and Nokia later released a TV receiver adapter for it.
A friend of mine had one. He said he spent a few days in the countryside watching films he copied to an SD card on an old tube TV with it. He also told me how he could play MP3 files and listen it on the old FM radio that was available in the house he was in. It was also possible for him, once in a city a few kilometers away, to answer e-mails and read news using WiFi. You could just plug the mini HDMI to a modern TV, plug a keyboard on it and use a Bluetooth mouse to get a fully functional computer where you could even write and run python programs. All this at a time when basically nobody even talked about "convergence".
We've been walking backwards since then. These days the only devices able to give similar power are the still unpolished linuxphones. That's why we should support them or else we will continue walking backwards.
[1] https://en.wikipedia.org/wiki/Nokia_N8
A friend of mine had one. He said he spent a few days in the countryside watching films he copied to an SD card on an old tube TV with it. He also told me how he could play MP3 files and listen it on the old FM radio that was available in the house he was in. It was also possible for him, once in a city a few kilometers away, to answer e-mails and read news using WiFi. You could just plug the mini HDMI to a modern TV, plug a keyboard on it and use a Bluetooth mouse to get a fully functional computer where you could even write and run python programs. All this at a time when basically nobody even talked about "convergence".
We've been walking backwards since then. These days the only devices able to give similar power are the still unpolished linuxphones. That's why we should support them or else we will continue walking backwards.
[1] https://en.wikipedia.org/wiki/Nokia_N8
Originally the N8 was going to run Meego. The N8 should have been a flagship phone running Linux. Instead they chickened out and and went with Symbian instead; pretty late in the development process.
I had an N8. Really nice device. A 13 megapixel camera in 2010? was pretty awesome and the aluminium body plus oled screen were pretty amazing as well. It actually had a screen saver mode that would stay on during the night where they'd only light a few pixels to show a clock.
But it was crippled by the OS; Symbian just wasn't great. And of course it still featured the resistive touch screen instead of a capacitive one (which Apple used).
Meego eventually shipped via the N900 (nice but very awkward form factor) and the only device that could have been great, the N9. Except they launched that years late and with the announcement that whole platform was being cancelled and the phone was for developers only. A misguided UI switch from GTK to QT, which Nokia bought to rescue Symbian did not help either.
Then windows phone started happening and and they unceremoniously killed Symbian. Then they handed the keys to MS. Somewhere in between, Nokia actually shipped a Nokia Android device, which MS promptly killed. Nokia also had another Linux platform (called Meltemi) under development aimed at feature phones. But that whole department got layed off a few months before the MS acquisition. I actually got caught up in that particular round (despite never having worked in that department). In the years after that, tens of thousands of engineers were shown the door. Probably the most bizarre and one of the largest layoff round of highly qualified hardware and software engineers in recent history.
Nokia had a great thing and they ran it straight into the ground. Arrogance and incompetence lead to a lot of bad decision making. The N8 is probably the key moment it went wrong for Nokia. They had all the solutions ready for market and then they chickened out and stuck with Symbian. There was more than a little bit of anger inside the company about that decision. The Symbian camp won and killed the company. Absolutely nothing they tried in the nearly three years that followed worked out.
I had an N8. Really nice device. A 13 megapixel camera in 2010? was pretty awesome and the aluminium body plus oled screen were pretty amazing as well. It actually had a screen saver mode that would stay on during the night where they'd only light a few pixels to show a clock.
But it was crippled by the OS; Symbian just wasn't great. And of course it still featured the resistive touch screen instead of a capacitive one (which Apple used).
Meego eventually shipped via the N900 (nice but very awkward form factor) and the only device that could have been great, the N9. Except they launched that years late and with the announcement that whole platform was being cancelled and the phone was for developers only. A misguided UI switch from GTK to QT, which Nokia bought to rescue Symbian did not help either.
Then windows phone started happening and and they unceremoniously killed Symbian. Then they handed the keys to MS. Somewhere in between, Nokia actually shipped a Nokia Android device, which MS promptly killed. Nokia also had another Linux platform (called Meltemi) under development aimed at feature phones. But that whole department got layed off a few months before the MS acquisition. I actually got caught up in that particular round (despite never having worked in that department). In the years after that, tens of thousands of engineers were shown the door. Probably the most bizarre and one of the largest layoff round of highly qualified hardware and software engineers in recent history.
Nokia had a great thing and they ran it straight into the ground. Arrogance and incompetence lead to a lot of bad decision making. The N8 is probably the key moment it went wrong for Nokia. They had all the solutions ready for market and then they chickened out and stuck with Symbian. There was more than a little bit of anger inside the company about that decision. The Symbian camp won and killed the company. Absolutely nothing they tried in the nearly three years that followed worked out.
I still belief Elop was a MS trojan horse to somehow get the Nokia phone devision to Microsoft. The whole "burning platform" memo together with hamstringing the N9 which was a great phone (I used one until the battery died some day) and OS (maybe we would not have this IOS/android duopoly if Nokia would have really pushed Meego), it all seemed incredibly unprofessional and more like the actions of someone competitor not what the CEO would do.
He was appointed by a Nokia board looking to sell the business to MS. He was a patsy. Most of the bad decision making happened before Elop. And they appointed him to finish the job. The fault lies with the Nokia management and the board, including their former CEO, Jorma Ollila.
If you want to go to politics, the sad reality is that Elop was neither a Trojan horse nor even the thing/person that killed Nokia. What is true is that Nokia was managed as an amalgamation of internally competing departments. The board and the C-level managers (already way before Elop) saw this as a good thing, or at least were too meek to stand up to the department heads. So when the Symbian team did everything it could to harm Maemo/MeeGo (maybe because they saw it as a direct threat to their job security), nobody understood this was massively hurting Nokia as a whole and not serving their customers.
What's more, even if somebody did understand this, any concerns would have fallen on deaf ears as Nokia also had a culture of corporate arrogance. It saw itself as too big & successful to fail. They could make whatever mistakes, but it was alright because they could always revisit and make better decisions later. I don't think they fully realized how wrong they were even years after the Android/iOS duopoly had already solidified - considering how immense amounts of money they kept spending (under M$) in trying to bootstrap the Windows Phone ecosystem that was always destined to fail.
What's more, even if somebody did understand this, any concerns would have fallen on deaf ears as Nokia also had a culture of corporate arrogance. It saw itself as too big & successful to fail. They could make whatever mistakes, but it was alright because they could always revisit and make better decisions later. I don't think they fully realized how wrong they were even years after the Android/iOS duopoly had already solidified - considering how immense amounts of money they kept spending (under M$) in trying to bootstrap the Windows Phone ecosystem that was always destined to fail.
It was capacitive touch. The catch was it was not bonded to the lcd like more modern smart phones are. This meant that it was a 5 minute job by a smart 13 year old to replace the digitizer without needing to replace the lcd.
I loved my N8. Built-in FM transmitter was awesome. And don't get me started on how many times it got dropped and laughed it off. At least 50 times onto concrete and such.
I loved my N8. Built-in FM transmitter was awesome. And don't get me started on how many times it got dropped and laughed it off. At least 50 times onto concrete and such.
Ah true, I forgot about that. The N8 was one of the first devices where they fixed that.
Not sure where your information that n8 was supposed to run Meego comes from, but I remember working with the Nokia s60 team already early 2009 and they were using n8 protos at the time. It’s definitely possible that there were two parallel projects though.
On the other hand, Maemo, the predecessor to Meego, required a pen-like pointer to comfortable use at the time as the UI elements were designed to be small. Only after they completely overhauled the UI (and renamed the Linux based OS Meego) it could have worked on the N8.
On the other hand, Maemo, the predecessor to Meego, required a pen-like pointer to comfortable use at the time as the UI elements were designed to be small. Only after they completely overhauled the UI (and renamed the Linux based OS Meego) it could have worked on the N8.
That would have been around the time when they should have launched a successor to the N800, which launched in 2007. As I recall, the n8 was originally designed to be that.
Meego/maemo had several UI redesigns. The issue was that Nokia just kept ripping it apart instead of just fixing it. The reason for the pen was resistive screens. Bigger buttons would have been an OK solution. The later n900 had the same issue. Ultimately, they bought QT to fix Symbian and then made the Meego team switch to that. They wasted years on the UI. Jolla emerged out of the ashes of that and is still around. Samsung's Bada is another descendant.
Meego/maemo had several UI redesigns. The issue was that Nokia just kept ripping it apart instead of just fixing it. The reason for the pen was resistive screens. Bigger buttons would have been an OK solution. The later n900 had the same issue. Ultimately, they bought QT to fix Symbian and then made the Meego team switch to that. They wasted years on the UI. Jolla emerged out of the ashes of that and is still around. Samsung's Bada is another descendant.
As other's have already mentioned, Symbian traces it routes back to the early Psion Organisers, which ran a pre-emptive multitasking operating system before Windows did, and was thought to be Microsoft's biggest competitor back then [1]. I've used the Psion II, and had a 3a, which you could program in their basic-like OPL language. The 5mx looked like Win95 in a palmtop and was a great pocket computing device with a reasonable keyboard, terminal, email client and internet connectivity. I remember back in 1998 or so looking longingly at the expensive phones that came with a built-in modem (Nokia 6210 and Ericsson R320 from memory), so I could use email and web on the go. Nokia took EPOC and became the lead in the Symbian consortium, using it on spiritual successors of the Psions - the 9300 and 9500, and when the E90 came out with a magnesium case and built in keyboard I had to get one.
That was in 2007, around the time of the first iphone, but was so much more capable. Incredible at that time having all that power in your pocket. I never got lost in foreign cities because I could just get a GPS lock on the train station and find my way back, without using very expensive data in a foreign country. It was a strange thing being able to access the internet anywhere back then. In some ways it was a better time - social media networks hadn't cottoned on to the ability to deliver dopamine from the pockets of world's population, so the device felt powerful, but not like a ball and chain, or distraction-device like my pixel does these days.
[1] https://www.independent.co.uk/news/why-is-bill-gates-so-scar...
That was in 2007, around the time of the first iphone, but was so much more capable. Incredible at that time having all that power in your pocket. I never got lost in foreign cities because I could just get a GPS lock on the train station and find my way back, without using very expensive data in a foreign country. It was a strange thing being able to access the internet anywhere back then. In some ways it was a better time - social media networks hadn't cottoned on to the ability to deliver dopamine from the pockets of world's population, so the device felt powerful, but not like a ball and chain, or distraction-device like my pixel does these days.
[1] https://www.independent.co.uk/news/why-is-bill-gates-so-scar...
Got a lot of nostalgia seeing OPL being mentioned…
Twenty years ago my grandfather gave me his old Psion 3c. To a curious 10-year-old, the novelties of a world clock, spreadsheet and diary grew old after a few hours — but OPL caught my imagination…
Here I am now, two decades later, programming professionally full time as a startup founder — all thanks to a dinky little BASIC-like language on a pocket organizer from the early 90s :)
Twenty years ago my grandfather gave me his old Psion 3c. To a curious 10-year-old, the novelties of a world clock, spreadsheet and diary grew old after a few hours — but OPL caught my imagination…
Here I am now, two decades later, programming professionally full time as a startup founder — all thanks to a dinky little BASIC-like language on a pocket organizer from the early 90s :)
I also had a Nokia N8. The UI was absurdly bad compared to iPhone at the same price.
It's not obvious in Nokia's carefully crafted screenshots, but the N8 UI was very static, slow, and unfriendly to touch actions. It was fundamentally designed around menu navigation on phone keypads. That's not something you can simply fix by making the menu items touchable instead of using arrow keys, yet that's basically what Nokia tried to do.
It's not obvious in Nokia's carefully crafted screenshots, but the N8 UI was very static, slow, and unfriendly to touch actions. It was fundamentally designed around menu navigation on phone keypads. That's not something you can simply fix by making the menu items touchable instead of using arrow keys, yet that's basically what Nokia tried to do.
Besides the awful UI, it missed several key third-party apps that Android and iOS had. Also the GMail integration was pretty bad.
It's funny how the top two comments on this article are (1) yours, talking about how far ahead of its time this phone was, even compared to modern phones in 2022 and (2) another post from a Nokia engineer talking about how frustratingly limited Symbian was thanks to cooperative multitasking, etc.
Of course, both are simultaneously true.
As you say, this phone was definitely ahead of its time as an open computing platform.
I had no idea that it even had an FM transmitter and support for composite video as well as HDMI. Thank you for sharing that.
Of course, both are simultaneously true.
As you say, this phone was definitely ahead of its time as an open computing platform.
I had no idea that it even had an FM transmitter and support for composite video as well as HDMI. Thank you for sharing that.
Symbian wasn't actually limited to cooperative multitasking. The kernel certainly supported preemptive multitasking, and apps could use multithreading if they wanted to. The POSIX threads API was available too.
However since everything in Symbian was designed first and foremost to minimize power use and memory requirements, the framework actively recommended against use of threads. Instead they asked you to schedule things on the app's main thread which gave the framework more control over when to run your callbacks. This wasn't a terrible idea at all, but the implementation of this system as a C++ multiple inheritance contraption was pretty confusing as I recall.
However since everything in Symbian was designed first and foremost to minimize power use and memory requirements, the framework actively recommended against use of threads. Instead they asked you to schedule things on the app's main thread which gave the framework more control over when to run your callbacks. This wasn't a terrible idea at all, but the implementation of this system as a C++ multiple inheritance contraption was pretty confusing as I recall.
CActiveScheduler ran your CActive::RunL(), IIRC
> That's why we should support them or else we will continue walking backwards.
I would love to, but the reality is that unless you're in the Android/iOS duopoly ecosystem, you're increasingly unable to participate in some parts of society. Talking to people, banking, food delivery, parking, public transport...
I would love to, but the reality is that unless you're in the Android/iOS duopoly ecosystem, you're increasingly unable to participate in some parts of society. Talking to people, banking, food delivery, parking, public transport...
Linux on the desktop was similar to that in early 2000's: hardware, software and services were frequently not compatible. The IE monopoly made things even worse. Pioneers suffered, there are still some problems, but the landscape changed drastically because of those people. Some pioneers must be willing to change the world and pay the price for that.
In short, be the change you wish to see in the world. If you want there to be a viable competitor to Chrome, use Firefox. If you want there to be a viable competitor to Apple and Google (and you have the cash), buy a Librem 5. The alternatives are out there, begging to be used.
As an active developer in a programming language with a small ecosystem, I scream this to the clouds all day: great software doesn't become well-supported until somebody has the gall to use it.
As an active developer in a programming language with a small ecosystem, I scream this to the clouds all day: great software doesn't become well-supported until somebody has the gall to use it.
> If you want there to be a viable competitor to Apple and Google (and you have the cash), buy a Librem 5.
No thank you, I will never buy or use any hardware from Purism. They are openly hypocritical and I have zero trust for them.
Quoting from: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
> The RYF has a “secondary processor” exclusion that can be granted on a case by case basis. We will leverage this exclusion to load and train the DDR PHY on the i.MX 8. We will use a secondary processor to keep binary blobs out of u-boot and the kernel.
Add extra silicon, to lock the user out of updating the firmware. Because the FSF will grant you an arbitrary badge of honour if the firmware is closed source, but not user-updatable. This is some next-level bullshit.
This is on top of the hardware being utter crap in terms of protecting user security or privacy; marcan_42 explains it quite well: https://news.ycombinator.com/item?id=30761886
If you want a reasonable trade-off between freedom and security, GrapheneOS is actually the only viable contender I'm aware of.
> If you want there to be a viable competitor to Chrome, use Firefox.
The IE monopoly was broken, because Mozilla made a better product. Also, it took Chrome to fully displace IE.
This is why FOSS can't "win". You have to have a better product, not just a feel-good badge. Look at the FOSS projects out there that are actually successful: they all have a good product strategy behind them. But for most FOSS activists, designing a better product is apparently much harder than indoctrination.
No thank you, I will never buy or use any hardware from Purism. They are openly hypocritical and I have zero trust for them.
Quoting from: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
> The RYF has a “secondary processor” exclusion that can be granted on a case by case basis. We will leverage this exclusion to load and train the DDR PHY on the i.MX 8. We will use a secondary processor to keep binary blobs out of u-boot and the kernel.
Add extra silicon, to lock the user out of updating the firmware. Because the FSF will grant you an arbitrary badge of honour if the firmware is closed source, but not user-updatable. This is some next-level bullshit.
This is on top of the hardware being utter crap in terms of protecting user security or privacy; marcan_42 explains it quite well: https://news.ycombinator.com/item?id=30761886
If you want a reasonable trade-off between freedom and security, GrapheneOS is actually the only viable contender I'm aware of.
> If you want there to be a viable competitor to Chrome, use Firefox.
The IE monopoly was broken, because Mozilla made a better product. Also, it took Chrome to fully displace IE.
This is why FOSS can't "win". You have to have a better product, not just a feel-good badge. Look at the FOSS projects out there that are actually successful: they all have a good product strategy behind them. But for most FOSS activists, designing a better product is apparently much harder than indoctrination.
Keep in mind I was spitballing. Don't take the Librem example too seriously- I didn't know about that stuff, and it certainly changes the way I view Purism.
> This is why FOSS can't "win".
I'm not really sure what "win" means in this context. If "winning" is what Chrome is doing right now, I don't want Firefox to "win" either. Competition is good.
If your argument here is that FOSS can't produce a "better" product, Firefox is as much a counterpoint now as it was when it broke the IE hegemony. For the user, it's just as good as Chrome. It even provides some features Chrome doesn't have (for example, popping out videos and actually-good ad block). Nobody cares about how chrome is 50% (i.e. 0.8ms) faster at responding to thing X.
> This is why FOSS can't "win".
I'm not really sure what "win" means in this context. If "winning" is what Chrome is doing right now, I don't want Firefox to "win" either. Competition is good.
If your argument here is that FOSS can't produce a "better" product, Firefox is as much a counterpoint now as it was when it broke the IE hegemony. For the user, it's just as good as Chrome. It even provides some features Chrome doesn't have (for example, popping out videos and actually-good ad block). Nobody cares about how chrome is 50% (i.e. 0.8ms) faster at responding to thing X.
> Don't take the Librem example too seriously- I didn't know about that stuff, and it certainly changes the way I view Purism.
This is the problem. You advise on something, but you barely look beneath the surface.
> If "winning" is what Chrome is doing right now, I don't want Firefox to "win" either. Competition is good.
Please take a good look at what Mozilla has been busy with, this past decade or so.
https://www.jwz.org/blog/2022/01/mozilla-blinked/ https://www.jwz.org/blog/2020/09/this-is-a-pretty-dire-asses... https://www.jwz.org/blog/2018/12/mozilla-mourns-microsoft/ https://venturebeat.com/2015/06/09/mozilla-responds-to-firef... https://en.wikipedia.org/wiki/Firefox_OS
All this happened while Firefox struggled to modernise the rendering engine, introduce process isolation, address stability and performance issues... Yes I know Quantum eventually delivered on these - but it was too little, too late, and still isn't great.
The only reason Mozilla is still alive, is because Google is throwing money at them - to avoid too much attention from regulators looking at Chrome's market share.
> Nobody cares about how chrome is 50% (i.e. 0.8ms) faster at responding to thing X.
I care. Just put it on any older hardware. Like my 2012 Thinkpad (3rd gen i5; OpenBSD), or my partner's 2017 MBP (infamous for its poor thermal design), running Firefox on either is a miserable experience compared to Iridium (Chromium fork) or Safari. The hardware is still pretty good for our needs.
Don't get me wrong: I dislike Chrome just as much as you do. I want to like Firefox, and I do agree with Mozilla's stated goals and values. But I won't (and wouldn't advise anyone to) personally suffer over this, in fact doing so is doing Mozilla a disservice - they need to get the message, fix their act, and deliver a better product; rather than blowing cash on CEO bonuses, sealing deals to screw their users, or engaging in planet-incinerating ponzi schemes.
This is the problem. You advise on something, but you barely look beneath the surface.
> If "winning" is what Chrome is doing right now, I don't want Firefox to "win" either. Competition is good.
Please take a good look at what Mozilla has been busy with, this past decade or so.
https://www.jwz.org/blog/2022/01/mozilla-blinked/ https://www.jwz.org/blog/2020/09/this-is-a-pretty-dire-asses... https://www.jwz.org/blog/2018/12/mozilla-mourns-microsoft/ https://venturebeat.com/2015/06/09/mozilla-responds-to-firef... https://en.wikipedia.org/wiki/Firefox_OS
All this happened while Firefox struggled to modernise the rendering engine, introduce process isolation, address stability and performance issues... Yes I know Quantum eventually delivered on these - but it was too little, too late, and still isn't great.
The only reason Mozilla is still alive, is because Google is throwing money at them - to avoid too much attention from regulators looking at Chrome's market share.
> Nobody cares about how chrome is 50% (i.e. 0.8ms) faster at responding to thing X.
I care. Just put it on any older hardware. Like my 2012 Thinkpad (3rd gen i5; OpenBSD), or my partner's 2017 MBP (infamous for its poor thermal design), running Firefox on either is a miserable experience compared to Iridium (Chromium fork) or Safari. The hardware is still pretty good for our needs.
Don't get me wrong: I dislike Chrome just as much as you do. I want to like Firefox, and I do agree with Mozilla's stated goals and values. But I won't (and wouldn't advise anyone to) personally suffer over this, in fact doing so is doing Mozilla a disservice - they need to get the message, fix their act, and deliver a better product; rather than blowing cash on CEO bonuses, sealing deals to screw their users, or engaging in planet-incinerating ponzi schemes.
> linuxphones
A hacker friend of mine carries around his pixel, which he has set up to use DAS KEYBOARD (ohne buchstaben) as his Linux development workstation.
This is a wonder to see, honestly. Truly a cyberpunk scenario out there on the edge of linuxphones.
Apropos, I flunk out with my PinephonePro+KB setup, which doesn't work nearly as well as his rig. Grr, power management "last 1%" ..
A hacker friend of mine carries around his pixel, which he has set up to use DAS KEYBOARD (ohne buchstaben) as his Linux development workstation.
This is a wonder to see, honestly. Truly a cyberpunk scenario out there on the edge of linuxphones.
Apropos, I flunk out with my PinephonePro+KB setup, which doesn't work nearly as well as his rig. Grr, power management "last 1%" ..
Yeah, the fact that we call iphone/android smartphones is kind of triggering. Especially in the early days they represented the dumbest phones imaginable, with the only saving grace having a better app-store to try and make up for it.
[deleted]
Spent some time at Nokia when I was fresh out of university. The thrill of getting "hello world" on the screen in Symbian/S60 is not something I'll ever forget. Took ages of battling CodeWarrior and I think even a simple app was something like 6 files, but seeing code I wrote running on a phone in 2004 was pretty awesome.
"Battling CodeWarrior": back when N95 was exciting to mention.
The moved on from CodeWarrior to Carbide, which was based on Eclipse.
Looking through some of this code is a painful reminder of the time when lots of people thought XML was a good idea.
<math result="sf.spec.sbs.numberofjobs" operand1="${env.NUMBER_OF_PROCESSORS}" operation="" operand2="2" datatype="int"/>
instead of
numberofjobs = NUMBER_OF_PROCESSORS 2
Talk about a headwind to productivity.
<math result="sf.spec.sbs.numberofjobs" operand1="${env.NUMBER_OF_PROCESSORS}" operation="" operand2="2" datatype="int"/>
instead of
numberofjobs = NUMBER_OF_PROCESSORS 2
Talk about a headwind to productivity.
Every time I see the templated yaml used widely in devops (see helm charts for example), I'm reminded of this sort of XML used for declarative programming. It was terrible then and it's terrible now.
I cringe at the places I've used XML for things like declarative programming, its just too obnoxious to think about.
However, as someone who is currently pushing bytecode on the wire in place of such things, because reasons, I can only tell you the madness is just a toolchain away.
However, as someone who is currently pushing bytecode on the wire in place of such things, because reasons, I can only tell you the madness is just a toolchain away.
The example he gives may just be a config file. XML was very popular for holding configuration, replacing the ancient property name/value pair system.
A lifetime ago, I spent lots of long hours on reversing Symbian apps, writing tools and tutorials for it. Any old souls here from the reverse engineering community of that era will recognize my username. :)
Was it a waste of time?
Oh, cool. I remember trying to write native apps for my Nokia 5800 and the SDK being... not very good. Also I lacked experience and a sufficiently powerful computer. Also I don't think the thing was documented much, either that or I didn't know where to look for the docs. And the bizarre class naming scheme. And the bizarre dozen types of strings. And the most bizarre custom error handling mechanism (iirc it was called "leave") instead of C++ exceptions.
I do wonder if this code is enough to build a working firmware image for a Nokia phone, but most probably some of the required parts are missing.
I do wonder if this code is enough to build a working firmware image for a Nokia phone, but most probably some of the required parts are missing.
It is not, unfortunately. It's missing plenty of proprietary middleware etc that you need to run it on Nokia phones.
IIRC you are supposedly able to build and run this source dump on some BeagleBoard.
I was there, coding multimedia stuff for the last generation of Symbian smartphones. I remember this dump was originally released on Gitorious (later acquired by GitLab) some 10++ years ago.
Fun fact: the source was originally supposed to be licensed under a different roll-your-own open source license (I think it was named "Symbian Foundation License" or something like that) but Nokia switched to Eclipse Public License 1.0 before the public release.
IIRC you are supposedly able to build and run this source dump on some BeagleBoard.
I was there, coding multimedia stuff for the last generation of Symbian smartphones. I remember this dump was originally released on Gitorious (later acquired by GitLab) some 10++ years ago.
Fun fact: the source was originally supposed to be licensed under a different roll-your-own open source license (I think it was named "Symbian Foundation License" or something like that) but Nokia switched to Eclipse Public License 1.0 before the public release.
I worked on Symbian aka EPOC around the early to mid 2000. Trips down to London to visit their offices. I'm still connected to some of the guys on Facebook from that time.
It was one of my first roles outside of Uni, boy getting exposed to everything from low level system software and kernels to application development, and API creation. I learnt so much. Much of which, in principle is still valid.
I learnt a lot from the other developers and engineers a met.
Remember sitting a room with David Wood, where we talked through the creation of a book about Python development / entry level development on the platform. I still recall David's view that we should use the best, easiest, and also most expensive tooling in the book. But that seemed to lock so many people out of the ecosystem.
Anyway - to many memories, and so much I learnt. Meeting PhDs, and Grads today who struggle with how C/C++ works, I'm really lucky I got the chance to work on it when I did. And now I've a craving for a Series 5mx... ebay here I come...
It was one of my first roles outside of Uni, boy getting exposed to everything from low level system software and kernels to application development, and API creation. I learnt so much. Much of which, in principle is still valid.
I learnt a lot from the other developers and engineers a met.
Remember sitting a room with David Wood, where we talked through the creation of a book about Python development / entry level development on the platform. I still recall David's view that we should use the best, easiest, and also most expensive tooling in the book. But that seemed to lock so many people out of the ecosystem.
Anyway - to many memories, and so much I learnt. Meeting PhDs, and Grads today who struggle with how C/C++ works, I'm really lucky I got the chance to work on it when I did. And now I've a craving for a Series 5mx... ebay here I come...
Am I the only person who saw this post and figured that it was the source code for a Sybian machine and rolled my eyes, thinking, "How sophisticated could it be, really?"
That closeness of name was pointed out back in the 20th century when the name was announced.
But then again, remember the somewhat deserved reputation for awareness of that other product line in the software/techie world...
https://www.penny-arcade.com/comic/2003/06/30/also-known-as-...
But then again, remember the somewhat deserved reputation for awareness of that other product line in the software/techie world...
https://www.penny-arcade.com/comic/2003/06/30/also-known-as-...
Harsh, but fair.
No LICENSE files. Is this official or a leak?
Pretty sure these are from when they open sourced it in an attempt to drive adoption.
I just looked at a couple of the files, it looks like license info is inline
I had a similar thought. Tried not to look at anything besides the presence of a license file.
I was looking for their implementation of T9, but haven't found it yet. Would that be in here? Does anyone with more context or Google-foo know where it is?
Fond memories of running my day to day (email, diary, expenses, task management) of a Psion 3a with 3xAA batteries and a modem/cable to my Nokia mobile.
A high school friend and I decided to try and port the .NET Compact Framework to Symbian OS, specifically Series 60. The company (https://web.archive.org/web/20100112091803/http://www.redfiv...) was based in Johannesburg, South Africa and although we raised funding, we just took way too long.
We were lucky enough to be able to bootstrap some things with the Mono/Xamarin .NET implementation. Initially we created an interpreter but then created a full JIT compiler. It was not easy, to say the least, getting things to work on that platform.
What also didn’t help was the level of support we got from Symbian/Nokia; our project/startup was mostly met with indifference. By the time we had a viable, mostly functioning .NET Compact Framework v2 running the writing was on the wall vs iPhone.
We were lucky enough to be able to bootstrap some things with the Mono/Xamarin .NET implementation. Initially we created an interpreter but then created a full JIT compiler. It was not easy, to say the least, getting things to work on that platform.
What also didn’t help was the level of support we got from Symbian/Nokia; our project/startup was mostly met with indifference. By the time we had a viable, mostly functioning .NET Compact Framework v2 running the writing was on the wall vs iPhone.
Wow. I did a quick random sample of their code and it's really clean, which is especially impressive in the bare-metal domain.
Maybe it's because I'm young, but the naming scheme is asinine. theThings? aThing? Why?
For anyone wanting to play Nokia N-Gage games (S60? I forget), there is already a lengthy walkthrough and setup of how to emulate the games on Windows that is available on The Internet Archive; complete with a torrent/zip of all the games on the system.
Really? Because as far as I know the N-Gage emulator is far behind.
hmd global should really bring back the ngage
Links, please. (:
This was what my team developed - a build system that worked properly with parallelism. I'm still very proud of it even though there were design issues, it was really quite innovative in its way and the only big mistake was to make it so Symbian specific:
https://github.com/SymbianSource/oss.FCL.sftools.dev.build/t...
https://github.com/SymbianSource/oss.FCL.sftools.dev.build/t...
This reminds me of those android tv boxes. Their spec is pretty good to run linux.
Is there generic way to convert them to say arch/ubuntu linux?
I've played some with those and it's not pretty. It's all the pain you get with commercial SBCs except: even less support, much lower quality hardware, and terrible thermal solutions (ventilation holes under the case with no feet and tiny/non-existent heatsinks).
In the end what killed my interest in them is that the cheapest you can get those is like 30 USD and for that price you can also get X86 thin clients that are just better in every single way.
Still, if you want to get your feet wet I suggest you start with RK3318. Those boards are much harder to brick than AmLogic and are the only ones with at least some support from Armbian: https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318...
In the end what killed my interest in them is that the cheapest you can get those is like 30 USD and for that price you can also get X86 thin clients that are just better in every single way.
Still, if you want to get your feet wet I suggest you start with RK3318. Those boards are much harder to brick than AmLogic and are the only ones with at least some support from Armbian: https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318...
If they can be boot-unlocked and run a custom ROM, you could look into supporting them under postmarketOS. That's the closest we get to a clean Linux install on AOSP-native devices.
I think you will need to be specific. Which particular make/model do you have in mind? Have you looked to see if someone's already done it?
I remember FCA00000, a Spanish guy who would write articles in Spanish for a long lost ezine about the internals of Symbian.
Here are the release notes for Symbian kernel
https://github.com/SymbianSource/oss.FCL.sf.os.kernelhwsrv/b...
1998 - 2010
https://github.com/SymbianSource/oss.FCL.sf.os.kernelhwsrv/b...
1998 - 2010
What a nice platform it was to use as a consumer, but terrible to program as a programmer.
Compared to iOS and Android development, Symbian was extremely hard, and iOS was much easy even with a whole new language (Objective-C, not the shiny Swift) to learn.
Compared to iOS and Android development, Symbian was extremely hard, and iOS was much easy even with a whole new language (Objective-C, not the shiny Swift) to learn.
It feels like Garmin devices are still dependent on this era's tools. When someone asks me about issues with using my Garmin Edge 1030 for navigation, I often say it works fine enough but it is sort of like using a Symbian phone in the early 2000s.
I think a fair amount of Symbian devs went to Garmin when Symbian ceased to exist.
Great to see the code up there on GitHub. So many cogent points made here. It brings it all back to me. What happened there from Symbian to Nokia and then Accenture ought to be taught in MBA programmes as a Greek tragedy.
Repo seems to contain personal data of employees. I won't post a link to it.
Wow, memory lane here. My first programming job was working on Symbian apps. I think I had a 1MB heap and something like an 8KB stack to work with. Good times!
My first smartphone was a Nokia running Symbian.
wow this gives me nostalgia. Symbian was probably the start of the smartphones era.
Is it all licensed as Eclipse Public License v1.0?
And for that he needed quite a few people to agree and he had to sign an NDA (again, as an employee, not a subcontractor!). Then, of course the whole thing was pretty hard to make work on his machine.
Later on I did some work with the (public) SDK as well. The build system was based on the GNU toolchain. More precisely, a windows port of the GNU toolchain, so it would only work on windows. But even on windows it had a lot of warts (because these tools were build for unix in the first place, so e.g. drive letters and back slashes were problematic). As far as I can remember, a lot of the build tools were written in perl. There was some script to generate makefiles for your project and even that, as far as I can remember had a front end script. (I remember something called MAKMAKE.BAT, but I may be wrong.)
The whole thing was a pretty frustrating experience. And we haven't talked about the libraries, the OS (cooperative multi tasking, everything is a callback) or memory management ('descriptors' that made trivial string operations a pain). No wonder it couldn't keep up with android and ios. Now, to be fair, the OS was based on a core and concepts created in the mid 1990s to allow software development on devices with 64k of memory or something. But even with several megabytes of RAM (so the early 2000s), that programming model was obviously way too constraining.