Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
Apple MacBook Air M3: chi deve davvero comprarlo? La recensione
A distanza di circa 8 mesi arriva l’importante aggiornamento dei MacBook Air: nessun cambiamento estetico, ma una revisione hardware interna con l’upgrade al processore M3. Le prestazioni migliorano rispetto alle generazioni precedenti, e questo fa sorgere una domanda spontanea: a chi è rivolto oggi questo laptop? Cerchiamo di capirlo nella nostra recensione 
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
Da ASUS un monitor particolare ma molto completo: principalmente indirizzato al videogiocatore, può essere sfruttato con efficacia anche per attività creative e di produzione multimediale
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Il nuovo robot aspirapolvere domestico di Dreame abbina funzionalità complete a un moccio flottante che raggiunge al meglio gli angoli delle pareti. Un prodotto tutto in uno semplice da utilizzare ma molto efficace, in grado di rispondere al meglio alle necessità di pulizia della casa
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 17-05-2021, 18:51   #1
Redazione di Hardware Upg
www.hwupgrade.it
 
Iscritto dal: Jul 2001
Messaggi: 75175
Link alla notizia: https://edge9.hwupgrade.it/news/devi...nto_97791.html

Dopo l'annuncio della dismissione di CentOS da parte di Red Hat, due principali eredi sono comparsi: Rocky Linux, che è ora alla prima release candidate, e AlmaLinux, che ha recentemente lanciato il supporto a pagamento

Click sul link per visualizzare la notizia.
Redazione di Hardware Upg è offline   Rispondi citando il messaggio o parte di esso
Old 17-05-2021, 19:00   #2
mihos
Senior Member
 
L'Avatar di mihos
 
Iscritto dal: Feb 2010
Messaggi: 1269
"[NO]"?
mihos è offline   Rispondi citando il messaggio o parte di esso
Old 17-05-2021, 19:07   #3
les2
Senior Member
 
L'Avatar di les2
 
Iscritto dal: Mar 2001
Città: MI
Messaggi: 1794
vedremo, so solo che ho 5 server su centos 7 e probabilmente passerò a ubuntu, senza gioia e abitudini ma almeno è certo per qualche anno.
les2 è offline   Rispondi citando il messaggio o parte di esso
Old 17-05-2021, 19:33   #4
Cfranco
Senior Member
 
L'Avatar di Cfranco
 
Iscritto dal: Apr 2002
Città: VR-PD
Messaggi: 10988
Vediamo quanto ci mette Red Hat a comprarseli e chiuderli
__________________
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
Cfranco è online   Rispondi citando il messaggio o parte di esso
Old 17-05-2021, 19:40   #5
les2
Senior Member
 
L'Avatar di les2
 
Iscritto dal: Mar 2001
Città: MI
Messaggi: 1794
mi piace lavorare con redhat, ma non tutti i clienti hanno abbastanza budget o i progetti ne giustificano l'uso e la spesa. Ormai sono troppi quelli che son passati a Ubuntu nell'open source. spesso tocca adeguarsi nel bene e nel male
les2 è offline   Rispondi citando il messaggio o parte di esso
Old 17-05-2021, 20:45   #6
matrix83
Senior Member
 
Iscritto dal: Dec 2006
Messaggi: 923
Quote:
Originariamente inviato da les2 Guarda i messaggi
vedremo, so solo che ho 5 server su centos 7 e probabilmente passerò a ubuntu, senza gioia e abitudini ma almeno è certo per qualche anno.
Che senso ha passare a ubuntu, a sto punto usa Debian. Io, oltre BSD, monto solo Debian ormai sui server e non ho mai avuto problemi. Gli RPM meno li vedo meglio sto.
__________________
matrix83 è offline   Rispondi citando il messaggio o parte di esso
Old 17-05-2021, 22:31   #7
Tasslehoff
Senior Member
 
L'Avatar di Tasslehoff
 
Iscritto dal: Nov 2001
Città: Kendermore
Messaggi: 6491
Quote:
Originariamente inviato da matrix83 Guarda i messaggi
Che senso ha passare a ubuntu, a sto punto usa Debian. Io, oltre BSD, monto solo Debian ormai sui server e non ho mai avuto problemi. Gli RPM meno li vedo meglio sto.
Per molti il fatto di avere comunque un'azienda come Canonical che può fornire supporto (ovviamente sottoscrivendo una subscription) è un fattore decisivo, magari anche solo dal punto di vista psicologico, però indubbiamente c'è.

