When will Linux phones be good

Has anyone had experience using a phone operating on a linux based OS. After the whole spill about Android trying to stop people from downloading applications from other sources besides from their playstore I'm surprised there isn't more of a push for people to take complete ownership of their mobile devices. The FLX1s Looks promising at first glance

A linux phone needs to simultaneously maintain working audio out, microphone in, wireless networking, and a pleasantly readable GUI. Each of these are problem enough for linux on conventional PCs... Linux phones seem like a less likely version of the year of the linux desktop. They will not be cheaper than purposefully inexpensive Androids, since those droids are able to offset some of their costs by monetizing the user. Maybe even selling at a minor loss. They will not be higher quality than iPhones, or Samsungs. It's not just a librem thing, it's inherent in the nature of the task. They will probably also not be more private or hardened than current effortful solutions like GrapheneOS, since gOS was designed by a paranoiac who is actually good with computronics. Anyone who is better at privacy and security than gOS would have made a better gOS. Phone culture is unprincipled and hypocritical in general. Joe Rogan spent years saying that if he could buy an ethically sourced and ethically manufactured smartphone then even if it cost a ridiculous amount of money he'd do it just so he didn't look at his phone and think about the coltan mines in the Congo anymore. Then phones like that started appearing in the market and at that point it turned out price does matter. I've not paid the closest attention to the guy, maybe he's moved onto a fairphone or a librem-5-USA since then but if so it took years. If a public figure like Joe Rogan is willing to lose face in public over a few thousand bucks, there's not much chance of Joe Regular changing his ways. And if you can't get Mr. Rogan's money and you can't get Mr. Regular's money, there's not much incentive to make drastic changes. When the market size is a few thousand units sold, the key isn't to sell each of those few thousand units, it is instead to avoid cost overruns.

All Linux phones are worse in security, app compatibility, battery life, hardware specs, durability, and usability. The only advantage really is being able to run desktop or server programs without restriction, no weird Google proclamations, limited anyway because you're stuck on some old kernel and the battery life is soykaf. And I do mean the security is worse. Linux desktop security is atrocious, make no mistake, but then you add on how Waydroid is ALSO out of date and more insecure than native Android. The only saving grace is you're probably more likely to be using Wayland so you don't have a massive security hole if you managed to use VMs or jails to provide some isolation at least. Anyone telling you Linux security is "good" is a dangerous moron, you have to do so much work to even remotely compare to competing OSes. At the very least some good ideas were sort of forced in recent times like providing SOME isolation to services in systemd, which some babbling moron will tell you is worse than their very insecure init system and shell script duct tape. For example Android uses SELinux and barely anyone uses this in Linux. Probably the closest thing to Android in the GNU/Linux world is Secure Blue and nobody is using that yet at all. Most Linux distros are run by rank amateurs security wise who engage in pointless security theater while ignoring massive security holes for most of their users. That phone in particular is using that hybrid Android/Linux approach. It's essentially stuck on whatever kernel that device needs for Android to function. Phones are all kind of disposable like this eventually but cheap ones especially will be EOL on arrival kernel wise, or pretty close to it. A design like a Google Pixel is way out of reach for these Linux phone startups, far too expensive & not available to them. Mainline Linux phones tend not to support all functionality of a modern smartphone, the camera is usually not working, or texting is broken, or calling is broken, or WiFi is unstable, etc, so that is why the approach where Android handles this bit is being used.

>>89549 Can you elaborate more on why Linux security is bad compared to Android or other operating systems in general? Which threat actors on the skill curve (non-actor, novice-actor, talented-actor, advanced-actor, state-actor) can readily breach a Linux Desktop system set up with the following assumptions? - Assume the user doesn't run random scripts without checking e.g. no curl -O whatever.org/script | sh - Assume the user only uses packages from the distribution e.g. no compiling random github repositories - Assume the user updates the system once a day e.g. a cronjob automates system wide updates - Assume the user uses a bleeding edge distro e.g. Arch and Debian Sid, no security "backports", follows upstream - Assume the user doesn't allow remote code execution from usual suspects e.g. no javascript is allowed in web browsers, no yt-dlp with deno access - Assume the user doesn't open arbitrarily complex media formats outside of virtualized and locked down subsystems e.g. Open pdf, docx, and video files in non-networked disposable virtual machines

