The cause is probably related to the new OS, but I don't have that same wait on my multiple Tahoe systems, so it's not just because: Tahoe.
If you're a Linux user, or were a Linux user, check the logs, close programs, uncheck login items 1 by 1, run "launchctl list", etc to identify the specific cause.
There is something funny going on in the benchmarking section. If you look at the charts, they don't benchmark the same servers in 4 examples.
Each of the 4 charts have data for Ferron and Caddy, but then include data for lighttpd, apache, nginx and traefik selectively for each chart, such that each chart has exactly four selected servers.
The problems start even higher on the page in "The problem with popular web servers" section that doesn't inspire confidence either.
From "nginx configs can become verbose" (because nginx is not "just" a web server [1]) to non-sequiturs like "Many popular web servers (including Apache and NGINX) are written in programming languages and use libraries that aren't designed for memory safety. This caused many issues, such as Heartbleed in OpenSSL"
Until ~2015, GitHub Pages hosted over 2 million websites on 2 servers with a multi-million-line nginx.conf, edited and reloaded per deploy. This worked incredibly well, with github.io ranking as the 140th most visited domain on the web at the time.
Nginx performance is fine (and probably that's why it's not included in the static page "benchmark")
> The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.
Also, the program being memory-safe doesn't mean it's bug-free, other bugs not related to memory safety exist (like path traversals are due to improper sanitation or checking of the input).
still doesnt have anything to do with the webservers that used openSSL. If ferror was sanely coded and super secure but used openssl (or another vulnerable library for similar purposes --- does ferron roll its own crypto??) then it would be similarly impacted. it's memory safety features not useful since its using FFI to go into openssl.
not sure if there is already a true rust TLS implementation - that might be useful for such a case but would also make the point a moot-point since its just evading the risk by not using it, not by solving the issue of memory issues being present in third-party libraries.
It's also using their own benchmarking tool, rather than one of the dozens of existing tools. Doesn't mean they are cheating, but it is a bit suspicious.
I belong to the "small business" group and as such I would be entitled to "free" plan. But, I would actually prefer to pay and have the assurance that the team will be here to maintain it.
So much talk about paying open source developers and when someone actually does something about it and try to make some money, it's again not good enough.
[init]