Tornando a CentOS io francamente ho passato a CentOS 8 Stream alcune delle macchine su cui avevo già installato la 8.
Capisco l'indignazione per come RedHat ha gestito la cosa, e la provo io stesso, però trovo che dal punto di vista tecnico su questa faccenda si siano fatte considerazioni troppo precipitose e senza una reale valutazione costi/benefici.

Da molte parti si è fatta passare l'idea che CentOS Stream sia una distribuzione instabile o rischiosa dal punto di vista dell'affidabilità, il che è oggettivamente falso.
Parliamoci chiaro ragazzi, da sempre c'è gente che installa Fedora o Debian Sid, e onestamente non ho mai visto gente strapparsi i capelli per questo o servizi cascare come pere per l'instabilità dell'OS...
Se colossi come Facebook o Twitter hanno deciso di sostenere pesantemente CentOS Stream per i propri datacenter significa che poi così instabile non dovrebbe essere...

Diamo il giusto peso alle cose, condivido l'indignazione per le scelte di RedHat e trovo che dal punto di vista etico sia stata una mossa molto molto discutibile, però da qui a un fuggi fuggi generale ce ne passa, specialmente per chi ha pesantemente investito in conoscenze su distribuzioni derivate da RedHat.
__________________
https://tasslehoff.burrfoot.it | Cloud? Enough is enough! | SPID… grazie ma no grazie
"Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say."
Tasslehoff è offline   Rispondi citando il messaggio o parte di esso
Old 18-05-2021, 00:42   #8
WarSide
Senior Member
 
Iscritto dal: Oct 2008
Messaggi: 9702
Quote:
Originariamente inviato da Tasslehoff Guarda i messaggi
Parliamoci chiaro ragazzi, da sempre c'è gente che installa Fedora o Debian Sid, e onestamente non ho mai visto gente strapparsi i capelli per questo o servizi cascare come pere per l'instabilità dell'OS...
Mi son fermato dopo questa frase.
Chi installa fedora o Debian Sid in produzione merita solo di essere licenziato senza possibilità di appello

E' innegabile che RH si sia sparata da sola nei @@ col cambio. C'è poco altro da dire.
WarSide è offline   Rispondi citando il messaggio o parte di esso
Old 18-05-2021, 02:14   #9
Tasslehoff
Senior Member
 
L'Avatar di Tasslehoff
 
Iscritto dal: Nov 2001
Città: Kendermore
Messaggi: 6491
Quote:
Originariamente inviato da WarSide Guarda i messaggi
Mi son fermato dopo questa frase.
Chi installa fedora o Debian Sid in produzione merita solo di essere licenziato senza possibilità di appello
Guarda, onestamente io licenzierei prima quelli che permettono ad ambienti di produzione di girare su distribuzioni obsolete anche se considerate rock solid
E credimi, ne ho avute (e ne ho ancora ahimè) a perimetro con servizi ipercritici e che giravano su CentOS/Rhel 4, 5 o 6 (ho addirittura attualmente a perimetro una manciata con Rhel 3, su cui girano servizi di pagamento esposti a web o applicazioni che girano su php 4 ) e sinceramente preferirei la Debian o Fedora più instabili ma recenti e aggiornabili piuttosto che quei ruderi.

Poi chiaro, parlo di sistemi su cui devono girare dei servizi, per cui che Gnome o il tal servizio per l'audio posizionale siano instabili non mi interessa, perchè comunque sulla macchina a cui mi riferisco non installerò nemmeno quella roba.

Chiaramente prima di installare Fedora o Debian Sid ci sono millemila alternative considerate più adatte, però il mio post era solo per dire che se si devono far girare dei servizi anche quelle distribuzioni "bleeding edge" non crashano ogni due per tre, tutt'altro, idem CentOS Stream (che sappiamo bene non essere "bleeding edge").

