Linux vs Windows gällande diskfragmentering.

Det är något jag funderat över, varför tar det en sån fruktansvärd lång tid för Windows att uppdatera? Visst ibland går det fort men emellanåt tar det ju hur lång tid som helst.

Men inte tar väl det speciellt lång tid eller? Har bara installerat det på Debian och det tyckte jag inte tog omotiverat lång tid.

Du kan installera massa program i Linux utan att bloata ned ett register, så Linux blir inte instabilare ju mer program du installerar. Windows har det problemet, så installera få Windows program.

Generellt är ntfs inte vidare bra och gammalt, det blir fragmenterat lätt. Journal har inget med fragmenteringar att göra, det används bara vid reparation. Linux filsystem blir inte alls lika fragmenterat, pga de är modernare. Linux fragmentering är inte ett problem, men det är ett problem i windows.

(För längesen låg Linux grafik utanför ring 0, dvs i periferin i kernel, precis som alla Unix. Detta gjorde att du kunde starta om grafiken på ett enkelt sätt, och ifall grafiken kraschade så kraschade inte kernel. För typ 3-4? År sen, lades grafiken in tillsammans med ring 0 i kernel. Detta gjordes därför att då blev graiken snabbare, (pga färre context switches?). Problemet med detta är att ifall grafiken kraschar, så kraschar hela kärnan, dvs datorn kraschar och Linux blev instabilare. Men grafiken är snabbare idag.

Windows gjorde helt tvärtom. I början låg grafiken inne tillsammans med winkernel och det blev snabb grafik. För att få det stabilare, separerades grafiken och kernel ganska nyligen (win7?). Nu kan du enkelt starta om grafiken, uppdatera drivisiar, etc - utan att behöva boota om windows. Windows idag är mycket stabilare än förr. Medan Linux gått åt andra hållet, mer bloatad kernel.)

Det vart en jäkla tid, med eller utan nerladdning av paketen?

Jag tror Ubuntu och Debian har kommandot checkrestart. Om du kör kommandot sa listar det vilka processer som använder gamla versioner av uppdaterade filer och därmed behöver startas om.

Så spel servers kör windows alltså Förstår då varför dom är nere titt som tätt

Hahah, finns nog lite fler anledningar än det

Tänkte väl det. Är väl nästan en gigabyte den ska ladda ner och installera

Skillnaden mellan kernel mode setting och user mode setting koden är snarare det omvända. Linux grafikdrivrutiner (inclusive mode setting) brukade ligga x-servern (user space). X-servern mappade IO adresserna till hårdvaran direkt till sin egen adress space och skrev direkt till minnet genom /dev/mem. För att göra det var det nödvändigt att köra x-servern som root och eftersom x-servern hade direkt tillgång till hårdvaran det var omöjligt för kerneln att skydda sig själv för buggar i x-servern. Hela systemet kunde gå ner om x-servern gjorde galna saker.

Vanliga drivrutiner har inte det problemet eftersom de ligger i kerneln och user space processer kommunicerar bara med kerneln när de vill komma åt hårdvaran. Runt 2007 beslutades det att även grafikdrivrutiner ska ligga i kerneln för att garantera korrekthet. Fördelarna är att en buggig x-server inte kan krascha hela systemet. Power management blir enklare eftersom kerneln vet vad hårdvaran håller på med. Tidigare var det svårt att använda t.ex. ASPM för kerneln visste inte vad x-serven håll på med så den kunde inte avgöra om det var säkert att aktivera vissa power save modes. Suspend resume blir också enklare av samma anledning. Tidigare var kerneln tvungen att lita på att x-servern kunde återställa hårdvaran. Med drivrutinerna i kerneln kan kerneln göra all power management själv. När kerneln har kontroll över hårdvaran kan den bestämma vad som ska visas på skärmen när som helst. Det används nu för att automatiskt växla till en terminal och visa kernel oops meddelanden (linux blue screen of death). De meddelandena brukade tidigare gå förlorade.

Det är inte bara fördelar med KMS. De grafikdrivrutinerna som körs i kerneln är bara en liten del. Det mesta av koden t.ex. shader kompilering körs fortfarande i user space. User space drivrutinerna genererar en hårdvaruspecifik command stream som skickas till kerneln och kerneln matar sedan hårdvaran med denna command stream. User space drivrutinerna räknas som untrusted så för att garantera korrekthet måste kerneln validera denna command stream innan den ges till hårdvaran. Detta kan vara lite långsammare än att köra grafikdrivrutinerna helt i user space men i praktiken gör det ingen skillnad.

En annan fördel med user space drivrutinerna är att så länge kerneln tillåter direkt hårdvaruåtkomst så är drivrutinerna plattformsoberoende. De funkar både i linux och de olika bsd varianterna. KMS har inneburit en liten kris för *bsd för de har inte manskap att utveckla egna drivrutiner eller ens porta de befintliga linux drivrutinera i den takt de utvecklas.