mboost-dp1
unknown
gentoo med 2.6.0-test9 kører også fint her på min work pc med ati-drivers, har dog lidt probs med nvidia-kernel der virker lidt mystisk(meget langsomt i forhold til 2.4 med nvidia-kernel) min bærbare med et g4go kort.
Jeg kører da med nvidia-kernel fra nvidia's site. Det kører glimrende både på test9 men også på test10 som jeg installerede i går, på min workstation derhjemme... Jeg synes at der af forbedringer i 2.6 kan nævnes en meget mere overskuelig build proces (så newbies også har en chance for at optimere deres kerne), og så en noget mere komplet IPv6 understøttelse i forhold til 2.4
Kører iøvrigt med gentoo-dev-sources :-)
Kører iøvrigt med gentoo-dev-sources :-)
Inden jeg hoopede på freebsd-vognen, havde jeg netop opdateret -> test9 - det kører sindsygt lækkert i forhold til 2.4!
"af forbedringer i 2.6 kan nævnes en meget mere overskuelig build proces"
Well, det er den samme konfigurations menu, eneste forskel er de efterfølgende build kommandoer. Syns ikke det er blevet specielt meget lettere ..
"af forbedringer i 2.6 kan nævnes en meget mere overskuelig build proces"
Well, det er den samme konfigurations menu, eneste forskel er de efterfølgende build kommandoer. Syns ikke det er blevet specielt meget lettere ..
Min server (og nej ikke en server i kælderen el. lign, den her sider i en serverpark) kører linux 2.2 og kører uden problemer. Eneste grund til at jeg sku overveje at skifte skulle være hvis jeg ville køre noget iptables på den, men blir den nogensinde pillet ned ryger det nok en freebsd på den.
2.2 etc. er skam fin til server - men, til en workstation er det dejligt med forbedret perfomance :)
cybermike, hvor på irc ka man finde dig ? ( oddnumber her .. just in case:) )
cybermike, hvor på irc ka man finde dig ? ( oddnumber her .. just in case:) )
"...2.6 kernen kan således håndtere systemer med op til 64 CPU'er."
64 CPU'er! Ja, det er sandelig en anvendelig ny feature som vi alle faar brug for....!!!
tsk tsk tsk
64 CPU'er! Ja, det er sandelig en anvendelig ny feature som vi alle faar brug for....!!!
tsk tsk tsk
Hehe - well - du ved jo aldrig! Da min udviklede IPv4 mente man sikkert osse at der var mere end rigeligt IPer .. se nu .. :D
Af nye feature kan nævnes:
0] Der er ryddet op i menuen når der konfigureres.
1] ALSA er nu en med i kernen.
2] I2C Hardware sensors er med i kernen.
3] Support for flere chipsæts og cpu'er. (Blandt andet x86-64)
4] Boottiden er væsentligt hurtigere, selv med SCSI drivere der skal startes.
0] Der er ryddet op i menuen når der konfigureres.
1] ALSA er nu en med i kernen.
2] I2C Hardware sensors er med i kernen.
3] Support for flere chipsæts og cpu'er. (Blandt andet x86-64)
4] Boottiden er væsentligt hurtigere, selv med SCSI drivere der skal startes.
Er det ikke noget med at modul systemet er skrevet om. Dette gør kernen meget mere skalerbar, mht store systemer (som det blev nævnt med 64 CPU'er) helt ned til små indlejrede systemer.
Derudover har jeg læst at der i 2.6 kernen skulle være en revideret resource management. Et eksempel: Du starter MANGE programmer, samtidig med at du vil kompilere en kerne og lave hd benchmarks, ved siden af starter du et 3d modellerings program. Selv om det måske tager en krig at få det hele kørt skulle man ikke opleve at musemarkøren lag'er eller højrekliks-menuer som ikke vil komme frem før lang tid efter man har klikket.
En ting som desktop brugere vil få meget glæde af.
Derudover har jeg læst at der i 2.6 kernen skulle være en revideret resource management. Et eksempel: Du starter MANGE programmer, samtidig med at du vil kompilere en kerne og lave hd benchmarks, ved siden af starter du et 3d modellerings program. Selv om det måske tager en krig at få det hele kørt skulle man ikke opleve at musemarkøren lag'er eller højrekliks-menuer som ikke vil komme frem før lang tid efter man har klikket.
En ting som desktop brugere vil få meget glæde af.
#16: "Et eksempel: Du starter MANGE programmer, samtidig med at du vil kompilere en kerne og lave hd benchmarks, ved siden af starter du et 3d modellerings program."
- Ja, og det goer jeg so saadan cirka 20 gange om dagen....NOT!
- min pointe i #9 er blot at 2.6 kernen bliver pustet op til l det helt store uden at vaere det (efter min mening)....
- Ja, og det goer jeg so saadan cirka 20 gange om dagen....NOT!
- min pointe i #9 er blot at 2.6 kernen bliver pustet op til l det helt store uden at vaere det (efter min mening)....
#18
Kernel 2.6 er en KÆMPE forbedring over 2.4...
A: Den har vist sig at være mere stabil end 2.4 er allerede.
B: Den skalerer enormt godt, og nu kræver det jo at man koder MEGET PRÆCIST for at understøtte 64 cpu'er. Dvs. at koden af sig selv bliver bedre og deraf mindre fejlfri.
2.6 er en kæmpe nyhed, og man kan mærke det.
Kernel 2.6 er en KÆMPE forbedring over 2.4...
A: Den har vist sig at være mere stabil end 2.4 er allerede.
B: Den skalerer enormt godt, og nu kræver det jo at man koder MEGET PRÆCIST for at understøtte 64 cpu'er. Dvs. at koden af sig selv bliver bedre og deraf mindre fejlfri.
2.6 er en kæmpe nyhed, og man kan mærke det.
#21 -
26. nov. 2003 17:46
Nr.16: Måske hentyder du til muligheden for en 'preemptive' kerne. Idet et operativsystem med mere end 1 processor skal sørge for at processor A ikke opererer på processor B's data, har man 'spin locks' som er en slags flag der kan indikere om en operation på et bestemt stykke data er tilladt. En eller anden fandt så ud af at kerne 2.4 med sølle 1000 linjers kode kunne udnytte disse 'spinlocks' til at låse dataområder, ikke for en anden processor, men for CPU'en selv.
Dermed kan CPU'en afbrydes i opgaver hvor den før krævede at færdiggøre operationerne før den igen 'havde fri'. Jeg har selv oplevet at f.eks. udpakning af filer (tar) eller kopiering har sløvet maskinen meget. Endvidere er der lavet tester hvor man har målt forsinkelser på mp3-afspilning, altså kigget efter 'klumper' i lyden.
Jeg arbejder selv på en maskine med 2 CPU'er, og jeg må sige 2x1GHz slår 1x2GHz, specielt hvad 'hosteri' angår. Jeg har dog engang selv prøvet 2.4 kerne-lappen, men fandt ikke den store forbedring.
Det bliver dog spændende at se om 2.6 kan udnytte min 2x maskine bedre end 2.4.18.
Men altså nr 18:
Man skulle gerne slippe for hakkeri ved filkopiering mv.
Dermed kan CPU'en afbrydes i opgaver hvor den før krævede at færdiggøre operationerne før den igen 'havde fri'. Jeg har selv oplevet at f.eks. udpakning af filer (tar) eller kopiering har sløvet maskinen meget. Endvidere er der lavet tester hvor man har målt forsinkelser på mp3-afspilning, altså kigget efter 'klumper' i lyden.
Jeg arbejder selv på en maskine med 2 CPU'er, og jeg må sige 2x1GHz slår 1x2GHz, specielt hvad 'hosteri' angår. Jeg har dog engang selv prøvet 2.4 kerne-lappen, men fandt ikke den store forbedring.
Det bliver dog spændende at se om 2.6 kan udnytte min 2x maskine bedre end 2.4.18.
Men altså nr 18:
Man skulle gerne slippe for hakkeri ved filkopiering mv.
#16
[Er det ikke noget med at modul systemet er skrevet om. Dette gør kernen meget mere skalerbar, mht store systemer (som det blev nævnt med 64 CPU'er) helt ned til små indlejrede systemer.]
Jo det er det.
Når jeg installere en 2.6 kernel, så kræver det også en pakke med opdateret module utilities.. ;)
[Derudover har jeg læst at der i 2.6 kernen skulle være en revideret resource management. Et eksempel: Du starter MANGE programmer, samtidig med at du vil kompilere en kerne og lave hd benchmarks, ved siden af starter du et 3d modellerings program. Selv om det måske tager en krig at få det hele kørt skulle man ikke opleve at musemarkøren lag'er eller højrekliks-menuer som ikke vil komme frem før lang tid efter man har klikket.]
Ikke hvis man opsætter den rigtig ihvertfald.
[Er det ikke noget med at modul systemet er skrevet om. Dette gør kernen meget mere skalerbar, mht store systemer (som det blev nævnt med 64 CPU'er) helt ned til små indlejrede systemer.]
Jo det er det.
Når jeg installere en 2.6 kernel, så kræver det også en pakke med opdateret module utilities.. ;)
[Derudover har jeg læst at der i 2.6 kernen skulle være en revideret resource management. Et eksempel: Du starter MANGE programmer, samtidig med at du vil kompilere en kerne og lave hd benchmarks, ved siden af starter du et 3d modellerings program. Selv om det måske tager en krig at få det hele kørt skulle man ikke opleve at musemarkøren lag'er eller højrekliks-menuer som ikke vil komme frem før lang tid efter man har klikket.]
Ikke hvis man opsætter den rigtig ihvertfald.
#17
Jeg ved ikke om kt400 er bedre supported. Jeg fik mit ATI kort til at virke i 2.4.22-ac på kt400 chipsæt, så noget virker i den gamle ...
Men 2.6.0-test6,7 og 8 har også virket med ATI driverne hos mig, så den er ihvertfald ikke mindre supported.
Jeg kan ikke helt huske om jeg brugte kernens AGP modul i 2.4.22-ac, men i 2.6.0 er det ihvertfald ATI's AGP.
Det skal også siges at jeg ikke kunne få ATI til på 2.4.21 og 22 med KT400.
Jeg ved ikke om kt400 er bedre supported. Jeg fik mit ATI kort til at virke i 2.4.22-ac på kt400 chipsæt, så noget virker i den gamle ...
Men 2.6.0-test6,7 og 8 har også virket med ATI driverne hos mig, så den er ihvertfald ikke mindre supported.
Jeg kan ikke helt huske om jeg brugte kernens AGP modul i 2.4.22-ac, men i 2.6.0 er det ihvertfald ATI's AGP.
Det skal også siges at jeg ikke kunne få ATI til på 2.4.21 og 22 med KT400.
I har da slet ikke forstået det.
Den største nyhed i 2.6 er den nye scheduler. Scheduleren er den funktion i kernen der så at sige "uddeler" systemet ressourcer til de forskellige processer (programmer), og den er MEGET forbedret i 2.6. Schedulerne i 2.4 og Windows (også XP) er hamrende elendige til sammenligning.
Dette gør for det første at det er svært for en proces at overtage alle systemets ressourcer (og derved låse hele pisset), for det andet at desktoppen (XFree86) føles meget mere "snappy" - det kan tydeligt mærkes.
Med den nye scheduler kommer også meget bedre understøttelse for multiprocessorsystemer, hvilket også gælder Pentium 4'ere med HyperThreading. Kernen kan fordele processer på processorerne så det giver mest mening, hvilket selvfølgelig forbedre performancen.
#21 henningp: En kerne-lap? :-D Mener du en kernel patch?
- Simon
Den største nyhed i 2.6 er den nye scheduler. Scheduleren er den funktion i kernen der så at sige "uddeler" systemet ressourcer til de forskellige processer (programmer), og den er MEGET forbedret i 2.6. Schedulerne i 2.4 og Windows (også XP) er hamrende elendige til sammenligning.
Dette gør for det første at det er svært for en proces at overtage alle systemets ressourcer (og derved låse hele pisset), for det andet at desktoppen (XFree86) føles meget mere "snappy" - det kan tydeligt mærkes.
Med den nye scheduler kommer også meget bedre understøttelse for multiprocessorsystemer, hvilket også gælder Pentium 4'ere med HyperThreading. Kernen kan fordele processer på processorerne så det giver mest mening, hvilket selvfølgelig forbedre performancen.
#21 henningp: En kerne-lap? :-D Mener du en kernel patch?
- Simon
#24
Scheduler hvad? Process? IO? Begge er nye, første er dog i de fleste 2.4 kerner i brug derude (alle vendor kerner, feks). Hvis du har feks 10000 processer på din boks er den et must, ellers er det ikke vanvittigt interessant. Der er i hvert fald mange 2.6 features jeg hellere vil fremhæve end CPU scheduleren :). 2.6 har ikke ordentlig hyperthreading support som du påstår, mange 2.4 vendor kerner har dog.
Generelt er de fleste kommentarer i denne nyhed marketing hype som ikke har det helt store hold i virkeligheden. Og som den slags typisk er, er de oftest proklameret af folk som fægter lidt med hænderne uden af have det helt store styr på hvad der sker og hvor.
Scheduler hvad? Process? IO? Begge er nye, første er dog i de fleste 2.4 kerner i brug derude (alle vendor kerner, feks). Hvis du har feks 10000 processer på din boks er den et must, ellers er det ikke vanvittigt interessant. Der er i hvert fald mange 2.6 features jeg hellere vil fremhæve end CPU scheduleren :). 2.6 har ikke ordentlig hyperthreading support som du påstår, mange 2.4 vendor kerner har dog.
Generelt er de fleste kommentarer i denne nyhed marketing hype som ikke har det helt store hold i virkeligheden. Og som den slags typisk er, er de oftest proklameret af folk som fægter lidt med hænderne uden af have det helt store styr på hvad der sker og hvor.
axboe:
Sorry jeg er lidt direkte nu.
Det lyder som om du gerne vil havde os til at tro du ved hvad du snakker om med hensyn til hvad kerne 2.6 kan og ikke mindst ikke er noget nyt.
Har du noget seriøst ikke markerings hype til at understøtte dette ?
Ikke fordi jeg ikke tror på hvad du siger, jeg kunne bare godt tænke mig at læse en ordentlig gennemgang af det du siger.
Sorry jeg er lidt direkte nu.
Det lyder som om du gerne vil havde os til at tro du ved hvad du snakker om med hensyn til hvad kerne 2.6 kan og ikke mindst ikke er noget nyt.
Har du noget seriøst ikke markerings hype til at understøtte dette ?
Ikke fordi jeg ikke tror på hvad du siger, jeg kunne bare godt tænke mig at læse en ordentlig gennemgang af det du siger.
#27 -
26. nov. 2003 20:53
Nr. 24: vi ku' jo kalde det en 'Service Pack' :-)
Jeg ved ikke om jobkontrollen, altså scheduleren er forbedret, men til tider kan kernen ikke afbrydes når den udfører en opgave. Lidt ascii-grafik:
Mozilla . . . -> interrupt fra kerne, den kræver opmærksomhed
KERNEPROCES
--> kerne allokerer en mængde hukommelse, men afbrydes af
---> en filoperation, men så afbrydes den af....
...ingenting, for filoperationen skal færdiggøres først
Jeg ved ikke om jobkontrollen, altså scheduleren er forbedret, men til tider kan kernen ikke afbrydes når den udfører en opgave. Lidt ascii-grafik:
Mozilla . . . -> interrupt fra kerne, den kræver opmærksomhed
KERNEPROCES
--> kerne allokerer en mængde hukommelse, men afbrydes af
---> en filoperation, men så afbrydes den af....
...ingenting, for filoperationen skal færdiggøres først
#26
Siden jeg har været med til at lave en del af den, vil jeg da håbe det er tilfældet. Ellers ville det da være lidt sørgeligt.
Der er en del gode 2.6 gennemgange på nettet, jeg vil henvise folk til dem. Det gavner ingen at sprede falske ideer om hvad 2.6 kan. Det bliver helt sikkert en god kerne (og de manglende features som ordentlig HT support vil med garanti blive merged i 2.6.x-tidlig).
Dave Jones har et 2.6 halloween doc som kan findes her:
http://www.codemonkey.org.uk/post-halloween-2.5.tx...
som beskriver i grove træk. C't har en artikel i seneste udgave som heller ikke er tosset. lwn.net har løbende haft rigtig mange gode artikler, kan ikke lige huske om de har et 'gyldent overview' dokument. Men de er bestemt hver at tjekke ud.
Siden jeg har været med til at lave en del af den, vil jeg da håbe det er tilfældet. Ellers ville det da være lidt sørgeligt.
Der er en del gode 2.6 gennemgange på nettet, jeg vil henvise folk til dem. Det gavner ingen at sprede falske ideer om hvad 2.6 kan. Det bliver helt sikkert en god kerne (og de manglende features som ordentlig HT support vil med garanti blive merged i 2.6.x-tidlig).
Dave Jones har et 2.6 halloween doc som kan findes her:
http://www.codemonkey.org.uk/post-halloween-2.5.tx...
som beskriver i grove træk. C't har en artikel i seneste udgave som heller ikke er tosset. lwn.net har løbende haft rigtig mange gode artikler, kan ikke lige huske om de har et 'gyldent overview' dokument. Men de er bestemt hver at tjekke ud.
#27
Dit eksempel er lidt forkert, en interrupt handler vil ikke blive preempted af andet kode. Den kører altid den er færdig. En process der kører i kernen kan således kun preemptes når den er i en tilstand til at blive det. Dvs hvis den i øjeblikket servicerer en interrupt, holder en (eller flere) locks, eller har interrupts disabled vil den ikke blive preempted.
Basalt set tager man samme sæt regler som man bruger på SMP processorer i mellem og benytter de samme primitiver til at holde styr på om en process kan preemptes eller ej.
Dit eksempel er lidt forkert, en interrupt handler vil ikke blive preempted af andet kode. Den kører altid den er færdig. En process der kører i kernen kan således kun preemptes når den er i en tilstand til at blive det. Dvs hvis den i øjeblikket servicerer en interrupt, holder en (eller flere) locks, eller har interrupts disabled vil den ikke blive preempted.
Basalt set tager man samme sæt regler som man bruger på SMP processorer i mellem og benytter de samme primitiver til at holde styr på om en process kan preemptes eller ej.
#30 -
26. nov. 2003 21:12
Nr. 27: Jeg tror dig på dit ord, jeg kan se dit navn figurer nogle gange i kernen :-)
Iøvrigt, tak for loop-AES-v1.7e tingen.
PS: Er AES som loop-enhed en sikker kryptering? Jeg har ikke haft "tid" til at tjekke koden (bob bob)
Iøvrigt, tak for loop-AES-v1.7e tingen.
PS: Er AES som loop-enhed en sikker kryptering? Jeg har ikke haft "tid" til at tjekke koden (bob bob)
#30
Jeg ved ikke rigtig hvorfor, men siden jeg skrev loop om i 2.4-tidlig, så tror folk jeg har lavet en masse andre ting der. Ikke sandt :-).
Hvor sikker AES er vil jeg overlade til eksperterne i kryptografi at vurdere, det er jeg vist ikke kvalificeret til at svare på.
Jeg ved ikke rigtig hvorfor, men siden jeg skrev loop om i 2.4-tidlig, så tror folk jeg har lavet en masse andre ting der. Ikke sandt :-).
Hvor sikker AES er vil jeg overlade til eksperterne i kryptografi at vurdere, det er jeg vist ikke kvalificeret til at svare på.
Skidrow og Axboe:
Kanon endelig en der ved hvad han snakker om.
Axboe:
Jeg vil gerne undskyld min direkte kommentar, du har tydeligtvis styr på hvad du snakker om, respekt.
Jeg tror lige jeg skal grave lidt i det nye c't, tak for tips.
øøøvvv, har ikke fået det c't endnu, kommer nok med posten i morgen.
Kanon endelig en der ved hvad han snakker om.
Axboe:
Jeg vil gerne undskyld min direkte kommentar, du har tydeligtvis styr på hvad du snakker om, respekt.
Jeg tror lige jeg skal grave lidt i det nye c't, tak for tips.
øøøvvv, har ikke fået det c't endnu, kommer nok med posten i morgen.
#30
Selve AES algoritmen er ganske sikker, og forholdsvis simpel så den er næste umulig at implementere galt...
(Man skal ikke tage højde for de to milliarder måder man kan faktorisere primtal på, som man skal med assymetriske systemer.).
Den er også lavet som en konkurrence af USA, hvor alle lande har kunne komme med forslag (AES er lavet af nogle hollændere).
AES blev valgt fordi den var den hurtigste algoritme som stadig var sikker.
Algoritmer du skal undgå er Des og 3-Des. Des fordi den er 56bit, og 3-Des, fordi den er gammel, langsom og bruger fordefinerede tabel værdier lavet af IBM og NSA. Disse kan måske bruges som bagdør til at dekryptere (dette er meget usandsynligt og aldrig bevist, men da DES blev udgivet var NSA/IBM også de eneste der kendte til differentiel cryptoanalysis... Som tabellerne er designet til at modvirke.)
Alle de andre symmetriske algoritmer der er i kernen bliver betragtet som sikre.
Blowfish, Serpent, Twofish osv. Men AES er den hurtigste i flokken.
Det største problem med krypterede harddiske er at nøglen måske bliver gemt i cache på harddisken - så det er noget at kerneudviklerne skal sørge for.
Et andet problem er at nøglen bliver gemt i rammen, og denne ikke bliver slettet når computeren bliver genstartet (så sæt det op i bios).
Men udover dette må du håbe at de 'mange øjne' forhåbentlig kigger koden igennem...
P.S, husk også at kryptere dit swap-drev.
Selve AES algoritmen er ganske sikker, og forholdsvis simpel så den er næste umulig at implementere galt...
(Man skal ikke tage højde for de to milliarder måder man kan faktorisere primtal på, som man skal med assymetriske systemer.).
Den er også lavet som en konkurrence af USA, hvor alle lande har kunne komme med forslag (AES er lavet af nogle hollændere).
AES blev valgt fordi den var den hurtigste algoritme som stadig var sikker.
Algoritmer du skal undgå er Des og 3-Des. Des fordi den er 56bit, og 3-Des, fordi den er gammel, langsom og bruger fordefinerede tabel værdier lavet af IBM og NSA. Disse kan måske bruges som bagdør til at dekryptere (dette er meget usandsynligt og aldrig bevist, men da DES blev udgivet var NSA/IBM også de eneste der kendte til differentiel cryptoanalysis... Som tabellerne er designet til at modvirke.)
Alle de andre symmetriske algoritmer der er i kernen bliver betragtet som sikre.
Blowfish, Serpent, Twofish osv. Men AES er den hurtigste i flokken.
Det største problem med krypterede harddiske er at nøglen måske bliver gemt i cache på harddisken - så det er noget at kerneudviklerne skal sørge for.
Et andet problem er at nøglen bliver gemt i rammen, og denne ikke bliver slettet når computeren bliver genstartet (så sæt det op i bios).
Men udover dette må du håbe at de 'mange øjne' forhåbentlig kigger koden igennem...
P.S, husk også at kryptere dit swap-drev.
Jeg vil da godt anbefale folk at tjekke Linux Weekly News (lwn.net), specifikt deres ugentlige udgivelser (som man kan abbonnere på, ellers må man vente en uge får de er frit tilgængelige). En oversigt over de seneste udgivelser kan findes her: http://lwn.net/Kernel/
De følger godt med i hvad der sker i udviklingen af kernen og har artikler om mange af de nye ting der er i den nye kerne.
De følger godt med i hvad der sker i udviklingen af kernen og har artikler om mange af de nye ting der er i den nye kerne.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund