Sistemi Dell con Linux preinstallato: parliamone

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! ;-)

Ma per fare dispetto a Linus sarebbe più interessante investire sulla recentissima vers. 3 di Minix, del suo ex-professore ed acerrimo contestatore Tanenbaum. Ha caratteristiche davvero interessanti ed è un VERO microkernel!!

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?

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!

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.

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!

Vedo che ignori puntualmente quanto viene scritto.

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.

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'...