> The FLX1s from Furi Labs runs a fully optimized Linux system called FuriOS, packing a lightning fast user interface, 3 hardware switches for microphone, camera and modem/gps, and a privacy centric approach like no other.

"Error establishing a database connection"

So it only works fine if you don't care what a FLX1s is.

People write their sites in slow languages "because it's I/O bound anyway" and put content which could easily be static in a DB.

Anyone competent can put a static site up on CF pages or even a lame VPS and serve huge amounts of traffic just fine. That’s not what they do.

"overpricing" is often higher cost of parts at lower quantity, future R&D and other costs that are much higher than for big corporation.

Underspeccing is specific to mobile industry. But I agree with you here. Going for premium specs is a better way to start. But they'll have to pick a specs that works for them the company and can reach maximum people. So I also acknowledge that it's tough.

Also still waiting for more userspace tools to support the v4l2-requests API for hardware video decoding.

Technically yes: there is iPhone 13 Mini and in Android world there is 2 or 3 Unihertz models and some "no-name" Chinese Aliexpress brands (Cubot has some small model, AFAIR, and there is several even more no-name offers).

Realistically no. All these Android models are underspecced. Old cores (8+ years old), small screen resolutions (small in PPI, not like small as screen proportion to big ones), small amount of RAM and storage (latest Uniherz is happy exception in this area, but not in the others), very bad cameras, very short OS update period (if ever).

iPhone 13 mini is Ok-ish (my wife uses one): camera is still very poor, but all other is usable.

Android is worse. If all you need are phone calls, and messaging with Telegram/Whatsapp/Signal it is Ok. But if you need good camera, good browsing experience (many open tabs) or something specific you are out of luck. Even Google Maps could be sluggish. Plus zero-days in old Android versions.

Good cameras is my pet peeve: good ones go only to flagship models and maybe sub-flagship ones (like, flagship and sub-flagship can be differentiated by addition of tele-module, which is most useful for me).

I mean I get what you're implying, I am just making sure I understand the meaning of "context" here. But if you have large fingers, smaller buttons obviously make the device harder to use, no two ways about it. However, in Android and iOS both, it's possible (for the user) to scale everything up, to help solve that very problem.

The bigger battery argument is a valid one too, but you have to keep in mind that most of the battery is consumed by the screen on average, and larger screen will eat more battery, so it's a bit like the rocket equation -- bigger rocket needs more fuel, more fuel needs more space and adds weight to the rocket, more rocket more fuel again and so on. In terms of batteries and rockets both, there's a golden middle there somewhere, I think. But it's a moving quantity since both screens and batteries are different -- OLED vs LED-lit LCD screen and LiPo vs LiOn for battery and so on. In short: I don't think a 5,5" phone (my preferred size) will suffer from shorter battery life, perhaps on the contrary (vs. a 6,5"). Especially considering that _large_ phones tend to be made _thinner_, since their ergonomics depends more on thickness (for the large width and height), perhaps becoming a problem with more than 8mm thickness, while a 5,5" phone can in fact be used comfortably even if it was 8-10mm thick, since it's smaller in the other two dimensions. That extra afforded thickness can directly translate to a battery that is as large or larger in terms of capacity as one for a 7mm "slick" 6,5" phone.

It's very similar to smart TVs. Yes, most people do prefer smart TVs, but vendors use it very successfully to sell inferior displays (poor color, poor contrast etc), to compensate and to pull more selling margin, since that's how the consumer functions (being utterly unable to quantify display quality for an uncalibrated TV). Anyway, I am digressing -- the point of my comparison is that it's complicated and not nearly as simple as "consumers want larger phones / TVs with slow menus and shitty picture as long as there's Netflix in there".

Add to the above that iPhone "mini" might have been slower or just "worse" and it wasn't just the screen that was reduced in size, so the word of mouth might have been that the phone is simply worse, and that contributed to poor sales.

There's no way of telling how a 5,5" phone would fare until there's consistent prolonged feature-parity based sales of such phones that are otherwise identical to other offerings by the same brand, across multiple brands (if I am a die-hard Fairphone customer, I am not buying an iPhone regardless of screen size) to help gather proper statistics.

I guess electronics has gotten denser, and density for the same volume is what quite literally translates to larger weight. The density thing is because they're able to cram more electronics, as our fabrication technology inches forward (i.e. Intel/TSMC/Nvidia/etc trying to break the 1nm barrier for transistors).

Remember the old Nokia phones, where the plastic shell likely amounted to as much volume that a modern phone instead dedicates to the entire front camera device? The latter will weigh much more than the plastic, for the same volume. Now apply that to _every_ component in the modern phone, and the difference is multiplicative -- there's just more features in every cubic millimeter of the phone today. No wonder it's getting heavier.

I completely agree with you, my app functionality should be built inside the OS because of better integration, privacy reasons, etc.

I just wanted to add that because of this permissions my app needs in order to work, I will never add the internet permission to Quick Cursor. I took this decission 5 years ago when I started the app because I understood the privacy risk, and my app will never have internet access permission.

In order for an app to have access to internet, it needs to have the android.permission.INTERNET added to its manifest, otherwise it won't work. This can be checked easily, there are some apps that shows you this info about your installed apps, or by manually looking at the AndroidManifest in the .APK of the app.

I guess I'm too much of an office worker to get that most people have their phones in their pocket, as soon as I sit down at my desk the phone gets placed on the desk.

I'm not a case user but even I agree

