FuriPhone FLX1s
By Sean E. Russell on on Permalink.
It’s about time I wrote up my thoughts about FuriLabs’ FLX1s. As someone who, myself, tends to skip to page 5 and read the summary before I go through the full review, I’ve been trying to think of a reasonably objective one-liner summary of this phone, and it’s been hard. Here are my top contenders:
- A Great Phone for Linux Enthusiasts
- Better Than Expected, but Worse Than Hoped For
- Good Hardware Hampered By Buggy Software
- Almost a Daily Driver
This review focuses on using the phone as a daily driver. If you’re looking for a second phone to play with, or for situations where dependability isn’t critical; and if you’re reasonably comfortable with Linux, then I’d pick that last bullet: it’s almost a daily driver. The specs are acceptable, and it mostly works. The company is very responsive to tickets, and seem well- intentioned. I have no concerns about dealing with, or buying from, Furilabs.
Hardware
While no flagship, the phone is reasonably spec’d. The screen is large enough that it’s on the “too large” side for my preference – I have large hands, and at 170mm it is large enough to make single-hand use difficult (being able to reach the whole screen while holding the phone one-handed). Most people like large screens, though. It’s reasonably slender at 8mm, and the battery is beefy – and while the OS is the cause of many issues, in this case Linux does an outstanding job of making the most of the battery; I’ve had the phone go for a full 36 hours between charges, and that’s with me using the phone; running passively “overnight on the nightstand”, you can lose as little as a couple of percent of charge… and that’s without turning off Bluetooth, WiFi, or cellular. Just not using the screen causes it to sip battery. It’s the most impressive aspect of the phone, to be honest. Anecdotally, once my previous phone, a Samsung, hit about 12% I could expect anywhere from zero minutes to an hour before the battery died. The phone could be at 8% and suddenly shut off. With the FLX1s, I can confidently let it run down to 4% and then leisurely look for a charger; as long as I don’t use the screen (or make or take a call), at 4% I have hours before the phone will shut off. Even at 10%, I’d take a short call and not worry about it shutting down. It’s seriously impressive. I’ve completely lost all Battery anxiety I developed from using Samsung phones for the past couple of years.
The FLX1s comes with a good amount of internal storage (128GB), but unlike many flagship phones it also accepts MMC cards, so storage is not an issue – or, you can throw in a second SIM instead and have a dual-SIM phone. It’s a genius design. At 8GB, memory is tight, but this is largely a result of OS choices.
A bit talking point for Furilabs is the hardware switches which allow you to physically disable the camera, microphone, and network chips. Combined with the ability to encrypt storage, and Linux’s wide array of security tools, these features put the FLX1s in the “secure” phone category – potentially secure. It’s up to the user to set up and use the phone securely, but the FLX1s gives you all the tools you need.
Here’s the phone benchmarking over WiFi to a server on the LAN:
FuriPhoneFLX1s » iperf3 -c sting.lan -i5 -t30
Connecting to host sting.lan, port 5201
[ 5] local 192.168.50.138 port 57882 connected to 192.168.50.113 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-5.00 sec 7.12 MBytes 11.9 Mbits/sec 1 1.51 MBytes
[ 5] 5.00-10.00 sec 4.75 MBytes 7.97 Mbits/sec 9 1.44 MBytes
[ 5] 10.00-15.00 sec 4.50 MBytes 7.55 Mbits/sec 0 1.93 MBytes
[ 5] 15.00-20.00 sec 3.88 MBytes 6.50 Mbits/sec 0 2.00 MBytes
[ 5] 20.00-25.00 sec 3.75 MBytes 6.29 Mbits/sec 1 1.99 MBytes
[ 5] 25.00-30.00 sec 1.75 MBytes 2.93 Mbits/sec 3 766 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-30.00 sec 25.8 MBytes 7.20 Mbits/sec 14 sender
[ 5] 0.00-32.05 sec 24.2 MBytes 6.35 Mbits/sec receiver
iperf Done.
Here’s the same test run from another Linux computer, over the same station:
nivrim » iperf3 -c sting.lan -i5 -t30
Connecting to host sting.lan, port 5201
[ 5] local 192.168.50.200 port 48578 connected to 192.168.50.113 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-5.01 sec 1.88 MBytes 3.14 Mbits/sec 2 38.2 KBytes
[ 5] 5.01-10.01 sec 1.62 MBytes 2.73 Mbits/sec 2 45.2 KBytes
[ 5] 10.01-15.00 sec 1.12 MBytes 1.89 Mbits/sec 6 46.7 KBytes
[ 5] 15.00-20.01 sec 768 KBytes 1.26 Mbits/sec 5 14.1 KBytes
[ 5] 20.01-25.01 sec 768 KBytes 1.26 Mbits/sec 7 26.9 KBytes
[ 5] 25.01-30.01 sec 1.00 MBytes 1.68 Mbits/sec 3 31.1 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-30.01 sec 7.12 MBytes 1.99 Mbits/sec 25 sender
[ 5] 0.00-30.05 sec 6.75 MBytes 1.88 Mbits/sec receiver
iperf Done.
Both the phone and the computer were about three feet apart, and although the computer is in the back of the desk and enclosed so the phone antenna had less obstruction, it’s still clearly doing well. The server was in another room.
The Software
So, I’m going to use adjectives (like “primitive”) which might seem hurtful or imply criticism of the developers’ skill. I intend no disrespect – much of this software is FOSS, young, and in active development. If you think my word choice is harsh, try to view it in as objective a manner as possible.
The phone has a few issues which prompt me to urge caution about depending on this phone as your daily driver. In summary:
- Bluetooth can not be used for calls.
- The speakerphone is unusable for calls, and suffers from echo. This might be a problem affecting only some percent of users, but it seems to be a known issue.
- The previous two points means that you can not legally use the phone while driving in most states in the USA. The FLX1s does come with a USB headset which works fine, but it’s not legal to drive with earbuds in most of the US.
-
I’ve figured this out; the details are below in the travel update, but
essentially it requires restarting the
bluetoothddaemon and fiddling withbluetoothctlin the command line – disconnecting and reconnecting the device. The good news is that, once done, it seems to be persisting, so it appears to need to be done only once per device.While I was able to pair the phone, I was unable to get either of our cars to recognize the FLX1s as an audio source over Bluetooth, so I’m not able to stream music from the phone in the car. - Bluetooth frequently has issues being accessed from Flatpak apps; it’s a common issue you can find reported in search engines.
- Bluetooth passthrough does not work with Waydroid, and since Andromeda (Furilabs’ solution for running Android apps on Linux) is derived from Waydroid, on Andromeda either. This may impose a strict limit on using your Bluetooth devices with the phone. For instance, the BangleJS watch will not sync with the phone; there is a native app for smart watches, but BangleJS support is limited and unreliable. If you have, for example, Bluetooth earbuds that have an Android app for controlling special features, or a smart Bluetooth doorknob which you use an app to configure, you will not be able to use these devices with the FLX1s because – while you may be able to install and run the apps – the apps will not be able to see the Bluetooth devices.
- There is no NFC chip, so you can’t use your phone for payment. This includes not being able to tap-to-charge at EV charging stations, or using your phone to access public transportation services which use NFC and an app.
- It’s important to recognize just how hard producing working, reliable cellular modem software is. The modem software is unreliable.
- DTMF stops working during a call. In those cases where you’re asked to do a survey after a support call, or in any case where you’re routed to a DTMF after speaking with someone, does not work. gnome-calls refuses to send tones. I suspect this happens after a screen lock, or when a sensor detects you’ve put the phone to your head; I believe it’s a bug in the code that prevents your face mashing DTMF, but I’m just guessing.
These are, for me, the big road blocks to using the phone as a daily driver. Not being able to take (or make) phone calls while driving is alone a show-stopper.
These are all (well, except for NFC) software issues, and undoubtedly the software will improve and updates will continue to chip away at this list. Unfortunately, the Gnome mobile suite on which FuriOS is based is full of issues like this, some more severe than others:
-
The Calendar app doesn’t support tasks, and the interface for configuring alarms and repeat schedules is primitive. You can not, for example, create an alarm for 2 hours in advance of an event; you can only choose one of the pre-defined, set alarm times.
-
There is an excellent third-party package called Phofono, based on Qt, which replaces gnome-calls, contacts, and messages, and does everything those do, better. However, it depends on the same modem software gnome-calls does, and so inherits many of the same issues gnome-calls, contacts, and messages are poorly integrated. There is no way, for example, to create a contact from a phone call you received.
-
The modem software is unreliable, at best. Various behaviors I’ve encountered are:
- On accepting an incoming call, the ring tone continues to play over the conversation, making the other person impossible to hear. (Fixed by Phofono)
- Inability to accept a call (unresponsive “accept” buttons)
- Inability to get to a dialog where a phone call can be accepted – I often have incoming phone calls where the phone is ringing, but there is no notification or app I can run that will give me the option to answer the call. All I can do is wait for it to go to voice mail, then go to the call history and try to call the person back. This is serious issue when the call is from a call-back from a company which you spent 20 minutes in a call center menu system before being sent to a call-back option, only to receive a call which you can not answer.
- The modem crashes when accepting a call.
- When a call is in progress, and another call comes in, rejecting the call hangs up both calls (this happens every time). If you do not want to accept the call, the only option is to let it ring until the incoming call goes to voicemail. (Fixed by Phofono)
- You can’t make telephone calls from the contacts app. (Fixed by Phofono)
- If the modem gets into a confused state, sometimes the only fix is a hard reboot.
These issues are not rare; I encounter them all at least weekly, and sometimes daily if I’m making a lot of calls.
Phofono does fix many issues, and has far better integration between the components; It isn’t really lost; it’s all in sqlite3 DBs, but you can’t access history through the GUI. however, there is currently no message migration, so switching “loses” message history – therefore, it’s best to install Phofono early.
-
The phone will ask you for your pin twice, every time you reboot or when Phosh crashes. The fix for this is to disable the pin on your secret service, which isn’t a great solution. If you choose to keep the double-pin entry, sometimes the keyboard disappears before you can enter the second pin, rendering the phone UI unsable; the only solution here is to reboot.
-
The community, however, has provided a solution in a tool called NightManager which you can download, install, and configure There is no phone state scheduler like Android and iOS’s do-not-disturb scheduling, or screen dimming based on time.
-
Phosh, and/or Wayland, can easily be crashed by apps. The Morph browser, for instance, regularly (but inconsistently) crashes Phosh.
GPU Screen Recorderwill crash Phosh (or Wayland) just by running it. For being a “more secure” display manager, it’s alarmingly easy to crash Wayland and Wayland compositors – I can’t remember the last time any application crashed X11 or any X window manager. -
Andromeda is a well-written piece of software, and I commend Furilabs for putting it together. It has a few bugs, most of which are not severe. About 30% of the time, it’ll get stuck thinking that it can use only 60% of the screen, and every Android app opened will have these constraints. However, when this happens, it happens on the first app opened, is easily recognized, and is fixed by simply restarting the Android container.
-
Andromeda provides a handy way to share data between the nominally isolated Android space and the main FuriOS filesystem. However, this setting does not persist between restarts, and it can be surprising when data you’ve saved under Android is not available to FuriOS, and can’t be shared without moving files around, re-enabling sharing, and moving files again.
-
Normally, I would not raise this issue, except that the system configuration app has a “Printers” section which leads you to believe all you need to do is enable it and you can print. But you can’t, because not only is it misleading, but it also gives you no indication of why it doesn’t work. CUPS is not installed or configured by default, and while installing and configuring the
furiosuser to be able to print is not hard, it does require the shell and commands that non-Linux users won’t be familiar with. -
The basic core dump debugging software that might be useful generating information in bug reports is not installed, and – again – installing and configuring it on FuriOS to produce useful output requires finding and following information spread across multiple web sites, and is a non-trivial exercise for inexperienced Linux users.
-
The touch screen is flakey; it’s a known software issue with a fix coming down the pipe, and honesty it’s easy to get used to in most cases. It isn’t too bad, but it’ll be nice when it’s addressed. My own device will sometimes not register taps, but has the most trouble with screen edges; some people report having to tap almost every widget multiple times to get a reaction.
-
Often, the Terminal app will abrubtly exit when Backspace is held down.
-
The best thing is to install the far, far better Pure Maps app, and uninstall the default Maps. The default Maps app has no useful search function for local businesses.
-
App activation is almost non-existant. Very few notifications will open the responsible app when tapped; even using the Phosh “More information” or “Uninstall” function doesn’t actually open the Software app – you have to do that manually. Sometimes, once you open the app it’ll be in the right place, but this is variable.
-
I recommend downloading the keyboard Squeekboard and replacing the default keyboard. It’s not more configurable, but it does work better and provides a path for compiling your own layouts. And the repeat speed isn’t glacial. The default keyboard repeat is slow, and not configurable. Keyboard configurability in general is spartan, there’s no auto-correct (the Squeekboardefault keyboard has suggestions; you lose that with Squeekboard), and anything as convenient as Swipe is simply not an option.
-
Text selection and copy/paste are inconsistent and often almost impossible to use. It works far better in Qt apps, but most of FuriOS is based on GTK software, and selection and copy/paste is just broken in mobile GTK. Often, to copy or paste, there’s no hold-pop-up menu; the best you can do, if you can select text at all, is switch keyboards to the terminal keyboard and use CTRL-C and CTRL-V, and then switch back out to the normal keyboard because the buttons are tiny and the punctuation is oddly placed in the terminal keyboard. A good example is that text selection and copy/paste in Firefox is nearly impossible to use, but works reasonably well in Morph browser (which is Qt).
-
This seems a minor thing to bring up, but in the terminal keyboard, meta keys are sticky. That means that if you press CTRL and then C, CTRL stays selected. And this means that if you press backspace, you’re going to delete words, not characters. Or if you type an “x” you may close a window. It’s entirely counter to every other mobile experience, and it still bites me occasionally, even though I’m aware of the behavior. You can’t disable this, either. It seems petty to bring up, but the first time you spend 15 minutes composing an email and then accidentally close the window because CTRL is sticky, you’ll understand why I’m including it.
-
Speaking of Flatpaks vs Android, there are rare apps which are available both as native Flatpak, or as Android apps. You’d think the Flatpak would be lighter and more resource-friendly… but you’d be wrong. Every time I’ve encountered this, the Android app is smaller and consumes fewer resources than the Flatpak version.
-
The phone itself locks up frequently, or becomes so laggy as to be unusable. One contributor is the batman, the power manager, which occasionally will decide to power restrict the UI to the point of unusability, even when the battery is over 50%. When this happens, if you are patient and able to navigate to Settings and to the power management panel, you can turn off batman and sometimes this will restore functionality. I also periodically have full-on lock-ups, where the only thing I can do is hold down the power button until it shuts down. Since the phone is often accessible over ssh when this happens, I assume that it’s another Wayland bug. If you’re fortunate enough to have an ssh connection when the phone locks up, sometimes you can avoid a hard reboot by simply killing Phosh and restarting your session. Sure, you’ll probably lose data (e.g. unsaved files) and state (e.g. clock timers), but it’s better than losing minutes while waiting for the phone to reboot.
-
Much of the gnome software is unpolished. A great example of this is the Clock app, which is almost as simple an application as a calculator. If you have a (countdown) timer running when one of the frequent session or system crashes happens, the timer state is lost and you’re left guessing how much time was left on the timer. This is systemic across the Gnome app suite; Text Editor is an exception, having good autosave and recovery functionality.
-
The MMC is frequently unmounted and remounted – or, the system is just sending cryptic alerts to this effect. I gather that this is not a common problem, but it is something you might suffer from.
-
Many Android apps will refuse to work because of gaps in the Andromeda API. For instance, many apps require an internet connection – the Delta (airline) app, for example. While some apps will continue to function despite warning that they can’t work without internet, some will refuse to work if they don’t get a positive response from whatever system API they’re querying to test for an internet connection. This will limit your ability to use a fair number of Android apps on the phone. As I mentioned, the Delta is one, which means if you’re a Delta flyer, you’ll be back to printing out your boarding passes.
-
More rarely, the keyboard will refuse to show. When this happens, the little bar at the bottom of the screen responds merely by giving a little horizontal shake. Sometimes, it’ll start working again after a few minutes, but sometimes it’ll stay broken; in this case, the only option is to shut down and restart the phone with the power button.
-
Phofono lets you take pictures directly from the messaging app, except that the camera app has several issues with screen rotation. I mean this generally: the phone app (
furios-camera) frequently gets confused by rotation and starts in landscape when you are holding the camera in portrait, or vice versa, or won’t rotate at all; all of these are resolved by killing and restarting the camera app (usually), but from Phofono, the camera app will not rotate, so you can’t take landscape pictures. Chatty, the default messaging app that Phofono replaces, does not have this issue… because it doesn’t have an “attach a picture from the camera” function at all. -
The default image viewer and rudimentary editing app (
loupe?) writes broken jpgs. As in, the images it writes often contain malformed headers that other tools (such as GraphicsMagick) will complain about, but most hilariously, prevent other Phosh software such as Portfolio from reading correctly. E.g., if you edit an image with loupe, Phosh can’t (or won’t) create a thumbnail for it.
This is a not-insubstantial list, and it is not comprehensive. If you lurk in the public furilabs forum/chat, you’ll frequently see people reporting issues which you aren’t experiencing.
Memory
I said 8GB of memory was “tight”, and this is because of software decisions. The default web browser is Firefox, which was has a wonderfully done port; however, it’s Firefox, so it will easily eat most of 8GB of RAM. I heard repeatedly that it wasn’t really that bad, but always with the caveat that, well, yes, if you try to run Android apps and a web browser at the same time, you’ll have memory contention. In my experience, Android wasn’t necessary, but if you want a really fun time, do try running both and place bets with yourself how many times per minute the Linux OOM killer will kill a random process, and which one (hint: it’s usually Firefox). Morph browser is far lighter on memory, but Morph has the unfortunate habit of killing Phosh and resetting the session. If you don’t run Firefox, 8GB seems to work fine for most things, including running Android apps. You just can’t browse the web at the same time.
Unfortunately, many mobile-friendly apps are also Electron apps, and if you want to kill a computer with limited resources, running a couple of Electron apps on it is a sure way to do it. Memory use by bloated apps is somehow worse than on Android, and Flatpak hides dependencies. The easiest way to tell that a Flatpak application is an Electron app is because it’ll be something like a calculator that is a 250MB download.
Which brings me to the second issue: FuriOS depends heavily on Flatpak, and Flatpak is unreasonably heavy for a phone with limited resources. A solution is to look for the same app in apt and install it from there preferentially, but many apps are only available for Furios from the hub, and this is where “being comfortable with Linux” comes into play. If you want to get the most from the phone, you’ll be spending a lot of time in the shell.
The cellular modem
I can’t stress that the modem issues are a result of how much of a mess cellular chips are. It’s almost all bespoke software specific to proprietary chips, which have to work on a globally diverse network of carriers which each introduce their own difficulties. Cellular modems are proprietary, obfuscated, and highly patent encumbered. The fact that Furilabs has been able to produce a phone which works at least to some degree almost everywhere in the world is a feat of engineering. However many accolades they deserve, for the end user the situation is the same: an FLX1s is a fine phone to have, but it requires patience and should not be relied on for critical communications.
Some of the issues I’ve experienced or heard reported:
- The modem never connects in 5G mode. I’m on a T-Mobile MVNO in a dense urban area, and I’ve never seen my phone get a 5G connection. However, I’ve met someone who is also on a T-Mobile MVNO but who lives in a different, more rural, part of the country and they regularly see a 5G connection. Experience varies widely, but as yet there’s no work-around and I’ve seen no reports that the problem is understood by Furilabs or that progress is being made.
- Some people report outages where the phone looks and acts connected, but SMS messages stop being delivered until a reset.
- Several issues I’ve already mentioned I believe are linked to the modem software, rather than bugs in the higher-level UI: the inability to accept calls; the modem crashing while in a call, or when accepting a call; the modem generally freaking out and borking the phone if a second call comes in during an in-progress call.
Software
Many of the apps from the app store, called simply “Software” in FuriOS, either won’t install, or don’t run after installing, or are not suitable for the mobile form factor. The last point would be a non-issue, except that Software does not provide a way to filter for only adaptive apps, which means you’ll spend a lot of time opening, scrolling, checking the adaptive capabilities (located inconveniently near the bottom of the app listing), and then backing out to check the next app. This process is often interrupted by Software reloading application metadata, which takes long enough that I have to assume it’s re- syncing from the Flathub. It’s not a great experience. Unfortunately, Flathub is the only option for most GUI applications; the upstream apt repository can be most cheritably described as “spartan”.
An update on the keyboard (2026-03-31)
I’m back to the default keyboard, at least for the moment, which – while more
cramped and awkward than Squeekboard – does have pop-up secondary key
functions, like accents and special characters; perhaps Squeekboard can be
configured to do this, but if so, I have seen no indication on any keyboard that
it can. The default keyboard is still highly annoying (the terminal layout, for
some reason, crams “.” and “a” together in the space of a normal “a” key, which
means I’m always accidentally typing “.” but find it difficult to type a period
when I actually want to). The default keyboard also has extremely rudimentary
spelling suggestions (but no autocorrect), which is still slightly better than
the absolutely no suggestions provided by Squeekboard. Squeekboard, OTOH,
provides arrow keys, which are entirely missing from any keyboard in phosh-osk-
stevia (the pre-installed, “default” keyboard). You have to brush up on your
readline command keys to edit commands, because it’s the only way to make
cursor movements.
For all of the bizarre design decisions and annoying omissions, the simple fact
that I don’t have to switch keyboards just to get to punctuation has pushed me
back from Squeekboard to phosh-osk.
A story about dependability (2026-03-31)
As has been the theme, this is a story about software, not the phone hardware. I recently went on a short trip, and noticed a few more things specific to travel, but which are also generally representative of the experience.
Bluetooth issues
By now I’ve figured out my BT headphone volume issues: the phone volume controls only contribute to the volume. In particular, I have to manually increase the volume to the headphone maximum using the headphone touch-controls, and from there I can control the volume from the phone to that maximum down to silent. If the headphones are not set to max, I can not raise the volume (via the phone) beyond that. In contrast, on Android volume control is absolute – the volume range is fully accessible either through the phone or the headphones. This issue is present for any Bluetooth device connected to the phone; when connected to the rental car, I was able to play audio, but I had to adjust both the car volume control and the phone volume control to get audible sound.
Frequently, BT audio just freaks out, playing jerkily and skipping. When this
happens, it can be corrected by opening a terminal and running Bluetoothctl,
and basically restarting the bluetoothd service and reconnecting the device. It
is specifically not correctable through the GUI; toggling Bluetooth on and off
through settings does not fix this issue.
A minor issue is that Bluetooth connections are basic and limited to audio and play/pause controls. You don’t get any audio metadata information on your infotainment system in your car.
Incidentally, after this trip I was able to connect my phone to my car at home
and play audio, with the same caveats as above. Perhaps I could have before
if I’d done the bluetoothctl dance.
Maps
Hoo boy. So, on my trip back to the airport, I discovered that Pure Maps doesn’t handle screen rotation. I suspect Flatpak, but it could be Yet Another Wayland Bug; in any case, when the phone was rotated, Pure Maps loses half the screen. Needless to say, this was extremely inconvenient when attempting to use the phone to navigate in a car, against a flight boarding deadline.
The first rotation-related issue is that, in navigation, Pure Maps will not
exit. So to restart it, I had to open a terminal and type in the laborious ps
awwux | grep Pure | awk '{print $1}' | xargs kill -9 command to kill it, and
then restart the app. Thankfully, Pure Maps remembers the previous navigation,
so it was fine until the notoriously touchy rotation software would rotate the
screen if the phone was at all handled, which would then screw up Pure Maps and
require the whole kill/restart process. After losing 20 minutes trying to get
navigation to be usable, I finally turned off rotation and things worked through
the rest of the trip.
In that 20 minute struggle, I did try gnome-maps, the app that comes with the
FLX1s. Atypically, it actually located the airport and created a route; however,
its navigation mode doesn’t follow the phone. I watched helplessly as I’d
drive along the route and off the edge of the map. Since I couldn’t be
constantly dragging the screen around to find myself, I eventually gave that up
and went back to Pure Maps. If there’s a setting to “follow the phone”, it’s
certainly well hidden, and why it’s not the default mode is beyond me. gnome-
maps did, however, handle screen rotations… but then, it’s installed as a
native app and not through Flatpak.
I’d built extra time into my travel specifically because of angst about depending on the FLX1s, and I needed it; however, in the end, I got to my flight.
My car has a built-in nav system which I prefer over any other option (Maps through Android Auto, for example), so I only noticed the limitations in the rental car.
OpenStreetMaps has good navigation and voice directions, but Linux OSM is designed for the desktop and is almost unusable on a phone; and both OSMAnd and native OSM consume vast amounts of memory – you risk having the OOM killer kill your entire session while you’re trying to navigate, even if the only app you’re running is OSM.
Top of my list of things to try to fix is now fnding a .deb for Pure Maps,
because it’s just so much better than gnome-maps, and I’m convinced most of
the issues I have with it is because it’s packaged as Flatpak – often the
source of most software issues.
Traveling summary
I did bring along my Android phone, based on my experience to date with the FLX1s, but I did not need to use it (I came very close during the navigation fiasco).
- Because the Delta app doesn’t work under Andromeda, I had to revert to printing boarding passes (yay, environmental waste!), which required sending PDFs to the hotel desk, having them print them, and going down to pick them up. Other minor annoyances included having to re-acquaint myself with the gate kiosks, because gates are not printed on boarding passes, nor do dead-tree boarding passes update when the gates change. This aspect requires time, effort, and – most importantly – more paper waste, but it isn’t a show- stopper. I think what’s most frustrating is that, of all the bespoke company Android apps one deals with, the Delta app is actually pretty good, and useful, telling you where the closest Delta lounge is and providing generally useful update notifications.
- I no longer have any concerns about relying on Pure Maps for navigation. If I can resolve the rotation issue, even better – but just knowing to turn off rotation before running Pure Maps addresses the layout issue. Pure Maps routing is pretty good, and even supports multi-stop routes. It’s an impressive bit of coding.
- Since Phosh obviously doesn’t have Android Auto or whatever Apple uses, you’re back to looking at your phone for directions; and neither maps app has voice navigation. This is a real safety issue that you need to consider: in many states it’s illegal to use your phone this way, even for navigation – the expectation is that nav will be on the car screen, or have voice instruction, and neither Gnome Maps nor Pure Maps have this.
- As many other users reported, getting the phone to connect correctly to a new location can require cycling the cellular connection. Toggling Airplane mode does not do the same thing. However, I had to do this on Android more than once, too, so this isn’t a failing of the FLX1s. Getting a GPS fix, OTOH, was much more challenging, and I didn’t find a reliable way to address this. It would eventually sync up, but there were a couple of times when I’d try to use navigation and the phone would either not report a location to the app (usually resulting in a “failure to route” error), or simply show me located in my state of origin. This was never a crisis for me, as outbound I had no deadline and could wait for the GPS fix, and on the return trip (when I was time-constrained) the phone had had me located correctly for a couple days.
My biggest concern for Furilabs is that they have to resolve using issues around using the phone in cars. The fact that calls can’t be made over bluetooth makes hands-free – a legal requirement in, well, most states and I would assume many countries – not possible, and so makes it illegal to use the phone in any capacity while driving. I have no doubt Furilabs is eager to get a fix for the Bluetooth calls issue, but I’d also focus on getting a working voice navigation.
Otherwise, traveling with the phone, and depending on it, was no worse than using it day-to-day. The same issues are present, but as for network connectivity and navigation, it worked well.
Another rant about Flatpak
I’ll make this brief, but: Flatpak makes using the command line to work with
Flatpak apps absolutely hideous. Want to find the PID of the process running a
Flatpak app? Good luck scrolling back through five screens of bwrap.real
gibberish, and god forbid there are multiple Flatpak processes in your results.
I wanted to include a screen shot here, but I’d have had to use a screen
recorder to record a video of the amount of scrolling.
There is a flatpak command which can be used to install, uninstall, and list
installed Flatpaks, and I love nothing more than a system which requires you to
use bespoke tools with an entire vocabulary to learn alongside the normal,
ubiquitous, well-established POSIX toolset you use for everything else. It’s
such a great design decision, especially when that tool can only be used for
half the operations you’d want to do, and so you still need to use the
standard toolset, only Flatpak makes doing this harder than it needs to be.
The good stuff
It’s not all doom and gloom. As I said, most of the issues seem to be software issues, and fixing software issues doesn’t require buying a new phone. They’ll get fixed, over time.
The flx1s is a real Linux phone. It doesn’t suffer from so much of what Android inflicts: you can easily have multiple, multi-subnet VPNs running concurrently. mosh works beautifully, almost always reconnecting even after I’ve been out shopping. Many of the best apps of FOSS are available: Syncthing, helix, tmux, KeepassXC, restic – they’re all there.
I’m also thrilled because – while it isn’t trivial to cross-compile for arm64 – I’m able to write GUI programs in Go using Gioui, and they run beautifully on the FLX1s. They’re relatively light, and blindingly fast.
However, if you’re a Linux enthusiast, the most thrilling moment is when you
discover that SMS messages aren’t buried somewhere inaccessible in the phone
unless you’ve rooted it – both Gnome Messages and Phofono store messages in
sqlite3 databases in ${HOME}. It’s wonderful, and thrilling. And while I still
haven’t broken the habit of reaching for the phone, often when I’m sitting at my
desk I can just switch to my terminal where I’m mosh’d into my phone and do
whatever I was going to do there.
Support
Furilabs responds to tickets quickly and sends out replacements as fast as overseas shipping can get them overy. While I didn’t have any hardware issues, chatter in the support group indicated a readiness to swap out faulty hardware.
Fulilabs is a small team, and they split their time between product support, improving their online presence by e.g. redesigning their web site, managing their product roadmap (as I write this, they’ve been rolling out the convergence dock and it’s been consuming much of their collective time), and all of the other activities necessary to run a business. Even so, you can often find members in their published online social media, and they do respond to hardware, order, and shipping issues.
Other reviews
User luigi311 not only provides some useful software, but they have written an extensive and quantified review of the flx1 which is an informative read; much of what they say about the flx1 overlaps with the flx1s, but there are significant differences so you need to take some of the superlatives with a grain of salt w.r.t. the flx1s. For example, they say
The camera quality is really good and the processing is instant as it’s using the mediatek isp. The camera application also opens up quickly.
In my experience, and from following the chat room, the FLX1s camera is categorically worse than the FLX1. I frequently see difficulty focusing, and the camera app does not always handle orientation correctly, often getting “stuck” in the wrong orientation and not adapting as the phone is physically rotated. The app itself opens slowly; it’s serviceable, but it’s a good example of the differences between the FLX1 and the FLX1s.
Summary
FuriOS might benefit from fewer bugs if it were using KDE Plasma; I have doubts that it would be more memory efficient – KDE is a fairly nasty memory hog – but the best replacement apps in the FLX1s all seem to be Qt: Phofono and Morph being prime examples.
I would not recommend the FLX1s if it is important to have reliable phone calls and I have not had any issues receiving or sending SMS, but I’ve seen reports from other people – it’s apparently highly dependent on the network carrier. messaging. That is, in fact, my biggest concern – missing important calls, dropped calls, an unusable speakerphone, and general unreliability in being reachable.
While the software running on the phone is mostly FOSS, the phone does cost real money, and there are enough issues that reporting them in tickets approaches a full-time QA job. There are enough limitations and bugs that it can not be labeled a dependable phone.
Most of my recommendations are in the main body, but if you do go this route, I suggest looking at the quality-of-life third-party add-ons:
- Installing Phofono early to preserve message history
- When the keyboard drives you nuts, try Squeekboard
- NightManager adds the missing DnD scheduling
- flx1s-bat-mon provides a more detailed report about memory and battery use
It’s also not hard to hack together scripts which change various settings; this is Linux, not Android, and you have full control over the phone.
Furilabs is doing an amazing job bringing Linux to the mobile space, and I think they’ve done a respectable job with the FLX1s. The hardware is there, or close enough; the software is unreliable, unpolished, and not ready. Maybe a switch to Plasma would help, and almost certainly getting rid of Flatpak would ease stress on hardware resources.
All in all, I think the headline that best describes the flx1s is “Good Hardware Hampered By Buggy Software”. Phosh, and the Gnome mobile suite, is simply too far away from ready for this phone to be a daily driver for anyone but the most disconnected Linux enthusiast – someone who either has a second phone upon which they can depend, or for whom a smart phone is only a convenience and not a requirement for their job or life. It’s so close to being usable that it’s almost painful – especially if you want to get away from walled gardens and surveillance platforms. The FLX1s will certainly do the latter, if you can put up with the sporadic functionality and frequent reboots.
Armchair general
It’s easy to complain and criticize. As I’ve said, I avoid complaining about FOSS, but the FLX1s is a real product costing real money, and I think pointing out the limitations is fair. I recognize the huge effort needed to bring a phone to market; I’m familiar with the cellular network domain and aware of the extraordinary demands working with mobile hardware impose.
If I were Furilabs, I would approach a few things differently:
- Get rid of Flatpaks. I understand what they’re supposed to do, but Flatpaks are a crutch to address fundamental architecture issues in a Linux distribution; a distribution with a non-broken dependency management system would not need them, and they introduce an entire extra failure layer as well as bloat.
- Furilabs has limited resources, much of which appears to be going toward fulfillment and addressing tickets. I think these are the right priorities. Where possible, I would focus software resources on working with the mobile Gnome (Phosh) developers to address – with urgency – the issues around Bluetooth and Android API coverage. Bluetooth is critical for both accessibility (many accessibility issues depend on robust Bluetooth solutions) and also frequently affects the safety-oriented legal use of the phone (i.e., car use).
- I would be putting secondary priority into an NFC solution – either add-on, or returning it to the next generation of phones (it was, ironically, available in the original FLX1, and was dropped from the successor FLX1s). NFC is increasingly and widely used as a payment option, but is also used in authentication and authorization. NFC is heavily leveraged by the EV (electric vehicle) charging network in the states, and as the world converts from fossil fuels to EV cars, motorcycles, and bicycles, not having functioning NFC in a phone will increasingly become a deciding factor in the purchase decision.
- Finally, I would at least experiment with a KDE-based image for the phone. Personally, I’m a terminal/TUI person. When I do use GUIs, I seek GTK solutions over Qt, because there are more GTK programs that don’t require Gnome services than there are Qt programs that work well without KDE. However, as an integrated desktop environment, KDE is more well-designed and generally better working than Gnome. From what I’ve been reading, mobile Plasma has surpassed mobile Gnome in several ways, and you can see it in the apps themselves – many mobile Qt-based apps work better than their GTK counterparts. I can’t say whether mobile Plasma would address all of the software issues the FLX1s is plagued with, but if I were Furilabs, I would absolutely dedicate some time into finding out – and then posting a blog about it.