Linsched: simulering av Linux kernel scheduler

Linsched är en kernel scheduler-simulator som fungerar i user-space. Linsched underlättar att utveckla och testa nya regler för schedulern och är samtidigt ett utmärkt medel för att studera scheduleringen.

Tack vare att Linsched fungerar enbart i user-space kan man använda vanliga debuggers såsom gdb. Linsched inkluderar ett antal automatiska testfall för att verifiera funktionen på olika hårdvaruarkitekturer.
Tyvärr finns det för närvarande väldigt lite dokumentation kring Linsched:

• Linsched: the Linux Scheduler Simulator
• Linux Scheduler simulation

Industrin stödjer Linux Kernel Long Term Support Inititiative

Linux Foundation annonserar initiativet LTSI (Long Term Support Initiative) som syftar till att bilda en ny gren av Linux-kärna med förlängd supportperiod och regelbundna uppdateringar. Initiativet förutsätter att vissa releaser av kärnan kommer att få särskild status med 2 års support period.

Initiativet stöddes av ett flertal ledande tillverkare av konsumentelektronik såsom Hitachi, LG Electronic, NEC, Sony, Panasonic, Samsung och Toshiba. Linux Foundation kommer att ha en roll som kooridantor för en centraliserad kodbas. Tack vare detta kommer blir det möjligt för hårdvarutillverkarna att sänka utvecklingskostnader och effektivisera användning av de resurser som tidigare inriktades på att göra samma jobb som redan hade gjorts av andra företag: t ex gransking och backporting av nya uppdateringar till kärnan, felsökning och testning samt utveckling av drivrutiner.

Man förväntar att LTSI-kärnan kommer att kunna användas även som grund för inbäddade system, chipsets och diverse mjukvaruprojekt.

Vad är en shell?

I den här artikeln ska vi inte ge någon inledning i tekniska detaljer. Här riktar vi oss till de användare som inte har någon stor erfarenhet av shell (även kallad skalprogram på svenska) och som skulle vilja veta varför man överhuvudtaget använder shells och vilken nytta man kan ha av dem. Här kommer vi att försöka besvara följande frågor:

• Vilken roll spelar en shell i det hela systemet?
• På vilket sätt underlättar shell det dagliga arbetet?
• På vilket sätt bidrar shell till att skapa en personlig arbetsmiljö?
• Finns det bara en shell eller flera olika?

UNIX, GNU och Linux: historisk tillbakablick

