Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Symbian Source Code

github.com

Post reply on HN
Print view View original

191–199 of 199 posts

Re: Symbian Source Code

#191

Post by eddywebs »

commandar wrote: post #151
dietrichepp wrote: post #140

Earlier quoted context omitted.

Worth mentioning the N-Gage, which got a Wordle port recently, powered by SDL2: https://hackaday.com/2022/04/08/wordle-comes-to-the-nokia-n-... I remember the N-Gage being lambasted when it came out, but recently I realized that those same people also lambasted the iPod, and maybe I can't trust those people's judgment about tech. You know, the Slashdot crowd. Maybe it was a good system that was just poorly positioned…

>and the more recent comments I've heard about it are along the lines of "underrated system that was ahead of its time". It always had a following, but the thing flopping wasn't because of the Slashdot crowd, it's because it just wasn't very good out of the gate. The N-Gage has an awful form factor that made it suck both as a gaming device and as a phone. Game cartridges were hidden behind the battery, button placeme…

I think they changed that with Ngage QD next gen ngage loved that phone. Quite stable and powerful for an symbian os.

Re: Symbian Source Code

#192

Post by KolenCh »

OOPMan wrote: post #175
KolenCh wrote: post #159

Earlier quoted context omitted.

The above mentioned Python’s import delay. This is a notorious behavior in high performance situation (including your cli startup time example). Essentially the import process is IO intensive. This comes up in massive parallel applications as at launch each process is importing the same stuffs. It is briefly mentioned for example in https://docs.nersc.gov/development/languages/python/ If you really care about the sta…

I've run into the import issue as well, it's especially painful if something imported is doing work using a slow library (e.g. a config module loading a HOCON config using pyhocon a.k.a slowasmolasseshocon)

That will be another slow down happening at import stage. But even if ideally everything you import only does import with not much work, the import overhead mentioned above still exists. But frankly I’m not sure how significant it is on a typical personal computer with SSD, especially when the OS may cache recently used files already.

The problem you mention can be significant because some design patterns in Python encourages this. Eg function arg with a default that’s expensive. Unfortunately this whole speeds up repeatedly calling the func, the cost is paid at first import.

Re: Symbian Source Code

#193

Post by app4soft »

andri wrote: post #162
HidyBush wrote: post #3

If anyone's interested here's [0] a Mediafire archive of Symbian developer sources of all kinds, from compilers and SDKs to manuals. [0] https://www.mediafire.com/folder/79jhy594xb3uk/Symbian_Devel...

The same set files seem to be mirrored at https://katastrophos.net/symbian/mirrors/delight/ . Probably more wget-friendly than Mediafire.

Also, «Symbian Archive»[0,1] project has a lot of mirrors of Symbian source & software.

Here is a list of active Symbian software developers* (+ links to its projects).[2]

P.S. I'm luckily archived/mirrored LCG's X-plore[3] & ProfiMail[4] apps source repos in time when it was released into Public Domain by LonelyCatGames* team (now official repos is disabled).

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

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

[2] https://github.com/mrRosset/Symbian-Archive/issues/10

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

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

Re: Symbian Source Code

#194

Post by elzbardico »

epolanski wrote: post #128
orev wrote: post #33

Earlier quoted context omitted.

Before the iPhone, mobile device companies were held ransom by wireless carriers. Carriers dictated everything about the phones, down the Verizon demanding Bluetooth file transfer was disabled to force people to use data minutes to send pictures. This is one of the things that I think modern techies have forgotten. No matter what you think of Apple, they were the only ones with enough market power to force carriers o…

There are different markets than US and phones aren't only sold by carriers. Even admitting what you say in US is true, it definitely was not in Europe or Asia thus I doubt any of your analysis of carriers impacting the tech.

You obviously didn't live at this age or were too young. Most people in the late 90s and the early 2000s got their phones subsidized by a carrier. There was a time when the carriers were the most important channel for selling phones and this was not only in the US.

Re: Symbian Source Code

#196

Post by slashnik »

pavlov wrote: post #9
substation13 wrote: post #2

Anyone else feel sad coming across something like this? So many hours spent for a product that is largely forgotten. Glad to see the pieces out in the open though.

Symbian, the Ozymandias of smartphone operating systems. They had a lot of the right ideas very early. They started building a high-resolution graphical mobile OS for 32-bit ARM in the mid-1990s, when most phones barely could display two lines of text and receive an SMS. Many concepts in iOS and Android today were pioneered by Symbian. IMO, the biggest failing of Symbian was to disown the UI and focus on the lower la…

I love your post.

NB tho, Symbian already knew (see 1998) how to make a "truly excellent mobile GUI" - sure, it was a PDA, but we were already making phone UIs with phone licensees then, and could happily have made a "well-designed high-level UI framework".

I'd've loved that "parallel universe".

Alas, the Symbian deal nixed it, and our new owners simply wanted us to make their kind of phone platforms for them: four whole new ones, in 18 months (heh right), mainly to their specs, while recruiting 100 new devs and 10 new designers.

