Hacker News new | past | comments | ask | show | jobs | submit login
Symbian Won (shkspr.mobi)
512 points by edent on June 25, 2020 | hide | past | favorite | 284 comments

I used work for Symbian. The OS itself was great at the time (it's open sourced somewhere), and got security correct (I don't recall 'privacy' ever being an explicit goal) but it was an absolute bitch to develop for. It had its own dialect of C++ which looks nothing like modern C++, the learning curve was huge. It tried really hard to have an app ecosystem but it was nothing like what google and apple have today. Network operators desperately wanted an alternative ecosystem to avoid being dependent on Android and Apple (but mainly I believe so that they could build their own walled gardens).

But by the time Nokia took over Symbian it became apparent that they saw Linux as the future OS for high-end devices and Symbian was to be relegated to mid-level devices.

I am Brazillian, and I think killing Symbian was a huge and stupid mistake.

When Microsoft release that memo that killed Symbian, in Brazil its marketshare was INCREASING, there was a lot of people learning how to code for it, many people saw it as a good future, because with it you could make blazing fast CHEAP phones, iPhones were crazy expensive, and android was a slow buggy mess.

Thing is... iPhones are STILL crazy expensive, and android STILL is a slow buggy mess if you buy a cheap one.

I am yet to find a smartphone I like as much I liked symbian based phones, that are phones first, smart second, and work great for actually phoning people.

Symbian Belle, the last iteration was just great.

I only moved to Android when forced to.

And this whole notion of "Symbian Won" reminds me how "Windows Phone Won" too. Just look at the latest iOS 14 widgets which is inspired by WP tiles.

I could enable GPS and leave the phone on without charging... for THREE WEEKS at a time.

GPS is a completely passive signal, so it's not really surprising that it lasts a long time. You can get similar battery life with IoT SoCs deployed on the field.

The difference between then and now is that modern smartphones use sensor fusion, combining cellular, WiFi, and GPS signals to generate a location. The end result is more accurate output, at the expense of battery life.

> The end result is more accurate output, at the expense of battery life.

Do you have sources? GPS is passive, yes, but the signal is very weak and several orders of magnitude below the noise threshold. Keeping receiver circuits enabled for a long time costs battery power as well. WiFi information can be obtained entirely passively as well, as AP's transmit their info regularly.

I think the difference rather comes from lots of bloaty background services on Android.

My understanding is that cheaper devices (at least historically) tended not to have a discrete chip for handling GPS, which could run extremely efficiently and at very low power, and instead were forced to use the CPU to do the work - contributing to the reputation of being slow and power inefficient.

Modern devices do the sensor fusion on CPU but it's just polling the GPS chip for coordinates as required, which handles all the actual signals processing stuff.

Are there any phones that allow you to customize this? I recall Android having a Developer Options setting for GPS + WiFi or just GPS for Location Accuracy. But IIRC, this didn't make a substantial impact to battery life. Maybe because I'm not a passive phone user.

That device was not continuously receiving a GPS signal. It was relying on network location services, and maybe occasionally waking up the GPS receiver.

Symbian was a dead OS walking when they killed it. They might have been able to keep it struggling along for a few more years but due to fundamental architectural limitations it would have fallen further and further behind iOS and Android.

I worked at Nokia starting in about 2004. Looking back on my career, one of the single greatest feelings of accomplishment was getting a Hello World application to run on Symbian/S60. I thought I knew C++ going in, but I wasn't prepared for two phase constructors and the 6 files you'd need to draw a simple list view on the screen. Felt amazing once it worked though!

Lol. At least you guys had actual phones to work with. Until we became Nokia all we had was a techview UI shell running on H2, or later, H4 boards that would boot an MMC card. Of course, when we became Nokia we got the flashing stations and access to Phoenix. Only a particular part of the company ever saw phones that were in development and you needed special access to get into that part of the building.

> Only a particular part of the company ever saw phones that were in development and you needed special access to get into that part of the building.

Oh, I remember it was near impossible to get access to service manuals Level 1 & 2 (just for understand how to repair/replace few parts on my N82), and fully impossible get its Level 3 & 4.[0]

AIKON service centers had monopoly on repairing devices.

[0] http://www.s-manuals.com/phone/nokia_n82

First job out of uni was writing device drivers for Motorola Symbian devices on H4 boards (I want to say LDDs and PDDs?). Codewarrior or carbide if you fancied a reboot every 2 mins, 40 minute turn-around times to flash and boot your software, boards without working SD and having to log to the screen ...I do not miss those days at all. BlackBerry was like a bloody dream.

I also went through a dev board phase later on when I was working on Maemo, etc. but they took it easy on me when I was fresh out of school and let me have real production hardware

I totally know what you mean - the sense of satisfaction and joy when you get even the most basic "end-to-end" functionality working in a new environment is hard to match.

It still is; try blink or counter on a new fpga board.

I loved symbian and the whole "java on phone" never seemed right to me. I would prefer having a linux phone - I dont ask for much - working camera, working calls, mms and sms, gps, bluetooth). I dont care for anything else.

All my hopes are now leaning into Cosmo Communicator( https://www.indiegogo.com/projects/cosmo-communicator - please take care, I have jumped into this with "I will loose my money" mentality - I still dont trust, they will realize the linux part, but hope dies last), it reminds me of beloved Nokia Communicator and if they realize my conditions (camera, calls, mms, sms - gps already works same as bluetooth ) I will give my foot a very long swing and remove my Android phone (even if heavly modified) from my life.

PinePhone and Librem 5 are better options for Linux phones:

https://www.pine64.org/pinephone/ https://shop.puri.sm/shop/librem-5/

Also, F(x)tec are making a keyboard based mobile device along the lines of Cosmo and N900.


As an owner of a Gemini, the hardware is innovative and good enough, but the OS is really an afterthought. You can browse their current wiki and see how organised it is.

No disrespect to the team, it just seems like taking sufficient care of this is a bigger job than they have the resources for.

But I'm glad I backed the kickstarter, and would do the same for something similar in order to diversify a very un-diverse market.

I agree, but they have announced initial voice call support for linux (update 78) and this is actually quite close to what I want :)

Still cannot get back to linux. Now just an android phone with a keyboard.

> the whole "java on phone" never seemed right to me

I'm not sure which Java on phone you are referring to, the Android Java or the older J2ME. The older J2ME apps ran well in limited resources, but was also incredibly complicated to develop due to device fragmentation.

I have one of planet's previous devices, the gemini. It's not very good. The software is some unpatched old android. And the available linux doesn't support very much.

I'll have to try the pinephone next, but I have much higher hopes for it.

The indiegogo page seems to imply that they're shipping these devices. Have you not received yours? The simulated pictures look nice...

I already have it, but it is usefull for me only as linux device (well until they release v22 firmware to mod it). But my main motive for buying it was linux/sailfish.

Symbian was great, and I loved my indestructible all-silver Nokia E61 non-US version (which included WiFi, unlike the carrier-crippled ones I found in the US).


I actually looked recently at trying to buy another E61 in good condition, and how much trouble it would be to kludge up access to my email through it. I figured it would be more productive for email than my current mainstream smartphone setup.

I have to resist the urge to look into this open-sourced Symbian... :)

My beloved E6 had its flaws. It was a pain to sync, the syncs were not serviceable, but at least it was syncing to my computer, not to the cloud. On this one, Symbian Anna felt better than Symbian Belle and it would have been a pain to revert.

That said, it was small, smaller than an iPhone SE. And it had a hardware keyboard. I'm not against fancy apps and stuff on my phone but, besides calling reliability, the first thing I want is to be able to type small things.

I must confess I was unhappy that it even had a touchscreen: a nightmare when it was raining. I guess I just loved the form factor and its promises.

I'm thinking of making this an ode. The E6 ballad. Sorry for that long little-informative comment...

But when J2ME support was added, it became easy to develop apps. I used to develop J2ME apps as hobby, I made a game and took it for my first job interview. In that job I had to port a 30,000+ J2ME code app to Android in 2010. The company I worked for was even experimenting with NFC payments in Nokia Symbian phones in 2010!

> But when J2ME support was added, it became easy to develop apps.

And adding Python support for S60 (PyS60) was the best gift by Nokia for users as it brings Symbian devices to be "on-the-go handheld devs tool for developing apps without desktop PC".[0]

