OPPO Reno15 A, lanciato appena lo scorso 25 giugno, riceve già un importante aggiornamento software. Il pacchetto, dal peso di circa 1,94 GB, introduce la patch di sicurezza Android di giugno 2026 e, soprattutto, corregge alcuni malfunzionamenti legati al surriscaldamento del dispositivo in condizioni di utilizzo intenso.

Fotocamera e prestazioni più stabili con il caldo

OPPO ha iniziato a distribuire l’update per la versione SIM-free del Reno15 A a partire dal 29 giugno, portando il dispositivo alla build “CPH2801_16.0.5.1000(EX01)”. Tra le novità principali segnalate dall’azienda figurano tre interventi mirati.

• Miglioramento della gestione termica della fotocamera, con correzione dei problemi di scatti a scatti durante le riprese video ad alte temperature
• Ottimizzazione delle prestazioni generali del sistema quando il dispositivo raggiunge temperature elevate
• Applicazione della patch di sicurezza Android di giugno 2026

Non si tratta quindi di un semplice aggiornamento di sicurezza: l’intervento punta esplicitamente a garantire una maggiore stabilità durante i mesi estivi, quando il rischio di surriscaldamento aumenta sensibilmente, specialmente durante le registrazioni video prolungate.

Distribuzione anche per le varianti degli operatori

L’aggiornamento sta raggiungendo anche i modelli brandizzati dagli operatori telefonici: dal 30 giugno è disponibile anche per la variante UQ mobile, identificata dalla build “OPG08_16.0.5.1000(EX01)”. In questo caso la nota di rilascio menziona solo un generico miglioramento della sicurezza, ma il numero di build identico a quello della versione SIM-free lascia supporre che siano incluse anche le correzioni relative al surriscaldamento. Le varianti per altri operatori non hanno invece ancora ricevuto l’aggiornamento, che dovrebbe arrivare nelle prossime settimane.

Vista la vicinanza al lancio del dispositivo e l’importanza dei correttivi introdotti, agli utenti che possiedono un Reno15 A conviene installare l’aggiornamento non appena disponibile, magari collegandosi a una rete Wi-Fi e assicurandosi di avere una carica sufficiente della batteria.

Nuove indiscrezioni sul futuro Galaxy S27 Ultra riguardano uno degli aspetti più attesi dagli utenti Samsung: l’autonomia. Secondo un leak recente, il colosso coreano avrebbe deciso di non adottare la batteria al silicio-carbonio già diffusa tra i produttori cinesi, preferendo invece una soluzione agli ioni di litio più tradizionale ma con una capacità superiore ai 5.500 mAh.

Il costo dietro la scelta di Samsung

Le fonti indicano che la decisione di evitare il silicio-carbonio non sarebbe legata a limiti tecnici, ma principalmente a ragioni economiche. Con una produzione stimata di un milione di unità del Galaxy S27 Ultra, il costo di approvvigionamento delle celle al silicio-carbonio risulterebbe significativamente più alto rispetto alle tradizionali batterie agli ioni di litio, un problema aggravato dal recente rincaro dei prezzi della memoria DRAM.

Secondo un leak condiviso sui social, Samsung starebbe rivalutando la roadmap delle batterie fornite da SDI, che prevedeva capacità di 5.600 mAh e 5.800 mAh, dopo aver inizialmente optato per una soluzione da 5.200 mAh. Se i test in corso avranno esito positivo, il Galaxy S27 Ultra potrebbe quindi superare i 5.500 mAh pur mantenendo la chimica al litio convenzionale.

La tendenza cinese non convince (ancora) Samsung

Negli ultimi anni diversi produttori cinesi hanno abbracciato la tecnologia al silicio-carbonio proprio per coniugare capacità elevate e spessori ridotti, un compromesso che finora ha reso i loro smartphone particolarmente competitivi sul fronte dell’autonomia. Samsung, tuttavia, sembra voler mantenere un approccio più prudente, privilegiando l’affidabilità della tecnologia consolidata rispetto all’innovazione più rischiosa e costosa.

Resta da vedere se questa scelta penalizzerà il Galaxy S27 Ultra nel confronto diretto con la concorrenza asiatica, ma un aumento della capacità oltre i 5.500 mAh rappresenterebbe comunque un passo avanti significativo rispetto all’attuale generazione. Come sempre in questi casi, si tratta di informazioni non ufficiali: solo l’annuncio di Samsung, atteso nei prossimi mesi, potrà confermare le specifiche definitive del nuovo top di gamma.

Sono emerse le prime tracce dello sviluppo interno di HyperOS 3.3 basato su Android 17, destinato ai futuri top di gamma Xiaomi 17 e Xiaomi 17 Ultra. Si tratta di build ingegneristiche riservate al personale interno, non ancora disponibili nemmeno in versione beta pubblica, ma che confermano come lo sviluppo della prossima generazione di flagship sia già in fase avanzata.

Due codenomi, due build distinte

Le build individuate riguardano due dispositivi specifici, entrambi datati 2 luglio 2026.

• Xiaomi 17 (codename “pudding”) – firmware OS3.0.330.11.XPCCNXM, basato su Android 17
• Xiaomi 17 Ultra (codename “nezha”) – firmware OS3.0.330.8.XPACNXM, basato su Android 17

Trattandosi di build engineering a uso strettamente interno, il software si troverebbe ancora in una fase iniziale, dedicata principalmente a verifiche e ottimizzazioni a livello di sistema, piuttosto che alla rifinitura dell’esperienza utente.

Su cosa si sta concentrando Xiaomi

Dalle build individuate emerge che lo sviluppo di HyperOS 3.3 si sta concentrando su diversi aspetti fondamentali del sistema, tra cui l’integrazione con Android 17, l’ottimizzazione del chipset di nuova generazione destinato ai flagship, la gestione di calore e consumi energetici, la calibrazione dell’ISP della fotocamera e il miglioramento generale della stabilità e della reattività del sistema.

Al momento non risultano invece elementi legati a una nuova interfaccia utente o a funzionalità pensate per l’utente finale, segno che il lavoro si trova ancora nella fase più tecnica dello sviluppo. Va inoltre sottolineato che in queste build non è stata rilevata alcuna traccia di “HyperOS 4”: lo sviluppo attuale sembra quindi concentrarsi esclusivamente sulla versione 3.3 della piattaforma software di Xiaomi, in vista del lancio dei nuovi top di gamma.

HelixNotes è un'app open source per prendere appunti in Markdown con archiviazione locale, gestione attività, wiki link e sincronizzazione WebDAV
L'articolo HelixNotes l’app open per gestire note Markdown in locale con Rust e Tauri proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Lin...

🔗 Leggi il post completo

La serie Google Pixel resta uno dei nomi più riconosciuti tra gli smartphone Android, ma un recente sondaggio condotto da una testata internazionale mostra come il giudizio degli utenti si sia fatto più sfumato negli ultimi anni, complici problemi ricorrenti su batteria e aggiornamenti.

Poco più della metà ancora fedele al brand

Al sondaggio hanno risposto circa 2.700 persone. Il 51,6% ha dichiarato di amare ancora la serie Pixel, mentre il 44% circa ha ammesso di apprezzarla meno rispetto al passato. Il distacco tra i due gruppi è quindi minimo, segno di una base di utenti sempre più polarizzata riguardo alla qualità percepita dei dispositivi Google.

Batteria e aggiornamenti tra le critiche principali

Tra le criticità più citate figurano i problemi di batteria segnalati su più generazioni di Pixel, le prestazioni non sempre convincenti dei processori Tensor e alcuni malfunzionamenti comparsi dopo determinati aggiornamenti software. Diversi intervistati hanno raccontato di essere passati ad altri brand a causa dell’aumento dei prezzi, mentre altri lamentano un salto prestazionale ridotto rispetto ai modelli precedenti.

Non manca chi resta soddisfatto

Non tutti gli utenti condividono però questo giudizio negativo. C’è chi ammette un lieve calo dell’autonomia ma nessun problema rilevante, e chi ridimensiona la portata dei bug software segnalati, giudicandoli meno gravi di quanto raccontato online. L’esperienza Android offerta da Pixel e la qualità fotografica restano tra gli aspetti più apprezzati da questa fascia di utenti.

Una sfida di fiducia per Google

Il quadro che emerge è quello di una base di utenti ancora in maggioranza fedele, ma con una quota consistente di insoddisfatti che supera il 40%. Google continua a lavorare su batteria e stabilità del software, ma per mantenere la fiducia dei propri utenti dovrà probabilmente intensificare gli sforzi su affidabilità e qualità costruttiva nelle prossime generazioni di Pixel.

Tra le numerose novità di Android 17 ce n’è una passata finora piuttosto inosservata: una nuova funzione dedicata al miglioramento della qualità delle chiamate vocali e video tramite la rete 5G. Sulle reti degli operatori compatibili, le chiamate potrebbero risultare più stabili anche nei momenti di maggiore congestione della rete.

Rete 5G dedicata alle chiamate in automatico

La novità sfrutta il cosiddetto network slicing 5G per instradare automaticamente le chiamate vocali e video di app come WhatsApp e Zoom verso un canale di comunicazione prioritario. Il network slicing consiste nel suddividere un’unica rete 5G in più reti virtuali dedicate a usi differenti, garantendo così un canale a bassa latenza e alta qualità separato dal traffico dati generico.

Meno interruzioni negli ambienti affollati

In contesti come stadi o concerti, dove molte persone si collegano contemporaneamente, la velocità della connessione tende solitamente a calare. Dove disponibile, questa funzione permetterebbe di instradare automaticamente le chiamate su un canale prioritario, riducendo ritardi e interruzioni video anche in condizioni di rete affollata.

Meno lavoro per gli sviluppatori

