Follow

Some observations regarding what DE works best on which distro for the :

- ( mobile shell by Purism) is probably the most "ready" mobile shell overall, mainly in need of more GTK apps that utilize libhandy to resize themselves properly for the small screen.

In particular would be a good candidate since every modern smartphone needs a good email client in its arsenal.

has probably the best implementation, followed by & ARM/Manjaro

in particular shines with its mobile friendly config that also works with non-ESR versions, but it's held back by insisting on not using and the fact that just can't handle deep CRUST sleep properly, which is not a problem on say .

however currently relies on Firefox ESR, rather than the latest stable version, however it does have the most mobile parches to make apps usable on the small screen, including for Geary.

Show thread

For Plasma Mobile, there's the KDE Neon builds for the , however they feel less functional than the Manjaro Plasma builds, specifically when it comes to turning of the screen, going to sleep, waking up and also the Neon builds seem more prone to freezes.

That being said, it is hard to recommend a Manjaro build after all the drama they've been involved in and how they treat upstream.

Plasma also has problems bringing up the keyboard in GTK apps, so I'd wait for a while re KDE.

Show thread

Plasma implementation is currently rather broken, sleep doesn't work at all for example, but they do have an interesting UI that few others offer; .

Sxmo is basically a config for the PinePhone with some additional tooling to make it recognize touchscreen gestures and handle rapid successive key presses in order to map more functionality on to the 3 HW buttons of the PinePhone than they would normally be able to.

This feels the most old-school UNIXy and power user UI

Show thread

After initially being skeptical, I can honestly see myself using Sxmo, my only concern really would be with its reliance on the hardware buttons of the which do not feel built with the intention of being used constantly, so them being the primary method of interaction with the UI may not have been the wisest choice.

Other than that, am impressed with it.

Also, it's pretty much the only UI where deep sleep works flawlessly without having to echo to /sys...

sr.ht/~mil/Sxmo

Show thread

Another important feature implemented by and not offered by any other distro at this point is full disk encryption, which I think is a must for a mobile device in 2020.

Show thread

Overall, my recommendation would be:

If you want Phosh shell, go with first or if you want full disk encryption then but be ready to use a shell script to trigger deep sleep, because only can handle it properly atm and pmOS doesn't use it.

If you want Plasma Mobile, I'd suggest you wait until at least the next release when the pmOS implementation is supposed to get better, if you cannot wait there's the Manjaro Plasma builds.

Also, give a try, it's fun.

Show thread

@ivanrancic They've broken their own internal rules on how they should go about spending donated funds and then censored + fired their treasurer for exposing it.

They also don't acknowledge the work ARM is doing upstream in any of their announcements and have been known to actively modify PKGBUILDs to remove Arch maintainers from them.

It feels like a bit of a parasitic project. I do think there's probably plenty of people in there trying their best, but the leadership feels dodgy

@MatejLach >postmarket doesn't support systemd
sounds like a pro to me

@georgia It results in a worse system in practice, but I guess it's worth taking the hit because Poettering or something I guess.

@MatejLach I mean systemd falls back to googles DNS and NTP but sure its totally compatible with FOSS values

@georgia Mine doesn't.All it takes is setting FallbackDNS to whatever.

That said, many of Alpine's components are not even copyleft, which to me is rather concerning.

@MatejLach changing fallback DNS is above even many Linux users who don't know they're phoning home to Google. what in alpine isnt copyleft besides musl?

@MatejLach "insisting" is just wrong. First of all that implies that not using systemd would be wrong, which is very much subjective and a highly controversial thing to state.

Secondly, it's literally not possible because systemd doesn't compile with Musl and interest has no interest whatsoever in fixing that or maintaining support for that in the future.

@postmarketOS In my opinion not using the GNU stack is also a problem. I know it's justified by all kinds of "small, fast" claims, but in practice even the Alpine SDK itself requires the GNU toolchain, which is rather ironic if you ask me.

My problem with these choices is that they actually result in a worse experience overall. Specifically systemd-based distros for the PinePhone that I've tested handle suspend no problem, whereas pmOS has it broken.

