Link alla notizia: http://www.hwupgrade.it/news/software/20459.html

Dell raccoglie informazioni dagli utenti per valutare eventuali configurazioni con Linux preinstallato

Click sul link per visualizzare la notizia.

L'argomento è estremamente vasto e delicato; proprio questi aspetti giustificherebbero la cautela di Dell nel prendere una posizione ben definita
Tanto alla fine scelogono come tutti Red Hat Enterprise e/o Suse.

Su un client ubuntu è secondo me la scelta da prediligere attualmente, per vivacità della comunità, release a cadenze stabili e con un colosso dell?HW come Dell alle spalle potrebbe fare il definitivo salto di qualità

ma perchè le aziende non rilasciano i sorgenti dei loro driver? in fondo l'innovazione sta nell'hardware, no nel software, che serve solo per il corretto funzionamento.

@spannocchiatore

Ed i monopoli fondati ed artificialmente mantenuti su di un mercato chiuso e stagnante come intendi mantenerli?

un raro esempio di democrazia :-)

Va a finire che venderanno sistemi con linux senza assistenza :asd:

ma perchè le aziende non rilasciano i sorgenti dei loro driver? in fondo l'innovazione sta nell'hardware, no nel software, che serve solo per il corretto funzionamento.

nn è vero pure il saper scrivere un software è un arte, poi tutti starebbero a copiarsi gli algoritmi, e cmq da un driver si potrebbe capire molto di una architettura

Debian is Gnu/Linux for excellence!

Debian is Gnu/Linux for excellence!

Debian ha solo tanto nome e pochi fatti, excellence proprio per niente, per lo meno da chi i sistemi operativi li usa per lavorare e produrre.
Tutti i principali registrar, web hosting/domini utilizzano principalmente Fedora Core, nell'ambito enterprise sono tutti orientati su Solaris 10, RedHat Enterprise Linux (a proposito, ieri è uscita la versione 5.0), Suse e Novell. Per l'uso "utonto", Ubuntu spopola.

Debian è solo l'OS di chi vuol far vedere che sa usare Linux (senza riuscirvi, per altro)

Va a finire che venderanno sistemi con linux senza assistenza :asd:

Perchè che cosa ci sarebbe di male?

Io sinceramente sono in parte d'accordo con spannocchiatore, i driver secondo me dovrebbero essere open, in modo che favoriscano i seguenti punti:
1) concorrenza sugli OS
2) compatibilità su più os
3) maggior diffusione tra gli utenti
4) evoluzione del codice e quindi ottimizzazione e ampliazioni sulle funzionalità dell'hw

Debian ha solo tanto nome e pochi fatti, excellence proprio per niente, per lo meno da chi i sistemi operativi li usa per lavorare e produrre.
Tutti i principali registrar, web hosting/domini utilizzano principalmente Fedora Core, nell'ambito enterprise sono tutti orientati su Solaris 10, RedHat Enterprise Linux (a proposito, ieri è uscita la versione 5.0), Suse e Novell. Per l'uso "utonto", Ubuntu spopola.

Debian è solo l'OS di chi vuol far vedere che sa usare Linux (senza riuscirvi, per altro)

forse non sai che ubuntu non è altro che Debian Etch.

Quindi evita di spalare merda se non sai e oltretutto evita di offendere per cortesia, non che ti voglia reportare anche perchè sai che me ne frega? nulla, un'utente in meno che spala merda per sport non mi cambia la vita :)

ps: sai perchè usano fedora core o redhat? fai 1+1 quando hai finito posta la soluzione e ti dico se è sbagliata o no ;)

e cmq da un driver si potrebbe capire molto di una architettura
Ancora sto aspettando che qualcuno mi porti un solo esempio in cui un driver libero è stato sfruttato da un concorrente per copiare l'hardware.

Ancora sto aspettando che qualcuno mi porti un solo esempio in cui un driver libero è stato sfruttato da un concorrente per copiare l'hardware.

infatti è quello che sto sostenendo da una vita, i driver open portano solo sviluppo maggiore per l'azienda stessa e agli utenti che si forniscono da essa.

infatti è quello che sto sostenendo da una vita, i driver open portano solo sviluppo maggiore per l'azienda stessa e agli utenti che si forniscono da essa.

questa è tutta da dimostrare, soprattutto per lo sviluppo dell'azienda.

questa è tutta da dimostrare, soprattutto per lo sviluppo dell'azienda.

Nvidia.
dico solo questo.


Driver open -> supporto linux/mac/windows -> maggior raggio di utenti -> più maneggiati -> maggior ottimizzazione -> più $

Ati:
Driver closed -> fanno cagare -> supporto windows -> meno utenti -> driver non maneggevoli -> meno ottimizzazione -> meno $

non mi pare sia un discorso troppo difficile :)

infatti è quello che sto sostenendo da una vita, i driver open portano solo sviluppo maggiore per l'azienda stessa e agli utenti che si forniscono da essa.
I driver open per linux sono una rogna di non poco conto per le aziende; ma per fortuna ci abbiamo pensato:
http://www.kroah.com/log/linux/free_drivers.html

I driver open per linux sono una rogna di non poco conto per le aziende; ma per fortuna ci abbiamo pensato:
http://www.kroah.com/log/linux/free_drivers.html

leggi il mio post sopra il tuo ;)

Nvidia.
dico solo questo.


Driver open -> supporto linux/mac/windows -> maggior raggio di utenti -> più maneggiati -> maggior ottimizzazione -> più $

Ati:
Driver closed -> fanno cagare -> supporto windows -> meno utenti -> driver non maneggevoli -> meno ottimizzazione -> meno $

non mi pare sia un discorso troppo difficile :)

Sicuro che i driver nVidia siano Open? a me risulta che siano rilasciati da nVidia, e ancor più della dimostrazione che non sono Open basta vedere le rotture che hanno avuto i vari Optimizer di driver nVidia.

leggi il mio post sopra il tuo ;)
Ehm non ho capito... :stordita: intendi dire che i driver nvidia sono "open"?

Sicuro che i driver nVidia siano Open? a me risulta che siano rilasciati da nVidia, e ancor più della dimostrazione che non sono Open basta vedere le rotture che hanno avuto i vari Optimizer di driver nVidia.
http://linux.html.it/articoli/leggi/2142/nouveau-driver-open-source-per-schede-video-nvidia/

http://linux.html.it/articoli/leggi/2142/nouveau-driver-open-source-per-schede-video-nvidia/
http://nouveau.freedesktop.org/wiki/

Currently, nothing works. If you're not a developer, you're not interested in this at all.

ragazzi non facciamo diventare la solita discussione è meglio linux è meglio windows e non basiamoci solo sui dvr video di ati o nvidia,
visto che linux da quel pò che ho visto con le suddette vga anche con i dvr close riesce degnamente a far girare qualcosa.
non sono loro il problema per 2 colossi del genere se si impegnano fare dvr linux decenti close non cambia nulla sempre se ovviamente c'è il numero sufficente di utenti a cui vendere le vga.
il problema sono tutte le altra periferiche che gravitano attorno al mondo pc,vedi webcam hd portatili schede di acquisizione tv e tutte le altre periferiche che non hanno un utilizzo generale.
senza contare che parlate di ati o nvidia ma a questo punto tocherebbe andare da amd,intel,via e dirgli di fare i dvr free anche x i chipset...ati forse ma sn sicuro intel propio no^^.
a questo si aggiunge il fatto di un leggero timore se dell entra nella vendita di sistemi linux non pensate che possa far pressione con tanti soldi sugli sviluppatori e di fatto rendere linux free è vero ma indirizzato solo nella sua direzione.
aziende come dell non possono permettersi di dare sistemi free ma con un supporto software non capilarre o con aggiornamenti che non sono programmati ma a tempo di "comunity"
a questo punto si regolarizzerebbe tramite i soldi di dell le uscite degli aggiornamenti snaturando di fatto il progetto linux.

senza contare che dell è una azienda e come tale se qualcosa va storto con probabilità potra chiedere danni economici,allora finche c'è microsoft che è un altra azienda se fanno sistemi difettosi se la prendono con loro del tipo "o mi fai il SO funzionante o ti cito in giudizio visto che pago le tue licenze" mentre credete che le case di produzione linux abbiano le risorse economiche e di personale per poter cmq essere parate da situazioni del genere?

non sono un fan ne di win ne di linux secondo me sono 2 so complementari se ti serve fare una cosa usi win per un altra usi linux,ma non riesco a capire chi con 1 dei 2 so pretende di fare anche le altre cose dove l'altro so è meglio e pretende di farle alla stessa maniera e con gli stessi risultati dell'altro so

Ehm non ho capito... :stordita: intendi dire che i driver nvidia sono "open"?

Infatti non sono rilasciati da nVidia, ma è un progetto a se stante per la creazione di driver Open per nVidia per il supporto al 2D e al 3D.

il problema sono tutte le altra periferiche che gravitano attorno al mondo pc,vedi webcam hd portatili schede di acquisizione tv e tutte le altre periferiche che non hanno un utilizzo generale.
Ti interesserà sapere che il s/o che supporta "out of the box" il maggior numero di periferiche, sul maggior numero di processori, nel maggior numero di architetture, è proprio linux ;)

senza contare che parlate di ati o nvidia ma a questo punto tocherebbe andare da amd,intel,via e dirgli di fare i dvr free anche x i chipset...ati forse ma sn sicuro intel propio no^^.
Parliamone, invece :)
Intel realizza in proprio tanti driver liberi, dalle schede 3d ai dispositivi wifi.

a questo si aggiunge il fatto di un leggero timore se dell entra nella vendita di sistemi linux non pensate che possa far pressione con tanti soldi sugli sviluppatori e di fatto rendere linux free è vero ma indirizzato solo nella sua direzione.
aziende come dell non possono permettersi di dare sistemi free ma con un supporto software non capilarre o con aggiornamenti che non sono programmati ma a tempo di "comunity"
Infatti non hanno ancora deciso nulla. Tutto è nato da una poll, dove Dell chiedeva cosa avrebbero voluto gli utenti nei loro sistemi. Sorprendentemente, ha vinto "linux" (con un interessante secondo posto per OpenOffice).
Quindi, ora Dell sta facendo una seconda raccolta dati, per sapere gli utenti cosa intendono di preciso. In questa raccolta si chiede anche, tra le altre cose, che tipo di supporto ci si aspetta da Dell.
Una volta che avranno i dati, vedremo che conclusioni trarranno.

Infatti non sono rilasciati da nVidia, ma è un progetto a se stante per la creazione di driver Open per nVidia per il supporto al 2D e al 3D.

esatto, però il progetto è in crescita e i driver cmq funzionano, il problema e che sono da compilarseli e sono pensantini in confronto a quelli ufficiali.

E comunque il discorso mio qual'è:
Le periferiche multiplatform vanno molto di più rispetto a uno che viaggia solo sotto un'os, ati questo non l'ha ancora capito, idem tante altre società.

E poi i costi di sviluppo dei driver non sono pochi, mentre una community che sviluppa driver e software per conto loro, con un pò (logicamente) di supporto da parte delle case produttrici diminuirebbe i costi delle periferiche, quindi ci guadagnamo noi e le aziende.

forse non sai che ubuntu non è altro che Debian Etch.

A parte che ubuntu con debian ormai non c'entra più una bega se non per PARTI del formato dei pacchetti, che già mantiene la stessa estensione ma mostra incompatibilità nella struttura dei repository e nei metodi di autenticazione del pacchetto.

Specialmente rapportando Ubuntu (edgy) con Debian (etch) davvero non c'è nemmeno un pacchetto in comune. Nè sono uguale le relazioni di dipendenze, nè è uguale nient'altro.

A parte che ubuntu con debian ormai non c'entra più una bega se non per PARTI del formato dei pacchetti, che già mantiene la stessa estensione ma mostra incompatibilità nella struttura dei repository e nei metodi di autenticazione del pacchetto.

Specialmente rapportando Ubuntu (edgy) con Debian (etch) davvero non c'è nemmeno un pacchetto in comune. Nè sono uguale le relazioni di dipendenze, nè è uguale nient'altro.

sarà come dici tu, però io ho xgl, driver e tante altre cose prese da ubuntu e ho una debian etch :mbe:

per kernel, servizi di default e tante altre cose ti dò ragione, ma prova a fare $ cat /etc/debian_version su un'ubuntu ;)

esatto, però il progetto è in crescita e i driver cmq funzionano, il problema e che sono da compilarseli e sono pensantini in confronto a quelli ufficiali.

E comunque il discorso mio qual'è:
Le periferiche multiplatform vanno molto di più rispetto a uno che viaggia solo sotto un'os, ati questo non l'ha ancora capito, idem tante altre società.

Vero se Linux avesse almeno il 15% del mercato, ma la realtà è molto più ristretta e le aziende evidentemente non trovano conveniente sobbarcarsi il costo dello sviluppo driver per Linux. In questa maniera Linux non si espande... lo so è un cane che si morde la coda.

E poi i costi di sviluppo dei driver non sono pochi, mentre una community che sviluppa driver e software per conto loro, con un pò (logicamente) di supporto da parte delle case produttrici diminuirebbe i costi delle periferiche, quindi ci guadagnamo noi e le aziende.

Il problema credo che riguardi proprio le modalità di sviluppo dei driver. Potrei dire una castroneria ma molto probabilmente per crearne uno che supporti a pieno tutte le funzionalità di una periferica bisognerebbe conoscere tutti i dettagli e i segreti della periferica stessa, e le aziende sappiamo bene quanto ci tengano ai propri segreti industriali.

e le aziende evidentemente non trovano conveniente sobbarcarsi il costo dello sviluppo driver per Linux.
Ancora...
http://www.kroah.com/log/linux/free_drivers.html


Il problema credo che riguardi proprio le modalità di sviluppo dei driver. Potrei dire una castroneria ma molto probabilmente per crearne uno che supporti a pieno tutte le funzionalità di una periferica bisognerebbe conoscere tutti i dettagli e i segreti della periferica stessa, e le aziende sappiamo bene quanto ci tengano ai propri segreti industriali.
Vorrei che qualcuno mi spiegasse cosa esattamente intendeva difendere ATI quando ha negato a certi sviluppatori informazioni su come attivare il TV-OUT di alcune loro schede video.
Oppure, come ATI ha magicamente rilasciato sotto opportune pressioni le ultrasegrete specifiche dell'R200 quando fino al giorno prima erano segreto di stato.
Ancora, qualcuno che mi giustifichi il comportamento di ATI in questo caso:
http://airlied.livejournal.com/31180.html

Vero se Linux avesse almeno il 15% del mercato, ma la realtà è molto più ristretta e le aziende evidentemente non trovano conveniente sobbarcarsi il costo dello sviluppo driver per Linux. In questa maniera Linux non si espande... lo so è un cane che si morde la coda.



Il problema credo che riguardi proprio le modalità di sviluppo dei driver. Potrei dire una castroneria ma molto probabilmente per crearne uno che supporti a pieno tutte le funzionalità di una periferica bisognerebbe conoscere tutti i dettagli e i segreti della periferica stessa, e le aziende sappiamo bene quanto ci tengano ai propri segreti industriali.

facendo cmq reverse engineering dovresti scoprire cose "nascoste" delle schede, ma non è così, idem per tutte le aziende che hanno rilasciato i driver open.

Vedasi intel, realtek e tante altre.

sarà come dici tu, però io ho xgl, driver e tante altre cose prese da ubuntu e ho una debian etch :mbe:

XGL è una roba molto "a sè stante", quindi tecnicamente dovrebbe potersi installare tranquillamente su debian senza lamentele particolari, anche perchè dipende semplicemente da xorg, che --più o meno-- è pacchettizzato uguale (o perlomeno i pacchetti principali hanno lo stesso nome**).
Quindi non ho motivo per non crederti.

Per il resto, dipende sempre da cosa hai portato... ai tempi di Warty (4.10) si poteva travasare facilmente molta roba da debian ad ubuntu e viceversa, a patto che non si trattasse di pacchetti "core" (per esempio gnome 2.8 di debian e gnome 2.8 di ubuntu erano palesemente diversi in gnome-panel e gnome-session, e l'installazione di uno sull'altro generava casini non da poco), ma poi la cosa è andata via via peggiorando, fino ad arrivare ad una totale incompatibilità di qualunque cosa tra dapper e la testing di allora (etch).

Ora le cose sono *leggermente* migliorate perchè debian si è messa ad importare alcune "policy" da ubuntu, come per esempio le convenzioni per la pacchettizzazione di xorg, ma se metti i repository debian nel sources.list di ubuntu edgy, apt-get update ti risponde un pernacchione, sappilo :)

**: precisazione... in ubuntu/debian/distro_su_deb è relativamente semplice installare pacchetti di una distribuzione su un altra in quanto è sufficiente che nome e versione delle dipendenze corrispondano. Non viene infatti effettuato (a differenza di quanto fa fedora con yum e rpm, per esempio) alcun controllo sul contenuto effettivo del pacchetto, e su cosa esso installa.
Se, per esempio (il caso è inventato a puro scopo illustrativo), su ubuntu ho xorg-core e su debian ho xorg-core e xorg-core-lib, dove lo xorg-core di ubuntu rappresenta la somma dei due pacchetti debian, un programma che richiederà come dipendenza solo xorg-core si installerà sia su debian, sia su ubuntu, senza accorgersi di cosa richiamino effettivamente quei pacchetti. Tuttavia, in caso di installazione su debian, se xorg-core-lib non fosse per qualche motivo presente ed il pacchetto fosse originariamente stato fatto per ubuntu, il programma non funzionerebbe.
Questo aspetto ha alcuni lati positivi ed alcuni lati negativi... dipende da quello che si cerca :)
Di sicuro, per tornare al nostro discorso, questa caratteristica "collaterale" dei pacchetti deb ti ha sicuramente dato una mano per "simulare" una compatibilità debian/ubuntu che in realtà non c'è assolutamente.

