Dagen har blivit lite sisådär. Det började bra med att jag fick en tid hos en av dem som tatuerar mig tidigt (nu på torsdag). Sedan fick jag reda på att jag ej fått lägenheten jag var och kollade på förra veckan. Vilket är mindre bra. Nu ska vi se om jag har tur att få en annan lägenhet som eventuellt är på gång. Antagligen inte, men den tur jag brukar ha.

Blö.

Jag hade för några år sedan en Nokia N900, mycket för jag ville ha en renodlad linuxmobiltelefon. Sedan  blev jag intresserad av en Samsung Galaxy Note och införskaffade mig en sådan när mitt abonnemang gick ut. Den var stor och vit, två saker som passade in på mina preferenser. När jag väl haft min Note ett tag kom tanken om Android och Linux upp, de flesta vet att Android har en Linuxkärna (väldigt bra). Men där stannar det faktiskt, enligt mig. Mig veterligen finns det inte mycket öppen källkod till Android, de flesta appar har antingen reklam (och varför släppa dessa appar fria när programmerare enbart skulle ta bort den funktionen och därmed göra utvecklarna fattiga?), eller betalappar. Värt att notera är att det finns applikationer som bygger på öppen källkod, men de flesta gör det inte.

Jag funderade länge och visste att min syster var lite sisådär intresserad av sin iPhone och skulle kunna tänka sig att sälja den. Jag blev då ganska intresserad, faktiskt. Främst för båda operativsystemen innehåller så mycket proprietär kod vilket skulle göra att det känns lite strunt samma vilket system man använde. När vi väl skulle komma till skott så visade det sig att hennes telefon var operatörslåst till Felia (företag sysslar tydligen med sådant 2013). Nu i efterhand är jag dock tacksam för det. Hon har i detta nu min telefon på lån, men kommer med största sannolikhet att köpa den.

Jag beslöt mig för att gå in på blocket.se för att se om det fanns någon billig N900 att köpa, och hittade en för 600 kronor. Till det priset var jag tvungen att köpa en. Nu i efterhand ångrar jag inte mitt köp. Det känns helt enkelt bättre, och det fysiska tangentbordet har jag verkligen saknat. Den här telefonen kommer jag nu att ha tills något nytt kommer ut på marknaden. Tizen, Sailfish OS, Firefox OS och Ubuntu är bara några som verkar intressanta och värda att hålla utkik efter.

Det finns mängder med gigantiska communitys för Android, vilket är en av dess styrkor. Till Maemo (operativsystemet N900 använder sig utav) finns det ett också. Det är inte speciellt stort, men det finns engagerade utvecklare som fortfarande håller igång, även om telefonen är från 2009. Vad dessa gör är bland annat att fixa buggar, och att försöka att ersätta den någorlunda lilla mängd proprietär kod som finns, med öppen källkod. Kolla bara in CSSU. Jag önskar jag kunde lära mig att programmera, då skulle jag försöka engagera mig i det också, men jag får nöja mig med att bruka deras verk.

Så. Vad kommer jag att sakna hos Android då? Självfallet, dess utbud av appar. Främst de appar jag har köpt, men också Swedbanks app, och appen för kollektivtrafiken i det län jag bor i (skulle jag någon gång få för mig att börja programmera skulle jag försöka göra en sådan till Maemo).

Tack och hej.

Kommer du från Windows är du antagligen väl bekant med att trycka på bakåtknappen om du vill gå… bakåt. Likväl är du van vid att trycka på scrollen för att snabbt förflyta dig när du besöker någon hemsida. Dessvärre är inget av detta standard när du installerar Firefox på en datorn med Linux (mig veterligen åtminstone), konstigt nog. Som tur är så är det enkelt att fixa.

Öppna en ny flik -> skriv about:config (lova att du är försiktig!!) Sedan skriver du in följande:
general.autoScroll vilket du senare ändrar till true. Detta gör att du kan trycka på scrollen (eller middle click) för att scrolla snabbare.
browser.backspace_action ändrar du till 0. Vilket gör det möjligt att gå bakåt med bakåtknappen.

I recently ordered a new batch of Arch Linux laptop stickers. However, because they have been selling so well, I ordered three times the number that I usually stock! I was able to get a much better price by ordering a larger bulk quantity and I’m excited to pass the savings onto all the loyal Arch Linux users out there.

The price for a single Arch Linux Sticker has dropped from $1.90 to $1.35. The savings are even greater if you purchase in bulk; you can now order 20 stickers for 80 cents a piece!

Head over to schwag.archlinux.ca to order your stickers and other Arch Linux goodies. If you’re interested in more generic Arch Linux branded items, check out our Zazzle shop.

Det finns många snygga teman till Linux, dessvärre finns det snygga gtk2-teman som är något äldre, och därför inte har någon gtk3 alls, eller för en äldre version av gtk3. gtk-candido-engine, jag tittar på dig!

I alla fall, vad jag har gjort är att skapa en egen mapp i .themes (döp den till vad du vill), sedan lägger du in de teman du vill ha (gtk2 och gtk3). Sedan går du in i inställningar och väljer du det namn du skrev när du skapade mappen. Då borde du ha de teman du valde. I mitt fall valde jag Candido-candy och Zukiwi som gtk3-tema. Helt perfekt, faktiskt. Nu slipper du installera applikationer från AUR som kompilerats med gtk2, enbart för att du valt ett tema som ej har något gtk3-tema. Smidigt, och fint!

Här kan du se det in action.

