Con One UI 8.5, Samsung sta democratizzando alcune delle funzionalità fotografiche più apprezzate della gamma Galaxy, portandole finalmente anche sui modelli di fascia media. La protagonista di questa espansione è Camera Assistant, il modulo avanzato che permette di affinare il comportamento della fotocamera ben oltre le impostazioni standard.

Cos’è Camera Assistant e perché è importante

Camera Assistant è un modulo disponibile tramite Good Lock o Galaxy Store che estende le opzioni della fotocamera nativa Samsung. Non sostituisce l’app fotocamera, ma aggiunge uno strato di controllo granulare che gli appassionati di fotografia mobile apprezzeranno. Tra le funzioni disponibili si trovano:

• Controllo del cambio automatico tra le lenti
• Regolazione della velocità dello shutter
• Impostazioni di nitidezza e morbidezza per foto e video
• Attivazione/disattivazione dell’Auto HDR
• Registrazione video in HDR10+
• Regolazione del numero di scatti nel timer
• Aggiunta di scorciatoie per lo zoom

I nuovi modelli supportati con One UI 8.5

Fino ad ora Camera Assistant era disponibile principalmente sui Galaxy S di fascia alta e su alcuni Galaxy A5x. Con One UI 8.5, il supporto si allarga in modo significativo, includendo:

• Galaxy A37, A36, A35, A34
• Galaxy M36, M35, M34

Si tratta di dispositivi di fascia media molto diffusi, che ora possono offrire un’esperienza fotografica più personalizzabile.

La strategia Samsung: funzioni premium per tutti

L’espansione di Camera Assistant rispecchia una tendenza più ampia di Samsung: ridurre il gap tra i modelli premium e quelli di fascia media in termini di software. Già con le ultime versioni di One UI, molte funzioni Galaxy AI erano state estese ai modelli più economici. Ora tocca alle funzionalità fotografiche avanzate fare lo stesso percorso.

Per chi possiede un Galaxy di fascia media e vuole esprimere al massimo il potenziale della propria fotocamera, il consiglio è di verificare la disponibilità dell’aggiornamento One UI 8.5 e di esplorare Camera Assistant non appena disponibile.

Nothing ha ufficialmente lanciato il Nothing Phone (4a), il suo nuovo smartphone di fascia media che porta avanti il design iconico con il retro trasparente e le luci Glyph. Il dispositivo si posiziona come una valida alternativa per chi cerca un’esperienza Android diversa dal solito, senza dover spendere una fortuna.

Design e identità: l’eredità Glyph continua

Come i suoi predecessori, il Nothing Phone (4a) porta il caratteristico retro trasparente che lascia intravedere i componenti interni — un elemento che ha reso Nothing immediatamente riconoscibile nel panorama Android. Le luci Glyph, che fungono da notifiche visive personalizzabili, sono naturalmente presenti e ulteriormente perfezionate rispetto alle generazioni precedenti.

Posizionamento di prezzo

Il Nothing Phone (4a) viene proposto a un prezzo di listino di 59.800 yen in Giappone — equivalente a circa 370 euro al cambio attuale — nella configurazione da 8 GB di RAM e 128 GB di storage. Si tratta di un posizionamento competitivo che lo mette in diretta concorrenza con i mid-range di Xiaomi, Google Pixel 9a e la fascia media di Samsung.

Nothing OS: la vera differenza

Il punto di forza del Phone (4a) non è solo il design, ma anche il software. Nothing OS è una delle interfacce Android più pulite e veloci disponibili sul mercato, con un approccio minimalista che punta alla fluidità e alla semplicità. Gli aggiornamenti software sono garantiti per diversi anni, rendendolo un investimento più solido nel lungo periodo.

Per il pubblico italiano appassionato di Android, il Nothing Phone (4a) rappresenta una delle scelte più originali nella fascia di prezzo media. Chi cerca qualcosa di diverso dai soliti Samsung, Xiaomi o Google, ma non vuole spendere quanto un flagship, troverà nel 4a un candidato decisamente interessante.

Brutte notizie in vista per chi sta pensando di acquistare un Galaxy di fascia alta: Samsung starebbe valutando un aumento dei prezzi per alcuni modelli smartphone, a causa del continuo rialzo dei costi dei componenti di memoria. Secondo le ultime indiscrezioni, i primi mercati a essere interessati potrebbero essere quelli europei, già a partire da giugno 2026.

Galaxy Z Fold7 e Z Flip7 nel mirino: fino a 100 euro in più

Stando alle fonti, i modelli più a rischio di ritocco al rialzo sarebbero i prossimi pieghevoli Galaxy Z Fold7 e Galaxy Z Flip7, con aumenti stimati attorno ai 100 euro rispetto alle generazioni precedenti. Anche la serie Galaxy S potrebbe non essere esclusa, sebbene i dettagli sui modelli specifici non siano ancora chiari.

Il DRAM alle stelle: i produttori non riescono più ad assorbire i costi

Il problema di fondo è l’impennata dei prezzi di DRAM e memorie NAND, in crescita ben oltre le aspettative. Fino a qualche tempo fa i produttori riuscivano a tamponare questi rincari grazie a ottimizzazioni interne, ma il livello attuale sembra aver superato la soglia di sostenibilità. I moderni smartphone di fascia alta incorporano quantità crescenti di RAM — spinti dalle funzioni AI sempre più intensive — e questo li rende particolarmente vulnerabili alle fluttuazioni dei prezzi della memoria.

Un problema che potrebbe riguardare tutto il mercato Android

Attenzione: Samsung non è l’unico produttore a fronteggiare questa situazione. Gli analisti di settore avvertono che, entro la seconda metà del 2026, la carenza di memorie potrebbe acuirsi ulteriormente, trascinando in alto i prezzi di molti altri marchi Android — e potenzialmente anche Apple. Chi sta pianificando un acquisto nei prossimi mesi farebbe bene a non rimandare troppo a lungo.

Il driver grafico NVIDIA per sistemi GNU/Linux rappresenta la versione proprietaria sviluppata da NVIDIA per garantire prestazioni elevate, stabilità e compatibilità avanzata sulle distribuzioni GNU/Linux, oltre che su FreeBSD e Solaris. Questo driver nasce...

🔗 Leggi il post completo

AlmaLinux è una distribuzione GNU/Linux completamente libera e open source, progettata come alternativa compatibile a Red Hat Enterprise Linux (RHEL), il sistema operativo commerciale di riferimento nel settore aziendale. RHEL è una piattaforma enterprise...

🔗 Leggi il post completo

Introduzione

Con il rilascio di .NET 11 Preview 1, Microsoft ha introdotto uno dei cambiamenti architetturali più significativi nella storia dell’async in .NET: il Runtime Async V2. Questo cambiamento sposta la responsabilità della gestione delle operazioni asincrone dal compilatore al runtime stesso, con impatti concreti su debug, profiling, leggibilità degli stack trace e potenzialmente sulle prestazioni.

In questo articolo analizziamo nel dettaglio come funziona il nuovo modello, come differisce dall’approccio attuale basato su state machine, come abilitarlo nei propri progetti e cosa aggiunge .NET 11 Preview 1 oltre al solo Runtime Async.

Il problema: le state machine del compilatore

Chiunque abbia lavorato seriamente con codice asincrono in C# conosce la frustrazione di leggere uno stack trace in produzione e trovarsi sommerso da frame generati dal compilatore. Ogni metodo async viene trasformato dal compilatore in una classe di stato (state machine) che implementa IAsyncStateMachine. Questa trasformazione è efficace, ma introduce livelli di indirezione che offuscano la reale catena di chiamate.

Un semplice stack di tre metodi async produce tipicamente oltre dieci frame nello stack trace live, la maggior parte appartenenti all’infrastruttura del compilatore (AsyncMethodBuilderCore.Start, ecc.). Il risultato è un debug più laborioso e strumenti di profiling che faticano a restituire una visione chiara dell’esecuzione.

Runtime Async V2: come funziona

Con Runtime Async, il compilatore non genera più la state machine. Emette invece un IL semplificato, annotato con [MethodImpl(MethodImplOptions.Async)], e delega al runtime la gestione della sospensione e ripresa dei metodi asincroni. In pratica, è il CLR stesso a tracciare l’esecuzione asincrona, non il codice generato dal compilatore.

Il risultato più visibile è nei live stack trace, ovvero ciò che profiler, debugger e new StackTrace() vedono durante l’esecuzione. Con Runtime Async, i metodi effettivi appaiono direttamente nello stack, senza wrapper di stato.

Confronto diretto degli stack trace

Consideriamo questo codice di esempio:

await OuterAsync();

static async Task OuterAsync()
{
    await Task.CompletedTask;
    await MiddleAsync();
}

static async Task MiddleAsync()
{
    await Task.CompletedTask;
    await InnerAsync();
}

static async Task InnerAsync()
{
    await Task.CompletedTask;
    Console.WriteLine(new StackTrace(fNeedFileInfo: true));
}

at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
at Program.<<Main>$>g__InnerAsync|0_2()
at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
at Program.<<Main>$>g__MiddleAsync|0_1()
at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
...
(13 frame totali)

at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
at Program.<Main>$(String[] args) in Program.cs:line 3
at Program.<Main>(String[] args)

Miglioramenti al debugging

Con Runtime Async, il debugger può finalmente fare ciò che ci si aspetterebbe da sempre:

• I breakpoint all’interno di metodi async si associano correttamente, senza essere deviati su codice generato
• È possibile fare step-through attraverso i boundary degli await senza “saltare” nell’infrastruttura del compilatore
• La finestra call stack del debugger mostra la catena reale, non i wrapper di stato

Questi miglioramenti avvantaggiano qualsiasi strumento che ispeziona lo stack live: profiler come dotTrace, logging diagnostico, e naturalmente il debugger integrato di Visual Studio e VS Code.

Come abilitare Runtime Async nel proprio progetto

Runtime Async è una feature in anteprima che richiede opt-in esplicito. Aggiungere le seguenti proprietà al file .csproj:

<PropertyGroup>
  <Features>runtime-async=on</Features>
  <EnablePreviewFeatures>true</EnablePreviewFeatures>
</PropertyGroup>

Requisiti hardware aggiornati

.NET 11 alza il baseline hardware richiesto. Per x86/x64, il minimo passa da x86-64-v1 a x86-64-v2, richiedendo istruzioni aggiuntive come SSE3, SSSE3, SSE4.1, SSE4.2 e POPCNT. Questo rientra nei requisiti già imposti da Windows 11 e copre tutta l’hardware Intel/AMD attualmente supportato ufficialmente (i chip più vecchi sono usciti dal supporto intorno al 2013).

Per Arm64 su Windows, il baseline aggiunge ora il requisito dell’instruction set LSE, richiesto da Windows 11 e da tutti gli Arm64 supportati da Windows 10.

Altre novità di .NET 11 Preview 1

Supporto nativo a Zstandard

Le librerie guadagnano il supporto nativo alla compressione Zstandard tramite la nuova classe ZstandardStream. Zstandard offre rapporti di compressione migliori rispetto a gzip con velocità di decompressione molto elevate — un’aggiunta benvenuta per pipeline di dati e API ad alta frequenza.

BFloat16 per AI e ML

Arriva il tipo BFloat16 (Brain Float 16), un formato floating-point a 16 bit nato per carichi di lavoro di machine learning. È ampiamente usato da librerie AI come TensorFlow e PyTorch, e la sua presenza nativa in .NET facilita l’integrazione con modelli ML senza conversioni intermedie.

Miglioramenti JIT

• Eliminazione dei bounds check: il JIT elimina ora i controlli ridondanti sul pattern i + cns < len, comune nei loop su array e Span
• Rimozione di contesti checked ridondanti: quando un valore è già noto essere nel range, i controlli di overflow vengono rimossi
• Devirtualizzazione in ReadyToRun: le immagini R2R possono ora devirtualizzare chiamate a virtual method generici non condivisi

Miglioramenti VM

Su piattaforme senza JIT (come iOS), l’interface dispatch ora usa un meccanismo di cache con miglioramenti di performance fino a 200x in codice ad alta intensità di interfacce. Guid.NewGuid() su Linux migliora del 12% circa usando la syscall getrandom() con batch caching.

C# 15: prime anticipazioni

.NET 11 Preview 1 include anche le prime feature di C# 15. Tra quelle già disponibili:

• Collection expression arguments: possibilità di specificare capacità, comparatori o altri parametri del costruttore direttamente nella sintassi delle espressioni di collezione
• Extended layout support: il compilatore emette TypeAttributes.ExtendedLayout per tipi annotati con ExtendedLayoutAttribute, principalmente per scenari di interop

