Live data from Hacker News

What we talk about when we talk about sideloading

f-droid.org

591–600 of 646 posts

Re: What we talk about when we talk about sideloading

#591
My wife runs a clinic with about a dozen health care providers. They use a paging service that delivers pages to a phone app. It has to be a phone app because the shifts are 24hrs and the providers sleep when they can and need to be able to turn off all other notifications.

This costs about $12,000/yr and uses servers in the United States. Some of the staff work very part time, but still need a license at the same cost even if they only get one or two call shifts a month. The price ratchets up regularly.

There is competition, but nothing really better.

I could stand up an asterisk server and write a simple Android and iOS app for an ongoing cost two orders of magnitude lower (using existing infrastructure), but the app store impedance is too high to risk it.

I don't have the practical ability to confidently get an app into the Google play store and the Apple app store and keep it there.

The only viable alternative to bending over for these vendors for us is to go back to discrete pagers. It may come to that.

Re: What we talk about when we talk about sideloading

#592
post #432

Earlier quoted context omitted.

> Any device that doesn't have DRM will never support a paid digital marketplace Yet here am on linux buying games on steam

Steam is a bit different, since that originated as a PC digital marketplace before complete root-of-trust DRM from HW->bootloader->OS->SW. If anything, I would bet on a shift where Steam on Linux requires a signed OS like Windows Secure Boot. Call of Duty and Battlefield 6 already require Windows Secure Boot. Wait, a signed Linux OS with Secure Boot already exists. It's Android Play Protect. Also on Linux, you only g…

Shifting goalposts: you said there's no marketplace, I pointed out a highly prominent one, and your counterargument is… they don't count because other different things exist.

Re: What we talk about when we talk about sideloading

#593

My wife runs a clinic with about a dozen health care providers. They use a paging service that delivers pages to a phone app. It has to be a phone app because the shifts are 24hrs and the providers sleep when they can and need to be able to turn off all other notifications. This costs about $12,000/yr and uses servers in the United States. Some of the staff work very part time, but still need a license at the same co…

By the way, the system we used before this was an answering service where an actual human answered the phone and triaged the call.

It was cheaper.

We could go back to that, but no one wants a pager again.

Re: What we talk about when we talk about sideloading

#594
post #523

Earlier quoted context omitted.

Most of the software I use depend on centralized functionality. Example: convenient online invitation, sharing of resources and integrations (for productivity), accomplishments, ladders and updates (for games). For music media, there are a lot of people (67%) using streaming (random source: https://ifpi-website-cms.s3.eu-west-2.amazonaws.com/IFPI_GMR... ) which is a totally different service than having a list of son…

Regional pricing based on Purchasing Power Parity could be a solution. However, perhaps too many customers would use VPNs and pretend to be from the poorest countries on Earth.

Some technical solutions could be implemented, but I wonder if it is worth it? My claim is that probably 80-90% of the people that can pay, already do, because they get things they want in return (as mentioned with the online services connected to various things). We shouldn't make it completely easy to copy software, but the focus of companies would be to develop new useful things not to restrict platforms to police poor people or the few that like to steal.

In the end, I suspect that the platform companies know that - as an example Google probably gave Android without asking a lot in return - but what they need are excuses to restrict competition when they reached a dominant position.

Rather than proposing technical solutions to fix this invented issue, I would rather find the next challenger - that will start by being nice (same as Google did).

Re: What we talk about when we talk about sideloading

#595
post #557

Earlier quoted context omitted.

Librem 5 is in stock, and it's my daily driver. These phones are niche, because in discussion like this one, everyone is constantly saying that it's impossible to escape the duopoly and we're doomed.

A quad-core ARM A53 just isn't doing that device any favors, even for a Linux phone. If only they had included at least a couple of ARM A76 cores or something.

https://puri.sm/posts/the-danger-of-focusing-on-specs/

Re: What we talk about when we talk about sideloading

#596
post #543
post #506

Earlier quoted context omitted.

> You have the right to install whatever you want on your computer, regardless of whether that computer is on your desk or in your pocket. That's a hill I'll die on. I totally agree with that. BUT: > Splitting hairs about the origin of the term "sideload" does not change You can't start your article by splitting hairs about the meaning of the term, and then complain that people follow down that discussion :-).

Since you're someone who welcomes splitting hairs: "meaning" and "origin" are different things.

Agreed. But splitting hairs is splitting hairs.

Re: What we talk about when we talk about sideloading

#597
post #547

Earlier quoted context omitted.

> Did you live at a time where Internet was not a thing? You must be relatively young. Software existed before the widespread adoption of the Internet. > I remember very clearly buying software on physical media and never, ever "receiving" a single patch. You had to take action to receive them. They weren’t automatic updates like they are today. > I don't even know how that would have looked... "buy this floppy disk,…

> You must be relatively young. Did you read my comment at all? :-) > You had to take action to receive them. They weren’t automatic updates like they are today. Are you saying I was doing it wrong? > updates for Boeing 747s Oh I get it. Maybe we just weren't playing with the same toys :D

  > Did you read my comment at all? :-)