Finora, per sfruttare il network slicing degli operatori, gli sviluppatori dovevano implementare manualmente il supporto per ciascuna rete. Con Android 17, invece, è il sistema operativo a rilevare automaticamente l’inizio e la fine di una chiamata, instradando solo il traffico dell’app interessata verso il canale prioritario, per poi tornare alla connessione normale al termine della chiamata.

La disponibilità dipende dagli operatori

La funzione richiede però che l’operatore telefonico offra effettivamente il supporto al network slicing 5G. Negli Stati Uniti alcuni operatori già offrono slice dedicati alle videochiamate, e la nuova funzione di Android 17 potrebbe favorire una diffusione più ampia di questo tipo di servizi, anche se non è escluso che in futuro venga proposta come opzione a pagamento all’interno dei piani tariffari.

Nuove indiscrezioni fanno luce sul comparto fotografico della prossima serie Xiaomi 18. Secondo il noto leaker Digital Chat Station, la gamma sarà composta da tre modelli, ciascuno con una strategia fotografica differente, con il modello Ultra che potrebbe introdurre un sensore principale di nuova generazione basato sulla tecnologia LoFIC.

Tre modelli, tre approcci diversi alla fotografia

Secondo il leak, Xiaomi starebbe sviluppando tre varianti flagship della serie 18. Il modello più compatto punterebbe su una doppia fotocamera incentrata su un sensore principale da 200 megapixel, privilegiando la qualità dello scatto principale rispetto al numero di obiettivi.

Il modello Pro con teleobiettivo macro fino a 15 cm

Il modello intermedio, Xiaomi 18 Pro, aggiungerebbe alla fotocamera principale da 200 megapixel anche un teleobiettivo capace di funzionare in modalità macro fino a una distanza di circa 15 centimetri. Questa soluzione permetterebbe scatti macro di alta qualità senza dover ricorrere a un sensore dedicato, seguendo una tendenza sempre più diffusa tra i top di gamma.

Ultra al top con sensore LoFIC

Il modello Ultra rappresenterebbe il vertice della gamma, con il sistema fotografico più avanzato. La novità principale riguarderebbe l’adozione di un sensore principale basato sulla tecnologia LoFIC, in grado di trattenere più informazioni sia nelle zone chiare sia in quelle scure di un’immagine, migliorando la gamma dinamica in scenari complessi come controluce e scatti notturni. L’Ultra monterebbe inoltre un modulo fotografico più grande rispetto agli altri due modelli, a conferma di un posizionamento orientato alla massima qualità d’immagine.

Batterie più capienti in arrivo

Non sono ancora emersi valori precisi sulla capacità delle batterie, ma secondo alcune fonti del settore tutti e tre i modelli potrebbero superare la soglia dei 7.000 mAh, con l’Ultra che potrebbe spingersi fino a 8.500 mAh. Si tratta comunque di informazioni non confermate, legate a prototipi ancora in fase di sviluppo, che potrebbero cambiare prima della presentazione ufficiale della serie Xiaomi 18.

Oppo presenterà il 2 luglio la nuova serie Reno 16, che punta con decisione sull’intelligenza artificiale grazie alla nuova ColorOS 16. Tra le novità più rilevanti spicca la possibilità di utilizzare in modo integrato servizi come ChatGPT, Gemini e Perplexity, oltre a un tasto fisico dedicato interamente alle funzioni IA.

Un tasto fisico dedicato all’intelligenza artificiale

La novità più originale della serie è l’AI Snap Key, un pulsante hardware dedicato. Premendolo una volta è possibile salvare screenshot, appunti e materiali di riferimento in uno spazio chiamato AI Mind Space; tenendolo premuto si registra un promemoria vocale, mentre un doppio tocco richiama l’elenco delle informazioni salvate. Il tasto è inoltre in grado di riconoscere automaticamente appuntamenti ed eventi mostrati a schermo, aggiungendoli al calendario.

ChatGPT, Gemini e Perplexity in un’unica interfaccia

Un’altra funzione chiave è AI Mind Pilot, che riunisce ChatGPT, Gemini e Perplexity in un’unica interfaccia. Gli utenti possono confrontare le risposte fornite dalle diverse intelligenze artificiali e ricevere suggerimenti basati sulle informazioni salvate in precedenza, senza dover passare manualmente da un’app all’altra.

Traduzioni e gestione delle spese assistite dall’IA

ColorOS 16 introduce anche funzioni pensate per la vita quotidiana. AI Bill Manager raccoglie scontrini, SMS, screenshot e note vocali per gestire le spese, con supporto a più valute. AI Menu Translation, invece, traduce i menù dei ristoranti all’estero mostrando anche ingredienti e possibili allergeni. Non mancano una funzione di traduzione simultanea multilingue, la trascrizione automatica delle riunioni registrate e la scansione di documenti cartacei in formato editabile.

Snapdragon 7 Gen 4 e attenzione alla sicurezza

Sotto la scocca, Oppo Reno 16 monta il processore Snapdragon 7 Gen 4 abbinato alla nuova ColorOS 16, che introduce anche Live Space per una gestione più chiara di notifiche e attività in corso. Sul fronte sicurezza, l’elaborazione IA viene protetta tramite Private Computing Cloud, mentre Oppo Lock offre blocco remoto e protezione contro l’uso fraudolento della SIM. Con questa serie, Oppo prova a distinguersi nel mercato sempre più competitivo degli smartphone IA puntando su un tasto fisico dedicato e sull’integrazione di più assistenti in un’unica esperienza.

KDE Gear 26.04.3 è disponibile con correzioni e miglioramenti per Dolphin, Kdenlive, Konsole, Elisa e molte altre applicazioni KDE.
L'articolo KDE Gear 26.04.3 conclude la serie con miglioramenti per Kdenlive, Dolphin e molte applicazioni proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Lin...

🔗 Leggi il post completo

Nuova puntata della rubrica che parla di tutte quelle invenzioni (tipicamente di casa Microsoft) che sembrano utili e belle, ma che si rivelano essere un duplicato, fatto peggio e normalmente meno sicuro di qualcosa che in Linux esiste già da molto, molto tempo.
Questa puntata è dedicata ai Container!

🔗 Leggi il post completo

Negli ultimi giorni sono aumentate le segnalazioni di utenti Pixel alle prese con connessioni Wi-Fi e dati mobili instabili. Sui social e nei forum diversi possessori descrivono sintomi simili, riportando alla luce un problema di connettività già osservato in passato su vari modelli della gamma Google.

Sintomi diversi, stesso disagio

Le segnalazioni raccolte nelle ultime 24 ore non sono tutte identiche. Un utente con Pixel 10 riporta un continuo passaggio automatico tra Wi-Fi e rete dati, mentre un altro lamenta un’instabilità diretta della connessione dati mobile. Alcuni possessori di Pixel 7a segnalano invece di essere riusciti a risolvere il problema resettando le impostazioni di rete, mentre nei commenti diversi utenti confermano di riscontrare sintomi analoghi.

Un possibile legame con la beta di Android 17

Tra i primi utenti di Android 17 erano già emerse segnalazioni di instabilità Wi-Fi legate ad alcune app specifiche. Alcuni ipotizzano quindi un collegamento tra i nuovi problemi e gli aggiornamenti software più recenti, anche se al momento non esiste una conferma ufficiale di un nesso diretto. Va inoltre considerato che segnalazioni simili emergono in modo intermittente da diversi mesi, a testimonianza di un problema non sempre riconducibile a un singolo aggiornamento.

Cosa consiglia Google

Google ha suggerito ad alcuni utenti di provare il reset delle impostazioni di rete, procedura raggiungibile da Impostazioni, poi Sistema, quindi Opzioni di ripristino e infine Reset Bluetooth e Wi-Fi. Diversi utenti confermano che questo intervento ha effettivamente risolto il problema, un’indicazione che in molti casi si tratti di un malfunzionamento software di lieve entità.

Un problema ricorrente per la gamma Pixel

Non è la prima volta che i Pixel vengono associati a problemi di connettività: in passato si sono verificati casi legati a specifici aggiornamenti software, oltre a episodi risolti tramite sostituzione hardware. Anche se le segnalazioni online non riflettono necessariamente la situazione di tutti gli utenti, la ricorrenza del fenomeno resta un aspetto da monitorare, soprattutto in vista dei prossimi Pixel di nuova generazione.

Sono emersi i primi risultati benchmark relativi allo Snapdragon 6 Gen 5, il nuovo chip di fascia media di Qualcomm, e i numeri non sembrano riflettere il salto prestazionale che ci si aspetterebbe da una nuova generazione. Il dato ha subito attirato l’attenzione degli appassionati, spesso abituati a miglioramenti più marcati tra una generazione e l’altra.

Punteggi Geekbench praticamente in linea con il predecessore

Il test è stato individuato su Geekbench e riguarda uno smartphone Honor non ancora annunciato, equipaggiato con lo Snapdragon 6 Gen 5. Il dispositivo ha ottenuto 1.095 punti in single-core e 3.355 in multi-core: numeri che, confrontati con lo Snapdragon 6 Gen 4, mostrano addirittura un leggero calo nel single-core (dove il chip precedente arrivava a 1.112 punti) e un progresso minimo nel multi-core.

Il dispositivo di test potrebbe essere un Honor X80 Pro Max

Secondo le prime ipotesi, lo smartphone testato corrisponderebbe a Honor X80 Pro Max, modello appena lanciato sul mercato cinese e dotato di una batteria maggiorata da 11.000 mAh. Trattandosi di un dispositivo appena presentato, mancano ancora test approfonditi e ottimizzazioni software che potrebbero far variare i punteggi nelle prossime settimane.

Le prestazioni CPU non raccontano tutta la storia