I always thought Samsung had a clever approach with a toggle to just render at the lower resolution if you wanted the lower rendering load. Then you still only need to develop 1 cutting edge screen with all of the latest improvements but it will please both use cases well as the cost overhead of shipping models 2 separate screens would.

I'm not sure if I'd call it "making a difference", but I've noticed pixelation at one point on my 5.2" 1080p phone (424 ppi). I'm absolutely not the average person, sure, but higher resolutions are markedly nicer for me. A 16" 4k laptop is significantly crispier than my 13.5" 1500ish p framework screen. Yet you will find people who say that 4k below a 28" monitor size makes no sense.

It's all about how sensitive your eyes are and how much you lean towards the screen like a poorly postured crustacean lol

That's a hell of a hot take. Could you elaborate on why you think so?

From what I have been able to tell, the folks behind Furilabs are also behind Droidian, which is Halium/libhybrys based. Furilabs/FuriOS is the commercial version of it.

That would be a showstopper for now, IMHO. Doing it with maintainable open source Linux drivers is the hard part of having a viable device, from everything I've seen.

Another concern are that I can't find who the developers are, nor even definitively what country they're based in. (I don't see it on their About Us page, ~~and the GitHub repo contributors are hidden.~~ I saw a reference to Sydney, but unclear.) (Edit: my mistake regarding GitHub contributors; they aren't hidden)

Also, it would be nice to have the option of a better hardware provenance than a generic whitebox(?) phone from some unidentified manufacturer in China. Even for individual hobbyist users, and certainly for corporate ones. (This is why I'd like hardware options combinations like Purism for the premium device, and a cheaper device that runs the same software but is still from a brand that at least has a reputation to preserve, like Pine64 or (ha) Google.)

this is why halium exists. OEMs don't produce drivers beyond whatever kernel they ship with, so this is an attempt to build a system that leverages the crap they do ship.

> why stop at the OS?

Because the OS is the only thing you control. The reason the Librem 5 costs so much for a decade-old platform is because they didn't grab a predesigned device from another OEM. Doing everything yourself is going to be the only way to produce a first-class linux phone.

Nit: The Pine64 PinePhone's cameras at least have been fully functional since 2021. It's a very shitty pair of cameras, but they're definitely fully functional.

I know the wiki.postmarketos.org page for it says the camera support is "Partial" and that a bunch of drivers are out-of-tree. This and much of the rest of the page is extremely outdated, and I (maintainer) just haven't had the time to go through that page and fix it up.

I wish usb cameras were sold in the same form-factor as phone thermal cameras. Then the missing drivers for the built-in cameras wouldn't matter as much.

Go lurk in their Matrix chat. They've noted in there that they didn't exactly have a ton of choice in stuff like this because you don't really get a ton of options as a small operation.

My Librem 5's camera is fully functioning just fine. Many entries in that table are either outdated or pmOS-specific, or marked as "partial" because they require some tiny manual intervention that's not a big deal in practice.

Should they not? It would be unfair "extra energy" if the comments were fair criticisms, but they're not in the spirit of hacker or entrepreneurial culture. The parent seems to be arguing that most of these comments are entirely ignoring who the product is for to leap to hardware comparisons pre-hoc. And I agree with that conclusion; there is nothing intellectually stimulating or helpful in a discussion about how a dev kit appeals to the broader consumer market.

A mobile OS fundamentally needs a different application model -- apps can't just decide to run whenever they like. How will desktop GIMP know that it shouldn't waste my battery when in the background (unless it very specially requests it throuhg an API made just for that)? Does suspending it work as you expect? For how long will you suspend it, shouldn't you kill it as well after a while? Who saves stuff?

I can't help but feel that anyone strongly advocating for a GNU Linux phone (because let's be honest, Android is the linux phone) is just not familiar with the actual context of what it entails.

I thought there was a robust android emulator for linux such that I could run android apps - and call an Uber or whatever - from desktop linux ...

Is that not so ?

It does.

I have an FLX1, a review sample.

https://www.theregister.com/2025/02/03/furiphone_flx1/

I had 3 app stores on mine: Amazon, F-Droid, and Aurora. Apps from all 3 worked.

Edit: If you notice that this does not match with another comment I've made saying I wouldn't buy this because of the size, I can only offer as a defence that I'm also trying to vote with my wallet about the size of phones so I'm torn.

I think it's probably better on balance to have a small phone that does everything that it should perfectly, and live with the compromise of living with the walled garden, while still being small to easily hold and encourage me to go and use a more appropriate device than something I've pulled from my pocket for any task that requires staring at a screen.

1: https://furilabs.com/faq/

Pixels have decent hardware and have an open-bootloader. I'm fairly sure your desktop is not better/worse than that either.

It's most definitely a shame that it doesn't support an external display via the dock (which kinda makes moot the fact it supports other peripherals), I've used two different docks (both requiring DisplayLink drivers) with my home Linux setup and every kernel update is a crapshoot as to whether the dock-connected displays will blink back into life post reboot, or stubbornly stay blank until I roll back to the previous kernel version and await the drivers to catch up.

As such, I kinda understand that it may be harder than expected to get working for a device like this.

Having recently setup a new GrapheneOS device, however, it means I'm less motived to change mobile platforms again. Desktop-via-dock support could have convinced me.

On another note, I've successfully connected to wireless displays (Miracast) on Linux using https://gitlab.gnome.org/GNOME/gnome-network-displays

It is one thing if AOSP has some fundamental issues that cannot be patched/fixed, and another thing if someone just doesn't like it.