Alla kommersiella försök att standardisera UNIX misslyckades. Ett framgångsrikt projekt startades i början på 1980-talet vid MIT av Richard Matthew Stallman, gamla epokens siste hackare: projektet GNU (GNU's Not Unix). Stallmans mål var att skriva ett nytt UNIX-likande system from scratch. Tanken var att systemet skulle bli fritt tillgängligt. Tack hans intensiva insats och andra programmerares bidrag uppstod fram till slutet av 1990-talet en avsevärd och kraftfull samling av UNIX-verktyg. Själva systemet har hittils inte blivit färdigt, men GNU-verktygen har etablerat sig på många UNIX-varianter, bl a för att enstaka UNIX-leverantörer ville bygga ut sina intäktskällor ännu mer. Med grundpaketet levererades t ex ingen GNU C-kompilator. Sedan tog många systemadministratörer, för att spara pengar, Stallmans GNU C-kompilator som egentligen var kvalitativt bättre. Så blev GNU-verktygen til en systemövergripande quasi-standard. Den fria utvecklingsmetoden lyckades komma ett steg vidare än de proprietära standardiseringsförsöken.

Intressant: När Stallman tog beslutet att starta GNU, hade han aldrig tidigare arbetat med UNIX och inte skrivit en enda rad C-kod. Allt han visste var ett par grundläggande koncept och faktumet att UNIX hade bevisat sitt plattformoberoende.

Även på den akademiska sidan mötte man allt oftare UNIX-leverantörernas slutna hållning: i början ställde AT&T källkoden till universitetens förfogande och koden kunde därmed användas som undervisnings- och forskningsmaterial. När AT&T stängde källkoden försvann den här möjligheten. Andrew S. Tanenbaum, informatikprofessor vid Amsterdams universitet, bestämde sig därför för att skriva en egen version av UNIX som inte hade något att göra med AT&T:s upphovsrättsskyddade kod. Efter två års slit publicerade han sitt system som fick namnet Minix. Systemet var tänkt inte som något praktiskt användbart verktyg, utan framför allt som lärobjekt. Trots detta användes Minix av väldigt många studenter på hemdatorer för att det var tillgängligt till ett skäligt pris, till skillnad från de kommersiella UNIX-varianterna. I det här användningsområdet nådde Minix väldigt fort sina gränser. Många Minix-användare lämnade utvecklingsförslag till Tanenbaum och skickade sina patcher med tillägg och förbättringar. Tanenbaum var dock mycket tillbakahållen med detta. Han såg Minix framför allt som tutorial och strävade snarare efter en koncis och tydlig struktur än någon omfattande funktionalitet.

En Minix-användare vid namn Linus Torvalds nöjde sig inte med detta. Allt förutom kärnan i GNU-systemet var färdigt. En release av GNU-kärnan som hette HURD verkade vara en avlägsen händelse. För att fylla den här tidsluckan började Linus Trovalds skriva en egen kärna som väldigt fort spreds under namnet Linux och bildade en stor community av användare och utvecklare. De flesta utvecklarna jobbade på UNIX-varianter där GNU-verktygen fanns. Därför var det naturligt att gestalta Linux-kärnan på ett sådant sätt att den skulle kunna användas tillsammans med GNU-verktygen: GNU/Linux. Kärnan HURD har hittills inte övervunnit sitt tidiga "akademiska" utvecklickngsstadium och Linux, som i början var tänkt som något provisoriskt, har etablerat sig på HURD:s plats.

Samtidigt befriades BSD från sitt ursprungliga beroende av AT&T: en grupp BSD-utvecklare ersatte alla anvisningar i källkoden, som fortfarande styrdes till en stor del av AT&T, med nya och i ett långvarigt mål erövrade frihet för BSD. Det blev början till en mängd projekt såsom FreeBSD, NetBSD och OpenBSD som också fann en betydlig popularitet. De här projekten kallas ibland för Linux syskon (och många Linux-distributioner innehåller ibland något läckert från de här operativsystemen).

Sedan dess har Linux utvecklats till en betydande UNIX-variant: kommerisella UNIX-leverantörer förlorade marknadsandelar till fördel för Linux och fick utveckla nya strategier. Ofta mynnade deras nya idéer ut i att leverera stödtjänster för Linux vars vidare spridning inte längre kunde förhindras.

UNIX (särskilt dess fria versioner) är idag en stabil aktör på servermarknaden. En av de mest spännande frågorna idag är vilken potential UNIX har i desktop-segmentet.

Källa: UNIX, GNU & Linux

Splittring av UNIX och standardiseringsinitiativ

1984 lösgjorde sig AT&T från åtskilliga dotterbolag, vilket gjorde möjligt att uppträda som en vanlig aktör på IT-marknaden. Samtidigt höjdes licensavgifterna på UNIX drastiskt och tillgång till källkoden blev mer och mer begränsad. Det ledde till att samarbetet mellan de bolag som marknadsförde UNIX kommersiellt blev svagare och svagare: var och en byggde sina egna och tilläggsprogram och förbättringar i sin egen UNIX-version. Till slut blev UNIX splittrad i ett fruktansvärt stort antal olika versioner: SunOS av SUN, HP-UX av Hewlett-Packard, AIX av IBM, Ultrix av Digital, SINIX av Siemens. Även Microsoft försökte sig på UNIX-marknaden genom att släppa sin egen UNIX vid namn Xenix. En stor fördel, den enkla porterbarheten av UNIX-program, hotade att försvinna med den här splittringen. Många profeterade om ett ände av UNIX i det medellånga loppet.

När AT&T fick uppträda på marknaden som aktör efter ett nederlag, gjordes även ett försök att skapa en standard: System V (V:et står för talet 5 och inte för bokstaven, begreppet uttalas som System Five).

1985 offentliggjorde AT&T System V Interface Definition eller "den lila boken" (The Purple Book). Det här dokumentet presenterade en standard för UNIX-gränsnitten. Dessutom innehöll dokumentet ett antal verktyg som kunde kontrollera ett system på dess konformitet med Standard V. UNIX-versionen /UNIX System V" som släpptes 1983 hade blivit dominerande när standarden offentliggjordes. "Den lila boken" blev ett försök att ena de olika tillverkarna om en standard. På grund av motståndet, som uppstod bl a därför att man inte ville göra sig beroende av ett företag, skapades så småningom även andra standarder som t ex POSIX (Portable Operating System based on UNIX). IEEE (Institute of Electrical and Electronic Engineers) valde det här namnet för den här standarden för att AT&T ägde alla rättigheterna på namnet UNIX. Ett annat exempel på en liknande standard är X/Open. X/Open konsortiet är en sammanslutning av olika tillverkare som ville skapa en de-facto-standard. 1988 offentliggjordes X/Open Portability Guide.

Resurser

• Ett historiskt diagram av UNIX och UNIX-liknande operativsystem
• UNIX system
• System V Interface Definition Fourth Edition

Källa: SelfLinux: Die Zersplitterung von UNIX und Standardisierungsbestrebungen

Skapa egna paket för Debian/Ubuntu: ett enkelt sätt

För att förenkla migrationen mellan olika distributioner och/eller underhålla samma filer på flera datorer, går det att skapa egna paket i deb-format. Sådana paket är enkla att installera och ta bort på varje apt-baserad distribution av Linux.


Jag letade efter en enkel metod som skulle lösa mitt problem. Efter att ha läst lite om pakethanteringen i Debian hittade jag ett "quick-and-dirty" sätt att skapa egna paket.

Hur skapar man ett enkelt paket för Ubuntu/Debian: instruktioner

• Skapa följande kataloger för det blivande paketet:

  $ mkdir mypackage
  $ mkdir mypackage/DEBIAN
  

• skapa en kontrollfil:

  $ emacs mypackage/DEBIAN/control
  

  Använd den här mallen för filen control:
  

  Package: mypackage
  Priority: optional
  Section: devel
  Installed-Size: 100
  Maintainer: John Hancock <john.hanock@example.com>
  Architecture: i386
  Version: 1.0
  Depends: libc6 (>= 2.1)
  Description: This is just a test package.
  

  Installed-Size anger paketets storlek i KB. Om din beskrivning är längre och tar några rader, behöver du sätta ett mellanrum i början av varje nästa rad för att visa att texten tillhör fältet Description.
  

• Placera dina filer i katalogen mypackage. Katalogstrukturen i mypackage ska presentera paketets filsystem relaterat till roten (/): om en fil ska vara i /usr/bin/ efter installationen, ska den placeras i mypackage/usr/bin/ innan paketet skapas.

  $ mkdir -p mypackage/usr/bin/
  $ cp /home/user/myscripts/myprogram.sh mypackage/usr/bin/
  

  Nu innehåller ditt paket filen myprogram.sh som kommer att installeras i /usr/bin/.

• Nu bygger vi ihop paketet!

  $ dpkg-deb -z8 -Zgzip --build mypackage
  

  Detta kommer att skapa ett gzip-komprimerat paket (den 8 nivån av komprimeringen (9 är högst och långsammast)).

• Nu är ditt paket redo att installeras vilket man kan göra så här:

  $ sudo dpkg -i mypackage.deb
  

OBS: om dina paket ska distribueras, behövs det versionhantering, singering och utförligare beskrivning. Läs mer här:

• Create Debian Linux packages: Learn how to build easy-to-distribute packages for Debian users
• Rolling your own Debian packages
• Debian Binary Package Building HOWTO

Att skapa en effektiv arbetsmiljö med fönsterhanteraren awesome: varför är tangentbordet viktigt?

Den absolut största anledningen för mig till att välja Xubuntu i stället för Kubuntu var prestandan. Fönsterhanteraren XFCE4 i Xubuntu frigjorde en hel del datorresurser och jag var mycket nöjd med bytet ett tag. Efter att ha använt KDE4 och XFCE4 några månader, började jag dock längta efter Ion3 som jag hade använt före KDE4 och som var ännu snabbare än XFCE4.


Men det var inte prestandan jag längtade efter. Ion3 var tangentbordsstyrd och jag lyckades anpassa också både KDE4 och XFCE4 så att man kunde styra så mycket som möjligt från tangentbordet. Men det är inte fönsterhanterarens prestanda som gör den användbar. Prestandan är oerhört viktig, lärde jag mig, men jag insåg att det krävs något annat också.

Nu inser jag att en tile-baserad såsom awesome fönsterhanterare är ett måste för mig. Jag vill slippa tänka på fönster som överlappar varandra. Att använda musen eller pekplattan varje gång när man vill byta till ett annat fönster kräver för mycket fokus:

• jag måste hitta muspekaren visuellt
• jag måste flytta min hand från tangetbordet
• jag måste göra exakta rörelser med handen för att flytta muspekaren till det rätta stället på tangetbordet
• jag måste klicka

Tänk på att sådant måste göras tusentals gånger per dag! Det är ren slöseri med ens uppmärksamhet och koncentrationsförmåga. Att använda knappkombinationen Alt+Tab för att leta efter ett fönster när man kör tio program samtidigt blir oeffektivt också: man ser ett pop-up fönster där man ska hitta rätt program visuellt - det tar en hel del koncentration också om man gör det hundratals gånger varje dag.

Knappkombinationen Alt+Tab är effektiv om man byter snabbt mellan två program, men den är värdelös om man måste byta snabbt mellan tre eller fler program.
Det traditionella skrivbordet liknar ett skrivbord där pappren ligger i stora högar och man måste rota i dem varje gång man behöver hitta något. Det kan bli hur irriterande som helst!

I stället vill jag ha ett fast och separat utrymme för varje program så att jag slipper leta efter fönster och kan spara min koncentration för arbetet.

Med awesome vet jag att jag har:

• ett utrymme för terminalen som jag använder med GNU screen. Det innebär att jag kan ha flera bash kommandotolkar i en terminal vilket är väldigt smidigt. Dit kommer jag alltid genom att trycka Mod4+1
• ett utrymme för webbläsaren eller till och med två för att jag använder både Chromium och Firefox. Knappkombinationerna respektive Mod4+2 och Mod4+3
• ett utrymme för min favoritprogram: EMACS och org-mode. Det är särskilt viktigt här: jag måste alltid veta var jag hittar dem. Jag kommer alltid till det här utrymmet via knappkombinationen Mod4+4. Och det måste man kunna göra så smidigt som möjligt när man exempelvis behöver anteckna en tanke, skapa en TODO eller titta i almanackan.
• ett utrymme för instant-messengern pidgin. Knappkombinationen Mod4+9.

En annan förbättring som jag gjorde på sistone var att lägga knappkombinationer för att starta alla de här programmen och flera andra:

• Mod4+Shift+s för terminalen
• Mod4+Shift+f för Firefox
• Mod4+Shift+t för Chromium
• Mod4+Shift+o för org-mode
• Mod4+Shift+m för musikspelaren mocp
• Mod4+Shift+v för volumkontroll via alsamixer

Jag är förvånad hur snabbt det går att lära sig alla de här knappkombinationer som man har skapat själv. För man har valt något som känns intuitivt och naturligt.

Efter att ha gjort allt detta blev jag ännu mer irriterad på användargränssnittet i Windows på jobbet. Men jag hittade ett fantastikt program som heter bug.n som är väldigt liknande dwm som i sin tur liknar awesome. Med bug.n får man en tile-baserad och tangentbordsstyrd fönsterhanterare i Windows!