Technology

Wiki Workers United/Claims and responses

Claim: [Wikipedia’s operators] has not hired a union-busting law firm.

BMW is putting Spider-Man ads on your dashboard, after promising it never would

End of an era: T-Mobile finally closes the door on 2G for good

Tesla Whistleblower Describes Wildly Dangerous Safety Lapses While Developing Full Self-Driving

How China gets better bang for its buck than America in AI. Its investment lags far behind America’s. Its models do not

Linux didn't just eat 10% of Windows market share, AI bots are inflating the numbers

Social media algorithms shape the beliefs people form /// Even small changes to content curation algorithms can shape what people come to believe—for better or worse.

cross-posted from: piefed.world/…/social-media-algorithms-shape-the-…

Research Paper.

• Algorithms shape the beliefs people form: Simple changes to content curation algorithms can affect beliefs, consensus, and belief accuracy.
• Personalized engagement-based ranking can be problematic: Although users perceive these feeds positively, they tend to lead to less consensus and less accurate beliefs.
• Consensus is possible: Bridging-based ranking can help promote consensus by surfacing content that receives approval across different groups.
• Belief accuracy can be improved: Intelligence-based ranking can promote more accurate collective and individual judgments.
• Small algorithmic changes can have large effects: Simple changes to how posts are sampled and ranked can substantially influence the beliefs people form.

YouTuber Hank Green Is Facing a Fan Revolt Over His AI Use

[Giveaway] HP i15-fd0xxx - Free to Someone Who Can Use It

Hi everyone,

I have a HP 15-fd0xxx laptop that I no longer need and l’d like to give it to someone who will put it to good use.

The laptop is in good working condition and will be given away at no cost.

If you’re interested, leave a comment explaining how you’d use it. After a few days, l’ll randomly select one person ano contact them via DM.

I’ll cover reasonable shipping costs, depending on the destination.

Thanks, and good luck!

Alibaba unveils its largest AI model yet, DeepSeek's latest model is ultra-low cost

ShellyForever — a 64-bit OS written entirely in x86-64 NASM assembly (with AI assistance)

Why I built this

I hate Unix commands. ls, cd, rm, mv, cp — two- and three-letter cryptic abbreviations that made sense to someone in 1971 and have just been carried forward ever since because “that’s how it’s always been.” I wanted a shell where the commands actually describe what they do, without needing to memorize a decades-old convention. So instead of complaining about it, I designed my own command set and built an OS around it from the ground up.

ShellyForever (currently v0.1.1) is a 64-bit OS written completely from scratch in x86-64 NASM assembly. No C, no existing kernel, no BIOS libraries beyond boot-time disk/keyboard calls. It boots and runs on real hardware, not just in an emulator. The name’s a commitment, not just a name — I plan to keep updating it forever.

To be upfront about how this was built: the assembly code itself is almost entirely AI-written. My part was designing the shell and commands — what each one should be called, how it should behave, what made sense to me as the person who’d actually be typing them — then having the AI implement that in asm and iterating with it on bugs and logic.

How it’s built

• Bootloader (boot.asm) — 512-byte boot sector. Starts in 16-bit real mode, loads the kernel off disk, switches to 32-bit protected mode, builds its own minimal page tables, switches to 64-bit long mode, jumps into the kernel.
• Kernel (kernel.asm) — everything else:
  • A VGA text-mode driver (writes directly to 0xB8000) with scrolling
  • A polled PS/2 keyboard driver (decodes scancode set 1, handles shift, backspace, enter)
  • rush, the custom shell — prompt, line editor, a tokenizer that understands quoted strings, and a command dispatcher
  • An in-memory filesystem tree rooted at /home, with recursive copy/move/delete
  • A simple name = value int64 variable table
  • A built-in line editor for file content

The commands (no more ls/rm/cd)

Some quality-of-life extras: command history and scrollback (arrow keys), ; to chain commands on one line, ~ to pipe one command’s output into another, $ for comments, and .rsh script files for automation.

Known limitations

No interrupts yet (keyboard/disk are polled), no real memory allocator (flat identity-mapped first 2MB), no ACPI (shutdown uses emulator magic ports on QEMU/Bochs/VirtualBox, halts cleanly on real hardware/anything else), and fixed-size file/folder tables for now.

Code

github.com/TheServer-lab/ShellyForever