Has you ever know that there is fully functional Blender-like 3D mesh editor & animator app written in Python for S60 (PyS60) directly on Symbian smartphone?[1]

[0] https://en.wikipedia.org/wiki/Python_for_S60

[1] https://twitter.com/app4soft/status/1251175469044637696

Oh my, this thread is bringing back sweet nostalgia!

>And adding Python support for S60 (PyS60) was best gift by Nokia

Yeah installing python interpreter in S60 on my Nokia N70 ME, motivated me to checkout Python programming book from my college library. As I was reading it in the class during break, the top-ranking girl student came across and asked me "Why Python, isn't it a dead language?"(circa 2006-2007) I assumed she must be right, I didn't write python until several years later; I bet she's using Python in her job now.

So if all these things were possible on Symbian so early what in the world happened that they lost the market race so badly. Too much engineering-driven design? Lack of a unifying Jobs-esque force at the top to make hard decisions?


• iPhone's capacitive touch screen vs Nokia's resistive touch with stylus requirement was too much of a friction (pun not intended). 1 year after iPhone's release, Nokia released 5800 marketed as iPhone killer; guess what? it had f'in stylus with resistive screen.

• Then when android happened, which was poor man's iPhone; Nokia hugged Windows Phone OS. Which never became a thing as it lacked Google apps (Google killed it, MSFT would have done the same to Google if places were interchanged). Other comments have detailed possible leadership sabotage related to the MSFT deal, which I agree with.

> 1 year after iPhone's release, Nokia released 5800 marketed as iPhone killer; guess what?

I guess beside its resistive screen, Nokia 5800 has much more power than iPhone 3G:

- J2ME apps;

- Python for S60 apps (+ Pys60 IDE);

- Qt4 apps;

- Voice input;

- Built-in voice recorder;

- Video recording;

- Frontal camera for video calls;

- 3.2 Megapixel camera with zoom & flash;

- 35 hours of work in music player mode;

- Changeable battery;

- And much, much more.

Here is good comparison list (in Russian).[0]

[0] http://mobiltelefon.ru/post_122880924.html

That's true of several mobile hardware/SW of that time, I mentioned capacitive screen to show typical consumer preference.

Btw, you can also add native 3G video calling via front camera to that list, my Nokia N70 did that years earlier in India. Not many westerners seem to know about this feature in my earlier discussions.

Reading around on the Internet a bit I came upon this [1] which indicates Nokia's leadership was less engineering-driven than I thought.

[1] https://knowledge.insead.edu/strategy/who-killed-nokia-nokia...

Which is to be expected when one gets a contract from the shareholders with a bonus clause if the CEO manages to devalue the company and sell it.

US market was never keen in Nokia devices and Android is free beer.

The market have shifted. Before iphone, everyone was trying to build the smalles phone possible. Jobs convinced the world for brick sized devices and SymbianOS lost its USP - doing a lot on small batteriess. Had there been a wearables market back then, it could have had a second lease of life.

> So if all these things were possible on Symbian so early what in the world happened that they lost the market race so badly.

TL;DR: "Operation Elop" organized by Microsoft...[0]

[0] https://asokan.org/operation-elop/

Actually by Nokia shareholders, including a big bonus for managing to sell mobile division.

No. Nokia just sold its business to new owner, but new owner killed it.

Which is why Elop got the bonus from Nokia shareholders as per the signed contract. Finn press found out all the dirt about the contract back then, and the news are still relatively easy to track down.

The J2ME world never really felt easy to me:

What worked on 1 device didn't on another, there was very limited shared UI, and it felt like it was impossible to target multiple devices.

There were MIDP profiles[1] as long the version matched, the apps worked fine in my experience on any device although the devices themselves varied in their key pad placements; Nokia went crazy in their phone designs[2]!



Wow, thanks for that video down memory lane.

I had a 3660 (friends called it the "communications brick"). There was no wifi and I couldn't afford a data plan but I was able to have the phone dialup via Bluetooth (think "reverse tether") to my Linux desktop. I never got into J2ME: being a fledgling Linux snob in college, I went for Nokia's C++ target and got stuck in the quagmire.

But MIDP profiles were so limited that you could only build the simplest apps. To do anything complex required calling proprietary extensions, which destroyed portability.

Yeah, the portability on Android is wonderful. /s

Just like Android.

I can't edit my comment, but the source code seems to be here: https://github.com/SymbianSource

I could never accept the coding standard for curly bracket positioning.

> I could never accept the coding standard for curly bracket positioning.

OK, so I had to look.

It's like they saw the two main camps (same line vs next line) and said "let's come up with something everyone will hate":

    TInt GetROMSize(TInt /*aDeviceNumber*/, TInt /*aAttrib*/, TBool /*aSet*/, TAny* aInOut)
        TMemoryInfoV1 info;
        TPckg<TMemoryInfoV1> infoPckg(info);
        TInt r=UserSvr::HalFunction(EHalGroupKernel, EKernelHalMemoryInfo, (TAny*)&infoPckg, NULL);
        if (r==KErrNone)
        return r;

I can understand the desire to have the brackets at the same indent... but WOW does this break my brain having the inner code not indented from the bracket level. (I tend to prefer the opening backet being on the same line as the condition gate/guard and rely on the parser to inform me of missing brackets. This is even better in languages that have a single format convention.)

Wow. I had a CS professor insist on exactly that style. I couldn't stand it at first, but making accommodations was the whole point. Unfortunately it got me thinking about what I would want. Now I'm the weirdo and I rarely get to write it the way I want. <shrug>

> I could never accept the coding standard for curly bracket positioning.

Hahaha, how bad could it be...

... Why the fuck would they need to indent every function by an 8-space tab!?

I worked at STMicro for a while, and a neighboring team worked on Symbian support. I remember they had this weird coding standard that was essentially "why the fuck not?".

Now, over a decade later, I understand that they looked at the Symbian standard, and saw that anything goes.

8-space using the tab character is the Linux kernel standard, but the curly braces are closer to other coding standards.

It's not the 8-space I'm aghast about, but that every function body is indented by it.

Whitesmiths style is for sadists.

There are few more places where you could grab Symbian sources.[0]

[0] https://mrrosset.github.io/Symbian-Archive/Links.html

Hah, I've worked on such styled legacy project from the European client. Seems like this style was popular in Europe during 90s :)

Oh, I got a Symbian phone when I was 16 (I think?) and of course I did try writing native apps for it. Yes, the SDK was horrendous. The C++ dialect was so weird I was never able to make sense of it. (I probably could with my current experience.) I just remember that there were many, many methods that ended with L, this meant "Leave", and this was some bizarre replacement for exceptions, apparently. There were more types of strings than I could count. The naming conventions for things were very weird. The hello world consisted of something like 5 classes and took a minute to build. When you wanted to actually run the thing you made, you had two options: running it in an emulator that took several seconds to process inputs, or running it on your phone via some connector app that only worked 1/3 of the time.

I didn't get very far with native Symbian development. J2ME was just so much easier, and ran on everything under the Sun (pun intended).

Oh god I've got flashbacks of those weird exception stacks you had to manage manually

> It had its own dialect of C++ which looks nothing like modern C++

Was this just a "using different elements of C++" kind of dialect, or was this an "early Win32 when you had to use pretend-C++ (ATL) together with your real C++, bridging the two with C" kind of dialect?

I feel like a lot of application frameworks developed in the 90s ended up in the latter style, as C++ was just becoming popular around then, and many frameworks chose to "merge into" C++ support from C support, rather than creating a ground-up C++ SDK.


No std::string

Custom exceptions (no explicit try...catch, I think only ints could be 'thrown')

2-phase construction for C-classes.