Conclusione

Il Runtime Async V2 rappresenta un passo importante verso un’esperienza di sviluppo asincrono più trasparente e debuggabile in .NET. Non è ancora pronto per la produzione, ma la direzione è chiara: Microsoft vuole che gli sviluppatori smettano di combattere con stack trace incomprensibili e possano finalmente fare debug dell’async come del codice sincrono.

Con .NET 11 previsto per novembre 2026 come Standard Term Support (STS), c’è ancora tempo per sperimentare e contribuire al processo di feedback prima del rilascio finale.

Fonte: What’s new in the .NET 11 runtime — Microsoft Learn | InfoQ: .NET 11 Preview 1

Avete le GPU. Magari un paio di NVIDIA A100 in un rack, alcune RTX 4090 sotto le scrivanie, o un cluster con hardware misto. Avete la potenza di calcolo. Bene. Adesso, però, viene il problema vero: come gestirla?

Capire quali modelli entrano in quale scheda, come bilanciare il carico tra più macchine, come gestire un nodo che cade alle 2 di notte, e come esporre tutto questo come una API pulita che il team di sviluppo possa effettivamente chiamare — questa è la parte che manda in crisi la maggior parte dei team. Il risultato tipico è una raccolta fragile di script Python e crontab entries che nessuno tocca da anni e che funzionano finché non smettono di funzionare.

GPUStack è stato costruito precisamente per risolvere questo problema.

Cos’è GPUStack?

GPUStack è uno strumento open source (licenza Apache 2.0) per la gestione di cluster GPU destinati all’inferenza AI. Pensatelo come Kubernetes per i vostri workload di inferenza, senza la necessità di passare tre giorni a debuggare un errore di indentazione in un Helm chart.

Al suo nucleo, GPUStack fa tre cose bene:

• Aggrega le GPU: che l’hardware sia su bare-metal, pod Kubernetes o istanze cloud, GPUStack le vede tutte come un unico pool di compute. Una dashboard, visibilità completa.
• Orchestrare gli inference engine: GPUStack si integra con vLLM, SGLang e TensorRT-LLM, sceglie il motore giusto per il job, lo configura e ne gestisce il ciclo di vita.
• Espone i modelli via API OpenAI-compatibile: una volta deployato un modello, il team applicativo ottiene un endpoint REST familiare. Nessuna libreria client custom. Nessun protocollo nuovo da imparare. Solo cambiare il base URL.

Installazione in meno di 5 minuti

Step 1 — Avviare il server di controllo

Vi serve una macchina per il control plane. Non deve nemmeno avere una GPU — un box CPU-only è sufficiente per il ruolo di server:

sudo docker run -d --name gpustack   --restart unless-stopped   -p 80:80   --volume gpustack-data:/var/lib/gpustack   gpustack/gpustack

Step 2 — Aggiungere i worker GPU

Su ogni nodo worker, assicuratevi di avere installato NVIDIA driver e NVIDIA Container Toolkit, poi eseguite:

sudo docker run -d --name gpustack-worker   --restart unless-stopped   --gpus all   -e GPUSTACK_SERVER_URL=http://<ip-server>   -e GPUSTACK_TOKEN=<vostro-token>   gpustack/gpustack

Nota pratica: la parte più difficile non è eseguire il comando worker, ma installare correttamente driver e toolkit sull’host. Verificate sempre la compatibilità tra versione del driver NVIDIA, versione CUDA e container runtime prima di procedere.

Step 3 — Deploy di un modello

Dalla web UI andate al catalogo modelli. GPUStack supporta il pull da Hugging Face e dall’Ollama Library. Selezionate un modello e cliccate “Deploy”.

Qui il scheduler dimostra il suo valore: legge i metadati del modello, calcola i requisiti di VRAM e compute, e determina quali worker possono gestirlo. Se il modello è troppo grande per una singola GPU, può distribuirlo su più schede (model sharding). Non dovete calcolare manualmente se un modello a 70B parametri entra nel vostro hardware: ci pensa GPUStack.

Step 4 — Chiamare l’API

Una volta che il modello è running, ottenete un endpoint OpenAI-compatibile. Recuperate una API key dalla dashboard e testate:

curl http://<ip-server>/v1/chat/completions   -H "Authorization: Bearer <api-key>"   -H "Content-Type: application/json"   -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Spiega la gestione di cluster GPU in un paragrafo."}
    ]
  }'

from openai import OpenAI

client = OpenAI(
    base_url="http://<ip-server>/v1",
    api_key="<api-key>"
)

response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "Hello from my own GPU cluster!"}]
)
print(response.choices[0].message.content)

Funzionalità Avanzate

Flessibilità Multi-Backend

GPUStack supporta vLLM, SGLang e TensorRT-LLM out of the box. Nessun motore di inferenza è il migliore per ogni workload:

• vLLM: eccellente per batch processing ad alto throughput
• TensorRT-LLM: massimizza le performance sull’hardware NVIDIA
• SGLang: ideale per la generazione strutturata

GPUStack vi permette di scegliere il motore giusto per ogni deployment, o di lasciare che il scheduler scelga per voi in base al workload.

Monitoraggio Integrato

GPUStack si integra nativamente con Grafana e Prometheus, offrendo dashboard in real-time per utilizzo GPU, consumo VRAM, token throughput e request rate dell’API. Non serve aggiungere uno stack di monitoraggio separato. Quando qualcosa si rompe alle 2 di notte, saprete esattamente quale GPU su quale macchina è il problema.

Recovery automatico dai guasti

Un nodo che cade a causa di un errore PCIe bus o un driver mismatch che si manifesta solo sotto carico pesante tipicamente porta la vostra API di inferenza a restituire 500 finché non intervenite manualmente. GPUStack rileva i nodi non raggiungibili e redistribuisce i workload automaticamente, eliminando la necessità di un intervento manuale d’emergenza.

Quando Usare GPUStack

GPUStack è la scelta giusta se:

• Avete 2 o più macchine GPU e volete servire LLM o altri modelli AI tramite una API unificata
• Volete eseguire inferenza sulla vostra hardware invece di pagare per token a un cloud provider — il risparmio sui costi a scala è reale
• Il vostro team non vuole diventare ingegneri di infrastruttura a tempo pieno solo per tenere i modelli in funzione

Forse non è la scelta giusta se:

• Avete una singola GPU e volete solo eseguire modelli localmente per uso personale: in quel caso Ollama è più semplice
• Siete già profondamente integrati in una piattaforma ML custom su Kubernetes con KubeFlow o simili, dove l’overlap potrebbe non valere l’investimento

Il Quadro Generale: l’Inferenza Self-Hosted è di Nuovo Praticabile

Il panorama dell’infrastruttura AI sta cambiando rapidamente. Un anno fa la maggior parte dei team optava automaticamente per API provider per l’inferenza. Oggi, con modelli open-weight sempre più capaci e costi GPU in calo, l’inferenza self-hosted è diventata un’opzione reale — non solo per i grandi player, ma per startup e aziende di medie dimensioni.

Il collo di bottiglia non è più l’hardware. Sono le operations: il codice collante tra “abbiamo le GPU” e “la nostra applicazione può chiamare un modello in modo affidabile”. GPUStack è un tentativo serio di risolvere questo gap, ed è open source sotto licenza Apache 2.0 — ispezionabile, modificabile e deployabile senza vendor lock-in.

Se avete hardware che al momento scalda solo la stanza server, o se siete stanchi di bollette di inferenza cloud che sembrano mutui, vale la pena provare. Il progetto è disponibile su GitHub.

Fonte originale: Self-Hosted Inference Doesn’t Have to Be a Nightmare: How to Use GPUStack — DZone

Comprare uno smartphone in Europa costa sempre di più. Secondo l’ultimo rapporto di Omdia, nel primo trimestre del 2026 il prezzo medio di vendita degli smartphone nel mercato europeo ha raggiunto i 580 euro, un nuovo massimo storico. Una tendenza che non accenna a invertirsi e che cambierà profondamente le abitudini d’acquisto dei consumatori.

I telefoni economici spariscono dagli scaffali

La causa principale di questa escalation è la rapida scomparsa dei dispositivi sotto i 200 euro. Questa fascia di prezzo, che una volta rappresentava una fetta importante del mercato, è scesa a meno di un quarto delle spedizioni totali. I produttori stanno abbandonando i margini risicati dell’entry-level per concentrarsi su modelli di fascia media e alta, dove i profitti sono ben più sostanziosi.

Nel complesso, le spedizioni europee nel Q1 2026 sono state 33,1 milioni di unità, in crescita del 2% anno su anno: la domanda tiene, ma lo fa su prodotti sempre più costosi.

Samsung prima, Apple in crescita, Xiaomi in difficoltà

Nel dettaglio dei brand, Samsung mantiene la leadership con il 38% del mercato, supportata in parte dagli sconti sul Galaxy A16 4G — ma anche rallentata dai ritardi nell’uscita dei nuovi Galaxy S26, A57 e A37. Apple invece cresce del 9% nelle spedizioni, grazie a iPhone 17 ma anche ai modelli più economici come iPhone 16e, venduti senza grandi sconti.

Xiaomi soffre: -15% nelle spedizioni, penalizzata da problemi di fornitura. Tuttavia, anche per il marchio cinese il prezzo medio è salito del 21%, segno di un riposizionamento verso l’alto condiviso da praticamente tutti i produttori.

Cosa significa per i consumatori italiani

Per chi è alla ricerca di un buon smartphone a prezzo contenuto, il panorama si fa sempre più complicato. I modelli economici di qualità si riducono, e quelli che rimangono tendono a essere aggiornati meno frequentemente. Scegliere bene diventa fondamentale: meglio aspettare offerte sui modelli dell’anno precedente o puntare su brand come Realme, Poco o Honor che per ora continuano a presidiare il segmento accessibile.

Le indiscrezioni sul prossimo Galaxy S27 di Samsung si fanno sempre più interessanti, e riguardano soprattutto la configurazione fotografica del modello Pro. Secondo le ultime informazioni trapelate, Galaxy S27 Pro potrebbe non solo colmare il divario con l’Ultra, ma addirittura superarlo in alcune situazioni di scatto.

Zoom diverso ma non necessariamente inferiore

Stando ai leak, Galaxy S27 Pro e Galaxy S27 Ultra condivideranno lo stesso sensore principale e la stessa fotocamera ultra-grandangolare. La vera differenza si troverà nella lente telefoto: il modello Pro monterà un sensore da 50 MP con zoom ottico 3,5x, mentre l’Ultra punterà su uno zoom 5x.

A prima vista sembrerebbe una vittoria per l’Ultra, ma la situazione è più complessa. Samsung sta potenziando le tecniche di crop digitale basate sul sensore principale da 200 MP, rendendo la semplice comparazione dei valori di ingrandimento ottico meno significativa rispetto al passato. In certe condizioni, il 3,5x del Pro potrebbe risultare più versatile e naturale nel campo visivo rispetto al 5x.

Addio al doppio zoom sull’Ultra

Un’altra novità riguarda l’Ultra: il tradizionale obiettivo 3x presente sulle versioni precedenti verrebbe eliminato. Era una lacuna da tempo segnalata dagli utenti, che si trovavano un salto brusco tra il grandangolo e il teleobiettivo 5x. Con la nuova configurazione, questa debolezza potrebbe finalmente essere risolta.

Galaxy S27 Pro: il flagship “compatto” per gli esigenti

L’immagine che emerge è quella di un Galaxy S27 Pro che punta a ridefinire il concetto di “modello intermedio” nella gamma Samsung. Non più semplicemente un passo indietro rispetto all’Ultra, ma una valida alternativa con un proprio punto di forza: compattezza maggiore e fotocamera equilibrata.

Per chi non necessita dell’enorme display o dello stilo dell’Ultra, il Pro potrebbe rivelarsi la scelta più razionale — e forse persino superiore in determinati contesti fotografici. Resta da vedere se queste specifiche verranno confermate con l’arrivo ufficiale del dispositivo, atteso presumibilmente all’inizio del 2027.

I risultati di Xiaomi per il primo trimestre del 2026 raccontano una storia di trasformazione: meno smartphone venduti, ma a prezzi più alti. Un cambio di strategia deliberato, che spinge il produttore cinese verso il segmento premium del mercato.

Spedizioni in calo, ma il terzo posto è mantenuto

