HP crede sempre più in linux

Infatti. Mi spiace che sia finita così. Purtroppo sono dell'avviso che il fanatismo porti troppo spesso ad ottenebrare la mente...

Spero che il tempo faccia il suo dovere e porti le persone a maturare, a guardare le cose sotto più punti di vista e a cercare di avere una visione quanto più ampia possibile di ciò che ci sta attorno...

x Sheijtan: già letto da tempo. E' un bel manifesto e mi trova in parte d'accordo, ma per quanto mi riguarda in qualche modo si dovrà pur sopravvivere, e io ho scelto di far diventare lavoro la mia principale passione...

re: xeal, mi sa che hai le idee un po confuse

Mi ero scusato nel post per aver usato un termine che sapevo essere improprio. Quanto alla falla, non ho parlato di linux, ma dei primi unix (per quanto ne so, linux è unix-like), inoltre, se non ricordo male il problema si poneva anche per le connessioni in remoto. Ho parlato poi di comandi "c-like" solo per rendere l'idea di quello a cui mi riferivo, magari in realtà si servivano (o potevano servirsi) anche di qualche programma in c che scendeva ad un livello molto basso, superando la supervisione del s.o., e per quanto ne so l'operazione, in qualunque modo venisse effettuata, era resa relativamente facile proprio da alcuni bug nel s.o., oltre che ad alcune caratteristiche intrinseche del sistema e del linguaggio c (vedi indirizzamento assoluto, vedi la possibilità di fare casting assurdi, ecc.). Proprio per questi motivi, per garantire la compatibilità con tutto ciò che un po' alla volta veniva dal mondo dell'open source ed evitare inconvenienti, unix è stato nel tempo implementato, scusami se uso di nuovo un termine scorretto o ambiguo, a strati, tanto da essere definito in un'articolo dei primi anni '90 (non ti do dati più precisi perchè non so dove è andato a finire) come un sistema che si interfaccia a se stesso, ma che funziona egregiamente.
Quanto al discorso sul concetto di "gratis" l'ho fatto
a)perché mi era sembrato che qualcuno avesse le idee non molto chiare sul fatto che nessuno fa niente per niente,
b) perché al di là della diatriba open/closed è una strategia di marketing che gradirei fosse adottata da tutti (suit + ricche e - care, download quasi gratis, magari con qualche limitazione sulle garanzie, ma non ovviamente sul download di eventuali patch),
c) perchè intendevo fare un discorso di carattere generale e minimamente esaustivo mirato SOLO a giungere alla conclusione finale: non facciamo di un'opinione + o - personale uno spunto per "farci la guerra", ma vediamo di dialogare facendo dei commenti il più possibile equilibrati ed obbiettivi, fondati su fatti e osservazioni concrete. Volevo dire solo questo, partendo dall'osservazione (credo e spero) concreta che nessun sistema software è perfetto, tantomeno unix o linux, senza peraltro volerne sminuire i pregi, ne voler negare il "fascino" dell'open source, magari ne verrò travolto anch'io, magari solo in maniera parziale visto che vorrei guadanarmi il pane con quello che so o che sto imparando. E con quest'ultima affermazione non voglio entrare nel merito delle licenze GPL, LGPL, ecc., poichè al riguardo non so abbastanza e non posso fare commenti costruttivi.
Comunque grazie per la precisazione sulla Shell, e comunque non mi sono offeso.

mumble, questo e` gia` leggermente diverso pero`. Coglie un'aspetto "collaterale" della GPL, ovvero il 'lavoro derivato" se ben ricordo la dizione; comunque si tratta del prodotto del programma.
Mi sembra, ma non conosco i dettagli precisi della vicenda, che il nondo della questione sia che Bison e Flex producono output che consiste anche in parti di loro stessi, e questo spiega il vincolo sull'uso del loro output: perche` questo non e` un problema intrinseco della GPL,
ma solo di una sua particolare applicazione. Vedasi infatti GCC che pur essendo GPL non
vincola (ovviamente!) i binari da lui prodotti ad essere GPL.




No. Non ci vedo (limitazione mia, probabilissimo) la validita` generale.



Non sono interessato ma seguo ogni tanto le faccende simili.



Questo e` un'altro discorso...



Oh, semplice: il CSS e` una protezione informatica, no? Bene, violarla (DeCSS) e` reato punibilie penalmente



Per ora si. Ma wmv? I i .doc del futuro? E con EUCD/Pallaidium? Fosse cosi` facile...



Inerzia. Enorme forza di inerzia. Preconcetti, e via discorrendo.
E che non costi niente non ha relativamente importanza, l'importante e` che sia Libero.
(Cosa che dice anche Stallman, per inciso)

Hai centrato pienamente il punto: Bison e Flex integrano al codice del parser generato una serie di librerie e funzioni che erano coperte da GPL, con tutte le conseguenze che hai citato. Passando alla LGPL tutto è stato risolto.



