Hacker News Reader

Comment by oriesdan | Hacker News Reader

For the record, I received yesterday the new mainboard that will be in those phones to replace the one of my pinephone UBport edition. The boost in RAM (3gb instead of 2gb) does the trick for me, allowing to use firefox. Not to the point that the experience is even close to android, but at least usable (before that, I used elinks on the phone).

The system I use (mobian/phosh) still feels sluggish, but I suspect it's more a matter of software than hardware, now. I tried yesterday KDE neon/plasma with that new board, but had problems that the screen would black out after a few minutes of use (had to do hard reboot to recover).

I see in this release announcement that their build of plasma is on top on Manjaro, I'll have to try that one. It's especially interesting because someone from Plasma mobile team told on HN the other day that they support MMS.

View on HN

I grew up in the C64 days - I still can't get my head around the fact that you need 3gb of RAM because 2gb is not enough to run a webbrowser these days.

I know that what's going on on a typical website these days requires an enormous amount of computational power, but I mean, come on. That shouldn't be the explanation, it's part of the problem.

Any content you see on the screen hasn't changed at all.

On a typical website all of the analytics are causing page bloat.

Sometimes there are frameworks like bootstrap but hypothetically those should be cached.

If you are looking at a web application then it has a framework that is a magnitude higher and the rest of it you see a significant increase.

Website bloat isn't the explanation. Firefox on the original 2GB Pinephone board is painfully slow even if you have uBlock Origin and Noscript installed. It is slow even to open and browse to a minimalist text-only website with. I'm not sure how much of this is Firefox, and how much is the whole Mobian UI that depends on GNOME components that have not been optimized to save RAM.

It also has a lot to do with the fact that the Pinephone CPU is underpowered compared to anything from 2020 (or almost anything from 2015, really).

It is too bad (in the case of parsing) most websites have dynamic HTML structures... I wonder how hard it would be if you had some browser/wrapper that made most websites into wire-frame boxes, text to be simpler to render

You do realize if you use ublock Origin and Noscript that actually degrades your performance because it has to verify to not load that information.

My apologies for not making myself entirely clear: even if you have no addons whatsoever, and you open Firefox and try to navigate to some bare-bones text-only website, even that is extremely slow on the 2GB Pinephone.

However, I would question whether uBlock Origin degrades performance – my own experience running Firefox on low-memory platforms like netbooks and the Raspberry Pi suggests that is not the case. Yes, addons use some amount of RAM, but if they prevent the device from loading a modern advertising-based webpage where the ads and analytics run into the many megabytes and the useless Javascript is CPU-intensive, it seems to work out as a net benefit.

Firefox on the original 2GiB pinephone runs just fine (Xorg/i3wm) even on a 1440p monitor with non-JS easy to compose websites (no complicated CSS filters, blur, etc.) with smooth scrolling.

It's only slowed down by storage access speeds mostly.

https://www.youtube.com/watch?v=LdKNugT-mTQ

And this demo is purposefully using both displays at once to stress the device more. With single display mode there's less demands on RAM, and more bandwidth is available to CPU.

Or https://www.youtube.com/watch?v=ZqJOs0YwjwY

It isn't the Bootstrap-like frameworks that are causing bloat. It's that websites are written as apps these days by people with relatively beefy machines compared to consumers who don't usually buy top of the line hardware every year.

For example, compare Twitter or Facebook to their recent SPA rewrites in React. I can't use either without sacrificing GBs of residential memory. Loading anything on those sites now requires many more CPU cycles than they did before.

Reddit is the worst offender for me. I don’t know if they use react? But whatever they’ve done, it’s horrific. It’s bad even on my top of the line 2020 Intel 13” MacBook Pro (the i7 one)!

Pretty sure they do, or at least they use another SPA framework. I would have mentioned Reddit, but forgot about its rewrite because old.reddit.com still works.

Especially since on PC it doesn't even need 1gb. With 7 add-ons (one being an adblocker) and Firefox having spawned 9 processes in Win10 it still uses less than 1GB RAM for me (even though two tabs are chats, so background-active). Something is clearly either wrong in the Firefox he run, his add-ons or Phinephone.

Or maybe that the os needs some ram, too?

And no, the firmware and drivers are sadly not memory optimized (or barely run at all), as ar as I know.

I did not know, that in C64 days you had a browser, with x WebAPIs to do various networking stuff, p2p, soundAPI, database, payment processing, complex - hardware accelerated styling and composite of layout, plattform irrelevant assembler subset, with a integrated IDE etc. etc.

A Webbrowser these days is simply much, much more than a static document viewer, despite this might be, what you want it to be.

I don’t think you need all that for the important stuff.

But other people think different of "important stuff" thats why it is there.

And those who really want only simple HTMl rendering, I believe there are lightweight alternatives (?).

