Tag Archives: fri programvara

Booting Debian Wheezy (testing) from rEFIt in EFI mode using grub-efi on a Macbook polycarbonate Unibody

Basically I mixed two already existing guides, so I’m going to slightly gloss over what they’re saying and just fill in the blanks. Basically, the workflow is as follows:

  1. Partition your hard disks (from Mac OS disk utility).
  2. Create a BIOS Boot partition in Mac OS using gparted.
  3. Install Debian the usual way (using the guide) on your free space.
  4. Install rEFIt in Mac OS.
  5. Fix the now-broken protective MBR (mine wasn’t though) using gdisk in Mac OS.
  6. Use rEFIt to boot a Super Grub 2 boot disk, and use that to chainload your Debian installation (that can’t boot on itself due to the aforementioned nuked MBR). Also, we’re not home yet, we’re still in legacy mode.
  7. Once in Debian: remove grub-pc and install grub-efi-amd64.
  8. Mount the EFI boot partition and make an EFI boot image for grub using grub-mkimage.
  9. Copy files to your boot partition (that’s your /boot, not the EFI boot partition).
  10. Clean up and remove the BIOS boot partition.

The process is slightly complicated, but it’s the same as Rod’s guide (except I installed Debian and not Ubuntu), up until point 7, where I’m diverging from both of the guides. The main difference is that mennucc1 is basically building him/herself a new boot on the EFI startup partition, containing a separate copies of all Grub modules, kernel images etc. This means, specifically, that it’s completely out of sync with the debian config and needs to be manually maintained at every kernel update.

On the other hand, Rod’s approach didn’t exactly work for me either, because the installation of grub-efi didn’t update the module files in boot, leading to cryptic error messages at boot about »Invalid arch independent ELF magic« and, even worse, to the video drivers not being loaded and thus no image.

So, what I altered was: after generating the EFI image with grub-mkimage (and using my /boot/grub path, (hd0,gpt3)/grub as argument to -p) and placing it in a separate folder on the EFI boot partition (that is (hd0,0) on my computer, or sda1 – probably is on yours, too), I simply copied every .mod file from /usr/lib/grub/x86_64-efi/ to /boot/, overwriting the old files from grub-pc. After a reboot, Grub launched and booted Debian as expected.

It seems that what the -p argument does is setting the root partition for GRUB, from which it loads its modules and config files. In addition to this, I also updated /etc/default/grub to add GRUB_VIDEO_BACKEND=”efi_gop”, followed by the usual update-grub before reboot.

When everything works, delete the BIOS boot partition, as in Rod’s guide.

It’s worth mentioning that I have a quite complicated setup with encrypted LVM, and that everything worked out of the box once the grub.efi image was in place (and the correct .mod files copied to /boot/), save for the keyboard layout for the encryption password. Fortunately, I can still type with qwerty, just not very fast. I’d guess, however, that this is just a matter of passing the right module the right parameters somewhere.

For those who are interested, the boot process now goes something like this: EFI firmware → rEFIt → grub.efi on (hd0,0) → module files and settings on (hd0,gpt3)/grub/ (a.k.a. /boot/) → Linux kernel (also on (hd0,gpt3)).

Known problems

If I Insert a USB stick before I boot, this will be assigned to hd0 in grub, leading to grub.efi failing to load its settings or modules, since they are now at (hd1,gpt3)/grub, their device number having been incremented by one. I suppose this could be solved by using disk UUID for the -p argument in grub-mkimage.

Why going through all that trouble?

Well, mainly because I’m not fond of Debian being treated as a second-class citizen on the computer, running in an emulated BIOS legacy mode, but also because some functions aren’t available in that mode.

I hope someday this will be the default boot mode in Debian on Macintoshes. Actually, this shouldn’t be very far away, since everything I’ve done could easily be automated by debian-installer.

What lies ahead?

