Link alla notizia: http://www.hwupgrade.it/news/software/nuovo-kernel-linux-2623-con-process-scheduler-rivisto_22866.html

Il più recente kernel linux, giunto ormai alla release 2.6.23, introduce un nuovo Process Scheduler

Click sul link per visualizzare la notizia.

bello, se poi qualcuno spiega quali sono i vantaggi/svantaggi nella pratica è ancora meglio però =)

bello, se poi qualcuno spiega quali sono i vantaggi/svantaggi nella pratica è ancora meglio però =)

infatti hanno linkato per gli approfondimenti :stordita:

mi serve proprio il kernel nuovo per far vedere al mio sistema 32 bit 4gb invece di 2. Siccome sono sempre inesperto di linux (ora ho pclinuxos con cui mi trovo molto bene) per aggiornare il kernel è come aggiornare un qualsiasi altro pacchetto? lo posso fare dal gestore dei pacchetti?

non conosco la tua distribuzione linux, ma ubuntu ad esempio aggiorna il kernel come qualsiasi applicativo tramite gestore pacchetti.

mi serve proprio il kernel nuovo per far vedere al mio sistema 32 bit 4gb invece di 2. Siccome sono sempre inesperto di linux (ora ho pclinuxos con cui mi trovo molto bene) per aggiornare il kernel è come aggiornare un qualsiasi altro pacchetto? lo posso fare dal gestore dei pacchetti?

in linea di massima si pero' dubito che entrera' a far parte della lista dei pacchetti per la tua distribuzione a breve.

la cosa piu' veloce e comoda e' scaricare i sorgenti da kernel.org e compilartelo.

... e in ogni caso il supporto per grossi quantitativi di ram non e' un'esclusiva dei kernel piu' recenti, e' possibile da anni e anni e anni!

infatti hanno linkato per gli approfondimenti :stordita:

che peraltro ho letto prima di scrivere l'appunto

nel link tu trovi indicazioni concrete? al massimo un cenno


la cosa piu' veloce e comoda e' scaricare i sorgenti da kernel.org e compilartelo.

la cosa più comoda è aspettare che venga a far parte della propria distro =)

Strano Linux usa tre differenti moduli per la memoria(SEMPRE IN 32BIT)
1) per gestire max 768MB (non ne sono certo, ma sicuramente meno di 1GB)
2) per 4GB
3)per 64 GB esensione PAE

Di solito le distribuzioni hanno l'impostazione 2, dato che chi usa GNU/Linux su nuna mecchina da + di 4 GB di ram, qualcosa la capisce e sicuramente sa ricompilare il kernel (cosa che in realtà è molto facile)


All'avvio puoi pure specificare la ream da usare con mem=512M per 512 MB, non so sè è vailida anche la direttiva con GB(basta vedere la documentazione che nelle distribuzioni si ha con un pacchetto) al massimo per 4Gb usa "mem=4096M"

È molto strano quello che ti succede, ho avuto esperienza con queste cose anche col mio PC, e la differenza non è tra 2 e 4 giga, poi non ho mei usato la tua distro, protrebbero aver pacciato il kernel e modificanto in questo anche se non credo

nel link tu trovi indicazioni concrete? al massimo un cenno


In fondo alla pagina lincata sono riassunti in 5 punti. :)

Informazioni sullo Scheduler, si trovano dappertutto in rete

nella pagina linkata ci sono tanti riferimenti, anche alcuni in italiano

il nuovo scheduler vuol dire migliore prontezza del sistema in situazioni di alto carico. migliore interattività insomma.
Poi ci sono driver nuovi, novità per la virtualizzazione (guest multiprocessore con kvm ad es)

Veramente è da parecchio che sento parlare del CFS. Credevo che fosse nel kernel di Linux da tempo...

Vorrà dire che è il momento di mandare in pensione il 2.6.22 e le patch del mitico Con Kolivas che non svilupperà più perché il suo scheduler - che da tempo è superiore a quello disponibile fino alla versione 2.6.22 - non è stato incluso nella mainline.
Speriamo solo che CFS non faccia rimpiangere il RSDL.

in linea di massima si pero' dubito che entrera' a far parte della lista dei pacchetti per la tua distribuzione a breve.

la cosa piu' veloce e comoda e' scaricare i sorgenti da kernel.org e compilartelo.

... e in ogni caso il supporto per grossi quantitativi di ram non e' un'esclusiva dei kernel piu' recenti, e' possibile da anni e anni e anni!

eh lo so ma nn so fare a settare il mio perchè sono ancora inesperto, e nn cambiargli la fatidica impostazione che mi fa vedere 4gb di ram..per questo pensavo di aggiornarlo direttamente

l'ultima ubuntu scrive anche su ntfs, chissà se metteranno questo kernel..

mi serve proprio il kernel nuovo per far vedere al mio sistema 32 bit 4gb invece di 2. Siccome sono sempre inesperto di linux (ora ho pclinuxos con cui mi trovo molto bene) per aggiornare il kernel è come aggiornare un qualsiasi altro pacchetto? lo posso fare dal gestore dei pacchetti?

Ti sconsiglio di aggiornare il kernel perché PClinuxOS deriva da mandriva che usa un kernel modificato per supportare diverso hardware. Se compilassi il nuovo kernel perderesti tutte queste ottimizzazioni.

