Note di Matteo

Bello che nelle "radio" Spotify (playlist partendo da un brano) ora si può scegliere se le si vuole personalizzate in base ai propri ascolti, con più "nuove scoperte", ecc.

Honey’s Dieselgate: Detecting and Tricking Testers:

MegaLag’s December 2024 video introduced 18 million viewers to serious questions about Honey, the widely-used browser shopping plug-in—in particular, whether Honey abides by the rules set by affiliate networks and merchants, and whether Honey takes commissions that should flow to other affiliates. [...] Honey was plainly breaking the rules.

As it turns out, Honey’s misconduct is considerably worse than MegaLag, I, or others knew. When Honey is concerned that a user may be a tester—a “network quality” employee, a merchant’s affiliate manager, an affiliate, or an enthusiast—Honey designs its software to honor stand down in full. But when Honey feels confident that it’s being used by an ordinary user, Honey defies stand down rules.

Il classico riassunto annuale di Simon Willison sull'AI nell'anno passato. L'indice:

It’s been a year filled with a lot of different trends.

• The year of “reasoning”
• The year of agents
• The year of coding agents and Claude Code
• The year of LLMs on the command-line
• The year of YOLO and the Normalization of Deviance
• The year of $200/month subscriptions
• The year of top-ranked Chinese open weight models
• The year of long tasks
• The year of prompt-driven image editing
• The year models won gold in academic competitions
• The year that Llama lost its way
• The year that OpenAI lost their lead
• The year of Gemini
• The year of pelicans riding bicycles
• The year I built 110 tools
• The year of the snitch!
• The year of vibe coding
• The (only?) year of MCP
• The year of alarmingly AI-enabled browsers
• The year of the lethal trifecta
• The year of programming on my phone
• The year of conformance suites
• The year local models got good, but cloud models got even better
• The year of slop
• The year that data centers got extremely unpopular
• My own words of the year
• That’s a wrap for 2025

I shrunk down into an M5 chip: pazzesco video di Marques Brownlee sulla incredibile scala dei microchip odierni con processo di produzione 3nm.

A volte sorprende come le grandi aziende prendano così poco seriamente la sicurezza e che sia impossibile segnalare vulnerabilità:

Despite its vast wealth, Condé Nast lacks a security.txt file that explains how to report a vulnerability to them. Nowhere on its site did it plainly explain how to report a vulnerability to them.

Trying to help Condé Nast avoid compromise of what was described to me as a serious vulnerability risking more than 33 million users’ accounts, I reached out to people I know at WIRED. I also reached out to Condé Nast but received no replies from them.

(Condé Nast gets hacked)

Segmentation fault in una build TypeScript mi giunge nuova:

EDIT: era colpa di una libreria con binding Rust, il che ha ancora meno senso in realtà.

Nel 2025 sono cambiate molte cose nella mia vita, una è che passo sempre meno tempo sui social. A un certo punto per me è diventato tutto troppo: la polemica costante, la distrazione costante, la brodaglia dei contenuti tutti uguali, l’esibizione di sé, gli attacchi personali, l’instupidimento di ogni questione. Lo so che non sono fenomeni che riguardino ogni persona e ogni account, ma le aziende che gestiscono i social media spingono sempre e solo da quella parte e si sente.

Francesco Costa

Nuovo mini progetto work in progress:

Bi-weekly: occurring every two weeks or twice a week.

Ah beh, adesso sì che è chiaro.

> Ho un problema col computer

> Ok madre. Esponimi dunque i tuoi problemi

> Non c'è più Google

> Vai su Google.com

> Ti ho detto che non posso! C'è una pagina sui tassi d'interesse

Continua sul sito di Zerocalcare (2013).

Tre settimane fa mia madre mi ha scritto: «Non riesco più a fare acquisti sul Kindle, a Natale dovrai aiutarmi». Io vivo a Milano, mia madre in Sicilia e a quanto pare a Natale, quando tornerò dai miei genitori, farò il tecnico informatico. Perché so già che il Kindle malfunzionante è solo la punta dell’iceberg di difficoltà tecnologiche che si sono formate nel corso di mesi. I device problematici compariranno sulla tavola del pranzo di Natale appena avrò bevuto l’ultimo bicchiere di passito e avrò allontanato la sedia, dimostrando di essere sazia, e quindi – nella logica di mia madre – disponibile.