Nu har jag använt Xfce ett tag och trivs faktiskt ganska bra med det. Jag tycker dock om att experimentera så när följande tips hittades på reddit så var jag tvungen att testa. gala-bzr finns i AUR så några konstigheter är det inte.

cp /etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml

vim ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-session.xml

Leta upp xfwm4 och ersätt med gala. Spara och logga ut.

Här är en bild som kan ge ett hum om hur det kan se ut när det är färdigt.

Well as a CS student at my local community college here in Lakewood, Colorado. I noticed in my CS class that I am  the only black man in the class. I was curious how come the Open Source World did not reach out to more urban males? I have been in touch with some good people at GNOME in particular the OPW program which is for women. Now they have given me good advice to look at GSOC. Can I ask why is there not a similar program for minorities I know this may not apply to all countries. I am talking in particular the US where I am based at. I have in the past been a contributor to Fedora and Arch Linux. I would like some more feedback on any programs for CS majors like myself or even school age children from the inner-city. This is good way to spark interest in the next generation of software engineers.

From a gender equality point of view, I’d call Pycon 2013 a success, though perhaps a better word is “progress”. The gender ratio apparently doubled to 20% this year. If that continues (depending if it’s a constant, linear, or quadratic curve) we could be at parity in as little as two to three years.

Another indicator of forward momentum is that women this year were able to behave, to use a sexist term, “like women,” without fear of reprisal. That is to say, I saw makeup, heels, and skirts, and they did not seem out of place. This is not to suggest that women should or must dress up to attend conferences; the traditional vendorware is equally acceptable for all genders. However, it is progress that more women felt they had a choice in the matter and did not feel an obligation hide their physical differences. I think the fact that there was more variety among the male dress styles is also a sign of success.

The worst charges coming out of Pycon 2013 were the use of inappropriate jokes. To the best of my knowledge, there were no reports of women being harassed, assaulted, or groped during the conference. I’m not aware that this has been an issue at past Pycons either, but I think it’s a sign that the Python community is better behaved in this regard than some of her sister tech conferences.

So all in all, while it wasn’t completely successful, Pycon 2013 was a terrific step on the road to eliminating sexism and creating gender equality. Let’s make next year an equal sized step. Here are a few topics I think we, as a community, can work on to engender further progress.

I’m going to start with a couple links. Ruth Burr wrote a terrific essay titled Things You Think Aren’t Sexist, But Really Are a couple weeks ago. In summary: Men, you are instructed to go to conferences to network and interact, not to date or hook up.

Yes, you might meet the love of your life at Pycon, but don’t expect, intend, or plan for that to happen (at PyCon or anywhere). Behave professionally, and consider each woman you meet for her knowledge and intelligence, not her figure or her marital status, just as you would when interacting with a male.

Ned Batchelder, with his amazing talent for understanding and explaining problems wrote another great article on the root issues. Summarized, he says friction is inevitable, and that education is better than shunning when people make mistakes.

I started planning this article while attending Pycon this year. I had to scrap those plans after the so-memed “donglegate” fiasco. I don’t have anything to add to that discussion, but as Ned illustrated, there were many many instances of similarly inappropriate comments at Pycon. I myself made such a joke, most of my friends did so, I overheard a conference organizer say something inappropriate. This is not sexism per se, but sexual and other potentially offensive comments need to be reduced. Comments laced with sexual innuendo do not belong in a professional or a family setting, and Pycon is intended to be both.

Let’s start with interation between the genders. In her article, Ruth Burr mentioned that women can feel awkward when they interact with men because the men assume they are flirting rather than interested in the topic at hand. Many men see cleavage and assume the speaker can’t possibly know as much as them about whatever topic that is. Some girls avoid interacting with men because of this awkward sensation, and if they do, the interactions are tainted.

I had a related problem. While I comfortably talked to men of varying skill levels at Pycon, I felt uncomfortable addressing women because I was afraid of sending some vibe that I was being flirtatious. So I tended to ignore the female attendees. This is unfortunate for everyone who missed out on that potential conversation. Pycon 2014 needs to increase the interaction between the genders, not just the attendance ratios. Ladies, talk to the shy guys, they need to be taught that you aren’t that intimidating. Guys, talk to the women, they need to learn that we are interested in what they have to say about tech, and not their figures. As it stands, only the sexist guys are interacting with the women, and it makes us all look bad.

The gender ratio really fell during the developer sprints. I don’t think there were any female sprint leaders presenting projects to hack on. Worse, I’d estimate between one and two percent of the sprint attendees were women. This is a huge area for improvement. To the various diversity groups out there, please encourage your members to stay an extra day or two and attend the Pycon dev sprints. Get them involved with Open Hatch if they are unsure how to contribute to open source projects. Sprint leaders, make sure female attendees are welcome, especially if they are new coders (indeed, make all new coders welcome).

I noticed a lot of Impostor syndrome among the female attendees and speakers. Programming really is easy. The fact that you enjoy it and find it quite simple is not a sign that you don’t know the “hard stuff” and therefore you’re not a “real programmer.” Quite the reverse, in fact. It’s not necessary to apologize for your lack of knowledge if you’ve been invited to do a talk or are about to join an open source project for the first time. Find ways to build your confidence (contributing to open source and getting feedback is a great start), and start believing in your skills. Even if you don’t believe it yourself, try to project confidence in your coding abilities; it will send a much more effective signal that women are capable and here to stay. Don’t worry if you over-present yourself; faking your way through it is a great way to find out that you’re actually better than you thought!

