Newsgroup: it.comp.os.linux.iniziare
Titolo: Linux Sì, Linux No

Ciao a tutti!!
Avrei intenzione di installare Linux.
Essendo la mia macchina ormai datata (CPU: AMD K6 a 166Mhz con tecnologia
MMX; RAM: 64 MB; HD: 2 GB; SO: Windows 98 Second Edition) ciň e
sconsigliabile?
fd

 fd

Intanto grazie per la risposta.
A scanso di equivoci un'altro chiarimento: posso tenere sulla mia macchina
entrambi i sistemi operativi giusto? (Non voglio privarmi di Windows 98).
ciao
fd
"Franco" <franco...@RIMUOVIsrocco.it> ha scritto nel messaggio
news:3E2EA82...@RIMUOVIsrocco.it...


 
Certo, ma prima devi paciugare un po' le partizioni del disco.
Ovvero, se non vuoi "piallare" il disco e buttarci sopra linux prima 
devi "fargli posto" riducendo lo spazio dedicato a windows sull'hard 
disk, con un tool come partition magic o roba del genere.
Una volta che hai fatto posto, l'installer di linux si metterà 
tranquillamente nel posto che gli hai lasciato senza toccarti la 
partizione windows.
Io pero' sono un po' meno sicuro che ti troverai tanto bene con il tuo 
PC: le distribuzioni più "amichevoli" per l'installazione sono anche 
decisamente "appesantite" e non so se riusciranno a girare 
soddisfacentemente lì sopra... OpenOffice in ogni caso scordatelo, ad 
esempio, a meno che tu non abbia la pazienza di Giobbe :-)
bye!
-- 
Fabrizio "Hermooz" Ermini

	Con 2 Giga di spazio temo che dovresti rinunciare a qualche programma 
per avere due partizioni.
	Per quanto riguarda la pesantezza delle distribuzioni, è perfettamente 
vero l'appunto. Temo però che venendo da Windows ci sia un certo 
percorso per "digerire" Linux (almeno per me è così).
	Esistono senza dubbio distribuzioni più performanti delle due, ma non 
so come ti ci troveresti. Comunque a parità di programmi Linux è SEMPRE 
più leggero e veloce di Win.
Franco


 SEMPRE più leggero e veloce di Win.
Non essere così categorico, che diffondere eccessiva aspettativa non fa 
bene alla causa del pinguino :-)
Ad esempio, per fare quello che fa windows 98 con KDE ci vogliono almeno 
il doppio di processore e di RAM, purtroppo... un sistema linux PUO' 
essere molto piu' veloce di uno winzozz, ma non è questa la vera 
motivazione per cui sceglierlo :-)
PS: Il quoting, please :-)


 ciò e sconsigliabile?
Considera che installero' Linux su un P133 e un P75 e faranno da
server...
Direi che quello come client vada piu' che bene quindi :)
-- 
   => Don't Let Your Fears Stand in The Way of Your Dreams !!! <=
 
http://www.delymyth.net/
 ~ 
http://members.ebay.it/aboutme/delymyth/
 ICQ: 8761263 - MSN: 
dely...@msn.com
 E-Mail: 
DEly...@despammed.com
           => FREE! Hardware Anti-Virus!!! - /dev/brain <=

 ringiovanita (pių veloce) di un paio di anni.
Si, probabile, ma ci vorra` un bel po` di lavoro. Se si affida a RedHat
o Mandrake e alle configurazioni di default, e` probabile che otterra`
solo un sistema lento e una robusta dose di frustrazione.
-- 
Ikitt

 ha scritto nel messaggio
news:uExX9.89383$AA2.3...@news2.tin.it...

--
se vuoi scrivermi, metti al posto di ermanza23 --> ermanza22

Hermooz scriveva:

Il doppio di processore?
Dipende da cosa ci fai:
Se un utente abituato a windows 95/98 (non XP) fa una ricerca di un file con
kfind (su un disco rigido con qualche GB di dati) non potrà fare a meno di
notare che:
1) Cercare un file su win95/98/ME e' 10/20 volte + veloce
2) Cercare un file su win95/98/ME usa pochi MB di memoria mentre con linux
ti occupa 500/1000 MB di memoria.
3) Se dopo la ricerca decido di farne un'altra win95/98/ME e' velocissimo
perchè ha cachato tutto (con pochi MB di cache utilizzata) mentre linux ci
rimette una vita (gli ci vogliono 500/1000 MB per non swappare e per
cachare diversi GB)
Ovviamente ciò accade solo facendo una ricerca su diversi GB di dati.
OK, kfind e' pesante ma i risulatati non cambiano di molto con gnome-find,
find o glob.
Il discorso non vale per XP che è lento come linux nella ricerca di files
(l'ho usato 1 settimana solamente quindi non posso dare un giudizio
preciso).
P.S. Uso ext3, forse con altri filesystem la situazione e' diversa....

 find o glob.
 ^^^^^^
Ho dei dubbi...
-- 
Ikitt 
"Stupid people do stupid things smart people outsmart each others"
*** mailserver: 
freemail.it

 cachare diversi GB)
Ma che diamine di find usi? Il mio linux non funziona cosi':
$ df -h  | head -2
Filesystem            Size  Used Avail Use% Mounted on
/dev/hdb5             4.8G  3.0G  1.6G  65% /
# time find / -xdev -name "*.ppt"
real    1m28.128s
# time find / -xdev -name "*.ppt2"
real    0m10.012s
# time find / -xdev -size +200000k
real    0m18.797s
Ovviamente lanciati uno dopo l'altro a macchina non scarica. La swap non
viene toccata e ho *solo* un vecchio duron con 256 Mb di RAM. Mentre facevo
il test stavo usando kde3, avevo aperto 2 konsole in una delle quali c'e'
slrn per scrivervi e nell'altra konsole ho apt-get che tira giu' l'ultima
versione stabile di kde3 per redhat8 (3.0.5a-1).
-- 
Enrico Bodo  -   Postdoc Fellow       
University of Rome "La Sapienza"    
Department of Chemistry        

 Occupa poco piu' di mezzo mega.
Beh, anche a me è abbastanza pesantino....sono contento per te, ma vorrei 
sapere se posso fare qualcosa per velocizzarlo, o se esiste un altro modo, 
anche da console, per cercare i file....
Ciao
 
-- 
| (o_  | Edoardo "Edoloz" Carminati             |
| //\  | "VI" Registered Linux user #301558     |
| V_/_ | "VI" = "V"ery "I"ncompetent  : )       |
| SuSE |                                        |

 1106 root      15   0   552  552   396 R     1.5  0.2   0:02 find
Anche a me top da un consumo di memoria dello 0.2% ma non mi sembra
importante la quantita' di memoria che si ciuccia find direttamente!
Innanzitutto vorrei correggere il punto 2 del mio precedente messaggio in
cui dicevo che per cercare un file su win95/98/ME usa pochi MB di memoria
mentre linux occupa 500/1000 MB di memoria.
Correggo con:
2) Cercare un file su win95/98/ME usa pochi MB mentre con linux (kfind) ci
vogliono 500/1000 MB per non swappare e per cachare diversi GB.
Questa e' la situazione del mio disco riportata da df -h:
Filesystem         Dimens. Usati Disp. Uso% Montato su
/dev/hda5             6.7G  5.6G  810M  88% /
none                  188M     0  187M   0% /dev/shm
/dev/hda7             4.9G  3.8G  956M  80% /mnt/ext3
/dev/hda1             6.7G  5.6G  1.1G  83% /mnt/windows
Il processore e' un Celeron Coppermine 700 overclockato a 875, il SO e'
Mandrake 8.2 con kde 3.1.
Dunque, ora apro una console e lancio il comando free...
             total       used       free     shared    buffers     cached
Mem:        384800     353560      31240          0      42460     189212
-/+ buffers/cache:     121888     262912
Swap:       548816          0     548816
lancio find / -iname "qualcosa" e lo lascio lavorare.....
dopo 6 minuti find ha finito.
             total       used       free     shared    buffers     cached
