Torna indietro   Hardware Upgrade Forum > Hardware Upgrade > News

Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione
Abbiamo provato il nuovo Galaxy S25 Edge, uno smartphone unico per il suo spessore di soli 5,8 mm e un peso super piuma. Parliamo di un device che ha pro e contro, ma sicuramente si differenzia dalla massa per la sua portabilità, ma non senza qualche compromesso. Ecco la nostra prova completa.
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto
Pensato per il professionista sempre in movimento, HP Elitebook Ultra G1i 14 abbina una piattaforma Intel Core Ultra 7 ad una costruzione robusta, riuscendo a mantenere un peso contenuto e una facile trasportabilità. Ottime prestazioni per gli ambiti di produttività personale con un'autonomia lontano dalla presa di corrente che permette di lavorare per tutta la giornata
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso
Basato su piattaforma Qualcomm Snapdragon X Plus a 8 core, il nuovo Microsoft Surface Pro 12 è un notebook 2 in 1 molto compatto che punta sulla facilità di trasporto, sulla flessibilità d'uso nelle differenti configurazioni, sul funzionamento senza ventola e sull'ampia autonomia lontano dalla presa di corrente
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 14-12-2018, 16:21   #1
Redazione di Hardware Upg
www.hwupgrade.it
 
Iscritto dal: Jul 2001
Messaggi: 75173
Link alla notizia: https://www.hwupgrade.it/news/sistem...x32_79662.html

Gli sviluppatori del kernel Linux stanno pensando di abbandonare l'ABI x32, che permette di usare puntatori a 32 bit su sistemi a 64 bit con conseguenti vantaggi prestazionali, per via dell'utilizzo pressoché nullo

Click sul link per visualizzare la notizia.
Redazione di Hardware Upg è offline   Rispondi citando il messaggio o parte di esso
Old 14-12-2018, 16:55   #2
s-y
Senior Member
 
L'Avatar di s-y
 
Iscritto dal: Nov 2007
Messaggi: 8368
se non ricordo male i cosiddetti vantaggi prestazionali dovrebbero essere sul 1% ma a fronte della gestione (e patch da applicare) di un set aggiuntivo di librerie. alla fine credo che lo scarsissimo utilizzo dipenda da questo. detta in altre parole, massa casin per poca ciccia
s-y è offline   Rispondi citando il messaggio o parte di esso
Old 14-12-2018, 20:27   #3
bancodeipugni
Senior Member
 
L'Avatar di bancodeipugni
 
Iscritto dal: Nov 2013
Città: Nel cuore dell'8 Mile di Detroit
Messaggi: 3719
ah vedi che una notizia su linux ogni tanto salta fuori ?

è bastato chiamarlo, ed è arrivata

si' alla fine...
__________________
"Se devi mangiare merda non assaporarla: mordi, mastica, ingoia, ripeti.
Fai presto, e te la cavi con poco"
bancodeipugni è offline   Rispondi citando il messaggio o parte di esso
Old 15-12-2018, 05:49   #4
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Quote:
Originariamente inviato da s-y Guarda i messaggi
se non ricordo male i cosiddetti vantaggi prestazionali dovrebbero essere sul 1%
No, sono dal 5 al 10%: per l'1% non avrebbe avuto alcun senso introdurre una nuova ABI.
Quote:
ma a fronte della gestione (e patch da applicare) di un set aggiuntivo di librerie.
In linea teorica un'ABI del genere non dovrebbe comportare grossi problemi, ma dipende quasi esclusivamente da com'è stato scritto il codice. Se lo scrivi facendo certe assunzioni (es: sizeof(long) == sizeof(void *)), allora è chiaro che possono esserci problemi.
Quote:
alla fine credo che lo scarsissimo utilizzo dipenda da questo. detta in altre parole, massa casin per poca ciccia
x32 ha il suo perché come ABI, perché consente di eseguire codice a 32 bit girando su un s.o. a 64 bit, traendo il vantaggio di entrambi i mondi (puntatori "corti" assieme al doppio dei registri GP & SIMD + PIC), e senza portarsi dietro tutte le problematiche di x86.

Meglio ancora sarebbe stato un s.o. a 64 bit con supporto trasparente per applicazioni x32, in modo da offrire binari ad hoc a seconda del tipo di applicazione, ottimizzando sia lo spazio su disco sia le prestazioni, visto che non serve poter avere tutte le applicazioni a 64 bit (e qui, specificamente, intendo applicazioni che abbiano ESCLUSIVAMENTE bisogno di indirizzare più di 4GB di memoria).
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 15-12-2018, 09:56   #5
s-y
Senior Member
 