Si è aggiornato oggi il kernel alla mia Ubuntu 7.10 ma la versione installatasi non è assolutamente quella della news.

Hanno per caso diminuito anche le latenze??

Avevo notato una bella differenza tra il kernel low latency di Ubuntu Studio e quello di una Ubuntu normale. La prima mi sembrava decisamente più scattante.

Ti sconsiglio di aggiornare il kernel perché PClinuxOS deriva da mandriva che usa un kernel modificato per supportare diverso hardware. Se compilassi il nuovo kernel perderesti tutte queste ottimizzazioni.

capito grazie mille...allora ormai tengo duro e attendo di mettere kubuntu nuova e provo magari a modificare il kernel che ho.

ne approfitto per chiedere 2 cose a voi esperti di linux: mettere linux a 64 bit per fargli vedere + di 2 gb di ram è inutile quindi? nn è come xp 32 bit che è limitato a 3,2 gb circa, con linux posso tranquillamente mettere distro a 32 bit e utilizzare tutti e 4 i gb di ram...
seconda cosa gli aggiornamenti: se io metto ad esempio ubuntu 7.04 e quando esce la 7.10 voglio passare a quella nn devo formattare, in realtà basta che aggiorno il sistema ed è come avere la versione nuova, o sbaglio?

Si è aggiornato oggi il kernel alla mia Ubuntu 7.10 ma la versione installatasi non è assolutamente quella della news.

La 7.10 userà il kernel 2.6.22, se vuoi quello nuovo devi scaricarlo e ricompilarlo.

capito grazie mille...allora ormai tengo duro e attendo di mettere kubuntu nuova e provo magari a modificare il kernel che ho.

ne approfitto per chiedere 2 cose a voi esperti di linux: mettere linux a 64 bit per fargli vedere + di 2 gb di ram è inutile quindi? nn è come xp 32 bit che è limitato a 3,2 gb circa, con linux posso tranquillamente mettere distro a 32 bit e utilizzare tutti e 4 i gb di ram...
È praticamente inutile mettere la 64 bit solo per far vedere i 4 giga di ram.
seconda cosa gli aggiornamenti: se io metto ad esempio ubuntu 7.04 e quando esce la 7.10 voglio passare a quella nn devo formattare, in realtà basta che aggiorno il sistema ed è come avere la versione nuova, o sbaglio?

Se non vuoi formattare devi cambiare il source list. In pratica dove vedi scritto feisty devi sostituirlo con gutsy. Poi dai un get update e infine un dist-upgrade e ti ritrovi la versione nuova. Attento a non avere source list troppo "esotici" però, se non hai aggiunto niente di nuovo al source originale nell 99% dei casi va tutto alla perfezione.

Per tutti quelli che vogliono cimentarsi con nuovi kernel e hanno una distro debian based consiglio di scaricare kerneler un programma fatto da un italiano che con una veste grafica ti guida alla compilazione del kernel e ti genera un fantastico pacchetto .deb da installare dopo comodamente o da portare all'amichetto :D
http://www.kerneler.org

E' ancora in versione alpha, pero' l'ho provato e funziona abbastanza bene, ti installa i pacchetti necessari per compilare, compila e genera il pacchetto debian (o i pacchetti se uno vuole dividere moduli dal core) tutto in automatico.
Sul mio pc l'intero processo ci mette circa 45-50 minuti (athlon x2 4800+ 2 gb di ram hdd 7200rpm)