Mem:        384800     380324       4476          0     160272      42428
-/+ buffers/cache:     177624     207176
Swap:       548816       1896     546920
La situazione della memoria e' molto cambiata; i buffers sono 160272 K e la
cache 42428 K.
Ora rilancio il comando find / -iname "qualcosa".
Spererei che in quei buffers e in quella cache ci siano abbastanza dati da
velocizzare la ricerca ma.... find finisce dopo 5 minuti (contro i 6 della
prima volta).
E' normale? Ha bufferizzato 160 MB e 40 di cache, mica noccioline....
Riprovo per la terza volta a dare il comando find e dopo i soliti 5 minuti
eseguo il comando free.
             total       used       free     shared    buffers     cached
Mem:        384800     380064       4736          0     178320      38116
-/+ buffers/cache:     163628     221172
Swap:       548816       3524     545292
Ha cominciato a usare anche la memoria di swap.
Provo ora con kfind.... solita ricerca....
17 MINUTI!!! Neanche 4 ricerche l'ora :-(
Do il solito comando free e ottengo:
             total       used       free     shared    buffers     cached
Mem:        384800     380592       4208          0     202196      32324
-/+ buffers/cache:     146072     238728
Swap:       548816      14064     534752
Non mi pare che servano a molto 200 MB di buffers.........e 32 di cache....
Ovviamente se riprovassi con kfind ci rimetterebbe 15/20 minuti alla faccia
della cache e dei buffers.
Meno male che da qualche giorno ho cancellato i sorgenti, ho compresso in un
tar.bz2 tutti i temi di icone per kde che non uso (per find e' meglio un
file che 32876 piccoli files), ho messo in tar.bz2 varie directory....
quindi per find le cose sono più semplici ora ma fino a pochi giorni fa
arrivava a swapparmi (con kfind) anche 100 MB subito alla prima ricerca.

Ikitt scriveva:

Se vogliamo fare un confronto tra cercare files in win e in linux credo che
il confronto debba essere fatto con un frontend grafico tipo kfind o
gnome-find visto che win ha un'interfaccia grafica.
Sul mio pc find risulta 3 volte piů veloce di kfind.
A parte questo mi sembra che le tue ricerche siano veramente velocissime,
buon per te! 
Hai qualche suggerimento per velocizzare anche le mie ricerche (a parte
usare find al posto di kfind)?
P.S. Ti invito a leggere il messaggio che ho inviato a Bodo in cui correggo
il punto 2 del mio messaggio e spiego meglio la mia situazione (17 MINUTI
per cercare un file con kfind).

 usare find al posto di kfind)?
No, mi dispiace.


Non so cosa, magari non hai attivato il dma ho hai qualche altro 
problema/collo di bottiglia, ma
Test su: (macchina buonina, ma non eccezionale)
Amd duron 1300 (su mb con chipset kt400) 512Mbram disco IDE 
ibm gpx120 da 120GB collegato su un controller 
ataraid promise kernel 2.4.21....
ricerca su reiserfs (con 471568 file presenti nella root
montati su una decina di partizioni)
comando #time find / -iname 'gcc*'
Eseguito la prima volta
[cut] da mè vengono trovate 265 righe
real    0m23.514s
user    0m0.510s
sys     0m1.510s
Le volte successive
real    0m1.593s
user    0m0.530s
sys     0m0.940s
Mentre facevo il test ho:
setiathome che sta lavorando (circa 4.50' ore per analisi)
kde aperto su F7 e F8
il gcc che mi sta ricompilando compilando emacs
un fetchnews in esecuzione
sto navigando con galeon
e ho 4/5 applicazioni aperte in 'standby'


 usare find al posto di kfind)?
Abbatanza userfriendy e poco piu lento di find puoi usare il find che trovi 
nel filemanager testuale 'mc' (Midnight Commander) oppure  xnc è grafico, 
ma la ricerca ha funzionalità molto limitate


mrz scriveva:

Il comando hdparm -t /dev/hda5 (hda5 è la mia directory / in ext3) da il
seguente risultato:
/dev/hda5:
 Timing buffered disk reads:  64 MB in  2.57 seconds = 24.90 MB/sec