Nel primo trimestre 2026, Xiaomi ha spedito 33,8 milioni di smartphone, con un calo del 19,2% rispetto allo stesso periodo dell’anno precedente — la contrazione più significativa tra i primi cinque produttori mondiali. Nonostante ciò, l’azienda conserva la terza posizione globale, davanti a OPPO (-6,6%) e vivo (-6,7%).

Al contrario, Samsung e Apple hanno registrato rispettivamente +8,0% e +9,9%, confermando la solidità del segmento alto di gamma.

Prezzi medi in salita del 8% anno su anno

Il dato più rilevante è l’aumento del prezzo medio di vendita (ASP): da 1.211 a 1.310 yuan cinesi, con una crescita di circa l’8% su base annua. Xiaomi sta chiaramente scommettendo su modelli come la serie Xiaomi 17 e 15T per alzare il profilo del brand nel segmento medio-alto e premium.

Forte presenza anche nel wearable

Non solo smartphone: Xiaomi mantiene la terza posizione mondiale e la seconda in Cina nel mercato delle smartband, e si piazza seconda globalmente e in Cina nel segmento degli auricolari true wireless (TWS). Un ecosistema accessori sempre più solido, che complementa l’offerta mobile.

Geograficamente, Xiaomi è seconda in America Latina, terza in Europa, Africa, Medio Oriente e Sud-Est asiatico, e quarta in India. Un’impronta globale che — nonostante i numeri in calo — rimane ampia e difficile da ignorare.

La sfida ora è capire se il riposizionamento verso l’alto darà i frutti sperati nel medio termine, o se il calo di volumi si rifletterà anche sulla redditività complessiva del segmento smartphone.

Labwc è un compositor Wayland leggero progettato per offrire un ambiente grafico essenziale, veloce e completamente personalizzabile. Il progetto nasce con l’obiettivo di riprodurre l’esperienza di Openbox nel contesto moderno di Wayland, il protocollo...

🔗 Leggi il post completo

Si parla di:
Toggle

Un attore di minacce non ancora attribuito ha sfruttato una vulnerabilità zero-day nel sistema LMS KnowledgeDeliver, sviluppato dalla giapponese Digital Knowledge, per ottenere Remote Code Execution non autenticato e distribuire la web shell in-memory BLUEBEAM. L’indagine di Mandiant rivela un attacco sofisticato a più strati: dalla deserialization di ViewState ASP.NET al social engineering degli utenti finali con un falso plugin di autenticazione che installa Cobalt Strike BEACON, personalizzato per organizzazione. Una vulnerabilità che colpisce sistemi universitari e aziendali in tutto il mondo a causa di una scelta progettuale fatale: chiavi crittografiche condivise tra tutte le installazioni.

La radice del problema: chiavi macchina hardcoded

KnowledgeDeliver è un Learning Management System (LMS) enterprise ampiamente utilizzato in Giappone e in numerosi contesti educativi e corporate internazionali. Come molte applicazioni ASP.NET, utilizza la funzionalità ViewState per preservare lo stato delle pagine web tra una richiesta e l’altra. ViewState è protetto tramite una machineKey: una coppia di chiavi crittografiche (validationKey + decryptionKey) che garantiscono l’autenticità e la riservatezza dei dati serializzati inviati tra client e server.

Il difetto critico di KnowledgeDeliver, ora tracciato come CVE-2026-5426, consiste nell’utilizzo di valori machineKey statici e identici in tutte le installazioni del prodotto. Digital Knowledge distribuiva il software con chiavi hardcoded nel file web.config, anziché generare valori unici per deployment. Il risultato è devastante: chiunque abbia accesso a una singola installazione — anche la propria — può ricavare le chiavi e usarle per forgiare payload ViewState malevoli validi su qualunque altro server che esegue KnowledgeDeliver nel mondo.

La catena di attacco: da ViewState a RCE

L’exploitation della vulnerabilità segue un pattern ben documentato, già osservato in attacchi a Sitecore e in campagne evidenziate da Microsoft riguardanti chiavi macchina esposte. L’attaccante costruisce un payload serializzato contenente istruzioni arbitrarie e lo inserisce nel parametro __VIEWSTATE di una normale richiesta HTTP. Il server ASP.NET, fidandosi della firma crittografica (valida perché l’attaccante conosce la chiave), deserializza il payload e lo esegue con i privilegi del processo IIS (tipicamente Network Service o Application Pool Identity).

L’intera operazione non richiede credenziali, autenticazione pregressa o interazione utente sul lato server. Un singolo POST HTTP con il ViewState artefatto è sufficiente a ottenere esecuzione di codice remoto. Mandiant ha datato la compromissione iniziale alla fine del 2025, suggerendo che l’attore fosse a conoscenza della vulnerabilità mesi prima della disclosure pubblica avvenuta il 24 febbraio 2026.

BLUEBEAM: la web shell fantasma

Una volta ottenuto il foothold iniziale, l’attaccante ha distribuito BLUEBEAM, una web shell .NET nota anche come Godzilla. Ciò che distingue BLUEBEAM dalle web shell tradizionali è la sua natura interamente in-memory: il malware non scrive file su disco ma viene caricato direttamente nel processo worker IIS (w3wp.exe), riducendo drasticamente la superficie di rilevamento per strumenti forensi e antivirus basati sulla scansione del filesystem.

BLUEBEAM comunica con il suo operatore tramite richieste HTTP POST cifrate, mascherandosi come normale traffico web. Attraverso questo canale, l’attaccante può eseguire comandi arbitrari, caricare ulteriori payload, modificare file e mantenere persistenza nell’ambiente compromes. Mandiant ha osservato l’uso del tool di sistema icacls per allargare i permessi sul filesystem, indebolendo ulteriormente i controlli di sicurezza dell’host compromesso.

Il vettore secondario: social engineering sugli utenti finali

L’attacco non si è fermato al server. Con l’accesso a w3wp.exe, l’attaccante ha manomesso i file JavaScript legittimi del portale LMS, iniettando codice malevolo nelle pagine visitate dagli studenti e dai dipendenti. Il codice iniettato mostrava un avviso di sicurezza convincente, informando l’utente della necessità di installare un “plugin di autenticazione” aggiuntivo per continuare ad accedere alla piattaforma. Parallelamente, caricava script da infrastruttura controllata dall’attaccante.

Gli utenti che installano il falso plugin vengono infettati con un Cobalt Strike BEACON, il framework di post-exploitation commerciale più abusato nel panorama delle minacce avanzate. L’elemento che rivela la natura mirata e pianificata dell’operazione è la personalizzazione del payload: il BEACON era cifrato con una chiave derivata dal nome dell’organizzazione vittima, dimostrando che l’attaccante aveva condotto ricognizione preventiva e aveva predisposto un payload ad hoc per ogni target.

Timeline degli eventi

• Fine 2025: Compromissione iniziale rilevata da Mandiant durante un incident response
• 24 febbraio 2026: Data limite per le installazioni vulnerabili (le versioni precedenti a questa data con machineKey di default sono esposte)
• 25 maggio 2026: Pubblicazione dell’advisory Mandiant/Google Cloud e assegnazione CVE-2026-5426

Indicatori di compromissione (IoC)

# BLUEBEAM web shell
SHA-256: 7c1f99dca8e5a7897892f9d224a6495023a2cfd2671697d229d355978c415ed2
File:    LoadLibrary.dll (caricato in-memory da w3wp.exe)
# CVE
CVE-2026-5426 – KnowledgeDeliver ASP.NET machineKey RCE (CVSS: critico)
# Segnali di detection
Windows Application Log - Event ID 1316 (ViewState validation failure/anomalia)
Processo: w3wp.exe che genera child process cmd.exe, powershell.exe, cscript.exe
File JS del portale modificati con tag 
User-Agent anomali nelle richieste POST a pagine .aspx (concatenazione di UA multipli)
Uso di icacls.exe da processi IIS per modifica permessi
# Pattern ViewState malevolo
Parametro __VIEWSTATE con lunghezza anomala (>50KB)
Richieste POST a pagine .aspx che non prevedono ViewState volumioso

Remediation e due righe per i difensori

La mitigazione primaria e indispensabile è la rotazione immediata dei valori machineKey a valori unici e crittograficamente robusti per ogni singola installazione. Le chiavi devono essere generate con un generatore di numeri casuali sicuro (CSPRNG) e non devono mai essere condivise tra ambienti diversi. La configurazione va inserita nel file web.config sotto il tag <system.web><machineKey validationKey="..." decryptionKey="..." />. Oltre alla remediation tecnica, le organizzazioni dovrebbero limitare l'accesso al portale LMS a range IP fidati, condurre threat hunting retrospettivo alla ricerca di sign of compromise elencati sopra, verificare l'integrità dei file JavaScript del portale tramite confronto hash, e investigare eventuali installazioni del presunto "plugin di autenticazione" sulle macchine degli utenti finali. Questo incidente è un promemoria sistematico del rischio insito nelle configurazioni di default condivise: una singola chiave hardcoded può trasformare un'applicazione enterprise globale in una superficie di attacco che compromette simultaneamente organizzazioni altrimenti non correlate.

Il progetto curl, come il Kernel Linux ed altri progetti open-source, è letteralmente sovrastato da report di sicurezza artificiali che sono validi, dettagliati e lunghi da analizzare.
A farne le spese è chi gestisce i progetti, ed il conto è salato, poiché impatta sulla vita familiare e gli affetti.

🔗 Leggi il post completo

nmap è uno degli strumenti più potenti e longevi nell’arsenale di qualsiasi sistemista Linux. Nato nel 1997, è oggi uno standard de facto per l’audit di rete, la verifica della superficie d’attacco esposta e il troubleshooting di connettività. Questa guida copre i comandi e le tecniche che un sysadmin usa davvero in produzione: niente teoria astratta, solo esempi concreti.

Nota legale: scansionate solo reti e host di vostra proprietà o per cui avete un’autorizzazione esplicita. La scansione non autorizzata può essere illegale nella vostra giurisdizione.

Installazione di nmap

nmap è disponibile nei repository di tutte le principali distribuzioni Linux:

# Debian / Ubuntu
sudo apt install nmap

# Fedora / RHEL / CentOS
sudo dnf install nmap

# Arch / Manjaro
sudo pacman -S nmap

nmap --version

Host Discovery: chi è attivo sulla rete?

Il primo passo in qualsiasi audit è capire quali host sono raggiungibili. Il ping scan usa il flag -sn, che dice a nmap di non eseguire scansioni delle porte:

nmap -sn 192.168.1.0/24

Nmap scan report for 192.168.1.1
Host is up (0.0011s latency).
MAC Address: A4:3E:51:XX:XX:XX (Ubiquiti Networks)

Nmap scan report for 192.168.1.10
Host is up (0.00032s latency).
MAC Address: DC:A6:32:XX:XX:XX (Raspberry Pi Trading)

Scansione delle Porte

Scansione di default

Senza flag aggiuntivi, nmap scansiona le 1.000 porte TCP più comuni. Non richiede root, ma i risultati sono meno dettagliati:

nmap 192.168.1.10

SYN Scan (Stealth Scan)

La SYN scan è la modalità default quando si esegue nmap come root. Invia un pacchetto SYN senza completare il three-way handshake TCP: più veloce e meno visibile nei log applicativi:

sudo nmap -sS 192.168.1.10

Scansione di tutte le 65.535 porte

Le 1.000 porte di default possono mancare servizi su porte non standard — MySQL su 33060, SSH spostato su 2222:

sudo nmap -sS -p- 192.168.1.10

Porte specifiche o range

# Porte specifiche
sudo nmap -p 22,80,443,3306 192.168.1.10

# Range di porte
sudo nmap -p 1-1024 192.168.1.10

UDP Scanning

L’UDP è spesso dimenticato. DNS (porta 53), SNMP (161) e NTP (123) girano su UDP e sono vettori comuni di attacco e misconfiguration:

sudo nmap -sU -p 53,161,123 192.168.1.1

Rilevamento di Servizi e Versioni

Il flag -sV esegue probe sulle porte aperte per determinare servizio e versione. È il primo scan da eseguire su un server sconosciuto:

sudo nmap -sV 192.168.1.10

PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.6
80/tcp   open  http    nginx 1.24.0
3306/tcp open  mysql   MySQL 8.0.35

Rilevamento del Sistema Operativo

nmap può fare ipotesi sull’OS basandosi sul fingerprinting del TCP/IP stack:

sudo nmap -O 192.168.1.10

OS details: Linux 5.15 - 5.19, Linux 6.1
Network Distance: 1 hop

Aggressive Scan: tutto in uno