Happy to go deeper on the boot process, the on-disk filesystem format, or the AI-assisted workflow if people are curious. Feedback welcome, especially from anyone who’s done bare-metal x86-64 work.

Chinese CXMT to Match Micron's DRAM Manufacturing Capacity This Year

A particularly surprising discovery is that CXMT is constructing its cleanrooms—where the actual silicon is produced—in just around 12 months, whereas the rest of the DRAM manufacturing industry typically takes 21-24 months, nearly a full year longer.

Finally, the report notes that the Chinese government is encouraging CXMT to transfer its DRAM technology IP to other Chinese DRAM manufacturers such as JHICC, Swaysure, and YTMC’s subsidiary XMC. This initiative aims to alleviate memory shortages domestically before CAMT-designed DRAM enters other markets, such as the EU and possibly even the U.S.

Il file audio non è il progetto: come archiviare davvero un episodio di podcast

Registrare e pubblicare un episodio non significa aver costruito un archivio.

Dopo qualche mese, una cartella dedicata a un podcast può contenere decine di file con nomi simili:

• episodio-finale.mp3
• episodio-finale-2.mp3
• episodio-corretto.mp3
• intervista-completa.wav
• montaggio-nuovo.mp4
• sottotitoli.srt
• note.txt

Finché si lavora sull’episodio più recente, è ancora possibile ricordare quale file sia quello corretto. Il problema appare più tardi, quando bisogna recuperare una citazione, correggere un nome, preparare una clip, aggiornare le note o capire quale versione sia stata effettivamente pubblicata.

Il file audio è soltanto una parte del progetto.

Un episodio completo comprende anche la registrazione originale, il montaggio approvato, la trascrizione, le correzioni, i capitoli, le note, i sottotitoli, le immagini, le autorizzazioni e i collegamenti alle piattaforme su cui è stato distribuito.

Organizzare questi elementi fin dall’inizio rende ogni episodio più facile da cercare, riutilizzare e verificare.

Partire da un identificatore stabile

Il titolo editoriale di un episodio può cambiare più volte.

Per questo motivo non dovrebbe essere l’unico elemento usato per collegare i file.

È meglio assegnare a ogni episodio un identificatore semplice e stabile, per esempio:

ep-042

Tutti i file possono quindi condividere lo stesso prefisso:

ep-042-recording-original.wav
ep-042-edit-v1.wav
ep-042-master-v2.mp3
ep-042-transcript-v2.md
ep-042-subtitles-v2.srt
ep-042-show-notes-v2.md
ep-042-cover.jpg

Il titolo visibile al pubblico può cambiare senza rompere la relazione tra i materiali.

L’identificatore può essere usato anche nelle cartelle, nel calendario editoriale e nei documenti condivisi.

Conservare separatamente originale e master

La registrazione originale e il file pubblicato non hanno lo stesso scopo.

La registrazione originale conserva tutto ciò che è stato catturato:

pause
errori
ripetizioni
prove tecniche
conversazioni eliminate
più tracce audio
rumori
materiale non destinato alla pubblicazione

Il master rappresenta invece la versione approvata e pronta per la distribuzione.

Non conviene sovrascrivere l’originale durante il montaggio. Se viene scoperto un taglio sbagliato o serve recuperare una frase, il materiale sorgente deve essere ancora disponibile.

Una struttura minima potrebbe essere:

ep-042/
  01-original/
  02-edit/
  03-master/
  04-transcript/
  05-subtitles/
  06-publication/

L’accesso alla cartella originale può essere più limitato, soprattutto se contiene conversazioni private o informazioni escluse dal montaggio finale.

Trascrivere la versione giusta

La trascrizione dovrebbe essere generata dalla versione che corrisponde al suo utilizzo.

Per cercare idee e citazioni presenti nell’intervista completa, può essere utile trascrivere la registrazione originale autorizzata.

Per creare capitoli, sottotitoli o note sincronizzate con l’episodio pubblicato, bisogna invece usare il master finale.

Se il montaggio elimina cinque minuti all’inizio, tutti i timestamp successivi cambiano. Una trascrizione creata prima di quel taglio non sarà più sincronizzata con la versione pubblicata.

