2018-09-17

Vad Linux behöver för att lyckas på skrivbordet

Det har skrivits åtskilliga analyser om varför Linux (ännu) inte lyckats på på “skrivbordet”, det vill säga - i skrivbordsdatorer, laptops och liknande.

De flesta analyser jag läst inom området fokuserar på det tekniska, exempelvis ur denna bloggpost av Miguel de Icaza från slutet på augusti 2012:

In my opinion, the problem with Linux on the Desktop is rooted in the developer culture that was created around it.

Linus, despite being a low-level kernel guy, set the tone for our community years ago when he dismissed binary compatibility for device drivers. The kernel people might have some valid reasons for it, and might have forced the industry to play by their rules, but the Desktop people did not have the power that the kernel people did. But we did keep the attitude.

The attitude of our community was one of engineering excellence: we do not want deprecated code in our source trees, we do not want to keep broken designs around, we want pure and beautiful designs and we want to eliminate all traces of bad or poorly implemented ideas from our source code trees.

And we did.

We deprecated APIs, because there was a better way. We removed functionality because “that approach is broken”, for degrees of broken from “it is a security hole” all the way to “it does not conform to the new style we are using”.

We replaced core subsystems in the operating system, with poor transitions paths. We introduced compatibility layers that were not really compatible, nor were they maintained. When faced with “this does not work”, the community response was usually “you are doing it wrong”.

Tekniken var det som “dödade” Linux på skrivbordet, inget annat. Det var åtminstone lärdomen som de Icaza drog för sex år sedan. Inget konstigt med det egentligen - Apple var 11-12 år in i det som numera heter macOS men på den tiden hette Mac OS X, en Unix på skrivbordet som inte bara var vacker utan också var så bra så den attraherade över Linuxhackers och utvecklare från alla läger. Problemet med det sätt Linuxutvecklarna hade arbetat utifrån, enligt de Icaza, låg i bristen på bakåtkompatiblitet, i hur Linux och dess grafiska användarmiljöer hanterade äldre versioner av såväl applikationer som bibliotek och andra funktioner i operativsystemet.

När vi sakta men säkert närmar oss slutet på 2018 så kan jag rapportera att saker och ting ser ljusare ut. Nyckeln till detta heter i mitt tycke inte förbättrad bakåtkompatiblitet, vassare utvecklingsverktyg eller snyggare källkod. Nej, nyckeln stavas standardisering. Efter att en rad olika fönsterhanterare kommit och gått så har vi i dagsläget endast två stora som fajtas om användarna: Gnome och KDE. Försöket med Unity blev tyvärr en flopp men det var ett allvarligt försök att ta fram en grafisk användarmiljö som kunde, i brist på bättre ordvitsar, förena dem alla och försöka skapa en standard. Ordet standard är nyckeln här, för om det är något som grafiska användarmiljöer i Linux har saknat i alla år så är det ju en standard - en guide, ett ramverk. Med andra ord, precis det som Apple haft för MacOS och senare Mac OS X och macOS, det vill säga: HIG. Human Interface Guidelines - Apples minst sagt stränga instruktioner, eller i praktiken regelverk, om hur en applikation i macOS ska se ut, uppföra sig och vilka funktioner som hamnar var.

Det är tack vare HIG som alla applikationer på en Mac har nästintill identiska menyer vilket gör att det är lätt att hitta i en applikation du kanske aldrig använt tidigare. Om du använt Microsoft Windows så har du säkert slagits över hur vissa applikationer ser ut som något katten släpat in, även om samma applikation är 100 procent certifierad för att fungera på Windows 10. Anledningen är enkel - Microsoft har visserligen riktlinjer för hur en applikation ska se ut när man installerar den i Windows 10 men de är inte på något sätt tvingande och har aldrig varit det heller varför många applikationer under Windows alltid sett ut som det där katten släpat in - användarna har aldrig behövt bry sig så varför börja nu?

Med de senaste versionerna av Gnome som jag kört så tycker jag mig se försökt till att standardisera saker och ting. Det finns en applikationsbutik och de inställningar man kan göra i Gnome för exempelvis e-postkonton används faktiskt av vissa applikationer i systemet. Många applikationer ser fortfarande ut som de släpats genom en köttkvarn och sen tejpats ihop med gaffatejp men saker och ting blir faktiskt bättre. Sakta men säkert, som det brukar heta.

För att Linux verkligen ska bli framgångsrikt på skrivbordet måste man ta bort de valmöjligheter som många har idag. Inget mer KDE, inget i3, inget Xfce, och så vidare, utan bara en enda standard: Gnome. Ska Linux lyckas på skrivbordet kan det inte finnas 40-50 olika fönsterhanterare - det är en valmöjlighet som endast skadeskjuter Linux skrivbordsambitioner ytterligare.

Linuxvärlden måste helt enkelt bli mer som Apple - mindre valfrihet och mer diktatoriskt. Om Linuxvärlden sedan anser att det är ett rimligt offer att göra för att få en bättre och mer hållbar grafisk skrivbordsmiljö med Linux under skalet återstår väl att se men jag tror inte Linuxfolket kommer vilja gå den vägen, och en del av mig är tacksam för det.


2018-09-16