È comunque presto per giudicare il nuovo chip solo sulla base dei benchmark CPU. I processori di fascia media moderni puntano sempre più su comparto grafico, intelligenza artificiale ed efficienza energetica: secondo i primi dati, la GPU dello Snapdragon 6 Gen 5 mostrerebbe infatti un miglioramento di circa il 20%, un dato che potrebbe tradursi in benefici concreti su gaming e autonomia.

Meglio aspettare o puntare sul modello precedente?

Se i risultati preliminari dovessero essere confermati, per molti utenti potrebbe convenire orientarsi verso dispositivi con Snapdragon 6 Gen 4, i cui prezzi tendono solitamente a scendere subito dopo l’arrivo di una nuova generazione. In un contesto dove il salto prestazionale appare così contenuto, il rapporto qualità-prezzo del chip precedente potrebbe risultare più conveniente, almeno fino a nuovi test e all’annuncio ufficiale del nuovo SoC.

Google ha iniziato a distribuire, tramite l’aggiornamento del sistema Google Play di giugno 2026, una nuova funzione dedicata alle firme digitali integrate direttamente in Android. La novità permetterebbe di firmare documenti senza dover più ricorrere ad app di terze parti, con compatibilità annunciata a partire da Android 12.

Una funzione aggiunta senza clamore

La nuova funzione è comparsa silenziosamente con l’aggiornamento di giugno: Google non l’ha inclusa nelle note ufficiali di rilascio. Al momento risulta disponibile su alcuni dispositivi, tra cui Pixel 10 e Galaxy Z Fold 7, con un’espansione graduale prevista nelle prossime settimane. Il sistema è stato sviluppato come componente di Android 17, ma con retrocompatibilità fino ad Android 12.

Tre modi per creare la propria firma

La funzione consente di registrare la propria firma in tre modalità diverse, pensate per adattarsi a diverse esigenze d’uso.

• Firma manoscritta con il dito o con una penna stilo
• Digitazione di nome o iniziali con font in stile corsivo
• Acquisizione tramite fotocamera di una firma già scritta su carta

Una gestione centralizzata delle firme

Il sistema include una schermata dedicata, “Gestisci firme”, che permette di salvare più firme diverse: ad esempio una versione completa con nome e cognome e una più rapida con le sole iniziali, da usare a seconda del contesto. Nelle app compatibili basterebbe selezionare la firma salvata per inserirla direttamente nel documento.

Verso una firma elettronica più accessibile

Finora, firmare digitalmente un documento su Android richiedeva spesso app dedicate alla modifica di PDF o servizi online esterni. Integrando questa funzione a livello di sistema, Google elimina la necessità di installare applicazioni aggiuntive, rendendo la firma elettronica più semplice da usare per contratti, moduli e pratiche amministrative. Resta da vedere quando Google annuncerà ufficialmente la funzione e quali app la supporteranno pienamente.

Nothing si prepara a presentare il suo nuovo smartphone Nothing Phone (4b) il 7 luglio, e ha già anticipato che accanto al modello standard arriverà anche una versione speciale a tema sportivo, realizzata in collaborazione con i Royal Challengers Bengaluru (RCB), popolare franchigia della Indian Premier League di cricket.

Una collaborazione con il mondo del cricket

L’edizione speciale è stata annunciata da Nothing tramite un video pubblicato su Instagram insieme ai membri della squadra RCB. Pur non essendo ancora stati diffusi i dettagli completi del design, l’azienda ha confermato che il dispositivo adotterà una colorazione rossa ispirata ai colori del team, accompagnata probabilmente da sfondi esclusivi, un tema software dedicato e una confezione speciale.

Anche il modello standard potrebbe avere più colori

Secondo indiscrezioni emerse in parallelo, il Nothing Phone (4b) potrebbe arrivare in almeno tre colorazioni standard, tra cui nero, blu e bianco, a cui si aggiungerebbe il rosso dell’edizione speciale RCB come quarta variante disponibile. Non è ancora chiaro se la Special Edition verrà lanciata contestualmente al debutto del 7 luglio o in un secondo momento, seguendo una strategia già adottata da Nothing in passato con altri modelli.

Hardware sostanzialmente identico al modello base

Le differenze tra l’edizione RCB e il modello standard dovrebbero limitarsi principalmente all’estetica, mentre la scheda tecnica rimarrebbe invariata. Secondo le indiscrezioni circolate finora, il Nothing Phone (4b) dovrebbe montare un display AMOLED FHD+ da 6,7 pollici a 120 Hz, processore Snapdragon 6 Gen 4, 8 GB di RAM, tagli di archiviazione fino a 256 GB, fotocamera principale da 50 megapixel abbinata a un grandangolare da 8 megapixel e una batteria tra 5.000 e 6.000 mAh, con Android 16 preinstallato.

Appuntamento al 7 luglio

Nothing ha costruito negli anni un’identità forte puntando su design distintivo ed edizioni limitate, e la collaborazione con RCB sembra andare nella stessa direzione, puntando in particolare sul mercato indiano. Tutti i dettagli su prezzo, disponibilità e specifiche definitive saranno svelati in occasione della presentazione ufficiale del 7 luglio.

Google ha confermato che il fastidioso problema di riavvio in loop che colpisce alcuni Pixel 4a verrà finalmente risolto con l’aggiornamento di sistema Google Play di luglio 2026. Le segnalazioni si susseguivano da circa un mese, e l’azienda aveva già riconosciuto il problema senza però fornire una soluzione.

Un dispositivo che si riavvia senza sosta

Il malfunzionamento impedisce al Pixel 4a di completare l’avvio: lo smartphone raggiunge la schermata iniziale del boot ma poi si riavvia continuamente, restando bloccato in un ciclo. Il problema è stato segnalato prevalentemente su Pixel 4a, ma alcuni utenti riportano sintomi simili anche su Pixel 4 e Pixel 4 XL.

Le possibili cause

Diversi utenti hanno ipotizzato un legame con le impostazioni di Wi-Fi o localizzazione, ma finora non è stata individuata una causa certa. In assenza di una soluzione ufficiale, molti si sono trovati con il dispositivo temporaneamente inutilizzabile.

La correzione arriverà tramite Google Play

Google ha dichiarato che la correzione sarà distribuita attraverso l’aggiornamento del sistema Google Play di luglio, un canale diverso rispetto agli aggiornamenti OS veri e propri, pensato per aggiornare componenti di sistema senza richiedere un update completo. Diversamente da quanto accaduto a gennaio 2025 per un problema alla batteria, che richiese un intervento straordinario, questa volta la patch arriverà come parte del normale ciclo di aggiornamento.

Un supporto che continua oltre la fine del ciclo software

Il Pixel 4a ha già concluso il proprio periodo ufficiale di supporto software, ma Google ha scelto comunque di intervenire data la gravità del problema. Un segnale che conferma come, per bug particolarmente critici, i produttori Android tendano ormai a garantire interventi anche su dispositivi non più aggiornati regolarmente. Per chi è alle prese con i riavvii continui, l’aggiornamento di luglio rappresenta quindi la soluzione attesa da settimane.

Hypersomnia è uno sparatutto open source che combina azione tattica, editor integrato, networking deterministico e supporto multipiattaforma.
L'articolo Hypersomnia sparatutto open source che punta su tattica, velocità e tecnologia proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Eas...

🔗 Leggi il post completo

mpvRex, il lettore video Android basato su libmpv con interfaccia moderna, gesture avanzate, ampie opzioni di personalizzazione e prestazioni ottimizzate
L'articolo mpvRex il lettore video Android che porta libmpv a un nuovo livello proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy...

🔗 Leggi il post completo

Launchy è una dashboard self-hosted con bookmark, RSS, AI chat, meteo e widget personalizzabili. Deploy con Docker e pieno controllo dei dati.
L'articolo Launchy dashboard self-hosted per i tuoi bookmark e widget proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene rilasciato c...

🔗 Leggi il post completo

KStats è un nuovo widget per KDE Plasma 6 che porta nel pannello statistiche di sistema in tempo reale con un menu ricco di informazioni.
L'articolo KStats porta il monitoraggio di sistema direttamente nel pannello di KDE Plasma proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy vi...

🔗 Leggi il post completo

Il System76 Lemur Pro rappresenta l’eccellenza nel segmento dei notebook ultraportatili progettati per GNU/Linux, frutto dell’impegno di System76, azienda statunitense pioniere nell’hardware open source e nella creazione di un ecosistema completo per il sistema...

🔗 Leggi il post completo

Si parla di:
Toggle

Il Dipartimento di Stato americano ha messo sul piatto 10 milioni di dollari per chi fornira’ informazioni utili a identificare o localizzare i membri dei gruppi UNC5792 e UNC4221, entrambi legati ai servizi di intelligence militare e al FSB russo. Nel frattempo, FBI e CISA hanno aggiornato il loro advisory di marzo 2026 con una nuova tattica individuata nella campagna: il furto delle Signal Backup Recovery Key, che consente agli attaccanti di accedere all’intera cronologia dei messaggi delle vittime.

Chi sono UNC5792 e UNC4221

I due gruppi, tracciati pubblicamente con i designatori UNC di Mandiant/Google, operano nell’ambito dei servizi segreti russi. UNC5792 e’ associato all’FSB (Federal Security Service), in particolare agli ufficiali embedded nelle Guardie di Frontiera russe; UNC4221 opera invece per conto dei servizi militari russi. Le attivita’ delle due entita’ si sovrappongono parzialmente: entrambi prendono di mira individui di alto valore informativo attraverso campagne di phishing su applicazioni di messaggistica, in particolare Signal e WhatsApp.