Not using systemd is imo detrimental.

@postmarketOS

I appreciate what pmOS is trying to do in general and have pointed out that it is the only distro for the PinePhone right now supporting full disk encryption, which is really important for me.

But it's also true that systemd based distros fare much better when it comes to power management and battery life than pmOS currently does and it's important to give you guys credit where it's due, but I just think that swimming against systemd results in a worse experience for users.

@postmarketOS Granted, optimally there would be a choice of init systems and whoever wants OpenRC can use that, but systemd is also an option.

I get that's not possible because of upstream choices, but I wouldn't go blaming systemd maintainers for that. No project wants to take on maintaining a minority use case for little benefit.

I realize it's popular to dunk on systemd, but every "alternative" I've ever used was less complete and more buggy.

Your mileage may vary, am talking about mine.

@MatejLach I'm not blaming systemd maintainers, I'm just explaining why we can't use even if we wanted too.

Yes suspend currently isn't triggered on button press but I'd say that is being worked on and "just use systemd" to fix that problem would cause a whole bunch of other problems for us. Again, I have nothing against systemd, I just wanted to make clear that not using it doesn't mean we're automatically doing something bad and that we can't use it even if we wanted too

@postmarketOS Fair. I understand that point. You're based on Alpine which dictates musl and probably it also makes it easier to get pmOS going on Android devices.

As I said, I think rather highly of pmOS and appreciate everyone;s work.
I've got the pmOS CE PinePhone and participated in the community before. I like it.

That does not mean I cannot observe that systemd based distros handle things better atm than non-systemd based ones when it comes to suspend and thus battery life.

@postmarketOS
As for your constraints of not being able to use systemd and/or give users choice in doing so, I understand that too, you're downstream of Alpine which made a bunch of these choices and you decided that's what you like so based off them.

Nothing wrong with that as a project, if you're also willing to acknowledge that it has downsides, like suspend not working right now, or Plasma Mobile not even shutting the display off when the power button is pressed.

That's a matter of fact

@postmarketOS

One can respect something, even admire it, but still have some criticism for it.

I don't hold secret that in my opinion the negative aspects of systemd are rather overblown and the alternatives viewed with rose-colored glasses; OpenRC is basically a spiced up SysV init, which, in my opinion again, was pile of inconsistent shell scripts of variable quality, with varying failure modes and not portable access distros.

systemd solved that with portable, declarative services.

@postmarketOS

In my opinion, systemd's approach is vastly superior, however I do get that choices were made, (not by some kind of God btw, by the pmOS project itself), that mean that systemd cannot be integrated or even made a choice due to upstream being Alpine.

I'd done it differently myself, but I am not in charge of the project and I do respect your choices, your time and your efforts.

I do even prefer to run pmOS over systemd distros on my PinePhone due to its support for FDE.

@postmarketOS All that does not change the fact that factually the choice of Alpine as upstream and thus also OpenRC as init does in fact factually mean that right now the battery life and overall experience is worse on pmOS than some other distros which embraced systemd.

I know it's being worked on too, I am writing about my observations as of now, once these fixes land, I'll post an update.

Still, am a big fan of your project, appreciate the effort put in and am generally positive re pmOS.

@MatejLach To me SailfishOS has by very far the most ready DE, even if I'm biased towards it as a ~long time SailfishOS user (it's been about 5 years now).

@lanodan
Yeah, it's most ready, but partly proprietary (UI stuff & AOSP emulator). That's not the longterm solution :)
@MatejLach

@okias @MatejLach Well, longterm to me is extracting it's libre parts and putting it into PostmarketOS.

@lanodan @okias Yeah, definitely the most ready UI. I have a Sony Xperia X2 that runs the official port and it's super usable.

My hope would be that they open the UI sometime and maybe officially support the PinePhone, (wouldn't mind paying for the port like on the Xperia), so we can run it on a mainline kernel.

@MatejLach
Geary adaptive UI is worked on (not upstreamed yet, thou PureOS should have working package).

Sign in to participate in the conversation
Matej Lach's mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!