>>89550 Why not assume the user doesn't connect to the internet at that point.

>>89556 Lots of servers are running a linux kernel , if linux was really this insecure and you're correct then not all these servers would be running it

>>89558 NTA but OP didn't state that security can't be improved via third party applications >not all these servers would be running it Netflix and Meta both run FreeBSD

>>89550 >Assume... This is all security theater if you don't even plug GNU/Linux's well known holes. LD_PRELOAD, X snooping, failure to jail every program, etc. You're just rearranging deck chairs on the Titanic so I'm not going to address those points. All it takes is one internet connected program having a backdoor ("trusted" programs from the repos can have this, already has happened) or having some sort of remote code execution exploit and then they can do whatever they want with your home directory and hoover up all the cryptocurrency related files, key material, password DBs, any sort of information useful for identity theft, set up a keylogger or screen grabber. They can then attempt to get root as many times as they want because the distro developers did not actually set up limiting logins per X amount of time. Most people are going to run code on an OS and eventually there will be some sort of code that they can't absolutely trust. Trying to run only trusted code is not what actually happens on the Linux desktop. Flatpaks, Docker images, JavaScript, npm, pip, cargo, etc tend to get run. Instead of pretending people don't run untrustworthy code, we should isolate programs from each other, plug the obvious exploits that everyone knows about, and make it secure by default (which is the only sane way of going about this). Oddly enough some level of program isolation already happens for services in most distros since they use systemd, yet they don't do it for programs run by one user, unless they're Flatpaks or specifically configured scripts. >>89558 A lot of them are using VMs/hypervisors/microVMs/jails, SELinux or Apparmor, locking it down as much as possible. They don't run software the same way a single user desktop user does. If some malware ends up in some VM they can just wipe it clean and start over from their trusted template for example. Like Android they use Linux and whatever security feature they can find and they change the way the userland is used, not in the same way as Android as the needs are different. Hobbyist GNU/Linux is just barely recognizing that any of this exists in recent times. There's been some minor progress but there's few distributions willing to actually set the standard. Some common examples of these distros failing: They use Flatpaks but don't lock them down therefore allowing sandbox escapes, they allow setuid binaries, they use su/sudo/doas instead of run0, they allow insecure debugging tools like ptrace to be run, they allow LD_PRELOAD, they have not yet defaulted to Wayland, they default to insecure NTP, they default to insecure DNS, they do not use USBGuard, they do not use SELinux or do not use it properly, they don't have a blacklist of insecure kernel modules, they do not have an easy way to jail processes on demand, they have made a distro that is incompatible with Secure Boot and measured boot, they don't actually limit login attempts, etc.

>>89556 >>89558 The only real argument about Linux security, out of the box, is the fact that it is overly permissive... That said, I will say the linux ethos actually supports this. It is not a "security first" operating system. You guys are tilting at windmills.. There are plenty of ways to secure Linux. Shrinking the attack surface, both in the kernel AND in the software being used, fixing said permissions, etc. You can really do some good work in securing a system. It's some actual work, but we aren't complaining about work here. The pieces are all there. That said, I still run OpenBSD over Linux for security. I only use Linux (Gentoo, specifically) when I need to use things that may not run on OpenBSD for whatever reason.

>>89562 It's not a security theater if you are systematically plugging exploit vectors. You can solve (not mitigate, solve) radio based exploits by ditching wireless peripherals and use ethernet and cabled peripherals instead. All my assumptions are along that line of thought. Timely and constant updates solve n-day exploits. Preventing remote javascript and wasm execution solves JIT compiler exploits. Malicious scripts exist. You should read and understand every script and fork it into your own repository. Malicious files exist. You can get a relatively high protection by opening untrusted files inside hardened virtualized environments. That won't protect against a chained sandbox+kernel+VM escape, but it's a far higher bar than before. The real security theater is expecting that sandboxes and hypervisors will protect against every imaginable exploit. No notable work has been done to replace Linux with seL4 kernel so it will remain true. There are zero-click remote exploits for iOS, even though it is arguably the most secure consumer OS. Only hardware level segmentation and airgaps can help contain a catastrophic breach. >limiting logins per X amount of time That expectation is misplaced. Your password should have a high enough entropy to prevent bruteforce attacks in the first place. >Trying to run only trusted code is not what actually happens on the Linux desktop That's by choice. No untrusted code runs on my machine. >Flatpaks, Docker images, JavaScript, npm, pip, cargo, etc tend to get run. See above. Audit, pin the repositories and run. Segment activities into hardened virtual machines. You can create minimal virtual machine templates and clone them to run an application. Qubes OS can help simplify all of that. >they can do whatever they want with your home directory and hoover up all the cryptocurrency related files, key material, password DBs, any sort of information useful for identity theft If I have remote code execution on your machine I can also capture your keystrokes and decrypt your password database. Sandbox escapes are not impossible and have been demonstrated in the past so secrets should be kept offline. You can buy a cheap laptop, remove its networking card and use that for managing secrets e.g, Keepass database, crypto wallets.

>>89562 Fedora Atomic does good job on having the system immutable, using SELinux by default, having everything via Flatpaks by default, having all kinds of distrobox/toolbox/podman/etc stuff to sandbox/virtualize. Idk what is the thing you mention about Flatpak, most programs are barely allowed to use anything by default.

>when phones good Whenever cattle start caring about >complete ownership of their mobile devices Never. We're chained to cattle and they're dragging us down to hell.

>>89549 Do you think Wondows has better security? Linux just has to be better than that for it to be an improvement over the bar that's been set.

>>89579 Windows does have some nice security features like kernel hardening, kernel address randomization, stack canaries and hypervisor enforced segmentation, but no privacy. It also has all the baggage of backwards compability. Bulletproof Xbox security is what Microsoft could achieve if they didn't have to support every Windows program written in the last 20 years. macOS has an even better security posture but no privacy either, in fact it has embedded local AI models sending everything you look at to Apple servers. That's better than uploading all your files to OneDrive I guess. iCloud > OneDrive? Maybe not.

>>89589 iCloud > OneDrive > Protondrive > Hosting your own back ups / drive Also you have any information about the embedded local AI models on the mac os sending things to apple servers because as far as I'm aware windows / microsoft does the exact same thing. I know they both send out crash reports and call home for various reasons each in their own way

>>89565 >That expectation is misplaced. Your password should have a high enough entropy to prevent bruteforce attacks in the first place. A higher entropy password is helpful but we can't assume every user is a cryptography expert, and there's always some attacks that could potentially weaken existing passwords in the future. This is just an additional, low cost layer of security. To be honest it should be much easier to set up a two factor authentication setup via biometrics + a password or something like a FIDO key + password for increased entropy and increased likelihood of the real presence of the user. I know you can set it up, but it's again not even remotely default or simple usually. >That's by choice. No untrusted code runs on my machine. Did you review every line of code? Are the builds reproducible? No curling in the package recipes to random domains? There's always a chance and all code has the potential to be untrustworthy. Humans are fallible so having some extra security helps. >Qubes This method I think is more of an interim solution as it has some major drawbacks. Increased resource usage and increased difficulty in maintaining persistence is not ideal, requiring hardware virtualization support is not ideal, maintaining templates is not ideal. The stupid thing is you can more or less do something equivalent if you lock down Linux hard except with much less resource usage, the hard part is the complexity of doing that. Either has the potential to be escaped from but it's better than what the majority of Linux desktop users do right now. >You can buy a cheap laptop, remove its networking card and use that for managing secrets e.g, Keepass database, crypto wallets. This is what normal people use their phone for. Using a cheap laptop like this seems like security theater anyway, as you must access the database, wallets, and so on, so it's never going to be airgapped anyway. Unless you mean you're actually hand copying stuff by looking at the screen, which is a horribly slow way to do it, this is terrible in public anyway as there are a thousand cameras around. Also that cheap laptop is more insecure than your phone, heavier, and larger. >Audit, pin the repositories and run. Why not just have the language package manager install the things it actually says it will install without executing remote code in the first place? The npm model really needs to be eliminated. Overall I think what you're doing is going to require way too much discipline and system resources for the average end user, it's not realistic. >>89566 >Fedora Atomic does good job on having the system immutable, using SELinux by default, having everything via Flatpaks by default, having all kinds of distrobox/toolbox/podman/etc stuff to sandbox/virtualize. Yes, immutable distros are on the right track, however a lot of other distros do not follow this example. >Idk what is the thing you mention about Flatpak, most programs are barely allowed to use anything by default. A lot of older ones had poor settings, but I guess they must have changed a lot of them by now, which is good. >>89579 >>89589 I've heard Windows did make some progress since their golden era security wise but the problem is no one cares about it anymore, not even Microsoft cares for it as they pivoted to Azure, SaaS versions of some of their traditional products, AI junk, and a selection of software they focus on like VSCode and C#/Dotnet. Since the failure of the push for mobile convergence in Windows 8/their now failed mobile platform they basically have to slowly suck the life out of Windows. For video game development it's just something to target now and that can be safely moved to a Linux ecosystem using Proton and Wine if Windows falls apart someday, so the stakeholders like Valve and game dev companies don't lose everything due to irresponsible behavior. >>89590 You have brand loyalty to someone else's servers? If you can afford a cheap NAS with cheap high capacity HDDs in RAID with SD-WAN VPN software you're doing 90% of what they do. 95% if you can get your storage server co-located in a data center.

>>89589 So Windows achieves better security without the PITA that comes with sandboxing... >>89592 >no one cares about it anymore Many professionals are dependent on software that only runs on Windows. Engineers and AutoCAD. Traders and Bloomberg terminal. Dentists, and... whatever they use. There's too much software like that for Windows to be going anywhere, anytime soon.

>>89595 Unfortunately we seem to be trending towards cloud only Windows in the future. Google was too early yet again with Stadia but I think they established the concept well enough to be concerned that, in the future, we will likely see enterprises shift entire departments to pure cloud. We've already seen it in some sense already and I think realistically, the only thing that's holding us back from that even further is more reliable and high-speed internet for everybody, but I think that's a problem that's rapidly being solved. Maybe I'm off base here but I believe that owning your own machine will be a thing of the past before we know it for a large amount of consumers.

>>89547 there's just not enough capital to make a linux phone, you need bazillions of dollars to make an SOC and all the SOC makers won't mainline their drivers so you're stuck with android or cope like halium look at this, another linux phone startup that died due to lack of funding https://liberux.net/

>>89601 I don't understand how there isn't, Someone smart enough with a bit of money could start up a company twisting around with what google is doing with android and making people who are wanting to use android for it's 'openess' for themselves in promoting a phone that is completely open to the user to do what they want at the end of the day, Someone needs to make some half decent hardware , optimise a version of gnu/linux to run on a phone

>>89605 someone smart enough with a bit of money will just join google and make money off the catle

>>89565 I have found another (partially) formally verified kernel, written in Ada and SPARK. Here is the website and the code repository if anyone's interested. https://ironclad-os.org/ https://codeberg.org/Ironclad/Ironclad

>>89601 FSF started a "libre phone" project recently which is about reverse engineering the firmware of phone SoCs so HOPEFULLY things will improve https://www.fsf.org/news/librephone-project

There is also Sailfish OS, which is Linux-based and supports a number of devices. But it is not fully free software. Jolla C2 phone is not that terrible hardware-wise. Their business model is a bit sketchy though - they charge for updates on a yearly basis as far as I remember. In a better world Fairphone would collaborate with Sailfish OS and/or Graphene OS and create a modular truly secure and private phone with FOSS hardware and software with 8+ years of support.

>>89613 >prioritizing the free software work done by the not entirely free software mobile phone operating system LineageOS Great. Even if Librephone delivers firmware within this decade, there will still be the full weight of the Google-owns-Android problem to deal with. Why not reverse-engineer Pi blobs instead? Look at these specs! https://www.raspberrypi.com/products/raspberry-pi-5/

>>89640 Why RPi? There is a lot of other SBC/SoC that could be easier to make them fully free. Like sunxi or rockchip stuff I hope

>>89595 >Many professionals are dependent on software that only runs on Windows. Engineers and AutoCAD. Traders and Bloomberg terminal. Dentists, and... whatever they use. There's too much software like that for Windows to be going anywhere, anytime soon. That's just too few users to keep bare metal Windows going, and none of the companies using that software care what OS it runs on. New generations do not learn to use Windows, they start on phones and tablets which are all mobile OSes that are not Microsoft owned. Windows is simply on borrowed time as new users have zero loyalty to their platform. >>89598 >Unfortunately we seem to be trending towards cloud only Windows in the future. SaaS-ware mixed with some local programs/data on thin clients or phones/tablets? Sure. I don't think everyone can adopt actual dumb terminal-like stuff where everything is remote except for a screen and input. Local storage and caching means the users aren't all hitting the service at the same time, thin clients are just kind of cheap, easy, and available now. Especially if it's just some tablet hooked up to a keyboard. Oops you went into a tunnel, all your directories unmounted, you have to reconnect, oops another tunnel... then you lose some data in the process too because there isn't any storage or caching locally. Or your Internet goes out in a storm, or there's a service interruption. You can't make the local machine too useless or else you'll run into these fundamental problems with the cache hierarchy and connection loss and so on. >We've already seen it in some sense already and I think realistically, the only thing that's holding us back from that even further is more reliable and high-speed internet for everybody, but I think that's a problem that's rapidly being solved. There's a lot of locations that rely on iffy Internet by their nature, there simply won't be fiber lines going there. I think that is a part of why Stadia was a flop, beyond typical Google style management of the project. Tech companies just assumes people have much better, consistent Internet access than they actually do. Also adding more latency to gaming isn't exactly popular with gamers, and if there are no servers near your country it's not gonna be a great experience anyway. >>89613 >FSF started a "libre phone" project recently which is about reverse engineering the firmware of phone SoCs so HOPEFULLY things will improve This is a huge waste of time and money, by the time you reverse engineer a SoC fully they moved several generations ahead and it is way out of date, and the phones are going EOL soon. I think FSF does not understand the mobile hardware market, it's built to be thrown out, it isn't like the PC market where you can use a PC for 15 years. There is no UEFI, you are not meant to reuse phones, there is all this attestation crap, there are a bunch of coprocessors and cameras on the board that are absolutely proprietary. From the top down it's supposed to be a closed ecosystem, opening up some firmware won't help, they have to go against Google directly. Hardware is fundamentally proprietary, locking in a blob forever isn't making it not proprietary it just means you can't change it or fix hardware bugs. Also completely pointless if Google just shuts off free software on phones forever. You won't even be able to load up F-Droid anymore but you should be happy someone opened up some outdated firmware? They should be looking to get more control over the software ecosystem. They should have done that 15 years ago when smartphones were obviously becoming a thing. >>89640 >Why not reverse-engineer Pi blobs instead? It's a crappy overpriced SoC board and nobody actually needs one to interact with society.

>>89644 You have to crack the code only once. An iPhone 5s from 2013 is perfectly adequate for today's computing needs. The only reason it is well past its support windows is because of planned obsolescence and terribly inefficient programming practices that demand 8GB of RAM to run 5 webapps concurrently. I think it would be possible to sell Linux phones from a longevity angle. If the drivers are upstreamed, there is no need for distributions to maintain support for a particular piece of hardware either. You could install any distribution made for phones - much like most Linux distributions are compatible with most amd64 computers from this century - even on mobile hardware from 10 years ago. There is a UEFI standardization effort for ARM with some manufacturers on board. https://developer.arm.com/Architectures/Unified%20Extensible%20Firmware%20Interface And that effort is bearing fruit. https://hothardware.com/news/minisforum-unveils-worlds-first-arm-based-mini-workstation-with-uefi-boot >November 10, 2025 >The compact PC world may just have been given a good shake up with Minisforum's new MS-R1, a mini workstation with server-grade Arm performance in an expandable desktop form factor. But hold up, the machine is also being hailed as the first of its kind in the world to support UEFI boot. With UEFI, the MS-R1 makes it as simple to install and run mainstream OSes like Linux and virtualized environments as it is on any standard PC. Will developers and enthusiasts rejoice? Let's dig in some more. The most important piece of this puzzle will be whether if open source developers will choose to license their software under AGPL or even SSPL to retroactively prevent the source closure for this new environment.

>>89646 >An iPhone 5s from 2013 is perfectly adequate for today's computing needs. It's a decade plus old cellphone, any cheap UMPC or modern cellphone will basically beat it in all benchmarks, the only reason to keep it is because it probably still does calling and texting. It's not as secure as some phone running GrapheneOS, it's not as open as a x86 device, it's not really user serviceable, what is the point to this thing? Just buy a cheap Chinese Intel UMPC or something if you need something small-ish for general computing, otherwise a cheap Pixel for whatever time remains for the open Android ecosystem. >I think it would be possible to sell Linux phones from a longevity angle. No. The boards that Linux phone companies can afford come with source for an EOL kernel or for EOL Android version usually. They are already out of date on arrival. They're equivalent to using your e-waste phone with a new battery except maybe a bit better in hardware specs. They're pretty bad specs too usually, you can find UMPCs more powerful if you don't care much about battery life. Those companies would need to stop doing that for this to be possible and actually support the hardware, it has not happened in the mobile Linux push so far. >There is a UEFI standardization effort for ARM with some manufacturers on board. Unfortunately this is not leaking into the phone world so far, it seems to be a small energy efficient PC or energy efficient laptop type deal so far. I'd like actually supportable Linux phone hardware but you have to understand what gets sold now is basically insecure junk that is usually stuck on an old version of Linux.

>>89650 >>89644 Do they actually do school work, and then real work, on a mobile OS? And companies are invested in the Microsoft ecosystem. Outlook, active directory, power BI, and other crap like that. Sure, eventually they'll be dragged out of it, but that'll take decades. Even mainframes and their hideous software are still around and making IBM money. >>89650 >what is the point to this thing? It's not a moving target? Making it useful is for developers to figure out. Even a Nintendo DS would be a serviceable phone if it could make calls and send texts. Developers managed to create thousands of applications for it that are more diverse and impressive than the mobile ecosystem is.

>>89653 >Do they actually do school work, and then real work, on a mobile OS? You can't do everything on there yet but there's more being done than I would have thought. Artists can pretty much work on an iPad fairly effectively now, plus whatever SaaS or office-like app that can work with a Bluetooth or USB-C keyboard. They are working on putting Linux desktops on top of Android as well to bring in desktop programs directly. To some degree they can avoid Windows altogether on laptops via Macbooks and Chromebooks when they go to school or college. >And companies are invested in the Microsoft ecosystem. Outlook, active directory, power BI, and other crap like that. Sure, eventually they'll be dragged out of it, but that'll take decades. Even mainframes and their hideous software are still around and making IBM money. Going B2B only means ceding control of the PC market someday like IBM did. They will be outdated like IBM if they continue on this course as they are losing new generations to mobile platforms and Macs to some degree, that means they will never have that market share ever again. Mainframes are required because of legacy programs that can't go down, but a lot of Windows stuff is simply butts in seats kind of jobs, they can be phased into using Wine or a direct Linux port someday if Microsoft really leaves Windows in a state of decay. It'll take decades but the process has already begun. >It's not a moving target? Almost everything is broken on the port of postmarketOS for the iPhone 5s and no more of these phones will ever be made. So even if you fix it up, you now have limited stock and no way to make more. This is a time wasting exercise for hobbyists. I would say it's not even a good platform to target for a hobbyist OS as other Linux phones at least got somewhat further although they all have some subsystem broken if they're not running Android below Linux for hardware compatibility. And those phones are essentially stuck on some ancient version of Android and the Linux kernel. So yeah, complete waste of time from the viewpoint of normal human beings. >Even a Nintendo DS would be a serviceable phone if it could make calls and send texts. Most people use smartphones now. This would be comparable to a crappy feature phone or dumb phone, the ecosystem moved past this point long ago. >Developers managed to create thousands of applications for it that are more diverse and impressive than the mobile ecosystem is. There are millions of mobile apps and a smartphone is a hard requirement in many countries now. Nobody has even heard of this ecosystem except hobbyists and a few gamers. The ecosystem has moved on from these feature devices. You're free to waste time but this is not the direction to go in to make GNU/Linux a viable mobile platform.

>>89663 >Most people use smartphones now "Smartphone" is just a marketing term. The only difference between them and "feature devices", is providing an SDK, which the DS obviously did. Your suggestion is to completely surrender on hardware, so people can keep using the latest, bloated shovelware, except through Linux. Normal human beings would also consider that a waste of time.

>>89564 How is OpenBSD better in terms of security?

>>89564 That's true, but for what it's worth, there is some good work being done with flatpak. There is also permissionless sandbox mechanisms built into Linux. My good guess is that most open source developers are more interested in implementing features (fun and also easy to demonstrate to potential employers) than working on bug fixes and security hardening (boring and more difficult to pitch to potential employers, especially if they are a ship fast and *maybe* fix things later type of organization). It's also more difficult to bolt in new security features if the program was designed with none in mind and now widely deployed, so now you either break backwards compatibility or leave security issues unfixed. https://blog.prizrak.me/post/landlock/u >Landlock is a Linux Security Module (LSM) available since Linux 5.13. Unlike MAC frameworks such as SELinux or AppArmor, Landlock applies transient restrictions: policies are created at runtime, enforced on the current thread and its future descendants, and disappear when the process exits. >You don’t tag files with labels or extended attributes. Instead, applications create policies dynamically. >A Landlock policy consists of two pieces: > Handled accesses — the categories of operations you want to restrict (e.g., filesystem read/write). > Access grants — an explicit allowlist of which objects are permitted for those operations. >For example, you could create a policy that handles all filesystem reads/writes and network binds, and grants: > read-only access to /home/user > read/write access to /tmp > permission to bind to port 2222 >The application then calls landlock_restrict_self() to enter the restricted domain. From that point on, that thread’s child threads and child processes are permanently constrained. Restrictions cannot be revoked. >Policies can be layered (up to 16 layers). A child layer may further reduce access, but cannot reintroduce permissions the parent layer removed. For example, a child thread may add a layer to this policy to restrict itself to only reading /home/user, but it cannot regain permission to bind to port 2222 once a layer omits this grant. >Landlock is unprivileged — any application can sandbox itself. It also uses ABI versioning, allowing programs to apply best-effort sandboxing even on older kernels lacking newer features. >It’s also a stackable LSM, meaning you can combine it with selinux or apparmor in a supplemental layer.

