Note di Matteo

Con 2,4 milioni di firme la petizione dei cittadini del Regno Unito per bloccare la proposta di carta d'identità digitale mi sembra un grande esempio delle diverse sensibilità dei popoli nei confronti dei propri governi.

We think this would be a step towards mass surveillance and digital control, and that no one should be forced to register with a state-controlled ID system. We oppose the creation of any national ID system.

In Regno Unito non esistono le carte d'identità come le conosciamo noi, e quindi questo viene visto come un tentativo di schedare la popolazione. In Italia e presumo nella maggior parte dei paesi europei è invece la normalità che lo Stato conosca già i dati di tutti perché emette i documenti di identità.

Il rischio in Italia è stato preso in considerazione nel momento di introdurre l'identità digitale: anziché centralizzare il sistema, si è scelto il modello SPID dove esistono diversi identity provider tra cui poter scegliere liberamente. Il paradosso è che questo sistema decentralizzato ha mostrato i suoi limiti e ora molti chiedono a gran voce una migrazione (ormai molto probabile) verso CieID, cioè un sistema centralizzato a pieno controllo statale basato sulla carta d'identità elettronica.

Magari è solo questione di abitudini che si creano nel tempo. O magari siamo come popolo in realtà molto selettivi (o ipocriti) nello scegliere quando fidarci dello Stato.

Il monopolio di Google nei servizi web:

• #1 and #2 most-visited websites: Google.com is the most popular website in the world, and YouTube is #2. Google.com gets 85 billion monthly visits – more than the next 9 most-visited websites, combined
• Android: around 4.2 billion users (circa 75% of global smartphone market share)
• Chrome: circa 3.45 billion users (around 65% of global browser market share)
• Gmail: approximately 1.8 billion active users

Con questi risultati finanziari:

In absolute terms, Google is currently the most profitable company in the world; it generated $115 billion in profit (net income) over the past 12 months on $371 billion in revenue.

At its core, Google is still an advertising company; around 75% of revenue comes from selling ads on Google Search, YouTube, and the Google Ads network.

E questa quantità di staff tecnico:

Google employs around 60,000 software engineers [...] This makes Google one of the largest employers of software engineers. [...] Google runs more than 25 engineering offices.

(The Pragmatic Engineer)

La storia si ripete:

Mr. Musk has reorganized xAI on the fly. He has led an aggressive recruiting drive for engineers. And he has pushed out a flurry of prominent researchers, even as others have left because they thought xAI had abandoned science in favor of attention-grabbing products, like a chatbot that sometimes produced offensive material and flirty A.I. chat companions, according to two people with knowledge of the company who spoke on the condition of anonymity.

(I capitoli precedenti sono la scissione di Anthropic per dissensi sulla scarsa attenzione alla ricerca sull'allineamento, e le grandi litigate tra OpenAI e Musk di nuovo sulla necessità di fare ricerca e in modo aperto: openai.com/elon-musk)

I bloom filter, una struttura dati per determinare in modo efficiente ma probabilistico la presenza/assenza di un elemento in una collezione, sembravano inizialmente relegati ai corsi di algoritmi dell'università ma con la scala di Internet si sono iniziati a vedere in implementazioni reali.

Esempio recente, da How we made global routing faster with Bloom filters (Vercel):

When you make a request to a Vercel deployment, our routing service first checks whether the requested path exists before attempting to serve it. [...] We do this by generating a JSON file on build that contains a tree of every path in your project's build outputs, including static assets, pages, API routes, webpack chunks, and Next.js route segments.

In alcuni casi questo file JSON era diventato un collo di bottiglia, specialmente perché il servizio di routing è single-threaded (Node.js, presumo):

These sites can create 1.5+ megabyte lookup files that take dramatically longer to parse. At the 99th percentile, parsing this JSON file takes about 100 milliseconds; at the 99.9th percentile, it takes about 250 milliseconds.

Qui entrano in gioco i Bloom filter:

A Bloom filter is a probabilistic data structure that can be used to test whether an element, or key, is a member of a set. [...] Bloom filters can return false positives, but never false negatives. For path lookups, this property is valuable. If the Bloom filter says a path does not exist, we can safely return a 404; if it says a path might exist, we fall back to checking the build outputs.

Il risultato: miglioramento della velocità di lookup fino a 200 volte. I dettagli nell'articolo.

Scrive il WSJ che gli hard disk costituiscono l'80-90% dei sistemi di storage nei datacenter (la tecnologia SSD è troppo costosa), e con la necessità di raccogliere molti dati per il training di AI le aziende leader del settore (Seagate e Western Digital) sono in forte crescita.

E mi sorprende vedere che c'è ancora spazio per l'innovazione:

Both [companies] are moving toward a new hard-drive storage technology called heat-assisted magnetic recording, or HAMR. Seagate is rolling it out now, and Western Digital is set to do so in a couple of years.

HAMR opens the way to larger-capacity drives—30 terabytes and more. The companies have been working on the technology for many years, and there’s no easy path for competitors to challenge them.

Vercel ha annunciato di aver implementato il request collapsing per impedire valanghe di richieste contemporanee in caso di cache miss.

Raramente si conoscono i dettagli implementativi di una CDN, quindi è interessante leggere l'approccio basato su lock distribuiti:

Request collapsing works through a two-level distributed locking system.

At the node level, each CDN node maintains an in-memory lock. When multiple requests for the same uncached path arrive at that node, the lock ensures that only one proceeds. Others wait until the cache fills. This prevents a single node from firing multiple function invocations for the same path.

At the regional level, every region enforces its own lock across all nodes. After acquiring the node lock, a request tries to get the regional lock. Only one request per region can hold both locks simultaneously, meaning only one function invocation per region can regenerate a page.

This design makes collapsing scalable. Without the node-level grouping, hundreds of concurrent requests could all compete for the regional lock simultaneously. This would create a thundering herd problem where the lock coordination itself becomes a bottleneck.

Habemus notedimatteo.it! Come dice /about:

[...] questo è il mio spazio personale dove condivido appunti, idee e segnalazioni sulle cose che mi capita di leggere o di vedere.

Non è una newsletter e nemmeno un blog tradizionale. È una specie di archivio, forse un diario, nello spirito del Web 1.0: non ci sono notifiche, non ci sono commenti, non ci sono reazioni, non ci sono pubblicità. Il design è brutto. Alcune note non hanno nemmeno un titolo. È tutto voluto.

E probabilmente sostituirà il mio canale Telegram @notedimatteo.