I’d like to close with an admonishment to those people who open their articles on sexism with a discussion of their gender. These usually take one of two forms: the disclaimer and the shocker. The disclaimer is most often used by men and sounds like, “I am a privileged white male so I don’t understand what it’s like for women, but I still think I have something valid to say on this topic”. The shocker is used by both genders and sounds like, “I am a man/woman, so you’re going to be amazed that my opinion on this topic is different from other members of my gender.” Yes, it is useful to state your bias and frame of reference. However, be cautious that your purpose in doing so is to remove distortion from the lens you are applying to the discussion, not to add to it.

And now, feel free to analyze my bias in this article. I am a privileged white male from a blue-collar family. I’ve had many amazing opportunities in the tech industry. I have very little experience as the target of discrimination, outside my mental illness. My interest in feminist issues comes from my sister’s master’s degree on the subject; I proofread most of her undergraduate and graduate level essays, and gained a relatively deep understanding of the topic. I acknowledge that I am a racist, sexist jerk by culture and conditioning. Sometimes I forget to compensate for that. I find it exceptionally easy to overlook the patriarchy when it’s doing me favors, and I will never be as keenly aware of its negative impact as someone who is directly experiencing it every day.

At the two previous Pycons I’ve attended (2009 and 2012), Guido Van Rossum’s keynotes sounded bored and uninterested, even though the content was meaningful. I was actually wondering if this would be the year that he would step down from BDFL of Python. Thankfully, I was dead wrong.

Instead, he presented a highly technical and very exciting addition to the Python language. Alfredo told me this started when he took a month off between stepping down at Google and starting at DropBox. Now, when normal people take a month off, they relax or travel or visit friends and family. Not our BDFL. He writes a callback-free asynchronous event loop API and reference implementation that is expected to massively alleviate Python’s oft-maligned lack of a consistent, unhackish concurrency solution.

Let’s have more of that. What if Mr. Van Rossum could hack on Python full time? Would we see quantum progress in Python every month?

Anyone who knows about the Gittip project likely thinks they can guess where this is going. We, the people, can each tip our BDFL a few cents or dollars per week so he can focus on whatever he deems worthy. It’s safe to assume that a man who spends his vacation time drafting a new Python library would choose to work on Python full time if we funded him.

This plan is great, and I actually think that Guido could easily earn enough to quit his day job if he endorsed Gittip and invited individuals to tip him. But I’d like to discuss a different plan: Not individuals, but companies should tip Guido the maximum gittip amount as a sort of “partial salary”. At $1248 per year, most companies wouldn’t even notice this expense, and they would get a better programming language and standard library in return. The rate of accelerated development would be even higher if each of these companies chose to invest an entire salary, split between a hundred Python core and library developers. If a hundred companies chose to do this, those hundred people could work on Python full time. The language and library would improve so vastly and so rapidly that the return on investment for each of those companies would be far greater than if they had paid that same salary to a single developer working on their in-house product, full time.

It might take some convincing to justify such a strategy to these corporations. Companies tend to like to know what is happening to their money, and simply throwing a hefty developer salary at Gittip would be hard to justify. Obviously “goodwill” could support some of it, in the same way that so many companies sponsored Pycon in exchange for exposure.

Cutthroat CEOs should perhaps consider not just the value that having Guido working exclusively on Python is, but also the cost of having him work for the competition. I’m sure Box.com CEO Aaron Levie was a little nervous when he found out that the first and greatest Python programmer of all time had recently hired on at a major competitor. Perhaps Box.com can’t afford to steal Guido from Dropbox, but if all the companies currently involved in cloud storage were to tip Guido $24 per week on Gittip, this incredible programmer could be working on an open source product that directly and indirectly benefits their company rather than improving the competing product on a full-time basis.

Most of the arguments that Gittip will fail are based on the premise that not enough money can be injected into the platform to sustain full time development by open source programmers. However, if an open and caring relationship can be built such that the corporate world is also funding the system, I think it can become extremely successful. Everyone will benefit: Open source projects will improve at a rapid pace. Exceptional developers will get to pursue their passions. End users will get better products. The overall level of happiness in the world will be higher.

I would like to see a world where brilliant young software engineers are not risking their mental health (and consequently, their lives) on startup ideas in the hopes of being bought out for a few billion dollars. I would like to see a world where those engineers are not working for large corporations that have neither their employees nor their end users (but rather, their stockholders and advertisers) interests at heart. I would like to see a world where those developers can choose to invest their passion in open source products that will change the world.

Jag har svårt att bestämma mig om jag ska använda GNOME 3, DWM eller MATE. Alla är olika och har sina fördelar. Just nu använder jag dock MATE, samtidigt som jag har satt upp DWM så som jag vill ha det, ifall jag skulle få för mig att börja använda det istället. Vad finns det att skriva om MATE då? Ja, inte speciellt mycket tror jag. Gillar du GNOME 2 så kommer du att gilla MATE, gillar du snabbhet och enkelhet så kommer du att gilla MATE.

Jag verkar ha svårt att kunna lägga upp bilder just nu, så därför kan jag inte posta en skärmbild på hur det ser ut för tillfället. Vad jag dock kan göra är att förmedla det tema och de ikoner som används för tillfället.
GTK thema: Mint-themes
Ikoner:  Mint-x-icons

Tack för mig.

Efter lite tester råkade jag förstöra någonting. Wingpanel går inte längre att starta. Nåväl, jag har planer på att införskaffa mig en SSD till laptopen i vilket fall och då kommer det att krävas en ominstallation utav systemet, då kommer jag att installera allt det där igen. Tillsvidare får faktiskt GNOME funka, något jag tycker det ändå gör ganska bra. Jag har testat Cinnamon igen, men det är faktiskt inget som faller mig i smaken. MATE har jag också testat, det var snabbt och relativt stabilt men föll inte mig i smaken det heller. Av någon anledning kan jag inte installera min väldigt modifierade version av DWM, ganska skumt men samtidigt inget jag orkar lägga ner någon större energi vid, även om jag önskar att så var fallet.