Explicit lifetime management (to be fair RAII wasn't a thing in 'normal' C++ at the time either)

Link by ordinal

One interesting thing was that there were mandated, and strictly enforced, naming conventions and coding style. For example, above I mentioned C-classes. You had to use these in certain circumstances by inheriting from a CBase class. This gave you a virtual destructor and zero-initialised the memory. R-classes were resources classes mainly for things that needed Open and Close functionality.

I joined straight out of university and probably learned more about softare development in my first 6 months at Symbian than in 4 years of uni. There were some incredibly clever people there.

> (to be fair RAII wasn't a thing in 'normal' C++ at the time either)

RAII in C++ dates back to 1984-1989, and Strousop wrote about it in his 1994 book Design and Evolution of C++. And C++98 had auto_ptr<>. Symbian's release in 1997 means it had a weird timing relationship with C++ standardization, but RAII was still enough of a thing at the time to be in that very first standardized STL release.

Turbo Vision, OWL and MFC also made liberal use of RAII.

There is Alexander Trufanov's free book (in Russian) on programming for Symbian 9.x with many code samples.[0]

Also, as example of complex apps, there is code of Lonely Cat Games' X-plore[1] & ProfiMail[2] apps, released to Public Domain by LCG devs in 2015-2016.

Another one Symbian open-source app that I like: `fshell` — Symbian equivalent of bash + telnet + a posix-like set of command-line tools.[3]

And the latest app in development: S60Maps — OpenStreetMap & GPS tracker.[4]

FTR, Actually there is an experimental Symbian OS emulator for Linux & Windows.[5]

P.S.: And off course there are tons of useful stuff collected by "Symbian Archive" wiki.[6,7]

[0] https://github.com/trufanov-nok/SymbianBook_ru

[1] https://github.com/Symbian9/X-plore_free

[2] https://github.com/Symbian9/ProfiMail_free

[3] https://sourceforge.net/p/fshell/code/

[4] https://github.com/artem78/s60-maps

[5] https://github.com/EKA2L1/EKA2L1

[6] https://mrrosset.github.io/Symbian-Archive/

[7] https://github.com/mrRosset/Symbian-Archive

I was responsible for porting a fairly large C++ app to Symbian (this was like 15 years ago, so memory is hazy). The big problems were that exceptions were weird and non-standard, and you couldn't throw them from constructors, so anything using RAII had to be rewritten.

and it used their own proprietary toolchain, as a layer on top of visual studio iirc, that kind of worked in debug but actually no, I remember we had to purchase a specific nokia to run in dev mode, as not every nokia supported it or was actually supported by the toolchain at the time.

and I remember another pain point was feature detection, but can't recall the specifics.

I think VS was used before my time (2005), but then it used CodeWarrior and then after that Nokia's own IDE called Carbide.

It had MMP files which described the project and the files in it, a then a tool called 'abld' which was a perl script that did the compiling, which actually had two commands to clean... 'abld clean' and 'abld reallyclean' :)

RAII can be used without constructors and without exceptions. The acronym is misleading.

Yes, but if you have a large existing codebase that throws exceptions from constructors you can't just use it unchanged.

This documentation is for a very old version of the OS (I think it got up to 9.4 by the time it was sunsetted?).

Here is how it did its version of std::string:


It actually wasn't too bad once it was beaten into you by the compiler and code reviews. Non-embedded C++ devs can count their lucky stars.

My boss at the Austria Press Agency wanted a software to distribute our news to Mobile Phones in 2004 or 5 or so.

So I took a deep dive into Symbian with very limited C++ understanding. It took me at least a month to figure that that C++ is not C++ at all.

In the end senior engineers, were put on it. Project went nowhere. And then came iPhone and we went down the Mobile Browser Road (years later Apps I think).

They adopted C++ very early on in the language's life. The standard at the time had not even specified how exceptions worked, so Symbian rolled their own (TRAP and User::Leave).

But then they were stuck... breaking ABI was forbidden, so more modern C++ features couldn't be used (easily).

C++ was created in 1979 - I doubt Symbian adopted it "very early".

Also, the standard doesn't specify "how exceptions work" even today, in the sense that a lot of what happens when running C++ is implementation dependent.

But I can see what you mean about sticking to pre-C++11 (maybe even pre-C++98 ?) APIs.

The first C++ standardization was C++98, released in (you guessed it) 1998. Symbian's first release, under the EPOC32 name, was in 1997, with working starting on that OS in 1994 (and the company had a prior OS, EPOC16, that was from the late 80s)

In 1998 c++ was a totally different ballgame to c++ in 2010 let alone now

From the inside it wasn't that apparent, hence why the first Linux based prototypes did not had any radio support.

And as cumbersome as Symbian C++ might have been, Android Studio + NDK + JNI wrappers still make me wish for Carbide + Symbian C++ + PIPS.

Originally we used CodeWarrior internally and then Carbide. Most of the Carbide work was done in Dallas and I remember them having a stressful time dealing with Symbian's weird MMP + abld build system.

Yeah, I know also those nice Perl based scripts with batch files glue somehow being called from CodeWarrior, just referred Carbide, because at the end the experience wasn't that bad, specially by the Belle days.

Google just doesn't get it, note that major GDC 2020 Android talks are mostly related to NDK improvements, 10 years later.

Although the NDK is really annoying, it's not required to build an app, which it seems like Symbian C++ was. I think that's critical for getting the app ecosystem off the ground.

You could use Java, Flash, Python and Web Runtime as alternatives back then. Much richer than Android still.

Thanks for the clarification :) It was before my time.

Android studio and jni dev is pretty trivial TBH. It even builds the boilerplate for you

Try to generate boilerplate code for calling permissions API from C++.

NDK is designed for Java => NDK libraries only.

Well I'm generally only writing interfaces for native code I've written.

Was it the case where no globals were allowed, since "executables" (not really) were more remiscent of dll/shared libs/etc.?

Good question, I can't remember if globals were allowed, maybe they were as long as they were const so the OS could be executed directly from ROM. But again, I'm not sure, it's been some time.

The Symbian source code was only briefly public and open source, it got closed and unpublished again fairly quickly.

Oh I always want to write C/C++ code on a Non-Apple mobile but I didn't expect it to be THAT weird...

You could even program in Python!

This really reminds me of good times

I started a company with friends to write games for phones, before they were smart

Our fist breakthrough was at E3 in LA with a game for Nokia 7650, but we worked on prototypes years before

My first mobile connection was with a Nokia 9000i communicator, I was working for an ISP at the time that gave them to us to test mobile connections, and it felt like a James Bond movie

I learned so much developing on Symbian, especially being a diligent C++ programmer on a system that wasn't really using standard C++

Fast forward 20 years, I work on backends in Erlang/Elixir and never touched mobile development again

J2ME was nice, but limited, I lost hope soon after when iPhones came out and it was clear that the mobile platform wouldn't be fun anymore

When I moved from the UK to the US in early 2006 I lost my Symbian-running 6680 Nokia, because it couldn't be ported over, it was locked to a UK network and they refused to unlock it. I loved Symbian at the time, losing it took me back to the dark ages.

In the UK I'd had my Nokia 6680 with front and rear cameras, unlimited 3G, multi-tasking apps, a proper web browser, the ability to install apps, and even some crap ability to watch TV. It also had a memory card for storing and playing music. I had it connected to my Powerbook (17" powerbook was my best laptop ever), and had 3G usable browsing speeds anywhere, wirelessly through bluetooth, and the phone's 3G. It synced contacts, emails, etc.

Coming to the US I got the latest and greatest - a Razor. It had an OS that felt like going back to the 70s. No 3G. No camera at all. No apps or ability to use them. Contacts on the SIM with no decent data. All it could do well was text or call.

Even the first iPhones were well behind the Symbian/6680 combo I'd had for a while in the UK (no 3G, no apps, no multi-tasking, no front camera), and it wasn't until the iPhone 4 in 2010 that I got the front camera back, which meant I had feature parity with what I'd had in the UK in 2005.

I was big into Symbian before iOS and Android came around, and I was incredibly excited to buy the N95, the (then) flagship phone. I purchased the US variant of the phone very shortly after its launch date from the Nokia store in NYC.

This was one of the few Symbian phones to make it to American shores with our 3G bands, and at the time it was notable for having the best camera available.

I loved the device, but the same year the original iPhone came out. On the spec sheet it was worse in every way - no third party apps, no 3g, etc etc. But the market spoke quickly, and the N95 became the last Nokia device I would own.

I always thought it was a shame that the high end Nokia devices failed to really target the US market. Usually they were lacking key frequencies, and/or only available unlocked (without any carrier subsidies). Had Nokia been better situated here, perhaps they could have presented some real competition to the iPhone, but there was no way people were going to go specifically seek out an expensive, high end Symbian phone when AT&T had subsidized iPhones and a massive advertising blitz.

To be fair, it was possible to buy Windows, Palm, and Symbian phones in the US in the 2000s. I owned a few for fun, far after they were outdated. But my Nokia E51 worked amazingly, and I used it right as the iPhone was released.

I then switched to a Palm Pixi :D

The Razr's had a camera... it might have been useless, but they did have one.