And if not, well then maybe there is simply not enough demand, because most people apparently want to be able to have a email client in the browser and do online banking, or edit Wikipedia articles in a rich html editor, or play games, or watch videos and share and comment them or even do video editing, ... all in the browser.

> And if not, well then maybe there is simply not enough demand, because most people apparently want to be able to have a email client in the browser and do online banking, or edit Wikipedia articles in a rich html editor, or play games, or watch videos and share and comment them or even do video editing, ... all in the browser.

IMO they largely just want to do all these things in an open core VM, without risking installing malware on the ridiculously insecure proprietary OS most of them use if/when they use desktop computers.

Well yes and currently there is no alternative to a webbrowser which needs a lot of RAM for these tasks ... which was the main point, right? And not that we could do much better in theory. No doubt about that. But reality is the browser is usually the most pragmatic solution right now to most use cases. Which is good, when I can do online banking in a very niche project like pine, or do you think banks would port and certify their apps for the various linux distros?

Not to mention video.

I wonder if we could grade how much better a current system is vs something like the QNX 1.44MB demo disk.

http://toastytech.com/guis/qnxdemo.html

Thats easy: does the qnx meets the requirement of a modern browser?

No, then it is not.

Or do you mean in academical sense of functionaliy per byte? How useful is that?

It’s interesting because the original iPhone from 2007 managed pretty well with a half a gigabyte of RAM (or was it a quarter?).

An eighth (128 MB) in fact, according to Wikipedia. The original Galaxy S had 512 MB though.

Hasn’t Android always needed more though due to its use of an interpreter/JITer (JVM initially) instead of native code? That doesn’t explain why the PinePhone would need more than two gigabytes for a browser.

Android never used the JVM.

Boat has sailed. Recently told an intern to setup a simple notification system at work between Linux desktops and Android phones. He ended up downloading 2 GB of Android tooling and 600 MB of kdeconnect to build basically a TCP connection.

Reminds me of garbage bins. The larger the bin I have the more rubbish I find to fill it.

Supposedly improvements in hardware acceleration have changed this but IME a window manager with no compositing is way faster than phosh. I use fluxbox and on that firefox scrolls in real time for example.

Thanks for mentioning it.

How does fluxbox works on mobile? Is it basically the same than the desktop on a small resolution, or it can receive phone calls and have a notification bar?

If it's the compositor that causes the problem, can't it be disabled? I don't know phosh but in Plasma you can disable the compositing from the system settings.

Nope, there's no option for that in phosh settings. Actually, it's the compositor (phoc) that starts gnome-session in /usr/bin/phosh. I've just tried to edit the startup script to launch gnome-session directly, but it would refuse to start.

It's also a pure wayland system, so it's quite unlike what we're used on desktop.

I see, thanks for your explanations :).

> It's also a pure wayland system, so it's quite unlike what we're used on desktop.

When you say "pure", do you mean "no XWayland"?

All Phosh distributions I’ve come across have Xwayland.

Yes, which means you can actually see the windows for things running in the background which can be nice when your eg reading something from firefox while writing an email. All the phone stuff is handled by chatty and calls, notifications are handled by libnotify, alert sounds are handled by feedbackd etc.

Have you tried Sxmo? It's a very lightweight UI based on suckless programs but seems like it would make the phone functions calls, sms, very intuitive & easy to access. It's based on postmarketOS anything supporting that should also work.

https://wiki.pine64.org/index.php/PinePhone_Software_Release...

I’ve been using Mobian on the UBport edition for the last month. Sluggish doesn’t even describe the usability.

I bought a few data only sims in hopes of leaving the house for short errands with different devices. There is no way I could leave the house with the pinephone. It isn’t usable yet. Could an extra gig of RAM solve this? It seems like it needs years of work.

As you noticed, it's not just a RAM issue. The problem is that Linux GUI and apps generally expect laptop/desktop-ish levels of hardware capabilities because that's what they were developed on/for. You're literally running the same code base that the x86 versions run, just recompiled for ARM. Most mobile SoCs, especially the ones that are Linux-friendly in terms of being open enough to be viable, are not even remotely that. On iOS and Android, widely used apps such as browsers are extensively optimized for mobile.

On the Pinephone, and all other ARM-based Linux devices, we're still running applications like web browsers that were written expecting to run on multi-core I/O monsters with lots of RAM, beefier GPUs etc. (the main exception being the main GUI shell... it would be so much worse if you had to boot the phone into a full Gnome/KDE environment) We're still in the late stages of getting the pile of software that is a typical Linux distro running at all on a mobile device. Then assuming these devices get enough traction, you'll start to see more effort put into mobile-optimized software.

Hmmm great points. Is this a "call for mobile versions" of classic Linux programs in a way?