Il flag -A abilita OS detection, version detection, script scanning e traceroute in un colpo solo:

sudo nmap -A 192.168.1.10

Nmap Scripting Engine (NSE)

L’NSE è ciò che distingue nmap da un semplice port scanner. Permette di eseguire script contro host e servizi scoperti. Gli script si trovano in /usr/share/nmap/scripts/ e coprono vulnerability detection, enumerazione di servizi e molto altro.

Verifiche pratiche

# Categoria default
sudo nmap --script=default 192.168.1.10

# Scansione vulnerabilità (più invasivo - usare deliberatamente)
sudo nmap --script=vuln 192.168.1.10

# FTP anonimo abilitato?
sudo nmap --script=ftp-anon -p 21 192.168.1.10

# Header HTTP esposti (versioni server, debug info)
sudo nmap --script=http-headers -p 80,443 192.168.1.10

# Open SMTP relay?
sudo nmap --script=smtp-open-relay -p 25 192.168.1.20

Per elencare tutti gli script disponibili per un servizio:

ls /usr/share/nmap/scripts/ | grep -i ssh

Formati di Output

Per qualunque cosa oltre un controllo rapido, salvare l’output è fondamentale:

# Output normale su file
sudo nmap -sV 192.168.1.0/24 -oN scan_results.txt

# XML (utile per automazione e import in altri tool)
sudo nmap -sV 192.168.1.0/24 -oX scan_results.xml

# Formato grepable
sudo nmap -sV 192.168.1.0/24 -oG scan_results.gnmap

# Tutti i formati in una volta sola
sudo nmap -sV 192.168.1.0/24 -oA scan_results

Timing e Velocità

nmap dispone di sei template di timing, da T0 (lentissimo) a T5 (aggressivo). Il default è T3. Per la maggior parte delle scansioni su reti locali affidabili:

sudo nmap -sS -T4 192.168.1.0/24

Combinazioni Pratiche per Sysadmin

Questi sono i comandi che si usano davvero nel lavoro quotidiano:

# Porte aperte su un host (solo quelle definitivamente aperte)
sudo nmap -sS -T4 --open 192.168.1.10

# Trovare tutti i server SSH su una subnet
sudo nmap -p 22 --open -sV 192.168.1.0/24

# MySQL esposto sulla rete? (non dovrebbe mai esserlo)
sudo nmap -p 3306 --open 192.168.1.0/24

# Host discovery + version scan concatenati (solo host attivi)
sudo nmap -sn 192.168.1.0/24 -oG - | grep "Up" | awk '{print $2}' | sudo nmap -sV -iL -

Gestione dei Target e Firewall

# Range di IP
nmap 192.168.1.1-50

# Host da file (uno per riga)
nmap -iL hosts.txt

# Escludere host dalla scansione
nmap 192.168.1.0/24 --exclude 192.168.1.1,192.168.1.5

Conclusione

Host discovery, port scanning, version detection, NSE scripts e salvataggio dell’output sono le fondamenta di nmap. Iniziate con -sn per la discovery, aggiungete -sV quando servono i dettagli sui servizi, portate gli script NSE quando volete approfondire. Mantenete il timing conservativo sulle reti di produzione e aggressivo nel vostro lab.

Se state verificando le regole firewall, nmap è tra i migliori strumenti per controllare che ciò che pensate sia bloccato lo sia davvero.

Fonte originale: nmap on Linux: Guide to Network Scanning and Discovery — LinuxBlog.io

Le architetture distribuite moderne sono progettate per la resilienza. Aggiungiamo retry per i fallimenti transitori, replica per la durabilità, autoscaling per l’elasticità, circuit breaker per l’isolamento. Ogni meccanismo, preso singolarmente, migliora la disponibilità. Ma sotto stress, la loro interazione può abbattere l’intero sistema.

La maggior parte delle interruzioni enterprise non è causata dall’assenza di fault tolerance. È causata da meccanismi di fault tolerance non delimitati che reagiscono simultaneamente. Questo articolo analizza il fenomeno del retry storm e mostra come progettare sistemi con bounded reliability.

1. Retry Storm: quando la resilienza moltiplica il traffico

I retry sono progettati per proteggere dai fallimenti temporanei. Ma i retry moltiplicano il carico. Ecco un esempio semplificato della logica di retry che si trova comunemente nei sistemi di integrazione tra servizi:

import time
import random

def downstream_service():
    latency = random.choice([0.1, 0.2, 0.8])
    time.sleep(latency)
    if latency > 0.7:
        raise TimeoutError("Slow response")
    return "OK"

def call_with_retries(max_attempts=3):
    for attempt in range(max_attempts):
        try:
            return downstream_service()
        except TimeoutError:
            print(f"Retry {attempt+1}")
    raise Exception("Failed after retries")

1. La latenza aumenta
2. Scattano i timeout
3. Ogni richiesta viene ritentata fino a 3 volte
4. Il traffico verso il backend triplica
5. Il backend rallenta ulteriormente
6. Aumentano i retry

In un’architettura a livelli tipica — Gateway → Experience API → Process API → System API → Database — se ogni livello gestisce i retry in modo indipendente, l’amplificazione del carico diventa moltiplicativa, non additiva. Un singolo rallentamento del database può abbattere tre livelli API a cascata in pochi minuti.

Il pattern Bounded Retry (sicuro per la produzione)

La soluzione non è eliminare i retry, ma delimitarli e renderli consapevoli del carico di sistema:

def call_with_bounded_retries(max_attempts=2, system_load=0.5):
    # Fail-fast quando il sistema è sotto stress
    if system_load > 0.75:
        return None

    for attempt in range(max_attempts):
        try:
            return downstream_service()
        except TimeoutError:
            # Exponential backoff con jitter
            backoff = 0.2 * (2 ** attempt)
            time.sleep(backoff + random.uniform(0, 0.1))
    return None

• Ceiling sui retry: massimo 2 tentativi invece di 3
• Exponential backoff: aumenta il tempo di attesa ad ogni tentativo
• Jitter: aggiunge variabilità casuale per evitare wave di retry sincronizzate
• Load-aware circuit: disabilita i retry completamente quando il sistema è sovraccarico

2. Fan-out della replica e collasso della coordinazione

La replica sincrona migliora la durabilità dei dati. Ma ogni write si moltiplica per il numero di repliche, aumentando il costo di coordinazione:

def write_to_replicas(data, replicas=3):
    for _ in range(replicas):
        time.sleep(0.2)  # Simula latenza di replica

La soluzione è la durabilità stratificata: non tutte le scritture richiedono le stesse garanzie. Le transazioni critiche usano replica completa; log ed eventi non critici ne richiedono meno. La reliability deve essere proporzionata, non massimizzata ciecamente.

3. Loop di feedback dell’autoscaling

L’autoscaling reagisce alle metriche di traffico. Ma se queste metriche sono gonfiate dai retry, il sistema escala in risposta a traffico artificiale:

def autoscale_safe(request_rate, sustained_load):
    # Scala su domanda sostenuta, non su spike da retry
    if sustained_load and request_rate > 120:
        print("Scaling up — domanda organica confermata")

• Domanda sostenuta (non spike improvvisi)
• Tendenze nella distribuzione della latenza (P95, P99)
• RPS organiche (esclusi i retry)
• Velocità di crescita delle code

4. Il problema reale: le reazioni correlate

Retry, replica e autoscaling reagiscono ciascuno a segnali diversi. Ma sotto stress, reagiscono tutti allo stesso segnale di degradazione. Questa correlazione crea il fallimento a cascata.

Scenario reale — payment reconciliation service:

1. La latenza dell’ERP sale a 700ms
2. Il servizio Billing va in timeout a 500ms
3. Billing ritenta 3 volte
4. La Process API ritenta l’orchestrazione
5. Il Gateway ritenta la richiesta client
6. L’autoscaling reagisce allo spike
7. Il lag di replica del database aumenta
8. La Dead Letter Queue inizia a riempirsi

In pochi minuti, un rallentamento minore diventa un’interruzione di piattaforma. La causa principale: reazione non delimitata.

5. Pattern di Bounded Reliability per sistemi API

Retry Budget

Il carico effettivo è: Carico Effettivo = RPS in ingresso × Numero Retry. Con 1.000 RPS e 3 retry, il backend riceve 3.000 richieste. Impostare un budget massimo di retry per richiesta e per servizio è non negoziabile in produzione.

Classificazione degli Errori

Non tutti gli errori sono retriable. Una tassonomia chiara:

I retry ciechi su errori di validazione o autenticazione sono debito architetturale.

Idempotency obbligatoria

I retry senza idempotency causano corruzione dei dati. Il transaction ID deve essere deterministic, non generato casualmente ad ogni tentativo:

# ❌ Non sicuro: genera un nuovo ID ad ogni retry
transaction_id = uuid()

# ✅ Sicuro: riusa l'ID dalla richiesta originale
transaction_id = payload.get("transaction_id") or request.headers["correlation-id"]

Dead Letter Queue con Osservabilità

Tracciare le seguenti metriche come segnali di early warning:

• Percentuale di retry sul totale delle richieste
• Frequenza dei timeout per endpoint
• Velocità di crescita della DLQ
• Shift nella distribuzione P95 della latenza

Conclusione

Le retry storm non iniziano con un fallimento catastrofico. Iniziano con un piccolo aumento di latenza, qualche timeout, una manciata di retry. Poi i meccanismi di fault tolerance reagiscono insieme — e la loro interazione non controllata trasforma un disagio minore in un’interruzione totale.

La resilienza nelle architetture distribuite non significa aggiungere più safety net. Significa controllare come quei safety net si comportano sotto stress. Delimita i retry. Classifica i fallimenti. Forza l’idempotency. Scala su domanda organica. Monitora i loop di feedback prima che si avvitino.

La differenza tra una piattaforma resiliente e un fallimento a cascata sta quasi sempre nella risposta a una sola domanda: i tuoi meccanismi di reliability sono controllati o sono illimitati?

Fonte: How Retry Storms Crash API-Led Systems: Bounded Reliability Patterns — DZone

OPPO ha annunciato ufficialmente per il mercato cinese i nuovi Reno 16 e Reno 16 Pro, portando in dote un impressionante set di specifiche che mette in discussione la distinzione tra fascia media e fascia alta. La serie debutta con la prima fotocamera da 200 megapixel su un Reno, una batteria da record e una resistenza all’acqua degna dei top di gamma più robusti.

Fotocamera da 200 MP con periscopio e OIS

Entrambi i modelli montano il sensore Samsung HP5 da 200 megapixel come fotocamera principale, affiancato da un grandangolo da 50 MP e da un teleobiettivo periscopico da 50 MP con zoom ottico 3,5x e stabilizzazione OIS. Anche la fotocamera frontale da 50 MP supporta l’autofocus, un dettaglio non scontato in questa fascia. Un comparto fotografico che molti top di gamma farebbero fatica a superare.

Batteria fino a 7.000 mAh: autonomia record

Il Reno 16 standard arriva con 6.700 mAh di capacità e ricarica rapida da 80W, mentre il Reno 16 Pro spinge fino a 7.000 mAh con l’aggiunta della ricarica wireless da 50W. In un’epoca in cui molti produttori faticano a superare i 5.500 mAh per i device di fascia medio-alta, questi numeri sono una dichiarazione di intenti precisa: Reno 16 vuole essere il compagno perfetto per chi non vuole preoccuparsi del caricabatterie.

Chip Dimensity, OLED a 120 Hz e impermeabilità totale

Sotto la scocca troviamo Dimensity 8550 SUPER nel modello base e Dimensity 9500s nel Pro, abbinati a memoria LPDDR5X e storage UFS 3.1. I display OLED da 6,32 e 6,78 pollici girano a 120 Hz, con supporto 10-bit e PWM ad alta frequenza per ridurre l’affaticamento visivo. Sul fronte resistenza, la serie raggiunge la certificazione IP69K — il massimo disponibile — oltre a IP68 e IP66.

Prezzi e disponibilità

In Cina i prezzi partono da 3.499 yuan per il Reno 16 e da 3.699 yuan per il Reno 16 Pro, con il top di gamma 16 GB + 1 TB che non supera i 5.000 yuan. OPPO ha già fatto capire che una versione globale della serie è in programma, con un possibile lancio internazionale tra giugno e luglio 2026.

Samsung non ha ancora annunciato il Galaxy S26 FE, ma le prime immagini leaked — attribuite ai produttori di cover — ci danno già un’idea di come sarà il prossimo Fan Edition. E la sorpresa è nel design: la classica disposizione delle tre fotocamere lascia spazio a un nuovo modulo verticale, più vicino all’estetica dei modelli Galaxy A di ultima generazione.

