Comment by tdeck
9 months ago
I've got to say, some of the comments here are pretty funny.
> "The sideloading restriction is easily solved by installing GrapheneOS"
> "Unless they block ADB, I wouldn't say it's accurate to claim they're "blocking sideloading"".
Not to pick on these folks but it's like we on HN have forgotten that ordinary people use phones too. For some of us, it's not a limitation as long as we can solder a JTAG debugger to some test pads on the PCB and flash our own firmware, but for most users that's just about as possible as replacing the OS.
There was some Ubuntu (or Linux) forum where I had asked a question and I wanted an app or something (I can't recall now) which was easier to use and do repeatedly. Most of the people were replying with stuff like "why can't you just do <something that involves lots of CLI and more than an hour ro so>" or on the lines of it.
I, someone extremely new to Linux (hell, new to computers), was bewildered. Then a commenter replied with something that helped me and exactly what I needed. He added a note directed towards others which went something like - the battle for Linux as THE desktop OS was sabotaged by its most ardent practitioners.
This definitely happened with Arch. For some reason they killed the noob guide (which I helped maintain). It was a great guide that helped people go from noob to kinda knowing linux.
You can't have wizards without first having noobs.
Why gatekeep people from enjoying the same thing you enjoy?
Well, I guess all that gave us EndeavourOS and Manjaro. But still, we need more places for people to learn that nitty gritty stuff.
Hell, I'd love to learn more about the hardware hacking the OP is talking about. Love to learn about those GPU hardware modifications people do. I know it's hacker news, but I'd actually love to learn about that hacker stuff. If these companies are going to continue to fight this hard to prevent us from owning the things we buy, it sounds like an important thing to learn. Or else we're soon going to have robot butlers that are just sending lidar maps and high resolution photos of our homes back to these companies. We don't need elitest pricks, we need wizards teaching noobs
Regarding gatekeeping, there was one webforum I used to visit when I was a kid, which I think approached this in an interesting way. Most of the boards were available to the public, general users could post in them (other than the one that announced rules of course), but there was a subforum which could only be accessed by those who had demonstrated some minimum level of competency. Specifically this was a forum about programs for bots for a for-kids MMO (said MMO didn’t really have PVP that depended or gear or levels or anything, or a way of trading items or anything like that, so there wasn’t any player economy. So I think these cheats were pretty harmless. Well, except for the people making bots move in arrangements to make offensive symbols.). The process was, one could submit a program one had made that did something interesting, and they would judge whether it was sufficient to be allowed in to the subforum.
I think this had the benefits of:
• allowing people who don’t want to bother with newbies to not have to, if they stay in the subforum
• still having the places for “people who are skilled and willing to work with/help newbies” and “people who are skilled but don’t want to deal with newbies much” be in a sense the same place, while also having the place for the latter be the same as a place for newbies.
• provides an incentive for newbies to become skilled.
_____
Of course, this method doesn’t work if no one is willing to engage with the newbies. But I think it’s probably fine/reasonable to keep outsiders away from a few things provided that there is a reasonable path in.
Though, I’m not advocating that the approach that forum used be implemented everywhere. I just think it is something that a community could reasonably choose, depending on their priorities.
2 replies →
Something I know from a past role is that teaching is demanding, and for any broad audience you've got to consider the range of different thought processes that you may need to provide your knowledge in different ways. As someone trying to increase my linux skills (and assess the best one for potentially migrating/supporting my parents) it doesn't help that a lot of linux documentation comes across as barebones, or very concise about the one way it's meant to be done with a certain distro (plus potentially outdated on an earlier version), and a general lack of explanations.
As example toy projects I'm trying to test out dnf-automatic because I'd prefer not to have the admin work of manually keeping on top of routine updates, but there's little feedback (although so far that's better than pacman on Arch which specifically expects atdmin), or learning why a distro has set up swap/zram/zswap the way they have, what the limits are on that config, how to measure what my system uses and if/how to adjust it. There's little guidance within the system to get you up to that level, and to open another can of worms the terminal-first approach in linux's DNA usually doesn't present anything but the bare essentials for whatever tool you're running, but any extra/wasteful information shown could nudge you where the next step is.
3 replies →
> Why gatekeep people from enjoying the same thing you enjoy?
That's an easy one to answer: they will eventually demand that Foo changes and remove things they do not like. It has happened to all media, it has happened to all software, you can be damn sure it will happen to something as modular as a Linux distribution.
8 replies →
> You can't have wizards without first having noobs.
But maybe some wizards feel miserable when they are forced to interact 95% of the time with noobs, instead of other wizards? Maybe they want a circle for themselves, as a basic human need?
1 reply →
Oh I am so pissed about the noob guide thing. I have intentionally removed my post about my bad interactions with the Arch community from my website, but if you're curious it's in the history: https://github.com/VegaDeftwing/OpGuidesHugoSrc/commit/dcc07...
The TL;DR: Arch gets harder year over year as the number of ways to setup/options for each piece of your system grows. Hell, even picking a bootloader among 10 options is confusing. A guide that just at least says "This is common for X, this for Y, the others are interesting and may be worth trying. If you don't want to investigate now, use X" Is DESPRATELY needed.
I tried to have that on my site, and a pretty high level arch forum admin came buy and told me to delete my website and made a PR just deleting the page. It was honestly one of the most rude and hateful interactions I've ever had online.
> Hell, I'd love to learn more about the hardware hacking the OP is talking about. Love to learn about those GPU hardware modifications people do. I know it's hacker news, but I'd actually love to learn about that hacker stuff.
This, I feel like ever since the fall of Twitter, a true hackerspace has been missing for awhile.
> For some reason they killed the noob guide (which I helped maintain).
Is it up or archived anywhere?
8 replies →
hear hear
Yet telling someone to open regedit, find some deeply-buried branch, create a new binary key, rename it to SetFocusRefreshTimeout and set its value to 0xFFFF is... desktop usability.
It's not, there is nothing essential a regular desktop user needs to edit in the registry directly. For better or worse, Windows has standard framework for things like GUI widgets, settings storage, installation paths. It might support decades of those standards, but I'm pretty sure you know that Linux kernel and Linux the distro are very different, and much more numerous, and logically do things differently.
1 reply →
Giving them a link to a msi that does that is pretty user intuitive.
3 replies →
>the battle for Linux as THE desktop OS was sabotaged by its most ardent practitioners.
Don't believe that for a second. Industry de-facto standards are a result of power dynamics, and the actual users of the thing wield orders of magnitude less power than they project. If a corporation like MS or Google wanted Linux desktop to happen, no amount of gatekeepers could actually hold the gates.
The reason why Windows is the de-facto standard is because Microsoft put a lot of behind-the-scenes work into making it a de-facto standard. I am meaning them sabotaging everything else, treating the status quo with the famous EEE, many business deals with governments to use it, put it in school curricula, having manufacturers preinstall it to PCs, and bend every piece of connected tech to Windows' direction - hardware drivers, computer games, specialty software, even the internet.
That is how Windows got its desktop users, and how Linux and others didn't really.
> Most of the people were replying with stuff like "why can't you just do <something that involves lots of CLI and more than an hour ro so>" or on the lines of it.
More than an hour? That's very strange, enough that I wonder if you had the right impression of things.
Usually the reason to go with command line is that even though it might be bewildering to look at, slamming in the command only takes a moment and you don't need to do any button-hunting.
It's a tradeoff, is what I'm saying. But you seem to be describing a situation where it's significantly worse in every way. Why would a bunch of people all be on that bad plan?
> More than an hour?
That's usually how long it takes me to get an FFMPEG command I'm planning to use more than once right
1 reply →
That may be. But the CLI guys have had the last laugh, no? An LLM can work through a terminal with decades of stability much better than it can poke around constantly changing product UIs.
What's needed is a Dropbox analogue for Linux -- something that doesn't do anything that isn't already possible, but that makes things that are possible accessible to non-specialists.
It looked like SteamOS was going to be a contender, but apparently not.
This is impossible by design. Decades ago there were some distributions that had this as a goal (e.g. Mandrake, Suse), they included an application similar to the Windows Control Panel to manage everything. But such applications can never reach into all the corners, unless the distribution is severely locked down. The example of this extreme is... macOS. And still, there are some cases where dropping into the command line is the better or even the only option.
Back on Linuxland, the userbase realized this about two decades ago, when Ubuntu launched. Having a nice default experience was considered better than having easy tweakability, because Ubuntu could also be configured to the fullest extent in the classic Linux way of reaching into the guts of the system and rearranging things to taste. Not that I would ever recommend tweaking Ubuntu too much, but it can be done.
What about the other end? Most people who like fiddling with Linux by reaching into its internals have settled on distributions such as Arch, where this way of managing the system is expected and thus the distribution works to ensure this experience is as easy and predictable as it can be, by providing a good happy path experience for common scenarios, and providing top-notch documentation for common and uncommon customization options, or minority hardware platforms and devices.
1 reply →
Does Android not fulfill that role already?
One reason that people often overlook is that it's much easier (and much less error prone for the user) to give an instruction that uses the cli instead of a GUI tool, e.g. if someone would ask how to add a new user who's in the usb group on Linux, I would always tell the person `adduser --ingroup usb [username] ` instead of giving the GUI instructions which are longer and depend on what desktop the person uses.
If you think a single add user command is comparable to things like use grapheneos or adb usb injection chains then you’ve missed the point here.
It once took me a few hours to get a printer working on Ubuntu, never again.
That problem plagues every OS. Fortunately, my 14 year old canon networked printer/scanner/fax works in fedora 42 without any configuration at all. As long as it sees it on the network. Scans too! I was surprised about the scanning lol.
The brother wifi laser printer I have works on everything without any installation at all. Windows, mac, linux, my phones.
To be fair, printers suck everywhere. I hate printers.
"... and just recompile the kernel!"
People in general are very bad at knowing what the average experience is. We almost all have a predisposition to perceive our experience as being approximately normal, or if not, not too far away from normal. This is especially exaggerated anywhere experts of a domain congregate. They adjust to a significantly biased frame of reference. And that results in opinions that don't fall anywhere within the galaxy of what's reasonable for the vast majority of users of a given thing.
[dead]
Do ordinary people side load at all? Assuming most people use the phone to do something else, and not for the sake of using the phone, after you get the apps you want/need, ordinary people are likely to just do the same thing/consume the same apps over and over.
Yes, my health relies on it.
I sideload a glucose monitor app that's not available through Playstore (it's FOSS and health is a tricky area with liability).
It's a fantastic app and the ability to sideload it is a major reason I use Android over iOS.
I also sideload a patched app of the Dexcom glucose reader OEM's shitty app to allow the data to be read by the better (sideload) FOSS app.
https://github.com/NightscoutFoundation/xDrip
https://www.patreon.com/byod/about?
Ok I'm not an ordinary person, I guess, but if I was I'd still use those apps and I know people who are ordinary and do so.
If I haven't prohibited him, I am pretty sure my 11 years old son would have installed dozens of pirated games and apps of dubious provenance on his phone.
But I am pretty sure that like any other teenagers since the beginning of time he obeys me, and has only rooted his phone for educational purposes.
His friends, though, I am not so sure.
When I was his age I had an old Android phone, but I couldn't play LAN with my friends because I couldn't sideload nor buy the game due to parental controls. I borrowed an extra phone from my friend and sideloaded the game there and we could play.
Yes. We download an apk file. And then install it after it giving it permission that it is ok to install unverified apks.
Some of the more savvy ordinary people even export apps as apk for other phones.
A lot of my non-techy friends have a sideloaded copy of spotify/youtube to get premium features for free. I think they just blindly follow some guide they find on tiktok.
Spotify uses something like the Play Integrity API to prevent access using modded APKs.
3 replies →
I installed fdroid on a friends phone and they use it install newpipe and keep it up to date, without having a tech savy friend around to download the apk relase from github.
They "sideload" apps on desktop, which we usually call "installing software". They would probably do it on a phone, too.
This!
It's crazy how we act like phones are dramatically different than other computers. An average computer user can go to a website, click "download" and then we think the average phone user can't do the exact same thing? It's the same people! They might be used to downloading from one location but it would be laughable to think they couldn't do the normal thing too
(To clarify, I mean apps. Things like GrapheneOS you're going to run into the same issues as expecting my grandma to install Linux. Might be doable but it isn't quite there yet)
2 replies →
I believe that the official DJI app required side loading on Android. Not sure if it still does.
Majority of users don't sideload any apps according to:
https://zimperium.com/blog/the-hidden-risks-of-sideloading-a...
You say that like 18% is just some rounding error.
About 1 in 5 users sideload?! That's not something to ignore
A majority do not, but the article characterizes it more positively:
Sideloading is a fairly popular practice. Our research indicates that 18.3% of mobile users globally engage in sideloading. In some regions, such as the Asia Pacific, the impact is as high as 43%.
A lot of Chinese apps still do. Mostly cause I guess they don't allow Google play store in China (? I think it's blocked, can't quite remember for sure)
> Do ordinary people side load at all?
Yes, usually when somebody calls them, pretends to be from the security department of their bank, and asks them to install an app to "catch the hacker who just stole $2000 from your account in the act."
In countries where Android is popular (not the US), this is an extremely common scam vector.
even though I've never seen this method in action, I have thought of it and it could be effective.
Everyone should side load the epic games, just to stick it to the MAN/Google
Installing the epic games launcher is just sticking it to yourself.
I love steam, but epic is very user hostile.
1 reply →
I've only side loaded my own app through Android Studio
edit: which I'm not even sure if that counts as side loading
it does
[dead]
And, worse, it isn't even true, right? As Google keeps adding more and more DRM tech to Android, along with APIs that let apps ensure they are running on "legitimate" software, installing GrapheneOS isn't even a viable option going forward unless you are effectively exiting the entire ecosystem anyway.
Apps have to choose to block using a non-stock OS and only a tiny minority of them do it. GrapheneOS bypasses it for many of them and we intend to get it fully resolved. Regulatory action is in progress for this in Europe already and it will be solved. GrapheneOS users can currently use nearly all Android apps with the exception of a subset of banking/financial apps and a tiny number of other apps. Google trying to crack down further will greatly increase the already incoming consequences in multiple countries for the existing Play Integrity API.
What regulatory action? I don't see any progress made legally.
Making it difficult for ordinary people to sideload apps that access their SMS or accessibility features (e.g. screen recording, controlling the phone) is the point.
I think what people on HN really forget is that the average person isn’t equipped to tell the difference between a legit source sideloaded app or a Trojan horse app that some TikTok video instructed them to install.
> Making it difficult for ordinary people to sideload apps that access their SMS or accessibility features (e.g. screen recording, controlling the phone) is the point.
I wonder if they could solve that with delays. E.g. you can sideload, but the process is deliberately delayed to take two full days and require carefully reading warning screens and correctly answering questions about the warnings, then getting time to think, multiple times.
Replying to everyone:
Google changing defaults is a permanent change for some large percentage of their userbase. A subset of those can still figure out how to download and run an APK file but have no further recourse against monopolistic behavior.
Maybe those people do need to be protected from scams. Social engineers have complete control over the user, so any control given to the user is owned by the scammer. Seems like the same problem as pig butchering, a technology or process solution can't save someone too stupid to save.
Thinking about less controversial options for Google, they could track if any side-loaded apps have the dangerous permissions, and provide a global true/false status to other apps that request it. So Wallet / whatever would disable features if any "outside" apps were in a position to exploit the user. And Android could offer a button that cleans up the "problem" apps, setting the global status back to false.
And official Android-based OS bring advantages too. For example, Samsung has lot of proprietary and useful features, and GrapheneOS you cannot use Google Pay (one major feature of a phone).
The primary reason why I haven't bought a Pixel and switched to GrapheneOS is because Samsung's OneUI is just so far ahead of the curve. They innovate new software features years before anyone else does.
I mean, Samsung and Xiaomi at this point pretty much just copy Apple, sometimes shamelessly.
5 replies →
Yes, you are right [regarding Google Pay].
That being said, it is a reasonable compromise that, as long as people know that beforehand, losing Google Pay as the price to loosen Google's grip on your data, location and preferences is an acceptable one [price].
> GrapheneOS you cannot use Google Pay (one major feature of a phone)
News to me. Edit: I misread parent comment.
Google Play != Google Pay.
2 replies →
> Not to pick on these folks but it's like we on HN have forgotten
The linked article is literally an ad for Librem phones though?
Fortunately the overlap between people that distrust centralization and those who have higher aptitude for overcoming is synergistic.
"Ordinary people" aren't sideloading apps one way or another. In fact this will help 99% of them, since for them sideloading is mostly used for malware and phishing.
GrapheneOS is totally normie friendly.
When we last got new phones I put GrapheneOS on mine and my partners, I never subsequently had to play tech support on hers.
And who's going to put GrapheneOS on an ordinary person's phone in the first place?
The Web installer [0] is not really approachable to a normal Android user. The instructions are dense, loaded up with warnings about dozens of edge cases that are discussed in jargon that would intimidate even relatively tech-savvy users:
What's USB passthrough? Did I install my browser through Flatpak or Snap? How would I know? Did I need to understand the paragraph explaining in detail how carrier models lock users in? There's a bunch of stuff in there about Linux... do I need Linux? What's a sha256 hash and do I need to care?
It's not that this is impossible for non-IT-folks to grasp, but there's no chance that my parents are installing this on their phone.
[0] https://grapheneos.org/install/web
It would be great if it were easier to setup but tech that works for normal users if someone gets in working for them is still useful. The first time I used Linux a guy at a meet up set up dual-booting and showed me the basics. Now I'm doing it for others.
You're right, but ironically the web installer is the most user-friendly way of installing Android. The GOS page simply documents technical aspects in great detail, but the actual process is no different from the stock web installer from Google[1]. It could easily be wrapped in a similar wizard-like UI without the technical jargon. The reason it's not is because the intended audience who would consider installing GOS is expected to be tech savvy, and they appreciate the details.
FWIW, GOS is an excellent project, but I don't think it's a good fit for non-technical users. But there's nothing stopping someone from creating a distribution of it with a preconfigured Google Play sandbox, some sane defaults and applications, to provide technical support, and to streamline the installation process, or even sell devices with it preinstalled. As long as that entity is trustworthy, it would be a good alternative for people who want to leave the Google/Samsung/etc. ecosystem, but don't have the technical knowledge or want to bother with installing and configuring GOS themselves.
[1]: https://flash.android.com/back-to-public
2 replies →
GrapheneOS can also be purchased preinstalled on devices regardless of what you think about the web installer.
It can be a non-binary option.
I have never installed OpenWRT on an home router -- too afraid to brick it, to deal with somewhat manual updates [I think].
I bought a GL.iNet. Totally normie, automatic updates. And then, "Hey look, this is... OpenWRT with a GUI!"
There are some [mobile] brands going on similar direction [albeit one that doesn't seem right to me]. Volla & Fairphone. They provide alternatives. I don't like them [the software options available for them], but alternatives exist, working out of the box.
If the web install guide only had to cover installing from macOS, ChromeOS and Android, it would be significantly simpler. Most of the complexity in the install guide is to work around issues with desktop Linux distributions. People do not need to read or understand the details about desktop Linux if they aren't using it. Similarly, people don't need to read or understand the details about installing a driver on Windows if they don't use Windows.
> There's a bunch of stuff in there about Linux... do I need Linux?
It's very clear about which browsers and platforms are officially supported at the top. Your complaint is essentially that we have not split up the guide based on install platform. That does make it more intimating, but doesn't have much impact on how easy it is to follow it.
> What's USB passthrough?
This is part of a paragraph telling people to avoid installing it from an OS in a virtual machine. This could be written in any guide about using a USB device. It's not specific to the web installer.
> Did I install my browser through Flatpak or Snap? How would I know? Did I need to understand the paragraph explaining in detail how carrier models lock users in? There's a bunch of stuff in there about Linux... do I need Linux? What's a sha256 hash and do I need to care?
People do not need to know about things only relevant to desktop Linux if they donj't use desktop Linux. Including instructions to work around desktop Linux problems doesn't make it harder for other people to install it. They simpler don't follow those parts of the guide because they don't use those things. It might make it less intimating to have it split up based on install platform but we haven't done that yet since we don't really want to have 5 or more web install pages instead of a single unified one. Another option would be selecting a platform with a drop-down menu and changing the guide based on it, but that's overly complex to maintain.
> It's not that this is impossible for non-IT-folks to grasp, but there's no chance that my parents are installing this on their phone.
Our experience shows that the vast majority of people can install it. The main reason someone couldn't is if English is their second language and they aren't capable of reading the instructions.
You're essentially asking for us to split out non-ChromeOS desktop Linux instructions from the guide due to how much of a mess working around it adds to the guide. That is something we could do along with splitting away Windows since it's also more complicated due to not having a USB driver. We don't think this would make it significantly easier to follow, but it would make it look easier. It is easy to follow the guide, especially on macOS, ChromeOS or Android. It's less easy on non-ChromeOS desktop Linux due to various issues with the overall platform, and the same for Windows to a lesser extent (installing a driver).
The reason the guide covers so much is because it covers all the common ways people have issues with their desktop OS or browser which impact following the guide. We added more information to the guide until people stopped needing help with installing it. People no longer typically need any help with it since we covered everything that comes up. Removing the information about troubleshooting and issues with platforms people use would make it harder and less accessible, not more. It's a good thing to have very detailed instructions covering all the edge cases and common issues.
I am legitimately glad for devs of graphene os and for it graphene working in your case but it is not functional if a user needs banking orr streaming apps, or any number of other impacted apps such as mcdonald's or pokemon go.... that is after installing the optional play services, reducing the privacy benefits of graphene.
I own no firsthand experience but read many users require app 2FA to make card payments.
The solution must be social-legislative. The London smog and terrifying auto deaths at 30 KPH were solved but not by niche enthusiast projects.
The vast majority of Android apps work on GrapheneOS. There are tap-to-pay apps including PayPal, Curve Pay and many European banking apps which work on GrapheneOS.
> that is after installing the optional play services, reducing the privacy benefits of graphene.
The only way to use Google Play services on GrapheneOS is via sandboxed Google Play. Sandboxed Google Play are regular apps with zero special access or privileges. They cannot do anything more than any other regular user installed apps. They do not have any access to user data, app data or more control over the device than other apps. They only have what other apps explicitly choose to implement through Google services, which apps can do without Google Play services too. Apps do not need Google Play to use Google services, and Google services are far from the most privacy invasive third party services used by lots of mainstream apps. Privacy from invasive apps is provided through features like our Contact Scopes, Storage Scopes, Sensors toggle, etc. Avoiding 1 particular set of services depended on by privacy invasive apps wouldn't solve that. Users need to carefully choose what to share with apps/services and take advantage of the provided privacy model improvements such as those features if they care about this but still want to use those apps.
> The solution must be social-legislative.
The solution to the anti-competitive Play Integrity API has to be regulatory/legislative but providing privacy and security almost entirely depends on technical improvements rather than laws/regulations which will be largely ignored and cannot solve an international issue without borders.
> niche enthusiast projects
GrapheneOS is a production quality OS made by a non-profit organization. It has a team of full time developers paid to work on it. It's very easy to install, can be purchased preinstalled on devices and has compatibility with the vast majority of Android apps. For most people, they don't have to make any major sacrifice to use it. Using a different app for tap-to-pay or using regular credit cards for it instead isn't really a big deal. There are only a few non-financial apps impacted. Several financial apps have recently explicitly permitted using GrapheneOS via hardware attestation and Block (Cash App, Square, etc.) is in the process of doing so.
Works for banking apps for me.
My phone is play store free, my SO's isn't. I agree having the play store isn't great for privacy but for the purpose of this thread it isn't relevant.
> but it is not functional if a user needs banking orr streaming apps
Huh? Banking apps not working on GOS are a rather rare exception (which I have not run into ever and I use several), and streaming apps work just fine. I "only" use Netflix & Amazon Prime but other people attest[0] to Disney+, Paramount, Max, and SkyGo working, too – even without Google services.
[0]: https://discuss.grapheneos.org/d/20256-streaming-apps/6
GrapheneOS is sold preinstalled on devices. People do not have to install it themselves. It's also far easier to install than a desktop OS via https://grapheneos.org/install/web.
The post from Purism is highly inaccurate and is inventing issues which are not real issues along with presenting a product which massive reduces security and app compatibility as somehow solving those things. Dropping mainstream app compatibility and support for the main open source app ecosystem entirely hardly solves a tiny number of apps enforcing using the stock OS.
They ordinary people would be the ones that need this level of protection, since a scammer would talk them into sideloading malware if the device permits it.
I mean, this website is also home to the famous Dropbox comment, so it is to be expected.
What comment?
https://news.ycombinator.com/item?id=9224
oh come on please it's easy just /etc/init.apt-get/frob-set-conf --arc=0 - +/lib/syn.${SETDCONPATH}.so.4.2 even my grandma can do that
[flagged]
It's important to note that the infamous Dropbox comment was not just misguided. It was wrong.
The proof is that multiple competitor products have been launched since, and all of them have had sync issues at some point, with different degrees of severity ranging from sync delays, through data conflicts, up to loss of data in all synced devices. To this day, I still trust Dropbox more than its competition. This includes custom rsync scripts.
Damn i didn't realize HN or DropBox was even around back then. I would've been in high school.
And in another year or two there are going to be people younger than this comment entering the workforce...
[flagged]
Murena has a preloaded fork.
Easy
No, Murena sells devices with /e/OS which is fork of LineageOS which drastically rolls back privacy and security compared to it. LineageOS itself rolls those back compared to the Android Open Source Project but not nearly as much as /e/OS. LineageOS would be a better choice for privacy, security, app compatibility and usability than Purism's product.
GrapheneOS and /e/OS are very different operating systems. GrapheneOS is a hardened OS with massive privacy/security improvements and a far different appropach to mainstream app compatibility. GrapheneOS can be purchased preloaded on devices including from companies like NitroKey, so that is not something that's a difference between them. GrapheneOS is based on AOSP directly, not LineageOS.
https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
https://grapheneos.org/features provides an overview of what GrapheneOS provides. It doesn't cover all of the features but it covers a lot of them.
/e/OS lags very far behind on shipping Android privacy/security backports, lags a year or more behind on shipping standard privacy/security patches and does not keep the standard Android privacy/security model or features intact. Like LineageOS, /e/OS mainly supports devices without proper non-stock OS support and without firmware/driver patches. For the few devices they support which do provide those updates, they are much worse than LineageOS at shipping them to users. They don't use standard hardware-based security features even when they're made available to an alternate OS. /e/OS is not a safe option because going months or even years without critical browser engine and OS updates is a serious problem. It is not an academic or theoretical issue. They are failing to patch critical issues and some of those are known to be exploited in the wild.
You can run nearly all Play Store apps on GrapheneOS, but not /e/OS with the much more limited and less secure microG approach. https://bsky.app/profile/grapheneos.org/post/3lamcjfv5r22s explains the difference in approach. Of course, their approach certainly provides dramatically more mobile app compatibility than using the desktop Linux stack on mobile as is being proposed in the original post.
Ok, now try sending RCS messages?
I use signal. Don't need.