Live data from Hacker News

What we talk about when we talk about sideloading

f-droid.org

291–300 of 646 posts

Re: What we talk about when we talk about sideloading

#291

You know, this would be a fantastic time for Google to get their sandbox in order. If we need to do it like this, go ahead and create a secondary user, call it sandbox and let me install all my wild and unapproved apps there. SecureNet can automatically fail in Sandbox. But I don't think they're going to do that, ultimately users who actually care about this are an absolute tiny percentage of the market. And weirdos…

I haven't tested it myself, but as far as I know you can run ADB in the phone itself via Termux. Perhaps it's possible to make a wrapper that install apps from F-Droid with ADB? It would mean that you would only need to be tethered to the your PC once. Obviously they'll eventually remove this because Google is hostile to things like ReVanced / some spook wants this power.

ADB using two Android smartphones and Termux (https://github.com/termux/termux-app):

* Search for "Smartphone-1 to Smartphone-2" "adb tcpip 5555" in "Motorola moto g play 2024 smartphone, Termux, termux-usb, usbredirect, QEMU running under Termux, and Alpine Linux: Disks with Globally Unique Identifier (GUID) Partition Table (GPT) partitioning": https://old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_mot... (old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_moto_g_play_2024_smartphone_termux/)

* Search for "termux-adb" in "Motorola moto g play 2024 Smartphone, Android 14 Operating System, Termux, And cryptsetup: Linux Unified Key Setup (LUKS) Encryption/Decryption And The ext4 Filesystem Without Using root Access, Without Using proot-distro, And Without Using QEMU": https://old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_mot... (old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_moto_g_play_2024_smartphone_android_14/)

Re: What we talk about when we talk about sideloading

#292
post #193

Earlier quoted context omitted.

The number of people that don't even own a general purpose computer is huge. And for those that do, ADB is a ridiculous thing to get setup for a particular device. I get paid to work on android software, and I don't even want to put up with the hassle.

you don't need a computer to run adb. there's install with options

For now

Re: What we talk about when we talk about sideloading

#293

I think we could set the bar substantially higher. Don't even bother with discussion of sideloading. Talk about bounded transactions and device control. What is needed is: Once I have purchased a device, the transaction is over. I then have 100% control over that device and the hardware maker, the retailer, and the OS maker have a combined 0% control.

People always say things like these, and I wish it were that way too. Maybe if history had gone a little differently. But what's the point of defining these standards now? Is the world where this is the reality still feasible? It seems nearly impossible, unless you're an extremely wealthy and influential individual. What I'm seeing is that we never will move to a world where a device that you bought is truly "yours"…

I said it elsewhere in the thread, but the current model is already falling apart: it has led to random IoT devices becoming parts of widespread botnets, affecting Internet functioning, and putting unwitting consumers at risk.

Fixing that problem might turn out to be cheaper for competitors by making their platforms more open and avoiding the full responsibility as a vendor.

Basically, combine current and future legislation about electronic waste, cybersecurity of IoT and connected devices, and the carve-outs for free software and open source platforms, and suddenly it becomes much cheaper to ship a product that will run for 20 years (say a washing machine) if you as a vendor can guarantee some of this for the warranty period (1-5 years), and open up the platform to consumers and shift the responsibility at that point. Also imagine the case of a vendor going under which needs to be covered too (this would make subscriptions infeasible too).

If legislation demands this (imagine no insecure devices for 20 years), markets will do the rest.

Re: What we talk about when we talk about sideloading

#294
post #193
post #182

Earlier quoted context omitted.

Forcing ADB may as well be a ban, if you don't see that, you're pretty out of touch with consumers. Sideloading is already hard enough for many, forcing the use of an extra computer, a dev tool in the CLI, and dev mode is way way outside what people will do

The number of people that don't even own a general purpose computer is huge. And for those that do, ADB is a ridiculous thing to get setup for a particular device. I get paid to work on android software, and I don't even want to put up with the hassle.

Yes. And a bigger question is, why should I have to? This is a perfectly functional computer, it is more than capable of downloading a file and running it.

It's really sad that Apple and Google (and to some extent MS though they're just behind in this race to the anti-consumer bottom) happened upon this "solution to malware" (note: not a real solution) of "OS vendor vets and controls all software." It's a lazy way, it's an ineffective way, and it has made computers - incredibly flexible, programmable devices - more like cable boxes or telephones from past decades, that you had to rent from a monopolist and had no control over.