Un look che si allontana dalla serie S

Sui precedenti S23 FE, S24 FE e S25 FE le tre fotocamere erano disposte individualmente sulla scocca, in continuità con i flagship S. Il Galaxy S26 FE, stando alle immagini trapelate, adotterebbe invece una barra verticale per le fotocamere, simile a quella vista su Galaxy A37 e Galaxy A57. Il frontale rimane invece pressoché invariato: cornici sottili e foro punch-hole centrale, eredità del S25 FE.

Specifiche trapelate: Exynos 2500 e Android 17

Sul fronte hardware, un dispositivo attribuito al Galaxy S26 FE è già apparso su Geekbench con il chip Exynos 2500 — lo stesso SoC atteso sul Galaxy Z Flip 7. Le indiscrezioni parlano di un display da 6,7 pollici a 120 Hz, tripla fotocamera con zoom ottico 3x, batteria da 5.000 mAh, certificazione IP68 e ricarica wireless. L’OS sarà Android 17 con One UI 9, e Samsung garantirebbe 7 anni di aggiornamenti software.

Il FE sopravvive: ma piace il nuovo design?

La presenza di questi leak dissipa in buona parte i dubbi sulla continuazione della linea Fan Edition, che negli ultimi tempi aveva destato qualche perplessità. Tuttavia il cambio estetico potrebbe non piacere a tutti: chi ha sempre apprezzato il look premium del FE — con il design derivato direttamente dai flagship S — potrebbe trovare la nuova direzione meno appetibile. Il lancio è atteso per l’autunno 2026, probabilmente tra settembre e ottobre.

In attesa del lancio ufficiale, Sony ha pubblicato le sfondi ufficiali di Xperia 1 VIII, già scaricabili gratuitamente. Il nuovo flagship di Sony si rinnova nel design — con un modulo fotocamera completamente ridisegnato — e anche le immagini di sfondo rispecchiano questa svolta estetica, proponendo un look più ricercato rispetto ai modelli precedenti.

Design marmorizzato abbinato ai colori della scocca

Xperia 1 VIII sarà disponibile in quattro colorazioni: Graphite Black, Iolite Silver, Garnet Red e Native Gold. Per ciascuna è stata realizzata una sfondo con pattern marmorizzato astratto, pensato per richiamare le tonalità della scocca e trasmettere un senso di coerenza estetica tra hardware e software. In particolare, le varianti Garnet Red e Native Gold presentano sfondi decisamente più vivaci rispetto a quanto visto nelle precedenti generazioni di Xperia, conferendo ai nuovi colori ancora più carattere.

Otto sfondi statici e quattro live wallpaper

Il pacchetto comprende 8 sfondi statici in risoluzione 2160×2340 pixel, sufficienti per sfruttare appieno il display OLED dell’Xperia 1 VIII senza perdita di qualità. A questi si affiancano 4 live wallpaper animati, in linea con la tradizione Xperia di proporre animazioni eleganti e non invadenti. Tutte le immagini sono già disponibili per il download, anche su dispositivi di altri produttori.

Xperia 1 VIII: le specifiche principali

Dal punto di vista hardware, Xperia 1 VIII porta con sé Snapdragon 8 Elite Gen 5, un sensore fotografico principale da 1/1.56 pollici (quattro volte più grande rispetto alla generazione precedente nella fotocamera con teleobiettivo), batteria da 5.000 mAh e il jack audio da 3,5 mm — una rarità tra i flagship moderni. Sony conferma ancora una volta la propria filosofia orientata alla qualità audio e fotografica, rendendo Xperia 1 VIII uno dei dispositivi Android più attesi dagli appassionati.

Void Dokkaebi, il gruppo APT nordcoreano tracciato anche come Famous Chollima, ha completato una significativa evoluzione del proprio arsenale offensivo: il malware infostealer InvisibleFerret è stato ricompilato da Python a Cython, trasformando script leggibili in binari nativi che sfuggono alla quasi totalità dei meccanismi di rilevamento basati sull’analisi del codice sorgente. La ricerca pubblicata da Trend Micro a maggio 2026 rivela una campagna di spionaggio industriale di proporzioni allarmanti che colpisce sviluppatori software con accesso a wallet di criptovalute e infrastrutture CI/CD.

Profilo del gruppo: chi è Void Dokkaebi

Void Dokkaebi, denominato anche Famous Chollima nell’ecosistema di threat intelligence di CrowdStrike, è un intrusion set allineato agli interessi della Repubblica Popolare Democratica di Corea (RPDC). Il gruppo si distingue da altre unità cyber nordcoreane come Lazarus Group per la specializzazione quasi esclusiva nel targeting di sviluppatori software, ingegneri DevOps e professionisti del settore Web3 che detengono chiavi di firma, credenziali di wallet e accesso privilegiato a pipeline di continuous integration e deployment.

La sua tattica operativa preferita è quella del “fake job interview”: gli operatori si spacciano per recruiter di aziende crypto o AI rinominate, contattano le vittime su piattaforme come LinkedIn o GitHub, e le convincono a clonare ed eseguire repository di codice come parte di una presunta prova tecnica per un colloquio. Il codice in apparenza innocuo nasconde i payload malevoli.

La campagna del 2026: infrastruttura blockchain e repository compromessi

L’analisi condotta a marzo-maggio 2026 ha rivelato la portata impressionante dell’infrastruttura malevola costruita dal gruppo. I ricercatori hanno identificato:

• Oltre 750 repository GitHub infetti, molti appartenenti a organizzazioni legittime come DataStax e Neutralinojs, che presentano marcatori di infezione nei workflow CI/CD
• Più di 500 configurazioni di task Visual Studio Code modificate per eseguire payload al momento dell’apertura del progetto
• 101 istanze dello strumento di commit tampering utilizzato per iniettare codice malevolo nei repository

L’elemento più innovativo della campagna 2026 è l’utilizzo di infrastruttura blockchain per la distribuzione dei payload. Void Dokkaebi sfrutta Tron, Aptos e Binance Smart Chain come staging server per i malware, rendendo gli indicatori di compromissione praticamente immuni ai tradizionali meccanismi di takedown. Aggiornare un riferimento su blockchain equivale a cambiare il payload consegnato a tutte le vittime già infette, senza modificare un singolo byte nei repository.

L’evoluzione tecnica: da Python a Cython

Il cuore dell’aggiornamento analizzato da Trend Micro riguarda InvisibleFerret, il modulo infostealer centrale nell’arsenale di Void Dokkaebi. Precedentemente distribuito come script Python in chiaro — facilmente analizzabili e rilevabili da sistemi YARA e EDR — il malware è stato interamente ricompilato tramite Cython.

Cython è un compilatore che traduce codice Python in sorgente C/C++ e poi in binari nativi. Il risultato pratico è che InvisibleFerret viene ora distribuito come file .pyd su Windows (Python extension DLL) e come librerie condivise .so su macOS. Entrambi i formati sono binari compilati: non contengono stringhe leggibili, non sono interpretabili senza reverse engineering specializzato, e bypassano le regole di detection tradizionalmente scritte per identificare script Python sospetti.

Le capacità del malware rimangono invariate rispetto alle versioni precedenti:

• Apertura di backdoor per accesso remoto persistente
• Furto di credenziali dai principali browser (Chrome, Firefox, Edge)
• Monitoraggio degli appunti di sistema (clipboard hijacking per intercettare indirizzi di wallet)
• Keylogging per catturare password e seed phrase
• Esfiltrazione diretta da wallet di criptovalute locali
• Ricognizione dell’ambiente: processi in esecuzione, file system, variabili d’ambiente

Toolset correlato: BeaverTail, OtterCookie, OmniStealer

InvisibleFerret non opera mai isolatamente. Il gruppo lo utilizza in combinazione con altri malware della stessa famiglia operativa. BeaverTail è il dropper JavaScript iniziale che viene eseguito durante il “test tecnico”, il quale successivamente scarica e installa InvisibleFerret. OtterCookie è un ulteriore stealer focalizzato sui browser e sui file di configurazione. OmniStealer amplia la superficie di furto a client di posta e applicazioni VPN. Tutti questi componenti possono essere aggiornati dinamicamente tramite i reference blockchain, garantendo al gruppo una flessibilità operativa senza precedenti.

Indicatori di compromissione (IoC)

# File IOC - InvisibleFerret Cython (maggio 2026)
# Estensioni malevole su Windows
*.pyd  (file Python extension DLL con firma digitale assente o anomala)
# Estensioni malevole su macOS
*.so   (librerie condivise caricate da processi Python non standard)
# Pattern comportamentale
Processo Python che carica estensioni .pyd/.so non firmate da directory temp
Connessioni in uscita verso endpoint Tron/Aptos/BSC non previsti dall'applicazione
Lettura anomala del keychain macOS o del credential manager Windows
Accessi al filesystem wallet: ~/.bitcoin, ~/.ethereum, ~/.solana
# Infrastruttura C2 (blockchain-staged)
TRC20 address utilizzati come dead drop resolver su Tron network
Transazioni su Aptos con payload codificati nei campi memo

Due righe per i difensori

La migrazione a Cython rende obsolete le regole YARA basate su stringhe Python. I team di sicurezza devono aggiornare la propria postura difensiva su più livelli. A livello di endpoint, occorre implementare controlli di integrità sulle estensioni Python caricate dinamicamente e monitorare processi Python che importano moduli non presenti nell’ambiente di sviluppo ufficiale. A livello di rete, è essenziale bloccare o monitorare le connessioni verso endpoint RPC di reti blockchain non autorizzate (Tron API: api.trongrid.io, Aptos: fullnode.aptoslabs.com). A livello procedurale, le organizzazioni dovrebbero verificare l’identità dei recruiter prima di clonare ed eseguire qualsiasi repository fornito esternamente, e condurre i test tecnici in ambienti isolati (sandbox o VM senza credenziali di produzione). Gli sviluppatori che lavorano su progetti Web3 o che detengono wallet crypto devono essere considerati target ad alto rischio e ricevere formazione specifica sul riconoscimento di queste campagne di ingegneria sociale.

Sway è un compositor Wayland, cioè un componente che gestisce la visualizzazione grafica utilizzando il protocollo Wayland, progettato per sostituire il sistema grafico X11. All’interno di questa architettura moderna, Sway integra la funzionalità di gestore...

🔗 Leggi il post completo

Sony Xperia 10 VII è uno smartphone apprezzato per il suo display 21:9 e la leggerezza, ma le community internazionali stanno raccogliendo un numero crescente di segnalazioni riguardo ad alcune problematiche software e hardware. Ecco una panoramica completa dei bug più diffusi e dei workaround disponibili.

Fotocamera: video instabili all’avvio e esposizione automatica difettosa

Il problema più citato riguarda la registrazione video: nei primi 3-5 secondi dopo aver avviato una ripresa — sia in Full HD che in 4K — il filmato risulta estremamente scattoso. Il difetto sembra legato ai tempi di “risveglio” del processore Snapdragon 6 Gen 3 dallo stato di risparmio energetico. Il workaround suggerito è avviare una registrazione breve di prova prima di quella importante, oppure ritagliare i secondi iniziali in post-produzione.

Un secondo problema fotografico riguarda l’esposizione automatica in modalità Photo: anche in piena luce, il telefono tende a scegliere tempi di otturazione eccessivamente lunghi (1/30 s o simili), causando foto mosse. La soluzione è passare alla modalità manuale e impostare lo shutter speed a mano.

Sensore d’impronte e interferenze Wi-Fi/Bluetooth

Diversi utenti segnalano che il lettore di impronte digitali integrato nel tasto di accensione smette di rispondere quando lo schermo è spento. Il riconoscimento torna funzionante solo dopo aver premuto il tasto per accendere il display e poi riprovare. Un riavvio risolve temporaneamente il problema, ma questo tende a ripresentarsi.

Chi usa cuffie Bluetooth insieme al Wi-Fi attivo riscontra una degradazione del suono — descritto come “ovattato” o “sott’acqua” — causata da interferenze nella banda 2.4 GHz tra le due radio. Spegnere il Wi-Fi o passare alla banda 5 GHz può attenuare il fenomeno.

Problemi di ricarica e vibrazione

Alcuni caricatori USB PD ad alta potenza — specialmente quelli per laptop con PPS — causano un loop di avvio/arresto della ricarica. Il problema sembra dovuto a un’incompatibilità nel negoziato di tensione tra il battery management di Xperia 10 VII e certi profili PPS. Sostituire cavo o caricatore risolve di solito il problema.