Tra l'altro a me spesso capita di trovare server su cui è stata installato CentOS o Rhel, o Ubuntu LTS, e va benissimo... poi però per far partire il tal servizio o per soddisfarne le dipendenze puntualmente ci sono package presi dai repository yum o apt più sconosciuti o controversi, o che cmq sono tutt'altro che "conservativi".
E spesso questo è inevitabile perchè cmq i package di quelle distro sono estremamente obsoleti e oggettivamente insicuri, ok ci sono anche repo alternativi ufficiali (o pseudo-ufficiali) con release più recenti dei package, e credo siamo tutti d'accordo nel considerarle alternative valide... però vedi che già ci siamo allontanati parecchio da quell'alone mistico di "stabilità" per cui si è scelto la tal distribuzione?

Lasciami aggiungere un'ultima cosa, ricordiamoci che 99 volte su 100 i problemi nascono sempre da criticità applicative, eccezioni non gestite, codice scritto a "membro di segugio", logica applicativa grossolana o architettura pensata male (tutte cose che spesso non nascono da incapacità di chi le ha realizzate, ma dalle pessime condizioni in cui costui è stato messo a lavorare, scarsità di risorse, tempo insufficiente, specifiche e obbiettivi che cambiano in corso d'opera etc etc... ), dalla mia esperienza il sistema operativo è veramente l'ultima cosa che può generare un problema vero.
__________________
https://tasslehoff.burrfoot.it | Cloud? Enough is enough! | SPID… grazie ma no grazie
"Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say."

Ultima modifica di Tasslehoff : 18-05-2021 alle 02:22.
Tasslehoff è offline   Rispondi citando il messaggio o parte di esso
Old 18-05-2021, 09:03   #10
najmarte
Member
 
Iscritto dal: Apr 2020
Messaggi: 138
Ma Oracle Linux è così brutto?
najmarte è offline   Rispondi citando il messaggio o parte di esso
Old 18-05-2021, 10:54   #11
WarSide
Senior Member
 
Iscritto dal: Oct 2008
Messaggi: 9702
Quote:
Originariamente inviato da Tasslehoff Guarda i messaggi
Guarda, onestamente io licenzierei prima quelli che permettono ad ambienti di produzione di girare su distribuzioni obsolete anche se considerate rock solid
Non ho scritto il contrario. Nel momento in cui il supporto scade e non ci sono aggiornamenti di sicurezza, la macchina va rifatta. Spesso non viene fatto perché i sistemisti sono pagati a cottimo ed il cummenda di turno non vuole sganciare soldi "perché tanto funziona, perché toccarlo?"

Quote:
Originariamente inviato da Tasslehoff Guarda i messaggi
Poi chiaro, parlo di sistemi su cui devono girare dei servizi, per cui che Gnome o il tal servizio per l'audio posizionale siano instabili non mi interessa, perchè comunque sulla macchina a cui mi riferisco non installerò nemmeno quella roba.

Chiaramente prima di installare Fedora o Debian Sid ci sono millemila alternative considerate più adatte, però il mio post era solo per dire che se si devono far girare dei servizi anche quelle distribuzioni "bleeding edge" non crashano ogni due per tre, tutt'altro, idem CentOS Stream (che sappiamo bene non essere "bleeding edge").
Non aggiorni l'OS di un server ogni 6 mesi rifacendo la macchina proprio perché non vuoi dover ritestare gli applicativi su uno stack software (OS+libs) differente. Usando Centos stream, uno yum update in pratica ti installa le nightly builds di RH, sei veramente così entusiasta di fare la cavia in ambienti di produzione?

Poi quando tutto sarà containerizzato e l'host sarà solo un "lancia container", allora questo discorso sarà superato. Purtroppo non è ancora così.