se la dell mettesse "di serie" linux su tutti i pc finalmente winzozz prenderebbe una bella mazzata e la gente imparerebbe ad usare linux

per kernel, servizi di default e tante altre cose ti dò ragione, ma prova a fare $ cat /etc/debian_version su un'ubuntu ;)

Beh, dammi 20 secondi e ti faccio vedere che funziona la stessa cosa anche su Gentoo :D
Se non ricordo male, tale file esiste per assicurare la compabitlità con applicativi che cercano il tipo di distribuzione.

Anche Fedora ha dentro i file di release di redhat enterprise, ma non per questo se sposti pacchetti da una all'altra non provochi catastrofi iperboliche.

XGL è una roba molto "a sè stante", quindi tecnicamente dovrebbe potersi installare tranquillamente su debian senza lamentele particolari, anche perchè dipende semplicemente da xorg, che --più o meno-- è pacchettizzato uguale (o perlomeno i pacchetti principali hanno lo stesso nome**).
Quindi non ho motivo per non crederti.

Per il resto, dipende sempre da cosa hai portato... ai tempi di Warty (4.10) si poteva travasare facilmente molta roba da debian ad ubuntu e viceversa, a patto che non si trattasse di pacchetti "core" (per esempio gnome 2.8 di debian e gnome 2.8 di ubuntu erano palesemente diversi in gnome-panel e gnome-session, e l'installazione di uno sull'altro generava casini non da poco), ma poi la cosa è andata via via peggiorando, fino ad arrivare ad una totale incompatibilità di qualunque cosa tra dapper e la testing di allora (etch).

Ora le cose sono *leggermente* migliorate perchè debian si è messa ad importare alcune "policy" da ubuntu, come per esempio le convenzioni per la pacchettizzazione di xorg, ma se metti i repository debian nel sources.list di ubuntu edgy, apt-get update ti risponde un pernacchione, sappilo :)

**: precisazione... in ubuntu/debian/distro_su_deb è relativamente semplice installare pacchetti di una distribuzione su un altra in quanto è sufficiente che nome e versione delle dipendenze corrispondano. Non viene infatti effettuato (a differenza di quanto fa fedora con yum e rpm, per esempio) alcun controllo sul contenuto effettivo del pacchetto, e su cosa esso installa.
Se, per esempio (il caso è inventato a puro scopo illustrativo), su ubuntu ho xorg-core e su debian ho xorg-core e xorg-core-lib, dove lo xorg-core di ubuntu rappresenta la somma dei due pacchetti debian, un programma che richiederà come dipendenza solo xorg-core si installerà sia su debian, sia su ubuntu, senza accorgersi di cosa richiamino effettivamente quei pacchetti. Tuttavia, in caso di installazione su debian, se xorg-core-lib non fosse per qualche motivo presente ed il pacchetto fosse originariamente stato fatto per ubuntu, il programma non funzionerebbe.
Questo aspetto ha alcuni lati positivi ed alcuni lati negativi... dipende da quello che si cerca :)
Di sicuro, per tornare al nostro discorso, questa caratteristica "collaterale" dei pacchetti deb ti ha sicuramente dato una mano per "simulare" una compatibilità debian/ubuntu che in realtà non c'è assolutamente.

Di xgl sicuramente è come dici tu, che ubuntu sia stato "modificato" fin li non ci piove, ma "coso" (non ricordo il nome dell'utente che spalava merda su debian) sparava cazzate mostruose, tipo "debian è da sboroni ecc" e l'ho ripreso dicendo che ubuntu è base debian, quello è il concetto che volevo far capire, se debian non fosse esistita ubuntu sarebbe ancora da creare.

Beh, dammi 20 secondi e ti faccio vedere che funziona la stessa cosa anche su Gentoo :D
Se non ricordo male, tale file esiste per assicurare la compabitlità con applicativi che cercano il tipo di distribuzione.

Anche Fedora ha dentro i file di release di redhat enterprise, ma non per questo se sposti pacchetti da una all'altra non provochi catastrofi iperboliche.

Ah, questo non la sapevo, pardome...pensavo l'avesse solo un sistema base debian, pardome :stordita:

Di xgl sicuramente è come dici tu, che ubuntu sia stato "modificato" fin li non ci piove, ma "coso" (non ricordo il nome dell'utente che spalava merda su debian) sparava cazzate mostruose, tipo "debian è da sboroni ecc" e l'ho ripreso dicendo che ubuntu è base debian, quello è il concetto che volevo far capire, se debian non fosse esistita ubuntu sarebbe ancora da creare.

Io sono intervenuto rispondendo a te perchè ho letto "forse non sai che ubuntu non è altro che Debian Etch.", affermazione che, tecnicamente, è errata.
Ubuntu ha *qualcosina* in comune con debian, e sono comunanze che fanno via via riducendosi da una versione con l'altra.
Feisty sarà un gran passo in questo senso, inserendo finalmente, temo, una VERA incompatibilità con debian, integrando strumenti che in quest'ultima non possono arrivare per le policy stesse di debian.

quanto a "coso", hai risposto a mjordan, che proprio il primo venuto non è. Si sarà espresso male, o avrà forse opinioni un po' "forti" sull'argomento, ma solitamente il fatto suo lo sa.
Io stesso ho usato per 2 anni debian, ho fatto parecchie installazioni, testing e assistenza varia su ubuntu, e non sono in disaccordo con lui.
Parliamo di debian, parliamo di ubuntu, ma le distribuzioni usate in veri ambienti di produzione sono altre, e per puro merito del prodotto.
Come ha giustamente detto, la maggiorparte delle webfarm e dei servizi hosting usano fedora, e ti assicuro che non è un caso :)

ps: sai perchè usano fedora core o redhat? fai 1+1 quando hai finito posta la soluzione e ti dico se è sbagliata o no ;)

Rh e Suse = SUPPORTO!

Ah, questo non la sapevo, pardome...pensavo l'avesse solo un sistema base debian, pardome :stordita:

No, per carità, solitamente il file debian_version ce l'hanno i sistemi basati su debian, ma non perchè sono effettivamente derivati da quella versione (feisty ad esempio deriva da un sync con i repo di SID, si è evoluta anche in tal senso, ha gnome 2.18, kernel 2.6.20, insomma con debian 4.0 non c'entra assolutamente nulla se non per il formato dei pacchetti, ma cat /etc/debian_version risponde sempre 4.0), ma semplicemente perchè, utlizzando una base più o meno comune, possono garantire la funzionalità anche a software di "terze parti" distribuire sottoforma di deb. Se questi software cercano debian (e capita spesso, in questo periodo sono a contatto con applicazioni per la medicina e le biotecnologie che fanno questo) la presenza di quel file soddisferà i loro requisiti, permettendo l'installazione del software.
Se io volessi installare dpkg su Gentoo (e posso farlo) per installare programmi diffusi come deb, potrei tranquillamente fare la stessa cosa che c'è su ubuntu, ed ottenere in ogni caso il mio bel programma installato.

Tutto qui :)

Rh e Suse = SUPPORTO!

Più RH che suse ;)

Io attendo impaziente che vendano notebook Dell con Fedora Core preinstallato :)

Non perchè io ora non abbia un Dell (640M) su cui fedora Core funziona che è un amore, ma perchè questa sarebbe davvero una bella iniziativa per diffondere linux e per abbassare i costi dei notebook :)

ma perchè le aziende non rilasciano i sorgenti dei loro driver? in fondo l'innovazione sta nell'hardware, no nel software, che serve solo per il corretto funzionamento.

E' un errore fondamentale di Linux richiedere che i driver siano opensource.

Il problema è che Linux è monolitico e quindi i driver vanno nel kernel. Per andare nel kernel servono i sorgenti, e siccome il kernel ha una licenza GNU, anche i drivers devono esserlo per essere integrati.

Non a tutte le aziende sta bene divulgare i propri segreti industriali ai quattro venti: spesso sono il loro vantaggio competitivo.

Si dovrebbe smettere di usare il kernel Linux e usare qualcosa di più moderno e più consono anche ad un utilizzo commerciale... un microkernel risolverebbe i problemi... es. Darwin (http://en.wikipedia.org/wiki/Darwin_(operating_system))! ;-)

Ma per fare dispetto a Linus sarebbe più interessante investire sulla recentissima vers. 3 di Minix (http://www.openaddict.com/review_of_minix_3.1.2a_ide_build2.html), del suo ex-professore ed acerrimo contestatore Tanenbaum. Ha caratteristiche davvero interessanti ed è un VERO microkernel!!

Pochi giorni fa erano stati segnalati alcuni nuovi prodotti distribuiti privi di sistema operativo e questa iniziativa aveva scatenato parecchio interesse da perte degli utenti.


infatti questi prodotti avevano scatenato anche il mio interesse ma io sul sito dell vedo solo notebook con windows vista o xp...
sono io che sono cieco o su dell italia ancora non ci sono?

Perchè che cosa ci sarebbe di male?

Per quanto mi riguarda niente, ma per una casa come Dell si...

Le ipotesi secondo me (che sono un pippone quindi lasciano il tempo che trovano ) sono 2

1) sistema con Linux allo stesso costo del sistema windows se non di + inizialmente per istituire una linea di assistenza dedicata a linux, cosa che credono nn esista in dell ancora

2) sistema con Linux ad un prezzo inferiore rispetto al sistema windows ma senza assistenza diretta da parte di Dell.

Io vorei usare ubuntu,l'ho già scaricato,ma sono limitato dal fatto che la wacon ,per la mia tavoletta grafica, che uso per lavorare non ha ancora i driver per ubunto.
Lo considero uno scandalo che la migliore produttrice di tavolette grafiche non supporti che windows e mac!

E' un errore fondamentale di Linux richiedere che i driver siano opensource.

Il problema è che Linux è monolitico e quindi i driver vanno nel kernel. Per andare nel kernel servono i sorgenti, e siccome il kernel ha una licenza GNU, anche i drivers devono esserlo per essere integrati.

Non a tutte le aziende sta bene divulgare i propri segreti industriali ai quattro venti: spesso sono il loro vantaggio competitivo.

Si dovrebbe smettere di usare il kernel Linux e usare qualcosa di più moderno e più consono anche ad un utilizzo commerciale... un microkernel risolverebbe i problemi... es. Darwin (http://en.wikipedia.org/wiki/Darwin_(operating_system))! ;-)

Ma per fare dispetto a Linus sarebbe più interessante investire sulla recentissima vers. 3 di Minix (http://www.openaddict.com/review_of_minix_3.1.2a_ide_build2.html), del suo ex-professore ed acerrimo contestatore Tanenbaum. Ha caratteristiche davvero interessanti ed è un VERO microkernel!!

I progettisti del kernel hanno già dimostrato che la paccottiglia proprietaria può tranquillamente girare in userspace lasciando in kernelspace solo roba insignificante, senza per questo avere problemi di affidabilità o cali di performance.

Linux è così apprezzato rispetto ad altri sistemi liberi proprio per le sue caratteristiche di "integrità" del software che deve essere per forza libero, cosa che garantisce frequenti bugfix e grande affidabilità, e per le sue caratteristiche di monoliticità, che lo rendono estremamente scalabile e portabile.
Se non Linux non fosse quello che è non sarebbe così diffuso.

Il mondo è pieno di microkernel mirabolanti... chissà come mai non li usa mai nessuno.

Io vorei usare ubuntu,l'ho già scaricato,ma sono limitato dal fatto che la wacon ,per la mia tavoletta grafica, che uso per lavorare non ha ancora i driver per ubunto.
Lo considero uno scandalo che la migliore produttrice di tavolette grafiche non supporti che windows e mac!

Che wacon usi? solitamente sono supportatissime su ubuntu, anche perchè solitamente nemmeno richiedono driver.

NON mi toccate Ubuntu!!
Serve per imparare e approcciarsi al mondo Linux, con semplicità.

E' un bene che esista.. e chi spala merda su questa distro è solo uno sborone, patetico! :lamer: :nonsifa:

E' un errore fondamentale di Linux richiedere che i driver siano opensource.

Il problema è che Linux è monolitico e quindi i driver vanno nel kernel. Per andare nel kernel servono i sorgenti, e siccome il kernel ha una licenza GNU, anche i drivers devono esserlo per essere integrati.

Non a tutte le aziende sta bene divulgare i propri segreti industriali ai quattro venti: spesso sono il loro vantaggio competitivo.
Vedo che ignori puntualmente quanto viene scritto.

I progettisti del kernel hanno già dimostrato che la paccottiglia proprietaria può tranquillamente girare in userspace lasciando in kernelspace solo roba insignificante, senza per questo avere problemi di affidabilità o cali di performance.

Linux è così apprezzato rispetto ad altri sistemi liberi proprio per le sue caratteristiche di "integrità" del software che deve essere per forza libero, cosa che garantisce frequenti bugfix e grande affidabilità, e per le sue caratteristiche di monoliticità, che lo rendono estremamente scalabile e portabile.
Se non Linux non fosse quello che è non sarebbe così diffuso.


Linus/Linux è stato molto fortunato, perchè è uscito in un periodo in cui gli Unix commerciali costavano uno sproposito e si è formata intorno a lui una comunità sorprendente. Inoltre il VERO kernel di GNU (Linux è parte del movimento GNU, una PICCOLA parte, direi) che doveva essere basato su MICROKERNEL Mach (come Darwin/OS X) non si è mai concretizzato.

Resta il fatto che Linux è basato su un concetto arcaico di OS, i kernel monolitici sono troppo ridigi sotto molti aspetti e potenzialmente inaffidabili e oggi le alternative migliori ci sarebbero (ne ho citate 2 nel precedente messaggio). Però ormai Linux è Linux... pure IBM si è dovuta sottomettere e spingerlo pur di contrastare M$. Ma i difetti base di progettazione col tempo vengono fuori e si vedono. E Linux sarà quindi sempre un OS di nicchia.

Sarebbe meglio abbandonarlo, tenere di buono tutta la parte GNU e andare avanti.

Guardate che spettacolo che possono essere dei microkernel moderni come Minix 3:

---------

Reduce kernel size
Monolithic operating systems (e.g., Windows, Linux, BSD) have millions of lines of kernel code. There is no way so much code can ever be made correct. In contrast, MINIX 3 has about 4000 lines of executable kernel code. We believe this code can eventually be made fairly close to bug free.

Cage the bugs
In monolithic operating systems, device drivers reside in the kernel. This means that when a new peripheral is installed, unknown, untrusted code is inserted in the kernel. A single bad line of code in a driver can bring down the system. This design is fundamentally flawed. In MINIX 3, each device driver is a separate user-mode process. Drivers cannot execute privileged instructions, change the page tables, perform I/O, or write to absolute memory. They have to make kernel calls for these services and the kernel checks each call for authority.

Limit drivers' memory access
In monolithic operating systems, a driver can write to any word of memory and thus accidentally trash user programs. In MINIX 3, when a user expects data from, for example, the file system, it builds a descriptor telling who has access and at what addresses. It then passes an index to this descriptor to the file system, which may pass it to a driver. The file system or driver then asks the kernel to write via the descriptor, making it impossible for them to write to addresses outside the buffer.

Survive bad pointers
Dereferencing a bad pointer within a driver will crash the driver process, but will have no effect on the system as a whole. The reincarnation server will restart the crashed driver automatically. For some drivers (e.g., disk and network) recovery is transparent to user processes. For others (e.g., audio and printer), the user may notice. In monolithic systems, dereferencing a bad pointer in a (kernel) driver normally leads to a system crash.

Tame infinite loops
If a driver gets into an infinite loop, the scheduler will gradually lower its priority until it becomes the idle process. Eventually the reincarnation server will see that it is not responding to status requests, so it will kill and restart the looping driver. In a monolithic system, a looping driver hangs the system.

Limit damage from buffer overruns
MINIX 3 uses fixed-length messages for internal communication, which eliminates certain buffer overruns and buffer management problems. Also, many exploits work by overrunning a buffer to trick the program into returning from a function call using an overwritten stacked return address pointing into the overrun buffer. In MINIX 3, this attack does not work because instruction and data space are split and only code in (read-only) instruction space can be executed.

Restrict access to kernel functions
Device drivers obtain kernel services (such as copying data to users' address spaces) by making kernel calls. The MINIX 3 kernel has a bit map for each driver specifying which calls it is authorized to make. In monolithic systems every driver can call every kernel function, authorized or not.

Restrict access to I/O ports
The kernel also maintains a table telling which I/O ports each driver may access. As a result, a driver can only touch its own I/O ports. In monolithic systems, a buggy driver can access I/O ports belonging to another device.

Restrict communication with OS components
Not every driver and server needs to communicate with every other driver and server. Accordingly, a per-process bit map determines which destinations each process may send to.

Reincarnate dead or sick drivers
A special process, called the reincarnation server, periodically pings each device driver. If the driver dies or fails to respond correctly to pings, the reincarnation server automatically replaces it by a fresh copy. The detection and replacement of nonfunctioning drivers is automatic, without any user action required. This feature does not work for disk drivers at present, but in the next release the system will be able to recover even disk drivers, which will be shadowed in RAM. Driver recovery does not affect running processes.

Integrate interrupts and messages
When a interrupt occurs, it is converted at a low level to a notification sent to the appropriate driver. If the driver is waiting for a message, it gets the interrupt immediately; otherwise it gets the notification the next time it does a RECEIVE to get a message. This scheme eliminates nested interrupts and makes driver programming easier.

Vedo che ignori puntualmente quanto viene scritto.

Cosa? Fare realizzare i driver a sviluppatori Linux sotto NDA?
Oppure creare escamotage per tenere solo un pezzetto di driver (rigorosamente opensource) nel kernel e il resto (la parte "segreta") fuori?

Non mi sembrano soluzioni reali al problema. Solo 'patch'... ;)

Cosa? Fare realizzare i driver a sviluppatori Linux sotto NDA?
Oppure creare escamotage per tenere solo un pezzetto di driver (rigorosamente opensource) nel kernel e il resto (la parte "segreta") fuori?

Non mi sembrano soluzioni reali al problema. Solo 'patch'... ;)
Non ho detto solo quello. Ho parlato anche dei vari tuoi appunti, tipo voler tenere segrete le cose altrimenti Bin Laden fa cadere altri aerei, o simili.
Dovresti riflettere sul fatto che esiste un'altra famiglia di sistemi operativi liberi, i sistemi *BSD, che sono praticamente uguali a linux ma senza la fissazione dei driver liberi. Stranamente, non hanno avuto la stessa diffusione di linux.

Il mondo è pieno di microkernel mirabolanti... chissà come mai non li usa mai nessuno.

Li usano, li usano...
Symbian è un microkernel, OS X è (fondamentalmente) un microkernel, QNX è un ECCELLENTE microkernel... ecc.

Di monolitico c'è rimasto Linux e Windoze... quest'ultimo neanche tanto con Vista che sta andando in direzione ibrida stile OS X.

Non so se è old, cmq. Dell dice no a linux
http://www.newstech.eu/hardware/dell-dice-no-a-linux.html?Itemid=49

Dovresti riflettere sul fatto che esiste un'altra famiglia di sistemi operativi liberi, i sistemi *BSD, che sono praticamente uguali a linux ma senza la fissazione dei driver liberi. Stranamente, non hanno avuto la stessa diffusione di linux.

Appunto dico che Linux è stato fortunato.
E' uscito al momento giusto, ha saputo raccogliere intorno a sè un vasto interesse.
Però oggi esistono alternative migliori. BSD è il VERO Unix!! Sicuramente megliore di Linux. Anche come licenza (per un utilizzo commerciale). Pur esserndo sempre un OS monolitico...

Resta il fatto che Linux è basato su un concetto arcaico di OS, i kernel monolitici sono troppo ridigi sotto molti aspetti e potenzialmente inaffidabili e oggi le alternative migliori ci sarebbero (ne ho citate 2 nel precedente messaggio). Però ormai Linux è Linux... pure IBM si è dovuta sottomettere e spingerlo pur di contrastare M$. Ma i difetti base di progettazione col tempo vengono fuori e si vedono. E Linux sarà quindi sempre un OS di nicchia.

Il software è fatto di compromessi, e non di scelte futuristiche. L'uso di un microkernel è un progresso solo se porta vantaggi, e definire "arcaica" una cosa che funziona è una definizione che lascia un po' il tempo che trova.

Linux è, per l'appunto, un buon compromesso: facilmanente manutenibile, facilmente scalabile, facilmente debuggabile. Sarà arcaico quanto vuoi, ma funziona.
Gli altri cosa offrono? Darwin/Mach fa drammaticamente pena, è uno dei pochissimi sistemi al mondo in cui il kernel può prendere il controllo ed inibire qualunque altra operazione, alla facciazza del multithreading. Solaris è lento da fa schifo, e gli altri sono kernellini piccoli e inmanutenibili, come Minix o Shark, che solo a metterci le mani si sputtana tutto, senza parlare di cosa comporti trovare un bug.
Sono eccellenti per applicazioni specifiche e hard-realtime dove la loro snellezza strutturale è oggettivamente un vantaggio, perchè non è un problema nè la variabilità dell'hardware, nè la moltitudine di sviluppatori, nè la portabilità, nè la potenza di calcolo.

Soprattutto nessuno di questi mirabolanti kernel ha la caratteristica essenziale che invece Linux ha: Linux funziona.

ma perchè le aziende non rilasciano i sorgenti dei loro driver? in fondo l'innovazione sta nell'hardware, no nel software, che serve solo per il corretto funzionamento.

spero che con "software" tu intenda solo i driver... perché altrimenti, è l'esatto contrario. E' il software che guida, non certo l'hardware.

Li usano, li usano...
Symbian è un microkernel, OS X è (fondamentalmente) un microkernel, QNX è un ECCELLENTE microkernel... ecc.

Di monolitico c'è rimasto Linux e Windoze... quest'ultimo neanche tanto con Vista che sta andando in direzione ibrida stile OS X.

1) Windoze è dai tempi di NT4 che non è monolitico.