Definitely... that's part of the reason I chime in when this topic comes up. Having done both Linux and mobile development, I don't believe that the entirety of the answer is going to be 'just throw a more powerful SoC in the device'. Sure, that will help to a degree in some areas but there is a lot of work that has been put into iOS and Android to achieve a balance between battery life and performance that most developers who have only worked in/on Linux haven't appreciated. Which is understandable since it wasn't 'their' problem... now with the Pinephone/Librem 5, it is.

Something I have found worthwhile has been listening to the UBports podcast over the last 6 months or so. They really do seem to be 'getting it' faster than most re: what's left to be done. That's partly because they're in the rather unique position of coming from a place of having the Android kernel (which isn't just a vanilla Linux kernel) do a lot of things for them (i.e. UBports on Android phones) and now that they're running on bare metal (i.e. UBports on Pinephone) with (mostly) the same code base they are able to see 'oh, yeah... the kernel and/or apps need to be able to do Y' in order to replicate the functionality they get on Android phones.

UBports relies on 2014-era Ubuntu-specific software that even Ubuntu moved away from. Consequently, I expect a lot of UBports to bit-rot before its maintainers can make it a reliable and competitive option. Mobian's stack isn't what I would have liked (it is a lot of unoptimized GNOME libs), but at least it seems to have enough corporate backing for development to keep going.

Yeah, both projects have their challenges. It's been good to see them, as well as the Librem developers, working with each other to advance their respective projects where it makes sense.

Just curious, what corporate backing are you referring to? I hadn't heard that before.

Historically so much of the GNOME tech stack which Mobian is based on, has been developed by Red Hat employees.

Is it possible the Raspberry Pi ecosystem could move things forward for ARM based linux devices? I know they aren’t mobile, but it is a strong ecosystem with some traction.

In a sense it already has. I suspect the reason that Linux ARM support is as good as it is currently has a lot to do with devices like the Raspberry Pi. In 2010 (i.e. before the Pi) I was using a BeagleBoard-xM and things were both rough and spartan. Today the ARM packages in the repos are nearly at parity and things work much better.

However, the Pi has never gotten much beyond being a forky port of Linux software (back then they had to: they were an arm6hf device in an arm7hf world) and since they seem determined to stay forked (i.e. they no longer need to be a fork, but rather seem to want to be), I don't expect much more from the project in terms of broader Linux enhancements. I'd love to be proven wrong on this.

In that regard pine64 is better, they attempt to get things upstream.

> The problem is that Linux GUI and apps generally expect laptop/desktop-ish levels of hardware capabilities because that's what they were developed on/for.

I remember running x11 and Java w/swing on 8MB 486 laptop... So something is off if multiple cores at 30-100 times the frequency can't run a gui?

Yep. But on mobile, Linux seem to run fine on the n900 and Ubuntu Phones.

The FreeRunner and Zaurus were sluggish, but they’re also on hardware that’s about 15 years old

My Nokia N9 ran a Debian derivative quite well. Gosh I miss that phone.

I have an old 32-bit machine from like 2005 with 2GB of memory running MATE Desktop that Firefox sails on, and that you can open several tabs on without it being a problem.

Yeah, it's obviously software related issues ... rather than having so many different distros running on it, it would be far more impressive to me if there was an demonstrable clear focus on improving performance!!

Relatedly, I've had a much better experience with Chromium than Firefox on my Pinebook -- I'm willing to bet this is because of Google's investment in Chromebooks.

RAM will not solve this. Extra RAM will only allow you do do more things at once.

I tried Mobian but eventually switched to https://github.com/dreemurrs-embedded/Pine64-Arch - the phone is much more usable for me including Firefox. I am waiting to receive my updated board and look forward to further improvements.

> It's especially interesting because someone from Plasma mobile team told on HN the other day that they support MMS.

I'm curious about this too, as I explicitly tried plasma mobile on several distros (PostmarketOS, Manjaro, KDE Neon), and MMS did not work for me at all. It seems to work on the ofono stack, which seems to be closer to supporting MMS versus ModemManger + Chatty, but I'd love to hear from that same person again to hear their set up.

For reference, this was the post, in case you come around the author : https://news.ycombinator.com/item?id=25101199

IIRC (not a MMS user, it never took off in Germany) MMS requires provider/carrier specific settings (e.g. a special MMS APN) to be set, meaning that it may not work for you even though it’s properly implemented.

The screen blacking out thing might be due to DRAM speeds or timings being too aggressive. I received a manjaro CE phone the other day that does the same thing.

https://forum.pine64.org/showthread.php?tid=9832 has more info

Elinks has known vulnerabilities in JavaScript (Spidermonkey) and possibly other parts. It is abandonware, and should not be used. You could use a terminal, mosh, and Browsh, allowing you to use Firefox remotely.

Reply on news.ycombinator.com