This sounds so interesting and fun. I’d love to do something like this but I lack the experience in construction to actually pull it off. Also, I like to host, and I feel that this kind of lifestyle is incompatible with the average person, who probably wouldn’t want to visit for more than an hour.
Maybe just me, but I have a feeling that we are currently stuck at 100-200k effective context window due to a parameter limitation, specifically the hidden dimension of the model, which would be an incredibly expensive dimension to increase vs adding optimizations elsewhere. I don’t think we are done scaling parameters yet.
Praying that fairphone somehow makes a foldable one day. My next phone will probably be a fold 8 because I really want a nice reading experience on the go, but I love the philosophy and love my framework laptop.
Considering the big players with R&D budgets valued in the billions have been struggling to make foldable phones, I can't imagine a niche player making one.
Personally I think we will just become more ambitious with our abstractions since the LLMs can generate more complex stuff at the lower level. To take the article's examples, LLMs will write kernels that fuse 3+ layers of a model, so the abstractions can enable more complex forms of kernel fusion.
I really want to love mobile Linux, and have given it multiple shots before. But I just don't see how it will catch up with iOS/Android in the same way it caught up with Windows/Mac:
- OEMs have poured an enormous amount of resources into the camera software, Linux cameras are years behind from what I understand.
- Android/iOS have thoroughly optimized the UX in all sorts of subtle ways, the big one being their keyboards. I literally can't type a single correct sentence on any of the mobile linux keyboards that I've tried because there's so much proprietary magic needed under the hood to figure out what the user is trying to say (autocorrect mostly, but I recall something about how apple also virtually adjusted the sizes of the keys to make it easier to type)
- GPS, banking, and now keys for your house and car all need to work.
Over the past few years I've felt the iPhone keyboard has degraded in quality so much. At first I thought I was just getting old, but I've seen so many people with a similar sentiment that I think it is actually the devices fault.
I have autocorrect and predictive text on on the iPad and off on the iPhone and it is fascinating how much better it is on the iPad. One of the things that particularly killed me was the iPhone correcting three or four words away from the cursor. There's an option for it to highlight when it does that (which it really shouldn't) but something about iPhone apps the highlights never work. iPad apps they actually work. (Maybe because every phone app thinks it needs to implement their own half-baked text boxes but iPad apps have fewer "designers" doing stupid things like that? I don't know, it's weird.) Still frustrating that there isn't a way to turn off "don't touch anything too far behind the current cursor), but being able to actually spot them when they do change is a big deal.
also the retrograde auto corrections drive me nuts ... like i type a word (correct) then next word and it adjusts the previous word. attempted several times to deactivate that "feature" - didn't figure out how.
Yup somehow I typo so many things or it auto corrects things I dont want it to allll the time I hate typing on my iPhone it sucks. I've personally been keeping an eye on e-ink phones. I'd really like to move off of having the ability to use websites and apps except for basic stuff like texting.
Agreed. I got an iPhone from work and I can barely type on that thing while my Pixel with Gboard just works and gets it right 95 % of the time even if I type gibberish.
I don't expect linux phones to catch up to ios for the mainstream, but I can see them working for me. I usually carry an actual camera with me so I don't care much about my phone one other than random utility shots / photos of receipts. And very much don't like the trend of forced app usage so having a device that physically won't run these apps helps me avoid companies that don't have a functional website.
> I don't expect linux phones to catch up to ios for the mainstream, but I can see them working for me.
That's the thing that allows them to catch up for the mainstream. Some nerds can use it and tolerate the rough edges, so they do. But the rough edges are still rough, so as more people use it, the small percentage of people willing to actually do something about it becomes a larger absolute number of people, and then more of them get shaved off. Which causes more people to use it.
The point when the devices are usable comes long before the point that they're what the majority of mainstream consumers are buying. Desktop Linux has been there for more than a decade and year after year its market share slowly goes up.
There isn't going to be a single year when its market share goes directly from 3% to 97%. There is going to be a year that its market share gets into the double digits and then continues slowly going up.
Linux cameras can be made to work well, it's a matter of software. Case in point, newer Ricoh/Pentax cameras actually run an a Linux firmware. (See: GR IV and K-3 Mark II/III). Parts of the software stack are already there, but noones had the will to glue it together correctly for a mobile device usecase, yet.
It's not about will. You need quite some HW for proper calibration, or cut corners a bit. Calibration is otherwise a few step process with some steps having substeps for each light source type.
That's true, but you can cut corners and still end up like 90% there. The software pipelines that can even consume detailed calibration are a pretty recent development anyway. The "cameras on Linux phones are bad" meme is induced purely by the fact that until recently there were like two or three people who have ever sat down to seriously work on this topic across the entire community. Fortunately, it's changing (although the biggest driving factor appears to be the fact that some laptops need a similar treatment now).
Well, rkisp1 driver that drives ISP on RK3399 on Pinephone Pro is available upstream in fully supported manner for like 4 years. It also has full docs in publicly available Rockchip datasheets and partial docs in calibration manuals.
What have people done with it? Some mediocre support in libcamera? :) I don't think lack of handholding is an issue here.
Pinephone is a low volume product. What you need is to get the firmware for some common device that has shipped millions of units so that the number of people with the incentive to make it work is high enough to actually build a community.
There are many such devices already. What is limited is number of people interested in FOSS/independent camera stack development AND usage/users, not lack of devices. Pine64 built and shipped about 60k phones to audience that could be the most interested/receptive - and it made about 5 people interested in doing indepth real work, that I know about.
Also RK3399 is not just pinephone pro, it's way more prominent in other things - notebooks, SBCs, ... whatever. Same ISP is in i.MX SoC, which covers another whole range of devices.
Not sure what 100's of millions shipped units to disinterrested audience achieved?
I don't know what the deal is with Linux and cameras. I've got Fedora installed on this old Retina MBP and apparently Linux somehow stopped supporting the built in webcam. I've never heard of a device losing Linux support but here we are.
Once the code is in the mainline kernel tree, things tend to stay supported indefinitely.
Some devices "work" without having real support by having some binary blob or third party code which is written against a specific kernel version. The code has to be updated when the kernel changes, which is why it's supposed to be in the kernel tree, but because it isn't the kernel developers don't know anything about it and aren't maintaining it. So then instead of working indefinitely it works until whenever third party stops updating it for current versions of the kernel. Which is why all the drivers should be in the kernel tree.
Of course, Apple isn't really that interested in supporting Linux since it's a direct competitor to macOS rather than a way to reduce their dependency on Microsoft/Google, so their hardware is more likely than most to be stuck using some reverse engineered alpha driver or proprietary blob extricated from the macOS one.
Once code is in mainline, it's in mainline. It doesn't mean things will work, lol. It means things will rather regularly break, because many people modify shared code you depend on without ability to test on your particular HW.
Not saying pushing mainline is bad. But assumption there's any kind of "support" is wrong. Code is there. That's all. You have to support it if you want it to work.
(This is very particular to HW/drivers support, Linux core is supported well, I guess.)
I don't think the differential with software is as big as it seems. If Google completely shuts down side loading or otherwise kills AOSP as an open project, you'll get a flood of millions of people into Linux devices (my rough estimate is that it's in the low millions of people using custom Android ROMs), and that's more than enough people to start building out the software ecosystem, especially with gen AI to help speed things up.
keyboard text prediction is no more complex than some of free/open AIs that we already see in the wild.
If google doesn't shut things down, then just continue to use AOSP, which is a fine open source OS for most people's use cases.
I installed PostmarketOS with Plasma-Mobile on my ancient Pixel 3a a month ago as something to play with and I was actually astonished at how polished it seemed. The keyboard was perfectly usable, apps were quick to load, I could do silly things like open full-fat Blender or OrcaSlicer on a tiny phone screen if I desired. Sadly old Pixels don't support video out over USB-C for whatever reason so I can't do what I really wanted to do and dock my phone into a USB dock for a desktop experience, but it's good enough to have me considering buying a more modern supported phone so I can try out daily-driving the experience.
Ive been really annoyed at my iphone keyboard recently because it seems like a slow drift of whatever optimized state it was in was getting slower and slower. It seems to freeze partway thru typing something frequently now.
Are you all seriously arguing/considering that the barrier is something like "innovation" or "UX" or "hard work at improving the OS?"
Like seriously?
Come on. By now we should know what actually happens. The entrenched carriers will fight tooth and nail to prevent this. That's the real threat. It will look like the above, but like e.g. Google lying about why it got rid of Google Reader, the real story will be "monopolies gonna monopolize."
some small company licensed the blackberry brand and sold really good devices with physical keyboard. They had support up until 2 or 3 years ago. Gone now.
If the Clicks Communicator had an adequate camera (definition may vary by person, I take a lot of photos) and ran Linux it would be an absolute winner of a device.
Years behind is not bad. Pinephone Pro has solid camera sensors and dated but good enough ISP pipeline. Original Pinephone's camera situation is limited by SoC having no ISP so at best you can try using GPU to perform the transformations, or completely rely on ISP embedded in the sensors.
Linux desktop is still not caught up with Windows/Mac in regards to graphics, gaming, and laptops hardware support.
Gaming, it is mostly Windows games via Proton, hardly any different from using MAME, FS-UAE, Amiberry,...
Graphics, most of the well known commercial packages for VFX, 3D modeling, visualisation, lack a Linux version.
Laptops, just two years ago I failed to make UEFI work with the myriad of distributions I tried out, unless booting from external USB drive, and even then there was the whole termal configuration.
I can't really speak to laptops but I ditched windows last year for Linux and it's pretty damn good for gaming I have no reason to go back to windows at this point every major game I want to play works flawlessly.
The only issue I've had is the new rust desktop from pop os, but I just pop back into gnome and everything is golden. I hope they get their issues solved soon but it was just released 6 months ago or so. I can understand there's some bugs to work out.
Linux desktop has always worked, and was better for me. There will always be stuff you can't have on one OS that works on another, this has been true since before Linux. The question here is of what we are given be iOS and Google Play Services is enough, for many of us it is not.
I daily drive SailfishOS on Jolla to see if it can be enough.
How so? To make it work on Librem 5 I had to fix some issues in Waydroid's gralloc and hwcomposer implementations, but that was back in 2022. It has just worked out-of-box ever since.
The only thing different from this list is the ceramic separator. It’s not polymer. However, the ceramic is ultra thin to the point that it’s flexible so volume expansion isn’t a problem and it solves the dendrite problem.
Perhaps a polymer will be invented that can’t be pierced by dendrites. But existing polymers need to be heated for ion transfer efficiency and are combustable.
Technically, QuantumScape also uses an organic liquid catholyte inside the cathode. So it’s not “pure” solid state.
As someone who generally liked the article, this is perhaps the strongest argument against it. Prose like this requires even native speakers to really focus. I wouldn't write this way for anything intended to be read by an unknown person.
I was unaware of alternative IRs for julia (albeit I started learning much more about compilers once I left the julia ecosystem). What other IRs is this supposed to replace? And why not just go with MLIR directly?
Julia has roughly 2 different IRs that live pre LLVM (one for type inference, one for Julia level optimization). This is a proposed replacement to both of these. The reason not to go MLIR is that writing Julia is a lot nicer than writing C++.
MLIR pulls in a lot of interface complexity that we don't want or need for pure-julia end-users. That said, it is obviously and deliberately close to MLIR as a representation since people do want to be able to interface with MLIR (e.g. in Enzyme), so I'd like to facilitate easy conversion back and forth.
You can depend on just MLIR core; Mojo (from Modular) uses MLIR, with only the index and LLVM dialects coming from upstream MLIR. The benefit is that you focus on designing your IR without also building supporting infrastructure, while having MLIR ecosystem at hand should you need it.
Linux has long been the most practical laptop OS for me, but I can't see it ever being competitive with mobile OSes, and that's coming from someone who wants it to succeed (I've installed postmarketOS on a OP6T). I just don't see how it will overcome the various issues (app support, tap-to-pay, camera quality, etc).
I've never understood tap-to-pay being a dealbreaker issue. It takes me just as long to pull out my credit card as it does to pull out my phone, and you can use them on the exact same terminals.
App support and camera quality I can understand more. I'm on a Linux phone using Phosh (FLX1s), and there's Android app compatibility, but it is a little rough (and of course things that rely on Play Integrity won't work). I've managed to avoid tying myself to anything that requires Google for now, but I acknowledge that I'm lucky there.
With tap-to-pay, you can store multiple cards in your digital wallet, and you don't have to remember any of their PINs. You can use your fingerprint to sign transactions. I believe this makes it faster.
There's also thresholds where a simple tap of a card won't work and you need to insert the chip, not the case with the phone. Phone is much much easier, don't even have to open the wallet app, just unlock the phone with your fingerprint and tap.
Tap to pay isn't itself a dealbreaker, for me it's more a representation of the status-quo and what is to come, specifically how more and more of the modern world will rely on integrations with proprietary software and hardware on phones. Tap to pay with credit cards isn't too big of a deal, but the wallet as a whole (i.e. boarding passes for airplanes, gift cards, ChargePoint tap-in) is a major feature.
> It takes me just as long to pull out my credit card
It can be a lifestyle difference.
I personally don't being my wallet in most daily trips, have no use of it. I used to stick a credit card in my phone case but also got rid of it as more stores reliably offered wireless and QR code payments.
Mind you this comes with a specific environment I don't expect everyone to live in or long for, I'm just explaining.
See, I have to have my driver's license, but if I could have that on my phone as well, I might do this. Running out of battery is largely not a concern for me as I already carry an external battery with multiple days of charge.
In Denmark at least we have this, both our drivers license and social security cards are apps on our phones. I only need my old physical drivers license when I leave the country.
I often leave the house without my wallet these days. It’s great. Especially riding the subway, where Apple’s transit functionality means you don’t have to do anything other than tap your device without even unlocking, is a very nice convenience when you’re carrying groceries or something similar.
I just put my debit card in the pocket in my phone case. Job done. If yours doesn't have a pocket, you can try putting it between the phone in the case. In that scenario, I suggest turning off NFC on the phone so it doesn't keep trying to read the card.
Unfortunately not. A lot of UK banks require using your mobile phone as the 2nd factor to log on to online banking on your laptop. They used to issue fobs/card readers, but have moved to using the app for this now.
That's why I never accepted the app from my bank. It still work most of the time but it's cumbersome for some uses (like adding a new recipient for wire transfers, it takes two days).
As long as every phone distro is just a desktop distro shoehorned on a small screen, that's not gonna happen.
IMO it's not a matter of tap to pay and camera quality, rather a matter of whole system paradigm. Having millions of disconnected services in the "do one thing and do it right" spirit and using text based communication and hundreds of python and shell scripts is relatively maintainable and relatively easy to use, but very inefficient when it comes to CPU cycles - and on a handheld every cycle counts.
And of course every app is optimized for desktops/laptops... but I guess that's a chicken-or-egg problem: once there is a working distro, there will be apps too. And once there will be apps to use, there will be a working distro. Maybe.
From personal experience, many apps work suprisingly well on Phosh. The thing keeping me from using a Droidian phone with Phosh was a seemingly device-specific issue with answering regular phone calls. Kind of ironic that the linux phone could do many apps from FlatHub flawlessly with touch and everything, but not regular phone stuff. Nevertheless, the smartphone part is handled quite well with the Settings app, the quick toggles, the support for flatpaks, and so on, especially with Wayland where the android ecosystem is within reach.
If I read correctly, you identified the lack of smarthpone-level apps and distro as the limiting factor. In my opinion, the lack of sufficiently powerful but still open hardware is what we miss. Mainline linux with proper hardware support is pretty good but not complete on the Snapdragon 845, a 9 y/o platform. Anything newer? Nearly impossible without some android-specific layers (such as libhybris in the case of Droidian). Currently mid-high level hardware with PinePhone-like openness would probably let Phosh (and Plasma-Mobile, SXMO etc.) distros strive. The smart features, as in the apps, are mostly there.
Better open hardware would help a ton. Phosh itself was made for the Librem 5. The mobile specific Linuix apps are getting made in response to hardware, not to make a market for it!
Oddly enough I am using Win10 right now on my laptop. On my
main computer I use linux but I also got tired having to set
up things specifically for the laptop or be locked down in
a specific distribution; plus, I also have to run various
software on the laptop and when the rest of the class or
group uses Windows, and you are the sole Linux person, it
feels very lonely. So I fake being a win user in that case.
I've been using GNU/Linux on my phones for the last 18 years, initially as a portable hacking platform back when I was a teenager and now as the most practical mobile OS for me. I often see people mentioning these areas as something they "can't see becoming competitive", but this doesn't really match my experience. It feels very much like what running GNU/Linux on a PC without having Windows around felt like 10-15 years ago or so and it very noticeably keeps moving forward over time.
My experience today is that I have all the applications I need daily, and the odd ones I don't have natively I can run in Waydroid. There are currently some limitations when it comes to access to hardware from within the container, but nothing that couldn't be overcome with some moderate effort. The only real blocker is remote attestation, but I see it as a threat to the whole fabric of society, not just Linux phones, and it should be opposed regardless of platform one uses.
I don't really get tap-to-pay. I never thought it's something I want or need to have on my phone (which doesn't even have NFC, though it could be added as an extension). I just use a card. I get it that it may be slightly more convenient, but definitely not worth changing the OS over, let alone giving others control over my phone. That said, I have full access to my bank account from my phone anyway. Practically everything except TOTP payments (Blik) can be done from the Web (and with Epiphany's webapps it's just there as an app to launch), and Blik can be used from the Android app in Waydroid. Frankly, if I couldn't access the bank from my phone I would rather change the bank than the phone, and would make sure to let the customer service know very clearly why I'm doing that.
And when it comes to camera quality, matching the state-of-the-art overprocessed mess would be hard, but having played with camera processing a lot recently I can say that perfectly adequate quality is absolutely well within the reach (if not there already for daylight photos). I only researched absolute basics of photo processing and implemented some essential stuff while completely ignoring others and I'm already quite happy with the photos I get (https://social.librem.one/@dos/tagged/shotonlibrem5) and there's enormous room for improvement still that only needs someone who knows what they're doing to sit down and implement things that are missing. Some of that stuff is already happening around libcamera as more people get involved there thanks to laptops with webcams that also need similar software handling. The particular phone I'm using doesn't have hardware video encoder (only a decoder) so video recording will stay low res there forever unless limited to short clips, but it's not a limitation inherent to the platform, just to this specific device.
I have briefly carried an Android device as a secondary phone some 10 years ago out of necessity (N900 was starting to get too old to handle the Web and Librem 5 did not exist yet) and it felt quite miserable, it seemed like an appliance rather than a personal computing device despite of equipping it with microG, F-Droid, rooting it etc. When you're used to being able to script a simple thing right on your phone using whatever technology you already feel comfortable with, it's hard to give it up. Just try to patch a simple thing from the system's core on an Android phone - yes, it's possible if you're really determined, spend a lot of time on it and don't mind attestation issues, but I can do that with dpkg-buildpackage on my phone's screen within minutes, send a patch upstream and have it actually merged in time it would take my laptop to produce an Android image. I may not exercise this ability a lot in my daily use, but having such possibility is incredibly empowering. I can't see Android becoming competitive there, quite the contrary ;) The only actual obstacle I see on the path to growth is the threat of remote attestation gaining widespread use and this affects any existing or future platform from outside the duopoly, not just GNU/Linux in particular, and I believe this still isn't a lost game.
Thanks for sharing your experience, I'm glad to hear that mobile linux is practical for some people. What do you do for GPS? And in day-to-day use, doesn't WayDroid drain the battery?
I usually use Pure Maps [0]. Note that various phones handle GNSS differently and for fast fixes, depending on the phone and distro, you may have to configure or trigger retrieval of assistance data from the Internet ([1] is an example for Librem 5's Teseo LIV3) - the module will be able to download all this stuff from the sky as well, but it may take several minutes or even fail under poor conditions, while getting fresh data online and acquiring a fix based on it takes seconds.
When it comes to Waydroid, I boot it up very rarely and usually just to do something specific and stop the container afterwards, so it's not a concern. But if you wanted to keep it loaded for fast access (booting it up takes about half a minute) you can either freeze the container or just suspend the entire phone and it shouldn't influence anything other than keeping RAM occupied.
reply