Dessa tillägg har jag till GNOME, de är alla väldigt bra och fyller sin funktion:

Alternative Status Menu

Frippery Applications Menu

Media player indicator

Quit Button

Remove Accessibility

Remove Rounded Corners

User Themes

This week, I was finally able to fulfil a longstanding goal: to delete my Google account from my Android phone. This is a step in a series of progressions towards “completely” disappearing from Google’s radar. I have been comfortable with the state of my laptop, which avoids all Google spyware using ghostery to block Google analytics, disabling cookies on all Google domains, and using Startpage.com for search. I’ve dropped Google Talk in favour of a jabber server hosted by a friend. While I still actively monitor my Gmail account via IMAP, it is not my primary address and is largely only used for correspondence that is already public, such as mailing lists and Google Groups.

The three things that I have still been using Google for were:

• Maps
• Paid Apps From Google Play
• Contact Backup

I still use Google maps on occasion, though my main navigation equipment is an offline Garmin GPS device that — to the best of my knowledge — is not notifying anyone of my location at any time. I largely addressed the other two issues this past week.

I recently received my Cubieboard in the mail. It’s basically a specced up Raspberry PI. I installed Arch Linux by following the instructions at this thread.

I then set up Own Cloud by following the instructions at the Arch wiki. Once it was set up, I realized that I personally don’t have much use for calendar sync or file sharing, but that the contact backup was crucial. I didn’t want a full LAMP stack running on my little ARM processor, so I uninstalled Own Cloud and set up Radicale instead. Now my phone’s contacts are backed up and I no longer need my Google account to support that feature.

Then I was notified that AOKP, my current Android ROM of choice, had released an update. I thought “Hm, I wonder if I can get away with not installing the Google Apps package at all.”

I couldn’t. But I tried. The main issue is that there are two paid apps in my Google Play account (SwiftKey and SwipePad MoreSpace) that I do not want to live without, and do not want to purchase again from another vendor. In the case of SwipePad, I couldn’t even find another vendor. I toyed with backing up and restoring the .apk’s, but I got certificate and signing errors. I’ve read that these can be circumnavigated with Titanium Backup, but I haven’t gotten around to trying it yet.

So I installed Google apps and reluctantly activated my Google Account to install these two paid apps. Then I disabled my Google Account.

I then installed Aptoide to replace Google Play. It had recent versions of all the free apps I use on a regular basis. It looks like it will be able to supply my app needs into the future.

I have logged into my Gmail account and deleted my pre-existing contact list. This means that even if I do have to enable Google Play in the future, I will no longer be spammed with “Your friends like this app” messages. It also means Google will not be able to track my future relationships unless they are with people who use Google services.

Now if only Ghostery and Firefox would get Ghostery working on Android, I’d actually feel safe using my device!

… Install the new kernel 3.8.

Manjaro XFCE, by manjaro.org

A weekend off in the middle of winter – just perfect to test a new Linux distro. I decided on Manjaro, the new star among Arch- based Linux distros (currently ranked 15 on Distrowatch) which seems to be on the best way to become something like “Mint for Arch”.

So what does Manjaro do on top of Arch ?

The most important feature is of course the pre- configured desktop environment. Manjaro uses XFCE by default, and there are official Openbox and Cinnamon versions and a headless “Net” variant. KDE, Mate and LXDE are offered as “community editions” with a different release schedule. The 1GB XFCE image (32 Bit) has all you need for daily work, including gParted, the VLC mediaplayer, Abiword, Gnumeric and  Gimp for Office purposes, Chromium, Pidgin and Xchat for internet access, and even Steam for gaming.

The installer is text based and closely resembles the old Arch installer (those were the days …). While installing the system is not complicated, there’s certainly room for improvement if you compare the process to established end user distributions like Ubuntu, SUSE or even Fedora. The graphical package / upgrade manager Pamac handles pacman packages from a special, tested Manjaro repository which is updated regularly (usually once a week) in a rolling release model, yaourt is included for easy AUR access.

I’m not sure about the current state of things in Arch, but Majaro runs very smooth. All hardware was recognized successfully. The only changes I did are more a matter of preference, I removed pulseaudio (using gnome-alsamixer as mixer) and configured Ubuntu- style 2 finger right mouse tap by adding ‘synclient TapButton2=3 TapButton3=2′ as new startup command in the ‘Session and Startup’ settings.

Manjaro lives up to the expectation of an easy, polished and stable Linux distribution. The desktop layout with the XFCE panel on top and Plank dock at the bottom looks very clean and modern, in fact it looks like a combination of Elementary OS and Mint. The Pamac graphical package manager is the first application of that type on an Arch- based system that is actually usable. The only thing missing to take on the Mints, Ubuntus and SUSEs of the world is a graphical Installer, but there’s already one in the works.

Först och främst, se till att du har dconf-editor installerat.
Sedan:

->com->canonical->indicator->datetime. Sedan väljer du de alternativ du är intresserad av.

There is a common misconception that those people who commit suicide have made a rational decision between two options and picked the one that they thought was most suitable for them. I’ve read this many times, often in the context of, “I really miss him, but I respect his choice.”

For those of you lucky enough to have never experienced suicidal thoughts, I want to make something clear:

Suicide is not a choice. It is a compulsion.