Did you read *MY* comment at all?!

Everything @mechanicalpulse said was accurate.

To answer @grishka's question (because it seems you also don't know)

  > What did that look like? 
Well I literally answered that in my comment!

  >>> Back when software came on physical media we still had patches. 
      We had patches that came through the internet AND WE HAD PATCHES THAT CAME THROUGH PHYSICAL MEDIA.
      THE ***LATTER*** MAKING IT ***HARDER TO PATCH.***
I broke it up and emphasized the key parts.

If you are going to accuse someone of not reading your comment you damn well better be reading the comments you're responding to.

  > Oh I get it. Maybe we just weren't playing with the same toys
Considering it was "harder to patch", yes, it does also mean "things often went unpatched." Mind you, this doesn't mean patches didn't exist nor does it mean, as you suggest, patches don't matter.

But again, I already addressed that in my original comment, so I'm not going to repeat myself again...

Re: What we talk about when we talk about sideloading

#598

Earlier quoted context omitted.

> You had to take action to receive them. What did that look like? Remember, back then, developers and users often had no after-sale communications at all. It was a technical impossibility more than anything. There was paper mail. There were telephone networks. That's about it. I suppose you could occasionally call the developers of every software product you're using to ask if there is an update. I doubt anyone ever…

> Remember, back then, developers and users often had no after-sale communications at all. They often had no pre-sale communications either, indeed no communication of any kind. It was just like buying a spatula or a pair of shoes. You went to a retail outlet and bought the software; the developer wasn't involved in the transaction at all. It was just the consumer and the retailer. Sometimes there was a postcard you…

  > but many people never registered.
Which leads to things not getting patched, more bugs, and more computers getting hacked. A great system...

I'll also add that if it was a big enough bug that it'd end up on the news and that's how people got informed. Otherwise, like you suggest, good luck. But it was possible.

It is baffling to me that we are having this conversation on Hacker News of all places. Aren't we a community of programmers? How in the world does any programmer think for a hot second that code is bug free? Last I checked formally verifying your code was 1) very rare and 2) still impractical if not impossible for anything of sufficient complexity. Unless we're formally verifying our code, I absolutely guarantee it has bugs. I know we have big egos, but egos so big that we think we're omniscient?

Re: What we talk about when we talk about sideloading

#599

Earlier quoted context omitted.

> Back when it came on physical media, it was very much finished. That's also not true and I think you're not reading my point fairly. Back when software came on physical media we still had patches. We had patches that came through the internet and we had patches that came through physical media. The latter making it harder to patch. It's a great situation when a bug is discovered and it is hard to patch. You're fant…

> we are not omniscient writers who can foresee all problems, fix all bugs, and write software that is unhackable We can come close to that in all other areas of engineering, but somehow not software? We can build buildings and bridges and be certain that they won't collapse. We can engineer machines that work reliably and safely. But for some reason we can't do the same for software? I call bullshit. > Hardware chan…

  > We can come close to that in all other areas of engineering, but somehow not software?
I worked as an Aerospace Engineer before I moved to software. What the absolute fuck are you talking about? Physically engineered stuff fails all the time.

Look, March of *THIS YEAR* (2025) SpaceX had a rocket *EXPLODE*[0].

Rapid unscheduled disassembly[1] does not indicate we can "foresee all problems and fix all bugs". In fact, it indicates the *exact opposite*.

There is absolutely no field where we've become omniscient. To think we are is just laughable! But if you want to know why physical engineering tends to be more robust, you might want to take an engineering class. You'll find that the way they do things is... a bit different... There's a lot more verification and testing.

  >> Software rots.
  > What the heck do you even mean by that?
It is an old, yet common, phrase that encompasses a wide range of issues that result in "no changes were made, but now the program doesn't work"[2]

[0] https://www.bbc.com/news/articles/cj92wgeyvzzo

[1] https://space.stackexchange.com/questions/10022/who-coined-t...

[2] https://en.wikipedia.org/wiki/Software_rot

Re: What we talk about when we talk about sideloading

#600
post #28

`abd install` will still work as per[0] so to me sideloading is still possible, so the statement 'Google’s message that “Sideloading is Not Going Away” is clear, concise, and false' is not correct. I think users should be able to install whatever software they want, without any charge or other external permissions, but at the same time device and OS makers should be able to make it difficult to do so, within reason.…

So are we going to download APKs from fDroid to our computers and then adb install them to our phones? For every update? I see a lot of people, even developers, giving up.

This is what people defending this are overlooking. While it may still be technically possible to sideload apps, the additional barriers to entry will be enough to push at least some app developers away from Android development. So while it is possible for some users to avoid direct impacts of this change, the overall fallout will be unavoidable.
Post reply on HN