Quote:
Originariamente inviato da Tasslehoff Guarda i messaggi
Tra l'altro a me spesso capita di trovare server su cui è stata installato CentOS o Rhel, o Ubuntu LTS, e va benissimo... poi però per far partire il tal servizio o per soddisfarne le dipendenze puntualmente ci sono package presi dai repository yum o apt più sconosciuti o controversi, o che cmq sono tutt'altro che "conservativi".
E spesso questo è inevitabile perchè cmq i package di quelle distro sono estremamente obsoleti e oggettivamente insicuri, ok ci sono anche repo alternativi ufficiali (o pseudo-ufficiali) con release più recenti dei package, e credo siamo tutti d'accordo nel considerarle alternative valide... però vedi che già ci siamo allontanati parecchio da quell'alone mistico di "stabilità" per cui si è scelto la tal distribuzione?
Repo sconosciuti e controversi === peracottaro. Se hai bisogno di lib molto diverse per i tuoi servizi o ospiti servizi eterogenei sullo stesso server, vai di virtualizzazione/containerizzazione oppure di compilazione statica delle lib.

Quote:
Originariamente inviato da Tasslehoff Guarda i messaggi
Lasciami aggiungere un'ultima cosa, ricordiamoci che 99 volte su 100 i problemi nascono sempre da criticità applicative, eccezioni non gestite, codice scritto a "membro di segugio", logica applicativa grossolana o architettura pensata male (tutte cose che spesso non nascono da incapacità di chi le ha realizzate, ma dalle pessime condizioni in cui costui è stato messo a lavorare, scarsità di risorse, tempo insufficiente, specifiche e obbiettivi che cambiano in corso d'opera etc etc... ), dalla mia esperienza il sistema operativo è veramente l'ultima cosa che può generare un problema vero.
Come dici, non è solo il sistema operativo, ma è anche il set di dipendenze a corredo.

Ti dico cosa ho visto spesso in giro: server con versione di ubuntu non LTS, server con fedora non aggiornati e non aggiornabili pena applicativi che si spaccano. In quel caso, non avendo OS stabile e supporto per anni, sei fottuto e ti tocca rifare la macchina e metter mano agli applicativi.

Centos Streams va avanti con rolling release e gli aggiornamenti sono le nightly builds di RH.

1. Puoi trovarti in situazioni dove gli aggiornamenti ti spaccano gli applicativi installati e ti tocca capire cosa ha spaccato cosa e perché e fare rollback degli update.
2. Tu sei veramente tranquillo sapendo che sul server ci finiscono delle nightly builds? Ok che sono NB di RH, ma cavolo, son sempre NB.

Insomma, come non userei mai una Ubuntu non LTS o una Fedora, non installerei mai CentOS Stream su un server. Discorso diverso sul desktop personale dove, anche se si spaccasse qualcosa dopo un aggiornamento, potrei velocemente fare rollback senza far andare down servizi esposti.

Ultima modifica di WarSide : 18-05-2021 alle 11:06.
WarSide è offline   Rispondi citando il messaggio o parte di esso
Old 19-05-2021, 01:04   #12
Tasslehoff
Senior Member
 
L'Avatar di Tasslehoff
 
Iscritto dal: Nov 2001
Città: Kendermore
Messaggi: 6491
Quote:
Originariamente inviato da WarSide Guarda i messaggi
Non ho scritto il contrario. Nel momento in cui il supporto scade e non ci sono aggiornamenti di sicurezza, la macchina va rifatta. Spesso non viene fatto perché i sistemisti sono pagati a cottimo ed il cummenda di turno non vuole sganciare soldi "perché tanto funziona, perché toccarlo?"
Certamente c'è anche questo scenario, come ce ne sono tanti altri, es non c'è budget, chi paga il rifacimento della macchina?
Oppure il setup è il frutto di anni di lavoro, patch su patch custom rilasciate dal supporto di [metti multinazionale big IT a caso] a seguito di ticker sanguinosi e niente di tutto questo è documentato.
Oppure non ci sono più gli installer o non vi si ha accesso perchè nessuno ha rinnovato la tal subscription, etc etc.

Insomma gli scenari sono tanti, quella che descrivi se vogliamo è la migliore delle ipotesi, no moneta no cammello, e di certo se sei pagato per fare manutenzione ordinaria o presidio non regali un setup da zero, quello giustamente te lo fai pagare e bene.

Quote:
Non aggiorni l'OS di un server ogni 6 mesi rifacendo la macchina proprio perché non vuoi dover ritestare gli applicativi su uno stack software (OS+libs) differente. Usando Centos stream, uno yum update in pratica ti installa le nightly builds di RH, sei veramente così entusiasta di fare la cavia in ambienti di produzione?