Obviously, I can’t really speak individually for the million people a year who take their own lives, nor for the order of magnitude more that failed in their attempt. There are, in fact, reasons for a mentally healthy person to choose (perhaps even rationally) to take their own lives. However, I believe that most of the people that killed themselves last year did not have a choice.

Consider a different illness for a moment. Consider cancer. It is a horrible disease. When a patient is diagnosed with cancer, they know they may recover, or that they may die. They don’t have a choice in the matter. Many patients find reserves within them to battle the illness with every tool available to them. Others don’t. Some survive, many die. Some beat the illness for a period, only to have the disease attack them again several years later.

In the case of cancer deaths, the cells in the human body turn on the victim to the point that it can no longer support that body’s vital systems.

Contrary to popular belief, mental illness works in much the same way. Instead of cells, it is the patient’s brain that turns on them. Their thoughts attack them repeatedly and incessantly until, eventually, they are compelled to destroy the body that houses them. Suicide is the result of an untreated psychological cancer.

Suicide ultimately arrives when the victim believes they do not have a choice. It becomes the only option. Suicidal thoughts begin as general thoughts about death. This leads to thoughts about the patient’s own death.They becomes obsessed, and begin to think about ways to actualize one or more of these scenarios. What options do they have, what tools can they use? Next, they are compelled to pick a time. If nothing changes, the time comes, and they die.

I speak from experience. Suicidal thoughts were my constant companion for twenty years, starting at the tender age of eight. At various times, I have reached the point where I believed I had no other options. I chose dates for my death. Luckily, phrases like, “I’d rather see you institutionalized than dead,” or “Do you need to be hospitalized” helped me realize there was something I hadn’t tried yet. I survived. At the moment, I am in remission, and I am optimistic that my “cancer” will not return.

So now, when I hear someone say, “It’s hard to deal with, but I respect her choice,” I hear the truth: “I am pretending she had a choice rather than admit that I didn’t give them the choice she needed.” Saying a suicide case had a choice is as insulting to their memory as suggesting that a cancer victim should have chosen to fight harder or a rape victim should have dressed differently.

When I use py.test, I often rely on the -k switch to swiftly select the test I want to run. Instead of having to type the full module, class, and test path as is required with unittest and nose, I can just type a few characters that uniquely match the name of the test.

For example, if I have a test file containing methods test_basic_clone and test_basic_clone_notes, I can run the latter test simply by calling py.test -k clone_no.

However, I often create multiple tests that have similar names. This can make it difficult to run just one test if the test name is a prefix of a longer test name. If I want to run just test_basic_clone, any substring will also be a substring of the test_basic_clone_notes test, and both tests are matched by -k.

Since pytest version 2.3.4, the -k keyword supports expressions. So I can build an expression like this:

py.test -k "basic_clone and not notes"

This selects all tests matching “basic_clone”, then excludes any containing the word “notes”. Thus, I run only the test I’m interested in without having to fix my crappy naming scheme. It’s more typing than is normally the case, but is still less cognitive load than trying to remember what module and class I’m editing and constructing a selector based on those attributes.

Kan man tänka sig vad tiden går fort ibland. Detta skall firas med lite kaffe, så här på kvällskvisten.

Nu till något helt annat. Jag har efter en del arbete fått ett par indicators att funka med Pantheon Shell. Som ni ser har jag en indikator jag gärna skulle vilja bli av med, dessvärre verkar den andra (för nätverket alltså) försvinna också. När jag känner mig färdig kanske jag kommer skriva hur jag gjorde för att få det så bra som det är möjligt på en installation med Arch Linux. Indicator-me funkar dock inte, skulle någon få det att kompilera skulle jag tacksamt ta emot hjälp.

I had a strange conversation with my classmate today in my Red Had System Administration class. It kind of left me speechless. The conversation wasn’t very well guided, but the main topics were software freedom and user control.

I brought up the topic of smart phones, and why having something like Linux on a phone would be so desirable. With my Nokia N900 and Maemo, I pretty much have just that. I also have control. Every Nokia N900 comes unlocked (I can use it with any SIM card), with root privileges (I have admin control anywhere in the filesystem), able to be rooted (any OS can be installed or reinstalled), and any application can be installed on it using the default package manager, apt (the same that is used by Debian GNU / Linux).

I brought up this topic so my classmate could help me think of reasons why Linux on a phone would be great. Instead, I discovered that his opinion is the exact opposite of mine: It’s much much better for the owner of the phone to have less control. This will prevent the user from breaking it.

He went on and on with this point. I wish I could describe it better, but the problem is I have a really hard time understanding it.

Here is my point: There’s no difference in stability between an iPhone that is locked down (like it currently is) and an iPhone that gives me complete control (to install applications from any source, access to the filesystem…). If I choose to do something with my phone that is not supported by Apple, then yes, I may break it, but at least it’s my choice. Instead, Apple worked very hard to add extra software and extra hardware that will prevent me from doing anything of the sort. They did extra work to give me less control of the electronic device that I own.

My classmate’s opinion surprised me. I mean, it really surprised me. I’m used to talking to people who care about software freedom, at least a little bit. I’m also used to talking to people who don’t know or don’t care about software freedom. But I can’t think of a time I’ve ever met someone who was so much against the idea of software freedom.

I was also extremely surprised to find out how little he and my other classmates understood about free software, as described by the Free Software Foundation. I mean, we’re in a Red Hat class, so I just kind of assumed everyone knew. I think I assumed incorrectly.