The, long, hard road to the perfect configuration. Also, playing around with Mac OS X to see how far I can customize it into something actually useful (think tiling window manager, Emacs, a package manager and much less fancy graphics, rounded corners and semi-transparency).

Problemet med webapplikationer och fri mjukvara (igen)

Det här låter som ett gammalt rant, men jag ska försöka hålla mig borta från att upprepa mig mer än nödvändigt. Mycket av min gamla kritik mot webapplikationer är ändå underminerad: när man började bygga dem så var det förvisso som att skriva program i worddokument, men i och med HTML5 och CSS3 har webstandarderna rört sig långt bort från dokumentstandarden och snarare blivit någon sorts gränssnittsstandard.

Detta har förstås både bra och dåliga konsekvenser, men alldeles oavsett så kan jag inte längre driva argumentet att webapplikationer är något i grunden tekniskt efterblivet längre. Åtminstone om man inte räknar med argumentet att det är dumt att återinföra tunna klienter (vilket förstås fortfarande håller). Många webapplikationer håller dock på att lösa även detta problem med avancerade funktioner för mellanlagring och synkronisering av data mot servrarna.

Dessutom finns det en juridisk-teknisk lösning för ofriheten i applikationerna i form av framför allt AGPL, som effektivt täpper till nätverkshålet. Om vi bortser från att ingen av de mer välanvända webapplikationerna följer AGPL så får vi ändå anse att problemet är hyfsat löst i teorin, om än inte i praktiken.

Men det kvarstår ett problem som är långt mycket viktigare. Syftet med fri programvara är ju att ge dataanvändaren kontroll över sitt datande, dels för att förhindra asociala situationer (typ att man har en hög kod som man inte får dela med sig av), dels för att ge användaren en ärlig chans att förbättra sitt datande.

I och med AGPL-lösningen hamnar kontrollfrågan och framför allt den sociala aspekten på skam. För är det verkligen koden vi vill ha? Är det verkligen i Googles kod som dess värde ligger? Svaret är att nej, det är det inte. Vi använder inte Gmail för att det är så jävla bra (eller ok, webklienten är ju typ den bästa web-epostklienten någonsin), utan för att det finns. Koden för Gmail skulle vara i princip värdelös för oss som användare! Det är nätverkseffekterna, olika synergieffekter och skalfördelarna vi är ute efter, snarare än just den tekniska lösningen.

För att exemplifiera problematiken med övergången till »molnet« kan vi tänka oss ett företag som gjort en klon av Diaspora och nu kör den under namnet Z-ION. Låt oss säga att vi har alla våra vänner och foton på Z-ION, samt att våra föreningar är organiserade där. Låt oss anta att en dag kundgör Z-ION att de ska införa någon vansinnig policy, typ att de avsätter en liten del av sidan specifikt för muslimer, där de bara under sträng övervakning får kommunicera med icke-muslimer. Dessutom raderas eller låses muslimernas konton slumpmässigt med jämna mellanrum, samt även konton tillhörande personer som kommunicerar med dem.

Z-ION besvarar kritiken mot denna helt vansinniga policy med att det är de som kör servrarna och de får göra vad de vill med dem. Dessutom påpekar de att om någon inte gillar hur de kör sin server så är de fria att köra en egen.

Sagt och gjort: en utbrytarfraktion bildar en ny server. Ett första problem dyker upp: AGPL (såvitt jag vet) ger inte användarna rätten att hämta ut sin data. Men ok, låt oss anta att detta har implementerats som ett tillägg. Nästa problem: AGPL kräver inte heller att det ens formellt ska finnas möjligheter att nätverka med servern från andra servrar.