Poi quando tutto sarà containerizzato e l'host sarà solo un "lancia container", allora questo discorso sarà superato. Purtroppo non è ancora così.
Capiamoci, non ho detto che ne sono entusiasta, però non ci vedo nemmeno questa tragedia epocale.
Anche a me è capitato di avere qualche problema per un update (l'ultima volta credo sia successo un paio di anni fa per un update di php, rollback immediato, dopo poche ore c'era già una fix, fantascienza anche per il prodotto commerciale più avanzato e strapagato) però oggettivamente dalla mia esperienza sono casi veramente rari.

Sullo scenario che descrivi riguardo ai container io onestamente non sono così ottimista, non lo vedo così rosa e fiori, anzitutto perchè aggiornare un container non è a costo zero (in termini di effort) o quantomeno è largamente superiore rispetto all'uso di un package manager schedulato.
In secondo luogo dalla mia esperienza anche la riproducibilità di un servizio che gira dentro un container non è sempre garantita, a me ne sono capitati parecchi di scenari in cui due ambienti, con gli stessi container, stessa versione di docker (o altro servizio simile), stessi parametri (o file yaml nel caso di docker-compose), si comportano in modo diverso e tocca tutte le volte ritoccare qualcosa.
Sul rollback nella gran parte dei casi cambia poco o nulla rispetto ad uno scenario tradizionale, per il semplice fatto che tolte le applicazioni totalmente stateless (che nel mondo reale sono più una teoria che realtà, perchè 9 volte su 10 qualche repository ce l'hai sempre, che sia un db o un volume persistente) in molti casi aggiornare un sw (aggiornando il container sulla base di una immagine con una nuove versione del prodotto) significa toccare qualcosa anche sul repository dove stanno i dati, sia che si tratti di qualche ddl per aggiornare la struttura del db o qualche modifica alla struttura dei file.

Quote:
Repo sconosciuti e controversi === peracottaro. Se hai bisogno di lib molto diverse per i tuoi servizi o ospiti servizi eterogenei sullo stesso server, vai di virtualizzazione/containerizzazione oppure di compilazione statica delle lib.
Ok però oggettivamente trovami qualcuno che avendo a disposizione un repository yum o apt si mette a ricompilare da sorgenti.
La ricompilazione la facevo ai tempi di RedHat 7 (la prima, non RHEL), a meno di avere esigenze talmente specifiche da non essere soddisfatte dai binari disponibili sui repo trovo veramente difficile che qualcuno si metta a ricompilare.
E questo per mille motivi, anzitutto per una questione di costi, ripetere il tutto ad ogni aggiornamento poi diventa ingestibile, e francamente rispetto a un sw che si aggiorna manualmente ogni morte di papa preferisco un repo conosciuto, anche se non certificato o che abbia un controllo di qualità di livello RedHat.

Per fare un esempio che credo molti abbiano sperimentato, in ambito RHEL e derivate praticamente EPEL è un repository necessario, è impensabile lavorare senza e francamente da quando è disponibile non ho trovato una singola macchina RHEL o CentOS che non l'avesse usato, non solo, spesso si trovano specifiche indicazioni di installarlo anche in prodotti enterprise per soddisfare dipendenze.
Vogliamo parlare della qualità dei binari distribuiti tramite Epel? Alcuni sono talmente obsoleti da essere imbarazzanti, sulla stabilità di altri ci sarebbe molto da discutere.

O prendiamo php, volente o nolente praticamente chiunque usa Remi repo, io trovo che il lavoro che c'è dietro sia ammirevole, e di una qualità in termini di supporto che veramente bagna il naso a multinazionali multimiliardarie, però non si può certo dire che sia all'altezza di standard di livello RHEL o Ubuntu LTS in termini di solidità, in fin dei conti è un tizio (che tra l'altro mi pare lavori in RedHat) che nel tempo libero fa tutto questo.

Quote:
Ti dico cosa ho visto spesso in giro: server con versione di ubuntu non LTS, server con fedora non aggiornati e non aggiornabili pena applicativi che si spaccano. In quel caso, non avendo OS stabile e supporto per anni, sei fottuto e ti tocca rifare la macchina e metter mano agli applicativi.
Non lo metto in dubbio, però capiamoci, sono casi un po' diversi.
Un conto se parliamo di un sistema operativo installato ora, su una distribuzione attuale, con aggiornamenti attivi e costanti, servizi che ci girano sopra le cui dipendenze sono costantemente aggiornate, etc etc...
Altra cosa se parliamo di macchine mai aggiornate per anni, dove chiaramente lanciare un apt upgrade o yum update sarebbe cosa davvero azzardata.

Ben inteso, ne ho viste tante anch'io in quello stato, però non è un problema dell'os instabile, ma di un percorso di upgrade che non è stato seguito.
Ma lo stesso l'ho visto su Windows, mai aggiornati per anni e dove il cluster active/passive scoppia.

Quote:
Centos Streams va avanti con rolling release e gli aggiornamenti sono le nightly builds di RH.

1. Puoi trovarti in situazioni dove gli aggiornamenti ti spaccano gli applicativi installati e ti tocca capire cosa ha spaccato cosa e perché e fare rollback degli update.
2. Tu sei veramente tranquillo sapendo che sul server ci finiscono delle nightly builds? Ok che sono NB di RH, ma cavolo, son sempre NB.

Insomma, come non userei mai una Ubuntu non LTS o una Fedora, non installerei mai CentOS Stream su un server.
Come ti dicevo io da anni ho deciso di applicare la politica "updates no matter what" e francamente di problemi ne avrò avuti un paio in anni e anni e presso tanti clienti e tanti scenari diversi; e non parlo solo di updates ufficiali di Rhel o della vecchia CentOS, ma anche di package installati con Epel, remi, rpmforge e altri.

Chiaramente non saprò mai quali problemi però ho evitato aggiornando sempre e comunque tutte le notti, soprattutto dal pdv della sicurezza.
Di certo c'è però che se si verifica un disguido per un package appena aggiornato è ovviamente spiacevole, ma se si verifica un problema per obsolescenza dei package o perchè non si aggiorna (e di solito lo vieni a scoprire a cose fatte perchè c'è una buona probabilità che si tratti di un problema di sicurezza) la situazione è decisamente più grave; i miei clienti tendono a essere moooolto più accondiscendenti nel primo caso, e giustamente molto meno nel secondo.

Riassumendo, rispetto al tua esperienza e concordo con te che lo scenario ideale sarebbe usare distribuzioni a prova di bomba (RHEL, Ubuntu LTS o Debian stable) però dal pdv tecnico non ci vedo tutto questo "casus belli", eticamente invece è un altro discorso e sono d'accordo al 100% con la polemica nata dopo le recenti decisioni di RedHat
__________________
https://tasslehoff.burrfoot.it | Cloud? Enough is enough! | SPID… grazie ma no grazie
"Arguing that you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say."

Ultima modifica di Tasslehoff : 19-05-2021 alle 01:25.
Tasslehoff è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Apple MacBook Air M3: chi deve davvero comprarlo? La recensione Apple MacBook Air M3: chi deve davvero comprarlo...
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ul...
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza Dreame L10s Pro Ultra Heat: la pulizia di casa t...
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere HONOR Magic6 Pro: come funziona Magic Portal, il...
L'innovazione richiede fiducia: Workday si propone come guida nell'era dell'IA L'innovazione richiede fiducia: Workday si propo...
RocketStar FireStar Drive: un propulsore...
Roscosmos: il lancio del razzo spaziale ...
Italia strategica per Oracle. Arriva la ...
Sam-Bankman Fried: 25 anni di reclusione...
Mobility Analytics di WINDTRE Business p...
Il lander lunare JAXA SLIM si è r...
Warframe conquista l'iPhone: senza soluz...
Marvel Rivals!, l'inaspettato shooter Pv...
Twitch aggiorna le linee guida sui conte...
Galaxy M55 ufficiale: la nuova fascia me...
Google corregge sette vulnerabilit&agrav...
IA: le imprese italiane sono in prima li...
Garmin Dash Cam 57: un'alleata perfetta ...
Elgato Facecam MK2: come rendere ancora ...
2 iRobot Roomba al prezzo più sco...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 06:06.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Served by www1v
1