Here’s the wiki page: https://wiki.postmarketos.org/wiki/Nothing_CMF_Phone_1_(nothing-tetris)

The FLX1 did not have DP alt mode either, unless I am totally mistaken. All external display concepts for the FLX1 were/are to require sth like DisplayLink. So all that’s lost are file transfer speeds over USB.

From what I could gather, they wanted to make more of the original FLX1, but could not get the a manufacturer to do that. I am actually not too unhappy with this one, the orginal FLX1 was too big and heavy for my liking.

In theory, you should just see the same apps in Discover and in GNOME Software, assuming they both can access/install native Alpine and flathub apps. (And I recall they did at some point in time, but breakage unfortunately happens, and I mostly use the terminal to install and remove things…)

With Ubuntu Touch apps it’s different, the Open Store is its own thing. I want to look into whether adapting this to postmarketOS when I can find the time.

Regarding few apps: Yes, it could be more, yes, there are gaps, but we’re doing somewhat okay: https://linuxphoneapps.org/

Glad that works for you! With my bank (comdirect.de) I can use a mobile website, and if I were to use something AOSP- or Halium-based, I could also use their PhotoTAN app, which, as the name implies, needs a working camera in Waydroid (on my OP6 with pmOS, the cameras work via libcamera, but not in Waydroid), so I have a small gadget for all these TANs.

My main worry with the “let’s just use Play Store/Aurora store and the run that apk”-approach is that it does not really send a visible signal to banks that they need to keep considering customers that don’t use Android proper.

It also always means that the next update (e.g., after some consultancy or some audit happened) may not work any more, meaning, access may be revoked at any time. Complaining to customer service or in Play Store reviews may have an effect, but it will still hurt. I think I would feel a tad safer if a banking app lived on FDroid… but sill.

I hope this gets my point across.

As someone who spent some time on the topic (result), it’s not that every new app is adaptive. Even if someone uses the nice new widgets of libadwaita (or previously libhandy (GTK3)), that app is not necessary running well on mobile if width-reqests demand a higher minimal width or content is just too wide.

The same is true for QtQuick Components or Kirigami, which are the equivalent for adaptive Qt apps.

That said, yes, many new apps developed with these technologies work fine OOTB without the developer even knowing; and if they are too wide or tall, fixing that is usually rather simple and not a full rewrite/redesign.

Not directly, here’s what we have:

https://linuxphoneapps.org/categories/maps-and-navigation/

Of these, at least PureMaps does turn-by-turn - as a no-car-person that last drove in meaningful way when paper maps where a thing, I am the wrong person to ask about car navigation stuff.

Additionally, there’s the OrganicMaps desktop flatpak (not a great experience, only good for seeing where you are) and zooming around. Fortunately, a work on a mobile-friendly Kirigami app for OrganicMaps has been funded by nlnet.