Sicuramente quello di queste due applicazioni è un caso (molto) particolare, ma mi avevi chiesto la dimostrazione di un fatto ben preciso e ti ho presentato un caso che era attinente, tutto qui.



Era solo per farti capire che, ai tempi, ho dovuto abbandonare Bison (Flex a dire il vero non l'ho mai usato, come qualunque altro analizzatore lessicale: preferisco costruirmeli di sana pianta ) e cercare una soluzione che mi permettesse di lavorare senza alcun vincolo, come hanno fatto anche tanti altri...

Per inciso: nella sfortuna ho avuto la fortuna di trovare TPYacc, che oltre ad essere totalmente free, genera anche codice Pascal...



Dipende dalle leggi vigenti nei vari stati. Non so se in questo caso incapperesti dei problemi in Italia, perché non ricordo più tutti i vincoli della legge varata tempo fa per quanto riguarda l'hacking e il software in generale.

Penso, comunque, che comprando un DVD ottieni il diritto ad usufruirne "pienamente" del bene, per cui se il CSS dovesse contrastare questo tuo diritto acquisito, dovrebbe decadere il reato dell'aggiramento della protezione (sempre se esista realmente: come ho detto non ricordo bene).

Forse qualcuno che mastica un po' di diritto informatico potrebbe chiarire la situazione, se ne è al corrente...



Si tratta di un formato proprietario, come pure il wma, ecc. Non penso che dei player non siano realizzabili...



Saranno in formato XML...



Non lo è, e Palladium mi spaventa non poco, per le implicazioni pratiche che porterebbe la sua completa implementazione.

Certamente non voglio con un mondo dominato da una sola persona, come ho già detto altre volte...



Questo è vero, ma con tutto ciò Linux si sta affermando sempre di più. A mio avviso le cose potrebbero veramente migliorare in tal senso, avendo la disponibilità di distribuzioni più user friendly.

Poi all'italiano non piace pagare , per cui se trova una scappatoia altrettando valida, si butta a pesce.



Non conosco Stallman, ma apprezzo questa sua affermazione...

P.S. In precedenza ho commesso un grossolano errore, riferendomi a Flex: non è un analizzatore semantico (ci mancherebbe! ), ma lessicale...

Il problema è che e Majore le grandi aziende di software tendo sempre più a limitare la tua possibilità di usufruire pienamente del bene acquistato... vedi i vari CD Audio protetti che ci sono in giro... e se voglio farmi una copia ad uso personale come faccio?



Appunto propietario... non è detto che sia possibile farci un player sopra... senza documentazione... devi fare il più delle volte reverse e non è detto che riesca o sia possibile senza violare il copyright




Speriamo... ma anche qui non ritengo che sia così scontata la cosa

Nella fretta è probabile che non sia riuscito a frmi capire... speriamo di si

Infatti è una cosa che mi dà parecchio fastidio...



Usi qualche buon vecchio masterizzatore che ti permette di farlo...

A parte gli scherzi, mi trovi d'accordo su tutta la linea...



Questo lavoro è già stato fatto con lo zip, e non ne ha infranto i copyright. Il DivX è arrivato come hack del asf/wmv e poi è andato avanti per i fatti suoi...

Le possibilità, quindi, di realizzarlo ci sono tutte: resta da vedere se c'è gente disposta a perderci del tempo, come per il DeCSS...



Office 2003 utilizzerà XML come nuovo formato per tutti i documenti della suite, per cui non vedo alcun problema, anzi!



Ti sei fatto capire benissimo, non ti preoccupare... Poi se vedi i miei messaggi sono stracolmi di errori, anche gravi, ma ho poco tempo per rileggerli e molto meno per poterli correggere...

Architetture CPU ed OS

Il prof che ha detto che l'8088 era un ottimo processore o era un po' ignorante oppure un venduto...

Ai tempi dell'8088 (o poco dopo) esisteva anche il motorola 68000... famose furono le confessioni di un ingegnere progettista per la IBM del primo modello di PC: l'IBM gli chiese espressamente di scegliere una CPU lenta e con poca memoria in modo che il sistema si sarebbe potuto espandere in seguito... il "super-potente" 68000 (era già a 32 bit interni e parliamo del 1979...!) fu scartato subito, e si scelse l'"ottimo" 8086 ad 8/16 bit...

meditate gente...

Emiliano

Re: Architetture CPU ed OS

Si parlava di didattica. E l'8086/8088 non era male come processore
Non dimenticare che all'università si fa didattica e non un forum.
Posso quindi ricordarti le (inutili) complicazioni che avrebbe portato lo studio del 68000. Innanzitutto era si a 32 bit ma i bus dell'epoca erano a 16 bit. La motorola aveva scommesso sul fatto che l'hardware sarebbe migrato verso i 32 bit ed ha avuto ragione. Quindi (sempre a livelllo didattico) la gestione del bus di dati era una inutile complicazione.
Aveva troppi registri - mi riferisco sempre al punto di vista dello studente che si affaccia per la prima volta ad un corso di calcolatori - e questi registri erano suddivisi in registri di dati e di indirizzi. E anche la ALU era a 16 bit...

Quindi caro Skywalk3r, renditi conto che la "filosofia" si fa sui forum. Perchè non hai tirato fuori anche lo Zilog Z80 o lo Z8000 (tanto per dar torto alla gente)?


Non a livello didattico:
Per quanto riguarda poi il gestore degli interrupt quello dell'8088 era molto buono e anche superiore al quello del motorola, che seppur più veloce, in certe situazioni si perdeva l'interrupt con più alta priorità. Il 68000 aveva anche altri problemi nella gestione di alcune eccezioni.
Infine l'8088 era figlio dell'8085 e nipote dell'8080. Il motorola era nuovo. Gli ingegneri tendono ad essere conservativi, le aziende valutano anche i costi.

In ogni caso il 68000 ha aperto un epoca, esattamente come l'8088


Che vuol dire



memoria indirizzabile?

Re: Architetture CPU ed OS

Indubbiamente: ha fatto storia, come ben sappiamo...



Complicazioni? Mumble, mumble...



Infatti il 68000, pur possedendo un'architettura interna a 32 bit, aveva bus dati esterno a 16 bit (come i processori a 16 bit dell'epoca) e indirizzi a 24 bit.