> With the latest releases of Android and iOS, we’re back to where we started. Both now prompt you the first time an app asks for access. Both give you regular reminders of which apps may be snaffling your data. Both let you manage access and selectively deny apps.

Every OS should do this, desktop OSes included. For the last 2 decades I've been using personal firewalls on Windows to do just this, now I use LittleSnitch on Mac (I just hope it's going to keep working on ARM macs), AFWall+ and XPrivacy on Android and miss this level of control terribly on Linux (it sort of can be achieved with AppArmor or SELinux but both are nightmares to use).

If only iptables would allow to filter by the executable path and other process parameters - that would be just so awesome. There was such a feature in some 2.x kernel but, sadly, it was deprecated long ago.

>if only iptables would allow to filter by the executable path and other process parameters

The problem going down that route is that implementing this opens a huge can of worms. That stuff is easy to spoof, you have to account for thousands of edge cases. It's not for nothing that the answer to "can I know the full path of the binary that was used to spawn <process>?" is generally "it depends" or "it's complicated". And let's not even bring up what happens for interpreters for instance. Parameters are also often easy to spoof and manipulate, although in this case I suppose the kernel could just keep a protected copy of the original parameters for that purpose.

I completely get why you want that though, and it would be a great feature to have indeed, but I also completely understand why kernel devs don't want to touch that with a ten foot pole.

I think it's a great idea mosts apps will not want to spoof the firewall. So while it may not be secure, it would be very helpful for user controlled privacy.

Errr... the general answer to "can I know the full path of the binary that was used to spawn <process>?" is "sure, just `readlink /proc/<process>/exe`".

Yeah, until the program deletes itself from disk on launch.

Or edits that value.

> LittleSnitch on Mac... miss this level of control on Linux

This is such a killer app it's hard to believe that only recently a linux variation has been developed...

https://github.com/gustavo-iniguez-goya/opensnitch (the original by evilsocket seems to have been abandoned).

I do that too, out of interest, but I'm under no illusion it will help me against data exfiltration or protect my privacy. There is lots of software of which you just don't know what it is, or that plain doesn't work when blocked. Some even crashes when their connect() call doesn't immediately succeed. If you do a few weeks of real world work on a machine and then go back through all system processes you allowed, you ask yourself what half of them even are.

I respectfully disagree. Because it's an EPIC pain, and it's absolutely hostile towards "average" users.

Back in the Android 5 (or so) days, I knew what permissions an app I was going to install on my mother's phone was going to ask to be granted _once_, and be done with it. Nowadays, an app might ask for some kind of new permission "on first use", and users on mobile are developing the same habit as users of desktop browsers during the dark ages of expired HTTPS certificates and broken Java Applet signatures had developed out of necessity: "default-ack/OK all the things".

The problem is that these days, even very technical people think that you could realistically expect to lie with dogs, and get up without fleas - i.e., install applications and software you cannot trust, and get away without having something bad (like loss of privacy, or maybe exfiltration of data) happen. All thanks to "modern" security constructs like sandboxing.

But that is not going to happen - sandboxes have been shattered and broken in the past, as they will continue to get circumvented in the future. There simply is no replacement for trust (in an application, its developers, its distributor, and its operator (if any)), and there are no technical solutions that could somehow replace it in full.

Yes, you can make it incrementally less bad to have a hostile agent/app on your machine or phone, but the trouble you're trying to prevent that way will never go away completely.

I guess some people just liked to feel "in control" when clicking away their "Norton Professional Antivirus 95 blocked 17 Viruses from damaging your machine today!" messages back in the day, and some apparently cherish clicking "grant 'Sexy FileManager Free Pro' access to your Photos and Videos" today. Personally, I'm actually rather sick of it, and all the security theatre that "modern" application delivery mechanisms like app stores/mobile platforms or stuff like snaps/appimage/younameit would have you participate in. I'd rather trust my distro's package maintainers to not let developers abuse their users, and have a look at the source if I'm in doubt about the upstream's intentions. I know I can't audit everything, but I feel like I'm much better off with that kind of trade-off, than with the non-solution to the problem I tried to describe above.

Edit: Removed a leftover part of a restructured sentence.

The problem isn't the sandbox, it's inherently the issue with lack of fine grained permissions and being unable to revoke permissions after installation.

Wanna see a real permission model, look at the BB10 Android Player model. After installation, you could revoke permissions and the player would basically act as if the data from that permission was just empty. App asks for contacts, here's an empty contacts list.

Edit: I just did a small hackathon and ended up having to request full BLUETOOTH Access and LOCATION access to connect to a label printer... how is this long term sustainable.

The reason for location permissions is because BT can track your location through Bluetooth beacons. See https://developer.android.com/guide/topics/connectivity/blue...

This is just Android being transparent. "Bluetooth usage may allow apps to track your location." Which is perfectly true.

There has to be a balance between explaining to the user, e.g. that there are multiple ways their location can be tracked, and permission request overload.

I don't imagine explaining to everyday users the details of the Bluetooth protocol is viable.

> 'd rather trust my distro's package maintainers to not let developers abuse their users, and have a look at the source if I'm in doubt about the upstream's intentions.

Trusting 3rd parties to decide what you can trust isn't ideal either. It's what Google and (especially) Apple have for mobile apps now. They decide what you can safely install and we're just supposed to trust them. That's clearly not working.

While you have the added benefit of being able to trawl over thousands of lines of code looking for something suspicious, that's not exactly scalable or even possible for the majority of users. In the end, what exactly are you looking for anyway if not signs that an application is making connections or accessing files that it shouldn't. In that respect, it's far better to have the OS just tell users when an application is doing those things (connecting to the internet, reading their personal files, or activating their cameras). The more transparency in what an app is doing the better because the reality is that we cannot trust every app we install. How could we possibly?

> I respectfully disagree. Because it's an EPIC pain, and it's absolutely hostile towards "average" users.

Are you sure you didn't mean "EPOC" pain? Maybe "EPOC32" pain?


- a Psion owner

Also if a Series 5 Psion, an early owner of mobile ARM in its younger days.

Even though it's sort of an aside, I'm glad someone mentions Psion. I'd love to check whether their keyboards are on par with the legend. I wonder how many others relate, at the global scale :)

For the time, it was good, maybe better mechnisms available now, but darn - it was built to last and my 5MX still works. Though a lot of psions market was retail/stock warehous stuff, their handheld terminals had a huge market. So robust design was key. Only design issue on the 5MX that griped me was the stylus holder spring being not as industrial designed. Apart from that, all works well.

Since then, dreamed of some comparable device, basic linux, enough for vi and terminal stuff, wifi/bluetooth and well, happy with the screen. Alas all devoplment of anything close, tend to wack in CPU's that would be classed as a supercomputer of the 5MX time, power hogging colour screens and you end up with devices that will last a day perhaps, but not the month the 5mx would pull with comparable usage with the rs232 adapter.

Hence a cheap terminal, basic local editor wifi device in that form factor and if it could do bluetooth and double as a keyboard for a smartphone, well, a simple device like that would tick my boxes and maybe many others.

