[HN Gopher] Symbian Won
___________________________________________________________________
Symbian Won
Author : edent
Score : 463 points
Date : 2020-06-25 11:53 UTC (11 hours ago)
(HTM) web link (shkspr.mobi)
(TXT) w3m dump (shkspr.mobi)
| shmerl wrote:
| Nokia had a chance with Meego. But internal politics killed it,
| and Symbain followed.
| Hnrobert42 wrote:
| I love the word snaffle now.
| rbanffy wrote:
| I don't remember this "decent ecosystem for developers". Did I
| miss something?
| einpoklum wrote:
| > With the latest releases of Android and iOS ... Both give you
| regular reminders of which apps may be snaffling your data.
|
| But what about _Google_ or _Apple_ accessing my data? I can't
| prevent that, and they're some of the dodgiest corporation with
| the dodgiest apps in terms of privacy - after all, we know they
| send your data to the NSA.
| mathgladiator wrote:
| I think a better title would have been "Symbian did it right
| first!"
|
| and this then illustrates that doing things wrong were about
| priorities, and a better focus for user-focus was the winning
| play by others.
| dangus wrote:
| I think the connection this article is trying to make is sort of
| a stretch.
|
| The way modern iOS and Android handles asking for permissions
| doesn't seem all that similar to me.
|
| Symbian was asking about network connectivity because, at the
| time, mobile phone networks charged for data in ridiculously
| small increments at high prices.
|
| One of Apple's biggest innovations was to convince Cingular to
| sell an unlimited data plan at a price acceptable to the general
| consumer and not just for businesses.
|
| If I recall correctly, there was a good period of time where
| BlackBerry service plans cost more than the iPhone by 10 or 20
| dollars per month, and yet a BlackBerry really didn't have a
| fast/usable enough web browser to even consume as much data.
|
| The iPhone was so popular that it was bringing Cingular's network
| to its knees, especially during sports events and things like
| that.
| secondcoming wrote:
| 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.
| speeder wrote:
| 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.
| russfink wrote:
| I could enable GPS and leave the phone on without charging...
| for THREE WEEKS at a time.
| nexuist wrote:
| 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.
| pjmlp wrote:
| Symbian Belle, the last iteration was just great.
|
| I only moved to Android when forced to.
| behnamoh wrote:
| 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.
| Abishek_Muthian wrote:
| 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!
| pistoriusp wrote:
| 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.
| pjmlp wrote:
| Just like Android.
| Abishek_Muthian wrote:
| 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
| Steltek wrote:
| 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.
| app4soft wrote:
| > _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
| Abishek_Muthian wrote:
| 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.
| foobarian wrote:
| 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?
| hcho wrote:
| 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.
| app4soft wrote:
| > _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/
| pjmlp wrote:
| Actually by Nokia shareholders, including a big bonus for
| managing to sell mobile division.
| app4soft wrote:
| No. Nokia just sold its business to new owner, but new
| owner killed it.
| pjmlp wrote:
| 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.
| pjmlp wrote:
| US market was never keen in Nokia devices and Android is
| free beer.
| Abishek_Muthian wrote:
| IMO
|
| * 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.
| app4soft wrote:
| > _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
| foobarian wrote:
| 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...
| app4soft wrote:
| > _Nokia 's leadership was_
|
| _Stephen Elop_ , Nokia President & CEO since September
| 2010.[0,1,2,3,4,5]
|
| Since 2011 Symbian & Nokia starts its degradation under
| Elop 's "leadership".
|
| [0]
| https://en.wikipedia.org/wiki/Stephen_Elop#CEO_of_Nokia
|
| [1] https://www.europeanceo.com/profile/stephen-elop
|
| [2] https://www.smartcompany.com.au/business-
| advice/strategy/how...
|
| [3]
| https://www.theguardian.com/technology/2014/oct/08/nokia-
| ste...
|
| [4] https://www.theverge.com/2015/6/17/8796465/grand-
| theft-elop
|
| [5] https://www.theregister.com/2018/02/15/elop_and_the_f
| all_of_...
| secondcoming wrote:
| 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.
| brianpursley wrote:
| > 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)
| { *(TInt*)aInOut=info.iTotalRomInBytes;
| } return r; }
| perennialmind wrote:
| 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>
| mjevans wrote:
| 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.)
| AceJohnny2 wrote:
| > _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!?
| nitrogen wrote:
| 8-space using the tab character is the Linux kernel
| standard, but the curly braces are closer to other coding
| standards.
| AceJohnny2 wrote:
| It's not the 8-space I'm aghast about, but that _every
| function body_ is indented by it.
| AceJohnny2 wrote:
| 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.
| app4soft wrote:
| There are few more places where you could grab Symbian
| sources.[0]
|
| [0] https://mrrosset.github.io/Symbian-Archive/Links.html
| SemiNormal wrote:
| Whitesmiths style is for sadists.
| zerr wrote:
| Hah, I've worked on such styled legacy project from the
| European client. Seems like this style was popular in Europe
| during 90s :)
| neilv wrote:
| 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).
|
| https://en.wikipedia.org/wiki/Nokia_E61
|
| 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... :)
| kevsim wrote:
| 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!
| QuercusMax wrote:
| 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.
| secondcoming wrote:
| 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.
| app4soft wrote:
| > _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
| mightyscouse wrote:
| 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.
| kevsim wrote:
| 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
| derefr wrote:
| > 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.
| defen wrote:
| 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.
| LoSboccacc wrote:
| 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.
| secondcoming wrote:
| 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'
| :)
| jfkebwjsbx wrote:
| RAII can be used without constructors and without
| exceptions. The acronym is misleading.
| app4soft wrote:
| 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
| secondcoming wrote:
| 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:
|
| http://n-gage.org/symbian-sdk-
| doc/6.1/developerlibrary/Commo...
|
| 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.
| secondcoming wrote:
| No STL
|
| 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.
| kllrnohj wrote:
| > (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.
| asjw wrote:
| 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
| ollo wrote:
| You could even program in Python!
| markus_zhang wrote:
| Oh I always want to write C/C++ code on a Non-Apple mobile but
| I didn't expect it to be THAT weird...
| namdnay wrote:
| Oh god I've got flashbacks of those weird exception stacks you
| had to manage manually
| stiray wrote:
| 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.
| afandian wrote:
| 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.
| ptman wrote:
| 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.
| kccqzy wrote:
| > 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.
| jessaustin wrote:
| The indiegogo page seems to imply that they're shipping these
| devices. Have you not received yours? The simulated pictures
| look nice...
| stiray wrote:
| 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.
| franze wrote:
| 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).
| secondcoming wrote:
| 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).
| einpoklum wrote:
| 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.
| easytiger wrote:
| In 1998 c++ was a totally different ballgame to c++ in
| 2010 let alone now
| kllrnohj wrote:
| 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)
| malkia wrote:
| Was it the case where no globals were allowed, since
| "executables" (not really) were more remiscent of dll/shared
| libs/etc.?
| secondcoming wrote:
| 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.
| pjmlp wrote:
| 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.
| smichel17 wrote:
| 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.
| pjmlp wrote:
| You could use Java, Flash, Python and Web Runtime as
| alternatives back then. Much richer than Android still.
| secondcoming wrote:
| 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.
| pjmlp wrote:
| 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.
| easytiger wrote:
| Android studio and jni dev is pretty trivial TBH. It even
| builds the boilerplate for you
| pjmlp wrote:
| Try to generate boilerplate code for calling permissions
| API from C++.
|
| NDK is designed for Java => NDK libraries only.
| easytiger wrote:
| Well I'm generally only writing interfaces for native
| code I've written.
| bayindirh wrote:
| People didn't like Symbian and PalmOS when shinier alternatives
| came out but, these two OSes did a lot fundamental things
| correctly and efficiently.
|
| The iOS lockscreen is a modernized version of the Today app from
| PalmOS. Current iOS homescreen is a slightly modified version of
| PalmOS homescreen to be precise.
|
| PalmOS and Symbian are the pioneers of mobile OSes and they were
| pretty good at that.
| matthewaveryusa wrote:
| It's easier to ask for forgiveness than permission.
| jokit wrote:
| >Libertarian free-for-all doesn't work.
|
| This is calling the cure "the disease", and vice versa.
|
| The author doesn't mention a libertarian free-for-all among the
| alternatives.
|
| A free market innovates at the edges in all directions in a
| decentralized fashion. It may take longer to address certain
| demands than a centralized, top down, approach.
|
| However, it is only a truly libertarian, truly free market, that
| allows for any individual empowerment. The proprietary "options"
| that turn you into their product, rather than produce a
| product/service for you, aren't going to free you from them.
| Other free individuals will by sharing their open source
| alternatives.
|
| It may take longer, but it is solved. Usually the proprietary
| alternatives than make "improvements" that are largely just meant
| to break an open source solution, but this is a temporary
| sabotage at best.
|
| What they really need is to trick people into believing that the
| disease is the cure... or, that government protects people from
| monopolies, rather than the truth, that they enable them.
|
| Imagine computers without open source. Just how impressive would
| Apple, Microsoft, Google, etc., be?
|
| They "innovate" as much as is necessary to protect their market
| share. If they can bribe government into eliminating competition
| with a cut of their monopolistic loot, some will do that too.
| Whatever the least expensive/most profitable path is.
|
| Why do people create and share open source solutions? What is
| their motive?
| Bud wrote:
| 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.
| edent wrote:
| That's not completely correct. My NEC smartphones didn't. Nor
| did the early BlackBerrys that I used.
| jeffbee wrote:
| 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.
| LeonM wrote:
| 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.
| giobox wrote:
| 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.
| dogma1138 wrote:
| 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.
| dogma1138 wrote:
| 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.
| rescbr wrote:
| 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.
| Spooky23 wrote:
| 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!
| dhosek wrote:
| I remember taking a road trip with my then-fiancee 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.
| unreal37 wrote:
| 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...
| calcifer wrote:
| > $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...
| hedora wrote:
| Yeah, it throttled, but it didn't randomly send you bills
| for $1000's (except maybe if you were near a roaming area).
| neurostimulant wrote:
| 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.
| vel0city wrote:
| 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.
| [deleted]
| ineedasername wrote:
| 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.
| 6510 wrote:
| 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.
| postfacto wrote:
| 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."
| alex_young wrote:
| Except your apps are all built using SDKs that sell your data to
| the highest bidder and even if that can be mitigated, your cell
| company is doing the same thing on the network level.
|
| They just brought back the illusion of control.
| ttsda wrote:
| Symbian was great! I got a used Nokia 6110 Navigator around 2008
| (I was 12/13) and it was mindblowing to me. It had GPS, and I
| could download apps from the internet that would do stuff with
| the GPS and send data in real time to my computer.
| 1cvmask wrote:
| 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!).
| miohtama wrote:
| 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.
| npunt wrote:
| 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/
| pydry wrote:
| I don't really understand why setting up permissions for apps are
| seemingly so hard get right for Android and apple. It's not
| complicated at all yet they fuck it up endlessly.
|
| It seems screamingly obvious that I might want to give apps
| access to some of my files but not _all_ of my files. Some of my
| contacts but not all of my contacts. No such options exist. Many
| other permissions are also needlessly coarse grained for no
| particularly good reason.
|
| I probably want to see apps flagged which ask for permissions
| which are ridiculous given what they do and justifications from
| developers. Not possible.
|
| These things aren't intrinsically hard at all.
| loxs wrote:
| It's not hard per se. It's hard to do correctly only when you
| side with the advertisers' interests.
| jayrwren wrote:
| I hope this is the stupidest thing that I read today.
| garaetjjte wrote:
| >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?
| darksaints wrote:
| More importantly, why did they ask you about secure
| connections, but automatically assume that insecure connections
| were okay?
| [deleted]
| danilocesar wrote:
| Dark ages my friend. Luckily we know better nowadays =)
| neurostimulant wrote:
| 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.
| alexwasserman wrote:
| 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.
| JeremyNT wrote:
| 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.
| zymhan wrote:
| 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
| jfrunyon wrote:
| The Razr's had a camera... it might have been useless, but they
| _did_ have one.
| randyrand wrote:
| Mostly decent article, but one point - Android is hardly a
| libertarian free for all. Google controls the way apps must ask
| for permission.
|
| If anything it shows that with just a single choice and no
| competition, android apps just all have to do the same shity
| thing. Opposite of libertarian.
| marban wrote:
| I owned every generation of the Nokia 9xxx Communicator series
| and especially the 9500 with Symbian 7 was a joy to use.
|
| Nothing beat laying by the pool and doing a little office work on
| the brick.
| xiconfjs wrote:
| Last Symbian phone I used was a SonyEricsson P910 (Symbian
| UIQ3?). I loved the on device programming - writing a script
| answering SMS based on content was the best.
| jbverschoor wrote:
| 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.
| webwielder2 wrote:
| Or from another, more accurate, perspective, Symbian didn't win.
| cdbattags wrote:
| I believe this is the same reason why https://hey.com will win
| too.
|
| Product engineering where the app/service is one big A/B test is
| how you truly figure out what your users want and need.
| draw_down wrote:
| Somehow I imagine that Nokia had other goals with Symbian than
| "increase the number of dialogs in mobile applications". Like,
| they probably wanted to sell a lot of phones. Just guessing!
| qwerty456127 wrote:
| > 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.
| c0l0 wrote:
| 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.
| cestith wrote:
| > 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
| WrtCdEvrydy wrote:
| 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.
| com2kid wrote:
| The reason for location permissions is because BT can track
| your location through Bluetooth beacons. See https://develo
| per.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.
| autoexec wrote:
| > '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?
| nix23 wrote:
| Not saying your wrong, but you said something about SELinux and
| AppArmor..if your interested in that stuff you should checkout
| OpenBSD's pledge:
|
| https://man.openbsd.org/man2/pledge.2
| simias wrote:
| >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.
| jfrunyon wrote:
| 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`".
| saagarjha wrote:
| Yeah, until the program deletes itself from disk on launch.
| richardwhiuk wrote:
| Or edits that value.
| teknopaul wrote:
| 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.
| canada_dry wrote:
| > 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).
| hathym wrote:
| > 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, ...)
| messe wrote:
| > 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.
| [deleted]
| Fnoord wrote:
| 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
| jmull wrote:
| > 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.
| dmd wrote:
| https://support.apple.com/en-us/HT210999
| messe wrote:
| A WWDC talk confirmed that notarized Kexts will still be
| allowed, but you'll have to enable that option via MacOS
| Recovery.
| saagarjha wrote:
| As long as they're using non-deprecated KPIs. Those that
| are require another trip to Recovery to disable SIP.
| roel_v wrote:
| 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.
| Fnoord wrote:
| 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
| qwerty456127 wrote:
| 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.
| Fnoord wrote:
| True, its not production quality. Here is an actively
| developed fork/repo of OpenSnitch [1]
|
| [1] https://github.com/gustavo-iniguez-goya/opensnitch
| vetinari wrote:
| 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.
| jfrunyon wrote:
| /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.
| saagarjha wrote:
| > 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.
| ajross wrote:
| > 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.
| spockz wrote:
| Could this be implemented with iptables rules on a per
| container/jail basis, like with K8s?
| derefr wrote:
| 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!
| cglong wrote:
| 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
| perryizgr8 wrote:
| > 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.
| derefr wrote:
| 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.
| edef wrote:
| 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.
| maxwellito wrote:
| 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
| AgloeDreams wrote:
| 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.
| DaiPlusPlus wrote:
| 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.
| maxwellito wrote:
| 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?
| cryptoz wrote:
| 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.
| kllrnohj wrote:
| 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.
| augusto-moura wrote:
| 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
| Fnoord wrote:
| 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?
| criddell wrote:
| It isn't about need, it's about _want_.
| matt2000 wrote:
| > "Because, as it turns out, a Libertarian free-for-all doesn't
| work."
|
| But isn't that how the Internet works? No one "approves" a
| website for release.
| glosses wrote:
| Right, but browsers are "regulated". The attack surface that a
| website has against a user is much smaller than what an app
| has. Or at least was, I think websites and apps are converging
| now.
| rvz wrote:
| 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.
| edent wrote:
| 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.
| braythwayt wrote:
| 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?
| gravitas wrote:
| 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.
| dfox wrote:
| 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).
| jbverschoor wrote:
| BeOS had a thread for each BWindow. So 5 browser windows is 5
| threads for the windows and 1 for the BApplication.
| bulka wrote:
| "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.
| ClumsyPilot wrote:
| If the 'winners' have to adopt your ideas, you've won.
|
| At least if your ideas where more important to you than
| 'winning'
| mola wrote:
| 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.
| nl wrote:
| I used Symbian. It was _annoying_.
|
| Easy of use and better UX is a very valuable "innovation".
| secondcoming wrote:
| 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
| kanox wrote:
| This is a ridiculously shallow dismisal.
|
| Android and iOS "won" because the phones were vastly more
| capable.
| secondcoming wrote:
| 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)
| jbverschoor wrote:
| Except that they didn't have a proper browser.
|
| People tend to forget that you had a desktop quality
| browser in the first iPhone.
| secondcoming wrote:
| Opera was available for it
| pjmlp wrote:
| 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.
| mola wrote:
| 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.
| juliend2 wrote:
| 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.
| Nextgrid wrote:
| The other problem here is the lack of regulation.
|
| It's reasonable for a non-technical person to assume that any app
| whose provenance is known (thanks to the App Store's policies and
| requiring a valid DUNS number or similar) would be investigated &
| punished if they end up doing something malicious, so as long as
| traceability can be ensured (which it is) then it must be safe.
|
| I myself used to think that as long as I use apps from a major
| brand (so like Facebook, Google, etc) I should be safe because
| there's no way they're going to pull spyware-like tricks and
| steal personal data... right?
| cletus wrote:
| I like the screenshot in this post about the permissions Android
| apps ask for. At least this matches my experience. Android apps
| by and large just ask for everything so it's a choice between
| giving them everything or not being able to use them.
|
| Apple OTOH does two major things different:
|
| 1. Apple's approach is to ask for individual permissions it needs
| when it first needs them. I can't overstate how much better this
| is than the Android all-or-nothing permission dialog.
|
| 2. Apple's permissions make more sense to users. Things like:
|
| - Your location
|
| - Run in background
|
| - Your contacts
|
| - Your photos
|
| - The camera
|
| Android's permissions always struck me as what engineers would do
| if they designed a permission system.
|
| > Because, as it turns out, a Libertarian free-for-all doesn't
| work.
|
| TRUE. Big true.
|
| Honestly though I don't really see the author's point. I don't
| see iOS 14 and whatever the next Android version is to be back to
| what Symbian did.
| danans wrote:
| Android has prescribed apps to request individual permissions
| at runtime since Android 6.0 (released in 2015):
|
| https://developer.android.com/training/permissions/requestin...
|
| iOS switched to the runtime permission request in iOS 6
| (released in 2012), so they switched earlier than Android, but
| both platforms have had runtime permissions requests for years.
| arpa wrote:
| 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.
| bjarneh wrote:
| 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.
| mempko wrote:
| 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.
| al_ak wrote:
| I'm still bitter about their Indiegogo campaign. I did get
| half a refund, so that's better than most failed
| crowdsourced projects.
| zepearl wrote:
| 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.
| distances wrote:
| 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.
| scooble wrote:
| 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.
| kwhitefoot wrote:
| 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.
| bjarneh wrote:
| At some point it just got too slow, and the browser was
| just not up to scratch. Still the best looking phone ever
| made..
| Brakenshire wrote:
| 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.
| arpa wrote:
| 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.
| Fnoord wrote:
| 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
| Intermernet wrote:
| 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.
| Fnoord wrote:
| Sorry, I could've added a link.
|
| /e/ referred to [1], not Enlightenment.
|
| [1] https://e.foundation
| ploek wrote:
| 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).
|
| https://en.wikipedia.org/wiki/Moblin
|
| https://en.wikipedia.org/wiki/MeeGo
|
| https://en.wikipedia.org/wiki/Mer_(software_distribution)
|
| https://en.wikipedia.org/wiki/Sailfish_OS
| zozbot234 wrote:
| Maemo Leste is a fork of the original Maemo bits. It's
| still maintained, at least to some extent.
| thepangolino wrote:
| I really liked the Meego iteration. Its UI was top notch.
| shaan7 wrote:
| This guy did it justice
| https://www.youtube.com/watch?v=pO4iNau8AWM
| distances wrote:
| Thanks for the link! He perfectly describes how I feel
| about N9 still to this day.
| TLightful wrote:
| That's the third option I wish we had ...
|
| How on earth did this not take off ?
| shaan7 wrote:
| > How on earth did this not take off ?
|
| Monies. Microsoft's offer to Nokia was way too lucrative.
| senko wrote:
| 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.
| erincandescent wrote:
| 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
| Apocryphon wrote:
| Great video, great timing.
| qwerty456127 wrote:
| 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.
| hajile wrote:
| 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.
| em-bee wrote:
| 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.
| belorn wrote:
| 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.
| Mediterraneo10 wrote:
| 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.
| floatboth wrote:
| You can use a mainline kernel. (Without the GPU..)
| belorn wrote:
| 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.
| Mediterraneo10 wrote:
| > 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.
| jokoon wrote:
| 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.
| 6510 wrote:
| I really liked _Viktors amazing 4 bit processor_
|
| http://www.vttoth.com/CMS/index.php/projects/13-4-bit-proces...
| bglusman wrote:
| Being too early is the same as being wrong.
| jillesvangurp wrote:
| 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.
| Tade0 wrote:
| _I witnessed NEC and Sagem and a host of companies launch
| smartphones and then disappear._
|
| I don't know about Sagem, but NEC is alive and kicking. Its glory
| days of the 80s are very much over, but they managed to stay on
| the market.
| aleken wrote:
| J2ME also asked about permissions for everything. Miss that!
| mwcampbell wrote:
| A truly sane platform would use capability-based security with a
| Powerbox UI, as Sandstorm does:
| https://sandstorm.io/news/2015-06-10-network-access-permissi...
| TheRealPomax wrote:
| This kind of reads like the exact counter-point to the title:
| Symbian was doing the right thing, but in such a horrible fashion
| that ios and android were able to capitalise on "we offer less
| friction" at the expensive of what history has shown we had to
| pay for that convience. And history equally shoes we collectively
| quite happily did?
| GekkePrutser wrote:
| 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.
| epx wrote:
| Got depression doing Symbian development. (I am not kidding.)
| GekkePrutser wrote:
| 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.
| alecmg wrote:
| not enough information
|
| was it related to symbian design choices?
| joezydeco wrote:
| I vote for the threading model.
| trenchgun wrote:
| I vote for the ridiculous number of different devices,
| screen sizes, hardware etc.
|
| Maybe the compiling times too.
| Someone wrote:
| 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."_
| epx wrote:
| 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.
| cairoshikobon wrote:
| iPhone is Mac-only for development. Some things never
| change..
| pavlov wrote:
| 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");
| fredPtr.Copy(KFred);
|
| 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.
| secondcoming wrote:
| 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.
| spaetzleesser wrote:
| Same here. Easily the worst dev experience I have had on any
| platform. The worst part was that the platform itself seemed
| very capable.
| ballenf wrote:
| > Because, as it turns out, a Libertarian free-for-all doesn't
| work. It requires rational people to have an educated
| understanding of the risks they face. Millions of people
| installed dodgy apps, saw the one-time prompt, and lost control
| of their data.
|
| Doesn't the premise of the article disprove this statement?
| There's been no regulatory movement forcing the "Symbian"
| granular permission approach.
|
| I'd argue the pseudo-regulated app stores were a bigger source of
| the problem, not the "libertarian free-for-all". That is, having
| an app store with Apple or Google's name on it is what encouraged
| users to let their guard down and trust all the apps on it. If
| you had to download the "battery charger" app from Bob's Phone
| Tools' site instead of the Google Play store, you'd maybe be a
| little more skeptical of that permissions list.
| loxs wrote:
| And also, people usually take a people-concept and apply it to
| tech. "It can't work in tech, so it won't work for the market".
| On the contrary. Libertarianism does not forbid a company to
| implement whatever jailed garden it wants, so long as it does
| not force or lie to its customers. And the problem with the
| lying corporations does not come from the free market, it comes
| from government lobbying and protections. Regulations are only
| a way for the monopolists to curb competition, nothing more.
| fiatjaf wrote:
| Exactly what I wanted to say but couldn't find the words to do.
|
| This comment is beautiful and should be read every time someone
| complains about "libertarianism" in such a completely misguided
| manner.
| fsckboy wrote:
| 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.
| onli wrote:
| > _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 3EUR 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.
| moepstar wrote:
| >>> Especially the secure connection. Why would it ever ask
| that?
|
| For whatever reason, old Internet Explorers (9? 10? not sure..)
| do that too...
| jfrunyon wrote:
| The really old ones didn't even have a "remember this choice"
| checkbox.
| dcomp wrote:
| 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
___________________________________________________________________
(page generated 2020-06-25 23:00 UTC)