2) mi hai citato un kernel per dispositivi embedded, un kernel che gira su una sola configurazione hardware e che soprattutto fa schifo, e un kernel per applicazioni hard realtime. Nessuno di questi è minimamente paragonabile a Linux. Mentre, viceversa, Linux è tranquillamente paragonabile a Loro.
Grandi utilizzatori di microkernel embedded, come Motorola, Nokia, o Philips (per l'illuminazione controllata) stanno studiando da tempo e con grandi risorse in uomini e soldi soluzioni Linux e ucLinux dei loro prodotti, tanto i loro microkernel sono vantaggiosi. Mai sentito parlare di N800? ecco, è solamente la punta dell'iceberg.

Salve a tutti,
prima si parlava di driver open source per le schede Wireless Intel.

Magari ho frainteso io, però le cose non stanno proprio così: è vero che il driver è open, ma il firmware della periferica no. E, guardacaso, il driver open è piuttosto piccolo, mentre il firmware è decisamente più corposo... ho la sensazione che il vero driver risieda nel firmware, mentre il driver open sia solo un'interfaccia verso di esso.

Sebbene anche io preferisca sicuramente che i driver siano open, non vedo quale sia l'enorme problema per linux: semplicemente non li si inserisce nella distribuzione e si lascia la briga all'utente di scaricali e installarli. Sapendo, ovviamente, che quel driver viola la liceza del kernel stesso e che quindi, in caso di problemi, il responsabile non sarà certo linux, ma il driver.

Rispondendo a ilsensine, personalmente credo che le case produttrici di chip grafici non vogliano rilasciare il codice dei driver perchè nei driver stessi potrebbero esserci avanzate routine di compressione delle texutre, di ottimizzazione dei triangoli, di rimozione delle superfici nascoste, di sfruttamente delle estensioni SIMD, ecc.. Insomma, immagino che non tutte le feature sbandierate dai produttori siano realmente al 100% integrate nell'hardare, ma magari qualcosa è implementato anche lato software (nel driver). Se le cose stanno davvero così e decidessero comunque di rilasciare i driver open, stai pur certo che brevetterebbero tutto il brevettabile. E una situazione del genere (software open ma brevettato) mi piacerebbe ancora meno che avere il driver closed.

Comunque, lo ribadisco, personalmente preferirei di gran lunga driver open!

Discorso micro/mono kernel: la possibilità che un driver scritto male crashi un sistema monolitico è reale, ma in passato i microkernel avevano seri problemi di performance. Sono stati risolti?

Sono due righe che ho scritto così di "getto", magari ho detto delle inesattezze... nel caso perdonatemi! ;)

Ciao. :)

Discorso micro/mono kernel: la possibilità che un driver scritto male crashi un sistema monolitico è reale, ma in passato i microkernel avevano seri problemi di performance. Sono stati risolti?

A giudicare dagli attuali esempi di microkernel che ci sono in giro direi di no.
Eccezione fatta per quelli realizzati per applicazioni mission critical, ma li è tutto un altro paio di maniche.

2) mi hai citato un kernel per dispositivi embedded, un kernel che gira su una sola configurazione hardware e che soprattutto fa schifo, e un kernel per applicazioni hard realtime. Nessuno di questi è minimamente paragonabile a Linux. Mentre, viceversa, Linux è tranquillamente paragonabile a Loro.