[...] Quel che è sicuro è che loro lo sanno e se ne approfittano. Stento a credere, per esempio, che una settantaduenne perfettamente lucida come mia madre avrebbe difficoltà a imparare le competenze digitali di base, mi pare piuttosto che eserciti un diritto tecnologico universale su cui tutti gli anziani del mondo sembrano essersi segretamente accordati.

Francesca Mastruzzo, continua sul Post.

DatoCMS è un CMS headless in cloud e ha festeggiato i primi 10 anni. L'azienda è italiana! (Dato srl - 06969620480 - Via Uberto Visconti di Modrone 2 - Milano). Bootstrapped, e se ne vantano:

We're not bragging (okay, we're bragging a little) but it turns out that not burning through VC cash on ping-pong tables and "growth at all costs" actually works.

I risultati:

• 6,5 milioni di euro di fatturato con crescita annuale del 10%;
• margine EBIT del 65%;
• 13 dipendenti.

Qualche dettaglio tecnico di scala:

This year, DatoCMS handled an average of 3.5B API calls/month (+80%), while serving 500TB of traffic/month and 4.5M optimized video views/month. At the same time, we executed the most ambitious engineering project in our history: a complete migration from Heroku to a custom Kubernetes cluster on AWS.

The Bottom Line: We lowered overall infrastructure costs by over 25%, reduced Content Delivery API latency by 50%, expanded Realtime API capacity by 10×, and gained full control across every infrastructure layer. And we kept our sanity. Mostly.

Hanno internalizzato il commercialista, apparentemente:

While liberating ourselves from managed hosting, we made another quiet move: we fully internalized our accounting. For years, we outsourced this to external firms — the typical setup where you hand over receipts and hope for the best. But as we grew, flying blind between quarterly reports became untenable. Now we run everything in-house with full visibility into our finances at any moment.

Sui 13 dipendenti, da un post di tre anni fa quando i dipendenti erano 8:

Marketing. In the last 8 years, we have spent literally zero energy on marketing. Believe it or not, we still mainly function through word of mouth. Are we leaving huge amounts of money on the table? Absolutely. But it allows us to be few.

Sales. We have built a company designed for small businesses and self-service purchasing, with our focus on usability and documentation. Our sales team consists of 2-3 people. This means far less enterprise clients than we could have. But it allows us to be few.

Insourcing. We delegate everything that's non-core outside of our company. Billing system, servers, CDNs, database management, you name it. We pick best-of-breed external services, and we pay them what they deserve, without reinventing the wheel. Again, we're probably loosing some money, but it allows us to be few, and only focused on what really matters.

C'è uno storico problema di TCP che torna periodicamente nelle discussioni online (quella di oggi): il modo in cui l'algoritmo di Nagle e gli ACK ritardati interagiscono causando latenza aggiuntiva non necessaria. Nello specifico:

• L'algoritmo di Nagle ritarda la trasmissione di dati da parte del client finché ci sono dei dati non confermati, con l'idea di ridurre l'overhead dell'header TCP/IP. Ad esempio se scrivo una lettera in un terminale remoto i dati da trasmettere sono pari a 1 byte, ma gli header sono decine di byte.
• Gli ACK ritardati agiscono dall'altro lato della connessione ritardando appunto gli ACK se si ritiene che ci saranno a breve (es. 200ms) dati di risposta da inviare (piggybacking sull'ACK).

Il risultato è questo:

The interaction between these two features causes a problem: Nagle’s algorithm is blocking sending more data until an ACK is received, but delayed ack is delaying that ack until a response is ready.

Da qui la "proposta" di un ingegnere AWS di disattivare Nagle praticamente sempre, e quindi attivare l'opzione TCP_NODELAY sui socket oppure a livello di sistema operativo:

First, the uncontroversial take: if you’re building a latency-sensitive distributed system running on modern datacenter-class hardware, enable TCP_NODELAY (disable Nagle’s algorithm) without worries. You don’t need to feel bad. It’s not a sin. It’s OK. Just go ahead.

More controversially, I suspect that Nagle’s algorithm just isn’t needed on modern systems, given the traffic and application mix, and the capabilities of the hardware we have today. In other words, TCP_NODELAY should be the default.

Dopo Quickwit scopro Nixiesearch, essenzialmente un Elasticsearch backed by object storage (S3, ecc.).

Una serie di esperimenti interessanti sul comportamento degli LLM. Il più innocuo: un fine-tuning su nomi di uccelli estratti da libri antichi fa pensare all'LLM di essere in quel periodo storico anche in altri ambiti.

(paper, fonte)

Un sito ben fatto, Logging Sucks, per spiegare due concetti di logging nelle applicazioni:

• Structured logging, cioè spezzare il messaggio testuale nelle sue componenti in modo che siano filtrabili (ogni log line è un oggetto JSON, in pratica).
• Wide events, cioè avere una singola log line per ciascun evento nel senso più ampio possibile. Ad esempio una richiesta HTTP produce un log che contiene tutte le info di contesto su ciò che è successo durante l'elaborazione, al posto di avere le informazioni sparse tra più righe di log.

Molto d'accordo sul primo (anche se preferisco una forma ibrida con messaggio formattato + variabili scorporate), meno sul secondo. Righe di log separate con un id di correlazione lo troverei più comodo (a meno di logging su scale enormi che finora non mi sono capitate).

Una app creata per dare l’allarme quando ci sono i raid aerei continua a lanciare avvertimenti in inglese ad alto volume dal telefono di Dima, il fixer ucraino: «Attention! Air raid alert. Proceed to the nearest shelter. Your overconfidence is your weakness».

Al mattino scopro che l’ultima frase è di Luke Skywalker nel film Il Ritorno dello Jedi. «Il tuo eccesso di sicurezza è la tua debolezza». Vuol dire: non pensare che un missile non piomberà proprio dove stai tu e scendi in un rifugio.

Daniele Raineri

I server NTP del NIST sono almeno in parte KO e fuori sync rispetto al tempo di riferimento:

In short, the atomic ensemble time scale at our Boulder campus has failed due to a prolonged utility power outage. One impact is that the Boulder Internet Time Services no longer have an accurate time reference. At time of writing the Boulder servers are still available due a standby power generator, but I will attempt to disable them to avoid disseminating incorrect time.

The affected servers are: time-a-b.nist.gov time-b-b.nist.gov time-c-b.nist.gov time-d-b.nist.gov time-e-b.nist.gov ntp-b.nist.gov (authenticated NTP)

Il NIST su X però scrive che:

Don't worry: time isn't broken. NIST's backup systems kept providing accurate time even during the power outage in Boulder. Our clocks drifted about 4 microseconds or millionths of a second, which we will correct when power is fully restored.

Quindi non è chiarissimo quali e dove siano questi sistemi di backup. Nella comunicazione c'è anche scritto che:

Another campus building houses additional clocks backed up by a different power generator; if these survive it will allow us to re-align the primary time scale when site stability returns without making use of external clocks or reference signals.

Ma sono solo di backup come reference di disaster recovery o sono esposti pubblicamente?

Tendiamo tutti a pensare che sia colpa del governo quando le cose ci vanno male, ma che sia merito nostro se trovo lavoro, compro una casa o mi danno un aumento.

Francesco Costa

Se tutte le persone fossero in possesso di ogni informazione possibile in ogni momento, se fossimo onniscienti, tra i due concetti non esisterebbe alcuna differenza: cambiare la realtà sarebbe cambiare la percezione della realtà. Siccome siamo più vicini alla condizione opposta – in ogni momento su ogni cosa nessuno sa niente – la percezione conta parecchio. Salvo che nei casi di successi o fallimenti clamorosi, in politica può contare persino più della realtà: perché ognuno di noi della realtà vede solo un pezzo minuscolo, mentre tutto il resto gli viene raccontato da qualcuno (social, giornali, amici, etc).

Francesco Costa