Per chi non sa che vantaggi da' uno scheduler migliore:
per farla molto breve (e un po' riduttiva) i vantaggi si vedono molto nel multitasking, ovvero quando uno ha molte applicazioni aperte e molte che usano memoria e cpu contemporaneamente.

Uno scheduler di buona fattura permette di avere un pc molto piu' reattivo, soprattutto in caso appunto di heavy load.

=-;19105060']In fondo alla pagina lincata sono riassunti in 5 punti. :)

no, lì sono riassunti gli aspetti tecnici

di quelle cose all'utente finale non frega un benemerito. la mia domanda rimane aperta: cosa cambia per l'utente finale?

no, lì sono riassunti gli aspetti tecnici

di quelle cose all'utente finale non frega un benemerito. la mia domanda rimane aperta: cosa cambia per l'utente finale?

ti ho risp sopra ^^^

Per tutti quelli che vogliono cimentarsi con nuovi kernel e hanno una distro debian based consiglio di scaricare kerneler un programma fatto da un italiano che con una veste grafica ti guida alla compilazione del kernel e ti genera un fantastico pacchetto .deb da installare dopo comodamente o da portare all'amichetto :D
http://www.kerneler.org

E' ancora in versione alpha, pero' l'ho provato e funziona abbastanza bene, ti installa i pacchetti necessari per compilare, compila e genera il pacchetto debian (o i pacchetti se uno vuole dividere moduli dal core) tutto in automatico.
Sul mio pc l'intero processo ci mette circa 45-50 minuti (athlon x2 4800+ 2 gb di ram hdd 7200rpm)

Per chi non sa che vantaggi da' uno scheduler migliore:
per farla molto breve (e un po' riduttiva) i vantaggi si vedono molto nel multitasking, ovvero quando uno ha molte applicazioni aperte e molte che usano memoria e cpu contemporaneamente.

Uno scheduler di buona fattura permette di avere un pc molto piu' reattivo, soprattutto in caso appunto di heavy load.

Ottimissimo!!! Non conoscevo il sito.

Se non vuoi formattare devi cambiare il source list. In pratica dove vedi scritto feisty devi sostituirlo con gutsy. Poi dai un get update e infine un dist-upgrade e ti ritrovi la versione nuova. Attento a non avere source list troppo "esotici" però, se non hai aggiunto niente di nuovo al source originale nell 99% dei casi va tutto alla perfezione.

si purtroppo io avevo installato dei pacchetti di 3v1n0 che l'hanno fatto fermare, purtroppo basta 1 solo pacchetto che mette i file in posizione diversa e ferma tutto l'aggiornamento, mi sembra un bug non da poco.

si purtroppo io avevo installato dei pacchetti di 3v1n0 che l'hanno fatto fermare, purtroppo basta 1 solo pacchetto che mette i file in posizione diversa e ferma tutto l'aggiornamento, mi sembra un bug non da poco.

Per forza che se aggiungi repositori esotici dopo il dist-upgrade non funziona, ma il 99% degli utenti che non li usa non ha problemi.

Soprattutto se il repositry in questione è mantenuto in modo amatoriale da uno che nel suo blog prima di andare in vacanza scrive "Ci si legge il 17 se tutto va bene, nel frattempo - ovviamente - i miei pacchetti non verranno aggiornati"...

Questo sarebbe 'un bug non da poco'?:rolleyes:

Per forza che se aggiungi repositori esotici dopo il dist-upgrade non funziona, ma il 99% degli utenti che non li usa non ha problemi.

Soprattutto se il repositry in questione è mantenuto in modo amatoriale da uno che nel suo blog prima di andare in vacanza scrive "Ci si legge il 17 se tutto va bene, nel frattempo - ovviamente - i miei pacchetti non verranno aggiornati"...

Questo sarebbe 'un bug non da poco'?:rolleyes:

Il bug e' assolutamente molto grave secondo me, perche' secondo te io ho installato una libreria X alla quale dipende 1 solo programma mi deve per forza fermare l'upgrade dell'intero sistema?

Al massimo dovrebbe lasciare non aggiornata tale libreria e i relativi pacchetti che dipendono da quella, ma non tutto.

Poi mi dicono che sono troppo pro-linux... la realta' e' che dico le cose come stanno :rolleyes:

ti ho risp sopra ^^^

non mi spiego

so cos'è uno scheduler, so a cosa serve e so che vantaggi comporta ottimizzare lo scheduler

la mia domanda è estremamente semplice: i vantaggi pratici, circostanziati a questo scheduler in particolare, quali sono?

lo scheduler è un elemento complesso, ci sono politiche, compromessi, regole; questo nel dettaglio che fa rispetto a quello vecchio?


ps: oh, si può anche rispondere "boh" eh, non è che bisogna saperlo per forza =)

Il bug e' assolutamente molto grave secondo me, perche' secondo te io ho installato una librearia X alla quale dipende 1 solo programma mi deve per forza fermare l'upgrade dell'intero sistema?

Al massimo dovrebbe lasciare non aggiornate tale librerie e i relativi pacchetti che dipendono da quella, ma non tutto.

Poi mi dicono che sono troppo pro-linux... la realta' che e' dico le cose come stanno :rolleyes:

Puo succedere benissimo, se questa libreria X dipende da un'altro pacchetto che sta per venire aggiornato col dist-upgrade e non è compatibile con la nuova verisone.
Questi sono appunto i problemi che saltano fuori quando si aggiungono tra la fonti software dei repository non professionali. La maggior parte degli utenti di ubuntu usa solo quelli standard quindi non ha questi problemi quando aggiorna la distro.

Poi bisognerebbe vedere nello specifico quello che ti è successo, quindi meglio lasciar perdere seno si va ot :)
(a scanso di equivoci, non sto mica cercando di difendere ubuntu e dire che non ha bug!)