Infine, le vibrazioni haptic sono oggetto di molte critiche: al tocco si percepisce un fastidioso ronzio o tintinnio, molto diverso dal feedback solido atteso. Trattandosi probabilmente di un limite hardware del motore vibrante, una correzione software completa appare difficile. Molti utenti hanno semplicemente disabilitato il feedback aptico.

Sony è al corrente di alcune di queste segnalazioni? Al momento non ci sono comunicati ufficiali, ma la speranza è che i problemi software vengano indirizzati con futuri aggiornamenti.

Una delle funzionalità più chiacchierate per il prossimo Google Pixel 11 è la cosiddetta “Pixel Glow” — un presunto sistema luminoso integrato nella barra della fotocamera posteriore. Ma l’hype è davvero giustificato? Un’analisi più attenta del video di Google I/O 2026 che ha acceso le speculazioni suggerisce di abbassare le aspettative.

Il video di Google I/O che ha scatenato il dibattito

Durante la presentazione di Gemini Omni al Google I/O 2026, in un breve filmato generato dall’intelligenza artificiale è apparso uno smartphone con la barra delle fotocamere illuminata. La somiglianza con la forma di Pixel ha fatto scattare immediatamente le teorie: e se Google avesse involontariamente mostrato una funzione reale del Pixel 11?

Più probabile un effetto visivo che un leak accidentale

La lettura più credibile, però, è che si trattasse semplicemente di un elemento estetico dell’animazione AI, senza alcuna corrispondenza con le specifiche del dispositivo reale. Il contesto del filmato — interamente generato — non lascia spazio a interpretazioni di tipo “leak ufficiale”. Google non ha commentato, e questo silenzio non è di per sé un’ammissione.

Google ama giocare con i rumor: il precedente Pixel Ultra

Non sarebbe la prima volta che Google incorpora riferimenti ironici ai propri rumor nelle presentazioni. In passato, durante un evento Pixel, l’assistente mostrava in bella vista la scritta “Pixel Ultra meeting” — un wink diretto alle voci su un modello mai annunciato. È possibile che anche questa volta ci sia una componente di auto-ironia nella scelta dell’animazione.

Pixel Glow esiste davvero? La risposta è: non lo sappiamo ancora

In assenza di leak hardware o render affidabili, la natura di Pixel Glow rimane avvolta nel mistero. Potrebbe essere un vero sistema LED attorno alla barra della fotocamera, oppure qualcosa di molto più discreto come un semplice indicatore luminoso. O ancora potrebbe non esistere affatto nella forma immaginata. Per ora l’unica certezza è che Pixel 11 è atteso per l’autunno 2026, e i dettagli ufficiali non tarderanno ad arrivare.

Samsung ha reso noto il calendario ufficiale per il rilascio di One UI 8.5, e le buone notizie riguardano anche i modelli meno recenti. L’aggiornamento raggiungerà non solo i flagship di ultima generazione, ma anche dispositivi della serie Galaxy S23 e Z Fold5, ampliando notevolmente la platea di utenti coinvolti.

I primi ad aggiornare: S25 e Z Fold7 da fine maggio

Il rollout partirà dalla fine di maggio 2026, con i modelli di punta che apriranno le danze. Tra i primi a ricevere One UI 8.5 ci sono Galaxy S25, S25 Ultra, S24, S24 Ultra, Galaxy Z Fold7, Z Flip7, Z Fold6 e Z Flip6. La distribuzione avverrà tramite i principali operatori e per i modelli SIM-free, con tempistiche che potranno variare leggermente a seconda del carrier.

Giugno per la serie S23 e Fold5

I dispositivi della generazione 2023 dovranno aspettare qualche settimana in più. Galaxy S23, S23 Ultra, Z Fold5 e Z Flip5 riceveranno l’aggiornamento a partire da giugno. Anche la fascia media non è esclusa: Galaxy A55 5G, A54 5G, A36 5G e A25 5G figurano tra i modelli supportati, rendendo One UI 8.5 accessibile a una gamma molto più ampia di utenti. Nell’elenco compaiono pure alcuni tablet della serie Galaxy Tab, tra cui Tab S10 FE e Tab S9 FE+ 5G.

Galaxy AI potenziato e nuove funzioni di editing fotografico

Il cuore dell’aggiornamento è il potenziamento dell’intelligenza artificiale Galaxy AI. La funzione “Foto Assistita” si evolve con il supporto alle istruzioni testuali: sarà possibile chiedere all’AI di trasformare una foto diurna in una scena notturna, ricostruire soggetti parzialmente tagliati o correggere dettagli dell’abbigliamento. “Creative Studio” aggiunge la generazione di sticker, sfondi e schede profilo personalizzate tramite AI.

Quick Share ora compatibile con AirDrop

Una delle novità più attese è l’evoluzione di Quick Share, che su alcuni modelli Galaxy diventa compatibile con AirDrop di Apple. I possessori di Galaxy S25, S24, Z Fold7/Flip7 e Z Fold6/Flip6 potranno condividere file con iPhone e iPad tramite Bluetooth, senza passare da QR code o link. Una svolta concreta nella comunicazione tra ecosistemi Android e iOS. Contestualmente, Samsung annuncia che sei nuovi modelli SIM-free supporteranno Starlink Direct a partire da metà giugno 2026.

OPPO ha presentato un accessorio decisamente originale: Oppo Bubble, un piccolo display rotondo che si aggancia magneticamente al retro dello smartphone. Non si tratta di un concept futuristico, ma di un prodotto già in vendita in Cina a 499 yuan (circa 65 euro). L’idea è semplice ma intrigante: portare un sub-display posteriore su qualsiasi telefono compatibile con Qi2.

Cos’è OPPO Bubble e come funziona

Oppo Bubble è un display AMOLED circolare spesso circa 7 mm e del peso di soli 27,5 grammi. Al suo interno ospita un piccolo schermo, una batteria da 550 mAh e i magneti per l’aggancio Qi2. Si può quindi attaccare al retro di qualsiasi smartphone compatibile con lo standard Qi2, inclusi gli iPhone, anche se l’integrazione software è pensata per i dispositivi OPPO.

Selfie con la fotocamera principale: il caso d’uso principale

La funzione più interessante è la possibilità di usare Bubble come schermo di anteprima per i selfie scattati con la fotocamera principale. Sugli smartphone OPPO compatibili — tra cui i modelli Reno 14, Reno 16, Find X8 e Find X9 — l’accessorio mostra in tempo reale l’inquadratura della fotocamera posteriore, consentendo di sfruttare sensori di gran lunga superiori al classico frontale per le foto da condividere sui social.

Anche per foto, video e come accessorio di stile

Bubble non è solo uno strumento per selfie migliori: il piccolo schermo può visualizzare foto e video, e grazie a una custodia dedicata può essere staccato dallo smartphone e indossato come accessorio su borse o zaini. OPPO punta chiaramente anche sulla componente estetica, trasformando Bubble in qualcosa a metà tra un gadget tech e un oggetto di moda.

Per il momento non è confermata una distribuzione globale, ma la popolarità crescente degli accessori magnetici — alimentata dalla diffusione di Qi2 e MagSafe — suggerisce che prodotti come Bubble potrebbero trovare spazio anche nei mercati europei nel prossimo futuro.

L'azienda produttrice di stampanti 3d, e dei software che servono ad utilizzarle, è stata imbeccata dalla Software Freedom Conservancy non solo perché si è "dimenticata" di rilasciare i sorgenti dei propri software basati su codice AGPL, ma anche perché ha minacciato azioni legali contro uno sviluppatore reo di aver fatto reverse engineering per rimettere le cose a posto.

🔗 Leggi il post completo

Un’operazione internazionale coordinata da sette paesi ha smantellato First VPN, un servizio VPN criminale attivo dal 2014 che per oltre un decennio ha fornito anonimato e copertura a ransomware gang, operatori di botnet e criminali informatici di ogni tipo. L’Operazione Saffron — condotta tra il 19 e il 20 maggio 2026 da autorità francesi e olandesi con il supporto di Europol ed Eurojust — ha portato al sequestro di 33 server, alla chiusura di domini multipli e all’identificazione di migliaia di utenti criminali. Almeno 25 gruppi ransomware si erano affidati al servizio per nascondere le proprie attività.

Cos’era First VPN: un servizio progettato per il crimine

A differenza dei normali provider VPN commerciali, First VPN era stato strutturalmente concepito per rispondere alle esigenze operative dei criminali informatici. Il servizio operava server in 27 paesi, accettava pagamenti anonimi e metteva a disposizione un’infrastruttura deliberatamente opaca, pubblicizzando esplicitamente la propria offerta agli hacker attraverso forum del dark web.

Europol ha confermato che First VPN non si limitava a offrire connessioni anonime: forniva ai cybercriminali pagamenti anonimi, infrastruttura nascosta e una serie di servizi specificamente commercializzati per chi voleva condurre attività illegali. L’FBI ha dichiarato che almeno 25 gang ransomware si servivano del servizio per mascherare il traffico malevolo, condurre ricognizioni sulle reti delle vittime, operare botnet, lanciare attacchi DDoS ed eseguire frodi su larga scala.

La durata operativa del servizio — dodici anni, dal 2014 al 2026 — rende First VPN uno dei provider criminali più longevi mai smantellati. Nel corso di questi anni il servizio ha rappresentato un elemento dell’infrastruttura criminale digitale quasi quanto certi servizi bullet-proof hosting che proteggono server di command-and-control.

Operazione Saffron: anatomia del takedown

L’Operazione Saffron è stata guidata dalle autorità di Francia e Paesi Bassi, con la partecipazione di cinque ulteriori paesi. Europol ed Eurojust hanno svolto un ruolo di coordinamento, mentre Bitdefender è stato tra i partner privati che hanno contribuito all’operazione con intelligence tecnica.

Il bilancio dell’operazione è significativo:

• 33 server sequestrati in tutta l’infrastruttura del servizio
• Chiusura di tutti i domini associati a First VPN
• Identificazione di migliaia di utenti criminali — le autorità hanno ottenuto accesso ai log e ai dati del provider
• 83 pacchetti di intelligence su 506 utenti condivisi con i paesi partner per follow-up investigativi
• Interrogatorio dell’operatore in Ucraina da parte di autorità francesi e olandesi

Un dato particolarmente rilevante: le autorità avevano accesso segreto ai sistemi di First VPN prima del takedown, raccogliendo intelligence sugli utenti e le loro attività. Come in precedenti operazioni simili (VPNLab, Fbi’s Anom), il monitoraggio anticipato ha permesso di costruire casi investigativi solidi contro i clienti del servizio.

Chi utilizzava First VPN: 25 gang ransomware e un ecosistema criminale variegato

Secondo l’FBI, First VPN era un punto di convergenza per una molteplicità di attori criminali. Le 25 gang ransomware che lo utilizzavano lo impiegavano principalmente per:

• Mascherare l’identità degli operatori durante la fase di ricognizione e compromissione iniziale delle reti
• Gestire i pannelli di command-and-control dei loro malware senza esporre infrastrutture proprie
• Condurre negoziazioni con le vittime attraverso connessioni anonimizzate
• Eseguire exfiltrazione di dati verso server di staging

Oltre al ransomware, il servizio veniva impiegato per la gestione di botnet, attacchi DDoS-as-a-service, frodi finanziarie e altre forme di cybercrime. La natura “crime-as-a-service” dell’offerta di First VPN riflette la professionalizzazione crescente dell’ecosistema criminale informatico, dove le diverse componenti delle operazioni illecite — exploit kit, accesso iniziale, VPN anonime, criptazione, estorsione — vengono acquistate come servizi separati su mercati specializzati.

Il contesto: la guerra delle autorità contro l’infrastruttura criminale

Il takedown di First VPN si inserisce in una sequenza di operazioni di law enforcement che negli ultimi anni ha progressivamente eroso l’infrastruttura tecnologica del cybercrimine organizzato. Tra le operazioni più significative degli ultimi 24 mesi si ricordano: il takedown di LockBit (febbraio 2024), l’operazione contro ALPHV/BlackCat (dicembre 2023), il sequestro di BreachForums (maggio 2024) e, più recentemente, l’arresto di Jacob Butler, il 23enne canadese alias “Dort” accusato di aver operato la botnet KimWolf — responsabile di attacchi DDoS da record a quasi 30 terabit al secondo, che hanno infettato quasi 2 milioni di dispositivi tra telecamere di sorveglianza e cornici digitali connesse a internet.