L'Avatar di s-y
 
Iscritto dal: Nov 2007
Messaggi: 8368
in effetti ricordavo male, e ho approfittato per riaggiornarmi un pò sulla questione (dopo un certo hype 5/6 anni fa se n'è parlato sempre meno)
afaik il problema principale, al momento, è che serve ricompilare i pacchetti per abilitare, con anche qualche problema di convivenza con quelli 'normali', a meno di separarli, in un chroot ad esempio.
poi anche cercando eventuali distro compilate con x32, si trovano directory apparentemente semiabbandonate

intendo a livello utenti finali, mentre a livello di mantainers non sono in grado di 'sintetizzare', provato a seguire il thread su lkml.org ma è per me fuori portata...

potrebbe essere uno di quei casi dove la natura frammentata dell'ecosistema, è solo uno svantaggio
s-y è offline   Rispondi citando il messaggio o parte di esso
Old 15-12-2018, 17:56   #6
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
x32 non e' stata sfruttata perche' ha senso solo in un ambito molto ristretto

davvero nel 2018 abbiamo bisogno di puntatori a 32 bit per risparmiare memoria? oppure abbiamo bisogno di quel 5-10% di prestazioni in piu', che possono essere annullate rapidamente in millemila modi diversi ( uso di JS per scrivere applicazioni desktop )?

certo che se fai calcoli dalla mattina alla sera su giganteschi dataset da miliardi di entry, allora un suo perche' ce l'ha

ma per un uso generale, temo sia una soluzione ad un problema che non c'e'

tirando tirando, sui server puo' essere sensato, ma anche li' ci sono altre variabili in gioco

i cloudisti preferiscono risolvere tramite un complessissimo sistema di orchestrazione che consuma millemila cicli di cpu per fare cose che si potrebbero fare con uno script da due righe

viviamo in un mondo sprecone, qualche MB guadagnato in ram o un 5% di cicli di cpu in piu' non attirano tanta gente

facciamoci il callo e prepariamoci per l'invasione delle applicazioni che girano su Electron
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 15-12-2018, 19:22   #7
Phoenix Fire
Senior Member
 
L'Avatar di Phoenix Fire
 
Iscritto dal: Sep 2006
Città: Aprilia
Messaggi: 12597
notizia interessante che mi ha permesso di conoscere qualcosa di "nuovo"

spero che decidano per il meglio, ovvero ragionino su casi dove serve e vantaggi che porta in questi casi
__________________
Quelli che dicevano che era impossibile non hanno mai fatto un tentativo
Inventario Steam contattatemi se interessati
Phoenix Fire è offline   Rispondi citando il messaggio o parte di esso
Old 16-12-2018, 08:01   #8
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
Quote:
Originariamente inviato da s-y Guarda i messaggi
in effetti ricordavo male, e ho approfittato per riaggiornarmi un pò sulla questione (dopo un certo hype 5/6 anni fa se n'è parlato sempre meno)
afaik il problema principale, al momento, è che serve ricompilare i pacchetti per abilitare, con anche qualche problema di convivenza con quelli 'normali', a meno di separarli, in un chroot ad esempio.
poi anche cercando eventuali distro compilate con x32, si trovano directory apparentemente semiabbandonate

intendo a livello utenti finali, mentre a livello di mantainers non sono in grado di 'sintetizzare', provato a seguire il thread su lkml.org ma è per me fuori portata...

potrebbe essere uno di quei casi dove la natura frammentata dell'ecosistema, è solo uno svantaggio
Personalmente, e come già detto, l'unico problema che vedo è nel modo in cui sono stati scritti i progetti, perché altrimenti supportare x32 dovrebbe essere una bazzecola (è esattamente identica a x64, tranne per i puntatori a 32 bit).
Quote:
Originariamente inviato da pabloski Guarda i messaggi
x32 non e' stata sfruttata perche' ha senso solo in un ambito molto ristretto
Ma anche no: come già detto, si può sfruttare in TUTTI i casi in cui NON sia richiesto accedere a più di 4GB di memoria virtuale.
Quote:
davvero nel 2018 abbiamo bisogno di puntatori a 32 bit per risparmiare memoria? oppure abbiamo bisogno di quel 5-10% di prestazioni in piu',
Direi di sì, considerato che l'IPC dei processori ormai cresce ben poco.
Quote:
che possono essere annullate rapidamente in millemila modi diversi ( uso di JS per scrivere applicazioni desktop )?
Questo non c'entra assolutamente nulla, perché appunto avviene già.

Non è che perché ci siano già tanti sprechi uno non debba pensare a risparmiare qualcosa quando può: è un ragionamento privo di senso.
Quote:
certo che se fai calcoli dalla mattina alla sera su giganteschi dataset da miliardi di entry, allora un suo perche' ce l'ha

ma per un uso generale, temo sia una soluzione ad un problema che non c'e'

tirando tirando, sui server puo' essere sensato, ma anche li' ci sono altre variabili in gioco
Può ed è sensato in quasi tutto, invece.
Quote:
i cloudisti preferiscono risolvere tramite un complessissimo sistema di orchestrazione che consuma millemila cicli di cpu per fare cose che si potrebbero fare con uno script da due righe

viviamo in un mondo sprecone, qualche MB guadagnato in ram o un 5% di cicli di cpu in piu' non attirano tanta gente

facciamoci il callo e prepariamoci per l'invasione delle applicazioni che girano su Electron
Come già detto sopra, sono prese di posizione prive di senso: lo spreco attuale NON può legittimare l'abolizione di strumenti che consentono, invece, di recuperare un po' spazio e prestazioni.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 16-12-2018, 10:12   #9
s-y
Senior Member
 
L'Avatar di s-y
 
Iscritto dal: Nov 2007
Messaggi: 8368
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Personalmente, e come già detto, l'unico problema che vedo è nel modo in cui sono stati scritti i progetti, perché altrimenti supportare x32 dovrebbe essere una bazzecola (è esattamente identica a x64, tranne per i puntatori a 32 bit).
si come scrivevo pure io, penso sia uno dei casi dove la frammentazione (o 'frankeisteinizzazione') dei pacchetti rende più complicata l'implementazione

ad ora afaik (ma non ne ho esperienza diretta) oltre ai pacchetti specifici per poterlo fare, serve ricompilare a mano i pacchetti (che possono essere molti) per i quali si vuole abilitare

se ci fosse qualche distro che mette su un repo dedicato potrebbe essere più semplice (sempre lato end user) ma se non è stato fatto un motivo ci sarà (non retorica)

ripeto che non ho esperienza diretta sulla questione, potrei non essere preciso
s-y è offline   Rispondi citando il messaggio o parte di esso
Old 16-12-2018, 10:32   #10
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Ma anche no: come già detto, si può sfruttare in TUTTI i casi in cui NON sia richiesto accedere a più di 4GB di memoria virtuale.
Non temere, gli sviluppatori di Electron elimineranno il problema

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Direi di sì, considerato che l'IPC dei processori ormai cresce ben poco.
Prima dovremmo pensare ad ottimizzare i software applicativi. Beh sicuramente con quel 5-10% si potrebbe colmare la voragine prestazionale introdotta dalle varie misure anti-Specter e compagnia.

Quote:
Originariamente inviato da cdimauro Guarda i messaggi
Non è che perché ci siano già tanti sprechi uno non debba pensare a risparmiare qualcosa quando può: è un ragionamento privo di senso.
No, ma costruire un'ecosistema software piu' sano porterebbe vantaggi ben maggiori.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 16-12-2018, 20:05   #11
cdimauro
Senior Member
 
L'Avatar di cdimauro
 
Iscritto dal: Jan 2002
Città: Germania
Messaggi: 26110
@s-y: non ho usato x32, per cui non saprei la situazione dei pacchetti e delle distro che la supportano.
Quote:
Originariamente inviato da pabloski Guarda i messaggi
Non temere, gli sviluppatori di Electron elimineranno il problema
:-/
Quote:
Prima dovremmo pensare ad ottimizzare i software applicativi.
Questo è un mantra che esiste dalla notte dei tempi informatici.
Quote:
Beh sicuramente con quel 5-10% si potrebbe colmare la voragine prestazionale introdotta dalle varie misure anti-Specter e compagnia.
x32 nasce parecchi anni prima.
Quote:
No, ma costruire un'ecosistema software piu' sano porterebbe vantaggi ben maggiori.
Il che, di nuovo, non ha nulla a che vedere con x32 e la sua abolizione.

Continui a trincerarti su un non-sequitur.
__________________
Per iniziare a programmare c'è solo Python con questo o quest'altro (più avanzato) libro
@LinkedIn Non parlo in alcun modo a nome dell'azienda per la quale lavoro
Ho poco tempo per frequentare il forum; eventualmente, contattatemi in PVT o nel mio sito. Fanboys
cdimauro è offline   Rispondi citando il messaggio o parte di esso
Old 17-12-2018, 10:04   #12
LukeIlBello
Bannato
 
Iscritto dal: Jan 2010
Città: Roma
Messaggi: 4638
io non capisco perchè NVIDIA si ostina a rilasciare le librerie per la compatibilità con linux (linulator), in ambiente BSD, solo a 32 bit
alla luce di tutte ste posizioni che vedono, giustamente, il progressivo abbandono dei puntatori a 32 bit.. mi aspetterei che escano le ABI emulate su FreeBSD only 64bit, o al max 32 e 64 bit.. ma SOLO a 32 bit che senso ha?
LukeIlBello è offline   Rispondi citando il messaggio o parte di esso
Old 17-12-2018, 11:08   #13
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Secondo me x32 era / è una buona idea, ma - ovviamente - su Linux non sono stati capaci a farlo funzionare per il casino che hanno sempre con i pacchetti software che sono legati mani & piedi al kernel

Un ulteriore ambito in cui è importante avere puntatori a 32 bit è in linguaggi managed come Java o C# dove praticamente tutto è un puntatore!

Infatti proprio per evitare un uso enorme di memoria (a volte più essere anche il doppio usando x64 senza alcun vantaggio vero e proprio!), Visual Studio di default compila le applicazioni .Net con "Prefer 32 bit"!

Un S.O. come Cosmos potrebbe usare tranquillamente x32 e la cosa bella è che il tutto sarebbe trasparente per le applicazioni!
Per me quello dovrebbe essere il kernel di "default".
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!
fano è offline   Rispondi citando il messaggio o parte di esso
Old 17-12-2018, 11:18   #14
LukeIlBello
Bannato
 
Iscritto dal: Jan 2010
Città: Roma
Messaggi: 4638
Quote:
Originariamente inviato da fano Guarda i messaggi
Secondo me x32 era / è una buona idea, ma - ovviamente - su Linux non sono stati capaci a farlo funzionare per il casino che hanno sempre con i pacchetti software che sono legati mani & piedi al kernel

Un ulteriore ambito in cui è importante avere puntatori a 32 bit è in linguaggi managed come Java o C# dove praticamente tutto è un puntatore!

Infatti proprio per evitare un uso enorme di memoria (a volte più essere anche il doppio usando x64 senza alcun vantaggio vero e proprio!), Visual Studio di default compila le applicazioni .Net con "Prefer 32 bit"!

Un S.O. come Cosmos potrebbe usare tranquillamente x32 e la cosa bella è che il tutto sarebbe trasparente per le applicazioni!
Per me quello dovrebbe essere il kernel di "default".
perchè non lo fai "cross-platform" come alphawinux?
LukeIlBello è offline   Rispondi citando il messaggio o parte di esso
Old 17-12-2018, 11:36   #15
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Un sistema operativo basato su .Net è cross platform by design sicuramente lato applicazione e se il kernel è fatto come si deve anche il kernel sarebbe cross-platform per un buon 90%.

Ma non sono sicuro se quando uno cita alphawinux meriti una risposta seria
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!
fano è offline   Rispondi citando il messaggio o parte di esso
Old 17-12-2018, 13:12   #16
s-y
Senior Member
 
L'Avatar di s-y
 
Iscritto dal: Nov 2007
Messaggi: 8368
come scritto svariate altre volte, non ha senso giudicare un os nato per gioco (quasi letteralmente) come se fosse stato pianificato a tavolino

che poi la natura 'distriubuita' (o 'incasinata') renda più complicate modifiche a basso livello, è senza dubbio vero, come già scritto

alla fine quello che conta è, anche se non perfetto (posto che significhi qualcosa il concetto di perfezione) può essere cmq un valido os per molti casi? (non universalmente quindi) secondo me si, e se si pensa alle suddette premesse, non è tanto poco

penso anche che qualsiasi os, pure win, se venisse riprogettato da zero oggi, sarebbe più efficiente... bisogna vedere in prospettiva e/o a regime...
s-y è offline   Rispondi citando il messaggio o parte di esso
Old 17-12-2018, 14:07   #17
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Su questo sono perfettamente d'accordo... anche Windows ha il suo "bagaglio" di inificienze dovute alla retrocompatibilità con Win32/Win9x in buona parte!
(Win32 credo proprio fosse un accrocchio malvagio, manco sono sicuro fosse corretto definirlo un S.O. era più un "parassita" di DOS ).
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!
fano è offline   Rispondi citando il messaggio o parte di esso
Old 17-12-2018, 15:17   #18
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da fano Guarda i messaggi
Secondo me x32 era / è una buona idea, ma - ovviamente - su Linux non sono stati capaci a farlo funzionare per il casino che hanno sempre con i pacchetti software che sono legati mani & piedi al kernel
Non mi pare che sotto Windows si possano creare eseguibili nativi multi-ABI. Se parli di .NET, pure gli eseguibili Mono o JVM sotto Linux presentano gli stessi vantaggi.

Semplicemente non c'e' domanda per un'ABI come x32, altrimenti avrebbe preso piede proprio in Linux, il cui ecosistema e' sempre stato poco orientato al conservatorismo.
pabloski è offline   Rispondi citando il messaggio o parte di esso
Old 17-12-2018, 15:41   #19
fano
Senior Member
 
Iscritto dal: Nov 2005
Messaggi: 2095
Sì su Windows a 64 posso far girare senza problemi applicazioni a 32 bit grazie a WoW (Windows on Windows), Microsoft non usa l'ABI x32, ma x86... anche se SSE1/SSE2 sono utilizzabile quindi non è poi tanto differente. Infatti proprio per risparmiare memoria molte applicazioni anche di Microsoft sono ancora a 32 bit su Windows (per esempio Visual Studio).

Per quanto riguarda "prefer 32" almeno quando testai con Mono su una CentOS non aveva funzionato nel senso che l'applicazione girava comunque a 64 bit, ignorare il flag è comunque "legale" visto che è appunto una "preferenza" quindi di per se Mono era compliant... non so se facendo accrocchi installando libreria a 32 Bit su Linux avrebbe funzionato... dubito, però
__________________
Cosmos C# Open Source Managed Operating System
Cosmos Thread Ufficiale
Cosmos Official Site Vuoi collaborare allo sviluppo? Unisciti alla chat!
fano è offline   Rispondi citando il messaggio o parte di esso
Old 17-12-2018, 16:08   #20
pabloski
Senior Member
 
Iscritto dal: Jan 2008
Messaggi: 8406
Quote:
Originariamente inviato da fano Guarda i messaggi
Sì su Windows a 64 posso far girare senza problemi applicazioni a 32 bit grazie a WoW (Windows on Windows),
Che e' la stessa cosa che si fa con Linux installando le varie lib32-blahblah.

E rimane su entrambi i sistemi la necessita' di ricompilare i programmi ( nel caso di x32 ). Non e' che un programma x86_64 diventa magicamente x32. Il prefer 32 non ti aiuta in questo caso, perche' x32 vuole poter usare elementi di x86 ed elementi di x86_64 nello stesso eseguibile.

Per cui francamente non vedo dove stia la differenza tra Windows e Linux su questo tema.

Inoltre non va mai dimenticata la vera ragione di queste soluzioni, ovvero avere milioni di programmi a 32 bit da far girare su un sistema a 64 bit. Ma nel mondo Linux i porting del genere avvengono molto rapidamente, per cui non c'e' nemmeno domanda per una simile soluzione.

Ultima modifica di pabloski : 17-12-2018 alle 16:11.
pabloski è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Samsung Galaxy S25 Edge: il top di gamma ultrasottile e leggerissimo. La recensione Samsung Galaxy S25 Edge: il top di gamma ultraso...
HP Elitebook Ultra G1i 14 è il notebook compatto, potente e robusto HP Elitebook Ultra G1i 14 è il notebook c...
Microsoft Surface Pro 12 è il 2 in 1 più compatto e silenzioso Microsoft Surface Pro 12 è il 2 in 1 pi&u...
Recensione REDMAGIC Astra Gaming Tablet: che spettacolo di tablet! Recensione REDMAGIC Astra Gaming Tablet: che spe...
Dopo un mese, e 50 foto, cosa abbiamo capito della nuova Nintendo Switch 2 Dopo un mese, e 50 foto, cosa abbiamo capito del...
Kindle Colorsoft: arriva la versione da ...
Electra ottiene altri 433 milioni di eur...
Cercate un hard disk esterno? Oggi Seaga...
Wi-Fi 8 sarà più affidabil...
Eccolo ancora, nuovo e non certo ricondi...
Thingiverse, stretta sulle armi 3D: perc...
DDR6 in dirittura d'arrivo: si punta su ...
Google Pixel 10 Pro Fold! Ecco tutti i d...
Sei pronto per il LEGO Game Boy? Ecco qu...
Google ha speso 14 miliardi in nuovi ser...
Primo semestre 2025, i veicoli elettrici...
Come va il principale produttore di semi...
Quando la sonda resta in magazzino: cosa...
Oggi grandi affari con i FRITZ!Repeater ...
Display nano-texture e più resist...
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: 14:23.


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