Il profilo delle vittime e’ estremamente specifico e rivela gli obiettivi dell’intelligence russa: funzionari governativi statunitensi e NATO (attuali ed ex), vertici militari, figure politiche, analisti di policy, giornalisti che coprono Russia e Ucraina, ONG attive in supporto all’Ucraina e ricercatori di sicurezza o esperti di affari russi. Secondo l’annuncio ufficiale del programma Rewards for Justice, migliaia di account individuali sono stati compromessi in questo modo.

La storia della campagna: dall’account linking al furto delle Recovery Key

La campagna non nasce oggi. Il primo advisory pubblico di FBI e CISA risale a marzo 2026, quando gli analisti avevano documentato una tecnica di compromissione basata sull’abuso della funzione legittima di device linking di Signal. Gli attaccanti, spacciandosi per il supporto di Signal, inducevano le vittime a collegare un dispositivo controllato dagli attaccanti al proprio account, consentendo la lettura in tempo reale delle conversazioni senza compromettere la crittografia end-to-end del protocollo.

L’advisory aggiornato del 26 giugno 2026 documenta l’evoluzione della tattica. Gli operatori hanno ora spostato il loro obiettivo primario: non piu’ solo l’intercettazione in tempo reale, ma il furto delle Signal Backup Recovery Key — le chiavi che proteggono le copie cifrate dell’intera cronologia dei messaggi nei server Signal Secure Backups. Si tratta di un cambio di paradigma operativo significativo: con la Recovery Key, l’attaccante puo’ recuperare su un proprio dispositivo tutti i messaggi storici della vittima, incluse conversazioni private e di gruppo potenzialmente risalenti a mesi o anni.

Come funziona l’attacco in dettaglio

La catena di attacco si articola in due fasi di social engineering, entrambe condotte direttamente su Signal spacciandosi per il team di supporto della piattaforma:

Fase 1: il pretesto

La vittima riceve un messaggio che afferma che Signal ha registrato un’ondata di attacchi da parte di “hacker iraniani e di paesi post-sovietici” e che, in risposta, la piattaforma sta introducendo una verifica obbligatoria a due fattori. Per “non perdere messaggi e media”, l’utente viene guidato passo per passo ad abilitare i backup e a visualizzare la propria Recovery Key:

Istruzioni fornite dagli attaccanti nel messaggio di phishing:
Settings -> Backups -> Enable backups -> View recovery key
-> Copy to clipboard -> Next -> Enter the recovery key
-> Next -> Continue -> Choose your backup plan

[Premere "Accept" nel pop-up]

Fase 2: l’estrazione della chiave

Poco dopo, sempre spacciandosi per Signal, gli attaccanti inviano un secondo messaggio urgente che avvisa l’utente di un “problema di sincronizzazione” che metterebbe a rischio la perdita permanente dei dati. Per “risolvere il problema”, vengono chiesti di andare nelle impostazioni di backup, copiare la Recovery Key e incollarla nel messaggio di chat. Se la vittima esegue, gli attaccanti ottengono la chiave in chiaro.

Con la Recovery Key in mano, gli attaccanti possono ripristinare il backup cifrato su qualsiasi loro dispositivo, scaricando l’intera cronologia messaggi della vittima dai server di Signal. L’operazione e’ completamente silenziosa per la vittima: nessuna notifica, nessun alert sul dispositivo.

La trappola del recovery: perche’ cambiare account non basta

FBI e CISA sottolineano un aspetto critico spesso sottovalutato: se un attaccante ottiene la Recovery Key di un utente, creare un nuovo account Signal con lo stesso numero di telefono non invalida la chiave compromessa. L’attaccante puo’ continuare a utilizzare quella chiave per scaricare i backup gia’ acquisiti, anche dopo che la vittima ha cambiato account.

L’unica azione risolutiva e’ generare una nuova Recovery Key attraverso le impostazioni di backup di Signal, che invalida la chiave precedente per i download futuri. Tuttavia — e questa e’ la parte piu’ critica — una nuova chiave non impedisce l’accesso ai backup che l’attaccante ha gia’ scaricato prima del cambio.

Il bounty e gli obiettivi del programma Rewards for Justice

Il programma statunitense Rewards for Justice (RFJ) ha pubblicato il 29 giugno 2026 un annuncio specifico per UNC5792 e UNC4221, offrendo fino a 10 milioni di dollari per informazioni su:

• Identita’, localizzazione, affiliazioni e biografie dei membri dei gruppi e del personale di supporto.
• Legami con i servizi di intelligence russi, contractor e fornitori terzi.
• Infrastruttura operativa: domini, server, hosting, strumenti, framework e software.
• Fonti di finanziamento, conti bancari, meccanismi di pagamento.
• Wallet di criptovaluta, transazioni blockchain e reti finanziarie a supporto delle operazioni.

L’entita’ del bounty — identica a quella offerta per i responsabili di attacchi ransomware contro infrastrutture critiche — segnala quanto Washington consideri questa campagna una minaccia alla sicurezza nazionale, non un semplice problema di cybercrime.

Il fronte ucraino: SMS fasulli per rubare credenziali

Parallelamente all’advisory FBI/CISA, l’Ucraina ha confermato che l’intelligence russa ha utilizzato falsi messaggi SMS di “supporto tecnico” per indurre utenti ucraini a rivelare le credenziali dei propri account di messaggistica. La tattica e’ la stessa: impersonare un servizio tecnico legittimo, creare urgenza attraverso una narrativa di sicurezza, estrarre credenziali o chiavi di backup. Il coordinamento tra le due campagne — quella focalizzata su obiettivi occidentali (UNC5792/UNC4221) e quella contro obiettivi ucraini — suggerisce un’operazione di intelligence integrata sotto ombrello comune.

Consigli pratici per i difensori e gli utenti a rischio

Signal e le sue comunicazioni cifrate restano tecnicamente integre: la crittografia end-to-end del protocollo Signal non e’ stata compromessa. Il vettore e’ esclusivamente il social engineering applicato alla gestione delle chiavi. Le misure di difesa piu’ efficaci sono le seguenti:

• Non condividere mai la Recovery Key: Signal non la chiedera’ mai via messaggio in-app. Qualsiasi richiesta in tal senso e’ un attacco.
• Verificare l’identita’ del mittente: il supporto Signal comunica esclusivamente tramite indirizzi email ufficiali, mai tramite messaggi in-app.
• Controllare i dispositivi collegati: in Settings > Account > Linked Devices, verificare periodicamente che non siano presenti dispositivi non riconosciuti.
• Ruotare la Recovery Key in caso di sospetto: Settings > Backups > Recovery Key > Create new key. Ricordarsi che i backup gia’ scaricati dall’attaccante rimangono accessibili con la vecchia chiave.
• Segnalare attivita’ sospette all’IC3 dell’FBI (ic3.gov) o al proprio ufficio locale FBI.

Per le organizzazioni con personale ad alto rischio (giornalisti, diplomatici, ricercatori, personale ONG), e’ consigliabile implementare sessioni di awareness specifica sulla gestione delle Recovery Key di Signal e sul riconoscimento di questo pattern di social engineering, ormai sufficientemente documentato da considerarsi una tecnica consolidata nel repertorio dell’intelligence russa.

Si parla di:
Toggle

Per due settimane, prima ancora che Oracle pubblicasse una patch, un gruppo di cybercriminali ha avuto le chiavi di oltre cento infrastrutture PeopleSoft in tutto il mondo. Tra le vittime finite nella rete c’è la National Association of Insurance Commissioners (NAIC), l’organizzazione che coordina la vigilanza assicurativa dei 50 stati USA: 3,1 terabyte di dati pubblicati online, agenzie di rating che hanno sospeso i feed verso il regolatore, e la firma inconfondibile di ShinyHunters, oggi meglio nota agli analisti come UNC6240.

Chi c’è dietro l’attacco: da ShinyHunters a Scattered LAPSUS$ Hunters

ShinyHunters non è un nome nuovo per chi segue il cybercrime dei data breach: attivo almeno dal 2019 e comparso pubblicamente nel maggio 2020 con la vendita di dati sottratti a oltre una dozzina di aziende, il gruppo ha costruito la propria reputazione sul modello “pay or leak” — contatto privato con la vittima, richiesta di riscatto, pubblicazione dei dati in caso di rifiuto. Dal 2025 ShinyHunters opera in una struttura più ampia e fluida, la cosiddetta Scattered LAPSUS$ Hunters (SLH), un’alleanza informale che unisce le competenze di Scattered Spider (accesso iniziale tramite social engineering e SIM swap), LAPSUS$ (estorsione ad alta visibilità mediatica) e ShinyHunters stesso, specializzato in exfiltration su larga scala e gestione dei data leak site. È la stessa federazione già dietro le violazioni a catena di Salesforce e Snowflake nel 2025.

Mandiant e il Google Threat Intelligence Group tracciano il cluster responsabile della campagna PeopleSoft con la sigla UNC6240, confermando la sovrapposizione operativa con ShinyHunters.

CVE-2026-35273: RCE non autenticata nel cuore di PeopleSoft

Il vettore d’ingresso è una vulnerabilità critica (CVSS 9.8) in Oracle PeopleSoft Enterprise PeopleTools, versioni 8.61 e 8.62, localizzata nel componente Environment Management Hub, noto anche come PSEMHUB. Tecnicamente si tratta di una Server-Side Request Forgery che, incatenata correttamente, consente l’esecuzione di codice remoto senza alcuna autenticazione né interazione dell’utente: basta accesso di rete via HTTP agli endpoint /PSEMHUB/hub e /PSIGW/HttpListeningConnector per prendere il controllo del server.