Per un episodio audio, un flusso [MP3 to Transcript ](https://totext.app/)può creare una prima versione ricercabile con timestamp. Il testo automatico deve comunque essere considerato una bozza.

Prima di usarlo pubblicamente, è importante verificare almeno:

nomi delle persone
nomi di aziende e prodotti
date
cifre
luoghi
termini tecnici
citazioni dirette
attribuzione dei relatori

Una parola riempitiva riconosciuta male raramente crea un problema. Un cognome, una cifra o una citazione errata possono invece modificare il significato dell’episodio.

Collegare la trascrizione al master

Ogni trascrizione dovrebbe dichiarare chiaramente da quale file deriva.

All’inizio del documento si possono inserire alcuni metadati:

episode_id: ep-042
source_file: ep-042-master-v2.mp3
source_duration: 00:54:18
transcript_version: 2
review_status: reviewed
last_reviewed: 2026-08-03

In questo modo, chi apre il documento sa subito se la trascrizione corrisponde al file pubblicato.

Quando il master cambia, anche la trascrizione dovrebbe ricevere una nuova versione.

Non è necessario cancellare immediatamente la versione precedente, ma bisogna evitare che entrambe appaiano come documenti correnti.

Uno stato semplice può essere sufficiente:

draft
under-review
approved
obsolete
Non usare la trascrizione come testo finale

Una trascrizione conserva ciò che è stato detto.

Le note di un episodio devono invece aiutare il pubblico a capire cosa troverà.

Sono documenti diversi.

La trascrizione può contenere:

esitazioni
domande ripetute
correzioni
deviazioni dall’argomento
frasi incomplete
riferimenti comprensibili solo ascoltando l’audio

Le note possono estrarre:

tema principale
punti discussi
ospiti
risorse menzionate
capitoli
avvertenze
collegamenti verificati

Conviene mantenere la trascrizione come fonte e scrivere le note come documento separato.

Questo rende possibile migliorare la leggibilità senza fingere che il testo riscritto sia una citazione letterale.

Creare capitoli verificabili

I capitoli sono più utili quando descrivono un vero cambiamento di argomento.

Titoli generici come:

Introduzione
Parte 1
Parte 2
Conclusione

forniscono poche informazioni.

È meglio usare titoli specifici:

00:00 — Perché abbiamo iniziato il progetto
06:42 — Il primo errore nella scelta dell’attrezzatura
17:30 — Come è cambiato il processo di montaggio
31:12 — Costi, hosting e distribuzione
46:05 — Cosa faremmo diversamente oggi

I timestamp dovrebbero essere controllati sul master finale, non soltanto sulla trascrizione.

È utile anche verificare che il titolo non prometta qualcosa che in quel punto viene soltanto menzionato per pochi secondi.

Trattare i sottotitoli come una versione dipendente dal video

Per un podcast video, il file dei sottotitoli dipende direttamente dal montaggio.

Un flusso [MP4 to SRT](https://totext.app/mp4-to-srt/) può produrre una bozza temporizzata, ma il file SRT deve rimanere associato alla versione esatta del video.

Per esempio:

ep-042-video-v3.mp4
ep-042-video-v3-it.srt
ep-042-video-v3-en.srt

Se viene pubblicato video-v4.mp4, non bisogna presumere che i sottotitoli v3 siano ancora sincronizzati.

Prima della pubblicazione è utile controllare:

inizio del video
alcuni punti centrali
ultimi minuti
cambi di relatore
dialoghi veloci
nomi propri
sezioni tagliate durante il montaggio
eventuale deriva progressiva dei timestamp

Un file tecnicamente valido può comunque essere difficile da leggere o non corrispondere più al video.

Conservare un registro delle citazioni

Le citazioni vengono spesso estratte settimane o mesi dopo la pubblicazione.

Può essere utile mantenere un piccolo documento separato:

EPISODIO: ep-042

00:08:14
Relatore: Ospite
Citazione verificata:
“Non avevamo un problema di strumenti, ma di responsabilità.”

Uso consentito:
Newsletter, sito e social.

Stato:
Verificata sul master v2.

Il registro dovrebbe distinguere tra:

citazione esatta
citazione leggermente modificata
parafrasi
passaggio non ancora verificato
contenuto non autorizzato per usi promozionali

Una frase può sembrare perfetta nella trascrizione ma risultare fuorviante senza la domanda precedente o la spiegazione successiva.

Registrare anche la pubblicazione

L’archivio dovrebbe indicare dove è stato pubblicato l’episodio.

Per esempio:

published_at: 2026-08-03
website: published
rss: published
youtube: published
newsletter: sent
transcript_public: no
subtitles_it: published
subtitles_en: pending

Questo evita di dover controllare manualmente ogni piattaforma quando viene aggiornata una descrizione o corretto un collegamento.

È utile conservare anche:

titolo definitivo
descrizione definitiva
immagine usata
URL canonico
data di pubblicazione
eventuali correzioni successive
Non conservare tutto automaticamente

Archiviare non significa conservare ogni file per sempre.

La registrazione originale può contenere dati che non appaiono nell’episodio finale:

recapiti personali
conversazioni escluse
indicazioni tecniche
nomi non autorizzati
informazioni riservate
parti registrate prima dell’inizio ufficiale

Per ogni tipo di file dovrebbe esistere una regola di conservazione.

Un esempio:

Registrazione originale: 90 giorni dopo la pubblicazione
Master pubblicato: conservazione permanente
Trascrizione approvata: finché l’episodio resta online
File temporanei: cancellazione dopo il controllo finale
Link di condivisione: disattivazione dopo la consegna

Le durate dipendono dal progetto e dagli accordi con gli ospiti.

È importante ricordare che cancellare l’audio non elimina automaticamente:

trascrizioni
sottotitoli
riassunti
estratti
copie scaricate
file condivisi
indici di ricerca

La cancellazione deve includere anche i dati derivati quando non esiste più un motivo per conservarli.

Una checklist minima per ogni episodio

Prima di considerare chiuso un progetto, si può controllare:

L’episodio ha un identificatore stabile?
La registrazione originale è separata dal master?
È chiaro quale master è stato pubblicato?
La trascrizione indica il file sorgente?
Nomi, cifre e citazioni sono stati verificati?
Capitoli e timestamp corrispondono al master?
I sottotitoli hanno la stessa versione del video?
Le note contengono soltanto collegamenti verificati?
Le autorizzazioni degli ospiti sono archiviate?
È registrato dove è stato pubblicato l’episodio?
I file temporanei possono essere eliminati?
Esiste una data per la revisione o la cancellazione?
Il vantaggio appare nel tempo

Organizzare un solo episodio in questo modo può sembrare un lavoro aggiuntivo.

Il vantaggio diventa evidente quando gli episodi sono cinquanta o cento.

Un archivio coerente permette di:

ritrovare una citazione
creare una raccolta tematica
aggiornare vecchie note
correggere un nome
recuperare una traccia originale
pubblicare sottotitoli in un’altra lingua
capire quale versione è online
eliminare materiali che non devono più essere conservati

Il vero archivio non è una cartella piena di MP3.

È l’insieme di relazioni tra sorgente, versione pubblicata, testo, metadati e autorizzazioni.

Domanda per chi produce podcast

Come organizzate i materiali dopo la pubblicazione?

Conservate la registrazione originale oppure soltanto il master?

Usate un identificatore stabile per collegare audio, trascrizione, note e sottotitoli?

E soprattutto: dopo quanto tempo eliminate i file di lavorazione?

Nota di trasparenza: collaboro al progetto di trascrizione menzionato nel post. Ho inserito i link perché sono esempi diretti dei due passaggi descritti; il metodo di archiviazione resta valido anche utilizzando strumenti diversi.

California data brokers must start deleting personal data requests Aug. 1

How Rogue Officers Turned a Nationwide Camera Network Into a Tool for Stalking

cross-posted from: https://piefed.world/c/tech/p/1304793/how-rogue-officers-turned-a-nationwide-camera-network-into-a-tool-for-stalking

Flock’s array of license-plate cameras was built to fight crime. But at least 50 law enforcement officers were charged with or accused of misusing it and other systems.

New York is suing prediction market Kalshi, calling it an illegal gambling operation

Apple engineer says he was fired after refusing to send customer device IDs to AT&T

cross-posted from: https://piefed.world/c/tech/p/1304483/apple-engineer-says-he-was-fired-after-refusing-to-send-customer-device-ids-to-at-t

A 16-year employee alleges Apple’s carrier team shared IMEI numbers through unsecured email without required customer releases. Apple denies wrongdoing and says he was fired for just cause. A jury trial is set for November 2027.

Two research efforts gave AI the same open problem. Their papers were submitted three hours apart ... raising new questions about independent discovery and scientific credit.

Alibaba’s AI model Qwen3.8-Max made widely accessible ahead of open-weights release: Flagship 2.4 trillion parameter model highlights native multimodal capabilities and ... agentic tasks.

Finally some good news from #Signal 🥳