Also, runnning some web Maps in a browser (e.g., via https://linuxphoneapps.org/apps/dev.heppen.webapps/) is always an option (e.g., for browsing Google Maps for an open restaurant nearby).

Just 2ct’s on the banking thing (sorry if it sounds rude, but I just can’t hear it anymore):

Just forget banking apps of you don’t want to stay on iOS or proper Google Android forever and ever and ever, even AOSP-based OSes struggle with that (a lot).

Go to a bank that still has a proper website and allows some kind of hardware device for TAN (and tell them that this is why you are leaving/joining) - we need to show market demand for alternative solutions or else these will disappear completely over time.

We also need to make regulators/politicians understand, that taking part in life must be possible without owning a device blessed by Google or Apple. We really need laws here.

Regarding Android apps: I hope that https://gitlab.com/android_translation_layer/android_translation_layer will make a difference here going forward. A Wine-like approach is just so much less of a resource hog.

Regarding the Camera on the PinePhone Pro: It somewhat works by now, if not on every OS. Be it with libcamera or Megapixels 2, we’re getting there. I suppose it’s just that nobody told the Wiki.

Having had both a Pinebook and a Pinebook Pro and two PinePhones and a PinePhone Pro at some point in time (I co-hosted a PINE64 podcast for a bit), I don’t follow. If your point is that the PinePhone (Pro) have never been a great for everybody, I think the same is true of Pinebooks (Pro), they’re definitely are among the worst laptops I have ever had. Various just as cheap ARM-based Chromebooks (especially the ASUS C101p) I’ve had were/are just so much better.

The PinePhone really helped with development of existing Linux on Mobile projects and caused the creation of some additional ones, as evidenced by the massive number of projects on https://pine64.org/documentation/PinePhone/Software/#software-releases.

The Community Editions helped projects like UBports or postmarketOS financially. Some people even daily drive the device (despite being slow, I’ve found Sxmo and Sailfish OS to be acceptable, with Phosh coming in third).

While I don’t recommend it anymore for anyone who wants to use GTK based stuff on it, I’d view it as a success (I don’t view the Pro as a success though, even though I believe they should have cancelled the A64-based PinePhone, not the Pro - a PP2 was IMHO overdue around 2023/2024). With better Quality Control, better relations between PineStore and the wider Community and a different default OS (putting the heavy Plasma Mobile on it was just nuts, and Manjaro definitely is not my favorite distro, to say the least) for the Beta edition, it could have been an even bigger success.

Yes, it didn’t work for everybody, but as getting to a working laptop is so much easier than getting to a working phone (think of calls: the device has to manage to wake up at any moment (and fast), audio routing must be switched, echoes must be cancelled etc.) with the sky-high user expectations attached to phones (and the shitload of semi-hostile phone carriers across the world), I regard the PinePhone as quite an achievement.

+1 for the Surface Go 2. I use on of these with NixOS GNOME, and it’s lovely. For Pen use I like Rnote. You could also use Plasma Mobile on it. The Go 3 is not really better, so don’t get it unless it is in the same price range, and avoid the 64 GB eMMC model.

That’s the age of the design. If you look at first use (usually a year later), and then widespread use beyond flagship chips for big cores (2+ years later), you’ll end up with different dates. Not every core ARM puts out ends up being used in a ton of chips across SoC vendors, as some fare better in the trade-of between transistors and real world performance/energy efficiency than others. A76 is definitely popular, if you look at SoC out there. The RK3588(s) GPU was announced in 2021 and shipped in 2022 first - so it’s relatively new, as the SoC is also not that old: RK3588s was introduced in early 2022, and these days it has decent enough Linux support to start building a Linux-first product with it.

The issue for small companies like Liberux is that they

1. can’t even get every chip on the market, as the Qualcomms of this world do not care about low volume operations (in addition to that, they need longer availability as they can’t afford to change chips at the pace bigger players do), and
2. need to pick a chip that fits the power envelope of their design AND has decent enough mainline Linux support.

That narrows things down very much, and leaves a quite narrow chip selection. Another start-up with the same goal, dawndrums, are designing around the same chip for that very same reason.

If you are in doubt about how competent RK3588(s) is, look into the work that Lucie from MNT does - a lot of future product design is done on MNT hardware, these days powered by that very RK3588.

The thing is: As far as I could gather, they are planning make this in Spain, which - in addition to small scale production (you pay more per part if you order less) introduces higher wages (and costs due to different regulations etc.).

Would I like it to be cheaper? Yes. But ceteris paribus I would not trust them to make it if this where cheaper.

Regarding alternatives, postmarketOS and Mobian also work on old Android phones.

It has 5G.

If this was their second try, after the first one had had an unreliable modem, it would make sense to advertise the modem as reliable… but that’s not the situation they are in.

The passcode doesn’t have to be 6-digit only, we could store the number of char somewhere if the user wants this feature!

That is a good point, having this configurable would certainly be a nice change for everyone.

One more thing regarding Phosh:

what is wrong with the emoji keyboard?? it’s bad

Now, there’s not just Squeekboard (which is the default on postmarketOS), but we also have other keyboards that you can try:

• https://gitlab.gnome.org/guidog/phosh-osk-stub (default in Mobian, Droidian and FuriOS)
• https://gitlab.com/flamingradian/unfettered-keyboard

and some people have managed to get Sxmo’s wvkbd to run with Phosh (see https://github.com/WHO53/wvkbd-phosh-osk for an example, I have tried another approach back in the day (but failed).

I think the matter is that:

• all main UT contributors are aware that VoLTE is that many people need (and those who don’t need it yet are going to need it eventually),
• the project has been working on it for years,
• but sadly it’s difficult, because even if you get it to work, it’s usually per device, and even when VoLTE works on a device on one carrier, that does not mean it will work on every carrier.

Also, being asked / or even encouraged again and again about one thing, can lead to burnout and will definitely not bring up happy feelings.

Just chiming in regarding apps (because https://linuxphoneapps.org/ is my hobby, where I still have to add a bunch of apps I assume are created by you – if that’s you, thanks for the apps!):

no good Bitwarden client GoldWarden just crash and seems abandonned

Have you tried https://codeberg.org/Chfkch/bitritter ?

(I am a KeePass user, so my first hand experience is not comparable to real-world use)

GS Connect works, but needs a tweak and UI is not good on small screen

I’d suggest https://valent.andyholmes.ca/

No lemmy apps

Yeah, the state of Lemmy apps is not great. I’ve tried a bunch, and aside from the Lemmur fork (that seems abandonned), only Nimlem felt like it had potential.

For the rest: I don’t really use Discord, YouTube and don’t have a Jellyfin instance, so … can’t suggest much here.

Regarding Phosh and GNOME Shell Mobile:

we need a way to bring up the OSK like on Phosh (holding the botto bar for a sec for example, maybe itcould be customizable too?)

IIRC, double tapping the white bottom bar thing should do that. IMHO, like with gestures, I just would love to see more consistency between GNOME Shell Mobile and Phosh where possible.

We NEED to press the unlock button after typing our code (would be neat to have the code automatically unlock the phone when we enter the same amount of characters as our passcode)

I disagree here, IMHO, the iOS-style 6-digit thing on GNOME Mobile is worse (I usually have longer passcodes). Having to press the unlock button can even be seen as a security feature ;-)