Lo installi mettendolo su usb o cd, poi lo avvii (sempre impostando da BIOS). Per iniziare, ti consiglio Ubuntu 10.04 LTS, poi passa ad un altra distro, Debian, Fedora e ArchLinux vanno benissimo.
Discussione PC Desktop "NUOVO"
- Autore discussione ManInBlack
- Data d'inizio
- Stato
Si installano come winzozz e non, nel senso che: alcune distro, tra cui: Ubuntu etc... si installano molto facilmente (point & click), altre come: Archlinux si installano via riga di comando e sono installazioni cazzute.
Prova: Mint, Fedora o OpenSUSE.
Un'altra cosa ma devo installare anche il software di Linux (se esiste) e poi Ubuntu (esempio)?
E GNU e' un'altro modo di chiamare Linux?
E GNU e' un'altro modo di chiamare Linux?
GNU è la licenza sotto cui sono distribuiti il kernel e le varie distro (open source)
S
Sten_Gun
QUel che ti consiglio, se vuoi optare per linux, è di dare un'occhiata all'apposita sezione di questo forum per scegliere la tua distribuzione perfetta.
Se sei una persona curiosa e ti piace scoprire allora puoi anche provare a buttarti su linux, altrimenti fai la solita solfa del "cracking" di windows (che ti sconsiglio vivamente visto che è illegale e porta a tediosi problemi, meglio una cosa gratuita e legale, ancora meglio se open source.)
I programmi che usi girano benissimo anche su linux: Minecraft è java e quindi lo stesso file jar parte da linux, Gimp è un validissimo sostituto di photoshop (e rispondo ai detrattori in questo topic che uso programmi di grafica per il mio sbocco professionale, e gimp ha sempre soddisfatto tutte le mie esigenze, tanto che mi intercambiavo fra i due senza problemi. È un programma usabilissimo per la maggior parte delle esigenze), ma se sei costretto a usare photoshop per svogliatezza o perché hai la licenza o altro allora parte decentemente anche usando wine (ma probabilmente se sei una persona svogliata difficilmente installerai linux).
È chiaramente una scelta da valutare bene, ma se fai un piccolo inventario di ciò che vuoi e che non vuoi allora capirai subito cosa scegliere.
In base alla distrubizione eviterai anche di riformattare ciclicamente per colpa del sistema che si impalla o che si aggiorna. ed è molto comodo.
---------- Post added at 16:05 ---------- Previous post was at 15:58 ----------
buttare giù 4 parole a caso non è il miglior modo per dimostrare la conoscenza di qualcosa.
Spiegare i perché 2 kernel sono uno meglio dell'altro forse sarebbe una mossa migliore. Linux è un ottimo sistema operativo, in quanto ha delle politiche di sicurezza particolari ed è un progetto che ha un grandissimo potenziale di crescita, direi praticamente infinito (al contrario di un qualunque software closed).
In relazione ai due kernel, la diatriba fra kernel monolitici e microkernel credo sia già un argomento dibattutto da 20 anni ed è chiaro che i kernel monolitici sono "inferiori" ai microkernel. Nonostante questo linux si rivela un sistema ottimo nonostante usi un kernel monolitico. Il kernel di windows è un kernel ibrido, come tale ha delle caratteristiche persino diverse da un microkernel.
Ambiti come dimensione del kernel, modularità, velocità di caricamento in memoria, politiche di sicurezza. Sono tutti aspetti che non potrai mai sintetizzare con "ho letto il kernel di linux e so di cosa parli". Hai letto 70 mega di codice? era bello? com'è la trama? ma fammi il piacere! Soluzioni geniali come lo scheduler dei dischi BFQ te le sogni su windows, il cui scheduler è talmente schifoso che non oso neanche proporlo come alternativa di studio.
Parlare di kernel in questo post è come provare a insegnare arabo via lettera: non ha senso. E credo sia meglio scendere dai trampolini, perché non ti rendono una persona migliore delle altre.
Se sei una persona curiosa e ti piace scoprire allora puoi anche provare a buttarti su linux, altrimenti fai la solita solfa del "cracking" di windows (che ti sconsiglio vivamente visto che è illegale e porta a tediosi problemi, meglio una cosa gratuita e legale, ancora meglio se open source.)
I programmi che usi girano benissimo anche su linux: Minecraft è java e quindi lo stesso file jar parte da linux, Gimp è un validissimo sostituto di photoshop (e rispondo ai detrattori in questo topic che uso programmi di grafica per il mio sbocco professionale, e gimp ha sempre soddisfatto tutte le mie esigenze, tanto che mi intercambiavo fra i due senza problemi. È un programma usabilissimo per la maggior parte delle esigenze), ma se sei costretto a usare photoshop per svogliatezza o perché hai la licenza o altro allora parte decentemente anche usando wine (ma probabilmente se sei una persona svogliata difficilmente installerai linux).
È chiaramente una scelta da valutare bene, ma se fai un piccolo inventario di ciò che vuoi e che non vuoi allora capirai subito cosa scegliere.
In base alla distrubizione eviterai anche di riformattare ciclicamente per colpa del sistema che si impalla o che si aggiorna. ed è molto comodo.
---------- Post added at 16:05 ---------- Previous post was at 15:58 ----------
buttare giù 4 parole a caso non è il miglior modo per dimostrare la conoscenza di qualcosa.
Spiegare i perché 2 kernel sono uno meglio dell'altro forse sarebbe una mossa migliore. Linux è un ottimo sistema operativo, in quanto ha delle politiche di sicurezza particolari ed è un progetto che ha un grandissimo potenziale di crescita, direi praticamente infinito (al contrario di un qualunque software closed).
In relazione ai due kernel, la diatriba fra kernel monolitici e microkernel credo sia già un argomento dibattutto da 20 anni ed è chiaro che i kernel monolitici sono "inferiori" ai microkernel. Nonostante questo linux si rivela un sistema ottimo nonostante usi un kernel monolitico. Il kernel di windows è un kernel ibrido, come tale ha delle caratteristiche persino diverse da un microkernel.
Ambiti come dimensione del kernel, modularità, velocità di caricamento in memoria, politiche di sicurezza. Sono tutti aspetti che non potrai mai sintetizzare con "ho letto il kernel di linux e so di cosa parli". Hai letto 70 mega di codice? era bello? com'è la trama? ma fammi il piacere! Soluzioni geniali come lo scheduler dei dischi BFQ te le sogni su windows, il cui scheduler è talmente schifoso che non oso neanche proporlo come alternativa di studio.
Parlare di kernel in questo post è come provare a insegnare arabo via lettera: non ha senso. E credo sia meglio scendere dai trampolini, perché non ti rendono una persona migliore delle altre.
Ma cosa stai dicendo? Hai usato una citazione inesistente dato che non ho mai detto "ho letto il kernel di linux" bensì "ho letto alcune parti". Quindi evita di fare lo spiritoso sulla tua fervida immaginazione.
Sentiamo, come funzionerebbe lo scheduling su windows? Cosa esattamente fa schifo del suo scheduling, dici a me di motivare e poi tu spari 4 parole a caso?
Se noti ho già dato le mie motivazioni. La genialità dell'astrazione che c'è su windows, il fatto che non tutto è un file del fs ma è un oggetto astratto, l'io mgr (un io mgr così te lo sogni su linux) geniale nalla sua concezione (consulta i source di reactos di ntoskrnl per scoprirlo).
Per concludere ti dico: io mi occupo solo ed esclusivamente di kernel (sia nell' idearli che nel lavorare al loro interno) quindi il mio parere lo do su quello!
Sto cercando di dimostrare la mia superiorità? Non mi pare, sto semplicemente esprimendo il mio parere ed è ovvio che Tux, dicendo diverse bestemmie, non sapeva nemmeno di cosa stesse parlando.
E ancora torno all'inizio, in cosa fa dunque schifo lo scheduling di windows?
S
Sten_Gun
Citazione inesistente? se torni indietro la leggi
E i moderatori ci faranno un culo così per questo immenso OT
Comunque, un grande esperto come te che sicuramente ha letto tutto il codice del kernel di windows e conosce a menadito i meccanismi di scheduling (dall' I/O al disco) riesce a confrontare le astruse tecnologie del kernel linux con quelle di windows, e dare dell'idiota indirettamente a tutti quei personaggi che usano il kernel linux come server. In ambito desktop probabilmente, windows ha alcuni aspetti che rendono linux obsoleto, ma i vantaggi che comporta il passaggio da un sistema all'altro sono chiaramente vantaggiosi, e con il tempo questo vantaggio si accentua sempre di più.
Il caro scheduler del disco di windows già senza conoscerne i dettagli ti fa capire di quanto sia stato progettato in modo approssimativo. Prova a fare, in modo concorrente, due o più trasferimenti di files e vedrai come il sistema diventi inutilizzabile. Poi fai la stessa prova su un kernel patched con il bfq e già fai la differenza empirica.
Dati alla mano, questi sono i test del bfq BFQ and related stuff on disk scheduling
richieste da 4k tutte trattate in modo equo. Il caso peggiore quindi si avvicina al caso migliore. Il metodo funziona e trovi ulteriori dettagli e test nella pagina del progetto. (e puoi anche leggere il codice, se dubiti di tutto questo.). Questo scheduler non è altro che una miglioria del CFQ, lo scheduler di default del kernel linux. Migliorie della comunità, che su windows ti puoi sognare (ma questa è un'altra storia).
Quindi no, mi sto basando con solo i dati dello scheduler che utilizzo io e sulla controparte windows solo su esperienze empiriche (e il che è facilmente contestabile se questa fosse stata una seria discussione sulle prestazioni). Ma puoi fare l'esperimento di benchmark tu stesso, con tutti e due gli scheduler, e ti renderai conto da solo di quanto cambi la questione.
Ho usato windows per anni, e stando alla mia esperienza empirica (torno a precisarlo perché non ho mai avuto la possibilità di leggere la "genialità" del codice di windows) posso dirti che, per quanto possa essere fantastica l'astrazione di quel sistema, il suo io manager e i suoi schedulers, sono tutte cose che senza codice alla mano rimangono teorie che i fatti poi smentiscono. Astrarre non è sempre una buona idea, quando la base non funziona porta un sacco di problemi e lega lemani a chi deve lavorare sui sistemi a basso livello. Ed è una storia che mi ricorda tanto i fantomatici test di prestazioni in cui internet explorer prendeva 100 e tutti gli altri browser andavano sotto il punteggio 40. Poi si scoprì che erano tutti test truccati.
Tutto questo è per rispondere principalmente alle tue sentenze su linux e la sua stupidità. Poi, il fatto che in ambito server sia il più usato e il più diffuso di tutti i tempi senza possibilità di appello, sembra non essere importante. (molte persone sono stupide, scegliere un os così per far girare l'intera infrastruttura interne mondiale, che roba).
Lavori sui kernel, fai kernel e ti sei ridotto a rispondere in un forum in cui l'età media è 15 anni
Il caro scheduler del disco di windows già senza conoscerne i dettagli ti fa capire di quanto sia stato progettato in modo approssimativo. Prova a fare, in modo concorrente, due o più trasferimenti di files e vedrai come il sistema diventi inutilizzabile. Poi fai la stessa prova su un kernel patched con il bfq e già fai la differenza empirica.
Dati alla mano, questi sono i test del bfq BFQ and related stuff on disk scheduling
richieste da 4k tutte trattate in modo equo. Il caso peggiore quindi si avvicina al caso migliore. Il metodo funziona e trovi ulteriori dettagli e test nella pagina del progetto. (e puoi anche leggere il codice, se dubiti di tutto questo.). Questo scheduler non è altro che una miglioria del CFQ, lo scheduler di default del kernel linux. Migliorie della comunità, che su windows ti puoi sognare (ma questa è un'altra storia).
Quindi no, mi sto basando con solo i dati dello scheduler che utilizzo io e sulla controparte windows solo su esperienze empiriche (e il che è facilmente contestabile se questa fosse stata una seria discussione sulle prestazioni). Ma puoi fare l'esperimento di benchmark tu stesso, con tutti e due gli scheduler, e ti renderai conto da solo di quanto cambi la questione.
Ho usato windows per anni, e stando alla mia esperienza empirica (torno a precisarlo perché non ho mai avuto la possibilità di leggere la "genialità" del codice di windows) posso dirti che, per quanto possa essere fantastica l'astrazione di quel sistema, il suo io manager e i suoi schedulers, sono tutte cose che senza codice alla mano rimangono teorie che i fatti poi smentiscono. Astrarre non è sempre una buona idea, quando la base non funziona porta un sacco di problemi e lega lemani a chi deve lavorare sui sistemi a basso livello. Ed è una storia che mi ricorda tanto i fantomatici test di prestazioni in cui internet explorer prendeva 100 e tutti gli altri browser andavano sotto il punteggio 40. Poi si scoprì che erano tutti test truccati.
Tutto questo è per rispondere principalmente alle tue sentenze su linux e la sua stupidità. Poi, il fatto che in ambito server sia il più usato e il più diffuso di tutti i tempi senza possibilità di appello, sembra non essere importante. (molte persone sono stupide, scegliere un os così per far girare l'intera infrastruttura interne mondiale, che roba).
Lavori sui kernel, fai kernel e ti sei ridotto a rispondere in un forum in cui l'età media è 15 anni
Ah sì, non vorrei dire ma reactos non è windows, è un progetto open source. Questo non prova che windows implementi bene ciò che ipotizza, e rafforza soltanto la tesi che cerco di sostenere. Se non si è capito, non è tanto il concetto a rendere un sistema geniale, quanto la sua implementazione. Se implementi una cosa geniale in modo ridicolo hai fatto tanto lavoro per nulla. E secondo me, windows fa proprio questo.
E i moderatori ci faranno un culo così per questo immenso OT
Ultima modifica:
A me mi hai dato dell'ignorante implicitamente ![:\](/forum/data/assets/smilies/mhhae.gif "Mhhae :\")
, però io l'ho accettato poiché di karnel davvero non ci capisco una mazza, però è anche vero che tu non hai detto molto... magari dacci\dammi quale info in più di questo GRANDISSIMO karnel di windows e di quel SCHIFOSO karnel di linux
P.S: Hai detto cose che si trovano facilmente su internet, con questo non voglio dire che hai preso spunto da li, ma che sono facilmente reperibili anche da internet queste informazioni.
Sten si è OT, ma credo che sia una discussione interessante, basta non creare flame.
, però io l'ho accettato poiché di karnel davvero non ci capisco una mazza, però è anche vero che tu non hai detto molto... magari dacci\dammi quale info in più di questo GRANDISSIMO karnel di windows e di quel SCHIFOSO karnel di linux P.S: Hai detto cose che si trovano facilmente su internet, con questo non voglio dire che hai preso spunto da li, ma che sono facilmente reperibili anche da internet queste informazioni.
Sten si è OT, ma credo che sia una discussione interessante, basta non creare flame.
S
Sten_Gun
Ah ecco, questo me l'ero dimenticato.
Hai mai sentito parlare di API? chi scrive i driver usa quello, ma non significa conoscere il codice del kernel su cui stai implementando quel driver.
Questo tuo atteggiamento ti scopre per quello che sei: un troll fanboy che ha trovato un terreno per sfogarsi
Ultima modifica:
Ovviamente anche tu stai parlando senza sapere. Basta usare le api? Questo è vero per un apicultore non di certo per uno che progetta un driver, e che deve tenere conto non solo del device stack ma dell'irp dispatch (nel caso di filter), dell'altitude e i vari frame a cui essa si collega nel device stack (nel caso di minifilter), degli spinlock per accedere a determinate strutture dell'os, delle pre e post operation (nel caso di minifilter), dell'accesso ai file object, delle rundown protection, della gestione del paging di windows (ed in generale della memoria), dello stato di alcuni registri (in determinate situazioni), delle risposte che da l'io mgr (nel caso di legacy filter) o del filter manager (nel caso di minifilter), del device al quale ti attacchi (nel caso di filter ET minifilter), delle operazioni del file system, della frammentazione. Questo lo fanno le API? Certo, anche perché scrivere ogni singola api sarebbe pura follia. Le api ti dicono come l'os è organizzato? Assolutamente NO! E' come dire "uno può risolvere integrali senza conoscere il calcolo integrale", magari può applicare la sostituzione, o il metodo per parti e risolverne un paio, ma sicuramente sarà solo un caso. Assodato questo, ovvero che per scrivere driver (i miei li trovi qui https://github.com/irp) occorre una conoscenza MOLTO PROFONDA del kernel nel quale sviluppi, che poi si ripresenta anche nel kernel debugging quando il tuo driver causa BSOD (praticamente sempre nei primi test), ripeto ciò che forse non ho detto qui ma in un'altra conversazione (scusami, è da stamattina che discuto -le vacanze esistono anche per me- e mi confondo tra le discussioni).Ah ecco, questo me l'ero dimenticato.
Hai mai sentito parlare di API? chi scrive i driver usa quello, ma non significa conoscere il codice del kernel su cui stai implementando quel driver.
Questo tuo atteggiamento ti scopre per quello che sei: un troll fanboy che ha trovato un terreno per sfogarsi
Io non ho mai detto KERNEL WINDOWS = BENE, KERNEL LINUX = MALE. Sono convinto che parlare di kernel sia come paragonare l'algebra all'analisi e dire "è più difficile questa o quell'altra cosa", ovvero non si può, essendo esso composto da troppe componenti (magari se si scende nel particolare, come tu hai fatto con lo scheduling -e non ho ancora capito perché lo scheduler di windows sia merd*, come tu hai detto- il paragone diventa lecito). Quindi non ho mai detto una cosa simile, ho solo espresso la mia personale preferenza, e la genialità che sta dietro la struttura del kernel di windows è sicuramente maggiore di quella che sta dietro il kernel linux, almeno nelle parti che ho letto.
Questa genialità non lo rende migliore, ma lo rende MIGLIORABILE. Personalmente a me fanno schifo entrambi gli os ed è per questo che sto creando il mio exokernel. Ma se devo giudicare il kernel, per vari motivi che come dici tu non ha senso elencare in un forum di 15enni (come ha detto SpeedJack i miei post qui sembrano supercazzole), allora preferisco l'ibrido NT. Poi che discorso è? Predator non è forse in gamba? Eppure posta qui no? Le tue argomentazioni "sociali" sono ridicole, per favore torna a scuola dai, che con i ragazzini non voglio averci a che fare. Oppure smettila di pensare che io sia qui per trollare e inizia ad acquisire un aria di serietà.
Tornando al kernel di windows nella mia vita (e sono davvero tanti anni che lavoro su win) ho avuto solo una BSOD dovuta ad un bug del kernel NT che ho riportato immediatamente allo staff del fs e che sicuramente non avrebbe causato privilege escalation o denial of service. Più che un bug era una svista che a volte colpisce anche i migliori programmatori. Io parlo in base alle MIE esperienze. Ma comunque molti interessante la parte in cui parli dello scheduling su linux (che non conosco sinceramente), più tardi approfondisco.
E lo ripeto: ho scritto alcune patch per ntoskrnl di reactOS e posso dirti che, nonostante (e ovviamente) io conosca l'io manager solo tramite documentazione offerta da microsoft stessa (anche se MOLTO PRECISA), posso dirti che ciò che leggo lo rivedo scritto sotto forma di codice in reactOS, sono praticamente, almeno a livello di kernel (non mi sono mai occupato dell'user mode ne di win ne di reactOS) coincidenti!
Ultima modifica:
Ahah ora ho capito chi sei, sei caromio aka coroner aka irp aka utente pluribannato per troll e flame. In effetti questo comportamento mi era abbastanza familiare.
Anzi ti dico precisamente ciò che ReactOS ha di identico a win nel kernel:
i seguenti manager: io, cm, dbgk, ex, ke, lpc, ob, ps, mm/arm3, pnp (non totalmente); poi il vm handling, l'hardware abstraction layer (IRQL e bus handling). Ciò che non è perfettamente uguale sono il cache manager e se (per la sicurezza del fs, access check etc), e questo non perché è diverso ma perché manca molto e sono poco implementati!
Direi che è un'ottima reference no?
---------- Post added at 19:08 ---------- Previous post was at 19:06 ----------
i seguenti manager: io, cm, dbgk, ex, ke, lpc, ob, ps, mm/arm3, pnp (non totalmente); poi il vm handling, l'hardware abstraction layer (IRQL e bus handling). Ciò che non è perfettamente uguale sono il cache manager e se (per la sicurezza del fs, access check etc), e questo non perché è diverso ma perché manca molto e sono poco implementati!
Direi che è un'ottima reference no?
---------- Post added at 19:08 ---------- Previous post was at 19:06 ----------
Quale atteggiamento scusa? Dove ho trollato e fatto flame? Quando ti ho insultato?
Lo stesso atteggiamento per il quale sei stato bannato e allontanato più volte dalla community
Io ho capito che sei un idiota, con te non parlo. Stai rovinando una conversazione interessante con la tua ignoranza. Quindi pensa ciò che vuoi, a me non interessa, segnalami pure se credi, ma sparisci e non rispondermi più, grazie
- Stato
DISCUSSIONI SIMILI
-
- 0
-
- 187
- In evidenza
-
- 20
-
- 13K