IBM investe su Linux ottimizzato per PowerPC

X nicgalla

Certo, anche M$ ha l'assistenza telefonica eccetera, e forse trovare un buon tecnico LINUX è + difficile che trovarne uno Windows, ma se IBM vende i propri server con installato LINUX, non credi che chieda ai propri rivenditori di fare in modo di garantire anche l'assistenza, non credo che le aziende (e sono la maggioranza) che non hanno un addetto interno al reparto informatico, che comprano i prodotti IBM o HP o qualsiasi altro, restano senza assistenza perchè c'è installato LINUX, ci penserà chi gli ha venduto il server con i programmi a farla ed agli stessi costi sia per Linux che per Windows.
Potrebbe essere diverso per le aziende che avendo il reparto informatico interno dovessero convertire i tecnici Windows in Linux, ma queste in genere sono aziende grandi e le cifre in ballo sono enormi in ogni caso.
Comunque tornando al discorso LINUX, sono sempre + le software house fornitrici di programmi per la gestione aziendale che stanno migrando le proprie applicazioni su LINUX, alcune che conosco hanno addirittura abbandonato Windows e altre lo affiancano, e altre ancora non hanno considerato affatto LINUX, però è innegabile che chi offre soluzioni LINUX può contare su un costo iniziale di licenze molto inferiore, basta pensare a quanto costa una distro RedHat e una licenza Windows 2000 server.

Cionci, ok, daccordo con te ma, se leggi bene quello che ho scritto, noterai che non diciamo cose differenti. Quello che volevo dire io è che non credo assolutamente che il codice Microsoft sia scadente o sia più scadente di quello del kernel Linux. Per il resto sappiamo entambi che i cicli interni sono i più critici, come lo sanno tutti i programmatori. Lo sanno anche quelli di Microsoft che per le routine di ordinamento in excel o access non useranno il bubble sort.

Io non li ho mai provati. Ho verificato il codice assembly generato dai compilatori Microsoft, Borland e gcc (x dos), oltre che misurato la velocità di esecuzione e vinceva il gcc.

Inoltre devo dire - e ci tengo a dirlo - che il gcc era un compilatore con le ... insomma un ottimo compilatore. Per colpa del borland (e anche del gcc) ho preso 25 all'esame di sistemi informativi. Il prof si era "accorto" di un warning del gcc che il borland non mi dava. Il problema è che il warning nascondeva un bug pericoloso ma soprattutto un errore concettuale grave. Il prof mi ha chiesto perchè io non ho saputo rispondere: 25!

Vabbè. Io il kernel linux me lo compilo quasi ogni settimana. Ho usato RedHat con il kernel per 386, mandrake con kernel per 586 e il kernel compilato da me per Athlon. Conclusione: a occhio le differenze erano impercettibili (uno o due secondi non cambia la vita). Mi era venuto lo sfizio di compilare xfree e kde e ottimizzarlo per il mio processore. Ho iniziato con kde, ma dopo circa 4 ore di compilazione mi sono stufato. Forse hai ragione tu. Forse compilando xfree e kde risparmierò quei 10 secondi. Ma tenendo conto che ci vogliono circa 24 ore per farlo (nel caso migliore) e che io nel caso migliore carico kde 30 secondi prima, ci vorranno ben 2900 boot prima di recuperare il tempo perso nella compilazione. 2900 boot li faccio (ad essere generoso) in 290 giorni. Prima di questi 290 giorni uscirà sicuramente una nuova versione di xfree e di kde. Punto e daccapo. Ho perso il mio tempo e non ho tempo da perdere o una macchina dedicata esclusivamente alla compilazione.
Come vedi bisogna considerare non solo i risultati ottenuti ma anche lo sforzo impiegato nell'ottenerli e valutare benefici e costi.


Discorso a parte la configurazione del kernel. Questa non c'entra affatto con discorsi di ottimizzazione...non quelli a cui mi riferisco io con questo post o con i precedenti. Scegliendo io la configurazione del kernel, il tempo di boot, ovviamente, diminuisce in modo sensibile. Ma per compilare il kernel ci vogliono 30 minuti.

Compilazione.

Ha ragione OninO.
Xfree l'ho compilato una volta, ma e' stata una vera rottura di scatole.
Adesso preferisco scaricare i pacchetti gia' compilati.

Pero' il kernel e' un'altra cosa, lo compilo abbastanza spesso.
Mi piace provare le varie opzioni ed i vari moduli, provarci le patch, vedere come va.
E le differenze si vedono, nel tempo di boot.
Mi piace anche curiosarci dentro, tra il codice.
Ci perdo tempo, pero' mi diverto!:P

Infatti: è risaputo che quei compilatori non generano buon codice...

Adesso non trovo più il link, ma avevo pescato una pagina in cui c'erano numerosi test fra compilatori M$ VisualStudio 7.0 (Beta), GCC e Intel, e mostravano quel che ho scritto: i compilatori Intel sono quasi sempre i migliori.

Per inciso, dal VisualStudio 6 al 7 la generazione del codice è molto migliorata.



Lo so. E per giunta free...



Capita quando si utilizzano compilatori diversi. Magari il compilatore Borland aveva dei settaggi più "rilassati" per quanto riguarda la generazione dei warning...

Ma dopo averlo sviluppato col Borland, perché non hai provato a compilarlo subito col GCC? Specialmente in vista di un esame, penso sia di fondamentale importanza arrivare con la sicurezza di non incapparre in problemi come questo...



Per curiosità, che cosa avevi combinato di così grave?

Per mia abitudine, quando sviluppo, tengo tutti warrnng settati. Non si sa mai Il borland (ti parlo del Borland C++ 3.0) questo tipo di warning non lo considerava.



Eh eh eh...e chi lo conosceva ai tempi quando l'ho visto funzionare mi sono detto: lo devo avere. Mi sono trovato bene col gcc.



Beh, errore stupido. Avevo allocato una stringa nel corpo di una funzione e poi ho passato il puntatore alla stringa come valore di ritorno e poi copiavo la stringa puntata. Non mi dava alcun problema ma è concettualmente un errore grave. Il programma era funzionante (l'unico tra tutti...grrr) ma il prof mi chiede di spiegare quel warning...e io non ho risposto (tra l'altro non avevo nemmeno capito la domanda ). Ero ancora alle prime armi. Avevo imparato da poco il C.

Re: Compilazione.

Anche a me piace. Lo farei anche più spesso. Peccato che Mandrake usa kernel personalizzati Non sono ancora pronto per Debian o Slackware