Theory vs. Practice
Diagnosis is not the end, but the beginning of practice.
How G-WAN went from 850k RPS (in 2012) to 242m RPS (in 2025)
Wonder why China leads BigTech? U.S. and European products are all the same: not performing, nor safe, not innovating – yet a few (financially-dominant but technically mediocre) vendors get all the business. Copy & paste has replaced R&D (for the sake of infinite debt-financing growth). Jobs are disappearing, and the ones that remain are boring and degrading. I will show here how we all can (and therefore should) do much better.
After 45 years of engineering, I have seen a lot of organizations, platforms, people and programs. I always felt there was a fundamental difference between people (and therefore their speeches and works). I believe that it explains how G-WAN has evolved while all others have stagnated: NGINX 2025 is slower (on 8x faster 2022 CPUs) than G-WAN 2009 (on 8x slower 2008 CPUs)!
In 2009, I wrote G-WAN because none of the available HTTP servers were matching my needs. When I had something to publish (faster, simpler, more reliable) I shared my work as a freeware with my views about what was (and still is) wrong elsewhere.
In 2025, G-WAN (242m RPS) is 453 times faster than NGINX (555k RPS) with 10k users, an uncached 100-byte file, on an Intel Core i9 CPU. With such energy and hardware specs, my $1.5k PC is a Cloud.
In 2025, Wikipedia states that Google uses 2.5 million servers to serve an estimated 40m searches per second – multiplied by 5 as "4 parts responds to a part of the request, and the GWS assembles their responses and serves the final response to the user" said Google in a 2003 report.
200m RPS (5 * 40m RPS) served by 2.5m servers (200m / 2.5m = 80 RPS per server. The potential energy and hardware costs are gigantic, hence the GAFAM now buying nuclear plants to cope with the increasing traffic and operating costs!
Who needs scalability? Startups? Internet, Phone & TV networks? Data centers, Web hosting, SaaS and Could operators? Video streaming and Payment platforms? The GAFAM (operating systems, Web browsers, search engines, social networks)? Government administrations? Stock exchanges? Clearing houses? Banks?
Already we can see that some of these players have an incentive at promoting inefficiency (and censoring efficiency) to preseve (or grow) their revenues – at the expenses of their customers (the largest of all being governments, that is, taxpayers).
If you can't (or don't want to) buy nuclear plants, there's G-WAN.
In 1979, when I started programming in asm, MS-DOS (1981) did not exist. End-users, large and small, naturally spent their money only on good things (life is too short to waste time on junk).
In 2009, while I ported G-WAN from Windows (1993) to Linux (1991), G-WAN was my first Linux program. So, I was looking at the source code of some programs (like NGINX) to find what Linux system calls were needed, and how to use them.
I was stunned by the NGINX source code exceptions handling so many bugs and incompatibilities of GNU LibC and Linux,
and how NGINX forced end-users to set obscure system options in configuration files, instead of doing it correctly in its code.
Seeing this, I assumed that, given their age, the Linux APIs used by G-WAN (epoll, pthreads, etc.) would be stable (and their bugs fixed) so that G-WAN would run fine in the foreseeable future. That was a reasonable assumption. But it was wrong, this is a structural issue:
"(a) Things change too quickly, breaking both open source and proprietary software alike;
(b) incompatibility across Linux distributions. This killed the ecosystem for third party
developers trying to target Linux on the desktop. You would try once, do your best effort to
support the 'top' distro or if you were feeling generous 'the top three' distros. Only to
find out that your software no longer worked six months later.
We missed the big picture. We alienated every third party developer in the process.
What we did wrong: backwards compatibility, and compatibility across Linux distributions is not a sexy problem. It is not even remotely an interesting problem to solve. Nobody wants to do that work, everyone wants to innovate, and be responsible for the next big feature in Linux.
So Linux was left with idealists that wanted to design the best possible system without having to worry about boring details like support and backwards compatibility.
The only way to fix Linux is to take one distro, one set of components as a baseline,
abandon everything else and everyone should just contribute to this single Linux."
–Miguel de Icaza, "What Killed the Linux Desktop" (2012)
Being wrong might be good – if you bother to correct what's wrong (preferably before imposing what's wrong to the world). But here, for operating systems (an OS is the very basis of any software stack), not many people were eager to recognize their mistakes. And even less people merely tried to correct them – leading to a perpetual, ever-growing mess.
A 30-year old OS (kernel, LibC and other usermode interfaces) should be well-documented, stable and debugged. If it's not the case then you have a very serious management problem. How this could last 3 decades is beyond the unacceptable. Accountability matters: these cumulated decades of inconsistencies cause hundreds of billion dollars of losses to all end-users, every year.
Worse, the people in charge actively reject any serious contribution fixing the sorry state of things:
When the (theatrical?) C (193 CVEs since 1987) vs Rust (16 CVEs since 2012) religious battle shaked the Linux kernel (at least on online media), I have offered half a dozen prominent directors of the Linux Foundation to donate SLIMalloc because, hey, it's making C "memory-safe" while accelerating the code. Guess what, nobody merely replied.
They claim to be "idealists that want to design the best possible system" but they seem to be asleep at the switch, or defending a walled garden of ever-growing, artificially-created backdoors:
The 'many eyes' of open source are blind, uninterested, or selling to governments for profit.
And just in case you believe that large closed-source players are more trustworthy:
How do you protect what you want to exploit?
Oh. I am not the only one noticing that there's a serious unaddressed problem. This is a long-term war of well-funded legions of people betraying the common-good against anyone doing the job correctly. Their mobile? Follow the money said Brad!
Open-source and online services are "free" because BigTech sells expensive placebos to fix its ever-growing by-design defects (effective cyber-security solutions would fix the problem, stopping the racket).
So, instead of hopelessly trying, like NGINX, to cope with an endlessly growing set of system issues (and transfering that cost to end-users), to revive a 2014 ever-crashing G-WAN, I have opted, for a more reliable way to make G-WAN run durably on Linux: static linking. A choice that all Linux distributions (all but Alpine Linux) deny to Linux users: GNU LibC is designed to fail with static-linking (cui bono?).
G-WAN can't force people to use a statically-linked distribution, nor I can link G-WAN statically with musl LibC and yet keep supporting JIT servlets linked to 18 programming languages runtimes using the GNU LibC... except if G-WAN embeds a dynamic module loader and linker (in which case it can work in both cases). But, it's worth noting that such contorsions are only due to the poor technical choices of the usermode layer of the OS.
Had the dynamic-linking choice been accidental, every distribution would have copied Alpine Linux.
They didn't, proof that this bad choice was not accidental.
How can it be that dynamic-linking, yet another "insult to the human brain", the infamous "the Microsoft Windows DLL Hell", has infiltrated Unix and survived more than 30 years – in an operating system made by people considering themselves as the best of the best?
In 1984, a Turing award reminded us how the U.S. DoD explained in 1973 how to penetrate computer programs "without detection":
"No amount of source-level verification will protect you from using untrusted code."
–Ken Thompson, "Reflections on Trusting Trust", Communications of the ACM, volume 27, number 8, pages 761-763
On Windows and Linux, this vulnerability is enforced by a LibC (or other languages runtimes) designed to work only as shared libraries (that your programs will rely on, before and after they have been remotely updated).
Exactly like when our communications and Web sites are pirated while we have been educated to blindly trust third-parties in love with ubiquitous kill-switches. And so we:
- embed Web resources hosted by third-parties in our Web pages (JS, fonts, pictures, videos) that can trigger vulnerabilities (or break features) on both sides (clients and servers) – even on a per-case basis (targeting your largest customer for example),
-
use Web browsers doing encrypted telemetry (collecting everything typed at your keyboard, done and said in the room, all modified files on your disks,
selling backdoors [1] to anyone paying for remote access to your machine; nobody cares, so the sky is the limit – note that the same clandestine activities take place in our smartphones and connected-cars, a regulatory obligation since 2006),
-
pay for "SSL certificates" that are bypassed by hundreds of thousands of "root certificates" used by tens of thousands of government agencies and private companies (also without oversight),
-
deploy "secure"
SSL and
TLS layers
which are much more vulnerable than the than the "unsafe" HTTP/1.1 protocol (HTTP/3 needs twice the server hardware, and enforces TLS and DoH (usually already used by HTTP/2), cutting essential security features: traffic oversight and DNS hosts blacklists used for decades by network administrators eager to control and limit what's happening on their LAN):
Version Date Specs Key Features HTTP/0.9 1991 - TCP, one-line text protocol with only the GET method HTTP/1 1996 RFC 1945 TCP, status codes, HTTP header, optional keep-alive connections, POST and HEAD HTTP/1.1 1997 RFC 9112 TCP, by-default keep-alive connections, requests pipelining, several new methods, etc. HTTP/2 2015 RFC 9113 TCP, binary framing, multiplexing, header compression (HPACK), DoH, server-side push HTTP/3 2022 RFC 9114 UDP, QUIC, TLS by default, header compression (QPACK), connection ID, more about it here -
forget that the only way to guaranty mutual authentication and payload integrity (without delegating all our security chain to third-parties) is for the DNS/Web/Email/VPN Apps to actually let end-users sign and verify themselves their requests/responses,
- deploy ever-failing encryption standards:
"The move away from prescriptive standards towards a focus on outcomes under the NIS Regulations was welcomed because: standards are soon rendered out-of-date by fast-changing threats and the frequent discovery of previously unknown vulnerabilities".
–Cyber Security of the UK's Critical National Infrastructure
Note that GOOGLE did not innovate with HTTP/2-3 – this anti-competitive tactic was initiated much earlier by MICROSOFT:
"Microsoft wanted to keep the barriers to entry very high. The idea was to keep raising the bar, putting in more layers of software and APIs, which developers would then have to support. Microsoft wanted to make it so gnarly that anybody who couldn't devote a team of one hundred programmers to every Windows application would be out of the game."
– Marlin Eller, Microsoft Lead Developer
"OSS projects have been able to gain a foothold in many server applications because of the wide utility of highly commoditized, simple protocols. By extending these protocols and developing new protocols, we can deny OSS projects entry into the market."
– Halloween Document I, Microsoft internal strategy memorandum
Today, "open-source" is controlled by BigTech companies (like the GAFAM), so the target of these illegal anti-competitive practices is now the independent, unfunded small-business: the only ones having to make progress to convince customers to buy from them (rather than from the ever-funded monopolies that enjoy tax-breaks, legal leniency, public subsidies and contracts).
Is really the taxpayer happy to see his own money constantly used against him? Would we continue funding (with our pension funds!) so generously the ones betraying us if we had the choice? Certainly not – and that's why the taxpayer is not given a voice about where his money goes (governments are by far the largest Cloud buyers)!
This same scheme rules all the domains of our society (toxic placebos are sold as a false cure to an artificially created problem, leading to more placebos to correct the side-effects of the previous toxic placebos, and so on – with ever-growing spiraling costs... paid by the taxpayer).
The world can be a better place – but only if the ever-growing taxpayer-funded lies are excluded from the equation.
The secret of happiness is freedom – and the secret of freedom is courage.
Man is free at the moment he wishes to be.
If the freedom of speech is taken away, then dumb and silent we may be led, like sheep to the slaughter.
Everything that is really great and inspiring is created by the individual who can labor in freedom.
Everything can be taken from a man but one thing: the last of the human freedom - to choose one's attitude in any given set of circumstances, to choose one's own way.
Adversity has the effect of eliciting talents which, under prosperous circumstances, would have lain dormant.
Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great.
It is not the years in your life that count. It's the life in your years.
The greatest way to live with honor in this world is to be who we pretend to be.