QNX girava anche su desktop (l'ho provato) che poi si sia ritagliato il suo spazio commerciale nell'ambito real-time è un altro discorso (in quell'ambito non aveva windoze a bloccargli il mercato).

Che OS X faccia schifo è una tua opinione (sorry ma non lo cambierei con Linux, anche se quest'ultimo me lo regalassero ;) ), che giri solo su una configurazione hardware invece non è semplicemente errato. Figurati che gira pure su molti PC e ben 3 architetture (in passato 2 più: Sparc e HP-Risc).

Grandi utilizzatori di microkernel embedded, come Motorola, Nokia, o Philips (per l'illuminazione controllata) stanno studiando da tempo e con grandi risorse in uomini e soldi soluzioni Linux e ucLinux dei loro prodotti, tanto i loro microkernel sono vantaggiosi. Mai sentito parlare di N800? ecco, è solamente la punta dell'iceberg.

Però nel frattempo usano Symbian (almeno i primi 2, Philips non so)....

Guardate che spettacolo che possono essere dei microkernel moderni come Minix 3:

Di fatto però non è che l'archittettura microkernel sia così fantastica allo stato dei fatti. L'intera architettura NT e seguenti è basata su microkernel. E ti sembra forse questo trionfo di stabilità e sicurezza?

La stessa Apple, riprendendo i vecchi progetti Mach per il suo kernel di MacOS X, ha praticamente 'segato' l'idea del microkernel per impiegare un kernel più monolitico che mai.

I sistemi mission-critical sono spesso ottimizzati per un numero molto limitato di compiti e girano su un hardware spesso uniforme e molto testato, e sono da questo punto di vista più semplici da gestire.

Insomma; bella l'idea, ma l'implementazione, allo stato dei fatti, trova ancora troppi limiti.

Purtroppo il Santo Graal dei kernel ancora non è stato trovato. O si opta per una soluzione 'di nicchia', stile Apple, ovvero si abbina kernel (ma anche una certa parte 'base' dello userspace) ad una quantità molto ristretta di hardware specificamente approvata per l'uso, o, se si vuole continuare ad avere l'attuale architettura 'open' dei pc (ovvero, miglialia di produttori e componenti diversi combinati insieme non sempre con cognizione di causa o testing approfonditi) qualche problema ci sarà sempre, sia con Windows che con Linux che con FreeBSD.

Certo, sarebbe bello che venissero offerti anche sistemi certificati 100% Open in maniera che un consumatore sia libero di scegliere quello che preferisce; al giorno d'oggi, specialmente nei portatili, bisogna scendere a compromessi ed essere disposti ad accettare che qualcosa non funzioni su Linux o FreeBSD. Il progetto open-hardware certification sembrava carino ma non ha preso piede...

EDIT:
n.b.: XNU non è un'architettura veramente microkernel. Mach 3.0 lo era, ma la stragrande maggioranza delle funzioni è stata incorporata nel nucleo centrale. Insomma, è un microkernel molto più di nome che di fatto.

QNX girava anche su desktop (l'ho provato) che poi si sia ritagliato il suo spazio commerciale nell'ambito real-time è un altro discorso (in quell'ambito non aveva windoze a bloccargli il mercato).

Appunto, girava, ma niente di più.
Se proprio vuoi appellarti ad un microkernel che funziona bene attaccati a BeOS...

Che OS X faccia schifo è una tua opinione (sorry ma non lo cambierei con Linux, anche se quest'ultimo me lo regalassero ;) )

Mia opinione proprio no. Basta studiarlo un po' per capirlo.
E' un patching mostruoso di roba assortita proveniente da almeno 3 kernel diversi, un po' micro, un po' ibrido, con i vari server che funzionano solo quando si realizzano alcuni eventi e non altri, perchè altrimenti vengono bloccati ed agisce lo stesso codice ma sottoforma monilitica che sta da un altra parte e che non richiede timing... senza considerare che chi ha messo le mani su OpenDarwin e su Mach (entrambi mezzi imbastardamenti di quella cosa che è il kernel di osX) ha riferito che c'erano intere *regioni* di codice in esecuzione ma mai usato, roba per gestire interruzioni ed eccezioni che erano invedce già gestite da altre parti... e altre robe così e peggiori.
Infatti i fatti lo dimostrano... come kernel è di un lentezza disarmante.

che giri solo su una configurazione hardware invece non è semplicemente errato. Figurati che gira pure su molti PC e ben 3 architetture (in passato 2 più: Sparc e HP-Risc).

Un kernel è portabile se puoi ricompilarlo su più architetture con nessuno o pochi cambiamenti ben circostanziati.
Il fatto che tutte le volte riscrivano mezzo kernel per fargli cambiare architettura non significa certo che "giri" su più architetture.

Non so se ti mai messo a guardare le differenze tra opendarwin-ppc e opendarwin-x86, quando erano entrambi scaricabili in forma sorgente.
Sembrano prodotti diversi.


Però nel frattempo usano Symbian (almeno i primi 2, Philips non so)....

Perchè symbian è più consolidato.
Ma se fosse il migliore non ci sarebbe bisogno di studiare e fare ricerca su Linux, basterebbe evolvere Symbian....

Rh e Suse = SUPPORTO!

Era semplice :sofico:

Io sono intervenuto rispondendo a te perchè ho letto "forse non sai che ubuntu non è altro che Debian Etch.", affermazione che, tecnicamente, è errata.
Ubuntu ha *qualcosina* in comune con debian, e sono comunanze che fanno via via riducendosi da una versione con l'altra.
Feisty sarà un gran passo in questo senso, inserendo finalmente, temo, una VERA incompatibilità con debian, integrando strumenti che in quest'ultima non possono arrivare per le policy stesse di debian.

quanto a "coso", hai risposto a mjordan, che proprio il primo venuto non è. Si sarà espresso male, o avrà forse opinioni un po' "forti" sull'argomento, ma solitamente il fatto suo lo sa.
Io stesso ho usato per 2 anni debian, ho fatto parecchie installazioni, testing e assistenza varia su ubuntu, e non sono in disaccordo con lui.
Parliamo di debian, parliamo di ubuntu, ma le distribuzioni usate in veri ambienti di produzione sono altre, e per puro merito del prodotto.
Come ha giustamente detto, la maggiorparte delle webfarm e dei servizi hosting usano fedora, e ti assicuro che non è un caso :)

Infatti non sto dicendo che non è un caso che utilizzino fedora, red hat o altro con debian il supporto è certamente più vago rispetto a red hat, suse o chi altro...
E comunque io non sto dicendo che mjordan sia uno sprovveduto o altro, anche perchè non lo sò, ma affermare che debian è solo da sboroni mi fà solo girare il cazzo.

Artemisyu io per winxp devo avere i driver altrimenti non mi vede la tavoletta , ho una intuos, ottima devo dire.
Comunque proverò lo stesso ad installare ubuntu sperando sia come dici tu.

Vedasi intel, realtek e tante altre.

A proposito di realtek: i driver audio generici rilasciati dal produttore sono affidabili? Tempo fa li ho scaricati (ho suse, che non figurava tra le distro specificamente supportate, e volevo togliermi lo sfizio di aggiornarli, anche se funzionano, visto che il chip audio - integrato - è supportato genericamente come parte del southbridge), però dando una rapida occhiata agli script di installazione ho notato che andavano ad operare su cartelle non presenti sul mio sistema/con nomi leggermente diversi da quelle esistenti, quindi ho desistito (non vorrei incasinare il sistema, anche perchè attualmente non saprei bene dove mettere le mani per risolvere, nello specifico).

[modalità_anti-moderatore]
Questo può essere una delle tante situazioni che spingono dell e altri produttori alla cautela verso linux, e potrebbero determinare la scelta di una distro rispetto ad altre (sto barando alla grande, visto nel caso in questione funziona tutto bene senza bisogno di andare a prendere quei driver e ricompilare il kernel - mi pare fosse necessario, ma lo facevano gli script del driver in automatico - :D)

Li usano, li usano...
Symbian è un microkernel, OS X è (fondamentalmente) un microkernel, QNX è un ECCELLENTE microkernel... ecc.

Di monolitico c'è rimasto Linux e Windoze... quest'ultimo neanche tanto con Vista che sta andando in direzione ibrida stile OS X.

NT è per definizione kernel ibrido fin dalla sua prima incarnazione, di monolitico non c'è nulla.

Basta parlare a vanvera di sti driver, tutto quello che ho, tastiera e mouse bluetooth, scheda video, audio, scheda tv, stampante e scanner li ho tutti perfettamente funzionanti sotto linux. A me sinceramente ste discussioni paiono abbastanza campate in aria. Certo c'è hardware non supportato ma i tempi in cui aveva un senso fare queste discussioni sono ampiamente finiti.

Hola.

Certo che se Dell intende chiedere agli utenti che distribuzione vogliono sui loro PC e magari anche quale ambiente grafico, tanto vale che chiedano all'intera popolazione italiana quale dovrebbe essere la formazione della Nazionale di calcio...

Debian ha solo tanto nome e pochi fatti, excellence proprio per niente, per lo meno da chi i sistemi operativi li usa per lavorare e produrre.
Tutti i principali registrar, web hosting/domini utilizzano principalmente Fedora Core, nell'ambito enterprise sono tutti orientati su Solaris 10, RedHat Enterprise Linux (a proposito, ieri è uscita la versione 5.0), Suse e Novell. Per l'uso "utonto", Ubuntu spopola.

Debian è solo l'OS di chi vuol far vedere che sa usare Linux (senza riuscirvi, per altro)

Santi numi! C'è parecchia disinformazione al riguardo...
Primo, tanto nome per una entità che non si fa pubblicità vuol dire che ce ne sono di fatti eccome.
Secondo, anche io non avrei nulla in contrario ad adottare Fedora Core, ma chi ci lavora su server di produzione lo sconsiglia alquanto, ma questo dipende molto dalla release particolare, e qua ci sarebbe molto da discutere sulla presunta qualità di Fedora. Poi se citi le grosse aziende è diverso, poichè esse si impegnano attivamente nel supporto tecnico ed è un grosso vantaggio per chi vuol far vedere che adotta Linux nei suoi server (ma non ha la conoscenza per mantenerli, per altro).
Infine, Debian viene utilizzato da alcune PA estere, non sarà mica perchè è la distribuzione più coerente in circolazione? oppure perchè ogni release di Debian è a prova di bomba, ha bisogno di meno supporto e di minore complessità?
Il ruolo di Debian ora è offuscato dal gran numero di distribuzioni basate su debian stessa o su ubuntu, derivata a sua volta da debian. Ma questo io lo vedo come una naturale evoluzione di una distribuzione che vuole semplicemente essere "solida".

Certi discorsi su microkernel e kernel monolito sn propri stupidi soprattutto se poi si prende ad esempio osX come "eccellenza". Il problema nn è certo il kernel ma il driver e senza driver l'hardware nn gira......e infatti su osx di hardware che nn gira ce n'è parecchio.
In linux l'impedicmento nn è certo pratico.....è più un impedimento "filosofico". Si crede nell'open source e quindi si cerca di insistere il più possibile verso questa strada anche per i driver. Ma i driver closed possono esistere tranquillamente. Se nn vengono inclusi nel kernel basta farli andare in user space ed è tutto risolto. Dov'è il problema? Linux da più possibile, altri sistemi decisamente no!

NT è per definizione kernel ibrido fin dalla sua prima incarnazione, di monolitico non c'è nulla.

Quoto, e rilancio:
in NT 3.51 addirittura il driver video era caricato in userspace, rendendo quindi la macchina discretamente immune anche a catastrofici driver video.
In NT 4.0, Win2000 e XP si è tornati un po' indietro, andando a caricare alcuni driver in kernel space; ad essere interessati sono stati i driver le cui prestazioni erano cruciali, come ad esempio proprio quello video.

Da quanto ho letto, Vista è tornato un po' alle origini, con i driver video (o almeno parte di essi) caricati in userspace.

Ciao. :)

Certi discorsi su microkernel e kernel monolito sn propri stupidi soprattutto se poi si prende ad esempio osX come "eccellenza". Il problema nn è certo il kernel ma il driver e senza driver l'hardware nn gira......e infatti su osx di hardware che nn gira ce n'è parecchio.
In linux l'impedicmento nn è certo pratico.....è più un impedimento "filosofico". Si crede nell'open source e quindi si cerca di insistere il più possibile verso questa strada anche per i driver. Ma i driver closed possono esistere tranquillamente. Se nn vengono inclusi nel kernel basta farli andare in user space ed è tutto risolto. Dov'è il problema? Linux da più possibile, altri sistemi decisamente no!
Infatti il microkernel vs kernel monolitico è pura teoria, ovvero in teoria puoi trovare mille motivi per preferire l'uno all'altro, nella pratica, tutti i kernel sono dei compromessi e non valgono come esempi per l'una o l'altra filosofia. Nei computer, siano essi server o workstation o palmari, non c'è veramente bisogno di un'architettura a microkernel secondo me. Quindi è come parlare di ATI Vs Nvidia o Inter Vs Milan. Discorso a parte per i sistemi embedded mission critical, dove i microkernel hanno veramente motivo di esistere.

Infatti il microkernel vs kernel monolitico è pura teoria, ovvero in teoria puoi trovare mille motivi per preferire l'uno all'altro, nella pratica, tutti i kernel sono dei compromessi e non valgono come esempi per l'una o l'altra filosofia. Nei computer, siano essi server o workstation o palmari, non c'è veramente bisogno di un'architettura a microkernel secondo me. Quindi è come parlare di ATI Vs Nvidia o Inter Vs Milan. Discorso a parte per i sistemi embedded mission critical, dove i microkernel hanno veramente motivo di esistere.

Concordo pienamente.
Poi però arriva il solito che ha fatto sistemi operativi con il Tanenbaum e un po' di ingegneria del software ed è diventato schiavo dell'approccio da designer.
E viene a tirare fuori la solita solva sui microkernel che sono il futuro e che linux è vecchio lento e stupido.

Bah.

Basta parlare a vanvera di sti driver, tutto quello che ho, tastiera e mouse bluetooth, scheda video, audio, scheda tv, stampante e scanner li ho tutti perfettamente funzionanti sotto linux. A me sinceramente ste discussioni paiono abbastanza campate in aria. Certo c'è hardware non supportato ma i tempi in cui aveva un senso fare queste discussioni sono ampiamente finiti.

Hola.
Per non parlare degli :stordita: che insistono col dire che bisogna ricompilare il kernel.:doh:

Concordo pienamente.
Poi però arriva il solito che ha fatto sistemi operativi con il Tanenbaum e un po' di ingegneria del software ed è diventato schiavo dell'approccio da designer.
E viene a tirare fuori la solita solva sui microkernel che sono il futuro e che linux è vecchio lento e stupido.

Bah.
Giuro che volevo scrivere questo, poi ho corretto il tiro per evitare di ferire qualcuno. In ogni caso sottoscrivo.

Dai, basta parlare di kernel e micro kernel :) E' molto OT rispetto alla notizia :)

Tornando alla notizia, io penso che la distribuzione scelta dovrebbe essere soprattutto semplice. Se la vendono preinstallata queso vuol dire che eventuali driver e configurazioni del caso li mettono loro. Detto questo, la dstribuzione dovrebbe essere soprattutto semplice da usare e flessibile. Motivo per cui io sceglierei Ubuntu, la distro ideale secondo me per chi si avvicina a linux...

noto che la discussione è virata su un OT più interessante (*) dell' argomento originale ...
* si fa per dire, è un discorso un po' trito e ritrito :D

mi limiterò a linkare un mio vecchio >post< (http://www.hwupgrade.it/forum/showpost.php?p=15800060&postcount=177), che puntualizzava una differenza qui trascurata ;)
Se proprio vuoi appellarti ad un microkernel che funziona bene attaccati a BeOS...se non ricordo male anche quello di BeOS era un kernel ibrido... streamlined quanto vuoi ma l' integrare stack tcp e il BeFS lo escludeva dai microkernel puri ... se non ricordo male, i principali motivi dell' efficienza del beos come sistema operativo multimediale desktop erano lo scheduler, che aveva bassi costi di creazione thread (il che rendeva possibile creare un thread per ogni finestra, per ogni widget o per ogni directory acceduta - pervasive multithreading) e l' application server (che oltre ad integrare GUI e window manager godeva di elevate priorità di scheduling) ;)
Poi però arriva il solito che ha fatto sistemi operativi con il Tanenbaum e un po' di ingegneria del software ed è diventato schiavo dell'approccio da designer.poi arriva il sottoscritto che, dopo aver studiato ingegneria del sw e osservato per qualche anno i vari kernel in circolazione, arriva a ritenerli tutti indistintamente imperfetti, e se avesse tempo si dedicherebbe alla realizzazione di quello definitivo ... :D
E viene a tirare fuori la solita solva sui microkernel che sono il futuro al di fuori delle sterili discussioni accademiche che lasciano il tempo che trovano, il futuro è sempre più un far evolvere quello che già c'è (quindi svecchiare e attualizzare quello che dopo un po' appare vecchio, ancorchè maturo e funzionante), per iniziative nuove ibridare idee prima antitetiche, a volte ritornare alle origini (corsi e ricorsi storici, anche in informatica)
e che linux è vecchio lento e stupido.Linux funziona, è innegabile, raggiunge buone prestazioni, altrettanto innegabile, ma ammetterai che il modo in cui questo viene ottenuto non è per via di un design, all' origine, *particolarmente* elegante, quanto per qualcosa che altri progetti possono solo sognare, cioè la forza lavoro su cui può contare (migliaia, milioni di sviluppatori nel mondo a studiare aggiunte, codificarle, mettere a posto i problemi e tappare buchi in quello che è praticamente un refactoring in ciclo infinito) in virtù della fama che ha conquistato...
quindi dal mio pdv, che funzioni e che sia vecchio (come concezione) non sono aspetti antitetici, e l' ultimo comunque non un' offesa o un demerito...

detto ciò, chiuderei l' off topic...

Non puoi cavartela cosi' facilmente .........................

........... vogliamo sapere cosa ne pensi della questione microkernel - kernel

visto che il link postato non si apre

se non ricordo male anche quello di BeOS era un kernel ibrido... streamlined quanto vuoi ma l' integrare stack tcp e il BeFS lo escludeva dai microkernel puri ... se non ricordo male, i principali motivi dell' efficienza del beos come sistema operativo multimediale desktop erano lo scheduler, che aveva bassi costi di creazione thread (il che rendeva possibile creare un thread per ogni finestra, per ogni widget o per ogni directory acceduta - pervasive multithreading) e l' application server (che oltre ad integrare GUI e window manager godeva di elevate priorità di scheduling) ;)

Ricordi bene, anche a me pareva di aver letto cose analoghe.

poi arriva il sottoscritto che, dopo aver studiato ingegneria del sw e osservato per qualche anno i vari kernel in circolazione, arriva a ritenerli tutti indistintamente imperfetti, e se avesse tempo si dedicherebbe alla realizzazione di quello definitivo ... :D

Concordo pienamente... ogni kernel è ugualmente imperfetto.
Tuttavia gli informatici che arrivano a fare i maniaci del design (cosa che solitamente accade dopo aver frequentato il corso di sistemi operativi) sono fuori come un nano da giardino... in università ho visto gente che non usava Linux per non accettava di usare un sistema operativo così concettualmente vecchio.
Suvvia, non ha senso :)

al di fuori delle sterili discussioni accademiche che lasciano il tempo che trovano, il futuro è sempre più un far evolvere quello che già c'è (quindi svecchiare e attualizzare quello che dopo un po' appare vecchio, ancorchè maturo e funzionante), per iniziative nuove ibridare idee prima antitetiche, a volte ritornare alle origini (corsi e ricorsi storici, anche in informatica)
Linux funziona, è innegabile, raggiunge buone prestazioni, altrettanto innegabile, ma ammetterai che il modo in cui questo viene ottenuto non è per via di un design, all' origine, *particolarmente* elegante, quanto per qualcosa che altri progetti possono solo sognare, cioè la forza lavoro su cui può contare (migliaia, milioni di sviluppatori nel mondo a studiare aggiunte, codificarle, mettere a posto i problemi e tappare buchi in quello che è praticamente un refactoring in ciclo infinito) in virtù della fama che ha conquistato...
quindi dal mio pdv, che funzioni e che sia vecchio (come concezione) non sono aspetti antitetici, e l' ultimo comunque non un' offesa o un demerito...

detto ciò, chiuderei l' off topic...

Anche qui, concordo pienamente... chiudere anche io l'off topic :)

Non puoi cavartela cosi' facilmente .........................

........... vogliamo sapere cosa ne pensi della questione microkernel - kernel

visto che il link postato non si aprea me si apriva :stordita: comunque il post è questo :
semplicemente volevo far capire che il contrario di microkernel non è "kernel monolitico", e la differenza tra un sistema cosiddetto "strutturato" (tramite compartimentazione interna) e uno "non strutturato" (in cui mancano confini - "boundaries" - che limitino e regolino tramite protocolli, l' accessibilità da parte delle sezioni di codice alle strutture dati "al di là" del confine)

ora, un sistema a microkernel puro, è intrinsecamente strutturato, perchè ad esempio, il servizio di rete e quello per il file system, se devono interagire, possono farlo solo scambiandosi messaggi attraverso il sistema di IPC , quindi attraverso un' interfaccia sia binaria che programmatica (la API coinvolta) e inoltre superando la barriera dello spazio di indirizzamento che li separa fisicamente
ma è "micro" sulla base del fatto che il kernel implementa, con un set limitato di facilities, un insieme limitato di astrazioni (spesso solo task e porte di comunicazione - in certi casi anche la gestione degli interrupt è lasciata fuori, o la gestione della memoria virtuale) - la ricerca ha prodotto kernel anche più "micro" dei microkernel, basati sul criterio di ridurre i compiti del kernel al solo multiplexing delle risorse (in pratica il solo scheduling) , nella forma degli exo-, o nano-kernel
ora, seguendo questo concetto, si intuisce che un kernel che integri direttamente anche file system, stack di rete, sistema di input, gestione dell' i/o e del device tree, oltre a scheduler e VM manager, sia non "monolitico", ma un "macro-kernel" , il quale può essere strutturato o non strutturato a seconda che il progetto di insieme sia basato o meno sulla compartimentazione logica delle sottoparti e sulla progettazione e adozione di interfacce interne - cosa che non è messa in discussione dal fatto che parti del kernel possano essere caricate e rimosse a runtime - che resta una caratteristica a latere

in questo senso, Linux sarebbe un ottimo esempio di kernel monolitico secondo la definizione classica, NT un sistema strutturato e ibrido (tra micro- e macro- kernel : questo per il fatto di integrare nell' Executive praticamente tutte le astrazioni di supporto alle applicazioni, compresa la grafica, ma al tempo stesso per il fatto di essere l' Executive e i driver, threaded al loro interno, con i kernel thread gestiti a loro volta dalla "sezione microkernel" separata
<cut>
anche qui, concordo pienamente... chiudere anche io l'off topic :):)

comunque attento ai nani da giardino ... potrebbero stupirti e lasciarti indietro quando meno te l' aspetti :O :asd:
(questa la capirà solo chi ha letto il Signore dei Ratti, by Leo Ortolani :p ) :D

ma perchè le aziende non rilasciano i sorgenti dei loro driver? in fondo l'innovazione sta nell'hardware, no nel software, che serve solo per il corretto funzionamento.Le innovazioni avvengono sia nel Hw che nel Sw; anche se quelle sw sono meno appariscenti di quelle Hw e quindi meno note ai consumatori usuali.

Il sorgente di un driver, per gestire un dispositivo o altro, viene realizzato sulla base di specifiche tecniche(funzionali) che descrivono funzionalmente in particolare anche i vari componenti programmabili con particolare enfasi su:

- descrizione degli state registers,
- command registers,
- timings vari
- sequenze di inizializzazioni, ecc
- ed altro ancora

Anche a distanza di tempo, gli stessi progettisti(te lo dico per esperienza diretta) per poter gestire(utilizzare/modificare, ecc) il sorgente di un driver non di rado devono come minimo consultare le specifiche funzionali del dispositivo.

Ma queste info, come il buon senso induce a pensare, sono coperte da segreto industriale, se diffuse potrebbero essere una manna per i propri concorrenti del settore.

Conclusione: con i soli sorgenti fai poca strada.

comunque attento ai nani da giardino ... potrebbero stupirti e lasciarti indietro quando meno te l' aspetti :O :asd:
(questa la capirà solo chi ha letto il Signore dei Ratti, by Leo Ortolani :p ) :D

Mitico il signore dei ratti :D

Alla fine gli unici 2 OS commerciali di successo sono entrambi ibridi (chi più chi meno, NeXT / OS-X parte da un microkernel puro per poi aggiungerci principalmente lo stack di rete BSD, Windoze non l'ho capito bene: come sempre M$ fa cose pasticciate) che è l'approccio che permette di avere un compromesso tra prestazioni e flessibilità/affidabilità.

Linux comunque è troppo monolitico e può funzionare solo grazie alla forza bruta della sua infinita manodopera. E poi spuntano sempre questi problemi con i drivers.

E comunque niente batte l'eleganza di un microkernel puro!
E OS come QNX (ma anche Symbian) dimostrano che possono benissimo esistere e funzionare.

E qui concludo l'OT.

Comunque ben venga Linux preinstallato sui Dell. Ma soprattutto OpenOffice!! :)

Per non parlare degli :stordita: che insistono col dire che bisogna ricompilare il kernel.:doh:

Ti riferivi al mio post? Newbie di linux lo sono sicuramente, scemo un po' meno, magari stordito ogni tanto si, ma caxx@te così "mediocri" non ne sparo (al riguardo, il mio stile è a dir poco sopraffino, e le mie raffiche di m1nk1@t3 sono micidiali, ci ammazzo il tempo abitualmente :Prrr: )

Realtek distribuisce, per linux, i sorgenti alsa in forma "mista" (driver 1.0.12, lib e utils 1.0.9a) e con delle personalizzazioni, che vanno compilati (e trattandosi di moduli del kernel, non sbaglio se dico che sto compilando un pezzetto di kernel :p ). Qualcuno (http://alsa.opensrc.org/AlsaBuild2.6#Compiling_new_alsa-package) suggerisce di ricompilare separatamente anche il kernel, disabilitando i driver alsa già inclusi, per aggiornare ad una nuova versione avendo installato un kernel della famiglia 2.6.x (se non ho frainteso è un' "esigenza" meno sentita dal 2.6.9/2.6.10 in poi, o almeno con gli ultimi 2.6.xx)

Li ho provati tutti, ma il migliore, che mi sento di consigliare anche ai principianti, è questo:
http://www.roesch-swiss.ch/?id=1156&prod_id=34

Si apprezza subito la pulizia dell'insieme, The Mask direbbe: "...spumeggiante!" ;)

Sorridete, siete su candid camera!

forse non sai che ubuntu non è altro che Debian Etch.

Quindi evita di spalare merda se non sai e oltretutto evita di offendere per cortesia, non che ti voglia reportare anche perchè sai che me ne frega? nulla, un'utente in meno che spala merda per sport non mi cambia la vita :)

ps: sai perchè usano fedora core o redhat? fai 1+1 quando hai finito posta la soluzione e ti dico se è sbagliata o no ;)

Quello che ho detto lo ribadisco e lo sottoscrivo. Se si parla di Ubuntu, si dica Ubuntu e non si citi il nome Debian. Che Ubuntu sia basata su Debian non significa affatto che siano la stessa distro e che i target di utilizzo siano gli stessi. Tant'è che Ubuntu è una distro "desktop" mentre Debian è tutta da un'altra parte, come target.

Anche Mandriva, successore di Mandrake e basta su RedHat Linux, anche RedHat Enterprise server è basata su Fedora. Eppure sono distribuzioni che al di la delle origini, sono profondamente "diverse" come spirito e target.

Il mio post non significa spalare merda, significa semplicemente rimanere obiettivi, per lo meno piu' che dire seccamente e fanboyisticamente che "debian è l'excellence" quando per usare qualche software nuovo bisogna usare branch considerate "unstable" dagli stessi sviluppatori, proprio per la loro politica. Siamo in tema di un produttore che deve produrre sistemi desktop e enteprise. Target di utilizzo in cui il nome Debian sembra inappropriato in entrambi i casi.

Fatto l'1+1, si usa Fedora perchè ha una frequenza di aggiornamento elevata, ottimi standard di manutenzione generale e costi di mantenimento nullo (zero supporto), pur mantenendo di base il servizio "RedHat", il tutto unito ad una discreta facilità di configurazione e utilizzo, oltre al corredo di pacchetti di base decisamente adatto allo scopo.
Se serve supporto enterprise, Solaris potrebbe essere una scelta migliore di RedHat, ci sono molti paper in merito, soprattutto per il fatto che Solaris su hardware enterprise a marchio Dell si trova a casa sua, oltre ad avere servizi molto piu' adatti. Il self-healing e il support lifecycle ne sono una testomonianza.

Ancora sto aspettando che qualcuno mi porti un solo esempio in cui un driver libero è stato sfruttato da un concorrente per copiare l'hardware.

Ti tigiro la domanda. Trovami ancora un driver open che usi tutte le caratteristiche dell'hardware che controlla da poter svelare le caratteristiche hardware da copiare ;) Se per caso lo trovi, guarda la data di rilascio di quel componente. :D
E' anche vero che se avessimo i sorgenti dei driver ATI, probabilmente non avremmo ancora nulla da svelare... :asd: :asd:
Il discorso che si fa sul legame che c'è fra l'apertura dei driver e lo svelare caratteristiche hardware, in parte è vero. Non a caso Creative, che ha sempre collaborato anche con codice aperto, nel caso del chip EMU10K1, questa volta non ha nessuna intenzione di rilasciare dettagli hardware sul X-FI (e quindi rendere possibile la scrittura di driver).
Risultato: se avete una Sound Blaster Live! avrete dei driver aperti scritti per la maggior parte Creative stessa. Se avete una Sound Blaster X-FI, ve la potete ficcare nel... :stordita:

Linux comunque è troppo monolitico e può funzionare solo grazie alla forza bruta della sua infinita manodopera. E poi spuntano sempre questi problemi con i drivers.


Problemi che non dipendono dal kernel in se, ma dal fatto che si deve far coesistere qualcosa di chiuso con qualcosa che è aperto e in precoce evoluzione. Tant'è che i driver open che funzionano e sono parte del kernel, non incontrano mai problemi di sorta.
Anche Windows, quando cambia, ha gli stessi problemi. In Linux il problema è piu' evidente perchè si aggiorna spesso (anche se in modo decisamente piu' incrementale) ma alla base il discorso è uguale.
E non credere che non sarebbe lo stesso per OS-X, se avesse l'esposizione che devono avere gli altri SO.
Sappiamo tutti, in fondo in fondo, che la guerra dei SO è stupida. Siamo a livelli che tutto è un compromesso.

Anche OS-X non è da meno con questi problemi. Magari non per i driver, ma prima che Java fosse rilasciato sotto GPL, per avere un JRE/JDK decente doveva pagare i diritti a Sun e farsi il porting da sola, pena l'esclusione completa dal mondo Java, con il problema addizionale di essere sempre in ritardo sull'ultima versione stabile. Gira e rigira i problemi ce li hanno tutti. :D
Che poi, diciamoci la verità, a parte Apple, Objective-C non se lo caga nessuno. ;)

Io da sei mesi utilizzo Ubuntu 6.06 e ne sono un felice utilizzatore.
Non ho mai problemi. Una volta installati tutti i pacchetti è un sistema che non dà noie come windows XP.
E piano piano sto cambiando mentalità e andando sempre più verso l'opern source...tanto da scrivere la tesi cn Latex e non con MS Word.
Parlando di kernel e microkernel (sn ing elettronico ma nn ho mai studiato come funziona un SO anch se mi piacerebbe) ho capito che Debian è 100% GNU/linux in cui tutti i pacchetti sono open e liberi e così anche Fedora, mentre Ubuntu si sta un po' allontanando e così anche Suse, cioè diventeranno dei SO a se stanti e non avranno niente a che spartire con GNU/linux.
Questa è una mia idea.
Comunque non riesco più ad usare windows... ma solamente Ubuntu (è incredibile come riconosca tutte le periferiche come stampanti tastiere senza fili, la mia macchinetta fotografica digitale). Per navigare non utilizzo un router ma un modem usb. Ci ho messo 1 giorno per collegarlo... ma questo nn dipende da GNU/linux ma dai vari brand che nnrilasciano driver.
Ragazzi date a Cesare quel che è di Cesare. E' GNU/linux e non solo linux.
Evviva Richard Stallman il più grande filosofo degli ultimi 20 anni.
Senza di lui oggi non si palerebbe delle 4 libertà
Ciao a tuttie d Ubuntu for ever

Mi sono dimenticato una cosa....

il kernel HURD di Stallman com' è ?
So che è un micorokernel ed è finito al 90%. quando arriva al 100% ?

Li usano, li usano...
Symbian è un microkernel, OS X è (fondamentalmente) un microkernel, QNX è un ECCELLENTE microkernel... ecc.


Ti rispondo da programmatore Symbian. Symbian è pessimo sistema, credimi. Difficilissimo da configurare per i produttori e forse ancora più difficile da programmare per gli sviluppatori.

E in più: è lento. Mortalmente lento. I nuovi cellulari hanno processori strong ARM9 e ARM11 a 600mhz eppure la reattività del sistema è peggio di quella di windows 98.

Gli stessi manager nokia si riferiscono a symbian con l'appellativo: "That piece of crap"

Mai sentito parlare di N800? ecco, è solamente la punta dell'iceberg.

Quanto hai ragione. Nokia sta cercando di scappare da symbian il più in fretta possibile pur non volendo darlo a vedere... per il momento con linux ci giochicchia, perchè non possiede le basi per riscrivere un sistema da zero (Mica è microsoft), ma stai sicuro che appena gli capita l'occasione symbian finisce nel cestino. E di una cosa son sicuro: non lo rimpiangeremo.

Però nel frattempo usano Symbian (almeno i primi 2, Philips non so)....

Perchè non c'è nulla di meglio, e soprattutto perchè symbian è quello che una volta si chiamava "Epoc": hai mai sentito di telefoni con symbian 4 3 2 1? No? Già, perchè si chiama symbian dalla versione 7. Era il sistema operativo delle vecchie agendine tascabili... e il kernel è fondamentalmente ancora lo stesso. Non hai idea di come gestisce la memoria...

C'è un unica cosa che ha fatto sì che symbian arrivasse fino a dove è ora: è stato comprato dalla società che vende più telefoni al mondo, Nokia. Nokia sapeva che i telefoni sarebbero diventati sempre più complessi, ma non aveva il know-how per scriversi un sistema operativo da zero. Acquisire epoc è stata un a mossa intelligente: era un sistema già pensato per funzionare su dispositivi piccoli e metteva a disposizione un sacco di classi già pronte per la gestione degli input (pennini, touch screen, pulsantiere ecc...).
L'alternativa sarebbe stata farsi licenziare da qualcuno un sistema operativo (Microsoft? Chi lo sà...), ma voleva dire iniziare a diventare schiavi.
E così si è aggregata anche sony-ericsson che di aver a che fare con altri la sony non ne vuol sapere (te lo immagini windows mobile su un cellulare sony?).
Questa è la storia... almeno come la conosco io.

Io da sei mesi utilizzo Ubuntu 6.06 e ne sono un felice utilizzatore.
Non ho mai problemi. Una volta installati tutti i pacchetti è un sistema che non dà noie come windows XP.
E piano piano sto cambiando mentalità e andando sempre più verso l'opern source...tanto da scrivere la tesi cn Latex e non con MS Word.


Concedimi la battuta, questo non significa andare verso lo spirito open source, significa essere auto-lesionisti. :D
Scommetto che per ottenere un documento leggibile della tua tesi devi digitare "make dvi ; dvips tesi.ps tesi.dvi"
:asd: :asd:

P.S.: Accertati di inserire un README e un file COPYING e di consegnare il tutto in segreteria in un'opportuno pacchetto tar.bz2
Se fossi in te aggiungerei un'altra chicca: sulla copertina della tesi, farei stampare anche la scritta "GNU Press" a caratteri dorati. :rotfl:


Mi sono dimenticato una cosa....

il kernel HURD di Stallman com' è ?
So che è un micorokernel ed è finito al 90%. quando arriva al 100% ?


In un progetto software in genere si impiegano i primi 6 giorni per arrivare al 90% e i successivi 6 anni per arrivare al 100% :D
Non lo dico io, se ti leggi il libro di Pressman, "Principi di Ingegneria del Software", c'è riportata una simpatica storiella sull'argomento.
Tant'è che Hurd lo possiamo considerare morto. Lo stesso Stallman disse che Linux poteva essere considerato il kernel che aveva preso degnamente il suo posto. Il problema di Hurd è che nessuno trova il coraggio di ammetterlo, ma è fermo al 90% da quando Stallman stava ancora al MIT. ;) Come kernel, comunque, è indissolubilmente legato ad una storia d'amore di Stallman di quei tempi (che a quanto pare è andata a finire male, un po come il kernel).

Ti riferivi al mio post? Newbie di linux lo sono sicuramente, scemo un po' meno, magari stordito ogni tanto si, ma caxx@te così "mediocri" non ne sparo (al riguardo, il mio stile è a dir poco sopraffino, e le mie raffiche di m1nk1@t3 sono micidiali, ci ammazzo il tempo abitualmente :Prrr: )

Realtek distribuisce, per linux, i sorgenti alsa in forma "mista" (driver 1.0.12, lib e utils 1.0.9a) e con delle personalizzazioni, che vanno compilati (e trattandosi di moduli del kernel, non sbaglio se dico che sto compilando un pezzetto di kernel :p ). Qualcuno (http://alsa.opensrc.org/AlsaBuild2.6#Compiling_new_alsa-package) suggerisce di ricompilare separatamente anche il kernel, disabilitando i driver alsa già inclusi, per aggiornare ad una nuova versione avendo installato un kernel della famiglia 2.6.x (se non ho frainteso è un' "esigenza" meno sentita dal 2.6.9/2.6.10 in poi, o almeno con gli ultimi 2.6.xx)

Uhm, questa mi giunge nuova...
Ho almeno 5 controller audio realtek in casa... mi dici il modello con cui hai avuto questo problema e la distribuzione, così posso starci alla larga? :)

Perchè symbian è più consolidato.
Ma se fosse il migliore non ci sarebbe bisogno di studiare e fare ricerca su Linux, basterebbe evolvere Symbian....

Sante parole.

ho capito che Debian è 100% GNU/linux in cui tutti i pacchetti sono open e liberi e così anche Fedora, mentre Ubuntu si sta un po' allontanando e così anche Suse, cioè diventeranno dei SO a se stanti e non avranno niente a che spartire con GNU/linux.

Essere un sistema Linux significa utilizzare un kernel Linux, essere un sistema GNU/Linux significa utilzzare un kernel Linux e le raccolte di programmi GNU (http://directory.fsf.org/GNU/).
Utilizzare un sistema GNU/Linux ed applicarci zozzeria commerciale però non significa non essere più un sistema GNU/Linux.
Al limite significa solo vendere un po' il culo, ma niente di più :)

Evviva Richard Stallman il più grande filosofo degli ultimi 20 anni.

Pur con il massimo rispetto per il personaggio, ma ho dei grossi dubbi sulla tua affermazione.

Quanto hai ragione. Nokia sta cercando di scappare da symbian il più in fretta possibile pur non volendo darlo a vedere... per il momento con linux ci giochicchia, perchè non possiede le basi per riscrivere un sistema da zero (Mica è microsoft), ma stai sicuro che appena gli capita l'occasione symbian finisce nel cestino. E di una cosa son sicuro: non lo rimpiangeremo.

Ho un paio di amici qua e la... uno lavora in openedhand, l'altro in motorola.
Entrambi mi hanno detto che Nokia e Motorola stanno lavorando moltissimo in ricerca su Linux e ucLinux, per sostituire i loro attuali sistemi operativi, che sono decisamente alla frutta.

Da quello che mi dici sembra più che Nokia stia semplicemente tentando di "tenersi aggiornata", mentre dalla Motorola, invece, mi riferiscono che stanno facendo prove a portare tutte le interfacce attuali sui telefoni già in vendita, provando su hardware già in vendita, e stanno anche integrando ambienti grafici nuovi (molto sullo stile dell'integrazione tipo iPhone, ma con sotto Linux), per testare nuovi studi di usabilità.
Al momento non sembra che ci sia un reale piano di vendita, ma mi riferiscono che stanno rivoltando tutto il loro hardware come un calzino :)

Li ho provati tutti, ma il migliore, che mi sento di consigliare anche ai principianti, è questo:
http://www.roesch-swiss.ch/?id=1156&prod_id=34

Si apprezza subito la pulizia dell'insieme, The Mask direbbe: "...spumeggiante!" ;)
!ma lol, e il finnico non li ha citati per uso di marchio registrato? :D

Ho un paio di amici qua e la... uno lavora in openedhand, l'altro in motorola.
Entrambi mi hanno detto che Nokia e Motorola stanno lavorando moltissimo in ricerca su Linux e ucLinux, per sostituire i loro attuali sistemi operativi, che sono decisamente alla frutta.
Vero, verissimo. Il paradosso è che allo stesso tempo nokia non può abbandonare symbian da subito... più di un milione di telefoni symbian venduti all'anno sono tanti. E bisogna pensare a continuare a fornigli supporto almeno per un po'...

Da quello che mi dici sembra più che Nokia stia semplicemente tentando di "tenersi aggiornata", mentre dalla Motorola, invece, mi riferiscono che stanno facendo prove a portare tutte le interfacce attuali sui telefoni già in vendita, provando su hardware già in vendita, e stanno anche integrando ambienti grafici nuovi (molto sullo stile dell'integrazione tipo iPhone, ma con sotto Linux), per testare nuovi studi di usabilità.
Al momento non sembra che ci sia un reale piano di vendita, ma mi riferiscono che stanno rivoltando tutto il loro hardware come un calzino :)
Una cosa è certa... quando motorola inizierà ad adottare linux sul serio sui suoi telefoni, Nokia si troverà nella merda. Perchè ormai non basta fare bei cellulari. Stanno nascendo software house per cellulari ovunque: convincerle a lavorare per la propria piattaforma è fondamentale. E symbian non è che sia un gran benvenuto... assomiglia molto di più ad un pugno in faccia.

Una cosa è certa... quando motorola inizierà ad adottare linux sul serio sui suoi telefoni, Nokia si troverà nella merda. Perchè ormai non basta fare bei cellulari.

Bhè, ma perchè Nokia fa bei cellulari? :D

Bhè, ma perchè Nokia fa bei cellulari? :D

Beh, oddio... io preferisco i sonyericsson. Detto questo non mi chiedere cosa ci sia di bello in QUESTO AFFARE QUI' (http://www.nokia.it/link?cid=EDITORIAL_18231) per pagarlo un pozzo di soldi del genere. E poi non è neanche symbian... come fai a prendere un telefono non symbian? Non lo sapete che symbian è il futuro? :rolleyes:

Beh, oddio... io preferisco i sonyericsson. Detto questo non mi chiedere cosa ci sia di bello in QUESTO AFFARE QUI' (http://www.nokia.it/link?cid=EDITORIAL_18231) per pagarlo un pozzo di soldi del genere. E poi non è neanche symbian... come fai a prendere un telefono non symbian? Non lo sapete che symbian è il futuro? :rolleyes:

Soprattutto il 7380, se si potesse usare come Wii-mote, sai che gran successo che avrebbe... :rotfl:

Soprattutto il 7380, se si potesse usare come Wii-mote, sai che gran successo che avrebbe... :rotfl:

Spero di sfuggire alla morsa de moderatori vista l'ora tarda: a me il 7380 ricorda tanto un assorbente. :stordita:

Spero di sfuggire alla morsa de moderatori vista l'ora tarda: a me il 7380 ricorda tanto un assorbente. :stordita:

Volevo dire io una cosa del genere, mi era venuta in mente una battuta volgare :D :banned:
Ritornando a Linux e Motorola, sapevo che da qualche parte avevano rilasciato i sorgenti di un qualche prototipo di SO da cellulare da qualche parte. Mica ne sai qualcosa?
Comunque il futuro è emozionante: Linux + Java integrati in un singolo "package".

Concedimi la battuta, questo non significa andare verso lo spirito open source, significa essere auto-lesionisti. :D
Scommetto che per ottenere un documento leggibile della tua tesi devi digitare "make dvi ; dvips tesi.ps tesi.dvi"
:asd: :asd:

P.S.: Accertati di inserire un README e un file COPYING e di consegnare il tutto in segreteria in un'opportuno pacchetto tar.bz2
Se fossi in te aggiungerei un'altra chicca: sulla copertina della tesi, farei stampare anche la scritta "GNU Press" a caratteri dorati. :rotfl:

:D
Comunque io ho usato Lyx (più Kile per qualche rifinitura finale) ma poi ho consegnato solo lo stampato, il file non lo volevano ;) L'ho usato perchè sui testi scientifici/ingegneristici è il massimo secondo me, anche come velocità di scrittura delle formule matematiche (con OOo o con Office ci perevo il triplo del tempo).
La mia compagna ha scritto invece la tesi con OpenOffice, visto che, dopo aver scritto 80 pagine, Office 2003 impazziva, gli scombinava l'impaginazione ed, alla fine, crashava 2 volte su 3 all'apertura del documento: dopo due ore di pianti ha ascoltato il mio consiglio di usare OpenOffice ed ha consegnato felicemente la sua tesi :)

tanto OT ma è sfuggita una cosa abbastanza importante:

Non so se è old, cmq. Dell dice no a linux
http://www.newstech.eu/hardware/dell-dice-no-a-linux.html?Itemid=49

Ti rispondo da programmatore Symbian. Symbian è pessimo sistema, credimi. Difficilissimo da configurare per i produttori e forse ancora più difficile da programmare per gli sviluppatori.

E in più: è lento. Mortalmente lento. I nuovi cellulari hanno processori strong ARM9 e ARM11 a 600mhz eppure la reattività del sistema è peggio di quella di windows 98.

Gli stessi manager nokia si riferiscono a symbian con l'appellativo: "That piece of crap"

Sì avevo letto che Symbian ha dei problemi...
http://roughlydrafted.com/RD/RDM.Tech.Q1.07/6856C375-FE4E-4BC8-B753-B48AF3BD8B30.html

Ma a quanto ho capito sono dovuti principalmente al fatto che è stato progettato per girare su hardware molto limitato e per motivi di efficienza (su tale hardware) sono stati utilizzati stratagemmi che lo complicano notevolemente e sono anacronistici per l'hardware odierno.

Comunque il suo successo l'ha avuto, anche se oggi è superato. E già il solo fatto di utilizzare un microkernel su hardware così limitati la dice lunga sulla diatriba dei problemi prestazionali dei microkernel.

La moda dei microkernel è uscita fuori con Mach che ha dimostrato per primo di essere un microkernel con prestazioni comparabili ad OS monolitici (ma con tutti gli altri vantaggi citati). I due principali sviluppatori di sviluppatori di questo OS, Tevanian e Rashid, sono finiti rispettivamente a capo dello sviluppo dei sistemi operativi NeXT (poi Apple) e Microsoft!

Da quello che mi dici sembra più che Nokia stia semplicemente tentando di "tenersi aggiornata", mentre dalla Motorola, invece, mi riferiscono che stanno facendo prove a portare tutte le interfacce attuali sui telefoni già in vendita, provando su hardware già in vendita, e stanno anche integrando ambienti grafici nuovi (molto sullo stile dell'integrazione tipo iPhone, ma con sotto Linux), per testare nuovi studi di usabilità.
Al momento non sembra che ci sia un reale piano di vendita, ma mi riferiscono che stanno rivoltando tutto il loro hardware come un calzino :)

Effetto iPhone? ;)
Dopo la figuraccia che ha fatto Motorola, con i suoi cellulari con iTunes che erano una ca*ata pazzesca, ad Apple non è rimasto altro che farsi il cellulare da sola!!!
Dubito che Motorola sia in grado di farsi un OS... (anche solo di modificarne uno in modo decente).

