***LINUX*** Perchè tutte le volte che aggiorno il Kernel mi da error 17 e devo reinstallare tutto?

Question

è la seconda volta che mi capita, come distribuzione ho una kubuntu moooolto personalizzata...il fatto è che sia io che il mio ragazzo l'abbiamo identica, solo che lui aggiorna senza problemi, a me invece mi da errore? Cosa potrebbe essere?

Sto usando windows e solo ora che sono abituata a linux mi accorgo di quanto fa schifo!

Answer 1

quella è destra, provare di conservazione

Answer 2

Microkernel: tipo di kernel progettato per svolgere operazioni molto ridotte; essenzialmente la gestione dei processi interni, una limitata gestione e scheduling dei processi oltre alla gestione di alcuni I/O di basso livello. Questa filosofia di sviluppo era stata creata in origine per produrre sistemi operativi facilmente portabili (cioè sistemi il cui porting su altre piattaforme hardware richiedesse solo una riscrittura delle parti inerenti all'interfacciamento con l'hardware). Il sistema a microkernel fondamentalmente astrae dalle problematiche inerenti al chipset, rendendo in teoria possibile, fra le altre cose, lo sviluppo di un unico kernel per più piattaforme differenti. In pratica i microkernel accusano notevoli problemi di prestazioni, sia a livello di velocità (le routine di interfaccia con il chipset — i driver di periferica, ad esempio — sono spesso causa di 'attrito' fra il kernel e l'hardware) sia di stabilità. Percontro, è molto facile far supportare nuovo hardware a questi sistemi, data la loro gestione "decentrata" dell'hardware stesso. I sistemi operativi Microsoft sono orientati (in linea generale, ovviamente) verso questo tipo di architettura.

Kernel monolitico: tipo di kernel progettato per svolgere tutte le operazioni fondamentali della macchina; queste comprendono lo scheduling degli eventi (pianificazione), la gestione dei processi, la segnalazione, la gestione dei dispositivi I/O e degli interrupt, la paginazione e lo swapping. I kernel monolitici sono profondamente legati all'hardware sul quale vengono sviluppati, in quanto esso viene gestito a livello di kernel; volendo, la filosofia 'monolitica' è la concezione più classica (e per questo qualcuno la ritiene un po' datata) di come si sviluppa un sistema operativo. Tuttavia, Linux la sta riportando in auge, dimostrando nel contempo come le difficoltà di porting di un ambiente monolitico non siano poi così insormontabili, a patto di progettare e sviluppare il codice in maniera solida e razionale. Gli svantaggi dei kernel monolitici sono comunque una maggiore difficoltà di porting rispetto ai sistemi a microkernel, e una maggiore complessità del codice sorgente (che quindi richiede competenze molto specifiche da parte di chi deve modificarlo). Inoltre, dal momento che l'hardware viene gestito direttamente dal kernel, spesso è necessario ricompilarne i sorgenti per consentirgli di supportare nuovi componenti. Per contro, i kernel monolitici sono di norma più veloci e più stabili dei microkernel.
[di Domenico Carbotta]:
Microkernel piccolo, kernel monolitico grande.
Falso mito. L'utilizzo di metodi "formali" di interazione tra moduli del sistema operativo rispetto all'utilizzo di tecniche più immediate sono causa di codice prolisso nell'implementazione del microkernel, che quindi risulta più grande di un kernel monolitico.

Microkernel lento, kernel monolitico veloce.
Mito parzialmente vero. La causa è da imputare all'architettura 80x86.
Scenario: un'applicazione di grafica vuole eseguire una scansione.

Kernel monolitico:

Applicazione ⇒ [passaggio nel kernel space] ⇒ driver scanner ⇒
driver USB ⇒ driver scanner ⇒ [passaggio nello user space] ⇒ ApplicazioneTotale di 2 context switch.
Microkernel:

Applicazione ⇒ [passaggio nel kernel space] ⇒ IPC ⇒ [passaggio nello user space] ⇒
driver scanner ⇒ [passaggio nel kernel space] ⇒ IPC ⇒ [passaggio nello user space] ⇒
driver USB ⇒ [passaggio nel kernel space] ⇒ IPC ⇒ [passaggio nello user space] ⇒
driver scanner ⇒ [passaggio nel kernel space] ⇒ IPC ⇒ [passaggio nello user space] ⇒ ApplicazioneTotale di 8 context switch. Quasi tutto avviene nello user space tranne il codice per le comunicazioni tra processi.
Su un processore della famiglia x86 tradizionalmente il context switch — passaggio da kernel mode, altrimenti detto ring 0 (cfr. VxD), a user mode, ring 3 — è l'istruzione più lunga da eseguire. Farne otto anzichè due, determina un overhead notevole. Cfr. User mode, Supervisor mode.

• Allora è vero che i microkernel sono per forza lenti.
Bugia. Altre architetture (PowerPC e credo quasi tutte le architetture RISC moderne, ma anche 680x0) non risentono così tanto in termini prestazionali di un context switch.
Esempio: 1) il sistema operativo degli Amiga era basato su un microkernel e dieci anni fa, su hardware oggi obsoleto, offriva alte prestazioni.
2) QNX è un sistema operativo microkernel real-time, più performante di così...

• Microkernel instabile, kernel monolitico stabile.
Falso. Sarebbe falso anche il contrario. Tendenzialmente vantaggi e svantaggi si bilanciano. Un'architettura microkernel matura, a rigore trae vantaggio dal fatto che un driver bacato non può affondare il kernel, visto che non risiede nel suo stesso spazio di memoria, ma al momento le architetture a kernel monolitico sono tendenzialmente più mature. BSD è vetusto.

• Microkernel facile da programmare, kernel monolitico difficile.
Un kernel monolitico può essere elegante almeno quanto un microkernel. È sufficiente organizzare il codice in maniera modulare, separando logicamente i vari blocchi di codice e documentando i meccanismi di comunicazione tra i vari moduli (potendo comunque contare sulla flessibilità offerta da un'architettura meno ottusa di quella a microkernel).

• Microkernel facile da portare, kernel monolitico difficile.
Bugia. Debian GNU/Linux supporta ufficialmente 12 architetture, NetBSD ne supporta 55. Sono due kernel monolitici, e NetBSD è un'evoluzione del kernel BSD, nato sul PDP-11, vetusto (cfr. UNIX).