Denna fråga är mycket snårigare än frågan om rätten till datan. Tjänsten tillhandahåller ju på sätt och vis alltid datan på ett människoläsbart sätt, så ett krav på att den även ska finnas på ett datorläsbart sätt är inte på något sätt orimligt. Att däremot kräva att serveradministratörerna inte bara ska implementera funktionen att nätverka med andra (konkurrerande) servrar, utan också faktiskt tillåta nätverkande med dessa är ett mycket tveksammare krav som bryter med allt vad liberalt rättighetstänkande är. Och utan server-till-server-kommunikation är vår Z-ION-klon mer eller mindre värdelös, eftersom värdet i ett socialt nätverk främst ligger i just nätverket.

Här kan vi dock tänka oss en lösning som går ut på att dessa krav om nätverksmöjligheter ställs från någon sorts samhällig myndighet på alla tjänster som överstiger en viss nätverksnivå och som börjat bli rena samhällsinstitutioner. Denna myndighet skulle kunna ha till uppgift att kontinuerligt granska hur nätföretag hanterar sina nätverkseffekter och förhindra monopolbildning.

Men även om vi både får möjligheten att nätverka och möjligheten att fly med vår data så finns det ett viktigt problem av närmast ontologisk karaktär. Kort uttryckt: är vår kopia av Z-ION verkligen samma eller ens likadan som originalet, eller ingår det något i detta dator-data-människa-assemblage som inte är kod, och som i värsta fall inte heller är kopierbart?

För att omformulera åter igen: förhåller sig verkligen användaren till en webapplikation på samma sätt som till en offlineapplikation? I vissa fall skulle jag säga att det är så, men i långt ifrån alla och verkligen inte med sociala nätverk.

Värdet i ett enskilt offlineprogram är för användaren att han eller hon kan använda det. Värdet i ett nätverk eller en webapplikation är dels att den allitd är tillgängligt, d.v.s. att någon betalar server- och nätverksavgifter samt har ett helt team av ingenjörer som kontinuerligt löser drift- och säkerhetsproblem, dels att det redan finns andra människor där att nätverka med, något jag bittert erfar varje gång jag kommunicerar med min enda vän på Diaspora.

Sociala nätverk är (som de är konstruerade nu) med nödvändighet stora. Facebook och Google har inte blivit gigantiska kolosser av en slump eller för att de är så bra, utan av en teknisk nödvändighet: när snöbollen väl börjat rulla kan man inte stoppa den, och att stara en ny går helt enkelt inte.

Notera att min determinism i det ovanstående påståendet inte är hård, utan mjuk. Den nuvarande tekniska utvecklingen har lett fram till denna situation. Det innebär inte att den inte kan leda bort från den, även om det nu finns starka krafter för att behålla ordningen, av dem inte minst latheten och slentrianen.

Min gissning är att DNS-systemet och WWWs tekniska utformning till stor del är ansvariga för att det har blivit som det blivit. För att snabbt hitta en dator på internet behöver man i princip ha ett domännamn. För att ha ett domännamn behöver man i princip ha en fast server stående i ett serverrum, speciellt som ändringar i DNS propagerar sig över nätet skrämmande långsamt.

Från detta kommer behovet av- och möjligheten till- en fast punkt i nätet, och ett nav materialiserar sig spontant som ett svar på detta behov – Google. Det är detta faktum som molnfetischismen döljer – min data är inte i ett abstrakt moln av olika nätverkade datorer, de är på Googles servrar. Min data är inte mer i ett »moln« än mina värdepapper på banken är det.

Så med andra ord: det enda sättet att göra slut på nätfascismen är att göra slut på klient-servertänkandet och därmed hela webben och DNS som de ser ut idag. Naturligtvis är det inte en övergång som kan ske direkt, och med största sannolikhet kommer den aldrig att avslutas.

Men även i och med det mer jämlika decentraliserade internätet kommer vi att förlora en viktig del av vår frihet, helt enkelt därför att vårt datande nu görs mycket mer socialt än tidigare. Kanske måste vi tänka om hela konceptet med fri mjukvara, och då helst på ett sätt som lutar sig mindre mot ett socialliberalt rättighetstänkande.