So I feel it's a little harsh to say "the biggest failing of Symbian was to disown the UI" -- we never had the option to keep control of it. (It was a major failing of the Symbian deal itself, sure.)

Re: Symbian Source Code

#197

Post by ryukoposting »

rollcat wrote: post #178
ryukoposting wrote: post #132

Earlier quoted context omitted.

In short, be the change you wish to see in the world. If you want there to be a viable competitor to Chrome, use Firefox. If you want there to be a viable competitor to Apple and Google (and you have the cash), buy a Librem 5. The alternatives are out there, begging to be used. As an active developer in a programming language with a small ecosystem, I scream this to the clouds all day: great software doesn't become w…

> If you want there to be a viable competitor to Apple and Google (and you have the cash), buy a Librem 5. No thank you, I will never buy or use any hardware from Purism. They are openly hypocritical and I have zero trust for them. Quoting from: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd... > The RYF has a “secondary processor” exclusion that can be granted on a case by case basis. We will leverage…

Keep in mind I was spitballing. Don't take the Librem example too seriously- I didn't know about that stuff, and it certainly changes the way I view Purism.

> This is why FOSS can't "win".

I'm not really sure what "win" means in this context. If "winning" is what Chrome is doing right now, I don't want Firefox to "win" either. Competition is good.

If your argument here is that FOSS can't produce a "better" product, Firefox is as much a counterpoint now as it was when it broke the IE hegemony. For the user, it's just as good as Chrome. It even provides some features Chrome doesn't have (for example, popping out videos and actually-good ad block). Nobody cares about how chrome is 50% (i.e. 0.8ms) faster at responding to thing X.

Re: Symbian Source Code

#198

Post by rollcat »

ryukoposting wrote: post #197
rollcat wrote: post #178

Earlier quoted context omitted.

> If you want there to be a viable competitor to Apple and Google (and you have the cash), buy a Librem 5. No thank you, I will never buy or use any hardware from Purism. They are openly hypocritical and I have zero trust for them. Quoting from: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd... > The RYF has a “secondary processor” exclusion that can be granted on a case by case basis. We will leverage…

Keep in mind I was spitballing. Don't take the Librem example too seriously- I didn't know about that stuff, and it certainly changes the way I view Purism. > This is why FOSS can't "win". I'm not really sure what "win" means in this context. If "winning" is what Chrome is doing right now, I don't want Firefox to "win" either. Competition is good. If your argument here is that FOSS can't produce a "better" product, F…

> Don't take the Librem example too seriously- I didn't know about that stuff, and it certainly changes the way I view Purism.

This is the problem. You advise on something, but you barely look beneath the surface.

> If "winning" is what Chrome is doing right now, I don't want Firefox to "win" either. Competition is good.

Please take a good look at what Mozilla has been busy with, this past decade or so.

https://www.jwz.org/blog/2022/01/mozilla-blinked/ https://www.jwz.org/blog/2020/09/this-is-a-pretty-dire-asses... https://www.jwz.org/blog/2018/12/mozilla-mourns-microsoft/ https://venturebeat.com/2015/06/09/mozilla-responds-to-firef... https://en.wikipedia.org/wiki/Firefox_OS

All this happened while Firefox struggled to modernise the rendering engine, introduce process isolation, address stability and performance issues... Yes I know Quantum eventually delivered on these - but it was too little, too late, and still isn't great.

The only reason Mozilla is still alive, is because Google is throwing money at them - to avoid too much attention from regulators looking at Chrome's market share.

> Nobody cares about how chrome is 50% (i.e. 0.8ms) faster at responding to thing X.

I care. Just put it on any older hardware. Like my 2012 Thinkpad (3rd gen i5; OpenBSD), or my partner's 2017 MBP (infamous for its poor thermal design), running Firefox on either is a miserable experience compared to Iridium (Chromium fork) or Safari. The hardware is still pretty good for our needs.

Don't get me wrong: I dislike Chrome just as much as you do. I want to like Firefox, and I do agree with Mozilla's stated goals and values. But I won't (and wouldn't advise anyone to) personally suffer over this, in fact doing so is doing Mozilla a disservice - they need to get the message, fix their act, and deliver a better product; rather than blowing cash on CEO bonuses, sealing deals to screw their users, or engaging in planet-incinerating ponzi schemes.

Re: Symbian Source Code

#199

Post by marcodiego »

pjmlp wrote: post #183
marcodiego wrote: post #44

Earlier quoted context omitted.

> a windows port of the GNU toolchain, so it would only work on windows. But even on windows it had a lot of warts (because these tools were build for unix in the first place, so e.g. drive letters and back slashes were problematic). About a decade ago I worked on a project for a South Korean cellphone vendor whose name I'll not cite for somewhat obvious reasons. The build system was similar to what you describe: a p…

Let me guess, that little Symbian like clone known as Bada.

No.
Post reply on HN