Ciò che emerge da questa serie di operazioni è una strategia deliberata da parte delle autorità: colpire non solo i singoli criminali, ma l’infrastruttura condivisa che permette a decine di gruppi diversi di operare. Sequestri di VPN criminali, hosting bullet-proof, servizi di riciclaggio crypto e forum di coordinamento costano al cybercrimine non solo singoli attori ma intere reti di supporto operative.

Le implicazioni investigative: i log di First VPN

Il punto più interessante — e preoccupante per chi ha usato il servizio — è la questione dei log. First VPN sosteneva, come quasi tutti i provider VPN nel mercato criminale, di non conservare log delle attività degli utenti. Le operazioni precedenti (VPNLab, IVPN, DoubleVPN) hanno dimostrato che queste affermazioni sono spesso false o parzialmente vere. In questo caso, la conferma che le autorità hanno ottenuto accesso anticipato ai sistemi e hanno costruito 83 pacchetti di intelligence su 506 utenti specifici suggerisce fortemente che dati sufficienti per l’identificazione erano disponibili.

Per le organizzazioni di sicurezza che seguono gruppi ransomware attivi, questo takedown ha una conseguenza pratica immediata: tutti i gruppi che utilizzavano First VPN dovranno migrare verso infrastrutture alternative, il che storicamente causa disruption operativa misurabile nelle campagne ransomware nelle settimane successive a simili operazioni.

Consigli per i difensori

• Monitorare i log di rete per connessioni in entrata o in uscita verso i range IP precedentemente associati all’infrastruttura di First VPN (le ION saranno condivise dai partner istituzionali nelle prossime settimane)
• Aspettarsi un picco di attività ransomware nelle prossime 2-4 settimane: i gruppi che perdono infrastrutture di supporto tendono ad accelerare le campagne attive prima di riorganizzarsi
• Aggiornare le TTP di threat modeling per i gruppi ransomware di riferimento: cambieranno IP, provider VPN e infrastruttura C2 in risposta all’operazione
• Condividere intelligence con i centri nazionali (in Italia, ACN) per contribuire alla costruzione dei pacchetti investigativi di follow-up sui 506 utenti identificati

Un sofisticato attacco alla supply chain ha compromesso quattro pacchetti PHP appartenenti al progetto Laravel-Lang, iniettando codice malevolo in oltre 700 versioni pubblicate in rapida successione tra il 22 e il 23 maggio 2026. Il payload — uno stealer cross-platform da quasi 6.000 righe di codice — è stato progettato per drenare credenziali cloud, token CI/CD, wallet di criptovalute e segreti di repository da qualsiasi sistema che utilizzi queste librerie di localizzazione diffusissime nell’ecosistema Laravel.

La natura dell’attacco: tag git riscritti, non codice sorgente

Quello che rende questa campagna particolarmente insidiosa è la tecnica adottata: gli attaccanti non hanno modificato il codice sorgente del repository, bensì hanno riscritto ogni tag git esistente in ciascun repository per puntare a commit malevoli appartenenti a un fork controllato dagli aggressori. Questo approccio bypassa molti controlli di integrità tradizionali basati sull’analisi dei diff del codice principale.

GitHub consente ai tag di versione di puntare a commit di fork dello stesso repository. Gli attaccanti hanno sfruttato questa funzionalità per sostituire silenziosamente tutti i tag — compresi quelli di versioni storicamente sicure — con riferimenti a commit malevoli nel fork. Il risultato pratico è che anche un progetto che non aggiornava le dipendenze da mesi si ritrovava improvvisamente a scaricare codice ostile.

I ricercatori di Socket, Aikido Security, StepSecurity e Snyk hanno analizzato in dettaglio l’incidente, confermando che le versioni compromesse sono state pubblicate in rapida successione — alcune a pochi secondi di distanza l’una dall’altra — il 22 e il 23 maggio 2026, con oltre 700 versioni identificate tra i quattro pacchetti interessati. La velocità di pubblicazione indica quasi certamente un processo automatizzato.

I pacchetti compromessi

I quattro pacchetti colpiti sono componenti fondamentali dell’ecosistema di localizzazione per applicazioni Laravel:

• laravel-lang/lang — le traduzioni principali per decine di lingue
• laravel-lang/http-statuses — messaggi di stato HTTP localizzati
• laravel-lang/attributes — traduzioni degli attributi dei form
• laravel-lang/actions — azioni comuni localizzate

Si sospetta che gli attaccanti abbiano ottenuto accesso a credenziali a livello di organizzazione, a sistemi di automazione del repository o all’infrastruttura di rilascio del progetto. Packagist ha risposto tempestivamente rimuovendo le versioni malevole e mettendo temporaneamente in stato di “unlisted” i pacchetti interessati per prevenire ulteriori installazioni.

Il meccanismo di esecuzione automatica: autoloader Composer

La funzionalità malevola è contenuta in un file denominato src/helpers.php, incorporato nei tag di versione compromessi. Il file è registrato nel campo autoload.files del composer.json di ciascun pacchetto. Questa scelta tecnica è devastante: qualsiasi applicazione PHP che esegua require __DIR__.'/vendor/autoload.php' all’avvio — ovvero praticamente ogni applicazione Laravel, Symfony, PHPUnit o framework PHP moderno — esegue automaticamente il payload senza che sia necessaria alcuna chiamata di metodo esplicita.

“Il backdoor viene eseguito automaticamente ad ogni richiesta PHP gestita dall’applicazione compromessa”, ha spiegato Socket nella propria analisi. Lo script genera un identificatore univoco per host (un hash MD5 che combina il percorso della directory, l’architettura del sistema e l’inode) per garantire che il payload si attivi una sola volta per macchina, limitando le esecuzioni ridondanti e aiutando il malware a restare non rilevato dopo l’esecuzione iniziale.

Payload: uno stealer modulare con 15 collector specializzati

Il dropper contatta il server flipboxstudio[.]info per recuperare il payload principale: uno stealer PHP cross-platform da circa 5.900 righe di codice, organizzato in 15 moduli collector specializzati. Su Windows viene distribuito un launcher Visual Basic Script eseguito tramite cscript; su Linux e macOS il payload viene eseguito tramite exec().

L’elenco di ciò che lo stealer è in grado di raccogliere è impressionante per ampiezza e profondità:

• Cloud provider: ruoli IAM AWS e documenti di identità dell’istanza, credenziali default di Google Cloud, token di accesso Microsoft Azure, profili service principal, token di account DigitalOcean, Heroku, Vercel, Netlify, Railway, Fly.io
• Container e orchestrazione: token Service Account Kubernetes, configurazioni Helm registry, token HashiCorp Vault, auth token Docker, configurazioni cluster Kubernetes
• CI/CD e DevOps: token e configurazioni di Jenkins, GitLab Runner, GitHub Actions, CircleCI, TravisCI, ArgoCD
• Criptovalute: seed phrase e file di portafogli Electrum, Exodus, Atomic, Ledger Live, Trezor, Wasabi, Sparrow; dati di estensioni browser MetaMask, Phantom, Trust Wallet, Ronin, Keplr, Solflare, Rabby
• Browser: cronologia, cookie e login data da Chrome, Edge, Firefox, Brave, Opera, usando un eseguibile Windows embedded in Base64 che bypassa Chromium’s App-Bound Encryption (ABE)
• Password manager: vault locali e dati di estensioni 1Password, Bitwarden, LastPass, KeePass, Dashlane, NordPass
• Comunicazioni e sessioni: token di Discord, Slack, Telegram; sessioni PuTTY/WinSCP, Windows Credential Manager, sessioni RDP
• File sensibili: chiavi private SSH, credenziali Git, history di shell, file .env, wp-config.php, docker-compose.yml, variabili d’ambiente del processo PHP
• Email e FTP: dati Outlook, Thunderbird, FileZilla, WinSCP, CoreFTP
• VPN: configurazioni OpenVPN, WireGuard, NetworkManager, NordVPN, ExpressVPN, CyberGhost, Mullvad

Dopo aver raccolto tutto il materiale disponibile, il payload cripta i risultati con AES-256 e li trasmette all’endpoint flipboxstudio[.]info/exfil, dopodiché si cancella dal disco per limitare le tracce forensi.

IoC (Indicatori di Compromissione)

# Dominio C2 principale
flipboxstudio[.]info
flipboxstudio[.]info/exfil
# File malevolo nei pacchetti
src/helpers.php  (registrato in autoload.files di composer.json)
# Pacchetti PHP compromessi (verificare versioni 22-23 maggio 2026)
laravel-lang/lang
laravel-lang/http-statuses
laravel-lang/attributes
laravel-lang/actions
# Verifica presenza del file malevolo
find ./vendor -name "helpers.php" -path "*/laravel-lang/*" -exec grep -l "flipboxstudio" {} \;

Contesto: una campagna in crescita nell’ecosistema PHP

Questo attacco non è isolato. Negli ultimi mesi si è assistito a un’ondata di compromissioni delle supply chain nei principali registri di pacchetti. In particolare, la campagna Mini Shai-Hulud attribuita al gruppo TeamPCP (UNC6780) ha colpito pacchetti npm di TanStack, Mistral AI, Guardrails AI e OpenSearch, diffondendosi come un vero e proprio worm grazie all’abuso di token OIDC GitHub e al meccanismo di trusted publishing di npm. Il fatto che ora un attacco simile colpisca l’ecosistema PHP/Composer dimostra che i gruppi criminali stanno sistematicamente esplorando tutti i principali registri di pacchetti come vettori di attacco.

La tecnica di riscrivere i tag git invece di modificare il codice sorgente rappresenta un’evoluzione tattica significativa: bypassando i controlli diff tradizionali, rende molto più difficile il rilevamento automatico da parte degli strumenti di analisi della composizione software (SCA).

Due righe per i difensori

• Verificare immediatamente se le applicazioni Laravel utilizzano uno dei quattro pacchetti compromessi e controllare le versioni installate durante il periodo 22-23 maggio 2026
• Ruotare tutte le credenziali (AWS, GCP, Azure, GitHub, npm, CI/CD, database) su qualsiasi sistema che abbia eseguito codice con le versioni infette
• Non revocare immediatamente i token sospetti prima di aver isolato e acquisito un’immagine forense del sistema: il malware include meccanismi di risposta alla revoca
• Bloccare il dominio flipboxstudio[.]info a livello di firewall/DNS
• Implementare controlli di integrità sui tag git (verificare le firme dei commit) e considerare il pinning degli hash SHA degli artefatti nel composer.lock
• Adottare strumenti SCA capaci di rilevare tag git riscritti, non solo modifiche al codice sorgente
• Aggiornare a versioni sicure dei pacchetti rilasciate dal team Laravel-Lang dopo la rimozione delle versioni malevole da Packagist

L’Xperia 1 VIII non è ancora nei negozi ma i problemi di disponibilità si fanno già sentire. A poche settimane dall’apertura degli ordini, alcune configurazioni del nuovo flagship Sony risultano già in attesa di disponibilità — sia in Giappone che in Europa.

Rosso e Oro in “attesa di arrivo merce” sullo store Sony giapponese

Sul Sony Store ufficiale giapponese, la versione SIM-free dell’Xperia 1 VIII con 16GB di RAM e 512GB di storage nei colori Garnet Red e Native Gold è già indicata come “spedizione alla ricezione della merce”, anziché con la data di lancio prevista dell’11 giugno. Il colore Graphite Black nella stessa configurazione ha registrato un problema simile, risolto nel giro di poco tempo, mentre le altre combinazioni di memoria sembrano per ora disponibili regolarmente.

In Europa il modello da 1TB è esaurito ovunque

La situazione è ancora più critica nel Vecchio Continente. Sui Sony Store ufficiali di Regno Unito, Germania, Francia e Spagna, il modello Xperia 1 VIII da 1TB risulta “OUT OF STOCK” con acquisto impossibile. Non si tratta di un caso isolato: la carenza è diffusa su più mercati contemporaneamente, una situazione che per un pre-lancio appare anomala. Anche il modello da 12GB/256GB in colorazione Rosso mostra segnali di scarsità in alcune regioni.

Il passaggio alla produzione in conto terzi potrebbe spiegare tutto

Tra le ipotesi più accreditate per spiegare questo scenario c’è il cambio nella catena produttiva di Sony. Secondo alcune indiscrezioni, Xperia avrebbe spostato parte della produzione dallo stabilimento interno a fornitori terzi. Questo cambiamento potrebbe aver influito negativamente sulla capacità di gestire scorte differenziate per colore e configurazione, specie nelle prime settimane di commercializzazione.