Re: What we talk about when we talk about sideloading

#295

Earlier quoted context omitted.

I haven't tested it myself, but as far as I know you can run ADB in the phone itself via Termux. Perhaps it's possible to make a wrapper that install apps from F-Droid with ADB? It would mean that you would only need to be tethered to the your PC once. Obviously they'll eventually remove this because Google is hostile to things like ReVanced / some spook wants this power.

ADB using two Android smartphones and Termux ( https://github.com/termux/termux-app ): * Search for "Smartphone-1 to Smartphone-2" "adb tcpip 5555" in "Motorola moto g play 2024 smartphone, Termux, termux-usb, usbredirect, QEMU running under Termux, and Alpine Linux: Disks with Globally Unique Identifier (GUID) Partition Table (GPT) partitioning": https://old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_mot... (old.r…

It's not necessary to use two phones, see https://news.ycombinator.com/item?id=45740033

Re: What we talk about when we talk about sideloading

#296

Author here. I admit I am rather startled by the tone of many comments here and the accusations of disingenuity. Splitting hairs about the origin of the term "sideload" does not change the fact that those who promote the term tend to do so in order to make it feel deviant and hacker-ish. You don't "sideload" software on your Linux, Windows, or macOS computer: you install it. You have the right to install whatever you…

Sorry about this. This hairsplitting is common on HN comment threads. We lose track of the main theme and nitpick at great length on some word.

.. A grateful F-Droid supporter and user.

Re: What we talk about when we talk about sideloading

#297
post #78

Earlier quoted context omitted.

> You don't want software updates? Most of the time, software updates remove features, change things around for no good reason (breaking our workflows), or add unwanted features. We really should separate pure bugfix updates (which include security updates) from feature updates. We nearly always want the former, but not necessarily the latter.

So much this. I totally want security fixes, but I only want security fixes. I don't want UI changes, features removed or altered, or anything with my usability upset. My computing devices are tools I use to do my job and run my life. I don't want those tools changing without my consent.

Unfortunately, even for desktop software, this has shifted today: you can hardly get a security update without a feature upgrade too.

Except in cases like Debian (or Ubuntu LTS main collection, Redhat distribution...) which assumes the burden of backporting security fixes to a stable collection of software.

Re: What we talk about when we talk about sideloading

#298
post #47

Earlier quoted context omitted.

Maybe I do, maybe I don't. It's for me to decide what updates I want, if any. Apple and Microsoft do not give you a choice. Precisely zero people wanted Copilot on their computers, but it's there anyway whether you want it or not.

You can choose not to update in both Android and iOS. Same with running Windows.

Security bugfixes are tied to feature upgrades, unfortunately.

Re: What we talk about when we talk about sideloading

#299

Author here. I admit I am rather startled by the tone of many comments here and the accusations of disingenuity. Splitting hairs about the origin of the term "sideload" does not change the fact that those who promote the term tend to do so in order to make it feel deviant and hacker-ish. You don't "sideload" software on your Linux, Windows, or macOS computer: you install it. You have the right to install whatever you…

[flagged]

Re: What we talk about when we talk about sideloading

#300

Earlier quoted context omitted.

Leds are already awful. I already lost 4 of 10 led light bulbs I boughtast year. I hope they will be replaced. It's because every led bulb has a small transformer inside and it fails quite quickly

It depends a lot on the bulbs. When we moved into our current house 11 years ago, we replaced everything with LEDs. Many of those original bulbs are still going strong, including all of the 20 or so integrated pot lights we put in to replace the old-school halogen ones. Others died within a year, and replacements have been similarly hit and miss. To some extent you get what you pay for; most of the random-Chinese-bra…

> as do anything installed in an enclosed overhead light fixture, due to heat buildup

This is my problem. My house has a lot of enclosed overhead light fixtures, and LEDs just do not last long in them. And renovating all of them to be more LED friendly would be quite expensive.

Post reply on HN