Effetto iPhone? ;)
Dopo la figuraccia che ha fatto Motorola, con i suoi cellulari con iTunes che erano una ca*ata pazzesca, ad Apple non è rimasto altro che farsi il cellulare da sola!!!
Dubito che Motorola sia in grado di farsi un OS... (anche solo di modificarne uno in modo decente).
Hai ragione. Nè motorola nè nokia sono in grado di scriversi un SO da zero. Ma il fatto che sia osx che linux abbiano dimostrato di funzionare egregiamente sui cellulari, oltre a dirla lunga su quanto faccia pena symbian, ti fà capire che la diatriba microkernel vs monolitico non c'entra una mazza. Un kernel è buono quando funziona. Punto.

Sì avevo letto che Symbian ha dei problemi...
http://roughlydrafted.com/RD/RDM.Tech.Q1.07/6856C375-FE4E-4BC8-B753-B48AF3BD8B30.html


Proporio a questo mi riferivo. Quando steve jobs sostiene che l'iphone è 5 anni avanti alla concorrenza ha ragione. Ma non per l'interfaccia grafica o per le funzionalità... Ma per il sistema che c'è sotto.

Detto questo non ritengo che l'iphone valga i soldi che costa.

tanto OT ma è sfuggita una cosa abbastanza importante:
Mi sembra sia precedente al poll in questione. Dell non ha al momento intenzione di fornire linux preinstallato, ma stanno approfondendo le richieste degli utenti.