My 3, 3a, 5, and 5MX all still work (as do my Atari Portfolios and HP LX series palmtops, save one 200LX with physically damaged screen. I too keep wanting to see something like the 5Mx, or the PS-1000, or something similar with modern specs. I don't need the screen to be fast, just useful and low power. The 16-color E-Ink screens I keep reading about in Chinese tablets should work. Big battery for the form factor wouldn't hurt, but we used to use AAs. A dual-core or quad-core A53 with all solid-state storage, a nice legible low-power screen, and a great little keyboard would be quite a find.

I think you have to believe in sandboxes if you use the modern web; each site you load is effectively a program you are running on your machine, with only a sandbox protecting it.

> now I use LittleSnitch on Mac (I just hope it's going to keep working on ARM macs)

It should. Kexts are still allowed, for now. They're almost certainly only a couple of releases away from being deprecated though.

From the article this HN discussion [1] links to:

"We expect the deprecation to become effective with the next major release of macOS. There’s no official release date from Apple, but based on the release schedule of recent years it will not be before this fall. Little Snitch 4 will then not be loaded by the operating system, but there will still be an option to allow the loading."

Little Snitch 5 (with NKE) requires a new license.

[1] https://news.ycombinator.com/item?id=22677849

> Little Snitch 5 (with NKE) requires a new license.

There is reasonable pricing for upgrades... LS4 bought within a certain time get a free upgrade, older licenses get a reduced price.

A WWDC talk confirmed that notarized Kexts will still be allowed, but you'll have to enable that option via MacOS Recovery.

As long as they’re using non-deprecated KPIs. Those that are require another trip to Recovery to disable SIP.

> If only iptables would allow to filter by the executable path and other process parameters - that would be just so awesome.

You can do that sort of thing with eBPF these days, either at the network level or via process tracing. It's non-trivial still, though. Lots of the various firwewall automation tools have features like this too. It's definitely a solved problem, but not one with a really clean obvious solution yet.

A personal firewall is nothing more or less than a layer-7 firewall which rules you can (somehow) manage as user you are logged in with, with a nice GUI. There is Open Snitch [1] (plus forks/patches) for Linux, if you're after such.

[1] https://www.opensnitch.io

Editing the rules as a user with a GUI is the easy part. The more difficult parts are in details:

- how do you recognize which applications the packets belongs to? Even if you would get pid in the rules engine (which you normally don't), how do you name it? /proc/$pid/cmdline can be manipulated at will by the process; then you need to recognize additional parameters when you are using applications that run other code, from bash to virtualbox.

- what happens to the connection while the firewall is waiting for the user input in the UI? Linux apps handle long timeouts badly

- what happens to other connections while the firewall is waiting for the user input in the UI? Right now, unfortunately, whey would have to wait too.

- LittleSnitch does interesting heuristic wrt hostname/ip translation - you can get different (or no) hostname via reverse query than the application asked for. You need to monitor what each application is resolving and what answers it get. If you get same IPs for different hostnames for a single application, all bets are off, only application knows which one it connects to (you can eventually learn with DPI, but for that it might be too late). For applications with their own resolvers using DoH/DoT, tough luck.

The first problem could be solved at the level of sandbox runtimes (i.e. flatpak et al), i.e. when you know, that the application is running in the namespace belonging to specific flatpak package, you would present that as that specific application, they cannot lie about that anymore but the price is, that you can handle only sandboxed apps; for scripting and so on you still have to find how to distinguish specific instances. For all the other problems, you would have to figure them out.

> how do you recognize which applications the packets belongs to? Even if you would get pid in the rules engine (which you normally don't), how do you name it? /proc/$pid/cmdline can be manipulated at will by the process; then you need to recognize additional parameters when you are using applications that run other code, from bash to virtualbox.

iTerm actually ran into this very issue (using the equivalent macOS APIs) and had to treat it as a security bug because the results were controllable in-process as well. And it also ran into the problem of how to deal with interpreters. It basically ended up being all ripped out and the API was redesigned to require authentication tokens rather than trying to figure out a meaningful source for a process.

/proc/.../exe exists.

ETA: and most Linux apps will just sit there blocking in the syscall, or at the very worst, retry/show an error/crash.

The page you have linked to won't even open. I have witnessed a number of attempts to replicate LittleSnitch on Linux, none of them went far enough to anything near a usable product quality.

You need to implement at least some functionality on the kernel level (what LitleSnitch does with a kernel extension) for this, most of the people who care about desktop apps on Linux (me included) lack kernel developer skills.

True, its not production quality. Here is an actively developed fork/repo of OpenSnitch [1]

[1] https://github.com/gustavo-iniguez-goya/opensnitch

did you try tinysnitch [0], opensnitch fork [1] or Douane [2]?

[1] works pretty well for me.

[0] https://github.com/nathants/tinysnitch [1] https://github.com/gustavo-iniguez-goya/opensnitch [2] https://github.com/Douane/Douane/

One thing I've been wishing for in the mobile OSes, is for them to copy web browsers, and offer a UI to change all these security/privacy permissions for an app quickly from the context of the app, rather than by going into Settings and navigating down to the app (which nobody ever bothers to do, and especially nobody ever bothers to do more than once—so you can't put stuff that'd be useful to change temporarily in there.)

Of course, the naive implementation—giving the app itself control over the system's settings for it—would be a disaster. (I think early iOS had something like that, but quickly got rid of it—right around the time the App Store stopped being so heavily curated.)

I'm suggesting something more like: if you pull up iOS Control Center while an app is open, it'd have either an "app settings" submenu, or merge "app settings" into the view of system settings. Then, within "app settings", you'd have a little privacy-lock, sort of like the one that appears in a browser's address bar—and which would allow you to change very similar things to what clicking said lock allows you to change in a browser: in est, the states of all the system confirmation prompts the app has triggered.

Less on-topic, but contextually-accessible app settings would also allow you to do neat things like provide the ability to set accessibility settings on a per-app basis in an intuitive way, or to start something like Guided Access Mode (https://support.apple.com/en-ca/HT202612) without needing to enable+remember an arcane gesture. I would especially love the idea of being able to change the perceived system font-size/scaling-factor, or the perceived system language/region, on a per-app basis — basically equivalent to Safari's display settings "A" menu. Maybe even a switch to enable that "monochrome to reduce addictiveness" mode, so you can have it on only within social media apps!

> offer a UI to change all these security/privacy permissions for an app quickly from the context of the app

Isn't this exactly how Android does it? I long press the app icon, click app info. All permissions, data usage, battery usage, storage usage options and metrics are shown for the app.

That still happens outside the app, though. You have to go back to the home screen, find the app icon. I'm talking about a design where there's no "lookup the app" step in any menu (Settings or Home screen); where instead, you go straight to the foreground app's preferences.

You can do this from the app switcher: long-press the "title bar", and there'll be a round "I" button that takes you to the app's settings.

If I am in the app, I can swipe slowly from the bottom, and click the "app info" button. So no hunting for the app icon needed.

Not really a direct answer to your request, but Android 11 will allow you to grant permission to an app once, and will clear permissions for apps you haven't used for a few months: https://developer.android.com/preview/privacy


Feels so intuitive. Turns the control center into the top bar from macOS or the file/edit/settings bar that many windows apps have. That's so darn obviously the right way to do it!!!!

> If only iptables would allow to filter by the executable path

iptables can filter based on the uid ( -m owner --uid-owner {USERNAME}) then, you have to to create a dummy user and launch your executable as that user (su, runuser, ...)

Not saying your wrong, but you said something about SELinux and AppArmor..if your interested in that stuff you should checkout OpenBSD's pledge:


Could this be implemented with iptables rules on a per container/jail basis, like with K8s?

> Both give you regular reminders of which apps may be snaffling your data. Both let you manage access and selectively deny apps.

But that's cool with users. It's not annoying, it's more or less a one time thing, maybe a hint more if the app is a bit more unusual.

The Symbian notifications? That's a "I hate you, user". Especially the secure connection. Why would it ever ask that?

On the other hand, some of those warnings made sense at the time. Mobile internet was so expensive that I never enabled it. Right up there with MMS one of the things that priced itself out of the reach of regular customers. It was like 3€ to send one single MMS, Internet was also in that domain - per Megabyte (I should note here that the country I lived in is technologically a third world country). That changed only later. So a more modern iPhone and Android could design those things differently.

>>> Especially the secure connection. Why would it ever ask that?

For whatever reason, old Internet Explorers (9? 10? not sure..) do that too...

The really old ones didn't even have a "remember this choice" checkbox.

The only thing more annoying is when it ignores the remember this site checkbox.

The current ones will ignore the remember this site probably due to a stupid group policy.

Possibly forgets on logoff

IIRC latest IE11 on Windows Server 2019 still asking such stupid things by default.

I don't miss symbian. Maemo on the other hand... was a loss. Nokia N900 was absolutely the best smartphone i ever used. Would use it still, but usb port issues forced me to upgrade.

I have two Nokia N9's (running Meego) at home still. I used N9 as my daily driver until about 3 years ago. The failure of that magnificent OS, combined with the failure of the successor (Jolla / Sailfish) still annoys me.

I would still use my N9 except that there are apps that I use every day that simply don't exist for Meego.

I suppose I should try to sell it to some one who can use it but it is such a beautiful thing that I am loath to get rid of it even though I haven't even switched it on for ages.

At some point it just got too slow, and the browser was just not up to scratch. Still the best looking phone ever made..

> browser was just not up to scratch

I found a version of Firefox that worked very well. Haven't tried it for a year or so though.

> Still the best looking phone ever made..


Sailfish is still around and is still getting upgrades every quarter with new features and improvements. Android support is actually pretty good and I use it for my daily driver.

It's not a success but it hasn't been a failure IMO.

I used an Xperia X with Sailfish until end of 2019 but then I finally dropped it - it mostly worked but got too much annoyed by small bugs that never got fixed 100% (but in the meanwhile the UI got a lot of changes => that would definitely not be my way of prioritizing work). It's a pity but personally I think Sailfish will die.

I still have both N9 and Jolla. I really loved my N9 and was excited about Sailfish, but as soon as I got my Jolla it was clear to me that it'll be a dead end. I did use it for a couple of weeks, but it absolutely missed the mark on why N9 was so loved.

I understand that you can't just straight up copy the functional and beautiful UI from N9, but Sailfish the Sailfish UI was just way too experimental and bare.

I'm still bitter about their Indiegogo campaign. I did get half a refund, so that's better than most failed crowdsourced projects.

The killing of the n9 is the one thing in tech I'm pretty sure I'm never going to get over. It was awesome, and they killed it.

I really liked the Meego iteration. Its UI was top notch.

Thanks for the link! He perfectly describes how I feel about N9 still to this day.

That's the third option I wish we had ...

How on earth did this not take off ?

Internal politics. Symbian faction was too strong and Maemo was (rightly) seen as something that would cannibalize it if successful.

Meego being a full rewrite and repackage (qt/rpm whereas maemo was gtk/deb), although it had merits, means development needed to restart from scratch.

Nokia also totally mismanaged dev relations. First it built up dev excitement for Maemo, then announced it was going to be abandoned (for Meego) a few months later.

Meego was a combination of Intel's Moblin (purchased from OpenedHand, a big Linux shop back in the day) and Nokia's Maemo.

Shortly after Intel abandoned the project in favor of Tizen, leaving Nokia holding the bag. Nokia went through the motions until the infamous burning platform memo, driving the last nail.

In some ways, N900/N9 is a parallel with Amiga. Great machine, tremendous excitement by a (small) loyal userbase, mismanaged by development, and now a subject of nostalgia and failed attempts to resurrect the dream.

This is anhistorical; Nokia abandoned the Meego project with/after the burning platform memo. The Linux Foundation abandoned the Meego project and adopted Tizen afterwards, in part because of Nokia's departure

> How on earth did this not take off ?

Monies. Microsoft's offer to Nokia was way too lucrative.

Great video, great timing.

There is Tizen and some other derivative I can't remember still actively developed. I would by a Tizen phone if I could be sure there are enough of good apps available for it and if I didn't trust Samsung even less than I trust Google.

Tizen is a derivative in name only. Samsung effectively took complete control of the group from all the other companies on the Meego project and it seems like they only continued work to keep pressure on Google.

Nokia owned Qt and Samsung didn't want to pay fees or buy Qt outright, so they went with the mostly unknown Linux Enlightenment project (didn't hurt that it's main dev worked for them at the time). Likewise, Nokia owned rights to SwipeUI, so they opted for a remake of the Android UI.

If they'd gone with something like a cleanroom implementation of SwipeUI or webOS, I think Tizen could have been a success. Instead, it just feels like a bad, outdated edition of Android. If users wanted that, they'd just use Android instead.

i had a tizen phone. tizen was not bad. but the selection in the app market wasn't to great. f-droid has more/better apps than tizen.

unfortunately, unlike sailfish, tizen lacks support for android apps. the reason for that is that samsung would loose its commercial android license if they added android support to tizen.

Was Maemo open source, including the shell? I wonder whether anyone will try and revive it now we have mainline kernel Linux phones, like Librem and Pinephone.

It wasn't fully open source, but mostly. It was merged with Intel's Moblin into MeeGo. Once Nokia stopped working on that, MeeGo was forked into the fully open source Mer. Mer is nowadays used by Jolla as a basis for Sailfish OS (which again has non-open source parts at the top of the stack).





Maemo Leste is a fork of the original Maemo bits. It's still maintained, at least to some extent.

I _think_ it mostly was, with the exception of binary driver blobs. At least a few years ago it still had very active dev community at maemo.org, so it is not inconceivable for it to be revived. Alas, the neo900 project died.

No idea if neo900 officially died, but unofficially the timeline on the bottom and lack of news on the website [1] say as much.

I believe right now you're best off with /e/ in combination with a Fairphone 3.

[1] https://neo900.org

Friends of mine were taught by Carsten Haitzler (rasterman, original author of enlightenment, lead dev of tizen) at UNSW. Back in the day enlightenment was, in many ways, miles ahead of the competition. Unfortunately it was miles ahead of the hardware as well.

Apparently he has always been passionate about open source, and I've always been impressed by his output. I'd love to see /e/ get some mind share on a decent platform.

Sorry, I could've added a link.

/e/ referred to [1], not Enlightenment.

[1] https://e.foundation

I still use mine. Got a suspicious cheap battery + charger several years ago when the usb broke again. Shipped from china it took 2 months by boat, and the other battery is now extended enough that you can't close the back lid, but dammit, great phone.

Why are you still using the N900? Its kernel, browser and SSL libraries haven't been upgraded in years and years now. If you connect to a network, you are just asking to be pwned.

I kept my N900 for years longer than most people because it has a quality DAC and, as long as I kept it in airplane mode, it was a good music player for the classical and jazz I listen to on high-quality headphones when traveling. But eventually I realized that the N900 could be totally replaced by simply adding a Bluetooth DAC to the Android smartphone I already have (and I'm glad I did that, because the BTR3-FiiO Bluetooth amp I got sounds even better than the N900).

I recently got a Pinephone, but it’s hard to enthuse about it. So much of the cool things you could go with the N900 – Emacs and the whole OS it brings along, writing your own scripts in the terminal – were due to its hardware keyboard. A modern smartphone that lacks a hardware keyboard is just a pain to hack.

First, it works and do the job of being a phone and it has a great keyboard for sms.

It also lack a bunch of anti-features. No calling the mothership. No advertisements. No constant attempts to get me to register, to send gps information, to get me to do things which I don't want to do but the manufacturer do.

Interface is clean, fast enough, intuitive to use. It has the few apps I want to use like the terminal, fosdem schedule and also a virtual debian machine. All the third-party stuffs still get regular updates.

In the future I don't know what will replace it. The free software phones are interesting but I have my doubts about how practical they will be. On the proprietary side there are the foldables, but it is still a touch keyboard. There are feature phones, but many seems to now days be smartphones in disguise.

> All the third-party stuffs still get regular updates.

OK, but I hope you are aware that even the third-party stuff still uses the 2.6-version kernel and the system SSL libraries, which have not received security updates for years.

Also, an Android phone running LineageOS would not call the mothership, advertise to you, nag you to register (there is nothing to register for), send GPS information anywhere once you configure it to not do so (or you can choose a libre alternative like Mozilla’s location services), or get you to do things which you don't want to do but the manufacturer does. That is why many if not most idealistic N900 owners moved on to LineageOS, while hoping that something like the Neo900 or the Librem 5 or the Pinephone would eventually remove the need for Android entirely.

You can use a mainline kernel. (Without the GPU..)

Eh, not really. Symbian was right for the wrong reasons. They were right to warn users about apps using internet access, but they were wrong about the reason - it was about data caps, not privacy or security.

Data caps mattered in that era, so from a narrow point of view it was the smart thing to offer those features. But to launch a category defining smartphone, that limitation needed to be broken entirely, and that involves work outside of software; namely, timing the launch such that you can negotiate with AT&T to ease the data restriction.

It's like saying RealPlayer 'won' against YouTube. No, they didn't. They just mistimed an idea, and a few implementation details were the same.

I've written more about this type of dynamic here: https://nickpunt.com/blog/category-defining-products/

That's like saying because everyone else has 'pervasive multithreading', BeOS won even when it was a commercial failure.

Everyone else did it better. It's not about who invented it first, its about innovating over other inventions.

Symbian still failed commercially in the market and couldn't compete or innovate with the other competitors.

If the 'winners' have to adopt your ideas, you've won.

At least if your ideas where more important to you than 'winning'

They innovated away privacy and security by relying on the human poor ability of impulse control and hardship with delayed gratification. Basically they made everything shiny and addictive. Is that really innovative? Perhaps 'bad' ui is better when you consider higher order consequences as opposed to concentrating only on first order popularity contest?

I'm not saying Nokia and symbian were better BTW. Just noting how our contemporary value system where, "it makes money"="it's good" is short sighted at times.

This is a ridiculously shallow dismisal.

Android and iOS "won" because the phones were vastly more capable.

Except they weren't. At the time, the US had really crap phones compared to Europe (which itself was behind Japan). The Nokia N95 could do everything. The original iPhone was pretty much laughed at by Nokia insiders because it lacked so many features. It turns out most users didn't care about most of these (MMS, DTV, Bluetooth)

Except that they didn’t have a proper browser.

People tend to forget that you had a desktop quality browser in the first iPhone.

Opera was available for it

Dismissal of what? I'm not saying symbian was a better os. I'm saying sometimes innovation and commercial success are not indicators of better solutions. And sometimes moving fast and breaking/distrupting things, is not a good thing.

Android won because it is free beer that the OEMs don't have to pay anyone for licenses, save on development costs and can stick to outdated versions as long as they feel like it.

I used Symbian. It was annoying.

Easy of use and better UX is a very valuable "innovation".

They were making massive efforts internally to get rid of the Series60 UI, which was not pretty visually or API-wise. The last UI before the platform was dropped UI was Belle, which actually wasn't bad.

Nokia actually had a touchscreen UI called Series90 but that went nowhere, they dismissed touchscreens completely initially, and then went with resistive touchscreens on the disastrous N97

I'm currently reading The Infinite Game by Simon Sinek, and he talks about exactly that: is your game finite or infinite? If infinite (like any business), there is no "winning" in that kind of "game" because there are so many standards by which one could say he beats the competition (win): is it market share, cashflow, valuation, innovation?...

Symbian was probably right about how it was handling of security, but it "lost" by disappearing from the game.

It is only tangentially related, but Symbian in fact had even more pervasive multithreading than even BeOS. IIRC "correctly behaving" EPOC/Symbian GUI application was supposed to have at least three threads (UI and application logic in separate threads and additional "housekeeping" thread).

BeOS had a thread for each BWindow. So 5 browser windows is 5 threads for the windows and 1 for the BApplication.

Yes, that's exactly what I'm saying. In the marketplace of ideas, both Symbian and BeOS eventually won the argument.

They didn't win commercially.

I make a similar argument when I say that “CoffeeScript was merged to main.” Yes, JavaScript 2015 won... By adopting all of the ideas that CoffeeScript made mainstream for front-end web development.

I realize this is a philosophical distinction, but it really does come down to whether you are attached to the fundamental characteristic of a thing, or the label/name/brand of the thing.

Financially, the brand matters. If Uber fails commercially, but ushers in an age of gig economy transportation, the idea won but the brand did not. As an investor or employee, you care deeply about the brand.

But as someone trying to change the world, you care deeply about the idea coming to pass by any means necessary. Sutherland did not get rich. But do we say he lost because “The Mother of All Demos” was not an Apple II or Macintosh?

In this era I was into mobile phonery (is that a word?) and in 2006 the Nokia e50 (Symbian 9.1) was such a great phone, it went to many countries that year and I just loved it (it was maybe my 3rd Symbian). Not as a developer but an end user hacker lite, all the flexibility it offered over other choices at the time (most devices were "dumb").

Until the end of 2006 when T-Mobile (US) introduced the BlackBerry Pearl; it was at that point Symbian/S60 died in my life when I realized how limited it was and what it could have been, haven't touched one since (the Pearl being eclipsed by the first Androids after that in 2008). They had a shot and a solid following on HowardForums and just sort of blew it and let the competition outrun them.

"Everyone else did it better" - by some very loose definition of "better" maybe. Author is agreeing that Symbian failed for good reasons at the very end of a very short blog post.

This analysis elides the fact that all OSes in the Symbian era had to compulsively ask about accessing the Internet because data usage was at such a premium.

Not until iPhone.

I carried an iPaq back in 2003/4. It was awful in many ways, but like living in the future with superpowers. I had Google Maps at any time, etc.

I was between jobs when we got married, and my wife and I went on a two month roadtrip for our honeymoon. It was only possible due the iPaq with the combo of Google Maps + a web browser that could access Priceline.com!

Data speed was never an issue, only signal. The good news is that era was where cities started throwing up free Wifi, so it worked out. I'd say that from a UX experience, being one of the few users in 2004 was a better experience than EDGE connectivity or 3G in some areas on the iPhone after it's release!

I remember taking a road trip with my then-fiancée in 2002 and thinking how neat it would be to be able to access Google maps, etc. on the road easily. I had my first Titanium Powerbook back then and when we needed internet, we would find a high school and pull into the parking lot and nine times out of ten there would be an open wifi network with internet access.

People forget that it was the release of the iPhone that caused AT&T and others to offer "unlimited internet". $60 for unlimited internet in 2007.

That was a revolution. Before that, yes, you could run up a massive phone bill.

[1] https://www.apple.com/newsroom/2007/06/26AT-T-and-Apple-Anno...

> $60 for unlimited internet in 2007. That was a revolution.

You mean their fake unlimited plan that resulted in a $60 million fine? That revolution?

[1] https://www.theverge.com/2019/11/5/20949850/att-fine-unlimit...

I remember paying metered data that cost around 0.005 cent per kb around 2006 (forgot the actual number but I'm pretty sure it's around that much). Having "unlimited" data is indeed revolutionary.

Yeah, it throttled, but it didn’t randomly send you bills for $1000’s (except maybe if you were near a roaming area).

AT&T offered unlimited internet plans pre-iPhone. I had an unlimited 3G internet plan pre-iPhone. It wasn't intended for PDAs/smartphones at the time but it seemed like they never bothered to check IMEI's for devices they did not sell. I forget the exact price but it was cheaper on the family plan than the unlimited iPhone data plan.

That's not completely correct. My NEC smartphones didn't. Nor did the early BlackBerrys that I used.

I guess that's why NEC and Blackberry never took off in Europe, as the data usage would financially ruin you.

With prices of about 5 euro per megabyte you lived in constant fear of accidentally using data.

Blackberry was quite popular in the UK amongst the corporate users, however BBM universally came with it's own data plans and they had their software running inside the cell providers as well as within the organization itself.

BBM absolutely did take off with youngsters for a while - I sold a lot of blackberries to teenagers in the U.K. in 06.

Blackberry failed for much same reason it failed everywhere else - much better phone platforms came out very quickly etc.

I don't remember Windows Mobile asking for permission to use mobile internet either.

So that's why I used a 100 MB modem plan in my smartphone (then 300MB before cheaper regular phone plans became available). Phone calls were 1.5x the pre-paid rate, but using the Internet somewhat freely was better.

I remember SK feature phones with WAP support that did ask. BB worked slightly different before 3g and it's advancements made mobile internet pretty much "free" for most people.

BlackBerry came with it's own data plans and they had they used integrate with the mobile providers on a much lower level than just internet traffic.

Blackberry OS definitely did this, and it was brilliant because you could allow the NYTimes application to access news.nytimes.com but not ads.adcompany.com.

I still have my nokia c2-01. It works fine, it stills takes picture, and it's 9 years old. The battery last for about 1 week or less. I do calls with a 2 euro/month plan.

I really wish I could have a smartphone with similar hardware that I could upload some executable on it written in C.

I still cannot believe there are no minimalist RPi-like smartphone that lets you easily do this. Smartphones today are overpriced supercomputers with asthmatic batteries with hardware that is possibly full of backdoors.

I know there's the pinephone, but I would rather have more limited, slower/cheaper hardware instead.

I really liked Viktors amazing 4 bit processor


I actually never understood why iOS and Android don't offer the same system browsers offer for the Web. When you pick a file, the OS prompt a screen to navigate through your pictures to pick the item you want and give it to the webpage. Because this workflow is what most of the apps needs. I don't want apps to have access to all my storage system, but just the picture I want to share. The same system could be applied to contacts as well

Android gives this option, and also gives the option for acessing arbitrary files too (for other user cases). Most of apps use the second option anyway for other purposes, so they see little trouble in doing a custom file picker

they do, the default file picker for iOS has a 'pick file' native command that then pops a system picker and then returns just the selected file but many companies would rather have full access to enable their own experience. In messaging apps, it is seeing the photos in a small view. Instagram has a full screen browser to enable their own chosen UX.

Edit: I just saw a really neat alternative view in iOS 14 whereas the 'allow access to photos' modal gives the option to pick and choose what photos are 'shown' by the OS.

Wow! It's so rare that I might have never seen it, or completely forgot about it. However, now that you mention it, I think I remember it from my early days on iOS.

Actually the problem is most of apps don't give you the choice between [slick UX + loose control over your data] or [ok UX + perfect control of your data].

If I download Instagram and refuse to access my local storage, I guess I won't be able to share a picture from my phone, right?

> If I download Instagram and refuse to access my local storage, I guess I won't be able to share a picture from my phone, right?

Not from within the app, but if you go into the Photos app and share a photo from there, you can choose to share to Instagram, and Instagram will get only that one photo.

Third-party apps could provide a custom UX to sensitive data by providing a separate executable that the device's OS then runs in a sandboxed process with read-only access to your sensitive data and without the means of communicating anything with the source app's process. When the user has completed whatever task the sandbox was needed for (e.g. finding a photo from your entire camera-roll or picking contacts) the sandboxed third-party code indicates the selection to the host OS who then does a quick "confirm you want to use these 3 photos?" prompt and then releases only the selected data.

...basically something like WinRT's broker-processes on steroids - or another use case for Apple's "App Extensions" feature but allowing for complete control of the UX more akin to a Photoshop Plugin than being limited to a small number of prescribed use-cases.

I think this is how Android works now, and has for a few years. It is crazy that it wasn't always this way, though. Apps in the past could choose to request access to all your photos just to let you pick; but now I think that will get you removed from the Play Store (maybe?) since the official way in Android is now the way you describe.

It was always this way. Intent.ACTION_PICK is API level 1:


But when you can integrate the picking into your app and avoid trying to learn a zero-permission approach because users just hit OK at install time anyway... why bother? And thus back in the day very little things used this, because there was very little reason to avoid just requesting every possible permission.

A very small part of the Symbian OS consisted of a useful feature that is now similarly implemented in iOS and Android.

That hardly deserves the extremely click-baity headline of "Symbian Won"

"Symbian Won on User Permissions" would be reasonable, and probably get less attention.

Symbian (and Java ME was awful as well) was not developer friendly at all till towards the very end. By then it was too late. You never had a choice to get rid of the annoying untrusted app pop up, and getting code-signing was a nightmare.

Apple was in contrast incredibly developer friendly when they started their store and then Android one-upped them (only 25 usd to join!).

I worked in the mobile phone industry 00s. Besides terrible Series 60 UI, Symbian also had non-POSIX (micro?) kernel. For example, file system was a service and handles like a log file handle were not transferable across threads. It made porting apps a pain. Developer tools existed, but were shit and usual failure mode was app crashing without a reason.

Symbian had shitty developer experience because internally they did not have a "Dev experience and third party app development" stakeholder. They had kernel, seats for various hardware vendors, mobile and wifi standards, but not for third party devs. Nokia itself was blind for its mistakes as in-house they could get whatever source code or access they wanted.

Note that there were non-Symbian mobile phones as well e.g. Ericsson. So Symbian was kind of Android, but no default UI and closed source.

> Note that there were non-Symbian mobile phones as well e.g. Ericsson

There were also multiple variants of Symbian - S60 was the Nokia UI, but Ericsson and Motorola had Symbian UIQ, in Japan they had MOAP-Symbian

Another thing that Symbian did really really well was networking.

You could choose per app which connection they should be using, or even a group with order of preference. So you could get your work apps to only work over WiFi, some apps always go over VPN, some always use 4G even if WiFi was active. It was brilliant because all these connections could be active at the same time.

Apple and Google are only just catching up to this now with tricks like Per-App VPN but it still doesn't offer the same level of flexibility.

it was my impression that a lot of those Symbian warnings weren't so much trust/privacy related, but were driven simply by "european" service plans that charged a lot of money for SMS (sending) and network data, and users were hypersensitive to receiving huge phone bills.

source: I used my Nokia phones internationally by swapping SIMs and there was a huge difference between US and European plans.

    >Symbian: Opening a secure connection. Continue?
    >IE6: You are about to view pages over a secure connection
Why did early 2000' software had such obsession with asking user about secure connection?

More importantly, why did they ask you about secure connections, but automatically assume that insecure connections were okay?

IIRC https/tls consumes a lot of overhead back then, both on server side and client side. These days https is so fast no one think about its overhead over plain text connection anymore. Not sure if that's the reason for the prompt though.

Dark ages my friend. Luckily we know better nowadays =)

Got depression doing Symbian development. (I am not kidding.)

Yeah it was a bitch to develop for... I tried it for a bit but then they started including J2ME and I switched to that. It wasn't as good as native but it worked. And was one hell of a lot easier to develop in.

Same here. Easily the worst dev experience I have had on any platform. The worst part was that the platform itself seemed very capable.

not enough information

was it related to symbian design choices?

I don’t know what the OP refers to, but using strings was ‘different’ from doing it in other systems. http://descriptors.blogspot.com/:

“Most programmers come to Symbian OS from some other development environment, and tend to think they’ve already got strings pretty much sussed. After all, there’s not much to C strings to understand, although there are plenty of ways they can go wrong. The Java String and StringBuf classes have about the best combination of power and simplicity that you can get. And the various String and CString classes found in different flavours of C++ environments are usually mastered fairly quickly.

But then they encounter Symbian OS descriptors. If there was anything invented to bring a high flying C++ developer firmly back to ground during their first week of Symbian OS development, it’s descriptors.”

From the linked blog, an example of how to copy a 4-letter string from a constant string into a new heap-allocated string:

  HBufC* heapbasedFred=HBufC::NewL(4);
  TPtr fredPtr(heapbasedFred->Des());
  _LIT(KFred, “fred”);
I had forgot it was this bad.

It's kind of weird that Symbian calls these descriptors, but the actual types and macros don't use that word at all — they are HBufC, TPtr and _LIT.

It was a combination of bad APIs, bad and Windows-only IDE, problems in OpenC, and pressure from client.

For the lack of a better word, development in Symbian was "tacky", was like walking on mud, everything took 10x the effort it should.

It was a time when Nokia was the only game in town (think N93, N95) and they thought they could get away with mistreating developers forever.

Funny how they sabotaged their own efforts to make development easier e.g. Python for Series 60, let alone Maemo.

iPhone is Mac-only for development. Some things never change..

Ha, I still might have the introduction to symbian c++ book somewhere. Descriptors blew everyone's minds initially but they eventually clicked. Active Objects and the manual CleanupStack were other headaches.

I vote for the threading model.

I vote for the ridiculous number of different devices, screen sizes, hardware etc.

Maybe the compiling times too.

No they didn’t. They made a huge mistake: not forcing their own AppStore globally.

The way to get app was by content aggregators and premium sms sites. Developers were lucky if they got 10% of the purchase price.

So please people, stop complaining about 30% for discovery, security checks, big number of payment methods, tax-consolidation, and global availability.

It is unfair to compare. An application with an offline map is different, by design, that one where you can download the map or require a connection. Compare TomTom and Garmin with Google Maps and Apple Maps. Which one's used much more nowadays?

What has won is capability-based design, and the fact that the review system in iOS is better (but not perfect) compared to Google. The install base is also much larger though, and the amount of personal data on a smartphone has also increased greatly.

The question we need to ask ourselves is the following: do we really need all this data available on our smartphone? Or, put different: do you need to be able to access this data while on the go, 24/7? Do you need to take your smartphone with you 24/7?

It isn't about need, it's about want.

We don't want erase all data permission. We need only very specific permissions. We should have custom permissions that we can get certified/approved.

Like with browser extensions I don't want access to all pages and tabs. I want [say] access to the `href` attribute `value` of the `link` elements that have attribute `rel` that is `alternate` AND `type` that is either `application/rss+xml` OR `application/atom+xml`

To be described to the user as: "Permission to discover RSS and Atom feeds."

I pay 25 euro, I wait, the platform ppl sign of on it, I update the tool with the new permission.

So in 2003, before the iPhone came out, I was a mac developer doing Cocoa/Objective-C development.

I then tried to learn Symbian and I found the IDE hard to setup, the API was hard to learn, and I believe it only ran on windows.

At the time I thought to myself “the NeXT/Cocoa API and utilities are so awesome, so easy, so mature that if Apple ever makes it possible to write mobile apps with them, they are totally going to absolutely destroy everyone else in the mobile development marketplace. Especially Symbian.”

Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact