Tweaking user-hostile OSes into user-friendly ones is impressive, but not sustainable. Even worse, it slowing us down from leaving Android entirely.
Look at the AdBlocker crackdown of Google Chrome. Every single chrome-fork has shut down MV2 extensions, even Brave is about to do it, because it is impossible to maintain features that complex on a browser that Google spends >$1B/year to develop.
Same story for /e/ and GrapheneOS, the day Google pulls the plug on source code releases, god knows how long they will last. We should focus our efforts on truly open platforms.
> Tweaking user-hostile OSes into user-friendly ones is impressive, but not sustainable. Even worse, it slowing us down from leaving Android entirely.
Not sustainable as opposed to what, exactly? Developing and maintaining a completely different mobile operating system? Focusing on truly open platforms sound nice in theory, but completely falls apart the moment you consider what people want to do with their phones compared to the developing resources available.
> Every single chrome-fork has shut down MV2 extensions, even Brave is about to do it
That's just wrong, there are other forks that still support MV2 extensions right now, and at least brave has no plans of shutting down MV2 extensions even after Google removes MV2 from upstream completely. It will certainly add maintance effort on brave's side, but they already patch a million other things that upstream doesn't support.
>Even worse, it slowing us down from leaving Android entirely.
There are zero OSes that are 1/ open source 2/ appropriate for phones 3/ with good hardware support. There's absolutely nothing. Running Ubuntu Touch isn't a viable option. Neither is postmarket, librem, tizen, they're all terrible. Security wise, for something as critically important in our lives as a smartphone, I am also not trusting any new pet project that won't be stable for 10 years.
Sure, you might be a poweruser that doesn't care about your phone burning its battery in your pocket after 1 hour because you know how to SSH on it from your watch and put it in sleep, but that's not a viable option. Leaving Android is suicide. A large part of its critical underpinnings are already into the kernel anyways, just disabled. (although a distro running binder could be a fun project). APIs are reverse engineerable generally speaking, except for the server part of play services. But then, if your issue is "my bank won't let me access their app without play services attesting me", I have great news, you won't even have an app for it on your new OS anyways, so it will not work by default. There's already not enough people working on GrapheneOS _or_ on mainstream linux OSes, what makes you think the sitation won't be ten times worse for your custom made mobile OS ?
>We should focus our efforts on truly open platforms.
Android is one, and that can never be taken away. Google pulls the plug ? cool, you're stuck on Android 17, which is centuries of work ahead of literally anything else in the open source community. Hell, for all the shit that Google is doing, they're still constrained by having to work with other vendors: the system privileged notification receiver is swappable at build time, the recent app signing/verification system also is, because Samsung wouldn't let them control it all.
I do agree, mobile OSS OSes are rough. My point is that we should help them instead of helping Google's toxic relationship. It happened with Chrome/Blink, and everyone already forgot that lesson.
About hard-forking Android, no one was brave enough (pun intended) to do that for Chrome, considering the insane complexity and engineering costs (>$1B/y). (Only Apple was able to affort it with Webkit/Safari, but they are in the ad business too.)
I kinda dont see how both of you cant be right. We need a mobile OS that google isnt involved in. Why not use pure open source android to do it. It can only be cheaper than making it from scratch, since it has alot of work already done on it
Building and maintainance cost are not linear, especially when you inherit legacy code. The AOSP codebase isn't great, is 4x bigger than the Linux Kernel, and full of "Ship now, patch later" mess.
But I agree that it is a significant endeavor. But the OSS community succeeded in similar projects before, and the current state of the Linux desktop makes me hopeful.
> you're stuck on Android 17, which is centuries of work ahead of literally anything else in the open source community.
It's far ahead, but at the same time, I think we shouldn't over-emphasise how much. Functionality at the beginning of a project's lifetime is way more important than incremental improvements (or just changes) made later, and thus while much more effort has been invested into Android, new projects primarily need to catch up when it comes to e.g. phone call support and stability, and won't have to redo a lot of the effort of e.g. implementing Material You 3 or whatever.
Which is to say that we're still years out from a viable competitor, but at the same time, there could be one five years from now, which is also not that long.
This is the sad part. I've resisted that slippery slope as much as possible. In part because of ideological reasons, and in part for usability reasons. I have large hands and poor eyesight - using a phone for non-trivial tasks is tedious. I think the only thing I encounter from time to time that requires a smartphone is paying for parking. Everything else I do from a desktop, or don't do at all (doom-scrolling etc.)
I wish society would resist the smartphonification of everything for no reason. A lot of it is marketing- and surveillance-driven.
I appreciate that there are people out there working on stuff like /e/OS, but the number one question I have when I learn about a mobile OS that isn't iOS or "Googled" Android is: will the banking and payment apps I need to operate in the modern world run on this OS?
A lot of people don't think this way because they haven't had any problems. But then one day it happens to you and you realize, ok, this is the one thing that matters - you're in a cashless store and the only way you can pay for your meal is to use Approved Apple or Approved Google operating systems.
Where I live, the app my electricity utility provides for viewing and paying my account DISABLES ITSELF FOREVER if you so much as enable USB debugging on your phone (even after you've disabled it again).
To their credit Graphene maintains a global database of which of these apps work and don't. They're the only ones I know of so a thousand upvotes to Graphene OS.
But for my banks, the records in that database are grim. They won't run on Graphene, and they don't respond to reports about it.
One of my banks just discontinued its web UI because "people don't use it anymore, they use the app only."
This is how they're going to get us, folks. This is how we're going to lose it all. Writing code alone will not solve this. It will require some kind of collective action to defend our liberties. Some parts of the world are already lost. So this situation will likely come to a jurisdiction near you eventually: to make a transaction you will need permission from Google, Apple, Visa, Mastercard, or it won't happen. Then that four company list will start to shrink.
> the app my electricity utility provides for viewing and paying my account DISABLES ITSELF FOREVER if you so much as enable USB debugging on your phone (even after you've disabled it again).
These are self-inflicted problems by these apps. Nothing to do with the OS. These apps simply don't work. Complain to the companies that push these broken apps to you.
Would you buy a microwave oven that kills itself if you play the wrong kind of music in your kitchen?
The problems may be inflicted by these apps but the reality is that in many cases you're stuck with them. Electric company freezes your account if you enable USB debugging? Well, you can't choose a new electric company. We can complain to these vendors all we want but they just ignore us.
So these problems become problems of the OS, not because the OS has a problem, but because it affects the reality of using the OS.
It obviously depends on where you live. In my country you certainly con choose a new electric company. I mention that because we really should use consumer choice to overcome these types of problems where we can. Ie if you can switch to a bank/electricity provider/whatever that has a less terrible app it’s really good to do so.
I promise your electric company accepts payments outside of an app on your phone. I further promise that other banks are available that don't have terrible apps. These problems are way more surmountable than you're painting them here.
Basically what you’re implying is that all the people working on Android derivatives like Lineage, Graphene, and /e/ coming together and working instead on a fully open source OS like a Linux mobile distribution would result in better outcomes and actually get us closer to a daily driveable open source environment phone operating system.
That’s analogous to saying that an automotive tuning shop that puts turbochargers and body kits on Toyota Corollas shouldn’t waste their time, and they should instead design and build their own sports car.
The level of effort difference between AOSP derivatives and a fully open source OS is massive.
> Even worse, it slowing us down from leaving Android entirely.
I appreciate the vibes where this is coming from, but does it really? I think that assumes that everyone that works on this would work on a true open source OS otherwise, and that if they did, that would result in us breaking free from Android where we otherwise wouldn't. I'm not confident about either of those assumptions.
Meanwhile I'll keep complaining to orgs that don't allow me to work through their website, and tell them that their app won't work on my phone.
There are more OSS devs active on Android ROMs than OSS devs working on independent mobile OSes. We are running out of time, and we are misallocating ressources.
It's like bailing out water from the Titanic. We should prepare the lifeboats instead.
And there are even more devs working on Windows. It's like we're actively drilling a hole into the Titanic.
The thing is that those people aren't "resources" that you can just "reallocate". And even if they were, two extra buckets weren't going to save the Titanic.
(GNU/)Linux on mobile is the true sustanable, independent OS. It relies on the existing, strong Linux development, natively runs existing Linux apps and guarantees you lifetime updates. What else do you need?
According to the website[0] I’d need 20+ hrs idle time, video recording, Bluetooth, and GPS.
I’m being gently snarky, of course, but the goal shouldn’t be an MVP that nerds who are deeply into privacy or FOSS or hate Google can tolerate - it should be something that disinterested normies could seamlessly and happily use.
Well, it idles for about 22 hours, can record videos, does multi-constellation GNSS and both classic and LE Bluetooth.
The way to make disinterested normies able to use it is to have lots of nerds capable of fixing various papercuts themselves switch already and contribute rather than complain.
Thanks for sharing! I hadn't heard of this before. IMO any competition in this space is good competition.
But the reality is that it's not quite that straightforward. Linux desktop is a perfect example of that. We have tons of nerds working on the Linux ecosystem. Many on distros meant to ease transition from Mac/Windows to Linux (like Pop OS).
But if I were to tell my mom to install Pop OS, she would look at me like I'm crazy.
In some ways, Linux has become "cool" — Steam Machine and Steam Deck run Linux, and they're popular. Unfortunately, they're popular within a niche, and even then, they're popular for only a slice of digital life. People don't do work on a Steam Deck and I can't imagine many doing work on a Steam Machine.
Mobile phones are completely different though because most people have one phone. And that phone needs to do everything they need it to do. It needs to run the apps they need. It needs to play the games they want. It needs to integrate into everything. And it also needs to look trendy, because smartphones have become a bit of a status symbol of sorts.
So, while I agree that us nerds must become part of the solution than the problem, it's not enough. We need buy-in from major service providers. We need marketing. That's all stuff that the typical nerd can't/won't do.
I'm considering to switch to your device and start contributing to gnome mobile soon! I'm interested in your experience, what do you like and dislike the most on it?
If mobile Linux runs through the same kind of tortuous adoption and rejection cycle that desktop Linux is still doing, then it's a non starter before it begins.
I've been happily using it on several phones since 2008 (and writing this on one of them right now), only two years shorter than on my desktops/laptops. "Non-starter" is in the eye of the beholder.
Brave said they'll try to maintain limited support for MV2 for only 4 specific extensions, but recommend Brave Shields as the go-to adblocker for the future. Google is about to remove most of the MV2 code from the codebase, which will explode the complexity soon.
Brave has perverse incentives to discontinue it because of their BAT crypto business model that rewards looking at ads.
Unfortunately even the fully open source Firefox isn't immune to the pressure from the advertising industry, with all their Google funding and their purchase of anonym.
I do, but even though they're not in the webpage itself and are as such not affected by the adblocker, brave still has an interest in the advertising industry. Many if not most of their advertising clients would use regular internet ads as well.
I can call Android user hostile. Most Banks and gov apps require play services nowadays, and Google is about to ban app installation outside of their store. Cherry on top, the play store is mostly adware junk. My parents phones are full of adware, bloatware, notification spam, it's almost worse than windows 11.
In your earlier comment you said that deGoogled Android alternatives are what's "slowing us down from leaving Android entirely", but that is not consistent with saying that most banks and government apps require play services.
If these apps cannot run on deGoogled Android, then deGoogled Android cannot be slowing us down from leaving Android because using deGoogled alternatives is as inconvenient for banking and government services as using a non-Android alternative would be.
As I explained elsewhere in this post, I got to this installer page by clicking on "Check device compatibility" on the https://e.foundation/e-os/ page.
So I was actually expecting a device listing page, not a WebUSB program.
That's a bizarre one. 'You need Chrome' is bad enough, which even the bloody NHS are guilty of, but I always assume that's 'just' an assumption that not Chrome means IE or something, and they haven't woken up even to the proliferation of mobile Safari users.
I didn't know it did, the commenter didn't mention it, and Imgur gave me an overloaded error message. (When it doesn't do that, it usually tells me it's not available in my region or that the image has been deleted anyway.)
Anyway, assuming it's for WebUSB flashing, I agree with other commenters it should just explain that's not available and still give the instructions - bonus points for hiding the unusable WebUSB option.
How do they do that? I'm not doubting that, it's an honest question. I understand how this works on Apple phones but I don't understand why an identity or attestation service cannot be replaced by another one by the alternative operating system when the hardware is not controlled by Google. Does Google have keys in tamper-proof chips? How else would those banks determine their apps are on the right phone? Or do those apps use Google authentication directly over the Internet, using hard-coded Google public keys?
Depending on the level of security you ask for Play Integrity, it can be:
* is this device rooted, is it an unsigned build ?
* Device is signed, but is it part of the blessed signing keys ? is play services untampered with ?
* Additional checks over the lifetime of the device.
You could fully trust the results of Play Integrity on device, but you can also send the returned token to your server, and your server then contacts play integrity to validate that token. So unless you know how to spoof those encrypted tokens, you won't go very far.
So basically an alternative OS can offer a service like Play Integrity and the only problem is that those banks hard-code a dependence on Google's Play Integrity and Google has a monopoly for that service?
This is something that could be addressed at least in the EU by mandating banks to allow alternative services or not use this service at all.
Chrome is just an example. Google stopped pretending Android is a general purpose OS and started cracking down on what is possible without Google’s approval. See developer verification, everything within Google services, etc.
> We should focus our efforts on truly open platforms.
But currently AOSP is very much open. That's also what the GrapheneOS devs say and why they want to continue using Android. Until it becomes clear that they will completely stop releasing the source code under a free software license i dont see why one should not use Android.
AOSP dev went private, and Google is slower and slower at releasing the source, now twice a year. Worse, many stock apps like the Dialer and Gallery went closed-source years ago.
But the source isn't the point, it's the governance. Just like Chrome, having the source is not enough to guarantee an open platform. Sure you can disable telemetry flags. But you cannot afford to maintain an important feature Google wants to remove, like MV2.
"Google built Android to be impossible to maintain without them."
Could be a very genuine answer to that question. Do you really need all of Android? What if you can build a very similar thing at a fraction of the size.
Building and maintainance cost are not linear, especially when you inherit legacy code. The AOSP codebase isn't great, is 4x bigger than the Linux Kernel, and full of "Ship now, patch later" mess.
But I agree that it is a significant endeavor. But the OSS community succeeded in similar projects before, and the current state of the Linux desktop makes me hopeful.
Everyone is excited (or scared) by vibe coded startups, but ask yourself, how many vibecoded apps do you use weekly ? Every single one I've tested looks great at first, but is an UX nightmare with awful performance.
Even worse, my founder friends are all churning slop prototypes with Claude Code with zero product vision and are going nowhere. Is this revolution just a mirage that is FOMO-driven ?
The daily scale is not statistically significant and is meaningless.
You should lower the confidence interval by either increasing the scale or the evaluations.
I think what is missing here is the growing trend of scammers convincing people they are their bank (or whatever) and walking them through enabling side-loading and then installing malware (sometimes to address some urgent security issues with their account).
This is meant to counter an actual issues that is affecting many many users.
If you can convince the user your are their bank, can convince them to install software and walk them through how to do it and enable side loading, you can also convince them to input their logging into any webpage.
If that was the only reason, they would proactively cooperate with alternative app-stores like F-Droid to allow them to provide a lesser friction flow for open source releases. My question would be why I they see themselves as the only possible trust anchor here. A high friction method to install a different app store, once, IMHO would be OK.
This is not simply an excuse. Android phones are prevalent in countries where smartphones offer the only realistic access to banking and cashless payments to the majority of the population. Scamming schemes targeting those users are also very frequent in many, if not most of these countries, and educating people about them is hard. Like it or not, this change is likely going to be a net positive for many people.
In the impacted nations people only use phones, and the local banking ecosystem is really focused on apps. I think most people would never think to use their bank website.
You cannot save these people by technical means. They'll just fall for something else instead.
The only one who can protect them is a family member or appointed guardian.
Or maybe, just maybe, we start doing something about the criminals and those who protect them. It's ridiculous how these industrial-scale scam operations are allowed to exist.
I have no trust in a solution that mostly benefits the proposer.
By all means let people curate and use safe lists of software, but let's not pretend that making the life harder for the few registries containing solely open source and vetted software is in any way about making people safer.
This solution clearly mostly benefits the ignorant phone users of the world who are susceptible to scams. There is a minuscule number of people sideloading Android apps on their phones compared to the greater population.
Like I strongly believe that sideloading should be possible on phones, I don't even do it myself anymore but it can be very helpful and is part of what makes the Android platform fundamentally more open than iOS. I was VERY opposed to their original idea of closing off sideloading altogether, but having to mark it in your settings manually seems like a very good compromise.
And many things have been done, including Windows telling you in bold red letters that this software is dangerous if it wasn't signed by a trusted signer with lots of installs.
Yes, but governments are getting involved because governments always like increasing control and reducing freedom; the "major problem" is merely a pretext.
Is the solution to make it harder? Or is the threat of scammers and the insecurity of the OS used as false flag to make installing software outside of the profitable walled garden much much harder?
I doubt that side-loading impacts revenue all that much. Alternate stores are the real, potential, risk to $.
I think the solution is to come up with a balance between the needs of different groups of users. People here see the phone as a general purpose computer they should be able to modify and use for all kinds of novel tasks. This is great, and should be fully supported.
But there are also many, many more people who see the phone as an important way to enable a higher standard of living. Giving them access to information, government services and banking for the first time. They are not technically sophisticated, and don't need or want a general purpose computer.
So, we need platform providers to come up with ways to work out who is who, and give each side what they need.
It seems you think what is missing here is some FUD, which is what I believe you are feeding us with here.
If there's anyone people need to be protected against, it's Alphabet and Apple and the entities they let in intentionally, rather than specter of "growing trend of scammers".
It's not a vulnerability necessarily, but "Display over other apps" permission allows malicious apps to intercept interactions like users entering passwords and trick them into performing actions (clickjacking).
This is revisionist history to make things sound scary and evil. The term sideloading was first published before Google existed.
Go to the XDA forums and search for the word "sideload". You can filter for results before 2020 if you like, you get hits going back decades.
It's been in common use since the day we got smartphones. The term dates back to the 1990s. I remember reading the word when I bought my HTC Evo at launch. It's an industry standard term and has been for longer than Google has existed.
You know this is the internet and anyone can fact check anything at any time? Including you!
Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email [email protected] and we'll look at the data.
You're infantilising the users. It's untrusted by Google, but it's trusted by myself. I actually trust the Termux and Kodi devs way more than Google, yet they Google has been blocking their updates.
Note that the term sideloading is exclusively used by mobile OSes. On Windows MacOS and Linux you can install anything.
What I'm talking about is actual trust. Like, there are cryptographic measures taken, certificates involved, code signing, that kind of thing.
You claim that you "can install anything" on Windows, but that is simply false. The system's Driver Signature Enforcement will prohibit the install of unsigned or invalid signatures on device drivers. Windows SmartScreen will also give you trouble by blocking unsigned apps.
So yeah, you can bypass these protective measures and "install whatever you want" ultimately, but it is basically the same process as sideloading on Android, isn't it? Disabling a bunch of protections that are there for your safety?
Your trust, honestly, doesn't mean jack shit. There is cryptographic signing, and certificate authorities, and processes to approve the certificates that authorized developers use. You don't got jack shit with your "trust" of Termux and Kodi. It means nothing to the end-user.
We do not work in "trust me bro" territory when it comes to signing software, anymore. I am sorry/not-sorry to say. It is very important to have a chain of trust that goes up somewhere above "goldenarm @ HN".
Cryptographic trust is a different thing than actual trust. The latter is what makes the world work, the former is a tool people occasionally confuse for the real thing, but actually is mostly opposite to it.
Look we are talking about computers here. Computers don't understand or exercise actual trust as you describe it. Actual trust doesn't make computers work at all, because it doesn't exist in their world. So you need a proxy for it.
The security vetting, the authentication, the scans that are done, whether by Google Play or by F-Droid, are a process that tries to eliminate egregious abuses and basically curate the collection so that the users have something to actually trust. Now you understand that actual trust comes in degrees, right? I don't trust everything on Play equally. There are plenty of different types of trust relationships between me and the Play Store and the devs who put their apps on it.
But cryptographically, cybersecurity-wise, we need that CIA triad, and we need to authenticate that developers are who they say they are. And that authentication is the crux of cryptographic code signing. That we can trust that updates came from the source, and not a 3rd party injection or supply-chain attack. If Google or F-Droid countersigns it, then it's been through their vetting process as well. That's how cryptographic signing establishes trust relationships for computers.
If your computer doesn't trust an app or a driver, it won't download, install or run it. Since you cannot teach a computer "actual trust" there must be an analogue to this. And it's working fine. I don't know what you're on about "opposite to actual trust". If you don't trust Google Play, that's a you problem.
> If you don't trust Google Play, that's a you problem.
When your lack of understanding is called out you devolve into rambling self-contradiction.
Two me, should I trust this app, that has “cryptography “ “security vetting “ “authentication” “scans” “code signing” etc on an App Store that you are praising ?
> We do not work in "trust me bro" territory when it comes to signing software, anymore. I am sorry/not-sorry to say. It is very important to have a chain of trust that goes up somewhere above "goldenarm @ HN".
If you so deeply believe in giving up user freedom and delegating control to authority maybe you are at the wrong place here, check the title of this website: "Hacker News"....
The inconvenient fact that bursts this bubble is that installing already is the default term, and it's the emergence of "side loading" which is the anachronistic attempt to redefine the term.
The idea that a precondition for something to count is installing is that it's vetted by a big company is the abberation, and the notion that it's trustworthy is belied by the avalanche of unsafe and privacy violating apps that find their way into the store. F-Droid apps are actually more carefully vetted than Play Store apps, so there goes the trust rationale.
The uneducated one here is the one who appears unaware that "installing software" was a thing long before app stores. Security is irrelevant to the meaning of the word, so continuing to go on about it only further devalues your point and does nothing to counter the OP's point.
So if you want to have a conversation about trusting curl and bash and random gists...
Like I said, I installed software in many ways back in the day. I typed it in; I loaded off cassette tape; I loaded off disk. One common denominator was loading from trusted sources. My Atari cartridges were store-bought and not homebrew. I went to B.Dalton mostly for the software, and got it shrinkwrapped from the publisher.
I had a number of classmates and colleagues who caught viruses and malware from loading and installing cracked software or untrusted programs... or even alleged porn, from shady sources. This is still a good way to get infected.
When I get on a friend's computer, I often have occasion to congratulate them for being uninfected, and it's nearly always because they "practiced good hygiene" in terms of loading only trusted software from trusted sources.
So you're correct, in that really nothing has changed. Back in 1983 you could certainly "sideload" crap from a pirate BBS and then suffer the consequences. And we all had choice words for people like that.
>Sideloading is a neologism to scare users and lawmakers, it just means "Installing software" and should be a basic right.
No it's not. The term originated far before this debacle, and carries a meaningful distinction than just "installing". Specifically it means installing from a non-first party source. You might not agree the restriction should exist, or that even the concept of first party source at all, but for communication purposes it's worth having a simple word to describe that concept, rather than something like "installing from a non-first party app store".
>No it's not. The term originated far before this debacle, and carries a meaningful distinction than just "installing". Specifically it means installing from a non-first party source
It's amazing how many confidently wrong people are springing up out of the wordwork to present revisionist history about the meaning of "install" like it's ancient wisdom. Pre-mobile computing treated "install" as neutral and primary and had no built in relation to centralized distribution. Sideloading as a term of art originally, in practice came into usage for transferring media to devices, and some cloud file hosts briefly used it to mean load a file to an online drive without downloading it to computer. It's usage was varied, irregular, and not at any threshold of popular acceptance for one meaning or another.
Windows, Dos, Linux, and online self-hosted services had no notion of "sideloading", or at least no usage of that vocabulary and did not use this notion of "install" that is now being retrospectively declared a longstanding historical norm. Even now, that's not a term used in Windows or Linux. Even Apple, who very much in practice utilize this controlled distribution model but even they don't use this sideloading/installing verbal distinction. In Apple's lexicon installing is neutral with respect to where an app comes from.
So it's staggering to see a specific term of art that deviates from historical precedent that only is used in an Android context and only relatively recently in the history of computing be referred to as if its observing a longstanding precedent across all of computing. It's nothing of the sort.
Oops, try taking a second look at your own links! I said "Sideloading as a term of art originally, in practice came into usage for transferring media to devices".
Your first link actually fits the description I gave, yet you're presenting it here as if unacknowledged.
Most of the usages you link to are in the paradigm of rom flashing or physical media data transfer, and don't even have the upshot of implying that "install" means download from preferred distributor, which is critical since that's what this whole thread is about. Hilariously, even your own links contain numerous casual references to "install" to describe the ordinary act of transferring files into the phone outside of the play store. Which is devastating for your point if your point is that sideloading is supposed to be exclusive term for that action, and that "install" has a long-standing and specific usage as meaning "distributed from Play Store."
Scattershot usage from people flashing ROMs or finding workaround hacks for hardware errors don't demonstrate that that vocabulary was as widely understood in the public consciousness as a settled meaning for sideload much less that the term install exclusively refers to downloading from the Play Store. And again importantly for this thread, it actually shows an evolution of the term that predominantly was about workaround hacks and rom flashing, which has now grown to comprehensively mean any installation of an app from outside the Play Store. If anything, that's a demonstration of a neologism.
And as a kid who grew up on Windows computers in the late '90s and early 2000s, it astonishes me that I have to say this but computing existed before 2009, and gives us a history from which we can draw when figuring out the established use of terms.
And again, as I already said, this sideload/install usage is unique to Android, not observed on Windows, Linux or even Apple. Giving me a bunch of links to a form of usage that I already accounted for in my own comment, and not addressing the more important part of my comment about the prevalence of install as a distribution neutral term, disregarding the history of computing prior to Android and outside of Android is an unfortunate misunderstanding of what your links do and don't say in this context.
>So it's staggering to see a specific term of art that deviates from historical precedent that only is used in an Android context and only relatively recently in the history of computing be referred to as if its observing a longstanding precedent across all of computing. It's nothing of the sort.
None of that refutes anything I said. You're basically arguing "back in the good old days, all installs were not from first party source and there was no distinction", but that doesn't mean no such distinction exists right now. Otherwise it's like arguing "immigration" is some "neologism" because back before the advent of the nation state, people just moved wherever, there wasn't random lines that turned "moving" to "immigration", and the word "immigration" is coined by statists that want to impose their worldview on the populace.
>but that doesn't mean no such distinction exists right now
A distinction only exists if people parrot the verbiage coined by corporations with a business interest in creating artificial moats. They have no obligation to, especially media outlets who have the right (and IMO responsibility) to use accurate vocabulary.
>How is that different from "installing software"?
It's easy to see this play out if try to replace "sideloading" with "installing software". If you apply it to OP's headline of
>Google confirms 'high-friction' sideloading flow is coming to Android
You get
>Google confirms 'high-friction' installing software flow is coming to Android
which isn't at all accurate. You still need the distinct concept of "installing software not from first party sources", otherwise it sounds like google is making it a pain to install all apps, which isn't the case.
Sure, you could argue it helps to express a distinction but that doesn't mean it has to live inside the verb install. Historically installing software was the general act and provenance was handled with qualifiers eg installing from "third-party sources", "manual install" etc. Android is alone among computing platforms in collapsing that qualifier into a new term that implicitly recenters the Play Store as the default meaning of "install."
In other ecosystems the store path is described as "store install" not the other way around. Android chose the inverse framing and that choice isn't neutral.
>Sure, you could argue it helps to express a distinction but that doesn't mean it has to live inside the verb install.
Right, which is why they used "sideload".
>In other ecosystems the store path is described as "store install" not the other way around. Android chose the inverse framing and that choice isn't neutral.
No, this is just being non-neutral in the opposite direction. Given the fact that installing from the play store is the default experience for the overwhelming majority of the user, calling it "store install" is even more obtuse.
"That’s why they used sideload" is exactly the point being contested. Historically, install was the unmarked, neutral verb for adding software, regardless of source. The distinction, when needed, lived in qualifiers about provenance. Introducing a new verb for non-store installs does more than merely describe a difference, it reassigns conceptual ownership of "install" to the store path.
And neutrality here isn't about mirroring current usage frequency (which is unique to Android and recent relative to the history of computing), it's about continuity with prior computing norms. Even when one distribution path dominated in practice, it didn't get to redefine the base verb.
How are "programming" "coding" and "developing" different? Is a "tap" different from a "click"? How about "swipe" vs "drag"?
Sometimes we use different words in different contexts. Language usually doesn't make logical sense. In mobile environments you sideload to get the binary onto the device and use the OS to properly install it. This dates from a time where putting the binary on the device was the difficult part. Devices didn't have standard ports or fast/free wireless data. You had to do something special to transfer the data.
In a lot of cases, installation was also a separate special process involving the command line. It wasn't always just tapping the install button.
> Specifically it means installing from a non-first party source
What "first-party" source? Apple invented out of thin air the notion of a "first-party" software source or that computer users can only install software approved by a central authority.
The idea the manufacturer of a product is a "first party" is BS.
You are the first party. If I own the device, I am the first party.
The manufacturer is now a second or third party after you own the device, and for most ideas, a third party, especially if they don't truly offer real support of the device.
This submission originally did link to https://ec.europa.eu/commission/presscorner/detail/da/speech..., but was later changed to this. Or two submissions (one for each URL) was linked/merged. But something used to link to the press release rather than this website, FWIW.
Also, about reducing it down to "an Ad for unofficial merch", isn't this literally the grassroot movement that led to what was announced today? Or am I getting the relationship wrong? The domain in question was registered 2024-10-09.
So correct me if I had way too little coffee, but that subdomain is under eu-inc.org meaning eu-inc.org is in fact the grassroot movement then? I don't understand the complaint, seems to be the right people? You're mad about that they also sell hats?
How can you maintain the rest of your argument when the entire basis for said argument been proven wrong? It's not "profiting from an ongoing news story" when they literally created what this news story is about!
That's not someone profiting from the news story. It's the website of the group of people who were pushing that, talking to the EU and lobbying for it for a while.
I agree they hyped the product too much, but contrary to Theranos, they did ship two products that actually moved AR tech forward. They just weren't efficient enough and the product market fit wasn't there. Even Apple is failing at AR.
I've noticed some OSS orgs have been shifting their center of gravity to europe recently. Notably the Eclipse, Linux Foundations, and soon WikiMedia.
VCs and politicians forgot that Silicon Valley did not appear out of thin air, it was the product of public research and open-source ecosystems that made the internet revolution possible.
If the US betrays these ecosystems too much, they could migrate and make another tech industry flourish somewhere else.
Look at the AdBlocker crackdown of Google Chrome. Every single chrome-fork has shut down MV2 extensions, even Brave is about to do it, because it is impossible to maintain features that complex on a browser that Google spends >$1B/year to develop.
Same story for /e/ and GrapheneOS, the day Google pulls the plug on source code releases, god knows how long they will last. We should focus our efforts on truly open platforms.
reply