Linux? No grazie...
JiuSDYC
linux non e' in crescita del 250% nelle grandi realta' aziendali
(specialmente in Italia) ma nelle piccole (se non piccolissime) e negli
utilizzatori casalinghi.
Ti spiego anche il perche'.
Entri a lavorare in una grande azienda. Trovi
8/10 uno Unix commerciale. Di questi almeno il 90%
sono Sun con Solaris.
A casa non sono in molti a poterselo permettere, e cosi', per
continuare a fare "palestra" anche a casa, installi linux. Solo
perche' e' gratis.
Non te ne fotte della filosofia che ci sta dietro.
Tanto e' vero che molti di quelli che USANO linux, e non chi ci
giocarella, sono professionisti che fanno consulenze su unix o lavorano
su unix o fanno assistenza su HW/Soft Unix.
Seconda questione: il codice del kernel.
Se quello MS fosse open, ti accorgeresti di quanto e' diverso da quello
di linux, magari con alcune parti che assomigliano a BSD, non certo a
linux.
L'ho detto e lo ripetero' fino alla morte.
Linux tecnologicamente e' solo un evoluzione di minix, roba di 20-30
anni fa...
Oggi l'informatica va in altre direzioni, e linux dimostra di non
essere piu' una piattaforma di sperimentazione, ma si sta mano mano
piegando alle esigenze commerciali dei suoi utilizzatori, che vogliono
firewire, allora gli si da, aggiungendo righe di schifezze nel
kernel...
Molto meglio la scelta di Debian di supportare HURD, un microkernel
molto buono, tecnologicamente all'avanguardia e dal futuro certamente
piu' roseo del kernel di linux attuale.
Morale? VIVA MICROSOFT
Elle
"JiuSDYC" <x...@xxx.xxx> wrote in message
news:MPG.156a01bedbeffc0d9897a5@localhost...
Emmanuele Bassi (Zefram)
\snip
> Linux tecnologicamente e' solo un evoluzione di minix, roba di 20-30
> anni fa...
\snip
Ohibo`, solo con questa frase il trollometro logaritmico ha fatto
*puff* e la lancetta e` partita a duecento chilometri all'ora (me
l'ha rilevata la polizia stradale con l'autovelox).
Vabbe`, investimento per l'anno prossimo: un nuovo trollometro, a
scala piu` grossa. Non posso continuare a fonderli...
Bye,
Emmanuele.
--
Emmanuele Bassi | [ http://digilander.iol.it/ebassi/ ]
emmanue...@iol.it |
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738 08BD 8ECC DB8F A432 0FF4
Max Adamo
Elle wrote:
>
> Scusate, le opinioni sono libere, ma sento odore di TROLL.....
Sempre con 'sta azzo di storia che se uno la pensa in maniera diversa in
casa d'altri č un troll :(
Scatena il flame dici? Saresti tu a cascarci, non io. ... e poi dilla la
verita', ti piacerebbe corrergli dietro ad instularlo: ammettilo.
Ognuno deve essere libero di esprimere la propria opinione in qualsiasi
contesto, senza essere offensivo, ma con i mezzi che ritiene piů
opportuni.
Questa č la mia opinione. Sono pure io un troll?
--
Massimiliano Adamo
Max Adamo
> Ohibo`, solo con questa frase il trollometro logaritmico
Sempre con 'sta azzo di storia che se uno la pensa in maniera diversa in
casa d'altri è un troll :(
Scatena il flame dici? Saresti tu a cascarci, non io. ... e poi dilla la
verita', ti piacerebbe corrergli dietro ad instularlo: ammettilo.
Ognuno deve essere libero di esprimere la propria opinione in qualsiasi
contesto, senza essere offensivo, ma con i mezzi che ritiene più
opportuni.
Questa è la mia opinione. Sono pure io un troll?
--
Massimiliano Adamo
Davide Inglima - limaCAT
> Scusate, le opinioni sono libere, ma sento odore di TROLL.....
Ciao... quando rispondi ad un post dovresti rispondere per cortesia sotto il
messaggio precendente, e tagliare le parti non interessanti del messaggio
a cui rispondi (ti bastava tenere ad esempio le ultime 5 righe del messaggio
prima)...
--
Davide Inglima, limaCAT
thorin_...@durin.khazad-dum.net
> Salve
> linux non e' in crescita del 250% nelle grandi realta' aziendali
> (specialmente in Italia) ma nelle piccole (se non piccolissime) e negli
> utilizzatori casalinghi.
Fancultroll
*plonk*
--
Pierluigi De Rosa (tho...@durin.khazad-dum.net).
<< LINUX: the choice of a GNU generation >>
<< For my real address... ask the Balrog. >>
* Sostenete la Lega per la Soppressione dei Troll *
Emmanuele Bassi (Zefram)
>> Ohibo`, solo con questa frase il trollometro logaritmico
>
> Sempre con 'sta azzo di storia che se uno la pensa in maniera diversa in
> casa d'altri è un troll :(
No: se uno viene qua e vuol fare l'emulo di Celentano lo si cazzia. Se,
invece, espone le sue idee con chiarezza, ci si discute. Il post di cui
sopra era fatto apposta per fungere da esca da troll.
///
Noi non si ha un laser di controllo mentale orbitale, pero` se qualcuno
dice qualcosa deve anche essere pronto a difenderla, perche' se penso
che abbia detto 'na strunzata, glielo si fa' notare. Quanto gentilmente
dipende dal tono di chi ha iniziato il thread, e dal livello di
incazzatura a cui chi risponde e` sottoposto.
Questo e` come Internet, e la vita, funziona.
> Questa è la mia opinione. Sono pure io un troll?
No, ma alle volte sei un gran rompipalle, detto cosi`, da amico... :-)
thorin_...@durin.khazad-dum.net
> Elle wrote:
>>
>> Scusate, le opinioni sono libere, ma sento odore di TROLL.....
> Sempre con 'sta azzo di storia che se uno la pensa in maniera diversa in
> casa d'altri è un troll :(
Max, stai attento a quello che dici.. che fai, ricaschi indietro? Ancora
non hai imparato a distinguere i troll imbecilli dagli umani?
Max Adamo
"Emmanuele Bassi (Zefram)" wrote:
>
> * Max Adamo <maxa...@iol.it> [2001-05-14 19:18]:
>
> >> Ohibo`, solo con questa frase il trollometro logaritmico
> >
> > Sempre con 'sta azzo di storia che se uno la pensa in maniera diversa in
> > casa d'altri è un troll :(
>
> No: se uno viene qua e vuol fare l'emulo di Celentano lo si cazzia. Se,
> invece, espone le sue idee con chiarezza, ci si discute. Il post di cui
> sopra era fatto apposta per fungere da esca da troll.
Va bene, chiedo venia ....
> Questo e` come Internet, e la vita, funziona.
No: nella vita i troll si chiamano "rompicoglioni" :))
--
Massimiliano Adamo
Max Adamo
thorin_...@durin.khazad-dum.net wrote:
>
> In un messaggio del Mon, 14 May 2001 19:17:09 GMT Max Adamo scriveva:
>
> > Elle wrote:
> >>
> >> Scusate, le opinioni sono libere, ma sento odore di TROLL.....
>
> > Sempre con 'sta azzo di storia che se uno la pensa in maniera diversa in
> > casa d'altri è un troll :(
> Max, stai attento a quello che dici.. che fai, ricaschi indietro? Ancora
> non hai imparato a distinguere i troll imbecilli dagli umani?
Va bene, chiedo venia ....
--
Massimiliano
Mirco Miranda
> Oggi l'informatica va in altre direzioni, e linux dimostra di non
> essere piu' una piattaforma di sperimentazione, ma si sta mano mano
> piegando alle esigenze commerciali dei suoi utilizzatori, che vogliono
> firewire, allora gli si da, aggiungendo righe di schifezze nel
> kernel...
Dimentichi che linux e` ancora piu` stabile di windows.
> Molto meglio la scelta di Debian di supportare HURD, un microkernel
> molto buono, tecnologicamente all'avanguardia e dal futuro certamente
> piu' roseo del kernel di linux attuale.
Debian fa anche la distribuzione di linux...
--
ciao, Mirco.
[ Icq#:51640305 ] [ http://spazioweb.inwind.it/mmos2/ ]
Andrea Carosi
> Linux tecnologicamente e' solo un evoluzione di minix, roba di 20-30
> anni fa...
completa stima sulla qualità di windows2000, un SO nato "oggi" che va
più lento di un sistema concepito 30 anni fa [1]
[1] Microsoft: I hope you can't go anywhere today
Ciao, Andrea
--
#include <signature.h> E-mail: andrea...@libero.it
Firma la petizione contro la nuova legge sull'editoria:
http://punto-informatico.it/petizione.asp
thorin_...@durin.khazad-dum.net
> JiuSDYC ha scritto:
>> Oggi l'informatica va in altre direzioni, e linux dimostra di non
>> essere piu' una piattaforma di sperimentazione, ma si sta mano mano
>> piegando alle esigenze commerciali dei suoi utilizzatori, che vogliono
>> firewire, allora gli si da, aggiungendo righe di schifezze nel
>> kernel...
> Dimentichi che linux e` ancora piu` stabile di windows.
Per favore, killate questo troglione [1] e non fomentate un thread
inutile !
[1] crasi fra troll e coglione, ovviamente...
Marco Costamagna
"JiuSDYC" <x...@xxx.xxx> ha scritto nel messaggio
news:MPG.156a01bedbeffc0d9897a5@localhost...
....
> Oggi l'informatica va in altre direzioni, e linux dimostra di non
> essere piu' una piattaforma di sperimentazione, ma si sta mano mano
> piegando alle esigenze commerciali dei suoi utilizzatori, che vogliono
> firewire, allora gli si da, aggiungendo righe di schifezze nel
> kernel...
Mai saputo che esiste la possibilitą di compilarlo senza le schifezze che
non ti servono, vero?
Simone Caldana
>
> * JiuSDYC <x...@xxx.xxx> [2001-05-14 13:53]:
>
> \snip
>
> > Linux tecnologicamente e' solo un evoluzione di minix, roba di 20-30
> > anni fa...
>
> \snip
>
> Ohibo`, solo con questa frase il trollometro logaritmico ha fatto
> *puff* e la lancetta e` partita a duecento chilometri all'ora (me
> l'ha rilevata la polizia stradale con l'autovelox).
ha ragione, un kernel monolitico e' una idea vecchia come il cucco.
(questo non toglie che quel post sia una flame bait)
--
. Simone Caldana - System and Network Manager at Vitaminic spa .
. simone....@vitaminic.net http://simone.caldana.org .
DISCLAIMER, PLEASE NOTE: This communication is intended only for
use by the addressee. It may contain confidential or privileged
information. Transmission, distribution and/or copy cannot be
permitted. Please notify immediately the sender by replying if
you are not the intended recipient.
Piergiorgio Sartor
Simone Caldana wrote:
> ha ragione, un kernel monolitico e' una idea vecchia come il cucco.
Che sia vecchia non vuol dire che sia sbagliata o non funzionale.
Come dire che la ruota tonda e` un'idea vecchia, quindi
facciamola quadrata...
Il fatto e` che il kernel monolitico ben si adatta alle
attuali CPU. Finche` qualcuno non cambiera` il paradigma
dell'HW, il kernel monolitico funzionera` bene.
bye,
--
Piergiorgio Sartor
Lorenzo Pulici
> Linux tecnologicamente e' solo un evoluzione di minix, roba di 20-30
> anni fa...
Gia', invece Win e' una evoluzione del Dos, che a sua volta e' uan
evoluzione del CP/M... roba moderna, nevvero?
*plonk*
--
Ciao | sno...@libero.it
Lorenzo | "Produci, consuma, crepa" - CCCP Fedeli alla Linea
Elle
> Ciao... quando rispondi ad un post dovresti rispondere per cortesia
sotto il
> messaggio precendente, e tagliare le parti non interessanti del
messaggio
> a cui rispondi (ti bastava tenere ad esempio le ultime 5 righe del
messaggio
Scusa, hai ragione per la quota, chiedo venia, ma intervengo poco nelle NG
ed a volte mi dimentico.. :(
Grazie comunque per la critica "Costruttiva", ciao
Xelloss
news:9dqr80$i7u$1...@by-tor.weitzmann.local...
> Gia', invece Win e' una evoluzione del Dos, che a sua volta e' uan
> evoluzione del CP/M... roba moderna, nevvero?
Win9X è morto.
Win2000 è vivo. Evviva Win2000.
Saluti.
--
Wilmer Ricciotti
wi...@bigfoot.com
Simone Caldana
>
> Simone Caldana wrote:
>
> > ha ragione, un kernel monolitico e' una idea vecchia come il cucco.
>
> Che sia vecchia non vuol dire che sia sbagliata o non funzionale.
>
cito dal tizio:
> > Linux tecnologicamente e' solo un evoluzione di minix, roba di 20-30
> > anni fa...
non vuol mica dire che sia sbagliato.
io cmq per pulizia e flessibilita' preferisco i microkernel (ne
progettabbi uno con 28 chiamate, se non ricordo male)
Piergiorgio Sartor
Simone Caldana wrote:
> cito dal tizio:
> > > Linux tecnologicamente e' solo un evoluzione di minix, roba di 20-30
> > > anni fa...
>
> non vuol mica dire che sia sbagliato.
Non dico che sia sbagliato (che e` vecchio), dico solo:
"e allora?"
Cioe` dire che Unix ha quasi 30 anni cosa mi significa?
Che e` vecchio?
Che e` un ottimo concetto, dato che e` sopravvissuto fino adesso?
> io cmq per pulizia e flessibilita' preferisco i microkernel (ne
> progettabbi uno con 28 chiamate, se non ricordo male)
Come ho scritto in precedenza, il problema e` che le CPU
moderne ed antiche "amano" i kernel monolitici.
Finche` qualcuno non cambia idea, il kernel monolitico
resta il migliore, come prestazioni, si intende.
bye,
--
Piergiorgio Sartor
Lorenzo Allegrucci
<sar...@sony.de.REMOVE.THIS> wrote:
>> non vuol mica dire che sia sbagliato.
>
>Non dico che sia sbagliato (che e` vecchio), dico solo:
>
>"e allora?"
>
>Cioe` dire che Unix ha quasi 30 anni cosa mi significa?
>
>Che e` vecchio?
30 anni sono 30 anni, ma se li porta bene :-)
>Che e` un ottimo concetto, dato che e` sopravvissuto fino adesso?
Yep.
"Everything is a file or a process."
>> io cmq per pulizia e flessibilita' preferisco i microkernel (ne
>> progettabbi uno con 28 chiamate, se non ricordo male)
>
>Come ho scritto in precedenza, il problema e` che le CPU
>moderne ed antiche "amano" i kernel monolitici.
>
>Finche` qualcuno non cambia idea, il kernel monolitico
>resta il migliore, come prestazioni, si intende.
A me piace anche esteticamente..
KISS principle ;-)
Le cose semplici sono belle e durano, in genere.
--
Lorenzo
(address rot13 encoded)
Giambo
>> Gia', invece Win e' una evoluzione del Dos, che a sua volta e' uan
>> evoluzione del CP/M... roba moderna, nevvero?
>
>Win9X è morto.
Purtroppo si e' clonato in WinME.
>Win2000 è vivo.
Ho scoperto che e' molto sensibile all'Hardware: Dove la SuSE faceva
scintille, Win2K crepava miseramente. Win98 non si installava
neanche :-)
--
__
| _ "The Internet is slow, could you please reboot it ?"
|__|iambo mailto:gabr...@giambonini.com www.giambonini.com
Giambo
>> Ohibo`, solo con questa frase il trollometro logaritmico ha fatto
>> *puff* e la lancetta e` partita a duecento chilometri all'ora (me
>> l'ha rilevata la polizia stradale con l'autovelox).
>
>ha ragione, un kernel monolitico e' una idea vecchia come il cucco.
Il problema e' che "qualcuno" ha fatto un gran blah-blah a proposito
delle "innovazioni", e si e' radicata l'idea che un prodotto basato
su un'idea vecchia di qualche anno, e' obsoleto.
Renato 'Hitman' Salzano
schifo che mi circonda e come la cosidetta societa` civile sia basata
sull'ipocrisia e dominazione, Xelloss interruppe il corso dei miei
pensieri bofonchiando:
>> Gia', invece Win e' una evoluzione del Dos, che a sua volta e' uan
>> evoluzione del CP/M... roba moderna, nevvero?
> Win9X è morto.
Rimane da convincere la MS di questo.
--
Renato "Hitman" Salzano - http://spazioweb.inwind.it/hitman/
e-posta : sonicblast (at) inwind.it / Xena:TWP fan
Webdesigner / indegno sysadmin di www.italservicesnc.it
Powered by Debian 2.x (Woody) on a K6/2 box - 100% Wintel free
thorin_...@durin.khazad-dum.net
>> Gia', invece Win e' una evoluzione del Dos, che a sua volta e' uan
>> evoluzione del CP/M... roba moderna, nevvero?
> Win9X è morto.
> Win2000 è vivo. Evviva Win2000.
Ma si, celebriamo il nuovo cadavere !! Allelujah !
Balu - Marco Verdecchia
> Salve
> linux non e' in crescita del 250% nelle grandi realta' aziendali
> (specialmente in Italia) ma nelle piccole (se non piccolissime) e negli
> utilizzatori casalinghi.
preciso nel segnalarci le fonti in cui hai letto simil dato. Aspetto con
ansia.
> Ti spiego anche il perche'.
> Entri a lavorare in una grande azienda. Trovi
> 8/10 uno Unix commerciale. Di questi almeno il 90%
> sono Sun con Solaris.
> A casa non sono in molti a poterselo permettere, e cosi', per
> continuare a fare "palestra" anche a casa, installi linux. Solo
Errato. Solaris ha rilasciato il suo sistema operativo per piattaforma intel
gratuitamente. Oddio, proprio gratis no, nel senso che la puoi liberamente
usare soltanto per scopi non commerciali. Se vuoi una "palestra" solaris a
casa ti installi solaris, non linux. Evidentemente chi installa linux lo fa
per altri motivi. (PS, per quei 8/10 sono convinto che la fonte sia la
stessa del 250% precedente vero? Allora aspetto la segnalazione della tua
fonte.)
> perche' e' gratis.
GNU/Linux e tutto il software GPL e' libero, non gratis. Prima di riempirti
la bocca, almeno leggile le licenze software. Grazie.
> Non te ne fotte della filosofia che ci sta dietro.
a te che non leggi le licenze si. A me no. GPL/BSD/X/LGPL non sono la stessa
cosa.
> Tanto e' vero che molti di quelli che USANO linux, e non chi ci
> giocarella, sono professionisti che fanno consulenze su unix o lavorano
> su unix o fanno assistenza su HW/Soft Unix.
Beh se e' vero o non e' vero non lo so . Io cmq sono uno studente di
informatica e conosco diversi amici che lo usano per hobby. E ti dico che a
me i video giochi su pc, per principio non ce li metto (uso la playstation).
> Seconda questione: il codice del kernel.
> Se quello MS fosse open, ti accorgeresti di quanto e' diverso da quello
> di linux, magari con alcune parti che assomigliano a BSD, non certo a
> linux.
lo hai visto per poterlo dire? Manzoni diceva...
dei "se" e dei "ma" son pien le fosse. Credo di piu' a quello che ha detto
Manzoni con questa frase che a te. Francamente mi sembri un po' ciarlatano o
chiaroveggente. Ma sono convinto che mi risponderai e mi darai tutte i
chiarimenti tecnici del caso.
> L'ho detto e lo ripetero' fino alla morte.
> Linux tecnologicamente e' solo un evoluzione di minix, roba di 20-30
> anni fa...
come l'homo sapiens. Soltanto una evoluzione della scimmia. Pero' come te la
spieghi il fatto che non ho mai e poi mai visto un crash del kernel? Eppure
di computer con linux ne ho visti parecchi, anche server collegati ad
internet 24 ore su 24 365 giorni su 365. Solo una volta ho avuto un timore
che si potesse essere verificato un crash e quando e' capitato mi ricordo
anche che ero soddisfatto, non vedevo l'ora di tornare all'universita' e
bearmi con i miei amici di come linux avesse effettuato un crash soltanto
dopo 6 mesi (abituati a quelli frequenti di NT). Peccato. Scoprii che
durante la notte al dipartimento era andata via la corrente e noi non avevamo
nessun UPS.
> Oggi l'informatica va in altre direzioni, e linux dimostra di non
quali direzioni. Spiegacele.
> essere piu' una piattaforma di sperimentazione, ma si sta mano mano
Linux e' come il jazz. Ideato dalla commistione di culture in America agli
inizi del Novecento ha dimostrato di evolversi a tal punto da diventare una
musica mondiale, senza fini. (hai mai sentito parlare di fusion?). E lo sai
qual e' il bello? Che la sua espansione non e' ancora finita. Un cosmo che
genera ad ogni stagione costellazioni ed infiti spazi.
Linux e' proprio come il jazz.
> piegando alle esigenze commerciali dei suoi utilizzatori, che vogliono
> firewire, allora gli si da, aggiungendo righe di schifezze nel
> kernel...
il kernel di linux e' costruito in modo da essere altamente modulare. E poi non
vedo proprio come sia possibile inserirci delle schifezze dentro visto che
e' pubblico e puo' essere visto da tutti. E' come se andassi a mangiare la
pizza in un locale ed il pizzaiolo me la fa davanti agli occhi. che fa, se
ci sputa dentro che dici non me ne accorgo?
>
> Molto meglio la scelta di Debian di supportare HURD, un microkernel
> molto buono, tecnologicamente all'avanguardia e dal futuro certamente
> piu' roseo del kernel di linux attuale.
>
HURD infatti e' una sfida. Non so cosa sara' e come sara', ma per il momento
nessun microkernel si e' dimostrato essere migliore. Forse saranno il
futuro, ma e' ancora troppo remoto. E poi Debian supporta linux. Un motivo
ci sara' che dici?
> Morale? VIVA MICROSOFT
Vuoi sapere la mia di morale? Viva la mozza. E' per questo che uso linux,
che cosa credevi?
--
\|||/
---------------------------oOOo--@ @--oOOo----------------------------
Marco Verdecchia <ba...@ELIMINAMI.katamail.com>
togli ELIMINAMI per potermi rispondere in email
Balu - Marco Verdecchia
>
>
> Elle wrote:
> >
> > Scusate, le opinioni sono libere, ma sento odore di TROLL.....
>
> Sempre con 'sta azzo di storia che se uno la pensa in maniera diversa in
il pensiero e' libero. Ma anche la democrazia ha bisogno di regole. Prima di
tutto, il rispetto per gli altri.
> Scatena il flame dici? Saresti tu a cascarci, non io. ... e poi dilla la
> verita', ti piacerebbe corrergli dietro ad instularlo: ammettilo.
l'ironia credo che sia una arma piu' efficace.
> Ognuno deve essere libero di esprimere la propria opinione in qualsiasi
> contesto, senza essere offensivo, ma con i mezzi che ritiene più
> opportuni.
>
prima di tutto, il rispetto. In un post che si parla di linux, si cita BSD,
HURD, Debian senza lasciare il minimo dubbio che questa persona manco abbia
una certa esperienza di utilizzo con questi mezzi per poi alla fine dire
VIVA Microsoft sulla base di che cosa poi. E poi come si fa a dire che un
sistema e' meglio di un altro se manco lo si e' provato?
> Questa è la mia opinione. Sono pure io un troll?
questa e' la mia di opinione.
Ginopilotino
gia...@no.spam.please says...
> On Tue, 15 May 2001 14:52:13 +0200, Xelloss wrote:
>
> >> Gia', invece Win e' una evoluzione del Dos, che a sua volta e' uan
> >> evoluzione del CP/M... roba moderna, nevvero?
> >
> >Win9X è morto.
>
> Purtroppo si e' clonato in WinME.
>
> >Win2000 è vivo.
>
> Ho scoperto che e' molto sensibile all'Hardware: Dove la SuSE faceva
> scintille, Win2K crepava miseramente. Win98 non si installava
> neanche :-)
Sentiamo un po' che hw ...
Ho istallato win2k su hw da schifo e tutto e' andato liscio.
Ciao ... Dino
Emmanuele Bassi (Zefram)
>> > Linux tecnologicamente e' solo un evoluzione di minix, roba di 20-30
>> > anni fa...
> ha ragione, un kernel monolitico e' una idea vecchia come il cucco.
Non su questo discutevo: il tono era per dire "Ohe`, guardate questo
s.o. scopiazzato da un concetto vecchio di trent'anni, e da un altro
software scritto da un professore universitario". Insomma: sono solo
chiacchere e distintivo.
Leonardo Serni
>Seconda questione: il codice del kernel.
>Se quello MS fosse open, ti accorgeresti di quanto e' diverso da quello
>di linux, magari con alcune parti che assomigliano a BSD, non certo a
>linux.
[...]
>Morale? VIVA MICROSOFT
Insomma, siccome bionda la figa aggratisse 'un ti garba, preferisci
pagare per acciuffarlo nel tabarčn.
Oh, per carita', tutti i gusti sono gusti, come diceva 'r mi' gatto
durante la toeletta.
Leonardo
--
Microsoft Outlook: il primo news reader con supporto messaggistica RAID 1.
Leonardo Serni
Bassi (Zefram)) wrote:
>Noi non si ha un laser di controllo mentale orbitale, pero` se qualcuno
>dice qualcosa deve anche essere pronto a difenderla
Mmm... ASR?
Sensei
> Salve
Ciao.
> linux non e' in crescita del 250% nelle grandi realta' aziendali
> (specialmente in Italia) ma nelle piccole (se non piccolissime) e negli
> utilizzatori casalinghi.
Vero. C'è moltissima attenzione per linux. Se l'hai usato _bene_ puoi anche
capire perchè. Se hai studiato l'architettura unix (anche linux) poi...
> Di questi almeno il 90% sono Sun con Solaris.
Mmmh...
> A casa non sono in molti a poterselo permettere, e cosi', per continuare a
> fare "palestra" anche a casa, installi linux. Solo perche' e' gratis.
*Solo*??
> Non te ne fotte della filosofia che ci sta dietro. Tanto e' vero che molti
> di quelli che USANO linux, e non chi ci giocarella, sono professionisti
> che fanno consulenze su unix o lavorano su unix o fanno assistenza su
> HW/Soft Unix.
Filosofia? Che vuol dire? Sai, molti amici miei si stanno avvicinando a
linux proprio per la sua filosofia. Dato che è open source, cosa che alla MS
non comprendono, dato che pensano che "OpenSource" sia la traduzione
dall'aramaico del tempo di Isaia del demonio :), affascina molti: poter
vedere come il tuo OS lavora fin nelle viscere è una cosa entusiasmante.
Poter ricompilarlo per la *tua* macchina è ancora più entusiasmante. Certo è
che non è per tutti linux. E non è detto che lo debba necessariamente
essere: se vuoi giocare, usa windoz (e non ti lamentare dei crash), se vuoi
lavorare tranquillo, puoi usare linux... anche se ad es. con le ultime GUI
non direi che sia tanto un bisonte americano: linux sta diventando anche
bellino da vedere (vedi KDE 2.1, che ha anche la gestione del lilo, cosa che
a me *frega*, ma a chi lo vede da poco può risultare utile)
> Seconda questione: il codice del kernel. Se quello MS fosse open, ti
]:> già, se lo fosse... ma la paura li attanaglia.
> accorgeresti di quanto e' diverso da quello di linux, magari con alcune
> parti che assomigliano a BSD, non certo a linux.
Ah, allora abbiamo 2 opzioni:
1) Sei uno sviluppatore degli OS della MS.
2) Sei un veggente che riesci a leggere cose che non si possono vedere:
l'hai detto tu che non è possibile vedere i codici MS.
Te ccome la vedi? ... La seconda che hai detto.
> fino alla morte. Linux tecnologicamente e' solo un evoluzione di minix,
> roba di 20-30 anni fa... Oggi l'informatica va in altre direzioni, e
Già... va in altre direzioni, hai ragione. E' l'IBM che è cretina... è
vecchio linux, tanto vecchio da essere il più moderno.
> dimostra di non essere piu' una piattaforma di sperimentazione, ma si sta
> mano mano piegando alle esigenze commerciali dei suoi utilizzatori, che
> vogliono firewire, allora gli si da, aggiungendo righe di schifezze nel
> kernel...
Che, naturalmente, tu che non hai un firewire non compili. Poi, che siano
schifezze è tutto da dimostrarsi.
> Molto meglio la scelta di Debian di supportare HURD, un microkernel molto
> buono, tecnologicamente all'avanguardia e dal futuro certamente piu' roseo
> del kernel di linux attuale.
HURD è un grandioso progetto. Un microkernel si avvicina molto a quello che
hanno fatto con BSD e sarebbe una bella cosa... tu che hai letto i codici di
windows, dimmi, è modulare il kernel di windoz? è un microkernel? come lo
ricompili?
> Morale? VIVA MICROSOFT
Morale? Gallina vecchia muore prima. Mah... le scelte sono scelte: come
disse il mio professore di controlli: Se voi volete chiudere il loop e
controllare la vostra centrale nucleare con windows, beh, fatemelo sapere,
che mi trasferisco lontano... (e non è uno scherzo)
--
Sensei <sens...@crosswinds.net>
MS Outlook : (noun) A newsreader with support for RAID 0.
MS Works : (noun) An oxymoron.
thorin_...@gruppocm-cs.it
> On Mon, 14 May 2001 13:53:26 +0000, "JiuSDYC" <x...@xxx.xxx> wrote:
>> Salve
> Ciao.
>> linux non e' in crescita del 250% nelle grandi realta' aziendali
>> (specialmente in Italia) ma nelle piccole (se non piccolissime) e negli
>> utilizzatori casalinghi.
> Vero. C'č moltissima attenzione per linux. Se l'hai usato _bene_ puoi anche
> capire perchč. Se hai studiato l'architettura unix (anche linux) poi...
Ma perche' anche tu sprechi banda rispondendo a questo troll idiota?
Killalo e basta.
Piergiorgio Sartor
Lorenzo Allegrucci wrote:
> 30 anni sono 30 anni, ma se li porta bene :-)
Direi ottimamente, dato che tiene il passo dei
giovinastri di oggi :-)
> >Finche` qualcuno non cambia idea, il kernel monolitico
> >resta il migliore, come prestazioni, si intende.
>
> A me piace anche esteticamente..
> KISS principle ;-)
>
> Le cose semplici sono belle e durano, in genere.
In questo senso un uK e` ancora piu` "KISS".
Semplice ed elegante, sicuramente.
Il problema e` che la semplicita` concettuale, mal
si sposa con l'implementazione effettiva su CPU
concepite, di fatto, per kernel monolitici.
O meglio: una CPU "KISS" preferisce kernel monolitici :-)
Io personalmente sono un fan dei uK e sono alquanto
"seccato" con i produttori di CPU che non implementano
le caratteristiche necessarie per poter far andare uK
in maniera decente.
bye,
--
Piergiorgio Sartor
Simone Caldana
>
> On Tue, 15 May 2001 09:06:07 +0200, Simone Caldana wrote:
>
> >> Ohibo`, solo con questa frase il trollometro logaritmico ha fatto
> >> *puff* e la lancetta e` partita a duecento chilometri all'ora (me
> >> l'ha rilevata la polizia stradale con l'autovelox).
> >
> >ha ragione, un kernel monolitico e' una idea vecchia come il cucco.
>
> Il problema e' che "qualcuno" ha fatto un gran blah-blah a proposito
> delle "innovazioni", e si e' radicata l'idea che un prodotto basato
> su un'idea vecchia di qualche anno, e' obsoleto.
mai detto questo
Lorenzo Allegrucci
<sar...@sony.de.REMOVE.THIS> wrote:
>Il problema e` che la semplicita` concettuale, mal
>si sposa con l'implementazione effettiva su CPU
>concepite, di fatto, per kernel monolitici.
>
>O meglio: una CPU "KISS" preferisce kernel monolitici :-)
>
>Io personalmente sono un fan dei uK e sono alquanto
>"seccato" con i produttori di CPU che non implementano
>le caratteristiche necessarie per poter far andare uK
>in maniera decente.
Che particolari caratteristiche dovrebbero avere?
Balrog
>Morale? VIVA MICROSOFT
AUE AUE ALLARME ANTI TROLL ATTIVO
AUE AUE ALLARME...
--
Balrog ):E...
Piergiorgio Sartor
Lorenzo Allegrucci wrote:
[CPU per uK]
> Che particolari caratteristiche dovrebbero avere?
Il problema e` che nei uK si hanno molti passaggi da user
mode a superuser mode, molti piu` che in un kernel monolitico.
Questo puo` essere visto come un numero maggiore di interrupt
che la CPU deve sopportare.
Uno dei problemi e` il salvataggio dello stato della CPU,
di solito sullo stack superuser.
Alcune CPU hanno introdotto il concetto di shadow (mi pare)
register. Praticamente lo stato della CPU e` mantenuto in
due set separati di registri che vengono attivati a seconda
della condizione in cui si entra.
Cioe` non appena arriva un interrupt (fisico o virtuale, tale
da far passare la CPU da user a superuser mode), un altro
set di registri viene reso disponibile ed il precedente
viene "nascosto".
In questo modo il tempo di risposta e` realmente basso,
condentendo di risolvere un elevato numero di interrupt
al secondo.
Se non erro si arriva ad un tempo di risposta sotto il
microsecondo, cioe` un milione di interrupt al secondo
possono essere serviti (con tempo di servizio zero, ovviamente),
su CPU relativamente lente (sotto i 100 MHz).
Nel caso di uK questo e` estremamente vantaqggioso, dato
che devono essere serviti in maniera piu` semplice (cioe`
molto piu` velocemente) molti piu` interrupt.
Vi sono altre "feature" utili, come ad es. un HW supported
process communication, cioe` un set di registri (puo` essere
tipo FIFO), che consentono di scambiare dati (di solito
semplici puntatori) tra processi senza dover passare alla
riconversione degli indirizzi (virtuale->fisico->virtuale)
usando la MMU (cioe` viene fatta una rimappatura automatica).
Il che migliora ancora le prestazioni riducendo le operazioni
necessarie alla rimappatura degli indirizzi (cosa valida anche
per un kernel monolitico).
In parole povere vi sono alcune feature che servono a ridurre
i tempi di latenza dei passaggi di stato, supportando alcune
necessita` in HW (altro esempio sono i semafori gestiti in HW).
Il punto piu` importante e` comunque il primo, cioe` gli shadow
register.
bye,
--
Piergiorgio Sartor
Piergiorgio Sartor
Piergiorgio Sartor wrote:
>
BTW, vi e` anche un'altra feature interessate, che non
ha molto a che vedere con i uK, ma e` divertenete lo stesso.
Vi e` (almeno) una CPU in grado di generare un interrupt
in caso di cache miss e di decidere, a quel punto, che
pezzo di codice caricare.
In parole povere in parallelo al caricamento della cache
viene effettuato un task switch, i modo da ridurre i
tempi morti...
bye,
--
Piergiorgio Sartor
Lorenzo Malaguti
> Poter ricompilarlo per la *tua* macchina è ancora più entusiasmante. Certo
è
> che non è per tutti linux.
primo: al 99.99% delle persone gli importa sega di ricompilare il kernel.
> E non è detto che lo debba necessariamente
> essere: se vuoi giocare, usa windoz (e non ti lamentare dei crash), se
vuoi
> lavorare tranquillo, puoi usare linux...
questo e' un dogma linuxiano.
se vuoi giocare -> windows
se vuoi lavorare -> linux
per favore, alziamo il livello della discussione, grazie.
Se windows e' montato su una macchina con driver non bacati va che e' una
meraviglia e non si inchioda neanche a morire.
(ovviamente parlo di w2k)
> > Seconda questione: il codice del kernel. Se quello MS fosse open, ti
> ]:> già, se lo fosse... ma la paura li attanaglia.
infatti e' gia' stato reso pubblico per le grandi aziende e per le
universita'.
> Ah, allora abbiamo 2 opzioni:
>
> 1) Sei uno sviluppatore degli OS della MS.
>
> 2) Sei un veggente che riesci a leggere cose che non si possono vedere:
> l'hai detto tu che non è possibile vedere i codici MS.
Chi programma veramente non ha neanche bisogno dei sorgenti per capire come
funziona un programma
spesso un debugger basta e avanza.
>
> Già... va in altre direzioni, hai ragione. E' l'IBM che è cretina... è
> vecchio linux, tanto vecchio da essere il più moderno.
che IBM sia cretina non ci piove, visto che avevano OS/2 e l'hanno fatto
marcire.
e ancora li maledico.
>
> Che, naturalmente, tu che non hai un firewire non compili. Poi, che siano
> schifezze è tutto da dimostrarsi.
quando gli utenti avranno bisogno di utilizzare piu' a fondo l'integrazione
fra i vari pacchetti allora ne vedremo delle belle.
>
> Morale? Gallina vecchia muore prima. Mah... le scelte sono scelte: come
> disse il mio professore di controlli: Se voi volete chiudere il loop e
> controllare la vostra centrale nucleare con windows, beh, fatemelo sapere,
> che mi trasferisco lontano... (e non è uno scherzo)
stessa cosa che controllarlo con Linux.
Lorenzo Malaguti
> dopo 6 mesi (abituati a quelli frequenti di NT). Peccato. Scoprii che
> durante la notte al dipartimento era andata via la corrente e noi non
avevamo
> nessun UPS.
server senza nessun UPS?
GENIALE!!!!
chi e' il sysadmin? Paperino? o Pluto?
> Linux e' come il jazz. Ideato dalla commistione di culture in America agli
> inizi del Novecento ha dimostrato di evolversi a tal punto da diventare
una
> musica mondiale, senza fini. (hai mai sentito parlare di fusion?). E lo
sai
> qual e' il bello? Che la sua espansione non e' ancora finita. Un cosmo che
> genera ad ogni stagione costellazioni ed infiti spazi.
> Linux e' proprio come il jazz.
'azzo, devo venire alla vostra universita', mi sembra che si fumi roba buona
da quelle parti... :-)
Cosmo?
Infiniti spazi?
Dico, stiamo scherzando vero?
> il kernel di linux e' costruito in modo da essere altamente modulare. E
poi non
> vedo proprio come sia possibile inserirci delle schifezze dentro visto che
> e' pubblico e puo' essere visto da tutti. E' come se andassi a mangiare la
> pizza in un locale ed il pizzaiolo me la fa davanti agli occhi. che fa, se
> ci sputa dentro che dici non me ne accorgo?
vuoi vedere del codice aperto che non capisci neanche se ti ci metti un
mese?
Valter Minute
<9du7fk$2vd$1...@fe1.cs.interbusiness.it>:
[...]
>
>> Ah, allora abbiamo 2 opzioni:
>>
>> 1) Sei uno sviluppatore degli OS della MS.
>>
>> 2) Sei un veggente che riesci a leggere cose che non si possono
>> vedere:
>> l'hai detto tu che non è possibile vedere i codici MS.
>
>Chi programma veramente non ha neanche bisogno dei sorgenti per capire
>come funziona un programma
>spesso un debugger basta e avanza.
>
Io programmo veramente (o forse mi pagano per programmare per finta?) e
posso affermare che per capire come funziona un programma dovrebbe bastare
della buona documentazione (e quindi il debugger avanza).
Ti grantisco però che per capire perchè non-funziona un programma è 1000
volte meglio avere a disposizione i sorgenti.
E, se manca la documentazione, il reverse-engineering a colpi di debugger
può essere divertente, ma non è molto "produttivo".
--
Valter Minute
min...@inwind.it (the reply address of this message is invalid)
Matteo Merli
> Io programmo veramente (o forse mi pagano per programmare per finta?) e
> posso affermare che per capire come funziona un programma dovrebbe bastare
> della buona documentazione (e quindi il debugger avanza).
> Ti grantisco però che per capire perchè non-funziona un programma è 1000
> volte meglio avere a disposizione i sorgenti.
> E, se manca la documentazione, il reverse-engineering a colpi di debugger
> può essere divertente, ma non è molto "produttivo".
ma poi... il reverse-engeneering su Windows intero!?!?!!!!!
..capisco su un file di 10k.. :)
per windows credo che anche con i sorgenti, senza documentazione *nessuno*
riesca a capirci dentro niente...
probabilmente neanche quelli che hanno scritto il codice :P
Matteo Merli
sr
>Salve
>linux non e' in crescita del 250% nelle grandi realta' aziendali
>(specialmente in Italia) ma nelle piccole (se non piccolissime) e negli
>utilizzatori casalinghi.
Esiste solo un rimedio contro il FUD, i fatti.
www.borland.com/linux
www.compaq.com/linux
www.dell.com/linux
www.hp.com/linux
www.ibm.com/linux
www.informix.com/linux
www.oracle.com/linux
www.sap.com/linux
--
sr - null...@PAMflashnet.it <strip NOS & PAM to email>
Lorenzo Allegrucci
<sar...@sony.de.REMOVE.THIS> wrote:
>[CPU per uK]
>> Che particolari caratteristiche dovrebbero avere?
>
>Il problema e` che nei uK si hanno molti passaggi da user
>mode a superuser mode, molti piu` che in un kernel monolitico.
>
>Questo puo` essere visto come un numero maggiore di interrupt
>che la CPU deve sopportare.
>
>Uno dei problemi e` il salvataggio dello stato della CPU,
>di solito sullo stack superuser.
>
>Alcune CPU hanno introdotto il concetto di shadow (mi pare)
>register. Praticamente lo stato della CPU e` mantenuto in
>due set separati di registri che vengono attivati a seconda
>della condizione in cui si entra.
>Cioe` non appena arriva un interrupt (fisico o virtuale, tale
>da far passare la CPU da user a superuser mode), un altro
>set di registri viene reso disponibile ed il precedente
>viene "nascosto".
Mi pare che attualmente solo IA-64 lo supporti in qualche modo.
Intel lo chiama "register spilling".
>In questo modo il tempo di risposta e` realmente basso,
>condentendo di risolvere un elevato numero di interrupt
>al secondo.
>Se non erro si arriva ad un tempo di risposta sotto il
>microsecondo, cioe` un milione di interrupt al secondo
>possono essere serviti (con tempo di servizio zero, ovviamente),
>su CPU relativamente lente (sotto i 100 MHz).
>
>Nel caso di uK questo e` estremamente vantaqggioso, dato
>che devono essere serviti in maniera piu` semplice (cioe`
>molto piu` velocemente) molti piu` interrupt.
>
>Vi sono altre "feature" utili, come ad es. un HW supported
>process communication, cioe` un set di registri (puo` essere
>tipo FIFO), che consentono di scambiare dati (di solito
>semplici puntatori) tra processi senza dover passare alla
>riconversione degli indirizzi (virtuale->fisico->virtuale)
>usando la MMU (cioe` viene fatta una rimappatura automatica).
>Il che migliora ancora le prestazioni riducendo le operazioni
>necessarie alla rimappatura degli indirizzi (cosa valida anche
>per un kernel monolitico).
La traduzione degli indirizzi e' costosa, non c'e' niente da fare.
E' possibile diminuirne la latenza con i TLB (Translation Lookaside
Buffer), una cache piu' o meno associativa di coppie:
[<virtual address> <physical address>], ma come vedremo piu' avanti ci
sono altre latenze che dominano.
Il context switch tra i processi server dei uK e' praticamente lo
stesso di due processi normali, ossia riesci a sfruttare i TLB
se sono gia' stati caricati, ovviamente, altrimenti il processore deve
andarsi a "sciroppare" le page tables con almeno due livelli (x86,
Alpha, M68K) o calcolare una funzione hash (PowerPC, PA-RISC).
In entrambi i casi hai un'alta probabilita' di "inquinare" le cache
(dati e istruzioni) del processore con ulteriori ritardi.
E' fatto del tutto naturale ed inevitabile. Se da una parte la localita'
del codice gioca(va) a nostro favore, nel momento in cui la rompiamo con
un context switch paghiamo un prezzo alto..
Questo nell'ipotesi ottimistica che l'architettura supporti i TLB nella
forma: [<pid, virtual address> <physical address>], cioe' dei TLB che
valgono *globalmente*, diminuendo il trashing.
Non tutte le architetture hanno questa "feature" e tra quelle che non
ce l'hanno c'e' x86.. ok x86 non fa testo :-)
In ogni caso, la latenza del context switch e' intrinsecamente alta
perche' e' dominata dalla localita' nelle cache dei due processi che si
stanno alternando in quel momento, e sappiamo quanto conti la cache nei
processori costruiti negli ultimi 10 anni.
A dimostrazione di cio' puoi far girare il micro-benchmark lmbench di
Larry McVoy. I tempi dei context switch sono estremamente variabili
al variare del numero e della dimensione del codice dei processi.
Per darti un'idea, sul mio Athlon 750 variano da 1 a circa 140
microsecondi. Sto ovviamente parlando di Linux, che e' uno dei SO piu'
agili in questi microbench :-)
Nota che questi sono comunque tempi calcolati in condizioni ottimali:
due processi (piccoli!) che si scambiano un token attraverso una pipe e
nel mezzo fanno qualche *piccolo* calcolo, senza nessun altro processo
che gira.
La realta' e' di solito molto meno "asettica" e si protebbe arrivare
anche a 500 microsecondi e oltre in certe condizioni di carico.
>In parole povere vi sono alcune feature che servono a ridurre
>i tempi di latenza dei passaggi di stato, supportando alcune
>necessita` in HW (altro esempio sono i semafori gestiti in HW).
>Il punto piu` importante e` comunque il primo, cioe` gli shadow
>register.
Sicuramente, ma come disse Linus circa 10 anni fa, queste stesse
ottimizzazioni valgono anche per i kernel monolitici :-)
Anche se in misura molto minore, ovviamente.
Lorenzo Allegrucci
<sar...@sony.de.REMOVE.THIS> wrote:
>BTW, vi e` anche un'altra feature interessate, che non
>ha molto a che vedere con i uK, ma e` divertenete lo stesso.
>
>Vi e` (almeno) una CPU in grado di generare un interrupt
>in caso di cache miss e di decidere, a quel punto, che
>pezzo di codice caricare.
>
>In parole povere in parallelo al caricamento della cache
>viene effettuato un task switch, i modo da ridurre i
>tempi morti...
Ma il task switch inquina la cache, non vedo come si possa farlo
in parallelo se non in condizioni molto particolari.
Balu - Marco Verdecchia
> > bearmi con i miei amici di come linux avesse effettuato un crash soltanto
> > dopo 6 mesi (abituati a quelli frequenti di NT). Peccato. Scoprii che
> > durante la notte al dipartimento era andata via la corrente e noi non
> avevamo
> > nessun UPS.
>
> server senza nessun UPS?
> GENIALE!!!!
> chi e' il sysadmin? Paperino? o Pluto?
sai quando c'e' un superiore chiamato docente che decide cosa comprare (anche
che cosa nascondere per se) rimane un po' difficile far comprare un UPS.
Comunque qualcosa sta cambiando e alla grande.
>
> > Linux e' come il jazz. Ideato dalla commistione di culture in America agli
> > inizi del Novecento ha dimostrato di evolversi a tal punto da diventare
> una
> > musica mondiale, senza fini. (hai mai sentito parlare di fusion?). E lo
> sai
> > qual e' il bello? Che la sua espansione non e' ancora finita. Un cosmo che
> > genera ad ogni stagione costellazioni ed infiti spazi.
> > Linux e' proprio come il jazz.
>
> 'azzo, devo venire alla vostra universita', mi sembra che si fumi roba buona
> da quelle parti... :-)
> Cosmo?
> Infiniti spazi?
> Dico, stiamo scherzando vero?
Si vede che quando programmo ascolto troppo Miles Davis?
Ma confermo la mia idea. Ci sono molti aspetti sociali del jazz e di come si
sia diffuso che sono simili a Linux. Prima di tutto...INFORMATIONS WANT TO
BE FREE (and public) e al fatto che il suo sviluppo pare andare avanti,
sempre avanti. Anche se il 2.4.x e' uscito da poco si inizia gia' a parlare
del 2.5.x. E poi se vuoi, puoi dire la tua. La licenza GPL ti incoraggia a
scrivere del software, condividerlo e spesso e volentieri capita che
esistono progetti simili sviluppati da diverse persone, alcune volte team.
KDE e GNOME, WindowMaker.
Linux e HURD.
Simil democrazia e polimorfismo oltre che al mondo GNU/Linux l'ho visto
soltanto nel jazz e piu' precisamente nel free jazz ove la parola liberta'
viene issata come unica regola.
Ed in fin dei conti del polimorfismo usato da Stourstrup e quello esplicato da
Polillo c'ho sempre visto delle analogie.
Piergiorgio Sartor
Lorenzo Allegrucci wrote:
> Ma il task switch inquina la cache, non vedo come si possa farlo
> in parallelo se non in condizioni molto particolari.
Perche` in caso di cache miss non viene caricato il "miss",
ma il nuovo task... In automatico.
Nella prima versione della CPU il problema (in realta` non e`
un problema), che se non avveniva un cache miss, non avveniva
neanche un task switch... :-)
bye,
--
Piergiorgio Sartor
thorin_...@gruppocm-cs.it
>>Salve
>>linux non e' in crescita del 250% nelle grandi realta' aziendali
>>(specialmente in Italia) ma nelle piccole (se non piccolissime) e negli
>>utilizzatori casalinghi.
> Esiste solo un rimedio contro il FUD, i fatti.
Questo non e' FUD, ma trolling di un cerebroleso, cosa ben differente,
per cui faresti meglio a killarlo e basta.
Piergiorgio Sartor
Lorenzo Allegrucci wrote:
> Mi pare che attualmente solo IA-64 lo supporti in qualche modo.
> Intel lo chiama "register spilling".
Anche altre CPU, non proprio cosi` general purpose.
Ad es. alcuni DSP per controllo, richiedono latenze
estremamente basse per gli interrupt ed applicano
questa tecnica.
> E' fatto del tutto naturale ed inevitabile. Se da una parte la localita'
> del codice gioca(va) a nostro favore, nel momento in cui la rompiamo con
> un context switch paghiamo un prezzo alto..
Infatti, quello che si cerca e` di cambiare l'HW in modo
da pagare un prezzo piu` basso in termini di prestazioni.
Nel caso particolare dei messaggi, il primo processo ha
disponibili tutti i dati. Nel momento in cui scrive
nel registro di comunicazione, la traduzione e` rapida
proprio perche` la MMU ha tutti i dati disponibili (in media).
Stesso discorso durante la lettura.
> Questo nell'ipotesi ottimistica che l'architettura supporti i TLB nella
> forma: [<pid, virtual address> <physical address>], cioe' dei TLB che
> valgono *globalmente*, diminuendo il trashing.
Ovviamente anche di piu`!
L'HW, come detto in precedenza, DEVE supportare il uK, in questo caso!
> Non tutte le architetture hanno questa "feature" e tra quelle che non
> ce l'hanno c'e' x86.. ok x86 non fa testo :-)
:-)
Motivo in piu`, probabilmente, per cui i uK non ci vanno troppo bene...
> In ogni caso, la latenza del context switch e' intrinsecamente alta
> perche' e' dominata dalla localita' nelle cache dei due processi che si
> stanno alternando in quel momento, e sappiamo quanto conti la cache nei
> processori costruiti negli ultimi 10 anni.
E dalla lunghezza del pipeline...
Riguardo la cache, alcune CPU (non i x86, mi pare) hanno la
possibilita` di "congelare" una parte della cache.
In questo modo il uK (che e` "micro" appunto) puo` stare
tutto o quasi (quello che conta) in cache. Riducendo ulteriormente
la latenza delle interruzioni.
In generale il concetto di shadow register puo` essere esteso
alla cache e pure al pipeline, portando, di fatto, ad avere
quasi due CPU in una.
> La realta' e' di solito molto meno "asettica" e si protebbe arrivare
> anche a 500 microsecondi e oltre in certe condizioni di carico.
Che non e` neanche male, direi :-)
Sarebbe interessante provare un P4 vs. un K7 a pari frequenza
(e forse pari cache).
Giusto per vedere che impatto ha il lungo pipeline del P4
> Sicuramente, ma come disse Linus circa 10 anni fa, queste stesse
> ottimizzazioni valgono anche per i kernel monolitici :-)
> Anche se in misura molto minore, ovviamente.
Certo, ma nel caso di uK si avrebbe anche una migliore
architettura SW!
bye,
--
Piergiorgio Sartor
Piergiorgio Sartor
Balu - Marco Verdecchia wrote:
-
> Linux e' come il jazz. Ideato dalla commistione di culture in America agli
> inizi del Novecento ha dimostrato di evolversi a tal punto da diventare una
> musica mondiale, senza fini. (hai mai sentito parlare di fusion?). E lo sai
Linux come Fusion Jazz?
Non mi pare proprio un bell'esempio...
bye,
--
Piergiorgio Sartor
Sensei
wrote:
> primo: al 99.99% delle persone gli importa sega di ricompilare il kernel.
Vero... forse. A chi non ne sa *nulla* e ha voluto imparare ad usare linux,
ha fatto una cosa saggia: ha letto AppuntiLinux ed ha imparato... e sai, una
ciliegia tira l'altra e si sono ritrovati proprio a ricompilare il kernel.
> questo e' un dogma linuxiano.
> se vuoi giocare -> windows
> se vuoi lavorare -> linux
>
> per favore, alziamo il livello della discussione, grazie. Se windows e'
> montato su una macchina con driver non bacati va che e' una meraviglia e
> non si inchioda neanche a morire. (ovviamente parlo di w2k)
Ok. Alziamo il livello? 1. Il paradigma "linuxiano" come lo chiami tu, è un
esempio tratto dalla mia vita: ad ingegneria informatica ramo software (non
robotica) chi pavoneggia le "meraviglie" di windows lo fa così: "ma con
linux i giochi non girano bene: vanno lenti, inoltre non se ne trovano
tanti". Il tuo paradigma ricontrollalo e vedrai che al 99.99% degli utenti
piace windows proprio per i giochi. 2. Non parlo di w2k, ma di 9x/Me che
fanno schifo (IMHO ed esperienza: Me ha piallato il kernel di un mio amico
perchè la partizione era piccola, e l'installazione non se n'era accorta...
ha continuato a scrivere oltre il limite della partizione windows). Inoltre
molte cose di w2k sono un po' troppo prese da *nix non trovi? (Fonte:
PCMagazine)
> infatti e' gia' stato reso pubblico per le grandi aziende e per le
> universita'.
A si? dove lo trovo?
> Chi programma veramente non ha neanche bisogno dei sorgenti per capire
> come funziona un programma
> spesso un debugger basta e avanza.
Ma tu di che programmi fai il debug? Hai mai fatto il debug di un eseguibile
di 1.5 Mb *senza* i sorgenti, cioè dall'asm puro?
> che IBM sia cretina non ci piove, visto che avevano OS/2 e l'hanno fatto
> marcire. e ancora li maledico.
Ti ricordi che OS/2 era un progetto MS/IBM e poi MS si è tirata indietro
annunciando Chicago?
> quando gli utenti avranno bisogno di utilizzare piu' a fondo
> l'integrazione fra i vari pacchetti allora ne vedremo delle belle.
Non ho capito cosa intendi.
> stessa cosa che controllarlo con Linux.
Non credo. Il mio prof. di automazione non è un cretino, anzi ci ha le
contropalle. Ma quello che ha detto è sacrosanto: un BSOD arreca danni,
linux, e qui non puoi dissentire, è molto più stabile. Certo, se hai fatto
un po' di controlli, sai che per controllare alcuni processi tramite
apparati elettronici servono degli OS real-time, servono controlli sui
sensori e risposte agli attuatori molto più piccole del ms, dell'ordine
magari dei microsecondi - quindi per PC preferirei Qnx al posto di linux
(che non è realtime).
Lorenzo Allegrucci
<sar...@sony.de.REMOVE.THIS> wrote:
>> Mi pare che attualmente solo IA-64 lo supporti in qualche modo.
>> Intel lo chiama "register spilling".
>
>Anche altre CPU, non proprio cosi` general purpose.
>Ad es. alcuni DSP per controllo, richiedono latenze
>estremamente basse per gli interrupt ed applicano
>questa tecnica.
Vedi piu' sotto.
>> E' fatto del tutto naturale ed inevitabile. Se da una parte la localita'
>> del codice gioca(va) a nostro favore, nel momento in cui la rompiamo con
>> un context switch paghiamo un prezzo alto..
>
>Infatti, quello che si cerca e` di cambiare l'HW in modo
>da pagare un prezzo piu` basso in termini di prestazioni.
>Nel caso particolare dei messaggi, il primo processo ha
>disponibili tutti i dati. Nel momento in cui scrive
>nel registro di comunicazione, la traduzione e` rapida
>proprio perche` la MMU ha tutti i dati disponibili (in media).
>Stesso discorso durante la lettura.
>
>> Questo nell'ipotesi ottimistica che l'architettura supporti i TLB nella
>> forma: [<pid, virtual address> <physical address>], cioe' dei TLB che
>> valgono *globalmente*, diminuendo il trashing.
>
>Ovviamente anche di piu`!
>L'HW, come detto in precedenza, DEVE supportare il uK, in questo caso!
>
>> Non tutte le architetture hanno questa "feature" e tra quelle che non
>> ce l'hanno c'e' x86.. ok x86 non fa testo :-)
>
>:-)
>Motivo in piu`, probabilmente, per cui i uK non ci vanno troppo bene...
Il punto e' che mentre si puo' migliorare con sofisticate tecniche hw,
un context switch tra due processi server di un uK sara' sempre molto
piu' lento di una semplice chiamata di funzione in un kernel monolitico.
Attualmente, la chiamata e' circa *tre* ordini di grandezza piu' veloce!
(A parita' di condizioni, con cache calda).
>> In ogni caso, la latenza del context switch e' intrinsecamente alta
>> perche' e' dominata dalla localita' nelle cache dei due processi che si
>> stanno alternando in quel momento, e sappiamo quanto conti la cache nei
>> processori costruiti negli ultimi 10 anni.
>
>E dalla lunghezza del pipeline...
Anche..
Come vedi, la costruzione delle CPU attuali e' ottimizzata per il
*throughput* e *non* per la latenza delle istruzioni.
D'altra parte se vuoi andare veloce e contenere i costi, questo devi
fare. Throughput e latenza insieme significa mettere piu' pipeline
in parallelo.. e moltiplicare i costi. E comunque otterresti un
risultato incerto, a causa delle dipendenze delle istruzioni.
>Riguardo la cache, alcune CPU (non i x86, mi pare) hanno la
>possibilita` di "congelare" una parte della cache.
>In questo modo il uK (che e` "micro" appunto) puo` stare
>tutto o quasi (quello che conta) in cache. Riducendo ulteriormente
>la latenza delle interruzioni.
Il problema a questo punto e' quale parte della cache congelare.
E' molto difficile se non impossibile saperlo con certezza.
La cache e' un meccanismo quasi del tutto trasparente a livello
di programmazione, nelle architetture che conosco.
Non nego che si possa fare, me lo trovo alquanto sofisticato.
>In generale il concetto di shadow register puo` essere esteso
>alla cache e pure al pipeline, portando, di fatto, ad avere
>quasi due CPU in una.
>
>> La realta' e' di solito molto meno "asettica" e si protebbe arrivare
>> anche a 500 microsecondi e oltre in certe condizioni di carico.
>
>Che non e` neanche male, direi :-)
>Sarebbe interessante provare un P4 vs. un K7 a pari frequenza
>(e forse pari cache).
>Giusto per vedere che impatto ha il lungo pipeline del P4
L'impatto si fa sentire, ma e' in parte compensato dal clock piu'
elevato. Solo in parte..
Il K7 resta come costruzione piu' "agile" anche del PIII, cioe' ha dei
tempi di latenza in genere minori.
Direi che tutto il discorso puo' essere condensato in questa semplice
considerazione: le CPU attuali ottimizzano il throughput a scapito
della latenza. Questa e' una scelta di progetto, non per fare un
dispetto ai fan dei uK, forse :-)
In passato (Era pre-pipeline e pre-cache) non era cosi' e i uK erano
meno svantaggiati dei monolitici.
Si potrebbe dire che mentre le prestazioni dei monolitici sono rimaste
pressoche' le stesse, quelle dei uK sono diminuite, o meglio il
*divario* tra i due approcci si e' allargato.
Chi sbaglia, i costruttori di CPU o i sostenitori dei uK?
Da parte mia penso che mentre ci sono delle "responsabilita'" dei
costruttori di CPU, ci sono anche dei limiti intrinseci alla messa in
pratica delle primitive di comunicazione dei uK.
Limiti che non possono essere superati, nel senso che una chiamata
sara' sempre piu' veloce che passare un messaggio tra due processi
in diversi spazi di indirizzamento.
>> Sicuramente, ma come disse Linus circa 10 anni fa, queste stesse
>> ottimizzazioni valgono anche per i kernel monolitici :-)
>> Anche se in misura molto minore, ovviamente.
>
>Certo, ma nel caso di uK si avrebbe anche una migliore
>architettura SW!
Su questo punto si sono scatenate le guerre sante dei SO degli ultimi
15-20 anni :-)
Mi ci butto anch'io..
Non sono del tutto convinto della migliore architettura sw.
In particolare, l'utilita' di avere i processi server ognuno nel suo
spazio d'indirizzamento.
Voglio dire, l'isolamento dei processi e' utilissimo (anzi,
indispensabile) in user space, per le applicazioni, perche' per loro
natura sono inaffidabili. Un kernel o un processo server di un uK
si *presume* che sia affidabile, perche' si deve pur partire da una base
solida! Attenzione, ho detto "presume" :-)
Si puo' dire: i uK hanno il vantaggio che se va in crash il server VM
questo puo' (in teoria) essere riavviato e tutto ritorna a posto mentre
se succede la stessa cosa in un monolitico si tira giu' tutto il
sistema.
Ora, io non ho una grande esperienza con i uK ma immagino che se succede
una cosa simile i risultati dovrebbero essere catastrofici in entrambi i
casi. (Vado a intuito, potrebbero sfuggirmi dei particolari importanti)
Dopotutto i processi server svolgono sempre funzioni *critiche* al
corretto funzionamento del sistema. La loro unica differenza con le
funzioni nei monolitici e' che portano le suddette funzioni in user
space. Se il VM va in crash non avro' piu' la gestione della memoria e
senza di essa non posso avviare altri processi. Non posso nemmemo fare
un flush della buffer cache..
Se va in crash il server VFS non ho piu' l'interfaccia virtuale con
i filesystem e perdo l'uso dei dischi sia locali che di rete.
Modularita'.
I kernel monolitici hanno i kernel threads.
I kernel threads sono visibili in user space come processi normali e
agiscono come processi normali tranne che hanno il loro spazio
d'indirizzamento in comune e coincidente con quello del kernel.
Per il resto, la semantica e' la stessa. Esempio:
posso fare 'kill -STOP kupdate' e sospendere il flush della buffer cache
su disco, per poi fare 'kill -CONT kupdate' per continuare.
Modularita' 2.
I kernel monolitici hanno anche i moduli kernel caricabili
dinamicamente. In linea di principio sarebbe possibile avere scheduler
multipli, VM multipli etc. Ogni modulo puo' agire come una sorta di
plug-in. Nel caso dei scheduler multipli so che c'e' una patch in giro.
Ovviamente nei moduli kernel posso creare altri kernel threads, cambiare
al volo una syscall, ridirezionarla, sostituirla, eliminarla etc.
Insomma, non vedo vantaggi netti dei uK sotto questi punti di vista,
percio' a parita' di condizioni prendo il rasoio di Occam e taglio via
la complessita' inutile, rimanendo con un monolitico :-)
Lorenzo Malaguti
un
> esempio tratto dalla mia vita: ad ingegneria informatica ramo software
(non
> robotica) chi pavoneggia le "meraviglie" di windows lo fa così: "ma con
> linux i giochi non girano bene: vanno lenti, inoltre non se ne trovano
> tanti". Il tuo paradigma ricontrollalo e vedrai che al 99.99% degli utenti
> piace windows proprio per i giochi.
Onestamente e senza prenderla come offesa o attacco personale.
MACCHISSENEFREGA di chi gioca con windows.
Chi gioca usa 98/me, faccia pure, importa sega.
Io parlo di W2K in ambito commerciale/industriale/sviluppo, che e' altra ben
diversa cosa.
> 2. Non parlo di w2k, ma di 9x/Me che
> fanno schifo (IMHO ed esperienza: Me ha piallato il kernel di un mio amico
> perchè la partizione era piccola, e l'installazione non se n'era
accorta...
> ha continuato a scrivere oltre il limite della partizione windows).
Inoltre
> molte cose di w2k sono un po' troppo prese da *nix non trovi? (Fonte:
> PCMagazine)
??? e con cio'? cosa hai dimostrato???
Quasi tutto ha una derivazione *nix, non vedo problemi.
>
> > infatti e' gia' stato reso pubblico per le grandi aziende e per le
> > universita'.
>
> A si? dove lo trovo?
in quelle precedentemente citate, grandi aziende e universita'.
Firmi un accordo e ti ritroverai circa 35 milioni di righe di codice.
Poi passi una vita a decifrarlo :-)
> > Chi programma veramente non ha neanche bisogno dei sorgenti per capire
> > come funziona un programma
> > spesso un debugger basta e avanza.
>
> Ma tu di che programmi fai il debug? Hai mai fatto il debug di un
eseguibile
> di 1.5 Mb *senza* i sorgenti, cioè dall'asm puro?
ho parlato di asm puro?
di debugger ne esistono di diversi tipi, alcuni anche molto 'simpatici' e
che permettono di vedere cose che altrimenti non si vedono.
poi se vuoi ti puoi guardare l'asm puro, perche' no...
>
> > che IBM sia cretina non ci piove, visto che avevano OS/2 e l'hanno fatto
> > marcire. e ancora li maledico.
>
> Ti ricordi che OS/2 era un progetto MS/IBM e poi MS si è tirata indietro
> annunciando Chicago?
no, calma e gesso.
OS/2 era un progetto MS/IBM e inizialmente avevano lo stesso Kernel, poi MS
e IBM si sono divise per cazzi loro (non mi ricordo, sono passati circa 6
anni direi) e lo sviluppo e' stato separato, tranne, in un momento iniziale,
la possibilita' da parte di IBM di poter incorporare in OS/2 l'accesso ai
programmi win31.
Poi IBM con una strategia di marketing degna di un cerebroleso, ha decretato
la morte di OS/2, che ora trovi solo in alcune grandissime aziende (che IBM
cura personalmente) o in alcuni enti (che IBM cura personalmente).
IBM ha fatto veramente ridere come strategia di impresa con OS/2 ed e'
veramente un peccato perche' OS/2 era meraviglioso.
> > quando gli utenti avranno bisogno di utilizzare piu' a fondo
> > l'integrazione fra i vari pacchetti allora ne vedremo delle belle.
> Non ho capito cosa intendi.
che il livello di integrazione fra servizi e applicazioni credo sia ancora
piuttosto blando sotto linux.
quando avra' piu' diffusione la gente chiedera' di piu', senza tante
ricompilazioni, e il problema si presentara' anche sotto linux.
>
> > stessa cosa che controllarlo con Linux.
>
> Non credo. Il mio prof. di automazione non è un cretino, anzi ci ha le
> contropalle.
non ne dubito
> Ma quello che ha detto è sacrosanto: un BSOD arreca danni,
certo
> linux, e qui non puoi dissentire, è molto più stabile.
ti posso garantire che ho schiantato diverse distribuzioni di linux piu'
volte.
con linux (anche se la situazione migliora di volta in volta) hai un
limitato set di hardware, e io ne uso di particolari, spesso e volentieri.
Talvolta non mi ha riconosciuto i bipro, altre volte si e' schiantato con la
scsi, altre volte con la rete...
per pieta' non dirmi che non so configurare.
19 anni di computer qualcosa mi avranno insegnato no?
>Certo, se hai fatto
> un po' di controlli, sai che per controllare alcuni processi tramite
> apparati elettronici servono degli OS real-time, servono controlli sui
> sensori e risposte agli attuatori molto più piccole del ms, dell'ordine
> magari dei microsecondi - quindi per PC preferirei Qnx al posto di linux
> (che non è realtime).
sbagli candeggio
Linux esiste in versione real-time come esiste W2K in versione realtime
per linux vai su RTLinux.org (mi sembra) per W2K vai su www.vci.com e ti
becchi le estensioni realtime (che hanno un certo costo) e ti becchi delle
risposte in timing da far paura.
Nota comunque che con nessuno dei due sistemi conviene far andare una
centrale nucleare, a meno di non avere una pluriridondanza totale, con
almento 3 computer per ogni processo.
Per certe applicazioni c'e' QNX, VXWorks e... bho, non mi vengono in mente
gli altri...
Salumi
Xelloss
news:9drtcu$2vt$1...@durin.khazad-dum.net...
> Ma si, celebriamo il nuovo cadavere !! Allelujah !
Funziona, e bene.
Saluti.
--
Wilmer Ricciotti
wi...@bigfoot.com
Xelloss
news:slrn9g2in3.1l...@harris.sonicblast.it...
> Rimane da convincere la MS di questo.
MS lo dice da tempo, ma i produttori di hardware si sono adeguati soltanto
ultimamente (e nemmeno tutti).
Piergiorgio Sartor
Lorenzo Allegrucci wrote:
> Il punto e' che mentre si puo' migliorare con sofisticate tecniche hw,
> un context switch tra due processi server di un uK sara' sempre molto
> piu' lento di una semplice chiamata di funzione in un kernel monolitico.
> Attualmente, la chiamata e' circa *tre* ordini di grandezza piu' veloce!
> (A parita' di condizioni, con cache calda).
Non vedo perche`?
Se azzeri il collo di bottiglia del contex switch i tempi si
equivalgono, anzi si riducono nel caso di uK, proprio per il
fatto che e` micro (cache allocation).
> Come vedi, la costruzione delle CPU attuali e' ottimizzata per il
> *throughput* e *non* per la latenza delle istruzioni.
Infatti, questo e` il fattore.
Nessuna CPU si e` evoluta per supportare un tipo di SW anziche`
un altro, non solo nel senso dei sistemi operativi, ma si
e` cercato di "battere" i benchmark.
> D'altra parte se vuoi andare veloce e contenere i costi, questo devi
> fare. Throughput e latenza insieme significa mettere piu' pipeline
> in parallelo.. e moltiplicare i costi. E comunque otterresti un
> risultato incerto, a causa delle dipendenze delle istruzioni.
Piu` che altro questo e` un metodo.
Ad es. il concetto VLIW e` differente, potrebbe anche non
penalizzare (dipende dall'implementazione) la latenza.
> Il problema a questo punto e' quale parte della cache congelare.
> E' molto difficile se non impossibile saperlo con certezza.
No, no!
Le CPU con questa caratteristiche consentono di fare proprio
questo: caricare un pezzo di codice in cache programma e congelarla.
Lo stesso con la cache dati.
> La cache e' un meccanismo quasi del tutto trasparente a livello
> di programmazione, nelle architetture che conosco.
> Non nego che si possa fare, me lo trovo alquanto sofisticato.
Affatto, alcune CPU forniscono *istruzioni* per il controllo
della cache (anche le 3DNow! extension dei K6 +), come prefetch,
allocate,
invalidate, flush.
> L'impatto si fa sentire, ma e' in parte compensato dal clock piu'
> elevato. Solo in parte..
Io dicevo a pari clock e pari cache...
> Il K7 resta come costruzione piu' "agile" anche del PIII, cioe' ha dei
> tempi di latenza in genere minori.
Direi che e` un fatto interessante, quindi per un utente
Linux un K7 e` raccomandato!!! :-)
> Direi che tutto il discorso puo' essere condensato in questa semplice
> considerazione: le CPU attuali ottimizzano il throughput a scapito
> della latenza. Questa e' una scelta di progetto, non per fare un
> dispetto ai fan dei uK, forse :-)
Certo :-)
Credo che si sia seguita una certa strada, non perche` non ve ne
fossero altre, ma perche` era *visibilmente* valida (anche
commercialmente).
> Si potrebbe dire che mentre le prestazioni dei monolitici sono rimaste
> pressoche' le stesse, quelle dei uK sono diminuite, o meglio il
> *divario* tra i due approcci si e' allargato.
Direi proprio di si.
Il contex switch sta diventando critico anche per i kernel
monolitici, questo e` il motivo per cui si vedono sempre
piu` "feature" in kernel space...
> Chi sbaglia, i costruttori di CPU o i sostenitori dei uK?
Quali CPU?
I costruttori di x86 sbagliano per definizione! :-)
L'architettura x86 e` un catorcio, non funziona.
Un processore a 100MHz VLIW ha prestazioni pari ad un x86 a 500MHz,
con 1/10 (un decimo) del silicio.
L'unico (grosso) difetto e` che non e` x86 compatibile :-)
[uK vs. monolith]
> Su questo punto si sono scatenate le guerre sante dei SO degli ultimi
> 15-20 anni :-)
> Mi ci butto anch'io..
Noooooo!!!! :-)
> Non sono del tutto convinto della migliore architettura sw.
Questo e` vero per definizione di "migliore architettura" :-)
I uK sono migliori (architetturalmente) dei monolitici.
> In particolare, l'utilita' di avere i processi server ognuno nel suo
> spazio d'indirizzamento.
Questa e` una cosa diversa....
[...]
> Se va in crash il server VFS non ho piu' l'interfaccia virtuale con
> i filesystem e perdo l'uso dei dischi sia locali che di rete.
Il problema e` che in un contesto moderno, il SO non ha
piu` un solo filesystem, ad esempio...
O meglio: cosa deve stare dentro e cosa deve stare fuori dal kernel?
Nel caso dei monolitici questo non e` definito chiaramente, il che
dimostra che l'architettura e`, diciamo, debole.
Nel caso dei FS: un SO tipo Linux ne gestisce decine, tutti in
kernel space, il che implica avere un sacco di codice in un
posto critico. Codice che non viene sempre realmente utilizzato,
ma di cui bisogna garantire la *perfetta* funzionalita`.
Se metti i FS in user space, risolvi un sacco di problemi
strutturali e concettuali: ognuno puo` avere il FS che vuole,
quando vuole, senza problemi.
> Modularita'.
> I kernel monolitici hanno i kernel threads.
> I kernel threads sono visibili in user space come processi normali e
> agiscono come processi normali tranne che hanno il loro spazio
> d'indirizzamento in comune e coincidente con quello del kernel.
> Per il resto, la semantica e' la stessa. Esempio:
> posso fare 'kill -STOP kupdate' e sospendere il flush della buffer cache
> su disco, per poi fare 'kill -CONT kupdate' per continuare.
Si cerca di dare le caratteristiche di un uK ad un kernel monolitico.
Con tutti i rischi connessi...
> Modularita' 2.
> I kernel monolitici hanno anche i moduli kernel caricabili
> dinamicamente. In linea di principio sarebbe possibile avere scheduler
> multipli, VM multipli etc. Ogni modulo puo' agire come una sorta di
> plug-in. Nel caso dei scheduler multipli so che c'e' una patch in giro.
> Ovviamente nei moduli kernel posso creare altri kernel threads, cambiare
> al volo una syscall, ridirezionarla, sostituirla, eliminarla etc.
>
> Insomma, non vedo vantaggi netti dei uK sotto questi punti di vista,
> percio' a parita' di condizioni prendo il rasoio di Occam e taglio via
> la complessita' inutile, rimanendo con un monolitico :-)
Ma i vantaggi sono proprio questi!!!
Ed il fatto che i kernel monolitici stiano prendendo le
feature dei uK lo dimostra!!!
Quello che scrivi e` proprio la prova che il concetto di uK e` valido.
Le idee dei uK vengono portate nei monolitici!!!
Con la differenza che i uK sono pensati per far queste cose, i
monolitici sono "patchati", il che non mi pare poco e dimostra,
ancora una volta, che l'architettura uK e` superiore.
Per le prestazioni... non se ne parla nemmeno, ovviamente.
Direi che se confrontiamo le prestazioni non c'e` storia:
i uK sono perdenti.
Se confrontiamo la struttura e l'architettura, allora le cose
sono all'opposto.
Un po' come C vs. C++, il secondo e` meglio come linguaggio,
ma il primo e` meglio come prestazioni.
bye,
--
Piergiorgio Sartor
thorin_...@gruppocm-cs.it
>> Ma si, celebriamo il nuovo cadavere !! Allelujah !
> Funziona, e bene.
Bene non direi proprio... ed oltre agli esempi qui in ufficio da me, su
macchine cui inspiegabilmente si pianta qualcosa non appena finito il
logon (che so, il control panel o altro) ci sono altri che potranno dire
la stessa cosa. E siccome 1) parliamo di macchine Compaq Deskpro non di
catorci taiwanesi 2) Linux su macchine anche su PC di potenza inferiore
a quelle su cui e' installato Win2bug (sempre di macchine Compaq parlo)
va come una scheggia direi che se la matematica non e' un opinione 2+2
non fa 22 quindi Win2bug fa un po' pena.
thorin_...@gruppocm-cs.it
>> Rimane da convincere la MS di questo.
> MS lo dice da tempo, ma i produttori di hardware si sono adeguati soltanto
> ultimamente (e nemmeno tutti).
Vero? Che peccato che non tutti i produttori abbiano prodotto macchine
adeguate (leggi magari dei dual Xeon) per fornire adeguato spazio a
questo nuovo gioiello di sistema operativo, eh? Se penso che su un
catorcio cosi' (un P75 con 32 Mb di RAM, dettagli in [1]) una Debian fa
scintille fornendo servizi Samba ed anonymous FTP mentre su dei PIII700
Win2bug arranca..
[1]
[pier@mordor pier]$ telnet cerberus
Trying 192.168.4.56...
Connected to cerberus.gruppocm-cs.it.
Escape character is '^]'.
Debian GNU/Linux 2.2 cerberus.gruppocm-cs.it
cerberus login: pier
Password:
Last login: Thu May 17 16:26:46 2001 from mordor.gruppocm-cs.it on pts/1
Linux cerberus 2.2.18 #10 Tue Apr 17 13:21:30 CEST 2001 i586 unknown
Most of the programs included with the Debian GNU/Linux system are
freely redistributable; the exact distribution terms for each program
are described in the individual files in /usr/doc/*/copyright
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
pier@cerberus:~$ su - root
Password:
cerberus:~# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 2
model name : Pentium 75 - 200
stepping : 5
cpu MHz : 74.705
[..]
rberus:~# cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 31899648 30715904 1183744 9510912 14905344 6639616
Swap: 105279488 2965504 102313984
MemTotal: 31152 kB
MemFree: 1156 kB
MemShared: 9288 kB
Buffers: 14556 kB
Cached: 6484 kB
SwapTotal: 102812 kB
SwapFree: 99916 kB
Lorenzo Allegrucci
<sar...@sony.de.REMOVE.THIS> wrote:
>> Il punto e' che mentre si puo' migliorare con sofisticate tecniche hw,
>> un context switch tra due processi server di un uK sara' sempre molto
>> piu' lento di una semplice chiamata di funzione in un kernel monolitico.
>> Attualmente, la chiamata e' circa *tre* ordini di grandezza piu' veloce!
>> (A parita' di condizioni, con cache calda).
>
>Non vedo perche`?
>Se azzeri il collo di bottiglia del contex switch i tempi si
>equivalgono, anzi si riducono nel caso di uK, proprio per il
>fatto che e` micro (cache allocation).
Perche' un context switch salva un intero contesto di esecuzione
invece di mettere nello stack solo l'indirizzo di ritorno come fa
una semplice chimata.
Un context switch significa:
- savare tutti i registri (in generale).
- scaricare completamente i TLB (alcune architetture possono salvarne
alcuni ma le entry dei TLB sono *poche*: 32, 64, 128 al massimo).
- ricaricare i TLB. Questo avviene automaticamente quando l'altro
task inizia a girare e hai un picco di TLB miss durante il quale
il processore deve andarsi a tradurre gli indirizzi accedendo alle
page tables. Questa e' la parte piu' costosa perche' per ogni pagina
da tradurre deve fare 3/4 accessi alla memoria che con buona
probabilita' beccheranno un cache miss.
- ricaricare i registri.
- altri setup, dipendenti dalle idiosincrasie dall'architettura.
Tutta questa roba costa.
E' possibile ottimizzare ma non piu' di tanto. Linux fa gia' dei
miracoli. 'struct task' e' ridotta al minimo e ogni cosa e' allineata
in memoria con le dimensioni di una cache line, 32 byte.
Eppure una chiamata e' 1000 (mille!) volte piu' veloce.
I rimedi hw sono palliativi che non risolvono il problema in generale.
Ok, si possono tenere piu' contesti contemporanemaente, portare il
numero dei TLB a qualche decina di migliaia, mantenere copie multiple
del set di registri etc. Otterrai un context switch da 10 nanosecondi.
Ma a quale prezzo? Perche' nessuna architettura mainstream ha queste
estensioni?
Le CPU sono fatte per macinare istruzioni, non per passare da un
contesto all'altro, e' questo il punto fondamentale che i uK trascurano.
>> Come vedi, la costruzione delle CPU attuali e' ottimizzata per il
>> *throughput* e *non* per la latenza delle istruzioni.
>
>Infatti, questo e` il fattore.
>Nessuna CPU si e` evoluta per supportare un tipo di SW anziche`
>un altro, non solo nel senso dei sistemi operativi, ma si
>e` cercato di "battere" i benchmark.
>
>> D'altra parte se vuoi andare veloce e contenere i costi, questo devi
>> fare. Throughput e latenza insieme significa mettere piu' pipeline
>> in parallelo.. e moltiplicare i costi. E comunque otterresti un
>> risultato incerto, a causa delle dipendenze delle istruzioni.
>
>Piu` che altro questo e` un metodo.
>Ad es. il concetto VLIW e` differente, potrebbe anche non
>penalizzare (dipende dall'implementazione) la latenza.
>
>> Il problema a questo punto e' quale parte della cache congelare.
>> E' molto difficile se non impossibile saperlo con certezza.
>
>No, no!
>Le CPU con questa caratteristiche consentono di fare proprio
>questo: caricare un pezzo di codice in cache programma e congelarla.
>Lo stesso con la cache dati.
Se esistono, non le conosco.
Cioe', e' probabile che esistano, ma non le conosco :-)
>> La cache e' un meccanismo quasi del tutto trasparente a livello
>> di programmazione, nelle architetture che conosco.
>> Non nego che si possa fare, me lo trovo alquanto sofisticato.
>
>Affatto, alcune CPU forniscono *istruzioni* per il controllo
>della cache (anche le 3DNow! extension dei K6 +), come prefetch,
>allocate,
>invalidate, flush.
Un conto e' il prefetch, un conto e' congelare la cache.
Queste istruzioni sono degli "hint", dei consigli che dai al
processore ma il modello della cache rimane comunque rilassato, cioe'
non puoi forzarlo piu' di tanto.
>> L'impatto si fa sentire, ma e' in parte compensato dal clock piu'
>> elevato. Solo in parte..
>
>Io dicevo a pari clock e pari cache...
A pari clock e pari cache il P4 perde su tutti i fronti.
>> Il K7 resta come costruzione piu' "agile" anche del PIII, cioe' ha dei
>> tempi di latenza in genere minori.
>
>Direi che e` un fatto interessante, quindi per un utente
>Linux un K7 e` raccomandato!!! :-)
Il K7 e' attualmente il processore x86 con la migliore architettura,
IMHO. Indipendentemente dal SO.
>> Direi che tutto il discorso puo' essere condensato in questa semplice
>> considerazione: le CPU attuali ottimizzano il throughput a scapito
>> della latenza. Questa e' una scelta di progetto, non per fare un
>> dispetto ai fan dei uK, forse :-)
>
>Certo :-)
>
>Credo che si sia seguita una certa strada, non perche` non ve ne
>fossero altre, ma perche` era *visibilmente* valida (anche
>commercialmente).
>
>> Si potrebbe dire che mentre le prestazioni dei monolitici sono rimaste
>> pressoche' le stesse, quelle dei uK sono diminuite, o meglio il
>> *divario* tra i due approcci si e' allargato.
>
>Direi proprio di si.
>Il contex switch sta diventando critico anche per i kernel
>monolitici, questo e` il motivo per cui si vedono sempre
>piu` "feature" in kernel space...
Parli di TUX?
Se e' cosi' forse ti sorprendera' che esiste una soluzione interamente
in user space che ottiene gli stessi risultati di TUX :-)
E' una questione di buon design delle API interne del kernel.
>> Chi sbaglia, i costruttori di CPU o i sostenitori dei uK?
>
>Quali CPU?
>I costruttori di x86 sbagliano per definizione! :-)
>
>L'architettura x86 e` un catorcio, non funziona.
>
>Un processore a 100MHz VLIW ha prestazioni pari ad un x86 a 500MHz,
>con 1/10 (un decimo) del silicio.
>L'unico (grosso) difetto e` che non e` x86 compatibile :-)
.. e che non esistono compilatori abbastanza intelligenti da sfruttarne
il parallelismo interno.
>[uK vs. monolith]
>> Su questo punto si sono scatenate le guerre sante dei SO degli ultimi
>> 15-20 anni :-)
>> Mi ci butto anch'io..
>
>Noooooo!!!! :-)
Perche no? :-)
>> Non sono del tutto convinto della migliore architettura sw.
>
>Questo e` vero per definizione di "migliore architettura" :-)
>I uK sono migliori (architetturalmente) dei monolitici.
>
>> In particolare, l'utilita' di avere i processi server ognuno nel suo
>> spazio d'indirizzamento.
>
>Questa e` una cosa diversa....
>
>[...]
>> Se va in crash il server VFS non ho piu' l'interfaccia virtuale con
>> i filesystem e perdo l'uso dei dischi sia locali che di rete.
>
>Il problema e` che in un contesto moderno, il SO non ha
>piu` un solo filesystem, ad esempio...
>
>O meglio: cosa deve stare dentro e cosa deve stare fuori dal kernel?
>Nel caso dei monolitici questo non e` definito chiaramente, il che
>dimostra che l'architettura e`, diciamo, debole.
Punti di vista.
Se una cosa non e' definita puoi definirla tu come meglio credi.
Esistono soluzioni userspace-kernelspace secondo i compromessi
che vuoi ottenere. Basta guardare a knfs, per esempio.
>Nel caso dei FS: un SO tipo Linux ne gestisce decine, tutti in
>kernel space, il che implica avere un sacco di codice in un
>posto critico. Codice che non viene sempre realmente utilizzato,
>ma di cui bisogna garantire la *perfetta* funzionalita`.
Vale anche per i uK. I uK hanno solo il vantaggio che se un server
va in crash non corrompe gli altri server ma cio' ha poca importanza
perche' a questo punto la sistuazione e' gia' compromessa, credo.
I server per la corretta funzionalita' dei uK restano critici, o
sbaglio? Se il gestore della memoria o dei processi non funziona
il sistema e' ancora utilizzabile?
>Se metti i FS in user space, risolvi un sacco di problemi
>strutturali e concettuali: ognuno puo` avere il FS che vuole,
>quando vuole, senza problemi.
>
>> Modularita'.
>> I kernel monolitici hanno i kernel threads.
>> I kernel threads sono visibili in user space come processi normali e
>> agiscono come processi normali tranne che hanno il loro spazio
>> d'indirizzamento in comune e coincidente con quello del kernel.
>> Per il resto, la semantica e' la stessa. Esempio:
>> posso fare 'kill -STOP kupdate' e sospendere il flush della buffer cache
>> su disco, per poi fare 'kill -CONT kupdate' per continuare.
>
>Si cerca di dare le caratteristiche di un uK ad un kernel monolitico.
>Con tutti i rischi connessi...
Ben calcolati pero', a vedere i risultati finali.
>> Modularita' 2.
>> I kernel monolitici hanno anche i moduli kernel caricabili
>> dinamicamente. In linea di principio sarebbe possibile avere scheduler
>> multipli, VM multipli etc. Ogni modulo puo' agire come una sorta di
>> plug-in. Nel caso dei scheduler multipli so che c'e' una patch in giro.
>> Ovviamente nei moduli kernel posso creare altri kernel threads, cambiare
>> al volo una syscall, ridirezionarla, sostituirla, eliminarla etc.
>>
>> Insomma, non vedo vantaggi netti dei uK sotto questi punti di vista,
>> percio' a parita' di condizioni prendo il rasoio di Occam e taglio via
>> la complessita' inutile, rimanendo con un monolitico :-)
>
>Ma i vantaggi sono proprio questi!!!
>
>Ed il fatto che i kernel monolitici stiano prendendo le
>feature dei uK lo dimostra!!!
Non ho problemi a riconoscere che per certi aspetti i uK hanno un
approccio piu' elegante, dal punto di vista teorico.
Dico pero' che i monolitici sono piu' funzionali, si adattano meglio
alla realta'. Risolvono lo stesso problema con meno overhead.
E' per questo che li preferisco.
Dopotutto, il compito di un SO e' far girare i processi sfruttando al
meglio le risorse disponibili, che sono sempre *poche*.
Altrimenti diventa solo un esercizio accademico, fine a se stesso.
>Quello che scrivi e` proprio la prova che il concetto di uK e` valido.
>
>Le idee dei uK vengono portate nei monolitici!!!
>
>Con la differenza che i uK sono pensati per far queste cose, i
>monolitici sono "patchati", il che non mi pare poco e dimostra,
>ancora una volta, che l'architettura uK e` superiore.
>
>Per le prestazioni... non se ne parla nemmeno, ovviamente.
>
>Direi che se confrontiamo le prestazioni non c'e` storia:
>i uK sono perdenti.
>Se confrontiamo la struttura e l'architettura, allora le cose
>sono all'opposto.
>
>Un po' come C vs. C++, il secondo e` meglio come linguaggio,
>ma il primo e` meglio come prestazioni.
Occhio che qui scateni un'altra guerra santa, ma stavolta non ti
seguiro' :-)
Piergiorgio Sartor
Lorenzo Allegrucci wrote:
> Perche' un context switch salva un intero contesto di esecuzione
> invece di mettere nello stack solo l'indirizzo di ritorno come fa
> una semplice chimata.
Questo nelle CPU "normali".
Esistono, ripeto, CPU in cui il contex switch e` esattamente
uguale ad una chiamata di funzione.
> Le CPU sono fatte per macinare istruzioni, non per passare da un
> contesto all'altro, e' questo il punto fondamentale che i uK trascurano.
Ovvio.
Pero` con pipeline lunghe, cache limitate, non e` che un SO
multitasking sia proprio favorito, sia uK che no.
Se vuoi macinare numeri, non usi un SO multitasking o se lo
usi e` di tipo RT, con tutte le implicazioni che ne derivano.
> Un conto e' il prefetch, un conto e' congelare la cache.
Erano esempi di come certe CPU permettano di controllare
la cache, incluso in questo vi e` il freeze.
> Queste istruzioni sono degli "hint", dei consigli che dai al
> processore ma il modello della cache rimane comunque rilassato, cioe'
> non puoi forzarlo piu' di tanto.
Dipende dal processo, ripeto.
> A pari clock e pari cache il P4 perde su tutti i fronti.
Mi pareva...
> Il K7 e' attualmente il processore x86 con la migliore architettura,
> IMHO. Indipendentemente dal SO.
Dovro` farci un pensierino...
> Parli di TUX?
Forse quello e` un esempio, ma non e` l'unico, direi.
[VLIW]
> .. e che non esistono compilatori abbastanza intelligenti da sfruttarne
> il parallelismo interno.
Per quale VLIW? Forse Itanium?
Quelli in commercio hanno compilatori realmente fantastici,
roba da non credere.
Inoltre esistono metodi *formali* per ottimizzare
il codice di un VLIW, anche se a scapito delle
prestazioni in termini di tempo di compilazione...
> >[uK vs. monolith]
...
> Perche no? :-)
:-)
> Se una cosa non e' definita puoi definirla tu come meglio credi.
Uhm, starei attento a certe affermazioni.
Soprattutto in relazioni ad altri SO, magari quelli
di una famosa SW house delle parti di Seattle.
> Esistono soluzioni userspace-kernelspace secondo i compromessi
> che vuoi ottenere. Basta guardare a knfs, per esempio.
Non e` questioni di soluzioni, ma di come si raggiungono.
Non metto in dubbio che si possono avere, ad es., i kernel
thread, ma direi che un uK fornisce la stessa soluzione in
maniera piu` elegante e naturale.
> Vale anche per i uK. I uK hanno solo il vantaggio che se un server
> va in crash non corrompe gli altri server ma cio' ha poca importanza
> perche' a questo punto la sistuazione e' gia' compromessa, credo.
Non e` solo quello il vantaggio.
E` un fatto concettuale, la stessa soluzione e`, come scritto
sopra, naturale ed elegante in caso di uK, mentre e` piu`
macchinosa e complessa nel caso di kernel monolitici.
> I server per la corretta funzionalita' dei uK restano critici, o
> sbaglio? Se il gestore della memoria o dei processi non funziona
> il sistema e' ancora utilizzabile?
Dipende, se hai tre scheduler che funzionano ed uno crasha gli
altri due continuano ad andare.
Inoltre, in teoria, puoi far ripartire quello crashato senza
dover fare reboot.
Ma, ancora, non e` solo questo il punto, bensi` la strutturazione
totale del sistema, che con i uK e`... migliore... :-)
> Non ho problemi a riconoscere che per certi aspetti i uK hanno un
> approccio piu' elegante, dal punto di vista teorico.
> Dico pero' che i monolitici sono piu' funzionali, si adattano meglio
> alla realta'. Risolvono lo stesso problema con meno overhead.
E` quello che dico anche io.
> Dopotutto, il compito di un SO e' far girare i processi sfruttando al
> meglio le risorse disponibili, che sono sempre *poche*.
> Altrimenti diventa solo un esercizio accademico, fine a se stesso.
Dipende dal problema.
Ad es. un uK e` molto utile ad uno sviluppatore, che puo`
testare pezzi di kernel "al volo".
Puo` testare uno scheduler, in ambiente reale, senza dover
fare reboot ed incrociare le dita...
Se dovessi controllare un motore di F1, userei un SO RT...
Avendo bisogno di un file server, preferirei uno Unix...
E cosi` via.
Quindi separerei il discorso, tra aspetti "reali" e "teorici",
in prima battuta.
Secondo separerei il discorso prestazioni da quello funzionale
ed architetturale.
[C vs. C++]
> Occhio che qui scateni un'altra guerra santa, ma stavolta non ti
> seguiro' :-)
E` uno dei miei cavalli di battaglia preferiti ;-)
bye,
--
Piergiorgio Sartor
H.P.L.
> > Un po' come C vs. C++, il secondo e` meglio
> > come linguaggio, ma il primo e` meglio come prestazioni.
> Occhio che qui scateni un'altra guerra santa, ma stavolta
> non ti seguiro' :-)
un'affermazione falsa.
Oltre ad essere infinitamente meglio il C++ non aggiunge *NESSUN*
overhead rispetto al C. Questo e' eventualmente dovuto ad alcuni di quei
meccanismi che non esistono in C (metodi virtuali, eccezioni, ecc..). Se
tu volessi implementare queste funzionalita' in C ti troveresti di
fronte ad overhead ben maggiori.
Poi bisogna anche tenere conto che i compilatori C hanno raggiunto un
ottimo grado di ottimizzazione, cosa che non tutti i compilatori C++
hanno fatto. Ma l'utilizzo di un compilatore non valido nulla deve
togliere al C++. Anzi conosco persone (io non utilizzo il C, al limite
il subset C del C++) che hanno ottenuto migliori prestazioni in C++ che
in C (oltre che avere un codice migliore e piu' chiaro).
Ciao.
sr
>> Esiste solo un rimedio contro il FUD, i fatti.
>Questo non e' FUD, ma trolling di un cerebroleso, cosa ben differente,
>per cui faresti meglio a killarlo e basta.
Tranquillo, non mi ci spreco piu' di tanto.
Il plonk e' ovviamente implicito:))
I links che ho postato servono non tanto al tizio in questione,
ma a quanti, non conoscendo il mondo Open Source, sarebbero
tentati di credere alle panzane che scrive.
Piergiorgio Sartor
"H.P.L." wrote:
> Oltre ad essere infinitamente meglio il C++ non aggiunge *NESSUN*
> overhead rispetto al C. Questo e' eventualmente dovuto ad alcuni di quei
> meccanismi che non esistono in C (metodi virtuali, eccezioni, ecc..). Se
> tu volessi implementare queste funzionalita' in C ti troveresti di
> fronte ad overhead ben maggiori.
Questo, semmai, e` falso.
Ed e` provato con i fatti, non con semplici considerazioni teoriche.
In C puoi implementare tutto quello che fai in C++ in maniera
migliore (nel senso delle prestazioni), dato che hai controllo
su quello che fai.
C++ e` un miglior tool di programmazione, ma non ha
prestazioni migliori, di fatto non le puo` avere, dato
che l'elevata astrazione del linguaggio non consente
una sicura ottimizzazione.
Certo, se usi il C++ per quello che e` stato concepito,
se lo usi come il C... allora ricadi nel problema dei compilatori...
> Poi bisogna anche tenere conto che i compilatori C hanno raggiunto un
> ottimo grado di ottimizzazione, cosa che non tutti i compilatori C++
> hanno fatto. Ma l'utilizzo di un compilatore non valido nulla deve
Questo e` vero, sicuramente i compilatori (e le librerie) C sono
piu` ottimizzate.
> togliere al C++. Anzi conosco persone (io non utilizzo il C, al limite
> il subset C del C++) che hanno ottenuto migliori prestazioni in C++ che
> in C (oltre che avere un codice migliore e piu' chiaro).
Senza offesa, ma si tratta di gente che non sa programmare
o che non conosce il compilatore C.
bye,
--
Piergiorgio Sartor
H.P.L.
> Questo, semmai, e` falso.
> Ed e` provato con i fatti, non con semplici considerazioni teoriche.
Non sono considerazioni teoriche, sono fatti.
> In C puoi implementare tutto quello che fai in C++
No, in C++ puoi fare *TUTTO* cio' che fai in C, ma il contrario non e'
vero.
> in maniera migliore (nel senso delle prestazioni),
Ripeto che non conosci il C++.
> dato che hai controllo su quello che fai.
Ed il C++ dove te lo farebbe perdere il contollo su quello che fai?
> C++ e` un miglior tool di programmazione, ma non ha
> prestazioni migliori, di fatto non le puo` avere, dato
> che l'elevata astrazione del linguaggio non consente
> una sicura ottimizzazione.
Questa poi e' assurda. Il C++ puo' essere utilizzato allo stesso basso
livello del C.
> Certo, se usi il C++ per quello che e` stato concepito,
> se lo usi come il C... allora ricadi nel problema dei
> compilatori...
Vedi che sbagli. Il C++ e' *MULTIPARADIGMA* , lo puoi utilizzare in
maniera OO, ma anche esattamente "alla C". Ma e' pur sempre C++.
> Questo e` vero, sicuramente i compilatori (e le librerie)
> C sono piu` ottimizzate.
Non tutti. alcuni compilatori C++ hanno raggiunto livelli di
ottimizzazione incredibili.
> Senza offesa, ma si tratta di gente che non sa programmare
> o che non conosce il compilatore C.
Senza offesa, ma e' proprio il contrario, e' chi non sa programmare in
C++ che afferma erroneamente che il C e' piu' veloce.
Ciao.
Giambo
>Chi programma veramente non ha neanche bisogno dei sorgenti per capire
>come funziona un programma spesso un debugger basta e avanza.
Come dire "non serve l'aeroplano per andare in America, per chi sa'
remare veramente bene un canotto basta e avanza" :)
--
__
| _ "The Internet is slow, could you please reboot it ?"
|__|iambo mailto:gabr...@giambonini.com www.giambonini.com
Giambo
>> Ho scoperto che e' molto sensibile all'Hardware: Dove la SuSE faceva
>> scintille, Win2K crepava miseramente. Win98 non si installava neanche
>> :-)
>
>Sentiamo un po' che hw ...
Non ho la macchina sotto mano ...
>Ho istallato win2k su hw da schifo e tutto e' andato liscio.
Gia' che ci sei, se magari riuscissi a far cantare una Ensoniq
ES1371 sotto NT4 e a spiegarmi perche' Dr.Watson viene a farmi
visita quando clicko con il tasto destro su un drive ...
Chiudo dicendo che la SuSE7.1 su quella macchina, con Gnome e
Sawmill e' _decisamente_ piu' veloce di NT4. Ah, sulla macchina
Linux ci girano pure un paio di servizi (NNTP, SMTP, SMB, NFS, FTP,
SHH, ...).
Marco d'Itri
>No, in C++ puoi fare *TUTTO* cio' che fai in C, ma il contrario non e'
>vero.
Turing, questo sconosciuto.
--
ciao, | "You're one of those condescending Unix computer users!"
Marco | "Here's a nickel, kid. Get yourself a better computer" -- Dilbert
| (Ri)scoprire fidonet: http://bbs.bofh.it
thorin_...@durin.khazad-dum.net
> u...@vaila.ble wrote:
>>No, in C++ puoi fare *TUTTO* cio' che fai in C, ma il contrario non e'
>>vero.
> Turing, questo sconosciuto.
ROFL !
Renato 'Hitman' Salzano
schifo che mi circonda e come la cosidetta societa` civile sia basata
sull'ipocrisia e dominazione, Ginopilotino interruppe il corso dei miei
pensieri bofonchiando:
> Sentiamo un po' che hw ...
da 16. C'era un'altra da 16M, ma e` morta) di RAM, scheda video Paradise
WD e scheda audio Mad16 originale (si, quella che nessun windows
supporta e linux si :P), due schede di rete 3com 3c503, HD da 250M IDE
(neanche EIDE) su controller dio-solo-sa-cosa infilato su slot VESA.
WinNT3.51 non vedeva l'HD. Win98 la scheda scheda audio e non ci
rimaneva mica spazio per nulla. Mi dice il proprietario che anche una
delle due schede di rete non andava.
Poi sono entrato in scena io con un CD della Debian 2.2 appresso.
Ehi, sara` pure HW da schifo, ma da FireWall + router + dns server lo fa
bene. Anzi, su richiesta ci sono riuscito a infilare PatheticWriter e
una GUI grafica, per giunta. E avevo ancora un 80M libero.
--
Renato "Hitman" Salzano - http://spazioweb.inwind.it/hitman/
e-posta : sonicblast (at) inwind.it / Xena:TWP fan
Webdesigner / indegno sysadmin di www.italservicesnc.it
Powered by Debian 2.x (Woody) on a K6/2 box - 100% Wintel free
Renato 'Hitman' Salzano
schifo che mi circonda e come la cosidetta societa` civile sia basata
miei pensieri bofonchiando:
> Se windows e' montato su una macchina con driver non bacati va che e'
> una meraviglia e non si inchioda neanche a morire. (ovviamente parlo
> di w2k)
Si usa un altro SO, ovviamente.
Davide Inglima - limaCAT
>Scusa, hai ragione per la quota, chiedo venia, ma intervengo poco nelle NG
>ed a volte mi dimentico.. :(
>Grazie comunque per la critica "Costruttiva", ciao
Prego :)
--
Davide Inglima, limaCAT
Davide Inglima - limaCAT
<ba...@katamail.com> wrote:
>> perche' e' gratis.
> GNU/Linux e tutto il software GPL e' libero, non gratis. Prima di riempirti
> la bocca, almeno leggile le licenze software. Grazie.
"Da Redmond alla Finlandia, ovverosia come le cozze passato l'oceano rimangano
pur sempre cozze"
--
Davide Inglima, limaCAT
Ginopilotino
gia...@no.spam.please says...
> On Tue, 15 May 2001 19:57:23 GMT, Ginopilotino wrote:
>
> >> Ho scoperto che e' molto sensibile all'Hardware: Dove la SuSE faceva
> >> scintille, Win2K crepava miseramente. Win98 non si installava neanche
> >> :-)
> >
> >Sentiamo un po' che hw ...
>
> Non ho la macchina sotto mano ...
>
> >Ho istallato win2k su hw da schifo e tutto e' andato liscio.
>
> Gia' che ci sei, se magari riuscissi a far cantare una Ensoniq
> ES1371 sotto NT4 e a spiegarmi perche' Dr.Watson viene a farmi
> visita quando clicko con il tasto destro su un drive ...
Ma non si parlava di win2k?
Cmq non sono un'indovino. Per il primo hai provato su
http://www.ensoniq.com?
Per il secondo caso invece ipotizzo ci sia installata qualche
applicazione che tenta di accedere al disco quando premi il pulsante di
destra, e per qualche motivo va in crash. Uno sguardo al log del dottore
non (ti) farebbe male :)
> Chiudo dicendo che la SuSE7.1 su quella macchina, con Gnome e
> Sawmill e' _decisamente_ piu' veloce di NT4. Ah, sulla macchina
> Linux ci girano pure un paio di servizi (NNTP, SMTP, SMB, NFS, FTP,
> SHH, ...).
Se hai almeno 64Mb direi che sotto nt4 dovrebbe essere piu' veloce.
Prob. non e' configurato a dovere.
Ciao ... Dino
Ginopilotino
hitma...@yahoo.it says...
> Era il Tue, 15 May 2001 19:57:23 GMT e, mentre stavo contemplando lo
> schifo che mi circonda e come la cosidetta societa` civile sia basata
> sull'ipocrisia e dominazione, Ginopilotino interruppe il corso dei miei
> pensieri bofonchiando:
> > Sentiamo un po' che hw ...
> > Ho istallato win2k su hw da schifo e tutto e' andato liscio.
> Installalo su un 486/33Mhz, 20M (4 simm da 30pin da 1M, 1 simm da 72pin
> da 16. C'era un'altra da 16M, ma e` morta) di RAM, scheda video Paradise
> WD e scheda audio Mad16 originale (si, quella che nessun windows
> supporta e linux si :P), due schede di rete 3com 3c503, HD da 250M IDE
> (neanche EIDE) su controller dio-solo-sa-cosa infilato su slot VESA.
> WinNT3.51 non vedeva l'HD. Win98 la scheda scheda audio e non ci
> rimaneva mica spazio per nulla. Mi dice il proprietario che anche una
> delle due schede di rete non andava.
Mi spiegheresti cosa centra con win2k?
> Poi sono entrato in scena io con un CD della Debian 2.2 appresso.
>
> Ehi, sara` pure HW da schifo, ma da FireWall + router + dns server lo fa
> bene. Anzi, su richiesta ci sono riuscito a infilare PatheticWriter e
> una GUI grafica, per giunta. E avevo ancora un 80M libero.
Su un pc simile a questo io ci facevo girare autocad e 3dstudiomax sotto
nt4, solo che avevo un hd un po' piu' grande.
Ciao .. Dino
Gianluca
> > vedere come il tuo OS lavora fin nelle viscere è una cosa entusiasmante.
> > Poter ricompilarlo per la *tua* macchina è ancora più entusiasmante. Certo
> è
> > che non è per tutti linux.
>
> primo: al 99.99% delle persone gli importa sega di ricompilare il kernel.
Vero. Ma solo il sapere che lo _puoi_ fare se _vuoi_ o _devi_ e' un bel
vantaggio.
> > E non è detto che lo debba necessariamente
> > essere: se vuoi giocare, usa windoz (e non ti lamentare dei crash), se
> vuoi
> > lavorare tranquillo, puoi usare linux...
>
> questo e' un dogma linuxiano.
> se vuoi giocare -> windows
Ancora per poco ;) ls SDL promettono molto bene.
> per favore, alziamo il livello della discussione, grazie.
> Se windows e' montato su una macchina con driver non bacati va che e' una
> meraviglia e non si inchioda neanche a morire.
> (ovviamente parlo di w2k)
Mmmmh, si, non si inchioda. Ma solo se qualche cattivone non decide di
sfruttare qualche buco _noto_ nei 15/20 giorni che passano tra l'annuncio
del buco e la patch di M$.
> > > Seconda questione: il codice del kernel. Se quello MS fosse open, ti
> > ]:> già, se lo fosse... ma la paura li attanaglia.
>
> infatti e' gia' stato reso pubblico per le grandi aziende e per le
> universita'.
Gia'. Guardare ma non toccare... Sai che me ne faccio.
> Chi programma veramente non ha neanche bisogno dei sorgenti per capire come
> funziona un programma
> spesso un debugger basta e avanza.
Bella questa.
> > Che, naturalmente, tu che non hai un firewire non compili. Poi, che siano
> > schifezze è tutto da dimostrarsi.
>
> quando gli utenti avranno bisogno di utilizzare piu' a fondo l'integrazione
> fra i vari pacchetti allora ne vedremo delle belle.
Sei sicuro ? Gia' adesso mi sembra che si parlino bene.
Per fare un esempio che conosco, GTM accetta tranquillamente il drag&drop da
netscape e mozilla, e viene usato tranquillamente via CORBA da galeon per
fare i download. E questo e' un esempio di un programma abbastanza banale,
visto che e' una semplice gui sopra wget. Dove dovrebbe essere piu'
integrato ?
Altre applicazioni stanno arrivando a risultati anche migliori. Dove vedi
tutti questi problemi ?
> > Morale? Gallina vecchia muore prima. Mah... le scelte sono scelte: come
> > disse il mio professore di controlli: Se voi volete chiudere il loop e
> > controllare la vostra centrale nucleare con windows, beh, fatemelo sapere,
> > che mi trasferisco lontano... (e non è uno scherzo)
>
> stessa cosa che controllarlo con Linux.
Diciamo che in una scala da 0 a 100, se lo controlli con windows la fiducia
e' 0, se usi linux e' 0.1
bye
Gianluca
Xelloss
news:9e0glo$fpq$1...@mordor.gruppocm-cs.it...
> Bene non direi proprio... ed oltre agli esempi qui in ufficio da me, su
> macchine cui inspiegabilmente si pianta qualcosa non appena finito il
> logon (che so, il control panel o altro) ci sono altri che potranno dire
> la stessa cosa. E siccome 1) parliamo di macchine Compaq Deskpro non di
> catorci taiwanesi 2) Linux su macchine anche su PC di potenza inferiore
> a quelle su cui e' installato Win2bug (sempre di macchine Compaq parlo)
> va come una scheggia direi che se la matematica non e' un opinione 2+2
> non fa 22 quindi Win2bug fa un po' pena.
Vabbè, a me non si pianta mai, si vede che ho culo.
Xelloss
news:9e0h0d$g1d$1...@mordor.gruppocm-cs.it...
> Vero? Che peccato che non tutti i produttori abbiano prodotto macchine
> adeguate (leggi magari dei dual Xeon) per fornire adeguato spazio a
> questo nuovo gioiello di sistema operativo, eh? Se penso che su un
> catorcio cosi' (un P75 con 32 Mb di RAM, dettagli in [1]) una Debian fa
> scintille fornendo servizi Samba ed anonymous FTP mentre su dei PIII700
> Win2bug arranca..
Almeno non parlare di cose che non sai, Win2K va a un'ottima velocità sul
K6III 450 che sto usando ora. Poi è chiaro, hanno venduto tanti di quei P!!!
1 GHz con 64 Mb di ram... castrati così certo che vanno lenti. Win2K
richiede, effettivamente, abbastanza ram: non è lento ma ingombrante, a
causa dei tanti servizi attivi di default... immagino che su XP Home Edition
le cose miglioreranno.
thorin_...@durin.khazad-dum.net
>> Bene non direi proprio... ed oltre agli esempi qui in ufficio da me, su
>> macchine cui inspiegabilmente si pianta qualcosa non appena finito il
>> logon (che so, il control panel o altro) ci sono altri che potranno dire
[..]
> Vabbè, a me non si pianta mai, si vede che ho culo.
Probabile che tu abbia una rara forma di culo, forse di tipo tropicale
perche' pare che io non sia il solo cui Win2bug dia problemi.
thorin_...@durin.khazad-dum.net
> news:9e0h0d$g1d$1...@mordor.gruppocm-cs.it...
>> Vero? Che peccato che non tutti i produttori abbiano prodotto macchine
>> adeguate (leggi magari dei dual Xeon) per fornire adeguato spazio a
[..]
> Almeno non parlare di cose che non sai, Win2K va a un'ottima velocità sul
> K6III 450 che sto usando ora. Poi è chiaro, hanno venduto tanti di quei P!!!
E tu non scrivere cazzate: quei PIII con *128* Mb di RAM li ho sotto gli
occhi tutti i giorni cosi' come ho sotto gli occhi macchine meno
performanti che con Linux vanno molto meglio. Hai mai visto un Linux
girare in vita tua oppure sei in fase di divinazione?
> 1 GHz con 64 Mb di ram... castrati così certo che vanno lenti. Win2K
> richiede, effettivamente, abbastanza ram: non è lento ma ingombrante, a
> causa dei tanti servizi attivi di default... immagino che su XP Home Edition
> le cose miglioreranno.
La differenza inesistente in casa m$ fra una OS server ed un OS
orientato all'home computing (non doveva sostituire 9x?) continuera'
sempre ad affascinarmi proprio perche' i concetti di base dei sistemi
operativi urlano dilaniati nelle loro cripte.
BTW sara' tutto da vedere se con XP miglioreranno, considerato
soprattutto che le migliorie di cui ho letto finora sono ancora una
volta cazzate estetiche e non funzionali dell'OS stesso.
Obelix
wrote:
>Vabbč, a me non si pianta mai, si vede che ho culo.
SE e' per quello, neanche a me non si pianta mai....
Obelix
Leonardo Serni
<ab...@1.2.0.1.0.0.1.e.f.f.3.ip6.int> wrote:
>u...@vaila.ble wrote:
>
>>No, in C++ puoi fare *TUTTO* cio' che fai in C, ma il contrario non e'
>>vero.
>Turing, questo sconosciuto.
ROFLASTB
Leonardo
--
Microsoft Outlook: il primo news reader con supporto messaggistica RAID 1.
thorin_...@gruppocm-cs.it
>>Vabbè, a me non si pianta mai, si vede che ho culo.
> SE e' per quello, neanche a me non si pianta mai....
Ce l'hai sempre spento?
Piergiorgio Sartor
"H.P.L." wrote:
> No, in C++ puoi fare *TUTTO* cio' che fai in C, ma il contrario non e'
> vero.
Ops...
Ad occhio e croce direi che esistono un paio di dimostrazioni
sull'equivalenza dei linguaggi formali (tutti).
Inoltre i primi compilatori C++ producevano codice C,
come output...
> > C++ e` un miglior tool di programmazione, ma non ha
> > prestazioni migliori, di fatto non le puo` avere, dato
> > che l'elevata astrazione del linguaggio non consente
> > una sicura ottimizzazione.
> Questa poi e' assurda. Il C++ puo' essere utilizzato allo stesso basso
> livello del C.
Appunto, allora scrivi in C e non in C++.
Se devi "abbassarti" al livello C per avere prestazioni,
vuol dire che il livello C++ non te le da.
Molto semplice.
Se uso un certo linguaggio e` perche` voglio approfittare
di un certo tipo di approccio.
Se devo scrivere un pezzo in assembly per poter avere
prestazioni, allora lo scopo del linguaggio (in termini
di prestazioni) fallisce, anche se mi da questa possibilita`...
Inoltre non metto in dubbio che si possa scrivere un
programma in BASIC piu` veloce di un programma assembly
che fa la stessa cosa, ma sicuramente sto forzando un
po' il benchmarking...
bye,
--
Piergiorgio Sartor
Sensei
wrote:
> Onestamente e senza prenderla come offesa o attacco personale.
> MACCHISSENEFREGA di chi gioca con windows. Chi gioca usa 98/me, faccia
> pure, importa sega. Io parlo di W2K in ambito
> commerciale/industriale/sviluppo, che e' altra ben diversa cosa.
Nessuna offesa :) siamo qui per discutere, non per offenderci e per
attaccarci.
Ed infatti era rivolto a quelli che 'mi sono installato w2k perchè ci ha i
menù a dissolvenza'. Windows 2000 l'ho provato (non ancora in ambiti mission
critical) ma non mi ha entusiasmato.
> ??? e con cio'? cosa hai dimostrato??? Quasi tutto ha una derivazione
> *nix, non vedo problemi.
Che anche linux non è poi tanto vecchio: sai, ho letto delle dichiarazioni
di boss MS che affermavano che w2k era mooooolto più moderno di linux, un OS
vecchio di 30 anni (deriando da unix). Poi leggo ciò che hanno messo in w2k
rispetto a NT4 e mi dico: se unix è vecchio perchè hanno scopiazzato?
L'unica cosa che _secondo me_ sanno fare *bene* alla MS sono le interfacce
grafiche... a ring 0... sigh...
> in quelle precedentemente citate, grandi aziende e universita'. Firmi un
> accordo e ti ritroverai circa 35 milioni di righe di codice. Poi passi una
> vita a decifrarlo :-)
...mi son perso qualche post? non ho nessun post che contenga nomi di
università dove trovare il codice (cave infinitum).
> ho parlato di asm puro?
> di debugger ne esistono di diversi tipi, alcuni anche molto 'simpatici' e
> che permettono di vedere cose che altrimenti non si vedono. poi se vuoi ti
> puoi guardare l'asm puro, perche' no...
Mi piacerebbe sapere se esiste qualche debugger più sofisticato... ma
nessuno che io conosca ti da un codice diverso dall'asm, naturalmente senza
debugging info dentro i files e senza codice disponibile.
> no, calma e gesso.
gesso? :) che vuol dire?
> OS/2 era un progetto MS/IBM e inizialmente avevano lo stesso Kernel, poi
> MS e IBM si sono divise per cazzi loro (non mi ricordo, sono passati circa
> 6 anni direi) e lo sviluppo e' stato separato, tranne, in un momento
> iniziale, la possibilita' da parte di IBM di poter incorporare in OS/2
> l'accesso ai programmi win31.
> Poi IBM con una strategia di marketing degna di un cerebroleso, ha
> decretato la morte di OS/2, che ora trovi solo in alcune grandissime
> aziende (che IBM cura personalmente) o in alcuni enti (che IBM cura
> personalmente). IBM ha fatto veramente ridere come strategia di impresa
> con OS/2 ed e' veramente un peccato perche' OS/2 era meraviglioso.
Non parlarmene... quando ho letto 'IBM abbandona il progetto OS/2' il mio
sangue ha ribollito. Se mi ricordo, la collaborazione IBM/MS è durata ben
poco... nel 94 mi pare già fosse IBM OS/2 (poi il Warp! :)... ma il vecchio
OS MS Cairo dove è finito? Con FS O-O (penso avessero in mente qualcosa tipo
HFS)...
> che il livello di integrazione fra servizi e applicazioni credo sia ancora
> piuttosto blando sotto linux.
> quando avra' piu' diffusione la gente chiedera' di piu', senza tante
> ricompilazioni, e il problema si presentara' anche sotto linux.
Infatti si sta lavorando al 'Linux Standard' per uniformare l'aspetto tra
librerie, packages, forse directories, blah, blah, tra le varie distro...
non mi ricordo l'URL, ma quello che chiedi ci sta quasi... alcune specifiche
se non sbaglio sono anche POSIX 1/2...
> ti posso garantire che ho schiantato diverse distribuzioni di linux piu'
> volte.
> con linux (anche se la situazione migliora di volta in volta) hai un
> limitato set di hardware, e io ne uso di particolari, spesso e volentieri.
> Talvolta non mi ha riconosciuto i bipro, altre volte si e' schiantato con
> la scsi, altre volte con la rete...
> per pieta' non dirmi che non so configurare. 19 anni di computer qualcosa
> mi avranno insegnato no?
A me 10 anni hanno insegnato una cosa: che il PC a volte ha una vita propria
:) C'è un problema di fondo con linux (che non è di linux): le specifiche
chiuse delle varie case, e la gente si deve fare un mazzo di reverse
engeneering per creare i drivers... fra un po' l'onda 'open' colpirà tutti
(lo sto vedendo anch'io anche con i motori geometrici... ed è solo un
esempio)
> Linux esiste in versione real-time come esiste W2K in versione realtime
> per linux vai su RTLinux.org (mi sembra) per W2K vai su www.vci.com e ti
> becchi le estensioni realtime (che hanno un certo costo) e ti becchi delle
> risposte in timing da far paura.
RTLinux e W2K non sono RTOS. Un RTOS è progettato _esclusivamente_ per
questo scopo: rispettare le specifiche di rescheduling. Questi, sono
progettati dalla punta dei piedi fino ai capelli per questo scopo, si
avvicinano a dei RTOS, ma non lo sono. VMS si. QNX si.
> Nota comunque che con nessuno dei due sistemi conviene far andare una
> centrale nucleare, a meno di non avere una pluriridondanza totale, con
> almento 3 computer per ogni processo.
> Per certe applicazioni c'e' QNX, VXWorks e... bho, non mi vengono in mente
> gli altri...
Appunto.
> Salumi
Prosciutti :)
--
Sensei <sens...@crosswinds.net>
MS Outlook : (noun) A newsreader with support for RAID 0.
MS Works : (noun) An oxymoron.
Andrea Carosi
> > Installalo su un 486/33Mhz, 20M (4 simm da 30pin da 1M, 1 simm da 72pin
> > da 16. C'era un'altra da 16M, ma e` morta) di RAM, scheda video Paradise
> > WD e scheda audio Mad16 originale (si, quella che nessun windows
> > supporta e linux si :P), due schede di rete 3com 3c503, HD da 250M IDE
> > (neanche EIDE) su controller dio-solo-sa-cosa infilato su slot VESA.
> > WinNT3.51 non vedeva l'HD. Win98 la scheda scheda audio e non ci
> > rimaneva mica spazio per nulla. Mi dice il proprietario che anche una
> > delle due schede di rete non andava.
>
> Mi spiegheresti cosa centra con win2k?
non ha 256Mb di ram e 1GB di HD (ed un processore adeguato)?
> > Ehi, sara` pure HW da schifo, ma da FireWall + router + dns server lo fa
> > bene. Anzi, su richiesta ci sono riuscito a infilare PatheticWriter e
> > una GUI grafica, per giunta. E avevo ancora un 80M libero.
>
> Su un pc simile a questo io ci facevo girare autocad e 3dstudiomax sotto
> nt4, solo che avevo un hd un po' piu' grande.
Solo per sapere, ma autocad e 3dstudio li hai messi in considerazione
del fatto che un giorno avresti potuto fregiarti del fatto di essere
riuscito ad installarli su un 486/33? Non ci credo che riuscivi ad
utilizzarli, neanche se lo vedo, con NT4 in 20MB di ram poi...
Ciao, Andrea
--
Andrea Carosi, just another linux user on a Debian woody
H.P.L.
> > No, in C++ puoi fare *TUTTO* cio' che fai in C,
> > ma il contrario non e' vero.
> Ops...
> Ad occhio e croce direi che esistono un paio di
> dimostrazioni sull'equivalenza dei linguaggi formali
> (tutti).
spiegazioni e senza mettermi in mano cose che non ho scritto.
> Inoltre i primi compilatori C++ producevano codice C,
> come output...
Il C++ si e' decisamente evoluto da allora...
> Appunto, allora scrivi in C e non in C++.
No, uso il subset C del C++. E' sempre C++ e questo porta comunque
vantaggi.
> Se devi "abbassarti" al livello C per avere prestazioni,
> vuol dire che il livello C++ non te le da.
Non ho detto questo. Ho detto che la tua affermazione e' palesemente
falsa perche' il C++, comprendendo il C, ha *per_forza* la possibilita'
di *sicuramente* le prestazioni del C /scrivendo codice alla "C"); ma e'
possibile ottenere prestazioni uguali a quelle del C anche utilizzandolo
in modo OO.
> Se uso un certo linguaggio e` perche` voglio approfittare
> di un certo tipo di approccio.
Il C++ ha piu' tipi di approccio. Che uno sia migliore degli altri non
inficia il fatto che ne abbia piu' di uno.
> Se devo scrivere un pezzo in assembly per poter avere
> prestazioni, allora lo scopo del linguaggio (in termini
> di prestazioni) fallisce, anche se mi da questa possibilita`...
Ma il C++ e' un'evoluzione del C, l'assembly invece non ha nulla a che
vedere con essi e quindi il tuo paragone non ha senso.
Ciao.
Renato 'Hitman' Salzano
schifo che mi circonda e come la cosidetta societa` civile sia basata
pensieri bofonchiando:
>>No, in C++ puoi fare *TUTTO* cio' che fai in C, ma il contrario non e'
>>vero.
> Turing, questo sconosciuto.
ROTFL!
Eggia... HPL tu lo conosci?
Renato 'Hitman' Salzano
schifo che mi circonda e come la cosidetta societa` civile sia basata
pensieri bofonchiando:
>> Rimane da convincere la MS di questo.
> MS lo dice da tempo, ma i produttori di hardware si sono adeguati
> soltanto ultimamente (e nemmeno tutti).
Perche` esiste ME allora?
Renato 'Hitman' Salzano
schifo che mi circonda e come la cosidetta societa` civile sia basata
miei pensieri bofonchiando:
>> 2. Non parlo di w2k, ma di 9x/Me che fanno schifo (IMHO ed
>> esperienza: Me ha piallato il kernel di un mio amico perchè la
>> partizione era piccola, e l'installazione non se n'era accorta...
>> ha continuato a scrivere oltre il limite della partizione windows).
>> Inoltre molte cose di w2k sono un po' troppo prese da *nix non trovi?
>> (Fonte: PCMagazine)
> ??? e con cio'? cosa hai dimostrato??? Quasi tutto ha una derivazione
> *nix, non vedo problemi.
Grazie per aver ricordato al mondo che i *nix hanno le idee migliori di
ogni SO, visto che gli altri SO le copiano :-)
>>> quando gli utenti avranno bisogno di utilizzare piu' a fondo
>>> l'integrazione fra i vari pacchetti allora ne vedremo delle belle.
>> Non ho capito cosa intendi.
> che il livello di integrazione fra servizi e applicazioni credo sia
> ancora piuttosto blando sotto linux.
Riformula la frase in italiano, grazie.
Cosi` ci ho capito poco. Che intendi per "servizi"? Che intendi per
"applicazioni"?
> quando avra' piu' diffusione la gente chiedera' di piu', senza tante
> ricompilazioni, e il problema si presentara' anche sotto linux.
Beh, non serve ricompilare nulla. I pacchetti precompilati aka binari
della Debian (per dirne una a caso) funzionano. Le installazioni
windows... beh.
>> Ma quello che ha detto è sacrosanto: un BSOD arreca danni,
>> certo
>> linux, e qui non puoi dissentire, è molto più stabile.
> ti posso garantire che ho schiantato diverse distribuzioni di linux
> piu' volte.
Capitato 1 volta in 2 anni e mezzo. Una.
Non contiamo i crash di NT e Win9x che ho visto nello stesso periodo.
> con linux (anche se la situazione migliora di volta in volta) hai
> un limitato set di hardware, e io ne uso di particolari, spesso e
> volentieri.
Ogni SO ha il suo piu` o meno limitato set HW.
Esistono HW che vanno su linux e non su Win2K/9x.
> 19 anni di computer qualcosa mi avranno insegnato no?
A non sparare sentenze affrettate, direi di no.
> Nota comunque che con nessuno dei due sistemi conviene far andare una
> centrale nucleare, a meno di non avere una pluriridondanza totale, con
> almento 3 computer per ogni processo.
In realta` questa e` una cosa che va assicurata a priori.
Anche perche se l'HW ti abbandona, nessun SO potra` farci mai nulla.
Renato 'Hitman' Salzano
schifo che mi circonda e come la cosidetta societa` civile sia basata
pensieri bofonchiando:
>> Chiudo dicendo che la SuSE7.1 su quella macchina, con Gnome e Sawmill
>> e' _decisamente_ piu' veloce di NT4. Ah, sulla macchina Linux ci
>> girano pure un paio di servizi (NNTP, SMTP, SMB, NFS, FTP, SHH, ...).
> Se hai almeno 64Mb direi che sotto nt4 dovrebbe essere piu' veloce.
> Prob. non e' configurato a dovere.
configurato) Linux da la polvere a priori a qualsiasi NT.
Simply per maggiore flessibilita`.
Renato 'Hitman' Salzano
schifo che mi circonda e come la cosidetta societa` civile sia basata
sull'ipocrisia e dominazione, Ginopilotino interruppe il corso dei miei
pensieri bofonchiando:
>>> Sentiamo un po' che hw ...
>>> Ho istallato win2k su hw da schifo e tutto e' andato liscio.
>> Installalo su un 486/33Mhz, 20M (4 simm da 30pin da 1M, 1 simm da 72pin
>> da 16. C'era un'altra da 16M, ma e` morta) di RAM, scheda video Paradise
>> WD e scheda audio Mad16 originale (si, quella che nessun windows
>> supporta e linux si :P), due schede di rete 3com 3c503, HD da 250M IDE
>> (neanche EIDE) su controller dio-solo-sa-cosa infilato su slot VESA.
>> WinNT3.51 non vedeva l'HD. Win98 la scheda scheda audio e non ci
>> rimaneva mica spazio per nulla. Mi dice il proprietario che anche una
>> delle due schede di rete non andava.
> Mi spiegheresti cosa centra con win2k?
Se non lo vedeva W98, non voglio pensare Win2K.
E per me quello e` "HW da schifo". Un Pentium 100 per me e` gia "HW
decente".
Quindi correggiamo l'affermazione: "Ho installato Win2K su HW da schifo
e tutto e` andato liscio" in "Ho installato Win2K su HW piu` che decente
e tutto e` andato liscio".
>> Poi sono entrato in scena io con un CD della Debian 2.2 appresso.
>> Ehi, sara` pure HW da schifo, ma da FireWall + router + dns server lo fa
>> bene. Anzi, su richiesta ci sono riuscito a infilare PatheticWriter e
>> una GUI grafica, per giunta. E avevo ancora un 80M libero.
> Su un pc simile a questo io ci facevo girare autocad e 3dstudiomax
> sotto nt4, solo che avevo un hd un po' piu' grande.
Se avevo un HD piu` grosso ci ficcavo molto di piu`.
E sotto NT4 quanti servizi di rete avevi attivi su quell'HW?
H.P.L.
> > Turing, questo sconosciuto.
> ROTFL!
> Eggia... HPL tu lo conosci?
ci saranno risposte del genere...
Ciao.
Ginopilotino
hitma...@yahoo.it says...
> Era il Thu, 17 May 2001 20:30:38 GMT e, mentre stavo contemplando lo
> schifo che mi circonda e come la cosidetta societa` civile sia basata
> sull'ipocrisia e dominazione, Ginopilotino interruppe il corso dei miei
> pensieri bofonchiando:
>
> >>> Sentiamo un po' che hw ...
> >>> Ho istallato win2k su hw da schifo e tutto e' andato liscio.
> >> Installalo su un 486/33Mhz, 20M (4 simm da 30pin da 1M, 1 simm da 72pin
> >> da 16. C'era un'altra da 16M, ma e` morta) di RAM, scheda video Paradise
> >> WD e scheda audio Mad16 originale (si, quella che nessun windows
> >> supporta e linux si :P), due schede di rete 3com 3c503, HD da 250M IDE
> >> (neanche EIDE) su controller dio-solo-sa-cosa infilato su slot VESA.
> >> WinNT3.51 non vedeva l'HD. Win98 la scheda scheda audio e non ci
> >> rimaneva mica spazio per nulla. Mi dice il proprietario che anche una
> >> delle due schede di rete non andava.
> > Mi spiegheresti cosa centra con win2k?
> Se non lo vedeva W98, non voglio pensare Win2K.
> E per me quello e` "HW da schifo". Un Pentium 100 per me e` gia "HW
> decente".
>
> Quindi correggiamo l'affermazione: "Ho installato Win2K su HW da schifo
> e tutto e` andato liscio" in "Ho installato Win2K su HW piu` che decente
> e tutto e` andato liscio".
HW da schifo puo' essere anche un athlon 1000. Prendi una bella scheda
madre con video, audio e cazzi vari integrati e fai un hw da schifo. Per
esempio molte delle offerte degli ipermercati sono hw da schifo. Mentre
un p100 puo essere un ottimo hw.
> >> Poi sono entrato in scena io con un CD della Debian 2.2 appresso.
> >> Ehi, sara` pure HW da schifo, ma da FireWall + router + dns server lo fa
> >> bene. Anzi, su richiesta ci sono riuscito a infilare PatheticWriter e
> >> una GUI grafica, per giunta. E avevo ancora un 80M libero.
> > Su un pc simile a questo io ci facevo girare autocad e 3dstudiomax
> > sotto nt4, solo che avevo un hd un po' piu' grande.
> Se avevo un HD piu` grosso ci ficcavo molto di piu`.
> E sotto NT4 quanti servizi di rete avevi attivi su quell'HW?
Non mi serviva nulla del genere. Non essite solo in networking.
Ciao ... Dino
Henryx
Quando? Thu, 17 May 2001 20:25:50 GMT
In quale articolo? <MPG.156e523d8...@news.libero.it>
| Prob. non e' configurato a dovere.
"Con Windows la colpa non e` mai dell'os ma dell'amministratore"
Henryx
--
===UN*X is SEXY!===
who|grep -i "green eyes"|date; cd ~; apropos fsck; whatis `unzip`|touch;
strip; finger; mount; gasp; yes|more; uptime; umount; sleep
Henryx
Quando? Thu, 17 May 2001 13:51:54 +0200
In quale articolo? <mTOM6.13610$iC1.4...@news6.giganews.com>
| > Ma si, celebriamo il nuovo cadavere !! Allelujah !
| Funziona, e bene.
Guarda, ti potrei anche dare ragione su NT, ma sul 2k mi dispiace ma hai
torto marcio
Ginopilotino
> On Thu, 17 May 2001 20:30:38 GMT, Ginopilotino wrote:
> > > Installalo su un 486/33Mhz, 20M (4 simm da 30pin da 1M, 1 simm da 72pin
> > > da 16. C'era un'altra da 16M, ma e` morta) di RAM, scheda video Paradise
> > > WD e scheda audio Mad16 originale (si, quella che nessun windows
> > > supporta e linux si :P), due schede di rete 3com 3c503, HD da 250M IDE
> > > (neanche EIDE) su controller dio-solo-sa-cosa infilato su slot VESA.
> > > WinNT3.51 non vedeva l'HD. Win98 la scheda scheda audio e non ci
> > > rimaneva mica spazio per nulla. Mi dice il proprietario che anche una
> > > delle due schede di rete non andava.
> >
> > Mi spiegheresti cosa centra con win2k?
> Il fatto che "il sistema operativo totale" di MS fallisce miseramente se
> non ha 256Mb di ram e 1GB di HD (ed un processore adeguato)?
Non hai la minima idea di quello di cui parli.
> > > Ehi, sara` pure HW da schifo, ma da FireWall + router + dns server lo fa
> > > bene. Anzi, su richiesta ci sono riuscito a infilare PatheticWriter e
> > > una GUI grafica, per giunta. E avevo ancora un 80M libero.
> >
> > Su un pc simile a questo io ci facevo girare autocad e 3dstudiomax sotto
> > nt4, solo che avevo un hd un po' piu' grande.
> Solo per sapere, ma autocad e 3dstudio li hai messi in considerazione
> del fatto che un giorno avresti potuto fregiarti del fatto di essere
> riuscito ad installarli su un 486/33? Non ci credo che riuscivi ad
> utilizzarli, neanche se lo vedo, con NT4 in 20MB di ram poi...
All'inizio avevo 18mb (4 simm30pin da 4mb + 2 simm72pin da 1mb, ma
autocad swappava troppo spesso. Allora sono passato a 32mb (2 simm72pin
da 16mb). Ho fatto anche qualche cosetta con max 1.0, ma anche in
wireframe era lentissima la visualizzaizone.
Purtroppo il pc l'ho smantellato ormai, quindi non posso farti vedere
nulla.
Per la cronaca cmq adesso ho anche un p90 con 64mb di ram che fa girare
acad2000i abbastanza bene (ovviamente sotto nt4). Certo non posso
lavorarci su file da decine di mb, ma roba normale si.
Ciao ... Dino
Ginopilotino
> Chi ha scritto? Ginopilotino <ginopilo...@nonspammare.yahoo.com>
> Quando? Thu, 17 May 2001 20:25:50 GMT
> In quale articolo? <MPG.156e523d8...@news.libero.it>
>
> | Prob. non e' configurato a dovere.
>
> "Con Windows la colpa non e` mai dell'os ma dell'amministratore"
Direi che solitamente questo vale per tutti gli os.
Ciao ... Dino