buona idea dell+linux ;)

E già il solo fatto di utilizzare un microkernel su hardware così limitati la dice lunga sulla diatriba dei problemi prestazionali dei microkernel.

Scusa, ma a me un processore ARM11 a 600mhz non sembra proprio un "hardware limitato", anzi, mi sembra che li ci sia potenza di calcolo a barili.
Considerando che Linux gira su router, macchinette del caffè, tostapane, centraline dei termostati, impianti di illuminazione, che usano potenze molto ma molto ma molto inferiori ad un telefonino, non mi sembra che symbian di distingua per prestazionalità.

Faccio un esempio pratico di un prodotto che ho sott'occhi da ultimo: il pc è fornito da DAVE-Elettronica (http://www.dave-tech.it/index.php?page=2&news=67&group=products&subgroup=) che è nella configurazione base, con il processore a 133mhz.
Questo apparecchietto viene alloggiato su un pallet din da 6 moduli, per quadro elettrico, e gestisce la comunicazione wifi con i lampioni, l'elaborazione dei dati di usura e di operatività di tutti i lampioni, gestisce una ethernet, una vpn via ethernet per l'amministrazione da remoto, scrive su memory card, gestisce un modem gprs per l'invio di sms di avviso, e qualche altra funzione che tuttora mi è ignota.
Tutto questo con che sistema operativo è realizzato? Ma ovviamente Linux 2.6, perchè linux sì che scala verso situazioni a limitata potenza di calcolo, a differenza dei microkernel :)

La moda dei microkernel è uscita fuori con Mach che ha dimostrato per primo di essere un microkernel con prestazioni comparabili ad OS monolitici (ma con tutti gli altri vantaggi citati). I due principali sviluppatori di sviluppatori di questo OS, Tevanian e Rashid, sono finiti rispettivamente a capo dello sviluppo dei sistemi operativi NeXT (poi Apple) e Microsoft!

Che i primissimi Mach non fossero completamente un calcio nelle palle, come invece è oggi, sono d'accordo, ma sul fatto che avesse prestazioni paragonabili con i kernel monolitici del tempo proprio no.
Mach era lentissimo e pesantissimo, tanto che i vari cubozzi che NeXT vendeva dovevano avere una potenza di calcolo di un centro di ricerca sul genoma, per far girare decentemente NeXTStep.
Sistemi operativi Windows e Digital, ai tempi giravano meglio e con hardware molto meno potenti.

Ti tigiro la domanda. Trovami ancora un driver open che usi tutte le caratteristiche dell'hardware che controlla...
Gli ultimi driver Intel per i loro dispositivi wireless?
...da poter svelare le caratteristiche hardware da copiare
Cosa puoi "rubare" dell'hardware da quei driver?

Appunto dico che Linux è stato fortunato.
E' uscito al momento giusto, ha saputo raccogliere intorno a sè un vasto interesse.
...e i sistemi *BSD non erano altrettanto disponibili al "momento giusto"?
http://www.levenez.com/unix/history.html#07
Però oggi esistono alternative migliori. BSD è il VERO Unix!! Sicuramente megliore di Linux. Anche come licenza (per un utilizzo commerciale).
Strano, mi era parso che le grandi realtà commerciali avessero deciso di preferire linux.

Scusa, ma a me un processore ARM11 a 600mhz non sembra proprio un "hardware limitato", anzi, mi sembra che li ci sia potenza di calcolo a barili.

Oggi sì, tanto che Apple ci farà girare addirittura OS X. Ma quando è stato progettato il predecessore di Symbian (EPOC) negli anni '90, le cose non erano certamente così.

Mach era lentissimo e pesantissimo, tanto che i vari cubozzi che NeXT vendeva dovevano avere una potenza di calcolo di un centro di ricerca sul genoma, per far girare decentemente NeXTStep.
Sistemi operativi Windows e Digital, ai tempi giravano meglio e con hardware molto meno potenti.

Ma che dici!?
Il NeXT aveva un 68040 con 8 MB di ram!!!
La stessa configurazione di un Mac dell'epoca di fascia alta.
E se vedi i demo dell'epoca (gira un filmato con Jobs che lo illustra per benino) sono da far cadere la mascella ancora oggi!!!

Edit: Ecco il filmato: http://youtube.com/watch?v=j02b8Fuz73A

...e i sistemi *BSD non erano altrettanto disponibili al "momento giusto"?
http://www.levenez.com/unix/history.html#07

Oddio!!
Aiutami tu!!
Comunque io ho sentito parlare dei BSD free ben dopo che Linux era una realtà affermata. Anche se non ti saprei dire quando li hanno rilasciati...

Strano, mi era parso che le grandi realtà commerciali avessero deciso di preferire linux.

Mah... grandi... è diffuso giusto sui server. E lì fanno i soldi con il supporto, non con i software. Il problema di Linux è che nessuno vuole rilasciare software commerciali, in particolare i produttori di periferiche per i problemi sopra riportati.

Se un programmatore è veramente bravo prima o poi verrà assunto da una Google/Adobe/Microsoft/Apple/ecc. Mica è così cretino a lavorare gratis per sempre... quindi il software free non potrà mai competere a certi livelli.

Ma che dici!?
Il NeXT aveva un 68040 con 8 MB di ram!!!
La stessa configurazione di un Mac dell'epoca di fascia alta.
E se vedi i demo dell'epoca (gira un filmato con Jobs che lo illustra per benino) sono da far cadere la mascella ancora oggi!!!

Il NeXTCube aveva il 68030 o il 68040 e da 8mb a 64mb di ram a seconda dei modelli. nel 1990.
Non so te, ma io 8 mega di ram li ho visti nel 1995, e gli 8mb di ram erano ancora la configurazione minima.

Un architetto amico di famiglia nel 1991 comprò un NeXTCube 040, che aveva equipaggiato con 32 (!!!) mb di ram. Inutile dire che i 32mb di ram sui pc in vendita si sarebbero visti solo con i pentium mmx, anni dopo.

i pc NeXT erano dei mostri di potenza rispetto ai normali pc dello stesso periodo. tutto questo per fare girare Mach.

PS: il 68030 e il 68040 erano tutto fuochè lenti come processori. Avevano prestazioni notevoli, tanto che venivano spesso usati con OS proprietari in centri di calcolo o in server amminitrativi bancari. E NeXT li mise su un pc.
Non dico altro.

Mah... grandi... è diffuso giusto sui server. E lì fanno i soldi con il supporto, non con i software. Il problema di Linux è che nessuno vuole rilasciare software commerciali, in particolare i produttori di periferiche per i problemi sopra riportati.
Stai un pò confondendo due cose:
- il software applicativo, commerciale
- i driver

Nel primo caso, il produttore fa i soldi vendendo le licenze del software. Per come la vedo io, non c'è nessun problema o ostacolo a vendere licenze commerciali per linux, tanti lo fanno (Oracle, IBM, e anche molte piccole entità). Non c'è molta differenza nel "vendere" un programma per Windows o per linux.
Nel secondo caso, il produttore fa i soldi vendendo l'hardware, non realizzando i driver.

Oddio!!
Aiutami tu!!
Comunque io ho sentito parlare dei BSD free ben dopo che Linux era una realtà affermata. Anche se non ti saprei dire quando li hanno rilasciati...

FreeBSD 1.0 è uscito qualche mese prima del kernel linux 1.0. Non so il BSD originale che licenza aveva, se commerciale o...BSD.

Stai un pò confondendo due cose:
- il software applicativo, commerciale
- i driver

Nel primo caso, il produttore fa i soldi vendendo le licenze del software. Per come la vedo io, non c'è nessun problema o ostacolo a vendere licenze commerciali per linux, tanti lo fanno (Oracle, IBM, e anche molte piccole entità). Non c'è molta differenza nel "vendere" un programma per Windows o per linux.
Nel secondo caso, il produttore fa i soldi vendendo l'hardware, non realizzando i driver.

Sì sono cose differenti ma in entrambi i casi i produttori sono scoraggiati a rilasciare i loro software su Linux, nel primo caso perché gli utilizzatori di Linux non sono "abituati" a pagare per il software, nel secondo perché dovrebbero rilasciare i loro sorgenti free.

In entrambi i casi non butta bene per un sistema che vuole conquistare il mondo e sostituirsi a M$...

Se si liberasse un po' della sua "religione" GNU ed avesse un atteggiamento più pragmatico, potrebbe avere una chance. Anche se è un OS vecchio e monolitico! ;)

Le applicazioni free e commerciali possono convivere. Sia su Win che su Mac sono disponibili eccellenti software freeware o shareware.
Ma non è necessario che lo siano tutti i software per motivi religiosi. Questo è solo controproducente per la piattaforma.

Vogliamo anche parlare dell'assurdo sistema di installazione dei programmi?
Come può convivere un software commerciale con un sistema come quello di Linux dove i software e le loro (pazzesche!!) dipendenze sono gestiti da un sistema centralizzato e automatizzato?
O che altrimenti costringe il produttore a fare diversi installer a seconda della "distribuzione" sempre molto instabile?

Sì sono cose differenti ma in entrambi i casi i produttori sono scoraggiati a rilasciare i loro software su Linux, nel primo caso perché gli utilizzatori di Linux non sono "abituati" a pagare per il software
Non è affatto vero, la dimostrazione la hai sotto gli occhi. hwu gira su server rigorosamente linux, ma per gestire il forum è stato scelto il commerciale vbulletin, pur esistendo l'alternativa libera phpBB.
Anzi una cosa che gli utenti linux sono "abituati a fare" è rispettare le licenze altrui.
nel secondo perché dovrebbero rilasciare i loro sorgenti free.

Chi li vuole i loro sorgenti, voglio solo sapere su che c***o di registro scrivere per attivare il TV-OUT sulle schede ATI. Chiedo troppo?

Vogliamo anche parlare dell'assurdo sistema di installazione dei programmi?
Come può convivere un software commerciale con un sistema come quello di Linux dove i software e le loro (pazzesche!!) dipendenze sono gestiti da un sistema centralizzato e automatizzato?
O che altrimenti costringe il produttore a fare diversi installer a seconda della "distribuzione" sempre molto instabile?
Non sai di cosa stai parlando, per favore astieniti

Il NeXTCube aveva il 68030 o il 68040 e da 8mb a 64mb di ram a seconda dei modelli. nel 1990.
Non so te, ma io 8 mega di ram li ho visti nel 1995, e gli 8mb di ram erano ancora la configurazione minima.

Un architetto amico di famiglia nel 1991 comprò un NeXTCube 040, che aveva equipaggiato con 32 (!!!) mb di ram. Inutile dire che i 32mb di ram sui pc in vendita si sarebbero visti solo con i pentium mmx, anni dopo.

i pc NeXT erano dei mostri di potenza rispetto ai normali pc dello stesso periodo. tutto questo per fare girare Mach.