Sony non ha rilasciato dichiarazioni ufficiali, ma i precedenti con Xperia 1 VII — che aveva sofferto di problemi simili al lancio — suggeriscono che questa potrebbe essere una criticità strutturale del brand nel gestire la distribuzione iniziale dei propri flagship. Per chi punta alle colorazioni più ricercate, la pazienza sarà la virtù più importante nei prossimi mesi.

I dati di vendita globale degli smartphone per il primo trimestre 2026 sono stati resi pubblici, e confermano una tendenza ormai consolidata: nel mondo reale — quello dei volumi, non dei margini — a farla da padrone sono i dispositivi Android nella fascia media. E Samsung, con la sua serie Galaxy A, guida questa classifica in modo schiacciante.

Galaxy A07 4G: lo smartphone Android più venduto al mondo

Il primato assoluto per unità vendute spetta al Galaxy A07 4G, un dispositivo entry-level che conferma come i mercati emergenti continuino ad assorbire enormi quantità di smartphone economici. Samsung ha costruito un ecosistema capillare nella fascia bassa e media che nessun competitor riesce ancora a replicare su scala globale.

Nella top 10 figurano anche Galaxy A56 e Galaxy A36: modelli mid-range che Samsung ha arricchito con funzionalità AI precedentemente riservate ai flagship, rendendo la serie A ancora più competitiva rispetto alla concorrenza cinese.

L’AI democratizzata spinge le vendite della serie A

Una delle chiavi del successo recente di Samsung nella fascia media è proprio la politica di “AI trickle-down”: funzionalità come Circle to Search, Live Translate e le editing AI delle foto — che fino a poco tempo fa erano esclusive dei modelli S — sono ora disponibili su Galaxy A. Questo ha ampliato il divario percepito tra la serie A e la concorrenza, convincendo fasce di utenti sempre più ampie a non doversi “accontentare” del budget.

Il mercato globale parla ancora Android

Al di là del dominio Samsung, la classifica nel suo complesso ribadisce la centralità di Android come piattaforma di riferimento globale. Nei mercati con il maggior numero di nuovi utenti — Africa, Asia meridionale, America Latina — la scelta è quasi sempre un dispositivo Android, spesso nella fascia tra i 100 e i 300 euro. Il premium market, dove Apple è più forte, rappresenta ancora una nicchia rispetto ai volumi totali. Una realtà che tende a passare in secondo piano quando si parla di smartphone su media tech occidentali, ma che definisce la vera forma del mercato.

MX Linux è una distribuzione GNU/Linux basata su Debian, progettata per garantire un’esperienza stabile, rapida e facile da utilizzare, così da risultare adatta sia a chi si avvicina per la prima volta al mondo del software libero sia a utenti...

🔗 Leggi il post completo

Rhino Linux è una distribuzione GNU/Linux a rilascio continuo (in inglese rolling release), basata su Ubuntu e progettata per ricevere aggiornamenti costanti senza richiedere reinstallazioni per passare a una nuova versione del sistema. Il...

🔗 Leggi il post completo

Xiaomi ha pubblicato un nuovo report settimanale di correzione bug per HyperOS 3, il suo sistema operativo basato su Android. L’elenco è lungo e tocca componenti chiave come Wi-Fi, galleria foto, gaming e launcher — un segnale che l’azienda sta affrontando con decisione la fase di stabilizzazione dell’OS.

I modelli coinvolti

Tra i dispositivi che beneficiano delle correzioni figurano Xiaomi 17 Pro, Xiaomi 17, Xiaomi 15 Pro, Xiaomi 15, Xiaomi 14, e — per il mercato globale — POCO F8 Ultra (equivalente al REDMI K90 Pro Max) e POCO X8 Pro Max (versione internazionale del REDMI Turbo 5 Max). Anche il REDMI K Pad 2 è nell’elenco.

Le correzioni principali

Le fix più rilevanti riguardano diversi ambiti del sistema. Sull’Xiaomi 17 Pro è stato risolto un problema di notifiche Wi-Fi ripetitive; sull’Xiaomi 17 un bug che faceva sparire il menu contestuale dell’App Store. Sui modelli 15 e 14 si risolvono anomalie nella galleria (thumbnail errate, annotazioni che scomparivano dopo la modifica) e un falso allarme sul traffico dati.

Per POCO F8 Ultra e X8 Pro Max le fix riguardano la duplicazione di foto e video nella galleria e problemi durante le live streaming su Douyin. Quest’ultimo bug impediva la scrittura di commenti durante le dirette, una limitazione significativa per i content creator. Viene anche risolto il reset spontaneo delle impostazioni di Game Turbo.

HyperOS 3: ora la priorità è la stabilità

Dalla quantità di fix contenuti in questo aggiornamento emerge chiaramente che Xiaomi ha spostato il focus dalla novità alla solidità. HyperOS 3 ha introdotto importanti funzionalità AI e miglioramenti all’integrazione tra dispositivi, ma il debutto non era stato privo di intoppi. La cadenza regolare dei bug report settimanali testimonia un approccio metodico alla risoluzione dei problemi.

Da notare che le correzioni vengono applicate prima ai firmware beta cinesi, per poi essere distribuite gradualmente nelle versioni globali. Gli utenti europei di Xiaomi, POCO e REDMI potrebbero quindi dover attendere qualche settimana prima di ricevere le stesse fix sui propri dispositivi. Monitorare il canale aggiornamenti dell’app MIUI/HyperOS rimane il modo più rapido per sapere quando il fix è in arrivo.

Il Samsung Galaxy A57 5G è uno degli smartphone Android più attesi del 2026 nel segmento mid-range: design sottilissimo da 6,9mm, funzionalità AI avanzate e ben sei anni di aggiornamenti garantiti. Eppure, a pochi mesi dal lancio, stanno emergendo alcune problematiche ricorrenti segnalate dagli utenti su Reddit e nei forum internazionali.

Ecco una panoramica dei bug più comuni ancora in attesa di correzione definitiva.

Ghost typing: il tocco che non c’è

Il problema più segnalato riguarda il comportamento anomalo del touchscreen durante la digitazione. Diversi utenti descrivono una situazione frustrante: caratteri vengono inseriti da soli, senza che il dito li abbia sfiorati, oppure lo stesso tasto viene premuto più volte in rapida successione — il cosiddetto “ghost typing”.

Inizialmente si pensava a un difetto della tastiera Samsung, ma il problema persiste anche installando Gboard o altre tastiere di terze parti. Gli esperti sospettano un bug nel digitalizzatore o nell’ottimizzazione del sistema operativo, piuttosto che un semplice errore software della tastiera. Attualmente non esiste una soluzione definitiva: si attendono futuri aggiornamenti di sistema.

Consumo anomalo della batteria con eSIM attiva

Un’altra criticità riguarda il consumo di energia in standby. Alcuni utenti riferiscono di perdere tra il 14% e il 40% della carica nelle 24 ore anche lasciando il telefono fermo sul tavolo, completamente inattivo.

Dopo varie prove e confronti nella community, è emersa una correlazione significativa: il problema tende a manifestarsi quando l’eSIM è attiva. Si ipotizza che il modem Exynos 1680 esegua ricerche di rete in background in modo incontrollato. Come workaround temporaneo alcuni utenti disattivano l’eSIM, ma si tratta ovviamente di una soluzione insoddisfacente in attesa di una patch ufficiale.

Cosa aspettarsi dai prossimi aggiornamenti

Samsung ha già dimostrato in passato di reagire tempestivamente ai bug più diffusi — come il flash verde allo schermo, già corretto nelle prime settimane. La speranza degli utenti è che anche questi problemi vengano risolti in tempi brevi attraverso aggiornamenti OTA. Nel frattempo, chi ha acquistato il Galaxy A57 5G è invitato a segnalare i problemi tramite l’app Samsung Members per accelerare il processo di fix.

Il sito di compravendita di smartphone usati Musuby ha pubblicato la classifica dei modelli più scambiati ad aprile 2026. I risultati confermano il dominio di Samsung nel mercato dell’usato, ma riservano spazio anche ai fan di Sony Xperia e Google Pixel.

Galaxy S25 al primo posto, Pixel 9a sul podio

Il modello più popolare del mese è il Samsung Galaxy S25, con un prezzo medio di transazione pari a 96.204 yen (circa 580 euro). Nonostante sia uscito nel 2025, mantiene un’elevata domanda anche nel mercato secondario. Al secondo posto si conferma il Galaxy S23, mentre il terzo gradino del podio spetta al Google Pixel 9a: quotato mediamente a 71.333 yen, con la maggior parte degli esemplari in condizioni “SS”, ovvero praticamente come nuovi.

Non mancano poi i modelli Ultra: Galaxy S23 Ultra, S24 Ultra e S25 Ultra compaiono tutti nella top ten, segno che la fascia alta Android conserva un mercato dell’usato vivace e solido.

Sony Xperia: tre modelli in top 10

Una delle note più interessanti del ranking riguarda Sony: ben tre Xperia sono entrati nella top 10. L’Xperia 10 VI si piazza quinto, l’Xperia 1 V sesto (a circa 61.744 yen), e — sorpresa — l’Xperia 5 IV è ottavo nonostante sia un modello del 2022. Il prezzo medio di quest’ultimo si è attestato intorno ai 29.360 yen, rendendolo un’opzione conveniente per chi cerca audio e fotocamera di qualità senza spendere cifre elevate.

Il mercato dell’usato premia il rapporto qualità-prezzo

L’analisi complessiva del ranking rivela un trend chiaro: i consumatori cercano il miglior equilibrio tra prestazioni e prezzo. I modelli di due o tre anni fa — quelli che hanno perso valore commerciale ma non capacità tecnica — stanno diventando sempre più appetibili, soprattutto in un contesto in cui i prezzi dei nuovi smartphone continuano a salire. Anche il Pixel 8a figura in classifica accanto al 9a, a conferma del forte interesse per la linea Google tra chi vuole AI avanzata e aggiornamenti garantiti a lungo termine.

Google sta espandendo la presenza di Gemini, il suo assistente AI, all’ecosistema Google TV. Dopo il lancio prioritario sul nuovo Google TV Streamer, l’intelligenza artificiale sta ora raggiungendo anche la precedente generazione di dispositivi: il Chromecast with Google TV, in particolare il modello 4K.

Confermato il rollout sul Chromecast 4K

Diversi utenti internazionali hanno segnalato la comparsa di Gemini sul proprio Chromecast with Google TV 4K nell’ultima settimana. Le segnalazioni indicano che il requisito necessario è il firmware UTTC.250917.004 abbinato alla patch di sicurezza di ottobre 2025. Google, come di consueto, sta procedendo con un rollout graduale e non simultaneo, il che spiega perché non tutti gli utenti abbiano ancora ricevuto l’aggiornamento.

Il modello HD dovrà aspettare

Per il momento, non si registrano segnalazioni di Gemini sul Chromecast with Google TV HD. Ciò non significa che il dispositivo non sarà mai supportato: è possibile che il rollout sia semplicemente in ritardo o ancora limitato a specifiche regioni geografiche. Google tende a distribuire le nuove funzionalità in fasi progressive, quindi un’espansione al modello HD nei prossimi mesi appare plausibile.

Una buona notizia in un momento difficile per Chromecast

Il timing non è casuale: il brand Chromecast ha vissuto mesi complicati, tra problemi di accesso ai servizi sui modelli più vecchi e annunci di fine supporto per diversi dispositivi. Google ha chiaramente spostato il suo focus sul nuovo Google TV Streamer, facendo intuire un graduale abbandono del formato dongle. In questo contesto, l’arrivo di Gemini sugli Chromecast esistenti è una sopresa positiva per gli utenti affezionati al form factor originale.

Cosa cambia con Gemini su Google TV

L’integrazione di Gemini promette di trasformare l’esperienza di ricerca e suggerimento contenuti sulla TV. L’assistente sarà in grado di rispondere a domande in linguaggio naturale — come “trova una commedia in famiglia di meno di due ore” — superando i limiti delle ricerche tradizionali per parole chiave. Google punta anche a integrare le funzionalità AI con la domotica, consolidando Google TV come hub centrale della casa connessa.

PhotoPrism è un’applicazione open source dedicata alla gestione e all’organizzazione di foto e video, progettata per essere installata direttamente sui propri sistemi (self‑hosted) e utilizzabile tramite un comune browser web. L’obiettivo principale del progetto è...

🔗 Leggi il post completo