Il dettaglio più inquietante è la tempistica. Secondo Mandiant, lo sfruttamento attivo in the wild è iniziato il 27 maggio 2026, ben prima che Oracle rilasciasse un advisory di sicurezza: un vero zero-day, sfruttato per circa due settimane a insaputa dei difensori. Solo il 10 giugno 2026 Oracle ha pubblicato una patch fuori banda (Patch Availability Document CPU187), poi confluita nel Critical Patch Update di giugno. Nel frattempo, CISA ha aggiunto la falla al proprio catalogo Known Exploited Vulnerabilities.

Una campagna su scala industriale

Tra il 27 maggio e il 9 giugno gli attaccanti hanno colpito circa 300 istanze PeopleSoft appartenenti a oltre 100 organizzazioni, con il 68% delle vittime concentrato nel settore dell’istruzione superiore, in gran parte negli Stati Uniti. Il gruppo ha pubblicato i dati sottratti sul proprio data leak site già il 9 giugno, un giorno prima ancora della patch ufficiale.

Sul piano operativo, gli attaccanti hanno predisposto ambienti di staging che ospitavano agenti MeshCentral camuffati da servizi Microsoft Azure legittimi (file come meshagent64-azure-ops.exe), utilizzati per eseguire query amministrative ed effettuare movimento laterale. Un elemento tecnico rilevante è lo script di defacement e lateral movement che automatizza il credential spraying via SSH: analizza il file /etc/hosts locale per identificare host interni secondo pattern di naming specifici, poi tenta l’autenticazione con una lista predefinita di credenziali amministrative e applicative comuni.

Il caso NAIC: cosa è stato sottratto

NAIC ha rilevato l’accesso non autorizzato al proprio ambiente PeopleSoft l’11 giugno 2026. ShinyHunters ha rivendicato il furto di 3,1 terabyte di dati, oltre 105.000 file: più di 264.000 PDF di filing regolatori assicurativi (rami property, casualty, health e life) relativi al periodo 2017-2024, circa 45.000 file provenienti da importanti agenzie di rating creditizio (tra cui Moody’s, Fitch, S&P, Kroll, DBRS, AM Best), log e file di configurazione di infrastruttura AWS di produzione, oltre a script SQL contenenti credenziali per ambienti produttivi.

NAIC ha dichiarato che nessun dato personale identificabile né informazioni di pagamento risultano compromessi, e che i sistemi regolatori critici — SERFF, OPTins, UCAA, EDP e RDC — non sono stati toccati. Ma l’impatto operativo è stato comunque tangibile: diverse agenzie di rating hanno sospeso temporaneamente i feed di dati verso il regolatore, e NAIC ha interrotto momentaneamente l’assegnazione delle proprie designazioni di investimento, i parametri che determinano quanto capitale gli assicuratori vita statunitensi devono accantonare a fronte dei propri portafogli. Un breach che tocca un ente pubblico, quindi, si traduce in frizioni immediate sull’intero mercato assicurativo americano.

Cosa devono fare i difensori

• Applicare immediatamente la patch CPU187 di Oracle su tutte le istanze PeopleSoft PeopleTools 8.61/8.62.
• Se il patching non è immediato, bloccare l’esposizione internet degli endpoint EMHub/PSEMHUB o disabilitare il servizio nelle configurazioni multi-server; nelle installazioni single-server valutare la rimozione dell’applicazione PSEMHUB.
• Verificare i log di accesso WebLogic per richieste POST esterne verso /PSEMHUB/hub o /PSIGW/HttpListeningConnector.
• Cercare file .jsp non attesi sotto PSEMHUB.war e cartelle anomale (logs, persistantstorage, scratchpad); controllare modifiche recenti ai file XML sotto envmetadata/data/environment, potenziale vettore di persistenza via XMLDecoder al riavvio.
• Monitorare traffico DNS e connessioni verso il dominio C2 noto azurenetfiles.net.
• Ruotare le credenziali potenzialmente esposte in script SQL, configurazioni e log applicativi.

La campagna NAIC conferma un pattern ormai consolidato per l’alleanza Scattered LAPSUS$ Hunters: individuare zero-day in software enterprise ampiamente diffusi (Salesforce, Snowflake, ora Oracle PeopleSoft), colpire in massa prima che la finestra di patching si chiuda, e monetizzare l’estorsione anche quando i dati sottratti sono in gran parte “pubblici” o di scarso valore diretto — sfruttando la pressione reputazionale e regolatoria che un data leak comporta per l’organizzazione colpita.

Indicatori di compromissione

CVE: CVE-2026-35273 (CVSS 9.8, SSRF -> RCE non autenticata)
Componente: Oracle PeopleSoft PeopleTools 8.61 / 8.62 - Environment Management Hub (PSEMHUB)
Endpoint sfruttati:
  /PSEMHUB/hub
  /PSIGW/HttpListeningConnector

C2 domain: wss://azurenetfiles[.]net:443/agent.ashx

Agenti MeshCentral malevoli (masquerading Azure):
  meshagent32-azure-ops.exe
  meshagent64-azure-ops.exe
  meshagent64-v2.exe

IP di staging (Python HTTP server, porta 8888):
  142.11.200.186 - 142.11.200.190