PS: il 68030 e il 68040 erano tutto fuochè lenti come processori. Avevano prestazioni notevoli, tanto che venivano spesso usati con OS proprietari in centri di calcolo o in server amminitrativi bancari. E NeXT li mise su un pc.
Non dico altro.

Dai su, aveva gli stessi processori dei Mac. Certo quelli più veloci, e con il doppio della Ram (che comunque erano solo 8MB all'inizio). Ma aveva anche uno schermo da 1 Mpixel da gestire, quando i Mac II avevano un monitor da 640x480.
I Mac (e bada che erano 2 spanne sopra ai PC in quell'epoca) non facevano quello che faceva il NeXT. Neanche lontanamente!

Aveva, è vero, alcuni chip custom DMA, un chip DSP e opzionalmente alcune schede video molto sofisticate, però il processore era quello che era (e infatti era la cosa che mi lasciava più perplesso all'epoca, perchè c'erano dei RISC migliori).

Quello che fa quel NeXT nel video ci vorranno 10 anni per vederlo nei nostri computer 'normali'.

Quello che fa quel NeXT nel video ci vorranno 10 anni per vederlo nei nostri computer 'normali'.

Non ho detto che NeXTStep non fosse innovativo per il tempo, ho solo detto che era oltremodo pesante, anche per le sue caratteristiche innovative.
Del resto Windows 3.1 offriva quasi tutte le stesse caratteristiche, tra cui il drag and drop, gestire risoluzioni a 800x600, sottosistema audio, e nel 1994 anche tcp/ip, e client di posta di terze parti, e tutto questo con hardware molto più basso di quello montato su NeXT.
nextstep poteva tanto perchè fondamentalmente recuperava utility e sistema base sa Unix, ed era stato farcito con progetti interessanti quanto ad usabilità.

Windows 95 (a parte la stabilità) non aveva oggettivamente nulla meno di NeXTStep, ed arrivò nel settembre 1995, non certo 10 anni dopo, e comunque se la cavava ancora con hardware inferiore a quello NeXT.

Aggiungo che altri sistemi operativi, come ViewMax, avevano features molto interessanti con costi ed hardware irrisorio sia rispetto a windows che rispetto a nextstep.

Sì sono cose differenti ma in entrambi i casi i produttori sono scoraggiati a rilasciare i loro software su Linux, nel primo caso perché gli utilizzatori di Linux non sono "abituati" a pagare per il software, nel secondo perché dovrebbero rilasciare i loro sorgenti free.


Anche se è un OS vecchio e monolitico! ;)



Vogliamo anche parlare dell'assurdo sistema di installazione dei programmi?

Io ho pagato il mio Passpartout(gestionale) 1200€ + 400€ annue di manutenzione e aggiornamenti. Uso ubuntu da 3 anni e anche se quel gestionale per Linux è fatto per sistemi Suse e RH per via dei pacchetti RPM non c'è stata nessuna difficoltà a trasformarli in DEB.

Non sono un tecnico, quindi se tu mi dici che è un SO "vecchio e monolitico" ti credo, ma chi se ne frega se funziona benissimo?

Mah?! tanto assurdo io non lo vedo come sistema di installazzione, anzi.

Concedimi la battuta, questo non significa andare verso lo spirito open source, significa essere auto-lesionisti. :D
Scommetto che per ottenere un documento leggibile della tua tesi devi digitare "make dvi ; dvips tesi.ps tesi.dvi"
:asd: :asd:

P.S.: Accertati di inserire un README e un file COPYING e di consegnare il tutto in segreteria in un'opportuno pacchetto tar.bz2
Se fossi in te aggiungerei un'altra chicca: sulla copertina della tesi, farei stampare anche la scritta "GNU Press" a caratteri dorati. :rotfl:

Utilizzo kile un editor di testo. Ho scritto tutta la tesi di getto, senza sapere come veniva, poi ho diviso in capitoli, paragrafi, ho dato il main, ho inserito \tableofcontent.
Alt+F2, ha compilato e poi ho premuto il tasto da DVI a pdf e la tesi in pdf l'ho finita in 1 settimana.
Se avessi usato word o open office ci avrei messo 1 mese perché hanno dei bug immensi.

Io sono un ingegenre iscritto alla IEEE e mi sembra che tutti i testi scientifici sono scritti in latex e non i word o openoffice
Questi ultimi due li usa solamente qualche ingegnere del c@z.... come il cestista Michael Jordan in NBA

Salve a tutti,
prima si parlava di driver open source per le schede Wireless Intel.

Magari ho frainteso io, però le cose non stanno proprio così: è vero che il driver è open, ma il firmware della periferica no. E, guardacaso, il driver open è piuttosto piccolo, mentre il firmware è decisamente più corposo... ho la sensazione che il vero driver risieda nel firmware, mentre il driver open sia solo un'interfaccia verso di esso.

Sebbene anche io preferisca sicuramente che i driver siano open, non vedo quale sia l'enorme problema per linux: semplicemente non li si inserisce nella distribuzione e si lascia la briga all'utente di scaricali e installarli. Sapendo, ovviamente, che quel driver viola la liceza del kernel stesso e che quindi, in caso di problemi, il responsabile non sarà certo linux, ma il driver.

Rispondendo a ilsensine, personalmente credo che le case produttrici di chip grafici non vogliano rilasciare il codice dei driver perchè nei driver stessi potrebbero esserci avanzate routine di compressione delle texutre, di ottimizzazione dei triangoli, di rimozione delle superfici nascoste, di sfruttamente delle estensioni SIMD, ecc.. Insomma, immagino che non tutte le feature sbandierate dai produttori siano realmente al 100% integrate nell'hardare, ma magari qualcosa è implementato anche lato software (nel driver). Se le cose stanno davvero così e decidessero comunque di rilasciare i driver open, stai pur certo che brevetterebbero tutto il brevettabile. E una situazione del genere (software open ma brevettato) mi piacerebbe ancora meno che avere il driver closed.

Comunque, lo ribadisco, personalmente preferirei di gran lunga driver open!

Discorso micro/mono kernel: la possibilità che un driver scritto male crashi un sistema monolitico è reale, ma in passato i microkernel avevano seri problemi di performance. Sono stati risolti?

Sono due righe che ho scritto così di "getto", magari ho detto delle inesattezze... nel caso perdonatemi! ;)

Ciao. :)

Mi autoquoto... così magari potete confermare / smentire quello che ho scritto! :p

Ciao. :)

Mi autoquoto... così magari potete confermare / smentire quello che ho scritto! :p

Avevo perso il tuo post...

Magari ho frainteso io, però le cose non stanno proprio così: è vero che il driver è open, ma il firmware della periferica no.

Esatto, e con ciò? L'uso di firmware è comunissimo. Il firmware risiede anche negli hard disk, nei lettori cd-rom, nei dispositivi USB, ecc.
La differenza è che il firmware (anche se "iniettato" dal driver) fa parte integrante del dispositivo che ti viene venduto, non viene eseguito sul tuo computer. E' estremamente comodo per chi fa l'hardware, in quanto molto più flessibile di soluzioni "hardcoded" in hardware o in ROM.
Visto che il firmware collabora con l'hardware per creare il dispositivo completo (nota: "creare", non "utilizzare"!) posso essere d'accordo che rilasciare il firmware vuol dire divulgare dettagli importanti sul dispositivo.
E, guardacaso, il driver open è piuttosto piccolo, mentre il firmware è decisamente più corposo...
Vuole semplicemente dire che il firmware è fatto bene, e mostra al driver una interfaccia di controllo pulita e semplice da usare.
nb un driver in kernel space ___deve___ essere piccolo. Se è "grande", c'è qualcosa che non va ;)
Rispondendo a ilsensine, personalmente credo che le case produttrici di chip grafici non vogliano rilasciare il codice dei driver perchè nei driver stessi potrebbero esserci avanzate routine di compressione delle texutre
S3TC. Ne abbiamo già una implementazione libera grazie.
di ottimizzazione dei triangoli, di rimozione delle superfici nascoste, di sfruttamente delle estensioni SIMD, ecc..
Non vogliamo sapere come le hanno realizzate nei loro driver, vogliamo solo conoscere abbastanza dettagli sull'hardware per implementarle ex novo.
Insomma, immagino che non tutte le feature sbandierate dai produttori siano realmente al 100% integrate nell'hardare
Ma _sicuramente_ non lo sono, e non c'è nulla di male a dirlo.
A meno che non c'è qualcos'altro da tenere "segreto", e qui quoto Jeff Garzik -- uno che di driver ne ha fatti parecchi:
When I am forced to sign NDAs to get hardware specs, the hardware IP "revealed" is inevitably something that some other company has done before, and done better. NDAs and closed specs are IMO only used by vendors to save face, when their hardware design is stupid, and their errata innumerable.

Avevo perso il tuo post...

Esatto, e con ciò? L'uso di firmware è comunissimo. Il firmware risiede anche negli hard disk, nei lettori cd-rom, nei dispositivi USB, ecc.
La differenza è che il firmware (anche se "iniettato" dal driver) fa parte integrante del dispositivo che ti viene venduto, non viene eseguito sul tuo computer. E' estremamente comodo per chi fa l'hardware, in quanto molto più flessibile di soluzioni "hardcoded" in hardware o in ROM.
Visto che il firmware collabora con l'hardware per creare il dispositivo completo (nota: "creare", non "utilizzare"!) posso essere d'accordo che rilasciare il firmware vuol dire divulgare dettagli importanti sul dispositivo.

Pensavo che questo fosse valido solo per le periferiche con firmware non eccessivamente corposi... quindi anche il firmware della scheda di rete wireless intel non viene eseguito sul processore della macchina host ma direttamente sul chip del dispositivo? Mmm, non so... ho "paura" che nel file del "firmware" in realtò risieda un bel pezzo di software che viene eseguito sulla macchina (a mo' di quello che si faceva con i Winmodem). E' solo un'impressione però, tu sicuramente sei molto più informato di me... :)

Vuole semplicemente dire che il firmware è fatto bene, e mostra al driver una interfaccia di controllo pulita e semplice da usare.
nb un driver in kernel space ___deve___ essere piccolo. Se è "grande", c'è qualcosa che non va ;)

Perfettamente d'accordo!

S3TC. Ne abbiamo già una implementazione libera grazie.

Non mi riferivo solo al "semplice" S3TC. Ad esempio, da parecchi anni le schede ATI (o, meglio, i driver ATI) analizzano le texture per capire se è possibile applicare il brilineare invece del trilineare puro senza un impatto visivo notabile... magari non vogliono che il codice che analizza la texture (e che gli permette un ottimo guadagno prestazionale ;)) sia reimplementato in altri driver.

Non vogliamo sapere come le hanno realizzate nei loro driver, vogliamo solo conoscere abbastanza dettagli sull'hardware per implementarle ex novo.

Sono di nuovo d'accordo con te, ma immagino che sia proprio questo che le case come ATI e NVIDIA non vogliano mollare: la possibilità, anche remota, di capire appieno come funziona l'accoppiata hardware/software, forse temendo che qualche concorrente ne tragga spunto per migliorare il suo prodotto.

Ma _sicuramente_ non lo sono, e non c'è nulla di male a dirlo.
A meno che non c'è qualcos'altro da tenere "segreto", e qui quoto Jeff Garzik -- uno che di driver ne ha fatti parecchi:
Effettivamente fa riflettere parecchio (l'avevi anche in firma questa citazione, vero? ;))...

Ciao. :)

Pensavo che questo fosse valido solo per le periferiche con firmware non eccessivamente corposi... quindi anche il firmware della scheda di rete wireless intel non viene eseguito sul processore della macchina host ma direttamente sul chip del dispositivo? Mmm, non so... ho "paura" che nel file del "firmware" in realtò risieda un bel pezzo di software che viene eseguito sulla macchina (a mo' di quello che si faceva con i Winmodem). E' solo un'impressione però, tu sicuramente sei molto più informato di me... :)
Non sta a noi dire quanto deve essere "grande" il firmware Intel. Evidentemente hanno preferito puntare molto più sul firmware e semplificare molto l'hardware.
Riguardo i winmodem, come funzionavano i modem _veri_? O con un hw molto complesso per fare le modulazioni, o con un firmware apposito, o con una combinazione dei due. Il discorso è lo stesso.
Anzi, visto che i winmodem non sono altro che scadenti schede audio, è incredibile come vengano tenute segrete le quattro fesserie che possono fare. Alcuni lo hanno capito, e oggi abbiamo i driver ALSA liberi per i winmodem Intel e VIA. La logica di modulazione viene effettuata in userspace da un demone proprietario; purtroppo non ne sono mai stati fatti di liberi per la modulazione V90.


Non mi riferivo solo al "semplice" S3TC. Ad esempio, da parecchi anni le schede ATI (o, meglio, i driver ATI) analizzano le texture per capire se è possibile applicare il brilineare invece del trilineare puro senza un impatto visivo notabile...
Ok quindi è una pura ottimizzazione software nei loro driver. Non serve questa informazione per realizzare il driver.

Sono di nuovo d'accordo con te, ma immagino che sia proprio questo che le case come ATI e NVIDIA non vogliano mollare: la possibilità, anche remota, di capire appieno come funziona l'accoppiata hardware/software, forse temendo che qualche concorrente ne tragga spunto per migliorare il suo prodotto.
...e la r200? Ho già raccontato la sua storia, devo ripeterla? :)

Non sta a noi dire quanto deve essere "grande" il firmware Intel. Evidentemente hanno preferito puntare molto più sul firmware e semplificare molto l'hardware.
Riguardo i winmodem, come funzionavano i modem _veri_? O con un hw molto complesso per fare le modulazioni, o con un firmware apposito, o con una combinazione dei due. Il discorso è lo stesso.
Anzi, visto che i winmodem non sono altro che scadenti schede audio, è incredibile come vengano tenute segrete le quattro fesserie che possono fare. Alcuni lo hanno capito, e oggi abbiamo i driver ALSA liberi per i winmodem Intel e VIA. La logica di modulazione viene effettuata in userspace da un demone proprietario; purtroppo non ne sono mai stati fatti di liberi per la modulazione V90.

Si, è vero, ma nei Winmodem il "modem emulato" girava appunto sul processore host. A questo punto, che differenza fa se a girare è un driver o un firmware? Forse che il firmware gira in userspace e il driver in kernel space (chiedo per capire meglio, non sono polemico eh!)?


Ok quindi è una pura ottimizzazione software nei loro driver. Non serve questa informazione per realizzare il driver.

Ah, quindi basterebbe pubblicare anche un driver, diciamo, "castrato". Be si, in effetti sarebbe possibile (non ci avevo pensato! :stordita: ), ma penso che per "paranoia" di lasciare qualcosa di importante, ci pensino diecimila volte prima di rilasciare i sorgenti... :(

...e la r200? Ho già raccontato la sua storia, devo ripeterla? :)

Ehm, veramente questa me la sono persa... ti dispiacerebbe farmi un piccolo sunto e/o indirizzarmi a qualche link sull'argomento?
Comunque, se non ricordo male, le specifiche di R200 furono rilasciate ben dop o che R300 (un chip completamente diverso) fece il suo debutto... magari dopo R600 rilasceranno finalmente le specifiche di R300! (della serie: rilasciamo i driver quando sono quasi inutili... :D ).

Ciao. :)

Si, è vero, ma nei Winmodem il "modem emulato" girava appunto sul processore host. A questo punto, che differenza fa se a girare è un driver o un firmware?
Il driver è un programma che gira sul tuo processore e nel tuo sistema operativo linux; il firmware gira sul dsp del dispositivo che è un mondo a parte.
In termini pratici, puoi prendere l'hardware (compreso il suo firmware) e portarlo dalla tua linux box x86 su uno scatolotto con processore ARM, e farlo funzionare ugualmente. Non puoi invece riciclare un driver closed source. Inoltre, un driver closed source non di rado ti pone vincoli sulla versione del kernel, la sua configurazione, ecc. Insomma, ti impedisce di esercitare la libertà che un sistema operativo libero di dovrebbe garantire.


Ah, quindi basterebbe pubblicare anche un driver, diciamo, "castrato".
Sei fissato con questa storia di "pubblicare il driver" :D
NON VOGLIAMO che pubblichino una sola riga di codice, ci basta sapere come creare un driver da zero.


Ehm, veramente questa me la sono persa... ti dispiacerebbe farmi un piccolo sunto e/o indirizzarmi a qualche link sull'argomento?
Non c'erano specifiche per l'r200. Poi "qualcosa" (una compagnia che era disposta a PAGARE per avere driver liberi) "convinse" ATI a divulgare delle specifiche. Di fronte ai $$$, tutte le fesserie sulla IP andarono a farsi benedire. Ah e ovviamente nvidia non trasse nessun vantaggio dal driver r200 libero.

Comunque, se non ricordo male, le specifiche di R200 furono rilasciate ben dop o che R300 (un chip completamente diverso) fece il suo debutto...
Non so quando è stato rilasciato l'r300; la notizia ufficiale che era finalmente possibile realizzare il driver libero per l'r200 è stata data l'8/6/2002.
E comunque ad oggi la ATI non ha rilasciato nulla sull'r300, con tutto che ormai è hw obsoleto e stanno tirando fuori schede DX10 (il driver esistente è frutto di reverse engeenering). Cosa stanno difendendo _oggi_ sull'r300?