Ma esisteva anche una versione estremamente più semplice ed economica, il 68008, che aveva il bus dati esterno ad 8 bit e quello indirizzi a 20 bit: il candidato ideali per realizzare computer molto economici, tipo C64 & co.



Il target iniziale di questo processore, infatti, erano le workstation. HP lo utilizzò (specialmente nelle successive versioni) nelle famosissime "Apollo"...



Vedi sopra... C'è da dire poi, che la gestione dei bus è molto più semplice nel 68000 rispetto all'8086, visto che quest'ultimo aveva quello indirizzi multiplexato con quello dei dati, per cui prima doveva spedire l'indirizzo, poi la logica esterna avrebbe dovuto memorizzarlo (circuiteria più complessa e costosa) ed infine avrebbe potuto leggere o scrivere i dati che gli interessavano.



Beh, anche l'8086 ha 8 registri, che rispetto ai 3 del 6502 sembravano un'infinità, ed inoltre erano tutti "specializzati" (AX = general purpose, BX/SI/DI/BP/SP = indirizziamento, CX = contatore, DX = dati ausiliari, SI/DI = gestione "stringhe".

Il 68000, da questo punto di vista, garantiva una semplicità e simmetria nell'architettura disarmante: 8 registi dati sui quali potevi farci TUTTI i calcoli indistintamente, e 8 per gli indirizzi (di cui uno usato come stack pointer).



Infatti "suddivideva" i calcoli a 32 bit in due elaborazioni (erano necessari il doppio di cicli di clock).



Perché andare a complicarci la vita? Proprio perché all'università si studia, meglio un 68000, che oltre ad avere un'architettura molto semplice, poteva contare su una cinquantina di istruzioni soltanto, contro le centinaia dell'8086, dello Z80 e dello Z8000...



Mi spiace, ma è l'esatto contrario: quello del 68000 era ed è anni luce avanti. Infatti l'8086 permette di utilizzare solamente due tipi di interrupt: l'IRQ classico e l'NMI non mascherabile.

Il 68000 permette, invece di avere ben 7 livelli di interrupt suddivisi per "priorità", e non si verifica alcuna perdita di interrupt con più alta priorità. Forse ti riferisci che un interrupt di livello 7, il più alto in assoluto, non lo si può interrompere? E' anche logico che sia così, perché ha le funzioni che nell'8086 sono attribuite all'NMI...



Nessun problema. Forse ti riferisci al fatto che, rispetto ai suoi "fratelloni", ne poteva gestire di meno. Ma d'altra parte, le nuove eccezioni che sono state introdotte successivamente, andavano a coprire nuove esigenze che s'erano create. Ad esempio, quelle del 68010 permettevano già di poter gestire un sistema con la memoria virtuale...



Diciamo che anche il 68000 era "figlio" del 6800...



E' vero, ma così facendo commissero un grosso errore...



Già. Quanti bei ricordi...



Anch'io vorrei saperlo...

Re: Architetture CPU ed OS

Si parlava di 68000



http://www.wikipedia.org/wiki/Motorola_68000
Non era quello che cercavo, ma mi sono perso l'indirizzo.



Vedi prima



Era la versione "rivista" , il 68000 non mi pare lo facesse, ma forse mi sbaglio...la mia memoria ha forti limiti e mi manca la documentazione cartacea



giusto...

Infine, l'universo tecnologico è pieno di scelte sbagliate

Per tutto il resto hai ragione tu, quoque Homerus... anche se io non sono Homerus