Percorsi sospetti da monitorare:
  /logs/
  /persistantstorage/
  /scratchpad/
  envmetadata/data/environment/*.xml (persistenza via XMLDecoder)

Attore: UNC6240 (Mandiant) / ShinyHunters / Scattered LAPSUS$ Hunters
Finestra di sfruttamento zero-day: 27 maggio - 9/10 giugno 2026
Patch Oracle: CPU187, rilasciata 10 giugno 2026

Si parla di:
Toggle

Un worm nato per infettare pacchetti npm, pensato per propagarsi da un progetto all’altro sottraendo token di pubblicazione, si è trasformato in un vettore capace di arrivare fino a un data warehouse Amazon Redshift in produzione. È la traiettoria che i ricercatori di FortiGuard Labs hanno ricostruito analizzando una compromissione partita da un semplice runner Jenkins esposto: nel giro di poche ore, l’attaccante è passato da un job di build a pieni poteri amministrativi sull’intero account AWS.

Shai-Hulud: la storia del worm che ha terrorizzato npm

Battezzato con il nome dei vermi delle sabbie di Dune, Shai-Hulud è emerso per la prima volta alla fine del 2025 come campagna di supply chain attack contro l’ecosistema npm, e da allora è stato attribuito al cluster tracciato come TeamPCP. Il meccanismo è quello del worm classico: un pacchetto compromesso esegue codice malevolo durante l’installazione o all’interno di una pipeline CI, ruba i token e le credenziali di build presenti sulla macchina, e li usa per pubblicare versioni trojanizzate di altri pacchetti di cui il maintainer ha accesso — propagandosi così, in autonomia, lungo l’intero grafo delle dipendenze.

La variante più recente, Shai-Hulud 2.0, ha alzato ulteriormente l’asticella: all’infezione di un pacchetto legittimo vengono iniettati due file, setup_bun.js e bun_environment.js, attivati tramite uno script di preinstall (anziché postinstall come nella prima ondata) — una modifica che amplia sensibilmente la superficie di impatto perché il codice malevolo scatta prima ancora che l’installazione del pacchetto sia completa. Il payload offuscato raccoglie credenziali da oltre 100 percorsi di file diversi, spaziando da provider cloud a wallet di criptovalute, tool AI e app di messaggistica, e installa hook di persistenza dentro Claude Code, VS Code e servizi a livello di sistema operativo, capaci di sopravvivere al riavvio della macchina. Secondo le stime della community, la campagna 2.0 ha compromesso almeno 796 pacchetti npm unici (1.092 versioni), toccando oltre 25.000 repository riconducibili a circa 350 maintainer.

Dal runner Jenkins a Redshift: la ricostruzione di FortiGuard Labs

Il caso analizzato da FortiCNAPP nasce a metà maggio 2026, quando gli analisti individuano su un ambiente cliente l’accesso persistente a un Jenkins runner con un pattern di credential-harvesting coerente con Shai-Hulud. Il runner, raggiungibile da internet, viene usato dall’attaccante come testa di ponte: sfruttando il ruolo IAM associato al job Jenkins, l’operatore compie un’escalation di privilegi fino a ottenere pieno accesso amministrativo sull’account cloud, dopodiché modifica i controlli di rete del database e avvia l’estrazione di dati da Amazon Redshift.

La sequenza operativa ricostruita da FortiGuard Labs è particolarmente istruttiva perché mostra quanto velocemente un accesso CI/CD apparentemente marginale possa tradursi in un data breach cloud su vasta scala:

• Creazione di un utente IAM con nome cloudops-monitor, pensato per confondersi con account di monitoraggio legittimi.
• Attribuzione della policy AdministratorAccess al nuovo utente ed emissione di access key.
• Modifica dei security group per allargare l’accesso di rete verso i database.
• Tentativi di modifica della configurazione di accesso a RDS e Redshift.
• Enumerazione sistematica di AWS Secrets Manager, con recupero dei secret collegati al data warehouse.
• Uso ripetuto della Redshift Data API (chiamate ExecuteStatement, DescribeStatement e successivo recupero dei risultati) per interrogare ed esfiltrare dati senza bisogno di una connessione diretta al cluster.
• Creazione di policy IAM con nomi espliciti dal chiaro intento di esfiltrazione, assunzione di ruoli con session name come exfil, e uso di SSM SendCommand insieme alla verifica di identità su Amazon SES — probabilmente in preparazione di un canale di invio dati o notifiche verso l’esterno.

Questa catena mostra un salto qualitativo rispetto alle prime campagne Shai-Hulud, centrate quasi esclusivamente sul furto di token npm e credenziali di sviluppatori: qui l’obiettivo finale è chiaramente il dato strutturato in un data warehouse aziendale, raggiunto attraverso l’abuso sistematico dei permessi IAM disponibili nella pipeline compromessa.

Perché la CI/CD è il bersaglio ideale

I runner Jenkins, GitHub Actions e sistemi CI/CD analoghi sono per costruzione dei nodi ad alto privilegio: hanno bisogno di credenziali per pubblicare pacchetti, effettuare il deploy su infrastruttura cloud e interagire con registry e repository. Quando queste credenziali sono sovradimensionate rispetto al reale bisogno — un ruolo IAM che consente escalation invece di essere ristretto al minimo indispensabile — un singolo pacchetto npm compromesso durante una build automatica può bastare per compiere il salto da “sviluppatore infettato” a “amministratore dell’intero account cloud”. È esattamente lo scenario che rende Shai-Hulud diverso da un comune infostealer: non si limita a rubare, usa quello che ruba per muoversi lateralmente e scalare privilegi in autonomia.

Raccomandazioni per i difensori

• Applicare il principio del minimo privilegio ai ruoli IAM usati dai runner CI/CD: nessun job di build dovrebbe poter assumere ruoli con permessi di amministrazione dell’account.
• Isolare i runner Jenkins/CI da internet o proteggerli dietro autenticazione forte e reti segmentate.
• Monitorare la creazione di utenti/ruoli IAM anomali, in particolare l’attribuzione di AdministratorAccess a identità nuove o non previste nell’infrastructure-as-code.
• Alert su chiamate massive alla Redshift Data API o pattern insoliti di query su data warehouse da identità di servizio.
• Verificare l’eventuale presenza degli script setup_bun.js e bun_environment.js in node_modules, e controllare gli script di preinstall dei pacchetti recentemente aggiornati.
• Applicare lockfile e pinning delle versioni, con verifica delle firme dei pacchetti dove disponibile, per limitare l’impatto di aggiornamenti automatici malevoli.
• Ruotare immediatamente tutte le credenziali (token npm, chiavi AWS, secret in Secrets Manager) se si sospetta una compromissione, anche parziale, della toolchain di sviluppo.

Il caso ricostruito da FortiGuard Labs è un promemoria scomodo: la supply chain del software open source non è più solo un problema di sviluppatori, ma un vettore diretto verso i dati più sensibili dell’azienda, quando la fiducia implicita accordata alle pipeline di build non è accompagnata da controlli granulari sui permessi cloud.

Indicatori di compromissione

Malware: Shai-Hulud / Shai-Hulud 2.0 (worm supply chain, ecosistema npm/PyPI)
Attore: TeamPCP (cluster tracciato)

File iniettati nei pacchetti compromessi:
  setup_bun.js
  bun_environment.js
Trigger: script "preinstall" (2.0) invece di "postinstall" (1.0)

Scala campagna 2.0 (stime community):
  796+ pacchetti npm unici compromessi
  1.092 versioni di pacchetto interessate
  25.000+ repository coinvolti
  ~350 maintainer impattati

Catena post-compromissione osservata da FortiGuard Labs (caso Jenkins -> Redshift):
  - Nuovo utente IAM: cloudops-monitor
  - Policy attribuita: AdministratorAccess
  - Modifica security group per esporre database
  - Enumerazione AWS Secrets Manager
  - Uso Redshift Data API: ExecuteStatement / DescribeStatement
  - Ruoli assunti con session name: "exfil"
  - Attività su SSM SendCommand e verifica identità Amazon SES

Persistenza osservata su endpoint sviluppatore:
  Hook in Claude Code, VS Code, servizi OS-level (sopravvivono al reboot)

Riferimento tecnico: FortiGuard Labs,
"From CI/CD to Cloud Data: How Shai Hulud Persistence Leads to Redshift Breach"

COSMIC è un ambiente desktop moderno e completamente open source sviluppato da System76, azienda statunitense specializzata nella produzione di computer e nella realizzazione di Pop!_OS, una distribuzione GNU/Linux basata su Ubuntu. Il progetto nasce...

🔗 Leggi il post completo

4kwall, l'app per Linux che permette di trovare, scaricare e gestire milioni di sfondi HD, 4K e 8K con un'interfaccia moderna.
L'articolo 4kwall l’app Linux per trovare e gestire milioni di sfondi in HD, 4K e 8K proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene rilascia...

🔗 Leggi il post completo

Un nuovo leak alimenta le attese sul prossimo tablet da gaming compatto di Lenovo, atteso per agosto. Secondo le ultime indiscrezioni, il dispositivo potrebbe debuttare con un pannello OLED, una novità assoluta per la linea Legion, oltre alla connettività 5G già emersa in precedenti rumor.

Un pannello OLED per la prima volta sulla serie Legion

Le informazioni arrivano dal noto leaker cinese Digital Chat Station, che su Weibo ha rivelato come il nuovo tablet compatto di Lenovo adotterà uno schermo OLED. Il modello di quest’anno, il Legion Y700 di quinta generazione, montava ancora un display LCD: il salto all’OLED promette un deciso miglioramento della qualità dell’immagine.

Il possibile nome: Legion Y700 Infinite

Il tablet individuato sarebbe lo stesso dispositivo non ancora annunciato avvistato durante l’evento gaming G-Fusion Game Festival di Shenzhen. Secondo le fonti, si tratterebbe del “Legion Y700 Infinite”, già annunciato da Lenovo per agosto: sarebbe il quarto tablet della gamma Legion presentato nel corso del 2026.

Nel mirino la concorrenza di RedMagic

Il nuovo modello sembra pensato soprattutto per contrastare il RedMagic Gaming Tablet 5 Pro, che offre un pannello OLED a 185 Hz ma senza supporto 5G. Lenovo punterebbe quindi a distinguersi offrendo sia il pannello OLED sia la connettività cellulare, una combinazione che però potrebbe far salire il prezzo rispetto all’attuale Legion Y700.

Un segmento sempre più competitivo

Il mercato dei tablet gaming compatti, con diagonali intorno agli 8 pollici, sta vivendo una nuova fase di interesse dopo anni dominati dai modelli di grandi dimensioni. Oltre a Lenovo, anche iQOO starebbe preparando un tablet compatto per la seconda metà del 2026, mentre secondo alcuni rumor pure Apple lavorerebbe a un iPad mini con schermo OLED. L’annuncio ufficiale del nuovo Legion è atteso per agosto: nelle prossime settimane potrebbero emergere ulteriori dettagli su specifiche e prezzo.

Google ha rilasciato Android 17 QPR1 Beta 6 per i dispositivi Pixel. Si tratta della terza beta dedicata principalmente alla correzione di bug, ma che porta con sé anche alcune novità grafiche e funzionali in vista della versione definitiva, ormai sempre più vicina.

Nuova grafica per sfondi e icona delle impostazioni

La schermata di selezione degli sfondi è stata ridisegnata con un layout più ordinato e leggibile, che semplifica la personalizzazione del dispositivo. Cambia anche l’icona dell’app Impostazioni, già vista su Pixel Watch, che ora appare in versione rinnovata quando viene spostata sulla schermata home.

Health Connect si arricchisce di nuovi dati

Anche Health Connect viene ampliato: da questa beta lo smartphone può registrare autonomamente distanza percorsa e calorie consumate, senza bisogno di dispositivi esterni, ampliando le funzioni dedicate al monitoraggio della salute e del fitness.

Raggiunta la Platform Stability

Google ha confermato che Android 17 QPR1 ha raggiunto la fase di “Platform Stability”: le API e il comportamento delle app sono ormai definiti, segno che il sistema è entrato nella fase finale di rifinitura prima del rilascio stabile.

I principali bug corretti

• Risolto un problema che impediva di selezionare più lingue per il controllo ortografico
• Migliorato il comportamento dei tasti volume durante l’uso dell’app Orologio
• Corretta la visualizzazione delle impostazioni rapide durante il cambio veloce di player multimediali
• Risolti crash che interessavano alcune applicazioni
• Corretto un bug che mostrava il nome di rete predefinito invece dell’SSID personalizzato con il tethering Wi-Fi attivo

Dispositivi compatibili

Android 17 QPR1 Beta 6 è disponibile per tutta la gamma Pixel supportata, da Pixel 6a fino ai recenti Pixel 10, 10 Pro e 10 Pro Fold. Pur senza grandi novità, l’aggiornamento conferma il percorso verso una versione finale sempre più stabile e rifinita.

RedMagic ha presentato ufficialmente il Gaming Tablet 5 Pro sul mercato cinese. Il tablet da gaming più estremo dell’anno integra il chip Snapdragon 8 Elite Gen 5, un display OLED da 185Hz e un sistema di raffreddamento a liquido — più un emulatore PC che supporta Steam.

Display OLED da 9 pollici a 185Hz

Il pannello OLED misura 9,06 pollici con frequenza di aggiornamento a 185Hz — tra le più alte su un tablet Android. La luminosità di picco in HDR arriva a 1.600 nit, mentre in full screen si attestano a 1.100 nit. Valori che garantiscono visibilità eccellente anche alla luce diretta del sole e colori vividi per titoli HDR.

Raffreddamento a liquido e pannello trasparente

Per gestire il calore generato dallo Snapdragon 8 Elite Gen 5 durante sessioni di gioco prolungate, RedMagic ha integrato un sistema di raffreddamento a liquido. Il pannello posteriore trasparente rende visibile il sistema di cooling, trasformando la tecnologia in un elemento estetico con illuminazione RGB.

Steam e doppia USB-C

La caratteristica più insolita è l’emulatore PC integrato con supporto a Steam: è possibile accedere alla propria libreria Steam direttamente dal tablet, senza connessione a un PC. Il dispositivo dispone anche di due porte USB-C per maggiore flessibilità nella ricarica e nella connessione di periferiche.

Nome globale: RedMagic Astra 2

Il Gaming Tablet 5 Pro arriverà sui mercati internazionali con il nome RedMagic Astra 2. Non sono ancora note le date per il mercato europeo né i prezzi ufficiali per l’Italia.

Lenovo annuncia il Tab Plus Gen 2, un tablet Android da 12,1 pollici pensato per il multimedia di alta qualità. Con 9 speaker JBL integrati, display 2.5K, Dolby Vision e una modalità speaker Bluetooth, si candida a diventare il centro entertainment per la casa.

Nove speaker JBL per un suono da sala cinema

Il punto di forza del Tab Plus Gen 2 è il sistema audio: 9 unità speaker firmate JBL, distribuite tra i lati e il retro del dispositivo. La configurazione include 4 tweeter laterali, 3 woofer posteriori e 2 radiatori passivi. Il supporto Dolby Audio garantisce una risposta sonora bilanciata su tutta la gamma di frequenze. La funzione Bluetooth speaker mode permette di collegare lo smartphone e usare il tablet come cassa wireless.

Display da 12,1 pollici con 120Hz e Dolby Vision

Il pannello LCD misura 12,1 pollici con risoluzione 2.5K (2560×1600 pixel) e frequenza di aggiornamento a 120Hz. La luminosità raggiunge 800 nit, con supporto a HDR10 e Dolby Vision per una resa cromatica fedele su contenuti premium. La cornice integra uno stand regolabile che permette di posizionare il tablet verticalmente senza accessori aggiuntivi.

Disponibilità e prezzo

Il Lenovo Tab Plus Gen 2 sarà disponibile in Giappone dal 3 luglio 2026 a un prezzo di circa 74.800 yen (circa 470 euro al cambio attuale). Non sono ancora state annunciate date per il mercato europeo, ma Lenovo distribuisce i suoi tablet in Italia e un arrivo nel corso del 2026 è plausibile.

I moderni strumenti di coding assistito da AI stanno diventando parte integrante del flusso di lavoro di milioni di sviluppatori. Ma questa automazione introduce una nuova superficie di attacco che i ricercatori di sicurezza hanno appena dimostrato in modo preoccupante: un repository GitHub apparentemente pulito può indurre un agente AI a eseguire malware, senza che nessun codice malevolo sia visibile né agli scanner statici né agli occhi umani.

La ricerca di Mozilla 0DIN

I ricercatori della Mozilla Zero Day Investigative Network (0DIN), la piattaforma di sicurezza AI di Mozilla, hanno pubblicato un proof-of-concept che dimostra come un agente di coding autonomo possa essere indotto a installare una reverse shell sul sistema dello sviluppatore. Il test è stato condotto specificamente con Claude Code, ma la vulnerabilità concettuale riguarda qualsiasi agente AI che abbia accesso al filesystem e al terminale.

La parte più inquietante della ricerca è questa frase dei ricercatori: “No exploit code, no warning, no suspicious command anyone had to approve.” Nessun codice exploit, nessun avvertimento, nessun comando sospetto da approvare.

Come funziona l’attacco: tre componenti innocui

L’attacco si basa su tre elementi che, considerati singolarmente, non destano alcun sospetto:

1. Un repository GitHub pulito — Il repo contiene istruzioni di setup standard: installazione dipendenze (pip3 install -r requirements.txt) e inizializzazione del progetto (python3 -m axiom init). Nessun codice malevolo, nessun flag da scanner.
2. Un pacchetto Python progettato per fallire — Il package è volutamente configurato per rifiutare l’esecuzione finché non viene inizializzato. Genera un errore che istruisce l’utente (o l’agente) a eseguire python3 -m axiom init. L’agente AI, tentando di risolvere autonomamente l’errore di setup, lancia questo comando.
3. Un record DNS TXT controllato dall’attaccante — Il comando di inizializzazione chiama uno script shell che recupera un valore di configurazione da un record DNS TXT controllato dall’attaccante. Quel valore viene eseguito come comando.

Il risultato è una reverse shell con i privilegi del developer. L’agente AI ha eseguito tre livelli di indirection — un messaggio di errore fidato, uno script che ha recuperato un valore, e un record DNS che non ha mai esaminato — senza mai “vedere” il payload malevolo.

Perché è invisibile ai controlli tradizionali

Questa tecnica bypassa tutti i meccanismi di difesa convenzionali:

• Scanner statici: non trovano nulla perché il repository è genuinamente pulito
• Code review umana: anche un revisore attento non vedrebbe codice malevolo
• AI review: l’agente AI valuta solo il codice che vede, non il payload DNS
• Audit log limitati: l’agente potrebbe non registrare l’intera catena di esecuzione, incluse le risorse recuperate dinamicamente a runtime

Ciò che rende l’attacco efficace è il comportamento goal-oriented degli agenti AI: quando incontrano un errore, il loro obiettivo è risolverlo. E lo risolvono eseguendo esattamente ciò che viene suggerito — anche se quel suggerimento porta a recuperare ed eseguire un payload da un record DNS remoto.

Cosa ottiene l’attaccante

Se l’attacco va a segno, l’attaccante ottiene una shell interattiva con i privilegi dello sviluppatore. Questo significa accesso a:

• Variabili d’ambiente (incluse credenziali e API key)
• File di configurazione locali (chiavi SSH, certificati, config di cloud provider)
• Possibilità di stabilire persistenza sul sistema
• Accesso ai repository locali e ai segreti in essi contenuti

I ricercatori 0DIN avvertono che questa tecnica potrebbe essere distribuita facilmente attraverso fake job posting, tutorial, post su blog tecnici o messaggi diretti su piattaforme come Discord o LinkedIn.

Come mitigare il rischio

0DIN ha proposto alcune contromisure concrete per chi sviluppa o utilizza strumenti di coding AI agentico:

1. Execution chain disclosure: gli agenti AI dovrebbero mostrare esplicitamente l’intera catena di esecuzione dei comandi di setup, inclusi script e codice recuperato dinamicamente a runtime, prima di eseguirlo.
2. Sandboxing più rigido: gli agenti autonomi che interagiscono con repository esterni dovrebbero operare in ambienti isolati (container, VM, namespace separati) con privilegi minimi.
3. Permission scoping: limitare le azioni che un agente AI può compiere autonomamente — specialmente l’esecuzione di comandi shell — richiedendo conferma esplicita dell’utente per operazioni ad alto rischio.
4. Monitoraggio DNS in uscita: implementare logging e alerting su query DNS anomale durante le operazioni di build e setup.
5. Analisi comportamentale: non fidarsi solo degli scanner statici, ma adottare strumenti di analisi comportamentale che monitorino le azioni effettive a runtime.

Un segnale di allarme per il settore

Questa ricerca evidenzia un problema strutturale nell’adozione degli agenti AI nel ciclo di sviluppo: l’automazione che ci fa risparmiare tempo è la stessa che può diventare un vettore di attacco. Man mano che strumenti come Claude Code, GitHub Copilot Workspace e altri agenti simili vengono integrati nelle pipeline CI/CD e nei workflow quotidiani, la superficie di attacco si espande in modi che i modelli di minaccia tradizionali non contemplano.

La buona notizia è che, per ora, si tratta di un proof-of-concept. La cattiva è che chiunque abbia letto questa ricerca sa come replicarlo — e il costo per un attaccante è praticamente zero: basta pubblicare un repository GitHub e registrare un dominio per il record DNS TXT.

Per i team di sicurezza, questo è il momento di rivedere le policy di utilizzo degli agenti AI, in particolare per quanto riguarda le operazioni autonome su repository di terze parti.

Fonte originale: 4sysops.com — ricerca originale di Mozilla 0DIN via BleepingComputer

Cosa sono i WSL Container?

Microsoft ha annunciato a fine giugno 2026 la public preview di WSL Container, una nuova funzionalità del Windows Subsystem for Linux che porta lo sviluppo di container Linux direttamente in Windows, senza richiedere strumenti di terze parti. L’annuncio è arrivato durante Microsoft Build 2026 e rappresenta un passo significativo verso l’integrazione nativa dei workload containerizzati nell’ecosistema Windows.

I container sono diventati una parte fondamentale dello sviluppo moderno: dalle applicazioni cloud-native ai carichi AI, dai test alle pipeline di deployment. Fino ad ora, gli sviluppatori su Windows dovevano ricorrere a Docker Desktop, Podman Desktop o Rancher Desktop, strumenti di terze parti non sempre ideali in ambienti enterprise per questioni di licensing o di gestione centralizzata. WSL Container punta a risolvere questo problema con una soluzione nativa, enterprise-ready e integrata con le policy di gestione Microsoft.

Le due componenti principali

La CLI: wslc.exe

Il cuore della nuova funzionalità è il binario wslc.exe, disponibile automaticamente nel PATH dopo aver aggiornato WSL alla versione pre-release più recente. La sintassi è volutamente familiare a chiunque abbia già usato Docker:

# Aggiornare WSL alla versione pre-release
wsl --update --pre-release

# Eseguire un desktop Linux completo in un container
wslc run -d --name=webtop \
  -e PUID=1000 \
  -e PGID=1000 \
  -e TZ=Etc/UTC \
  -p 3000:3000 \
  -p 3001:3001 \
  lscr.io/linuxserver/webtop:ubuntu-kde

# Verificare l'accesso GPU con PyTorch
wslc run --rm --gpus all pytorch/pytorch:2.5.1-cuda12.4-cudnn9-runtime \
  python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.get_device_name(0))"

La WSL Container API

La seconda componente è un package NuGet che permette alle applicazioni Windows di usare container Linux come parte della propria logica applicativa. L’API supporta C, C++ e C# e consente di gestire programmaticamente pull di immagini, avvio dei container, interazione via stdin/stdout, mount di file, configurazione di rete e accesso GPU.

Un aspetto particolarmente interessante per chi usa MSBuild o CMake è che l’API si integra direttamente nel sistema di build: aggiungendo poche righe ai file di progetto, la build e il deploy del container diventano parte del processo di compilazione dell’applicazione, senza step manuali aggiuntivi.

// Esempio di utilizzo base dell'API WSL Container in C#
// (il package è disponibile su nuget.org)
using Microsoft.WSL.Container;

var client = new WslContainerClient();

// Pull di un'immagine
await client.PullAsync("ubuntu:24.04");

// Avvio del container
var container = await client.RunAsync(new ContainerOptions
{
    Image = "ubuntu:24.04",
    Command = "/bin/bash",
    Interactive = true
});

// Interazione via stdin/stdout
await container.WriteLineAsync("echo 'Hello from Linux container!'");
string output = await container.ReadLineAsync();
Console.WriteLine(output);

Integrazione enterprise

Una delle priorità dichiarate di Microsoft è l’integrazione con gli strumenti di gestione enterprise già in uso nelle organizzazioni.

Microsoft Defender for Endpoint

Il plugin MDE esistente per WSL è stato aggiornato per rilevare anche gli eventi provenienti dai container Linux, offrendo la stessa copertura di sicurezza sia per le distro WSL tradizionali che per i nuovi container. Questa funzionalità è attualmente disponibile in private preview su registrazione.

Gestione con Intune e Group Policy

Tramite un file ADMX già disponibile su GitHub, è possibile configurare policy di gruppo per controllare se gli utenti possono avviare distro WSL o container, e soprattutto specificare una allowlist dei registry di container da cui è consentito fare pull di immagini. Questa è una risposta diretta a una delle richieste più frequenti degli amministratori enterprise: avere controllo sulle immagini Linux autorizzate nell’organizzazione. Il supporto nativo in Intune è previsto nelle settimane successive alla preview.

VS Code Dev Containers

Il supporto a VS Code Dev Containers è stato aggiunto a partire dalla versione 0.462.0-pre-release dell’estensione. La configurazione è semplice: nelle impostazioni dei Dev Containers di VS Code, basta modificare il campo “Docker Path” impostando il valore wslc. In questo modo VS Code utilizzerà wslc.exe invece di Docker per gestire i container di sviluppo.

Miglioramenti a livello di piattaforma

Lo sviluppo di WSL Container ha portato con sé significativi miglioramenti all’infrastruttura di WSL stessa, che beneficeranno anche dei tool di terze parti come Docker Desktop, Podman e Rancher Desktop.

Il filesystem predefinito per WSL Container è ora virtiofs, che raddoppia le prestazioni di accesso ai file Windows rispetto al layer precedente. La modalità di networking predefinita è consomme, una soluzione sperimentale che instrada il traffico di rete Linux attraverso lo stack Windows, garantendo compatibilità con VPN aziendali, proxy e policy di sicurezza di rete già configurate per i client Windows. Infine, sono state introdotte tecniche migliorative per il reclaim della memoria, con rilascio graduale e consistente della RAM non utilizzata dalla VM Linux verso l’host Windows.

Supporto GPU

Una delle funzionalità più rilevanti per chi lavora con carichi di Machine Learning è il supporto nativo alla GPU. Passando il flag --gpus all, i container WSL possono accedere all’hardware grafico dell’host, consentendo a framework come PyTorch di sfruttare l’accelerazione GPU direttamente dall’interno di un container Linux su Windows.

Come iniziare

La funzionalità è disponibile già oggi nella versione pre-release di WSL:

# Installare la versione pre-release di WSL
wsl --update --pre-release

# Oppure scaricare direttamente da GitHub (versione 2.9.3 o superiore)
# https://github.com/microsoft/WSL/releases

# Verificare la versione installata
wsl --version

# Primo test: verificare che wslc sia nel PATH
wslc --version

# Eseguire un container Ubuntu di base
wslc run --rm ubuntu:24.04 echo "WSL Container funziona!"

Considerazioni finali

WSL Container non vuole sostituire Docker, Podman o i tool esistenti — anzi, tutti questi beneficeranno delle migliorie a livello di piattaforma che questa nuova funzionalità porta con sé. L’obiettivo è offrire un’opzione nativa, senza licensing enterprise, con una gestione centralizzata tramite Intune e Group Policy, e con un’integrazione profonda nell’ecosistema di sicurezza Microsoft.

Per i team che già usano WSL intensivamente nel proprio workflow di sviluppo, WSL Container rappresenta un’evoluzione naturale: stessi strumenti, stessa infrastruttura, ma ora con la possibilità di isolare i processi Linux in container veri e propri. La GA è attesa per l’autunno 2026.

Fonte: WSL container is now available for public preview — Windows Command Line Blog (Craig Loewen, 29 giugno 2026)

Billance crea e converte fatture elettroniche ZUGFeRD e XRechnung con AI, validazione e sincronizzazione cloud per professionisti e PMI
L'articolo Billance fatturazione elettronica B2B per professionisti e PMI proviene da Linux Easy.
E' vietato riprodurre questo articolo senza autorizzazione.
Questo feed RSS è destinato ai lettori, non agli scraper o aggregatori.
Linux Easy viene rilasciato con L...

🔗 Leggi il post completo

Il Motorola Edge 70 Max è apparso nel database della Wireless Power Consortium con la certificazione Qi2.2.1, confermando il supporto alla ricarica wireless da 25W. Motorola si aggiunge così a Samsung e Google tra i pochi produttori Android ad aver adottato questa tecnologia.

Cos’è Qi2 25W e perché è importante

Qi2.2.1 è l’ultima revisione dello standard di ricarica wireless promosso dal Wireless Power Consortium. Il “25W” del nome indica la potenza massima di ricarica supportata, quasi il doppio rispetto ai 15W del Qi standard. Questo si traduce in tempi di ricarica wireless significativamente ridotti: un vantaggio concreto per chi preferisce evitare il cavo.

Magneti integrati come MagSafe

La certificazione include anche il profilo MPP (Magnetic Power Profile), che prevede magneti integrati nel corpo del telefono per allinearsi perfettamente al caricatore wireless. Il meccanismo è simile al MagSafe di Apple e garantisce che il telefono venga sempre posizionato in modo ottimale sul pad di ricarica. Questa funzione apre anche la porta a accessori magnetici come stand, portafogli e supporti per auto.

Prossima al lancio

La comparsa nel database WPC è spesso uno dei passi finali prima del lancio ufficiale di un prodotto. Non è ancora nota la data di presentazione del Motorola Edge 70 Max, ma la sua vicinanza è confermata dal completamento delle certificazioni internazionali necessarie per la commercializzazione.

Il nuovo Samsung Galaxy Z Fold 8 nel formato wide ha ottenuto la certificazione FCC, e con essa è emersa anche la denominazione per il mercato giapponese — indizio che il dispositivo sia destinato a un lancio globale, potenzialmente anche in Europa.

Il numero di modello che conferma tutto

Dalla documentazione FCC è emerso il codice SM-F971x, associato al nuovo pieghevole orizzontale Samsung. Accanto a questo, è comparso il codice SC-57G, che identifica il modello destinato all’operatore giapponese NTT Docomo. La presenza di una variante per carrier specifici è solitamente indizio di una commercializzazione su larga scala.

Fold 8 o Fold 8 Wide? Il nome non è ancora definitivo

Come anticipato da altri leak, il nome commerciale del dispositivo potrebbe essere semplicemente “Galaxy Z Fold 8”, con il modello tradizionale rebrandizzato come “Galaxy Z Fold 8 Ultra”. Tuttavia, la denominazione ufficiale resterà incerta fino all’evento di presentazione Samsung previsto per luglio.

Cosa aspettarsi

Il Galaxy Z Fold 8 in formato wide propone un’esperienza visiva diversa rispetto ai classici pieghevoli: il display esterno è più largo e orizzontale, avvicinandosi all’estetica di uno smartphone tradizionale quando chiuso. Aperto, offre un’area di visualizzazione ampliata con proporzioni più simili a un tablet compatto. Un formato che potrebbe attrarre chi trova i pieghevoli tradizionali troppo stretti da chiusi.

Il Motorola Edge 70 Max si sta avvicinando al lancio e i suoi punteggi su Geekbench 6 hanno attirato l’attenzione: il chipset Snapdragon 8 Gen 5 mostra prestazioni competitive rispetto all’Xperia 1 VIII che monta il più costoso Snapdragon 8 Elite Gen 5.

Due chip Snapdragon a confronto

Il Motorola Edge 70 Max monta lo Snapdragon 8 Gen 5 (SM8845), che è sostanzialmente una versione underclocked dello Snapdragon 8 Elite Gen 5 (SM8850) presente sull’Xperia 1 VIII. La differenza nei clock massimi è reale: il chip di Sony tocca circa 3.628 MHz, quello di Motorola si ferma a frequenze inferiori. Sulla carta, quindi, l’Xperia dovrebbe avere un vantaggio netto.

I benchmark raccontano una storia diversa

L’analisi statistica dei risultati Geekbench raccoglie dati su molte esecuzioni degli stessi test. L’Edge 70 Max mostra punteggi medi competitivi e, cosa ancor più interessante, una maggiore consistenza nei risultati: il throttling termico sembra meno aggressivo rispetto all’Xperia 1 VIII, che in alcuni casi fatica a mantenere le prestazioni di picco sostenute nel tempo.

Cosa significa per l’utente finale

In uso reale, la costanza delle prestazioni può contare più del picco teorico: un’app che si apre sempre allo stesso modo è preferibile a una che parte velocissima ma poi rallenta. Il Motorola Edge 70 Max sembra posizionarsi come alternativa solida e stabile ai flagship più costosi. Data e prezzo di lancio non sono ancora stati comunicati ufficialmente.