This is not yet another git vs Mercurial debate. I admit bias towards git, which I use whenever I have a choice. This is most of the time now that gitifyhg is awesome. However, I have been using Mercurial for my day job for about a year. I am more familiar with Mercurial and it’s extensions than many developers who prefer it. I consider myself an advanced git user (not an expert) and an intermediate Mercurial user.

I therefore have the background to claim that Mercurial and git are equally capable. Mercurial doesn’t have certain features of git that I miss, but those features are implementable with development time. Sometimes git’s interface isn’t as easy to use or teach as I would like, but aliases and projects like git extras alleviate this issue.

This article is about philosophy, not technology. Mercurial’s documentation, mailing lists, and stack overflow questions are littered with dire warnings that extensions that rewrite history are dangerous and best avoided. Git, on the other hand, takes a “consenting adults” approach to history rewriting. While it acknowledges that rewriting history can be dangerous and should be avoided in certain circumstances, it also allows the coder to choose when and how to apply this rule.

To avoid comparing the two systems, I’ll refer to the two styles as “permanent history” and “mutable history”. Both git and Mercurial are fully capable of maintaining both styles of history. However, Mercurial users tend to prefer “permanent,” while git users typically adopt a “mutable” approach.

The permanent history philosophy emphasizes that a changeset cannot be altered once it has been committed. It is important to record exactly what state the repository was in when the commit was made. If that state is not acceptable, then a new commit is made to correct it. Future readers of the history in question will see that a commit was made and that later, it was amended in another commit. Permanent history is analogous to a captain’s log or accountant’s general journal. Every action should be recorded separately.

The goal of committing in the permanent history paradigm is to record a specific state of the repository.

The mutable history philosophy, in contrast, sees changesets as individual paragraphs in a living story. It can and should be edited to ensure it tells the story as effectively and coherently as possible. Each changeset should have a topic sentence (the commit message) and supporting sentences (the patch). When a commit is initially made, the book is never assumed to be in the final draft that will go to the publisher.

The goal of committing in the mutable history paradigm is to record a related set of changes.

The different stages of code history

There are several stages that changesets go through as a program is written. These stages are perceived differently by the two styles.

1. Working directory changes have not yet been committed.
2. Local changesets have been committed but not yet pushed to any public repository.
3. Public changesets have been published to a public repository and are available to other coders.

The working directory stage is treated identically by the two philosophies. If it hasn’t been committed, both styles have an “anything goes” attitude. If you screw something up and fix it, you are not expected to commit the bad code for posterity. If you leave a debugging statement in the code but catch it in a git|hg diff command, just delete it before committing. If your tests aren’t passing during the uncommitted changes stage, edit the files to make sure they do pass.

The attitudes diverge slightly when it is time to commit the changes in the working directory. Neither style requires committing all of the changes that are in the working directory. For example, if you edit a test that is not related to the feature you are about to commit, you can separate the two diverse changes into separate commits. However, this practice is more common in mutable history circles than permanent, largely because permanent history coders want to record the current state of the repository while mutable history followers are focusing on related changes.

The two histories have polar opposite beliefs about the local changeset stage. Permanent history maintains that a committed changeset should not be altered in any way. Some proponents may allow amending or rolling back the most recent commit, provided it has not been pushed publicly. They frown upon editing the “second last” or earlier commits, even if they haven’t been published.

Mutable history, on the other hand, takes the same “anything goes” approach that applies to the working directory stage. If changes have never been pushed publicly, then the mutable historian will comfortably rearrange and reorder them, move patch hunks from one changeset to another, or squash relevant commits together.

Permanent history fans may be surprised to learn that their philosophy on public commits is the same as mutable history’s. Once a commit has been pushed to the permanent public repository, both philosophies consider that it should not be changed, ever. If mutable history is likened to writing a story with coherent chapters, then public commits are like a published book. Once it has been published, the book should not be altered.

Let me reiterate: altering permanent published history is considered a Bad Thing by both philosophies.

There is a fourth stage available in the mutable style that permanent history does not allow. This “temporary public” stage lies between the local changesets and public changesets phases. At this stage, other people can see your changesets before they are moved into permanent public history. They may be rearranged and edited as if they are local history, but there must be agreement between all viewers that this section of history is still considered mutable. This is akin to sharing a draft of the book with a proofreader or copy-editor before it is published.

The source code for git itself is managed in this way, as discussed in maintain-git.txt. While it contains permanent public branches that canot be altered, it also describes a “pu” branch that is temporary public. This branch is used to share the state of upcoming changesets; other developers can provide feedback, not only on the quality of the code, but also on the quality of individual patches, commit messages, and ordering.

History Is Communication

There are several reasons to maintain code history. Some examples include:

1. Preserve a record of past state in case you need to return to it.
2. Compare two versions of a code base and to find the specific code that introduced a new bug.
3. Concurrent development via patching and merging is virtually impossible without it.

However, the primary purpose of code history is to communicate. Each changeset implicitly communicates that the developer had some reason to take a snapshot of the repository at that time. It communicates exactly what the state of the repository was when the snapshot was taken, and is even able to communicate what changed between that snapshot and the previous one. The commit message describes these changes in English, preferably with a one line summary followed by a complete description of what changed and why.

While the two ideologies agree that history is extremely useful for communication, mutable and permanent history disagree as to what should be communicated.

Permanent history’s main purpose is to communicate “honestly” what happened, for all posterity to see. Each snapshot shows exactly what occurred in the repository. Two developers created different changesets in parallel and then at some specified point, they merged them. Someone forgot to delete a debugging statement and made a second commit to fix it.

Mutable history prefers to communicate “effectively”. The goal is to make local changesets as readable as possible before pushing them. Each changeset ideally contains a single related set of changes. Related changesets are further grouped together on individual branches. If this is not the case, they are modified or moved before being made public.