För vi måste komma ihåg att koden har alltid varit ett medel, inte ett mål. Det är framför allt här jag tror att Fri programvarurörelsen och Open Source-rörelsen skiljer sig, i det att den senare fokuserat just de tekniska aspekterna över de sociala och ideologiska. Tyvärr har den senares frammarsch på den förras bekostnad lett till att diskussionen om målet förs alltför sällan. Och följdaktligen har vi heller ingen lösning på webapplikationsproblemet.

Haiku och det grafiska gränssnittet

Haiku är en fri implementation av (och fortsättning på-) det ofta bortglömda operativsystemet BeOS. Det intresserar mig väldigt mycket eftersom det just nu är ett av få operativsystem som faktiskt är typ användbart (förlåt, Plan 9 9front), men som samtidigt försöker göra saker annorlunda. Och, kanske mer intressant, sammanhängande.

GNU/Linux är – skulle jag vilja påstå – det minst dåliga operativsystemet jag känner till, alla faktorer sammanvägda, men det är egentligen inte så mycket ett operativsystem som ett ekosystem av programvara. Detta har både bra och dåliga effekter, och en av de mest framträdande dåliga är att den ena handen inte vet vad den andra gör. Det finns ingen förenande tanke helt enkelt.

Efter att ha läst en lång text om Haikus inställning till sitt grafiska gränssnitt så är jag klart imponerad. Här finns uppenbarligen en tanke – något som hela jävla industrin inte verkar ha haft på evigheter. Anledningen till att varenda program nuförtiden ska ha tabbar är att GUI-utvecklarna helt har gått vilse i sina metaforer, vilket tvingar användaren till att bli en mjukvara som sorterar fönstren åt operativsystemet.

Vad är det som säger att tabbarna inte skulle kunna vara en fönsterhanterargrej? Speciellt nu som samma program gör tusen helt olika saker: dels kör det ofria mailprogrammet Gmail och ordbehandlaren WordPress, dels visar dokument i HTML-format. Det är ju två helt olika saker!

Tänk att till exempel kunna tabba ihop en debugger, en terminal och ett utvecklingsprogram, så att de får en flik var. Tänk att ha bättre kopiera och klistra in, en som faktiskt förstod vad det var för data som kopierades och klistrades in!

Problemet med att ha ett digitalt skrivbord och en digital papperskorg är nämligen mycket lika de som kommer av deras fysiska motsvarigheter: papperskorgen måste tömmas, och skrivbordet blir fullt med skräp om man inte städar det.

Mina förslag (för ett framtida önske-operativsystem) är som följer:

  • Inför ett stenhårt sammanhängande GUI-paradigm och följ det. En sån strategi (jag kommer att tänka på Apple) är helt värdelös för ofri programvara, eftersom koden är bortslösad på alla som inte gillar detta paradigm. Men om det är fri programvara så är det möjligt och t.o.m. önskvärt att samma kod används för många olika saker, eftersom det garanterar största möjliga flexibilitet och testning. Det är det vi har distribuerade versionshanteringsprogram för!
  • Baka in stöd för Unicode och alla andra såna självklarheter i operativsystemet från början.
  • Låt konstruktörerna växa upp i en låda i skogen så att de inte blir skadade av alla andra halvrumpade GUI-implementationer.
  • Läs den forskning som finns på människa-datorinteraktion.
  • Fundera jävligt noga över vilka metaforer som ska ligga till grund för operativsystemet.
  • Ha bara en jävla nivå för interaktion med systemet, alltså inte som DOS och Unix att man har en gränssnittsnivå för användaren som är jättelåg (DOS, konsolen), och en som är mycket högre (X11, gamla Windows) och som ska försöka översätta och kompromissa.
  • Bygg systemet för att hantera data – och konstruera filsystem och gränssnitt efter det.
  • Återuppväck Xerox PARC-filosofi. Se till att det går att gå direkt från symboler/objekt i datorn till koden på ett pedagogiskt sätt. Och att koden är läsbar så långt det är möjligt. Se också till att systemet tar ansvar för denna kraftfullhet med allt vad det innebär av stöd för att ångra sina ändringar och så vidare.
  • Använd konceptet med olika arbetsytor för olika uppgifter – titta på hur QubesOS gör för att omsätta det till säkerhetstänk.
  • Alla användare ska också vara programmerare, helst utan att de märker det själva.
  • Släng ut det flytande fönster-baserade GUI-paradigmet genom, öh, fönstret. Det är helt efterblivet.

