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

151–160 of 231 posts

Re: A faster heart for F-Droid

#151

Post by pabs3 »

wtallis wrote: post #147
amrit3128 wrote: post #134

Earlier quoted context omitted.

the _if_ is doing a lot of heavy lifting there. You're free to complain about it but Fdroid has been running fine for years and I'd rather have a volunteer manage the servers than some big corporation

They quite notably haven't been running fine for years: https://news.ycombinator.com/item?id=44884709 Their recent public embarrassment resulting from having such an outdated build server is likely what triggered them to finally start the process of obtaining a replacement for their 12 year old server (that was apparently already 7 years old when they started using it?).

Its embarrassing that Google binaries don't even use runtime instruction selection.

https://wiki.debian.org/InstructionSelection

Re: A faster heart for F-Droid

#152

Post by wtallis »

gnufx wrote: post #69
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…

> commodity hardware Apart from the "someone's basement", as objected to in this thread, it also doesn't say they acquired "commodity hardware"; I took it to suggest the opposite, presumably for good reason.

> it also doesn't say they acquired "commodity hardware"; I took it to suggest the opposite, presumably for good reason.

This seems entirely like wishful thinking. They were using a 12 year old server that was increasingly unfit for the day-to-day task of building Android applications. It doesn't seem like they were in a position to acquire and deploy any exotic hardware (except to the extent that really old hardware can be considered exotic and no longer a commodity). I'd be surprised if the new server is anything other than off the shelf x86 hardware, and if we're lucky then maybe they know how to do something useful with a TPM or other hardware root of trust to secure the OS they're running on this server and protect the keys they're signing builds with.

Re: A faster heart for F-Droid

#153

Post by arjie »

lrvick wrote: post #45
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…

400K would go -fast- if they stuck to a traditional colo setup. Donations like this are rare and it may be all they get for a decade. Personally I would feel better about round robin across multiple maintainer-home-hosted machines.

I, personally, have a cabinet in a colo. With $400k, I can host it at that datacentre with the income from risk-free return never exercising the capital with 10 GigE, 3 kW of power. If I can do it, they can do it.

Modern computers are super efficient. A 9755 has 128 cores and you can get it for cheap. If you've been doing this for a while you'd have gotten the RAM for cheap too.

If I, a normie, can have terabytes of RAM and hundreds of cores in a colo, I'm pretty sure they can unless they have some specific requests.

And dude, I'm in the Bay Area. Think about that. I'm in one of the highest cost localities and I can do this. I bet there are Colorado or Washington DCs that are even cheaper.

Re: A faster heart for F-Droid

#154

Post by wtallis »

pabs3 wrote: post #151
wtallis wrote: post #147

Earlier quoted context omitted.

They quite notably haven't been running fine for years: https://news.ycombinator.com/item?id=44884709 Their recent public embarrassment resulting from having such an outdated build server is likely what triggered them to finally start the process of obtaining a replacement for their 12 year old server (that was apparently already 7 years old when they started using it?).

Its embarrassing that Google binaries don't even use runtime instruction selection. https://wiki.debian.org/InstructionSelection

Nah, if you actually read into what's available there, it's clear that the compilers have never implemented features to make this broadly usable. You only get runtime instruction selection if you've manually tagged each individual function that uses SIMD to be compiled with function multi-versioning, so that's only really useful for known hot spots that are intended to use autovectorization. If you just want to enable the latest SIMD across the whole program, GCC and clang can't automatically generate fallback versions of every function they end up deciding could use AVX or whatever.

The alternative is to make big changes to your build system and packaging to compile N different versions of the executable/library. There's no easy way to just add a compiler flag that means "use AXV512 and generate SSE2 fallbacks where necessary".

The people that want to keep running new third-party binaries on 12+ year old CPUs might want to work with the compiler teams to make it feasible for those third parties to automatically generate the necessary fallback code paths. Otherwise, there will just be more and more instances of companies like Google deciding to start using the hardware features they've been deploying for 15+ years.

But you already know all that, since we discussed it four months ago. So why are you pretending like what you're asking for is easy when you know the tools that exist today aren't up to the task?

Re: A faster heart for F-Droid

#155

Post by arjie »

Calzifer wrote: post #93
Aurornis wrote: post #39

Earlier quoted context omitted.

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

> Data centers are built with redundant network connectivity, backup power, and fire suppression. [...] The question is their relative frequency, which is where the data center is far superior. Well, I remember one incident were a 'professional' data center burned down including the backups. https://en.wikipedia.org/wiki/OVHcloud#Incidents I know no such incident for some basement hosting. Doesn't mean much. I'm just…

I'm not going to pretend datacenters are magical places immune to damage. I worked at a company where the 630 Third Street datacenter couldn't keep temperatures stable during a San Francisco heatwave and the Okex crypto exchange has experienced downtime because the Alibaba Zone C datacenter their matching engine is on experienced A/C failure. So it's not all magic, but if you didn't encounter home-lab failure it's because you did not sample the population appropriately.

https://www.reddit.com/r/homelab/comments/wvqxs7/my_homelab_...

I don't have a bone to pick here. If F-Droid wants to free-ball it I think that's fine. You can usually run things for max cheap by just sticking them on a residential Google Fiber line in one of the cheap power states and then just making sure your software can quickly be deployed elsewhere in times of outage. It's not a huge deal unless you need always-on.

But the arguments being made here are not correct.

Re: A faster heart for F-Droid

#156

Post by Bridged7756 »

Calzifer wrote: post #93
Aurornis wrote: post #39

Earlier quoted context omitted.

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

> Data centers are built with redundant network connectivity, backup power, and fire suppression. [...] The question is their relative frequency, which is where the data center is far superior. Well, I remember one incident were a 'professional' data center burned down including the backups. https://en.wikipedia.org/wiki/OVHcloud#Incidents I know no such incident for some basement hosting. Doesn't mean much. I'm just…

Surely "Juan's home server in basement burns down" would make the headlines. You're totally right.

Re: A faster heart for F-Droid

#157

Post by olyjohn »

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.

It doesn't say it's in someone's house. Maybe the guy runs a business doing this.

At least they know where it is. They can go knock on the door.

Re: A faster heart for F-Droid

#158

Post by olyjohn »

LoganDark wrote: post #72
0x1ch wrote: post #65

Earlier quoted context omitted.

You have two options. Colo if you still want physical access to your devices, or cloud, where you get access to nothing beyond some online portals.

Colo is when you want to bring your own hardware, not when you want physical access to your devices. Many (most?) colo datacenters are still secure sites that you can't visit.

I don't think so. I don't think anybody is going to hand off their server and ask someone else to hook it up. Also, you need access so you can troubleshoot hardware issues.

Re: A faster heart for F-Droid

#159

Post by vachina »

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…

There is nothing wrong with hosting prod at home. A free and open source project needs to be as sustainable and low maintenance as possible. Better to have a service up and running than down when the funds run out.

Re: A faster heart for F-Droid

#160

Post by vachina »

basilgohar wrote: post #61

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…

Exactly, if you run out of money, processes meant jackshit.
Post reply on HN