If you catch a problem in mutable history after committing but before pushing publicly, fix the commit. If two distinct changesets actually communicate a single idea, squash them together. If a single changeset contains two ideas, split them apart or move one to a different branch so the current one only contains cogent changes.

The permanent history crowd suggests that this rewriting of local changes before they are pushed is dishonest, or lying. However, it is easy to lie at the working directory stage in the permanent history paradigm. If you run an hg|git diff and notice that you forgot to delete a debugging statement committing, then it is perfectly acceptable to delete that line and “lie” about having forgotten it.

If they truly wanted to record what “honestly” occurred, permanent history tools would track every single change at the text editor or IDE level.

I think we all agree that this is ridiculous. In truth, permanent history shares mutable history’s desire to have clean, communicative commits. The primary difference is deciding when it’s “too late” to change them. In permanent history, once committed, you can’t change it. In mutable history, you can and should change it up until the point it is pushed to a permanent public repository.

The ability to change history before pushing allows the developer to separate the two distinct tasks of “coding” and “organizing”. Often, when coding, we encounter a separate issue that needs to be addressed, a missing feature, a bug, documentation that needs writing. In strict permanent history paradigm, your only “honest” option is to commit both features in a single changeset. However, permanent history rules are relaxed before the first commit has been made, so two other available options are:

• shelve/stash the existing changes, write and commit the second feature, and then unshelve/stash apply
• write the two distinct features in the same working directory and use git’s index or Mercurial’s crecord extension to commit them as separate patches.

These options are commonly used by mutable history developers, but they also have another option: Commit the two features and continue coding. Then reorganize or split the changesets into a sensible series of commits appropriate to good communication before pushing the features to a permanent public repository.

To create clean, well-ordered commits, the permanent history style demands that we think about one thing at a time and decide what the most relevant history communication path is before we start coding.

The mutable history style understands that programming doesn’t work this way. It is common and acceptable to begin work on one feature and discover a bad comment or FIXME you had forgotten and perform a psychological context switch to work on that.

One of my colleagues once informed me that “Mercurial is for people who don’t need to hide their mistakes.” This is bullshit for two reasons. First, Mercurial, like git, is perfectly capable of hiding mistakes. It’s easy to edit local unpublished changesets in Mercurial before pushing them live. There are numerous extensions — both third party and built in — that allow this kind of operation.

Second, this statement deliberately misrepresents the purpose of history rewriting. We don’t rewrite history to hide our mistakes. We do it for the benefit of future readers of our git|hg log. Reorganizing history when we write it greatly reduces the cognitive overhead for readers trying to understand what we did and why. History, like code, is meant to be read more often than it is written. Crafting it before pushing it publicly eases the amount of work for future readers of that history.

It is difficult to understand a series of cumulative changesets that keep undoing themselves or refactor large sections of code. It is better to order these changesets such that they make sense. I’m not saying that only the final product should be committed, if other changesets are able to communicate useful information. There are legitimate reasons, regardless of history ideology, to record mistakes in the permanent record of the repository. If the mistake has already been pushed publicly, the best thing to do is admit that you did not communicate as effectively as you had intended and make a new changeset to fix the problem. This is akin to providing an errata to a published book.

Another good reason is to record that some experiment you attempted was a failure. Perhaps it made the system unbearably slow or it arbitrarily deletes data. These commits can live in a branch in permanent history, forever documenting that this experiment was attempted, that it failed (so people don’t waste time trying it again), and how it failed (in case someone else wants to improve upon your design). Neither philosophy advocates the hiding of this kind of mistake. However, mutable history does expect that the failed commits be well ordered with commit messages that effectively communicate what you did and what went wrong.

History is a form of documentation. Like any documentation, it should be well-crafted and report the evolution of the system effectively. For example, one of the best early pieces of advice I received when I started using git (and inadvertantly learned the mutable history philosophy) is to “never use the word ‘and’ in a commit message.” The word “and” is a sign that you are trying to communicate two different ideas or changes in a single changeset.

There are other motivators for this piece of advice in addition to disseminating useful information. If you ever want to revert certain related changes, it is easier to do so if those changes exist in a single patch or consecutive set of patches. There is no need to extract the changes that you want to keep from combined snapshots. Both DVCS’s provide commands to trivially reverse earlier changesets, but this is only useful if the changesets contain only the idea you wish to reverse. It also eases communication when a commit message says “reverse the changes from revision X,” compared to “reverse some of the changes that do this and this as committed in revision X, but allow the lines that perform an unrelated operation alone.”

Further, if you want to apply an individual set of changes to a different branch of the project without merging an entire branch, it is a trifling matter if those changes are part of a single coherent, cohesive, consecutive set of patches.

Finally, if you don’t have write access to a project, single idea changesets make it easy for the person who is integrating your patches to see what you did and what you intended. Mutable history integrators will generally reject your patches if they do not communicate effectively. You are unlikely to ever get write access to an upstream project (if it follows the mutable history paradigm) if you do not prove that you adhere to the single concept per changeset guideline.

Admittedly, it takes more effort to alter history than to just take a snapshot when you feel the code is in a semi-acceptable state or you want to have a backup available. This effort has a huge long-term payoff. When people say that they don’t care about maintaining clean history, I get the same sense of distaste as “I don’t bother with writing tests” or “I tend to put documentation off to the last minute”. Not maintaining clean history is a sign of a lazy developer. You may be saving yourself time by just committing, but you are adding overhead to everyone who ever has to interpret your commit history, including yourself.

