Live data from Hacker News

Symbian Won

shkspr.mobi

171–180 of 290 posts

Re: Symbian Won

#171
post #36

Earlier quoted context omitted.

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…

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

Re: Symbian Won

#172
post #126

Earlier quoted context omitted.

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…

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

Re: Symbian Won

#173

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. Net…

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

Re: Symbian Won

#174

Earlier quoted context omitted.

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)

Re: Symbian Won

#175
I worked for Nokia between 2005-2012. During that time, roughly, it managed itself into its own eventual demise. Symbian, it's technical limitations, and general many spots across senior management for the types of qualities actually valued by users kind of set the stage for both Apple and Google to come in and disrupt the market with an initially remarkably mediocre effort: it didn't take much to disrupt the train wreck that was Symbian.

The first IOS versions had quite a few limitations and a long list of stuff that it basically did not have at all. Yet it was better in only two ways:

- it had a well thought out UX; users loved that - it did not crash all the time and wasn't riddled with bugs; unlike just about anything that Nokia shipped.

There was a long list of stuff Symbian could technically do but sucked so hard at that few users actually bothered with using those things. Like using the web, taking photos and sharing them with friends, or doing some video conferencing. Technically you could do all those things but it was a combination of painfully awkward to do, unusable and extremely likely in your phone resetting randomly. All that was probably fixable technically but none of that was something Nokia was able to actually pull off due to it's management structure, priorities, and a general complete vacuum at the top in terms of leadership and vision.

Looking back, Nokia's bad decision making started around the time Linux became an obvious future choice for phones (late nineties) and just a few years ago before a tiny startup called Android actually started dreaming of making a linux & Java based phone. Instead Nokia ignored the signs of the time (and the many embedded hardware manufacturers experimenting with linux) and went for a little known 32 bit successor to 16 bit OS from the nineteen eighties and threw its weight behind it.

Google bought Android around the same time Apple kicked it's IOS efforts into gear, which was around the time I joined Nokia and also around the time Nokia Symbian phones actually started shipping in more meaningful volume (it was late and not great initially).

Symbian was not what made Nokia rich. That was actually two other platforms called S30 and S40. The S here is often confused for Symbian but actually means Series. Series 30 dates back to the early nineties and still ships in some volume in developing markets for a few dollars. That infamous indestructible Nokia phone that always comes up in Nokia nostalgia? S30. Snake, Calls, and SMS. All it did. (OK and a little WAP if you got any value out of that walled garden).

S40 started shipping around 1999 (the flip phone in the Matrix was the first model). Initially with black and white screens. Later with color screens, multi media capabilities, etc. This was the backbone of Nokia's revenue right until MS came in. Not Symbian either and actually kind of a cool OS design for its time.

Only Series 60, 80, and 90 were actually Symbian based. Nokia did not actually start shipping Symbian in volume until about 2004/2005, right when it's competition was basically going from prototype to eventual reality at Apple & Google.

The e-series phones (the ones with qwerty keyboards) were popular but comparatively a niche market. Initially that was S80 (the business variant) and later the two remaining Nokia Symbian platforms merged and S60 became the only version (initially this was positioned for multi media and gaming devices). Technically all of these were UI layers on top of Symbian. Ericsson had its own version called UIQ.

There were a quite a few flagship S60 phones that were basically variations of candy bars until after the iphone shipped. Nokia actually killed off S90 in 2005 which was intended as a touchscreen variant. Yep, that's the same year Google bought Android and Apple was moving ahead with IOS. And, yes, Nokia was well aware of those two facts (very much a public secret at the time).

For the next 3 years the only touch screen devices Nokia sold were Linux based. Only in 2007 Nokia woke up and went "oh F*" and gobbled together a company killing version of a touch screen phone on top of S60. I can't emphasize how rushed and how bad this was. Especially considering it had a perfectly good shipping Linux tablet running basically the same kernel as what later became Android.

It spent the next five years convincing consumers how much S60 didn't suck while failing repeatedly and hard. Especially a few years after Apple ate their lunch it became increasingly painful to watch. Lots of desperate moves happened during that time.

Fun fact, Nokia shipped an internet tablet running Debian Linux with X, GTK and a Mozilla Gecko based browser around 2006, almost half a decade before the ipad shipped. This thing was awesome and the reasons for it shipping without phone capabilities were entirely political and non technical (think management having a hard-on for Symbian). This little tablet eventually became a phone and then the whole MS thing happened. Meanwhile Google bought a lot of these because it basically ran the same kernel and drivers as early versions of Android and you could dual boot them to whatever; which was a nice feature to have before they shipped the first Nexus phone.

Nokia basically helped bootstrap Android but was too occupied moving deck chairs around on the sinking ship that was Symbian.

So, no, Symbian did not win.

Re: Symbian Won

#176
post #140

Earlier quoted context omitted.

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.

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.

Re: Symbian Won

#177

Earlier quoted context omitted.

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!

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]!

[1]https://en.wikipedia.org/wiki/Mobile_Information_Device_Prof...

[2]https://www.youtube.com/watch?v=YOZi-7V11k8

Re: Symbian Won

#178
post #170

Earlier quoted context omitted.

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 event…

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, fosd…

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

Re: Symbian Won

#179

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. Net…

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 infoPckg(info);
        TInt r=UserSvr::HalFunction(EHalGroupKernel, EKernelHalMemoryInfo, (TAny*)&infoPckg, NULL);
        if (r==KErrNone)
            {
            *(TInt*)aInOut=info.iTotalRomInBytes;
            }
        return r;
        }

Re: Symbian Won

#180
post #68

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…

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:

https://developer.android.com/reference/android/content/Inte...

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.

Post reply on HN