Il comando hdparm -T /dev/hda5 invece risponde:
/dev/hda5:
 Timing buffer-cache reads:   128 MB in  0.94 seconds =136.17 MB/sec
hdparm -I /dev/hda5 risponde, come puoi vedere nelle prossime righe, dicendo
che il disco va a udma4 (come mai non mi indica il PIO mode?) :
/dev/hda5:
non-removable ATA device, with non-removable media
        Model Number:           SAMSUNG SV2042H
        Serial Number:          0273J1FR171995
        Firmware Revision:      PK100-13
Standards:
        Used: ATA/ATAPI-4 T13 1153D revision 17
        Supported: 1 2 3 4 5 6 & some of 5
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        bytes/track:    34902           (obsolete)
        bytes/sector:   554             (obsolete)
        current sector capacity: 16514064
        LBA user addressable sectors = 39865392
Capabilities:
        LBA, IORDY(cannot be disabled)
        Buffer size: 426.0kB    ECC bytes: 4    Queue depth: 1
        Standby timer values: spec'd by Vendor, no device specific minimum
        r/w multiple sector transfer: Max = 16  Current = 16
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    NOP cmd
           *    READ BUFFER cmd
           *    WRITE BUFFER cmd
           *    Host Protected Area feature set
           *    DEVICE RESET cmd
           *    look-ahead
           *    write cache
           *    Power Management feature set
                Security Mode feature set
           *    SMART feature set
           *    DOWNLOAD MICROCODE cmd
Security:
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        80min for SECURITY ERASE UNIT. 80min for ENHANCED SECURITY ERASE
UNIT.
HW reset results:
        CBLID- below Vih
        Device num = 1
Inoltre ho messo come parametro di boot del kernel ide0=ata66 visto che con
questo parametro ho visto che ottenevo risultati migliori rispetto a non
metterlo.
Il mio povero vecchio PC equipaggiato con cpu Celeron Coppermine 700
overclockato a 875, 384 mb di ram, disco SAMSUNG SV2042H e motherboard VIA
(non ricordo il modello, mi pare VIA Pro 133) mi pare quindi che sia gia al
massimo delle sue obsolete prestazioni.....o quasi.
Ho provato a usare time con find come nel tuo esempio e dopo la lista dei
files trovati mi dice:
find: . changed during execution of find
Command exited with non-zero status 1
1.03user 7.94system 2:17.74elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (807major+752minor)pagefaults 0swaps
Riprovo e mi dice:
Command exited with non-zero status 1
1.90user 5.36system 5:05.81elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (164major+393minor)pagefaults 0swaps
Mah, qualcosa non va :-(

 
Grazie comunque.

non saprei aiutarti, la macchina dovrebbe essere sufficientemente prestante.
Bisognerebbe capire da cosa deriva il problema.
I tuoi dischi sembrano sufficientemente veloci, la memoria dovrebbe bastare 
e il processore mi sembra ancora rispettabile
magari prova a fare 
# find / |wc -l (L non UNO)
per contare quanti file hai sul disco se sono molto un superiori ai miei 
potrebbe anche avere un senso.
Sotto windows ho visto il sistema andare in crisi quando in un unico ramo di 
directory sono presenti molti file 10000-20000 file piccolini (erano 
scontrini di un registratore di cassa)
Non credo che sia il tuo caso, ma eventualmente verifica di non avere un 
problema simile.
prova a guardare di non avere attivi 50 servizi server che non utilizzi.
mantieni attivi solo quelli che ti servono
reinstalla le find-utils
ed eventualmente anche time (utile per misurare i tempi dei comandi)
Quando ho provato Kfind mi ha succhiato un mare di risorse, killandolo tutto 
è tornato a posto, ma non vorrei mai che ...
libera tutta la memoria che puoi (magari riavviando il pc) e riprova per 
vedere se qualcosa migliora.

 vedere se qualcosa migliora.
kfind richiede un computer del futuro.... tipo quello della nave spaziale
Enterprise.......
Ciao.