Live data from Hacker News

A faster heart for F-Droid

f-droid.org

101–110 of 231 posts

Re: A faster heart for F-Droid

#101

Earlier quoted context omitted.

A super duper secure locked cabinet acessible only to them or anyone with a bolt cutter. You want to host servers on your own hardare? Uh yikes. Let's unpack this. As a certified AWS Kubernetes professional time & money waster, I can say with authority that this goes against professional standards (?) and is therefore not a good look. Furthermore, I can confirm that this isn't it chief.

Colocation is when you use your own hardware. That's what the word means. And you're not going to even get close to the cabinet in a data center with a set of bolt cutters. But even if you did, you brought the wrong tool, because they're not padlocked.

Bolt cutters will probably cut through the cabinet door or side if you can find a spot to get them started and you have a lot of time.

Otoh, maybe you've got a cabinet in a DC with very secure locks from europe.... But all are keyed alike. Whoops.

A drill would be easier to bring in (especially if it just looks like a power screwdriver) and probably get in faster though. Drill around the locks/hinges until the door wiggles off.

Re: A faster heart for F-Droid

#102

Earlier quoted context omitted.

You can't just host servers in your own basement! You need to pay out the ass to host servers in some big company's basement!

I don't have a problem with an open source project I use (and I do use F-Froid) hosting a server in a basement. I do have a problem with having the entire project hosted on one server in a basement, because it means that the entire project goes down if that basement gets flooded or the house burns down or the power goes out for an extended period of time, etc. Having two servers in two basements not near each other w…

What do you think would happen if that server went down? People can't get app updates, or install new ones. That is all. That is not critical.

They can then probably whip up a new hosted server to take over within a few days, at most. Big deal.

They are not hosting a critical service, and running on donations. They are doing everything right.

Re: A faster heart for F-Droid

#103
post #44

Earlier quoted context omitted.

> It makes it sound like a very amateurish operation. Wait until you find out how every major Linux distributions and software that powers the internet is maintained. It is all a wildly under-funded shit show, and yet we do it anyway because letting the corpos run it all is even worse.

What do you mean by "major distribution"? e.g. AS41231 has upstreams with Cogent, HE, Lumen, etc... they're definitely not running a shoestring operation in a basement. https://bgp.tools/as/41231

[deleted]

Re: A faster heart for F-Droid

#104
post #6

So.. what kind of hardware did they buy?

Yeah kind of conspicuously absent! They said > The previous server was 12 year old hardware which is pretty mad. You can buy a second hand system with tons of ram and a 16-core Ryzen for like $400. 12-year old hardware is only marginally faster than a RPi 5.

> 12-year old hardware is only marginally faster than a RPi 5

My 14yo laptop-used-as-server disagrees. Also keep in mind that CPU speeds barely improved between about 2012 and 2017, and 2025 is again a lull https://www.cpubenchmark.net/year-on-year.html

I'm also factoring in the ability to use battery bypass in phones I buy now because they are so powerful, I might want to use them as free noiseless server in the future. You can do a heck of a lot on phone hardware nowadays, paying next to nothing for power and no additional cost on your existing internet connection. A RPi 5 is that same ballpark

Re: A faster heart for F-Droid

#105
post #36
post #29

Earlier quoted context omitted.

That looks cool, which might just be the point of your comment, but I don't think it actually changes the argument here. You still have to trust the app store to some extent. On first use, you're trusting f-droid to give you the copy of the app with appropriate signatures. Running in someone else's data-center still means you need to trust that data-center plus the people setting up the app store, instead of just the…

F-droid makes the most sense when shipped as the system appstore, along with pinned CA keychains as Calyxos did. Ideally f-droid was compiled from source and validated by the rom devs. The F-droid app itself can then verify signatures from both third party developers and first party builds on an f-droid machine. For all its faults (of which there are many) it is still a leaps and bounds better trust story than say Go…

None of this mitigates the fact that apriori you don't know if you're being served the same package manifest/packages as everyone else - and as such you don't know how many signatures any given package you are installing should have.

Yes, theoretically you can personally rebuild every package and check hashes or whatever, but that's preventative steps that no reasonable threat model assumes you are doing.

Re: A faster heart for F-Droid

#107
post #70
post #17

Earlier quoted context omitted.

As someone that has run many volunteer open source communities and projects for more than 2 decades, I totally get how big "small" wins like this are. The internet is run on binaries compiled in servers in random basements and you should be thankful for those basements because the corpos are never going to actually help fund any of it.

It's a shame mozilla wont step up to fund it. They've spunked way more money on way dumber things.

Imagine the good they could do if they didn't pay their CEO 6 million a year.

Re: A faster heart for F-Droid

#108

I think all the criticism of what F-Droid is doing here (or perceived as doing) reflects more on the ones criticising than the ones being criticised. How many things went upside down and all the "right" things were done (corporate governance, cloud native deployment, automation, etc.). The truth is none of these processes are actually going to make things more secure, and many projects went belly up despite following…

Not to mention this is a build server, its uptime isn't actually all that critical, assuming they then mirror the artifacts out from there.

Not to mention it also simplifies the security of controlling signing keys significantly.

Re: A faster heart for F-Droid

#109
post #75

> this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access. I can’t be the only one who read this and had flashbacks to projects that fell apart because one person had the physical server in their basement or a rack at their workplace and it became a sticking point when an argu…

The OSU Open Source Lab gives machines to groups in their datacenter: https://osuosl.org/services/hosting/ It has hosted quite a few famous services.

Which famous services?

I doubt OSU is going to host F-Droid. It doesn't even sound like F-Droid would want them to host it.

Re: A faster heart for F-Droid

#110
post #101

Earlier quoted context omitted.

Colocation is when you use your own hardware. That's what the word means. And you're not going to even get close to the cabinet in a data center with a set of bolt cutters. But even if you did, you brought the wrong tool, because they're not padlocked.

Bolt cutters will probably cut through the cabinet door or side if you can find a spot to get them started and you have a lot of time. Otoh, maybe you've got a cabinet in a DC with very secure locks from europe.... But all are keyed alike. Whoops. A drill would be easier to bring in (especially if it just looks like a power screwdriver) and probably get in faster though. Drill around the locks/hinges until the door w…

I'd go with a drill -- but I'm not sure what possible threat vector would have access to the cabinet who would be able to get to the cabinet in any decent data center.
Post reply on HN