Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A faster heart for F-Droid

f-droid.org

Post reply on HN
Print view View original

31–40 of 231 posts

Re: A faster heart for F-Droid

#31

Post by AndrewDucker »

skiing_crawling wrote: post #21
AndrewDucker wrote: post #12

Earlier quoted context omitted.

For a single server why would you use cloud services rather than go the self-owned route?

A "single server" covers a pretty large range of scale, its more about how F-droid is used and perceived. Package repos are infrastructure, and reliability is important. A server behind someone's TV is much more susceptible to power outages, network issues, accidents, and tampering. Again, I don't know that's the case since they didn't really say anything specific. > not hosted in just any data center where commodity…

Ah. I took "not just any data center" to mean "in a specific co-location facility where they trust the person responsible for it".

I agree that "behind someone's TV" would be a terrible idea.

Re: A faster heart for F-Droid

#33

Post by calgoo »

kiddico wrote: post #25
neogodless wrote: post #14

Earlier quoted context omitted.

I was able to find 2 x 16GB DDR4 for $150... Building a budget AM4 system for roughly $500 would be within the realm of reason. ($150 mobo, $100 cpu, $150 RAM, that leaves $100 for storage, still likely need power and case.) https://www.amazon.com/Timetec-Premium-PC4-19200-Unbuffered-... https://www.amazon.com/MSI-MAG-B550-TOMAHAWK-Motherboard/dp/... For a server that's replacing a 12 year old system, you don't need…

I don't think 32GB is going to be enough lol

Also, you would want ECC for something this important.

Re: A faster heart for F-Droid

#34

Post by wtallis »

PaulKeeble wrote: post #22

Modern machines go up to really mental levels of performance when you think about it and for a lot of small scale things like F droid I doubt it takes a lot of hardware to actually host it. A lot of its going to be static files so a basic web server could put through 100s of thousands of requests and even on a modest machine saturate 10 gbps which I suspect is enough for what they do. This just reads to me like they…

This isn't about a server for hosting the website or package repo, it's about the server building all the packages.

Re: A faster heart for F-Droid

#35

Post by Aurornis »

> 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 argument arose.

I know self-hosting is held as a point of pride by many, but in my experience you’re still better off putting lower cost hardware in a cheap colo with the contract going to the business entity which has defined ownership and procedures. Sending it over to a single member to put somewhere puts a lot of control into that one person’s domain.

I hope for the best for this team and I’m leaning toward believing that this person really is trusted and capable, but I would strongly recommend against these arrangements in any form in general.

EDIT: F-Droid received a $400,000 grant from a single source this year ( https://f-droid.org/2025/02/05/f-droid-awarded-otf-grant.htm... ) so now I’m even more confused about how they decided to hand this server to a single team member to host in unspoken conditions instead of paying basic colocation expenses.

Re: A faster heart for F-Droid

#36

Post by lrvick »

gpm wrote: post #29
lrvick wrote: post #19

Earlier quoted context omitted.

You actually do not have to trust the people who run f-droid for those apps whose maintainers enroll in reproducible builds and multi-party signing, which only f-droid supports unlike any alternatives.

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 Google Play. Developers can only publish code, and optional signatures, but not binaries.

Combine that with distributed reproducible builds with signed evidence validated by the app and you end up not having to trust anything but the f-droid app itself on your device.

Re: A faster heart for F-Droid

#37

Post by lrvick »

viraptor wrote: post #27
mcsniff wrote: post #13

Ugh. This 100% shows how janky and unmaintained their setup is. All the hand waving and excuses around global supply chains, quotes, etc...it took pretty long for them to acquire commodity hardware and shove it in a special someone's basement and they're trying to make it seem like a good thing? F-Droid is often discussed in the GrapheneOS community, the concerns around centralization and signing are valid. I underst…

> shove it in a special someone's basement They didn't say what conditions it's held in. You're just adding FUD, please stop. It could be under the bed, it could be in a professional server room of the company ran by the mentioned contributor.

100%. Just as an example I have several racks at home, business fiber, battery backup, and a propane generator as a last resort. Also 4th amendment protections so no one gets access without me knowing about it. I host a lot of things at home and trust it more than any DC.

Re: A faster heart for F-Droid

#38

Post by silisili »

Aurornis wrote: post #35

> 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…

Yup. But the same can happen in shared hosting/colo/aws just as easily if only one person controls the keys to the kingdom. I know of at least a handful of open source projects that had to essentially start over because the leader went AWOL or a big fight happened.

That said, I still think that hosting a server in a member's house is a terrible decision for a project.

Re: A faster heart for F-Droid

#39

Post by Aurornis »

a3w wrote: post #26
IshKebab wrote: post #5

Earlier quoted context omitted.

"F-Droid is not hosted in a data centre with proper procedures, access controls, and people whose jobs are on the line. Instead it's in some guy's bedroom." Not reassuring.

Depends on the thread model, which one is worse. State actor? Gets into data centre, or has to break into a privately owned apartment. Criminal/3rd party state intelligence service? Could get into both, at a risk or with blackmail, threats, or violence. Dumb accidents? Well, all buildings can burn or have an power outage.

> State actor? Gets into data centre, or has to break into a privately owned apartment.

I don’t think a state actor would actually break in to either in this case, but if they did then breaking into the private apartment would be a dream come true. Breaking into a data center requires coordination and ensuring a lot of people with access and visibility stay quiet. Breaking into someone’s apartment means waiting until they’re away from the premises for a while and then going in.

Getting a warrant for a private residence also would likely give them access to all electronic devices there as no 3rd party is keeping billing records of which hardware is used for the service.

> Dumb accidents? Well, all buildings can burn or have an power outage.

Data centers are built with redundant network connectivity, backup power, and fire suppression. Accidents can happen at both, but that’s not the question. The question is their relative frequency, which is where the data center is far superior.

Re: A faster heart for F-Droid

#40

Post by Aurornis »

silisili wrote: post #38
Aurornis wrote: post #35

> 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…

Yup. But the same can happen in shared hosting/colo/aws just as easily if only one person controls the keys to the kingdom. I know of at least a handful of open source projects that had to essentially start over because the leader went AWOL or a big fight happened. That said, I still think that hosting a server in a member's house is a terrible decision for a project.

> if only one person controls the keys to the kingdom

True, which is why I said the important parts need to be held by the legal entity representing the organization. If one person tries to hold it hostage, it becomes a matter of demonstrating that person doesn’t legally have access any more.

I’ve also seen projects fall apart because they forgot to transfer some key element into the legal entity. A common one is the domain name, which might have been registered by one person and then just never transferred over. Nobody notices until that person has a falling out and starts holding the domain name hostage.

Post reply on HN