Il driver è un programma che gira sul tuo processore e nel tuo sistema operativo linux; il firmware gira sul dsp del dispositivo che è un mondo a parte.
In termini pratici, puoi prendere l'hardware (compreso il suo firmware) e portarlo dalla tua linux box x86 su uno scatolotto con processore ARM, e farlo funzionare ugualmente. Non puoi invece riciclare un driver closed source. Inoltre, un driver closed source non di rado ti pone vincoli sulla versione del kernel, la sua configurazione, ecc. Insomma, ti impedisce di esercitare la libertà che un sistema operativo libero di dovrebbe garantire.
Ecco, è proprio il fatto che il firmware di intel giri sul DSP non mi convince molto. Sicuro che non giri sul processore host, dialogando poi con il chip wireless? C'è qualche modo di verificarlo? Ho questo dubbio perchè mi pare strano che un DSP abbia la capacità di far girare un firmware del genere... ho preso l'esempio dei Winmodem perchè accadeva un po' proprio questo: un driver girava sul processore host e, a computazione finita, dialogava con il DSP di turno (il chip audio).



Sei fissato con questa storia di "pubblicare il driver" :D
NON VOGLIAMO che pubblichino una sola riga di codice, ci basta sapere come creare un driver da zero.

Be', mi pare che prima nel thread si discuteva proprio della necessità di pubblicare i sorgenti dei driver... magari ho frainteso. :D
Comunque, mi accodo anche io alla richiesta delle specifiche! :read:


Non c'erano specifiche per l'r200. Poi "qualcosa" (una compagnia che era disposta a PAGARE per avere driver liberi) "convinse" ATI a divulgare delle specifiche. Di fronte ai $$$, tutte le fesserie sulla IP andarono a farsi benedire. Ah e ovviamente nvidia non trasse nessun vantaggio dal driver r200 libero.


Non so quando è stato rilasciato l'r300; la notizia ufficiale che era finalmente possibile realizzare il driver libero per l'r200 è stata data l'8/6/2002.
E comunque ad oggi la ATI non ha rilasciato nulla sull'r300, con tutto che ormai è hw obsoleto e stanno tirando fuori schede DX10 (il driver esistente è frutto di reverse engeenering). Cosa stanno difendendo _oggi_ sull'r300?

R300 è stato presentato per la prima volta a Luglio 2002... quindi non c'è stato divario tra pubblicazione delle specifiche di R200 e la presentazione di R300 (pensavo che le specifiche fossero state pubblicate tempo dopo). In ogni caso non è proprio corretto definire R300 obsoleto: in molte parti lo sarà pure, ma le singole unità shader di R580 gli sono molto vicine come architettura. ;)

Per curiosità, sai dirmi dove reperire le specifiche di R200? Grazie!

Ciao. :)

Ecco, è proprio il fatto che il firmware di intel giri sul DSP non mi convince molto. Sicuro che non giri sul processore host, dialogando poi con il chip wireless?
Sì, sicuro.
C'è qualche modo di verificarlo?
Non è un programma per linux ;)

ho preso l'esempio dei Winmodem perchè accadeva un po' proprio questo: un driver girava sul processore host e, a computazione finita, dialogava con il DSP di turno (il chip audio).
In quel caso c'è un driver proprietario in kernel space, o un demone proprietario in user space. Un programma per linux, insomma.

Per curiosità, sai dirmi dove reperire le specifiche di R200? Grazie!

Le ha la Tungsten Graphics, sotto NDA, quindi non può divulgarle a terzi.

Si, è vero, ma nei Winmodem il "modem emulato" girava appunto sul processore host. A questo punto, che differenza fa se a girare è un driver o un firmware? Forse che il firmware gira in userspace e il driver in kernel space (chiedo per capire meglio, non sono polemico eh!)?la differenza è che un firmware è in ogni caso codice residente (*) sulla periferica, sul device, o nel caso del BIOS, sulla scheda madre...
qualunque pezzo di software che venga eseguito dal processore centrale internamente al sistema operativo sarà un driver a livello di kernel o un servizio, ma non è firmware, punto ;)

* la cosa essenziale da considerare, per evitare confusione, è che un firmware può essere "residente" a bordo del device di cui è specifico e su cui dovrà girare , in modo persistente o transitorio
nel primo caso qualora memorizzato su una memoria non volatile (eprom, flash) , nel secondo qualora venga uploadato al device al momento di inizializzarlo (tipicamente proprio dal driver per l' OS, che quindi conterrà il BLOB del firmware come "payload") - e il motivo per cui adottare una tecnica del genere è invariabilmente per risparmiare il costo della memoria flash

Sì, sicuro.

Non è un programma per linux ;)

In quel caso c'è un driver proprietario in kernel space, o un demone proprietario in user space. Un programma per linux, insomma.


Le ha la Tungsten Graphics, sotto NDA, quindi non può divulgarle a terzi.

Benissimo, ho le idee più chiare... ti ringrazio! :)

la differenza è che un firmware è in ogni caso codice residente (*) sulla periferica, sul device, o nel caso del BIOS, sulla scheda madre...
qualunque pezzo di software che venga eseguito dal processore centrale internamente al sistema operativo sarà un driver a livello di kernel o un servizio, ma non è firmware, punto ;)

* la cosa essenziale da considerare, per evitare confusione, è che un firmware può essere "residente" a bordo del device di cui è specifico e su cui dovrà girare , in modo persistente o transitorio
nel primo caso qualora memorizzato su una memoria non volatile (eprom, flash) , nel secondo qualora venga uploadato al device al momento di inizializzarlo (tipicamente proprio dal driver per l' OS, che quindi conterrà il BLOB del firmware come "payload") - e il motivo per cui adottare una tecnica del genere è invariabilmente per risparmiare il costo della memoria flash

Si, ricordo di aver letto in proposito alcuni articoli... ma una cosa mi sono sempre chiesto: se la flash non c'è (è stata tagliata per risparmiare) il firmware viene caricato nella ram embedded del dispositivo oppure viene caricato nella ram centrale del sistema e vi accede attraverso lo spazio di indirizzamento del driver?

Magari ho scritto una castroneria, ma chiedere non fa mai male... :Prrr:

Ciao. :)

Si, ricordo di aver letto in proposito alcuni articoli... ma una cosa mi sono sempre chiesto: se la flash non c'è (è stata tagliata per risparmiare) il firmware viene caricato nella ram embedded del dispositivo oppure viene caricato nella ram centrale del sistema e vi accede attraverso lo spazio di indirizzamento del driver?

In genere questi dispositivi sono dei computerini a se stante, con tanto di RAM e periferiche interne.

Uhm, questa mi giunge nuova...
Ho almeno 5 controller audio realtek in casa... mi dici il modello con cui hai avuto questo problema e la distribuzione, così posso starci alla larga? :)

No, un momento, non ho problemi :D funziona tutto bene con la versione degli alsa già presenti nel kernel :D (openSuse 10.1, per la cronaca). E' solo che un paio di mesi fa mi era saltato il grillo di provare i driver rilasciati dal produttore, visto che li fornisce, per poi scoprire l'ambaradan: sono una versione apparentemente personalizzata degli ALSA (oltre a presentare versioni diverse dei componenti alsa, sono forniti in tre "salse" con lo stesso numero di versione: una per fedora, una per red hat ent. e una generica per le altre distro, che ho scaricato), esistono solo come sorgenti (mi ero illuso male dopo aver trovato i driver nvidia anche in un bel rpm - avendo una gf4, non mi faccio problemi a non usare l'ultimissimo driver) e, leggendo il file install prima di avventurarmi, essendo io curioso come un animale_che_non_mi_viene, ho scoperto che prima di installarsi vanno a ricercare/cancellare/sovrascrivere cartelle con eventuali versioni precedenti degli alsa, solo che dette cartelle nel mio sistema hanno nomi leggermente diversi, quindi ho desistito per evitare di incasinare il sistema (essendoci quasi riuscito, semplicemente aggiornando il kernel con yast2 - non senza pasticciare :fiufiu: - e ritrovandomi con il kernel debug, che non avviava kde, come default in grub, ma questa è un'altra storia :D).

Comunque, la pagina della wiki non ufficiale del progetto alsa che ho linkato, suggerisce di compilare il kernel per gli alsa in generale, non per la versione realtek, almeno con le prime versioni del 2.6; però mi sembra più un suggerimento, per avere una installazione più pulita e stabile rispetto al semplice aggiornamento dei driver già presenti (non saprei perchè, magari le prime release del 2.6 integravano una versione vecchia degli alsa, che usava diverse cartelle/impostazioni/convenzioni per il kernel cambiate nelle versioni più recenti - o poteva essere così per scelta di qualche distro specifica - e, comunque, suppongo - non dimientichiamo che sono niubboooo! - che ricompilando il kernel successivamente per altri motivi, senza togliere dalla configurazione le impostazioni specifiche per gli alsa già presenti, possa/potesse annullare le modifiche apportate e/o ritrovarsi con moduli diversi per gli alsa, creando conflitti/errori al momento del caricamento (?) - è previsto anche un metodo per sostituire i sorgenti della versione alsa scelta nell'albero dei sorgenti del kernel). Un utente diceva di riuscire "tranquillamente" ad aggiornare gli alsa con il kernel 2.6.1, già configurato per supportare gli alsa e tutte le caratteristiche desiderate, anche se poi doveva mettere mano a /etc/rc.d/rc.local e sistemare il caricamento dei moduli scelti su red hat 8 :boh:

Si, ricordo di aver letto in proposito alcuni articoli... ma una cosa mi sono sempre chiesto: se la flash non c'è (è stata tagliata per risparmiare) il firmware viene caricato nella ram embedded del dispositivo oppure viene caricato nella ram centrale del sistema e vi accede attraverso lo spazio di indirizzamento del driver?

In genere un firmware è un pezzo di codice che gira interamente su un altro processore che non è quello principale.

All'origine (al momento del boot) le periferiche che richiedono un firmware non 'sanno fare' praticamente niente: accettano solo di caricare un firmware. Nel momento in cui lo carichi, esse lo eseguono e a quel punto sono in grado di accettare 'comandi' dal sistema operativo host; ma il codice non viene eseguito in alcun modo dalla CPU di sistema.

Tanto per farti un esempio, di recente è stato un 'grande successo' il nuovo driver per le schede wireless ipw3945 di Intel. Prima richiedevano un demone userspace che era closed-source (oltre al firmware closed-source), ora è sufficiente il driver open + firmware closed source per far funzionare il tutto. Credo che il codice sia già in -mm e vedrà probabilmente la luce nel kernel ufficiale .22, ma ci sono delle patch in giro per i kernel precedenti.

Detto questo, i due problemi sostanziali nel rilascio delle specifiche sono secondo me essenzialmente questi:

1) Un problema IP 'inverso'. Ci sono così tanti brevetti idioti in giro che secondo me un'azienda ha paura che, rivelando anche solo le specifiche, qualcuno possa pensare che un suo certo prodotto viola un certo brevetto. Con driver e specifiche closed, invece la cosa può passare inosservata.
2) Design subottimali. Con la corsa continua al 'facciamo di più e sempre più in fretta' probabilmente molti dei dispositivi in giro hanno delle belle lacune visibili già a livello di specifiche, e i produttori non vogliono che si faccia.
3) Se non lo fanno gli altri, perché dovrei farlo io? Non mi risulta che, a livello di mercato, ci siano grossi vantaggi economici per un produttore che rilascia specifiche o driver open - almeno sul mercato desktop, perché il fatto che un prodotto di fascia server sia incompatibile con Linux è invece una castroneria che nessuno si sogna - e quindi non lo fanno.

cellulari cn linux ci sn da tempo e per la maggior parte motorola soltanto che sn tutti in asia. In europa si è visto giusto l'A780. Però nn c'è la possibilità di installare software di terze parti se nn lo prevede il costruttore e nn si aggiorna il firmware. Ad esempio sull'A780 girava opera.
il rokr II dovrebbe arrivare anche da noi cn linux sotto. Però sn come normali cameraphone che anziché avere un sistema proprietario usano linux.
Symbian fa schifo anche a me e pensavo anche io che nokia si stesse preparando a linux visti l'N770 e l'N800. Però adesso nn mi spiego più la recente aqcuisizione di symbian uiq da parte di sonyericsson. Nn è la stessa cosa del symbianS60 ma cmq l'origine è comune. Se symbian nn ha più tanto futuro sta scelta come si spiga? Tra l'altro neanhce da dire che abbia mai avuto tanto successo. Pure motorola ha presentato un nuovo modello cn symbian uiq (però senza touch screen).

Io sono un ingegenre iscritto alla IEEE e mi sembra che tutti i testi scientifici sono scritti in latex e non i word o openoffice
Questi ultimi due li usa solamente qualche ingegnere del c@z.... come il cestista Michael Jordan in NBA

Puoi essere iscritto pure al Jet Propulsion Laboratory della NASA, ma se non hai imparato a cogliere le battute, soprattutto quando espressamente indicato, stai messo male. Che poi gli ingegneri del cazzo stanno pure all'IEEE stai tranquillo. :rolleyes:

cellulari cn linux ci sn da tempo e per la maggior parte motorola soltanto che sn tutti in asia. In europa si è visto giusto l'A780. Però nn c'è la possibilità di installare software di terze parti se nn lo prevede il costruttore e nn si aggiorna il firmware. Ad esempio sull'A780 girava opera.
il rokr II dovrebbe arrivare anche da noi cn linux sotto. Però sn come normali cameraphone che anziché avere un sistema proprietario usano linux.
Symbian fa schifo anche a me e pensavo anche io che nokia si stesse preparando a linux visti l'N770 e l'N800. Però adesso nn mi spiego più la recente aqcuisizione di symbian uiq da parte di sonyericsson. Nn è la stessa cosa del symbianS60 ma cmq l'origine è comune. Se symbian nn ha più tanto futuro sta scelta come si spiga? Tra l'altro neanhce da dire che abbia mai avuto tanto successo. Pure motorola ha presentato un nuovo modello cn symbian uiq (però senza touch screen).

"Non ha piu' tanto futuro" se parliamo di questioni "tecniche" eppure la clientela va in euforia quando sente parlare di Symbian, nemmeno fosse l'ultimo ritrovato tecnologico ceduto da popolazioni aliene in omaggio agli umani. Tanto, alla fin fine, quello che interessa è quali applicazioni ci saranno alla resa dei conti e non quale kernel starà girando sotto la gonna. Piu' che altro mi domando cosa rimarrà di Linux una volta che questi sistemi operativi mobili "Linux" saranno pronti :)
Useranno QTopia come GUI? :)

"Non ha piu' tanto futuro" se parliamo di questioni "tecniche" eppure la clientela va in euforia quando sente parlare di Symbian, nemmeno fosse l'ultimo ritrovato tecnologico ceduto da popolazioni aliene in omaggio agli umani.
La nokia sa fare dell'ottimo marketing, questo è sicuro. Non solo verso gli utenti, ma anche nei confronti degli altri produttori (Sony e Motorola), tanto che è stata capace di ottenere l'adozione di quel sistema persino nei telefoni concorrenti (beccandosi una vanlanga di soldi, visto che symbian limited è di fatto proprietà di nokia). Ma ti assicuro che è davvero un sistema difficile da installare sui device... la sua configurazione è complessissima. E che lo dicano o no, nokia stessa sta cercando di liberarsene...


Tanto, alla fin fine, quello che interessa è quali applicazioni ci saranno alla resa dei conti e non quale kernel starà girando sotto la gonna.
Quello che interessa è che le modifiche eseguite dovranno essere rilasciate, rendendo il kernel linux ancora più versatile... a vantaggio di tutti.

Quello che interessa è che le modifiche eseguite dovranno essere rilasciate, rendendo il kernel linux ancora più versatile... a vantaggio di tutti.

Non credo che in realtà sarà cosi. Anzi, sono sicuro che la base "comune" avrà ben poco del prodotto completo e funzionante. Il resto sarà tutta un'accozzaglia di estensioni al kernel chiuse che non renderanno mai pubbliche. Un po' come hanno ipotizzato succeda con la piattaforma phoneME. Alla fine la piattaforma base è aperta e accessibile a tutti. Ma continua ad essere lontano dall'essere un prodotto "finito" (come del resto è ovvio).

Però il kernel di linux è sotto gpl, al limite si può mettere un'interfaccia open nel kernel e una parte proprietaria a parte, ma quello che gira nel kernel e ne fa parte dev'essere gpl, o sbaglio?

Il linux usato sui nokia n770 e n800 è maemo derivato da debian. cercate un po' di informazioni e fatevi un'idea della valità del progetto. Motorola usa monta vista. Altri usano qtopia ma già qui usciamo un po' dal concetto gnu/linux.
Nn credo che si voglia realizzare un sistema linux per sistemi mobili universale.....succederà un po' quello che accade adesso coi pc, ogni distro avrà il proprio sistema operativo linux cn i propri bacchetti e i propri file di configurazione. In fondo a noi utilizzatori di smartphone poco importa, l'importante è che il telefono funzioni bene e che ci siano tanti programmi, cioè che siano facili da realizzare per i programmatori e senza costi assurdi per la certificazione.....quello che sta accadendo cn maemo.
C'è anche un progetto di smartphone cn linux totalmetne opensource, openmoko ma penso che avrà successo solo fra gli appassionati

doppio