Code Review

Code review is an extremely useful tool for improving the state of a source code repository. It’s a simple concept: other members of the team review each changeset and make suggestions for future improvement.

Reviewers using the permanent history philosophy can improve the quality of the future codebase, but they cannot suggest improvements to patches already under review. They do not have an opportunity to improve the communication quality of those patches if they have been pushed publicly, which is normally the case if you want to share patches for review.

The mutable history style changes the point at which modifications are not allowed from “in the local directory” to “publicly pushed to the permanent repository”. Code can be pushed to a temporary public location for review purposes. Other team members can review it and comment on the quality, not only of the code, but also of the individual changesets. Once review is completed, and any suggestions integrated into the change history, the temporary repository can be safely deleted.

Thus, the code review phase becomes more than a review of the code, it is also a patch review, a history review. Code review gives other developers the chance to say, “This patch could communicate more effectively if…”.

Incremental Merging

The most dangerous moments in version control occur when two different branches of development that touch overlapping pieces of code have to be merged.Someone has to figure out what the two original sets of changes did and then figure out what the combined code has to do to accommodate both ideas. If the branches have been divergent for a long period of time, this job is nearly as difficult as rewriting both features entirely from scratch.

This is compounded by the fact that normally, the two different branches were written by different developers. While the person doing the merge may be intimately familiar with their own work, they have to become just as well-versed in the alternate branch before they can merge it safely.

Worse, all of these changes get combined into a large “merge commit” that basically includes the entire modified history of the two feature branches squished into a single gigantic diff. This is horrible for communication. If just one line of code was inappropriately merged, it becomes a nightmare to answer the question, “why did this work on the feature branch but fail after the merge”?

In the permanent history paradigm, it is common to attempt to alleviate this problem by merging frequently. This way, a smaller subset of changes can be covered in each merge. Unfortunately, this is a terrific way to introduce malicous or erronious changes into the history. People tend to assume merge commits “did the right thing” and don’t review them as closely as the patches being merged.

Moreover, the history becomes much less readable as these unnecessary merge commits clutter up the intention of both feature branches. Such commits do not serve any communication purpose other than, “the developer of this branch was afraid that divergent changes would be too hard to merge at a later, more appropriate time.”

The cognitive overhead is greatly reduced in the mutable history paradigm. Mutable history encourages rebasing over unnecessary merging. Instead of merging two branches of commits, rebasing makes one branch appear linearly after another branch. When rebased, the branch contains a series of commits that make sense in a linear order with no confusing merges in the history.

When you rebases a branch, each individual changeset is applied against the upstream branch, one at a time. Because the changesets contain small unit of changes, they are less likely to conflict, and therefore apply cleanly. When there is a conflict, it is easier to tell (from both the commit message and the code) how the code needs to be written to apply that changeset against new changes. This “one change at a time” process is much easier to apply than a single large merge commit. In addition, if you have previously rebased a branch and reordered commits for optimal communication, you will find that future merges or rebases onto other branches are even easier.

This means that, compared to a merge, you do not need to be as intimate with upstream changes from other developers. You figure out how you would have written each of your own changeset if you had been applying them directly to the upstream branch. This is not nearly so mentally fatiguing as trying to unravel two parallel sets of changes a la “ok, they did this, and I did this so I need to do this to get things back into a sane state”.

While I am avoiding a git vs Mercurial debate here, I’d like to point out that the various Mercurial utilities for rebasing and history editing are not very effective as compared to git’s tools. The rebase extesion, histedit, Mercurial queues, and pbranch all do the job, but they require more effort than in git. They don’t have git’s famous rerere functionality, they have potential to lose or obliterate history altogether, and they are neither as well integrated nor maintained as git’s tools. I do not say this to convince you to switch to git, but to point out that if you have tried these tools and found them lacking, it is not because the concept of rebasing and mutable history is a bad thing, but because the tools require further development.

Note that while mutable history users avoid unnecessary merges whose soul purpose is to reducing merge fatigue, they are not averse to merge commits that communicate useful information. So it is perfectly sensible to create a merge commit that demonstrate that a feature branch (usually containing a linear set of related changesets) has been merged into default. However, before the merge occurs, the feature branch should have its history edited in such a way that the entire branch will apply cleanly and no merge conflicts will occur that require any diff to be committed with the merge.

Have your cake and eat it, too

Distributed version control systems allow us to have multiple copies of repos in different states. If you feel strongly that an “honest” permanent history is important, perhaps it would be a good idea to keep this honest copy of history in a separate repository or a different branch. But for the sake of effective, coherent communication, maintain the main history in a mutable style.

In git, this can be done with branches. Simply do the development work on one branch (maybe give it a name like permanent/branchname to identify it as such). Push all changes to this branch as they occur. However, keep your master branch clean for most effective communication. When a feature is ready to go live, create a new branch from the commits on the permanent branch and rebase them onto master in a well-ordered manner that communicates clearly.

I’m not sure how viable this would be in Mercurial, since it’s not easy to copy commits between branches. More likely, it would be suitable to have two repositories; one that contains the permanent historical record, and one that contains the edited history.

I don’t personally believe this is necessary. The mutable history paradigm communicates everything I need it to. However, if you are unsure if you are ready to make the switch, I want to make it clear that it is possible to maintain both styles for a period while you experiment with the idea. If it turns out you don’t like the mutable history paradigm, you can always delete the offending mutable branches or repository… though, of course, this would be a mutation of history in itself.

I expect people who perform this experiment to realize that well-crafted history is worth the small amount of extra up-front effort required to maintain it.