i vantaggi sono in estrema sintesi:
1 più hardware supportato (ovvio)
2 miglior CFS (infatti c'era da prima, ma moolto prima..), cioè come detto da molti prima semplicemente si è migliorata la policy di gestione e allocazione dei processi, e giustamente si vede meglio nel multitasking, ove vi sono molti processi (job) in esecuzione

peccato che leggendo in giro si nota che come prestazioni siamo peggiorati (siamo nell'ordine del 5%, nulla di raccapricciante), quindi devono ancora sistemare qualcosina. ovviamente sulle distro lo vedremo l'anno prossimo, visto che semplicemente aggiornare il kernel e basta può (nella peggiore delle ipotesi) fare andare in casino il sistema (se qualche dipendenza cade col nuovo kernel, non sono sicuro se sia questo il caso ma meglio usare i kernel della propria distro, solitamente usano testarli..).
a me semplicemente ad ogni nuovo kernel devo reinstallare i driver nvidia, ma roba di poco conto. uso kubuntu quindi con altre dstro più "serie" non so che succeda
riguardo la storia della ram: problema risolvibilissimo (google come al solito aiuta), i veri problemi son ben altri (directx, gestione batterie portatili, fud e chi più ne ha più ne metta)

non mi spiego

so cos'è uno scheduler, so a cosa serve e so che vantaggi comporta ottimizzare lo scheduler

la mia domanda è estremamente semplice: i vantaggi pratici, circostanziati a questo scheduler in particolare, quali sono?

lo scheduler è un elemento complesso, ci sono politiche, compromessi, regole; questo nel dettaglio che fa rispetto a quello vecchio?

dunque se ho capito bene:
praticamente tratta tutti i processi come se potessero avere il 100% della cpu, ovviamente questo non puo' avvenire, allora setta una particolare variabile che conta quanto tempo ha perso e che dovrebbe "recuperare" perche' il processo sia funzionante per bene in quel dato momento.
Poi in base alla classifica da' + cpu ai processi dove sono piu' "indietro" rispetto alla computazione "perfetta".

Prima invece c'erano i time slice, ovvero ogni processo avev tot tempo a disposizione e poi veniva deallocato dalla cpu, processi con priorita' maggiore avevano time_slice maggiore, un approccio completamente differente.

Premetto che potrei aver detto delle imprecisioni, se e' cosi' correggetemi pure.

ps: oh, si può anche rispondere "boh" eh, non è che bisogna saperlo per forza =)

non avevo capito la domanda! :rolleyes:
In pratica vuoi i dettagli senza sbatterti a leggere i dettagli, una specie di prosa del changelog :D

La prosa in inglese l'ho trovata qui:
http://people.redhat.com/mingo/cfs-scheduler/sched-design-CFS.txt

Puo succedere benissimo, se questa libreria X dipende da un'altro pacchetto che sta per venire aggiornato col dist-upgrade e non è compatibile con la nuova verisone.
Questi sono appunto i problemi che saltano fuori quando si aggiungono tra la fonti software dei repository non professionali. La maggior parte degli utenti di ubuntu usa solo quelli standard quindi non ha questi problemi quando aggiorna la distro.

Poi bisognerebbe vedere nello specifico quello che ti è successo, quindi meglio lasciar perdere seno si va ot :)
(a scanso di equivoci, non sto mica cercando di difendere ubuntu e dire che non ha bug!)

oh ma non e' che devi ripetere le stesse cose 100 volte, ho capito, pero' mi pare strano che per una libreria che usava solo 1 programma ha interrotto l'aggiornamento di altre centinaia di librerie e pacchetti che nulla avevano a che fare con quella libreria.

Mi sembra un bug grave e mi sembra che il mio discorso sia estremamente chiaro.

Ma ricordo che si era detto che in questa nuova versione del kernel doveva portare dei miglioramenti nella durata delle batterie dell'ordine del 20% come pubblicizzato ampiamente da intel, qualcuno ne sa qualcosa in merito? ci sono dei bench in giro? ciao