Maktfördelning och mjukvarulicenser

När man köper ett program i en affär så kommer det ofta med en slutanvändarlicens, en s.k. EULA. I denna EULA brukar det stå alla möjliga villkor man måste underkasta sig för att få använda mjukvaran, t.ex. att man inte får försöka plocka isär programmet och lura ut hur det fungerar, att man bara får köra det på ett visst antal datorer och att man inte får sälja- eller låna ut det till sina kompisar.

Piratpartister riktar ofta in sin kritik mot just själva ägandet; att man bara använder mjukvaran på nåder och att ens licens när som helst kan kallas tillbaka. Att man, i korthet, inte äger det man köpt. Det är visserligen en rimlig kritik, men det blir lite bakvänt för en kommunist. Kanske borde man istället titta på vad det är i bristen på ägandet som gör det problematiskt?

Svaret på det är, helt enkelt, maktfördelningen. Som mjukvarulicenser ser ut nuförtiden så innebär de en enorm mängd inflytande åt utvecklarna/utgivarna och nästan ingen alls åt användarna. Det enda användarna kan göra är att stanna kvar i sin roll som just lydiga användare; de får inte hacka, inte förändra, inte utveckla, inte lära sig.

Detta har lett till två nya grenar av mjukvarulicenser som kan beskrivas som mer frihetliga. Båda två samlas under samma paraplybegrepp, »Open Source« eller »Fri programvara« (där jag föredrar det senare av bl.a. historiska- och lingvistiska skäl). Båda dessa grenar har med utvecklande att göra — man behöver alltså inte acceptera någon licens för att bara använda programvaran.

Den ena licenstypen brukar kallas för »tillåtande« licenser; de tillåter i princip användaren av mjukvaran att göra vad hen vill med den, och låter det stanna där. Ibland finns det även en klausul om att upphovspersonerna inte vill att deras namn ska användas i reklamsyften, men det är ungefär så långt det går. Exempel på tillåtande licenser är BSD-, Apache- och MIT-licenserna.

Den andra licenstypen kallas för »copyleft« och är mer invecklad. I princip går de ut på att vända upphovsrätten mot sig själv och skriva licenserna på ett sådant sätt att de »smittar«. De går vanligen ut på att det är fritt att använda mjukvaran till vad man vill, och att det är fritt att kopiera den som man vill. Så långt är båda licenstyperna i princip identiska. Skillnaden är att copyleft-licenser även bestämmer att eventuell framtida mjukvara baserad på ett copyleft-program måste släppas under samma licens. Exempel på copyleft-licenser är GPL och AGPL.

Ett klassiskt argument för BSD-licenser och mot copyleft-licenser är att de ger användaren (läs: utvecklaren) mer frihet, nämligen friheten att ta programkoden och släppa den, modifierad eller inte, som ett ofritt program.1 Men det bygger på ett synsätt där det är normalt att all makt ligger hos utvecklaren. Man skulle ju lika väl kunna se det som att licensen tryggar andra användares rätt (frihet) att använda även modifierade versioner av programmet som de vill.

Men man vill gärna ställa sig frågan: kan möjligheten att förbjuda verkligen kallas »tillåtande«?

  1. Detta har hänt i verkligheten. T.ex. har WINE, som används för att köra Windowsprogram på andra plattformar, släppts ofritt under namnet Cedega. Projektet har sedan dess bytt licens. []