As a quick solution before implementing the more sophisticated suggestions in this thread, you can try getting a small cheap VPS from somewhere outside and trafficking all your traffic through it via sshuttle[1]. For example, Vultr (not an endorsement) has some with ~$3/month that should be sufficient for your case.
Merklemap is running PostgreSQL as the primary database, currently scaling at ~18TB on NVMe storage, and around 30TB of actual certificates that are stored on s3.
The backend is implemented in Rust (handling web services, search functionality, and data ingestion pipelines).
Bit of a side note for my fellow protocol enjoyers: this site is WhiteWind which is another app on the atproto network. Bluesky is a microblogging app on atproto while WhiteWind is a long form blogging app on the same network. It's pretty neat.
I'll never forgive SiFive for discontinuing the only blobless RISC-V machine (HiFive Unleashed) after shipping only a few thousand units (which they did only because Debian demanded it as a condition of adding support).
HiFive Unleashed ($999 - $1199) was made in no more than about 500-600 units.
HiFive Unmatched ($665) had several thousand units built.
Absolutely no reason to buy an Unmatched now even if you could because the VisionFive 2 (Star64, Mars) are slightly better in almost every way starting at 1/10th the price.
I'm now wondering how many decades are still being lost because of similar bugs in other OSes that don't get as much scrutiny, like OpenBSD or even FreeBSD.
I'm not going to say scheduling is better or worse on different platforms, but it is clearly different.
When I tried to port the (at that time) new, open-source version of .NET Core to FreeBSD, one of the things which I simply couldn't fix in the .NET framework code itself was threading. For one, I had to (for some reason, don't remember now) use non-posix threading-functions to make it compile. But even with that in place, things weren't behaving as expected.
I mean... Threading worked, but .NET had a fairly big test-suite which was very opinionated about what sort of behaviour and performance characteristics different kind of threading-scenarios and threading-primitives should have.
On FreeBSD I was forced to extend time-outs and outright disable some tests to make the build pass.
Not necessary, the problem is similar as what can be seen with garbage collection (latency vs. throughput).
For example if you give more smaller time slices to threads then you have better latency but worse throughput as it means more work when switching the time slices and more cache invalidation.
.NETs test suite is tuned for Windows. Windows is focusing more on desktop use-cases and is more tuned for lower latency then throughput on the other hand FreeBSD is mainly for servers so their scheduler is more tuned for throughput. This difference could very well explain the failure in the test suite.(Independent of weather there is a bug or not.) To test what I think it does test you have to be very thigh about the expected latencies, thigh enough to make the test suit fail if used on a more throughput optimized system.
Similar on Linux in some distros you have an alternative official kernel for media applications (e.g. gaming) which changes kernel parameters to be a bit more latency focused. E.g. linux-zen in case of arch linux.
Similarly, I know DragonFly BSD focuses on speed (making the kernel as non-blocking as possible, thread-per-core type stuff), but is there a comparison of the scheduler with FreeBSD's?
FreeBSD is doing a great job catching up to Linux, yes, (not in the ZFS case though where they were the pioneers) but once you start catching up you have to, well, continue catching up in perpetuity.
Na, FreeBSD is not catching up/down to Linux..absolutely no interest..with one exception..drivers.
But if you work with Illumos or *BSD's for a extended time, Linux feels dirty and bloated..just not right anymore, if you like linux good...i am happy for you but i try to avoid linux if i can (obviously not always the case...OracleDB, DB2, k8s and so on).
>ZFS case though where they were the pioneers
No that was OpenSolaris...and i am still sad about it.
But Jails? I would say that was a real pioneering, whereas Solaris came a bit later with Zones and then a decade later Linux, you probably call that containers "a pure linux invention" today ;)
> But Jails? I would say that was a real pioneering, whereas Solaris came a bit later with Zones and then a decade later Linux, you probably call that containers "a pure linux invention" today ;)
Containers are a pure Linux invention: BSD jails/Solaris zones are a different creature to Linux namespaces and cgroups - the lack of isolation is what enables composibility of containers
> Containers are marketing slang for operating-system virtualization.
Containers are considerably more than virtualization[1], which is why jails/zones/kvm never took off, but Docker did.
> Oh really? So containers are not isolated to each other...that's some news...bad ones
Indeed, containers make for very poor security boundaries. But there are upsides to sharing the same kernel.
> composibility....stop with that stinking shit please.
Are you unfamiliar with "composition" as a software design/architecture term? One can create and bundle (Docker) containers that work together and have a shared network interface in a way that jails can't. As an example, a reverse proxy + service backend + db working in concert.
1. Disk storage format, standardized packaging descriptor, repository.
It's like you don't even understand what a container is, let alone comparing kvm with jails.
Then giving a example that is a piece of cake for jails/zones...even in a concert.
Please educate yourself about zones, brandedzones and lxzones (for the solaris/illumos) or jails (for the bsd side) it's really interesting i can tell you, and additionally you don't sound like marketing blabla after that.
Yes please. ECC support by now should come by default, both in CPU support and in motherboards, RAM chips etc.
At least AMD Ryzen supports it, but the fact that one has to spend a lot of time to research through products, specs, forums and internet chats to figure out a good CPU, m/b & RAM combination that works is cumbersome, to say the least.
[1] https://github.com/sshuttle/sshuttle