Proxmox-kluster med Fibre Channel

Kommer man från en virtualiseringsplattform som bestått av VMware ESXi, Hyper-V och liknande kommersiella plattformar så är det sällan ett problem att bygga ett virtualiseringskluster med delad lagring som innefattar Fibre Channel. iSCSI och NFS är överlag inte ett problem med Proxmox men Fibre Channel kan innebära större utmaningar än det rimligen borde vara.

Nyckeln till att få det hela att fungera är egentligen flera dito. Under VMware ESXi kan man exempelvis bara lägga till ett Fibre Channel-LUN på alla servrar som ska hantera virtuella maskiner och sen löser sig resten automatiskt. Har du endast en enda Proxmox-server kan du helt enkelt formattera enheten som vilken hårddisk som helst och sen lägga till den i Proxmox, men har du flera servrar som ska agera i ett kluster med failover-funktion krävs det lite mer. Denna guide förutsätter att du redan satt upp ditt kluster med allt vad det innebär.

Det finns ett stort aber med att köra den här typen av lagring i Proxmox. Till skillnad från NFS så tycks Proxmox åtminstone med mitt lätt uråldriga SAN (E610F från Promise) inte klara av att låta flera medlemmar i ett kluster komma åt och använda Fibre Channel SAN:et samtidigt via Fibre Channel. Istället är det en av medlemmarna i klustret som jobbar mot ett LUN i SAN:et via Fibre Channel och sedan delar ut detta LUN till andra medlemmar i klustret. Det finns ett stort aber i detta sammanhang och det är att utdelningen inte sker via Fibre Channel utan via ethernet, antingen i form av ett bond eller en enstaka länk. Det är viktigt att komma ihåg detta eftersom prestandan mot Fibre Channel LUN:et för de andra medlemmarna i klustret inte kommer bli optimal, men det fungerar åtminstone hjälpligt. En kommersiell virtualiseringsplattform som tidigare nämnda VMware ESXi klarar av detta utan omsvep och det hade onekligen varit önskvärt om Proxmox gjorde det samma. Jag har ännu inte testat kombinationen Proxmox och iSCSI men jag misstänker att det fungerar på samma sätt som med Fibre Channel om man har ett kluster.

Under Proxmox måste man först och främst skapa en volym med LVM på den enhet som ditt FC-lun presenterar för dig.

sgdisk -N 1 /dev/sdXX

Därefter är det dags att göra iordning LUN:et för LVM:

pvcreate –metadatasize 250k -y -ff /dev/sdXX

Slutligen är det dags att skapa den logiska volymen i LVM:

lvcreate –name namn –size XXXXG namn

Exempelvis skapade jag en volym på 4,6 terabyte med namnet vmdata01 i volymgruppen vmdata:

lvcreate –name vmdata01 –size 4600G vmdata

I det här läget är det för det mesta inga problem att lägga till volymen i Proxmox-klustret i det här läget men det finns två saker som återstår för att detta ska fungera.

Det första är att installera multipath-funktionaliteten:

apt-get install multipath-tools -y

Därefter startar du det hela och kollar om topologin för multipath ser bra ut:

multipath -ll

Om din volym inte syns i klustret eller inte kan läggas till får du göra det manuellt:

pvesm add lvm vmdata01 –vgname vmdata01

Det sista du kan behöva göra är att starta om den eller de servrar i klustret som är anslutna till ditt SAN via Fibre Channel.

Efter detta borde du kunna migrera virtuella gäster mellan dina servrar i klustret utan problem.


2018-08-15

Välkommen till Unixpro

Unix. Ett laddat ord med en lång historia där allt från män med korrekt skäggväxt till hackers, programmerare och systemadministratörer i alla åldrar ägnat årtionden åt att upptäcka, lära och bemästra en operativsystemsfilosofi som, om sanningen ska fram, är väldigt vänlig även om Unix, som det berömda talesättet stipulerar, är en aning petig med vem dess vänner egentligen är.

Unixpro är bloggen för dig som använder någon form av Unix eller Linux. Med Unix avses allt från FreeBSD, OpenBSD, macOS, Solaris, AIX, Irix eller annan variant som helt eller delvis bygger på Unix och till Linux där Unixpro företrädesvis skriver om CentOS, Ubuntu och Alpine. Unixpro avhandlar inte bara dessa operativsystem utan också vad du kan göra med dem i form av applikationer och lösningar som virtualisering och lagring.

Unixpro kom till efter att sajtens skapare under 14 år skrev och publicerade bloggen Macpro, vars mer proffsinriktade kostym blev allt snävare i takt med att Apple övergick till att satsa mer på mobila produkter och istället för att bevara det som gjorde Mac OS X, senare macOS, unikt övergick till att snuttifiera plattformen allt mer. Unixpro kommer ändå att skriva om macOS då den har tydliga arv från BSD-världen under skalet och för att man, emellanåt, faktiskt kan göra intressanta saker med denna plattform.

Unixpro kommer företrädesvis också avhandla mobila plattformar som Android och iOS och varianter av det senare som tvOS och watchOS.

Innehållet på Unixpro kommer vara allt från nyheter till guider, tips och tricks. Förhoppningsvis hittar du något här som du gillar.

Varmt välkommen!