peccato che leggendo in giro si nota che come prestazioni siamo peggiorati (siamo nell'ordine del 5%, nulla di raccapricciante), quindi devono ancora sistemare qualcosina.

link pls?

oh ma non e' che devi ripetere le stesse cose 100 volte, ho capito, pero' mi pare strano che per una libreria che usava solo 1 programma ha interrotto l'aggiornamento di altre centinaia di librerie e pacchetti che nulla avevano a che fare con quella libreria.

Mi sembra un bug grave e mi sembra che il mio discorso sia estremamente chiaro.
Se ti sembra strano è perche non hai capito.
Se la libreria X dipende ad esempio dalle glibc-2.5 e l'upgrade della distro aggiorna alle glibc-2.6, ma la libreria X non le supporta, cosa succede? Semplice, non ti installa le glibc2.6 e ti blocca l'aggiornamento.
E normale, è cosi che deve andare, non è un bug.
Basta solo che aspetti di fare l'upgrade finche non inseriscono nel repository esterno la libreria X che è compatibile col tree della nuova release della distro.
Secondo te invece cosa dovrebbe fare, aggiornare lo stesso il sistema, cosi dopo ti ritrovi con la libreria X e tutti i programmi che dipendono da essa che non funzionano? E a quel punto il povero utente cosa fa?:mbe:

Se ti sembra strano è perche non hai capito.
Se la libreria X dipende ad esempio dalle glibc-2.5 e l'upgrade della distro aggiorna alle glibc-2.6, ma la libreria X non le supporta, cosa succede? Semplice, non ti installa le glibc2.6 e ti blocca l'aggiornamento.
E normale, è cosi che deve andare, non è un bug.
Basta solo che aspetti di fare l'upgrade finche non inseriscono nel repository esterno la libreria X che è compatibile col tree della nuova release della distro.
Secondo te invece cosa dovrebbe fare, aggiornare lo stesso il sistema, cosi dopo ti ritrovi con la libreria X e tutti i programmi che dipendono da essa che non funzionano? E a quel punto il povero utente cosa fa?:mbe:

no io dico una cosa diversa.
Aggiornamento della libreria mlt e mlt++ (cosi' siamo specifici) dipendono tutti da librerie >= quindi supportano anche le nuove che vengono da Gutsy (per intenderci), pero' per un qualche motivo mlt ha un readme file (una cosa assolutamente marginale insomma) che invece di essere su mlt sta su mlt++ (e' un esempio).
Arriva mlt di Gutsy, aggiorna e non puo' perche' ha i file scambiati dovrebbe sovrascrivere un file di un altro pacchetto (in questo caso va' in errore giustamente).
Fin qua tutto ok, pero' perche' fermare l'aggiornamento di tutto il resto? Voglio dire il resto che non dipende da mlt e mlt++ non c'entra nulla no?

E anche tutte le librerie che sono necessarie per queste due possono essere aggiornate tanto le dipendenze vanno per >= quindi finche' si aumenta nessun problema.

No invece tutto si ferma (per un readme file magari) e non aggiorna piu' nulla.
Boh io lo vedo come un bug o se vuoi una missing feature...

link pls?

http://www.phoronix.com/scan.php?page=article&item=872&num=1

e prima mi son sbagliato, era l'ordine dello 0.5% più o meno.
ed anche nella considerazione: va come prima, in alcuni ambiti va pochissimo peggio, in altri nu pò meglio.

http://www.phoronix.com/scan.php?page=article&item=872&num=1

e prima mi son sbagliato, era l'ordine dello 0.5% più o meno.
ed anche nella considerazione: va come prima, in alcuni ambiti va pochissimo peggio, in altri nu pò meglio.

beh 0,5 e' un bel po' diverso e cmq secondo me i veri vantaggi li vedi appunto nel multitasking e non nel single tasking.
Per esempio con questo scheduler non dovresti piu' sentire la musica che salta se per caso c'e' un altro processo che piglia troppa cpu, questo fattore e' importante, ma difficilmente un qualsiasi bench te lo fa vedere.

In altre parole:
la reattivita' di un sistema molte volte la si "percepisce" anche se il bench ti dice che c'e' solo il 0,00001% di differenza ;)

no io dico una cosa diversa.
Aggiornamento della libreria mlt e mlt++ (cosi' siamo specifici) dipendono tutti da librerie >= quindi supportano anche le nuove che vengono da Gutsy (per intenderci), pero' per un qualche motivo mlt ha un readme file (una cosa assolutamente marginale insomma) che invece di essere su mlt sta su mlt++ (e' un esempio).
Arriva mlt di Gutsy, aggiorna e non puo' perche' ha i file scambiati dovrebbe sovrascrivere un file di un altro pacchetto (in questo caso va' in errore giustamente).
Fin qua tutto ok, pero' perche' fermare l'aggiornamento di tutto il resto? Voglio dire il resto che non dipende da mlt e mlt++ non c'entra nulla no?

E anche tutte le librerie che sono necessarie per queste due possono essere aggiornate tanto le dipendenze vanno per >= quindi finche' si aumenta nessun problema.

No invece tutto si ferma (per un readme file magari) e non aggiorna piu' nulla.
Boh io lo vedo come un bug o se vuoi una missing feature...

Ok, da come avevi detto nel post 29 avevo capito secondo te un packet manager deve aggiornare i pacchetti a prescindere senza verificare la consistenza del nuovo sistema.:stordita:

pero imho in questo caso fa bene lo stesso a fermare l'aggiornamento, altrimenti ti troveresti una distro che è mezza Feisty e mezza Gutsy... il dist-upgrade abilita una logica decisionale diversa da un normale apt-get update, probabilmente considera i pacchetti della nuova distro come un blocco unico da aggiornare, e se non puo aggiornarne uno rimani fermo a quella vecchia.
Per te è una missing feature, per me è un 'comportamento sicuro'...

Ok, da come avevi detto nel post 29 avevo capito secondo te un packet manager deve aggiornare i pacchetti a prescindere senza verificare la consistenza del nuovo sistema.:stordita:

pero imho in questo caso fa bene lo stesso a fermare l'aggiornamento, altrimenti ti troveresti una distro che è mezza Feisty e mezza Gutsy... il dist-upgrade abilita una logica decisionale diversa da un normale apt-get update, probabilmente considera i pacchetti della nuova distro come un blocco unico da aggiornare, e se non puo aggiornarne uno rimani fermo a quella vecchia.
Per te è una missing feature, per me è un 'comportamento sicuro'...

per me no (ovviamente sono opinioni), cioe' non so se hai guardato un po' da vicino lo sviluppo di Gutsy (io lo faccio dalla Dapper) e ci sono valanghe di bug perche' questa piccola cosa succede molto piu' spesso di quello che uno possa pensare e spessissimo durante gli aggiornamenti "daily" si ferma tutto per un non nulla.
Ok finche' questo succede nella versione development tutto ok, pero' siccome il bug e' molto ricorrente (ti ho fatto l'esempio del readme file perche' veramente spesso succede per delle cavolate del genere) e' accaduto che un pacchetto finisca nella versione final con questo tipo di bug e ferma l'aggiornamento di centinaia di persone per una cavolata.

Altro esempio e' se python va' in segmentation fault durante l'interpretazione dello script (anche questo mi e' successo) e ferma tutto anche se la libreria non e' tra le piu' importanti.

Secondo me non e' accettabile che nel 2007 una distro linux si fermi in update per un readme file di una libreria insulsa, non so forse tu la pensi diversamente.

In qualche modo penso si possa dire manualmente di non aggiornare quella libreria ed andare avanti. Con portage (gentoo) si può e suppongo si possa fare anche con apt-get

per me no (ovviamente sono opinioni), cioe' non so se hai guardato un po' da vicino lo sviluppo di Gutsy (io lo faccio dalla Dapper) e ci sono valanghe di bug perche' questa piccola cosa succede molto piu' spesso di quello che uno possa pensare e spessissimo durante gli aggiornamenti "daily" si ferma tutto per un non nulla.
Ok finche' questo succede nella versione development tutto ok, pero' siccome il bug e' molto ricorrente (ti ho fatto l'esempio del readme file perche' veramente spesso succede per delle cavolate del genere) e' accaduto che un pacchetto finisce nella versione final con questo bug e ferma l'aggiornamento di centinaia di persone per una cavolata.

Altro esempio e' se python va' in segmentation fault durante l'interpretazione dello script (anche questo mi e' successo) e ferma tutto anche se la libreria non e' tra le piu' importanti.

Secondo me non e' accettabile che nel 2007 una distro linux si fermi per un readme file, non so forse tu la pensi diversamente.

Beh, apt non puo sapere se si tratta di un inutile readme o di una importante libreria, lui quando trova un conflitto si ferma e basta.
E una cosa grave, lo so, ma il problema sono quelli che lasciano errori nei pacchetti, apt invece fa la cosa giusta.
L'ultima cosa che vorrei è un packet manager che quando trova un conflitto si mette a risolverlo da solo e mi sovrascrive file di testa sua, preferisco che si fermi piuttosto...

Beh, apt non puo sapere se si tratta di un inutile readme o di una importante libreria, lui quando trova un conflitto si ferma e basta.
E una cosa grave, lo so, ma il problema sono quelli che lasciano errori nei pacchetti, apt invece fa la cosa giusta.
L'ultima cosa che vorrei è un packet manager che quando trova un conflitto si mette a risolverlo da solo e mi sovrascrive file di testa sua, preferisco che si fermi piuttosto...

non ho detto che debba sovrascrivere, solo lasciare non installata quella libreria e tutti quei pacchetti che dipendono da lei.
La scusa che una distro dopo sia mezza Feisty e mezza Gutsy non regge, perche' quando si interrompe l'aggiornamento viene lasciata in uno stato ancor peggiore, talvolta se riavvii prima di sistemare potrebbe anche non partirti piu' il server grafico (anche questo gia' successo).

In qualche modo penso si possa dire manualmente di non aggiornare quella libreria ed andare avanti. Con portage (gentoo) si può e suppongo si possa fare anche con apt-get

esatto! Quello che voglio dire io.
Vabbe' scusate l'OT...

l'ultima ubuntu scrive anche su ntfs, chissà se metteranno questo kernel..

Non possono metterlo nel kernel.. Causa brevetti :fagiano:

quando si interrompe l'aggiornamento viene lasciata in uno stato ancor peggiore, talvolta se riavvii prima di sistemare potrebbe anche non partirti piu' il server grafico (anche questo gia' successo).

Su questo sono d'accordo, il fatto che inizi l'aggiornamento senza prima aver verificato se ci saranno dei conflitti è un grosso difetto di apt.
Su Fedora, Yum prima di iniziare l'upgrade esegue delle transazioni su un database e solo se hanno successo le applica altrimenti non inizia proprio, cosi se ci sono degli errori il sistema resta integro.
Quando dicevo che deve fermarsi se trova dei conflitti, intendevo che deve fermarsi prima di iniziare l'upgrade, non dopo che ha gia fatto il pasticcio!
In quel caso è meglio che salti quel pacchetto e vada avanti fino alla fine come dici te, ma comunque non è una soluzione, potrebbe non funzionare lo stesso. Alcuni pacchetti sono legati tra loro in qualche modo anche se non hanno vincoli di dipendenza.

Vabbe' scusate l'OT...
ok, fine :fagiano:

Cimmo nn puoi forzare l'installazione di quel pacchetto che ti da problemi e poi riprovare?

Il changelog migliore per sintesi/tecnica, senza vedere quello ufficiale molto dispersivo secondo me e' kernelnewbies:

http://kernelnewbies.org/LinuxChanges

X CIMMO

il sistema di pacchetti deb, e il loro ciclo di sviluppo, è il migliore del mondo.
debian in questo è insuperabile

non può essere un bug, il fatto che tu cambi la lista dei mirror e installi cose al di fuori della distro

Penso che tu non abbia capito ancora bene le differenze tra le distribuzioni linux e il modo in cui si gestisce linux

Io uso debian da 3 anni e prima per un anno ho usato mandrake(all'epoca)
avevo un scaao di problemi, ma non era gnu/linux ero io che ero smplicemente niubbo

ora non sono un esperto, ma ho imparato a fare le cose che mi servono, e non sono mai stato così soddisfatto del mo sistema dai tempi del dos e dei 286

quando si passa da win a gun/linux non si deve imputare il sistema perkè è diverso da win, e non si è imparato ad usarlo

X LEPTONE

Avrei molto da ridire! più di una volta aggiornando debian (senza aggiungere altri repository) mi sn trovato il sistema incasinato! Bene o male sta cosa mi è capitata un po' cn tutte le distro: ubuntu, pclinuxos, frugalware, arch. Però debian è quella che mi ha dato più problemi di tutte durante i dist-upgrade.
Secondo me il sistema migliore ce l'ha gentoo però dover ricompilare sempre tutto è una follia!!!!

il sistema di pacchetti deb, e il loro ciclo di sviluppo, è il migliore del mondo.
debian in questo è insuperabile

non può essere un bug, il fatto che tu cambi la lista dei mirror e installi cose al di fuori della distro

Su quel punto aveva ragione cimmo (dopo che ho capito cosa intendeva dire).
Se ci sono dei conflitti un buon gestore dei pacchetti si ferma prima di iniziare, uno meno buono inizia e va fino alla fine saltando quelli che hanno problemi, uno pessimo inizia e appena trova un errore ti lascia fermo a meta col sistema desfato.

Con debian ti va bene solo finche i manteiner fanno un lavoro perfetto e mantengono con cura l'albero delle dipendenze, appena fanno un errore apt ti rasa il sistema.

X CIMMO

il sistema di pacchetti deb, e il loro ciclo di sviluppo, è il migliore del mondo.
debian in questo è insuperabile

non può essere un bug, il fatto che tu cambi la lista dei mirror e installi cose al di fuori della distro

Penso che tu non abbia capito ancora bene le differenze tra le distribuzioni linux e il modo in cui si gestisce linux

Io uso debian da 3 anni e prima per un anno ho usato mandrake(all'epoca)
avevo un scaao di problemi, ma non era gnu/linux ero io che ero smplicemente niubbo

ora non sono un esperto, ma ho imparato a fare le cose che mi servono, e non sono mai stato così soddisfatto del mo sistema dai tempi del dos e dei 286

quando si passa da win a gun/linux non si deve imputare il sistema perkè è diverso da win, e non si è imparato ad usarlo

ragazzi ma perche' mi dovete rompere partendo con "penso tu non abbia capito come linux..." cioe' ma ti rendi conto?
Io la primo distro installata e' stata Mandrake (e non Mandriva) 7.qualcosa, con kde 3.2 o forse 3.1.
Ho pure scritto la guida di Linux Kubuntu Dapper QUI su hwupgrade e non ti sto parlando del forum, ma del sito!
Ho provato almeno 6-7 distro e ho seguito da vicino Ubuntu dalla versione Dapper, anzi installai anche la Breezy nel 2005, parlo spesso con i developer di Ubuntu, sono in contatto con developer Gentoo e sono beta tester ufficiale di skype per linux e mi vieni a parlare di Linux e del fatto che apt e' il migliore al mondo e che non so usarlo?
MA LOL!

Ma rispondi ai fatti con i fatti e non con le chiacchiere.
Secondo te e' normale che un processo di update si arresti per un problema di un singolo pacchetto e ti lasci il sistema mezzo aggiornato e mezzo no con dipendenze non risolte che se non le risolvi prima del reboot non parte piu' niente? E questo tu lo chiami il migliore al mondo?

Avanti ragazzi cioe' poi mi viene da ridere quando mi danno del fanboy linux, qui tra poco mi date del fanboy al contrario.

EDIT:
e comunque ti e' sfuggito il fatto che succede anche SENZA mettere repositary esterni, basta un piccolo bug nel + insulso e inutile pacchetto ubuntu che ferma tutti gli altri, quindi sei proprio fuori strada, next time leggere e capire prima di giudicare ;)

Cimmo nn puoi forzare l'installazione di quel pacchetto che ti da problemi e poi riprovare?

no, l'installazione si interrompe, almeno con adept e' cosi', magari da linea di comando ti chiede qualcosa non lo so, il problema e' che io so sistemare, ma il niubbo che sta provando linux per la prima volta e che ovviamente e giustamente usa i tool grafici?
Gran tristezza vedere molta gente lamentarsi che non sa piu' cosa fare una volta che l'aggiornamento si e' interrotto.

Il changelog migliore per sintesi/tecnica, senza vedere quello ufficiale molto dispersivo secondo me e' kernelnewbies:

http://kernelnewbies.org/LinuxChanges

bello, ordinato semplice e concreto, subito nei miei preferiti!

grazie

Su quel punto aveva ragione cimmo (dopo che ho capito cosa intendeva dire).
Se ci sono dei conflitti un buon gestore dei pacchetti si ferma prima di iniziare, uno meno buono inizia e va fino alla fine saltando quelli che hanno problemi, uno pessimo inizia e appena trova un errore ti lascia fermo a meta col sistema desfato.

Con debian ti va bene solo finche i manteiner fanno un lavoro perfetto e mantengono con cura l'albero delle dipendenze, appena fanno un errore apt ti rasa il sistema.

hai esattamente centrato il punto... vabbe' avevo detto stop, pero'...

Il sistema di pacchetti e dipendenze nn mi fa impazzire e l'ho scritto spesso sul forum! Però la verifica delle dipendenze viene fatta prima e se qualcosa che nn va nn inizia ad aggiornare mezzo sistema e poi si ferma. Solitamente a me nn parte proprio l'update per via di questo problema, cioè fa il controllo e mi dice che c'è quel problema senza scaricare e installare nulla Se fosse sempre così andrebbe benissimo, peccato che spesso installa tutto ma al riavvio mi accorgo che qualcosa è andato storto e il sistema nn parte o ha problemi. Ripeto, debian e ubuntu sn quelle che mi hanno dato più problemi durante il dist-upgrade.

Si sa che lo scheduler (e dispatcher) è la parte critica di un sistema operativo.
Spero in maggiori prestazioni:D

Ma questo nuovo scheduler è migliore di quello che veniva implementato con le patch ck?
Fino ad oggi ho sempre atteso la prima patch ck per ricompilare e installare i kernel appena usciti, adesso non so quanto mi convenga fare l'upgrade dal 2.6.22...

no, lì sono riassunti gli aspetti tecnici

di quelle cose all'utente finale non frega un benemerito. la mia domanda rimane aperta: cosa cambia per l'utente finale?

Io non ho provato questo nuovo process scheduler, però un paio di anni fa quando usavo Gentoo utilizzavo il kernel con la patch di Con Kolivas (nominato nell'articolo) senza neanche sapere che si trattava dello scheduler dei processi, e la differenza si sentiva parecchio, il sistema era molto più veloce nella risposta ai comandi, nel passare da un'applicazione all'altra, persino nell'aprire i menu. Insomma meno latenze.

Si sa che lo scheduler (e dispatcher) è la parte critica di un sistema operativo.
Spero in maggiori prestazioni:Dil punto è che, anche se si sta lavorando per renderli sempre più ristretti, si parla di particolari casi inficiati da regressioni proprio dal punto di vista prestazionale e delle latenze (in pratica codice userspace in cui ci si faccia massicio uso di sched_yield() - il che è comprensibile, visto che la semantica di sched_yield(), in pratica "sospendere il thread, che su linux è un processo, e spostarlo in fondo alla coda dei processi con quella priorità" viene stravolta dalla struttura ad albero binario su cui si basa CFS)

scusate ma apt-get -s upgrade non simula l'aggiornamento alla nuova versione per capire se ci sono problemi?

non l'ho mai utilizzata, ma ricordavo esistesse tale funzione,
magari sarebbe da integrare graficamente! :)

io installato ho questo kernel:
i686 32bit linux kernel (4GB)
The kernel package contains the Linux 2.6.18.8.tex5 kernel, the core of your
PCLinux operating system. It is optimised for the i686 cpu arch and supports up to
and including 4GB of system memory (via highmem). It defaults to using the 'CFQ'
scheduler, 'smp' support enabled and is compiled with kernel preemption disabled

che quindi dovrebbe vedere i 4gb di ram...perchè invece nn me li vede? (cioè nella sezione hardware me li vede, ma se controllo da shell mi dice 2 gb...)

nn c'è un comando che mi edita il kernel e mi fa regolare le impostazioni?

scusate sedico idiozie ma io nella mia ignoranza me lo immagino come un bios in cui regolo i paramentri fondamentali e poi salvo e esco

nn c'è un comando che mi edita il kernel e mi fa regolare le impostazioni?

scusate sedico idiozie ma io nella mia ignoranza me lo immagino come un bios in cui regolo i paramentri fondamentali e poi salvo e esco

Per cambiare le impostazioni di un kernel bisogna ricompilarlo (o compilarlo la prima volta con le caratteristiche che uno vuole :p)

Ciao!

io installato ho questo kernel:
i686 32bit linux kernel (4GB)
The kernel package contains the Linux 2.6.18.8.tex5 kernel, the core of your
PCLinux operating system. It is optimised for the i686 cpu arch and supports up to
and including 4GB of system memory (via highmem). It defaults to using the 'CFQ'
scheduler, 'smp' support enabled and is compiled with kernel preemption disabled

che quindi dovrebbe vedere i 4gb di ram...perchè invece nn me li vede? (cioè nella sezione hardware me li vede, ma se controllo da shell mi dice 2 gb...)

Avevi già aperto un thread apposta nella sezione linux, dove ti era stato suggerito di installare un kernel PAE o di avviare il kernel attuale con l'opzione mem=4G, hai provato a vedere se funziona?

ecco mi ero scordato che mi aveva già suggerito quello, scusa ma in sti giorni c'ho 2000 cose per la testa, ora provo e ti faccio risapere nel thread che ho aperto

Strano Linux usa tre differenti moduli per la memoria(SEMPRE IN 32BIT)
1) per gestire max 768MB (non ne sono certo, ma sicuramente meno di 1GB)
2) per 4GB
3)per 64 GB esensione PAE

Di solito le distribuzioni hanno l'impostazione 2, dato che chi usa GNU/Linux su nuna mecchina da + di 4 GB di ram, qualcosa la capisce e sicuramente sa ricompilare il kernel (cosa che in realtà è molto facile)


All'avvio puoi pure specificare la ream da usare con mem=512M per 512 MB, non so sè è vailida anche la direttiva con GB(basta vedere la documentazione che nelle distribuzioni si ha con un pacchetto) al massimo per 4Gb usa "mem=4096M"

È molto strano quello che ti succede, ho avuto esperienza con queste cose anche col mio PC, e la differenza non è tra 2 e 4 giga, poi non ho mei usato la tua distro, protrebbero aver pacciato il kernel e modificanto in questo anche se non credo

E' cos' facile ricompilare il kernel che lo feci 4 anni fa da niubbo totale su una red hat 7.3 per ricompilaro ad SMP per supportare il P4 HT che ho e fargli vedere tutti e due i processori virtuali... Già allora c'erano le famose tre opzioni per la memoria... Ma anche i vari SO microsoft hanno la possibilità tramite le PAE di usare fino a 64 GB per SO a 32 bit... Ma è prerogativa solo delle versioni server... Per alcune la memoria è limitata a 4GB, per altre (le più costose) a 64 GB...