>>89670 >Your suggestion is to completely surrender on hardware, so people can keep using the latest, bloated shovelware, except through Linux. I'm saying it's dead before arrival as there is no open ecosystem for hardware on mobile platforms. Linux phone startups get the trashiest SoC, fail to fully support the on board devices (things people expect to work by the way), then declare victory. Plus free software enthusiasts have done a horrible job on trying to "solve" the hardware problem. Just take a few glances at RMS's beliefs about hardware and you'll realize he wants you to burn in proprietary software forever into ROM chips instead of working on open hardware. Free software enthusiasts have zero clue what to do about hardware and essentially have no solution. Right now essentially ALL HARDWARE IS CLOSED, including your computer, including "Linux Libre" devices. Show me schematics plus all source code of all on board devices, otherwise fuarrrk off with this nonsense. You just have a somewhat more open ecosystem which is a byproduct of something that happened in the industry decades ago in the PC and server world. Linux phone projects keep assuming some sort of PC-like ecosystem and run into trouble immediately as they can only afford the most garbage SoC without any way to make the on board devices function without reverse engineering or running Android on top of it to run Linux (usually stuck on one kernel version as that's all that will be supported). The top end of phone companies can design their own hardware or buy the very best solution because they know the whole thing is bespoke and not really an open ecosystem and that the OEMs are horrible at supporting their hardware. This is way out of the reach of software hobbyists unfortunately so they'll stay in the tar pits unless the mobile ecosystem opens up a lot more. >The only difference between them and "feature devices", is providing an SDK, which the DS obviously did. It doesn't have all the features of a smartphone, which has more sensors and is a slate touchscreen design usually, which is the design people have come to expect. Anyone spending like a day using a smartphone for the first time can tell you that there is a pretty large difference between those devices. A NDS is a game console feature device that has reached its end of life which very few people target as developers anymore. Android is not just a SDK either, it's a complete OS. You can't be taken seriously when you're comparing an obscure SDK only used by hobbyists with two of the biggest OS platforms in the world either. You're either a delusional hobbyist or a complete and total fossil if you believe otherwise. >>89928 Landlock is a push in the right direction, but it's incomplete for now, you can't use it on UDP sockets yet for example. I also doubt that Linux developers will immediately eat their vegetables and use it when it's ready.

>>89929 So you're happy with the status quo. Keep enjoying your bloated, ad-infested mobile slop then.

>>89938 As just to make it clear, the DS was just an example. It can't make calls, so it's obviously not a viable phone. The POINT is that the hardware requirements to create any application that people ACTUALLY need, is very low and the iPhone 5s is well within that point. Programmers just have to be competent enough to work within those limitations. Increasing how powerful phone hardware is, has not resulted in any meaningful benefit to end users. It literally just 1. provides an excuse to sell people the same product 2. enables poorly optimized code and more ads

I wonder why Linux became the basis of Android. Why didn't OpenBSD or FreeBSD become basis for a mobile operating system yet? I know BSD systems are used in game consoles and various electronics so why has there been no phone version? Or why not Minix?

>>89944 Java. Linux had official java support, android userspace & apps are based on modified java. Android was following the trend of flip-phone java.

>>89948 Huh I didn't know there would be an actual reason rather than just something more random than that.

New Linux phone from Jolla accepting preorders now https://commerce.jolla.com/products/jolla-phone-preorder

>mobile dumb client >connects to home server or "the cloud" >apps run in a sandboxed user environment on server >hardware acceleration on client Can somebody explain why the entire OS for a mobile device needs to be on the local client? I fully expect that in the not-to-distant future you won't even need a unique device. The devices will mostly be generic and interchangeable. Just a terminal to access your user space. You will own nothing and be happy.. Yeh just a bunch of mobile clients strewn about everywhere like those god damned scooters. You'll be tripping over them. Just pick one up as needed, stick it in your ass for a biometric rectal scan and you'll be logged in right where you left off. Tokens will automatically be deducted from your USPS custodied wallet per use. AI generated uou can text your AI generated mother to coordinate when you are going meet up and eat some AI generated slop. Skip it across a pond when finished.