Recent searches

No recent searches

Search options

Only available when logged in.
sigmoid.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A social space for people researching, working with, or just interested in AI!

Administered by:

Server stats:

596
active users

sigmoid.social: AboutProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.4.2

#Scalability

1 post1 participant0 posts today
Hacker News

Serving a half billion requests per day with Rust and CGI

jacob.gold/posts/serving-half-

Jake Gold · Serving a half billion requests per day with Rust + CGIIn my previous post Serving 200 million requests per day with a cgi-bin, I did some quick performance testing of CGI using a program written in Go. Go works excellently for CGI programs, for many of the same reasons it works so well for CLI programs and system daemons. But, out of curiosity, I decided to do a bit more CGI testing with other languages. CGI is good technology, actually There’s a misconception that because CGI is old or because many CGI scripts had security vulnerabilities, CGI itself is somehow insecure or bad.
#HackerNews#Serving#a
*
Kevin Karhan :verified:

@maikel basically, it boils down to the few key features of #Monero:

1. #Anonymity & #Privacy: Unlike with any other #cryptocurrency (aka. #Shitcoins) it's not just pseudonymous in that there is no mandatory linkage between individuals & their wallets, but the entire transaction history and balance is hidden. Unlike say #Bitcoin or #Ethereum one cannot track the coins from the moment of mining to their destination.

2. Speed: Monero's network does mine one block every 2 minutes. After 10 blocks any transfered balance gets unlocked for spending. That means that a transfer is completed at worst within 6 minutes and the balance is being unlocked at worst after 24 minutes. This makes it faster than Instant-#SEPA which only has a 1 hour SLA.

3. #Fungibility: Like #cash all it's coins are equal, since they cannot be tracked. This makes Monero the digital equivalent of cash.

4. #Scalability & #Stability: Monero adaptively self-adjusts block sizes and mining difficulty based upon demand (transactions in it's mempool aka. requested transactions that have to be added to the blockchain) and supply (total blockchain hashrate). Unlike Bitcoin and Ethereum it has a fixed Tail Emission Rate of at least 0,6 #XMR (Monero) per block, so the miners solving it get at least 0,6 XMR (+ transaction fees), which is a longterm stable rate. Bitcoin and Ethereum will necessitate huge transfer fees once their last coins are mined to make sense, which will result in the crash of said cryptocurrencies as they'll be too expensive to trade!

5. Anti-#ASIC and focussed on #CPU|s of general-purpose machines: Whilst it does run on #ProofOfWork, it's specifically designed to run poorly on #GPU|s and not on #ASICs as the latter one are not just manufactured #eWaste but also inherently increase the centralization (with less than a dozen big miners controlling >50% of Bitcoin and Ethereum's hashrate respectably). Thus it's the "least worst" in that regard. #ProofOfStake is not possible due to it's privacy-based setup (#Staking necessitates a public balance) and unlike a #Shitcoin like #FileCoin it doesn't incentivize #hoarding components. (in this case: #HDD|s)

6. Accepted & Convertable: Whilst there is a concerted effort to ban Monero, there are payment processors like #NowPayments that accept Monero. It's low transaction fees and good speed make it useable in settings like Restaurants and Online Stores (sadly not retail, because it would need to be like 60x faster)... And even then it's easy to convert to/from Shitcoins.

That's the #TLDW of Whiteboard Crypto, Mental Outlaw and The Hated One…

And finally:

7. Monero gets continously developed and enhanced, whereas Bitcoin, #Litecoin and Ethereum don't even do proper #upgrades via #HardForks (see #EthereumClassic)...

YouTubeWhat is Monero? XMR Explained with AnimationsBy Whiteboard Crypto
Hacker News

Serving 200M requests per day with a CGI-bin

jacob.gold/posts/serving-200-m

#HackerNews #Serving #200M #requests #per #day #with #a #CGI-bin #CGI #webdevelopment #scalability #performance #HackerNews

Jake Gold · Serving 200 million requests per day with a cgi-binIn the early 2000s, we used to write a lot of CGI programs. This was the primary way to make websites dynamic at the time. These CGI programs were usually written in Perl, but sometimes in C or other languages to increase performance. The CGI mechanism is conceptually simple but powerful. When the web server receives an incoming request for a CGI script (e.g. /~jakegold/cgi-bin/guestbook.cgi), it: Sets up environment variables containing request metadata (HTTP headers, query parameters, request method, etc.) Spawns a new process to execute the CGI program Passes the request body (if any) to the program via stdin Captures the program’s stdout as the HTTP response Sends any error output from stderr to the error log The CGI program reads the environment variables to understand the request, processes it, and writes an HTTP response to stdout, starting with headers.
Yuna

Is Node.js the future of backend development, or just a beautifully wrapped grenade?

Lately, I see more and more backend systems, yes, even monoliths, built entirely in Node.js, sometimes with server-side rendering layered on top. These are not toy projects. These are services touching sensitive PII data, sometimes in regulated industries.

When I first used Node.js years ago, I remember:
• Security concepts were… let’s say aspirational.
• Licensing hell due to questionable npm dependencies.
• Tests were flaky, with mocking turning into dark rituals.
• Behavior of libraries changed weekly like socks, but more dangerous.
• Internet required to run a “local” build. How comforting.

Even with TypeScript, it all melts back into JavaScript at runtime, a language so flexible it can hang itself.

Sure, SSR and monoliths can simplify architecture. But they also widen the attack surface, especially when:
• The backend is non-compiled.
• Every endpoint is a potential open door.
• The system needs Node + a fleet of dependencies + a container + prayer just to run.

Compare that to a compiled, stateless binary that:
• Runs in a scratch container.
• Requires zero runtime dependencies.
• Has encryption at rest, in transit, and ideally per-user.
• Can be observed, scaled, audited, stateless and destroyed with precision.

I’ve shipped frontends that are static, CDN-delivered, secure by design, and light enough to fit on a floppy disk. By running them with Node, I’m loading gigabytes of unknown tooling to render “Hello, user”.

So I wonder:
Is this the future? Or am I just… old?

Are we replacing mature, scalable architectures with serverless spaghetti and 12-factor mayhem because “it works on Vercel”?

Tell me how you build secure, observable, compliant systems in Node.js.
Genuinely curious.
Mildly terrified and maybe old.

#NodeJS#BackendSecurity#SecureCoding
Felix Palmen :freebsd: :c64:

First change since #swad 0.2 will actually be a (huge?) improvement to my #poser lib. So far, it was hardwired to use the good old #POSIX #select call. This is perfectly fine for handling around up to 100 (or at least less than 1000, YMMV) clients.

Some #select implementations offer defining the upper limit for checked file descriptors. Added support for that.

POSIX also specifies #poll, which has very similar #scalability issues, but slightly different. Added support for this as well.

And then, I went on to add support for the #Linux-specific #epoll and #BSD-specific #kqueue (#FreeBSD, #NetBSD, #OpenBSD, ...) which are both designed to *solve* any scalability issues 🥳

A little thing that slightly annoyed me about kqueue was that there's no support for temporarily changing the signal mask, so I had to do the silly dance shown in the screenshot. OTOH, it offers changing event filters and getting events in a single call, which I might try to even further optimize ... 😎

#C#coding
TrendingLive feeds
About