21 Jan 2015

H/FOSS Experiences and Reflections

TOS Exercise 2.4.4

The Open Source software that I’ve most recently installed and used is i3lock. I recently switched my windows manager to be i3wm, and needed a lock screen. Installation was simple enough, as i3lock came packaged with i3wm. So I installed it using my package manager: sudo apt-get install i3. It worked well initially, I created a keybind to run i3lock when I pressed ctrl + superkey + l. Everything functioned as it should.

My next task was to run i3lock when I suspended my machine by shutting the lid. To achieve this I wrote a script:

#!/bin/bash
#
# screenlock: lock screen on hibernate or suspend
# place in /etc/pm/sleep.d
# chmod 755
# chown root:root

username=lixxia 
userhome=/home/$username
export XAUTHORITY="$userhome/.Xauthority"
export DISPLAY=":0"
case "$1" in 
    hibernate|suspend)
       sudo $userhome/.i3/resumelocker.sh
       ;;
    thaw|resume)
       ;;
    *) exit $NA
       ;; 
esac

It took some trial and error: my first iteration of the script used su instead of sudo, and for some reason took an inordinate amount of time causing the suspend process to delay for several seconds. Eventually I got it to run properly and quickly. However, at this point, it would not accept the proper password and unlock the screen. This lead me to look at the actual source code for i3lock. Through some searching online, I finally discovered that I needed to edit the i3lock.pam (which generates the pam.d/i3lock file that is used to authenticate the user credentials and unlock the computer).

Lastly I had to compile my code. It was mostly written in c, so it was a simple matter of make clean (to remove files from my previous installation), make and sudo make install. Everything worked!

After this success I was inspired to fiddle with the source code further, customize some graphical aspects and add some features. By default i3lock can be configured with an image or solid color background by passing arguments (for example: i3lock -c 000000 for i3lock with a black background), and has an unlock indicator that appears after a keypress.

The standard settings for i3lock

I made the following changes: - Changed the display on key-strokes and escape/backspace. - Added 12-hour clock to the unlock indicator and periodic updater so time stays relevant. - Changed border, text and background colors. - Changed it so that the unlock indicator will always be displayed, regardless of state. (Originally it was only shown after initial keypress)

Screenshots below.

My Default

Key Press

Escape/Backspace

And a link to my repo.

Reading - The Cathedral and The Bazaar

The Cathedral

I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.

The Bazaar

the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches out of which a coherent and stable system could seemingly emerge only by a succession of miracles.

I will start by saying that I adore the provided descriptions of these two contrasting development styles. They are almost artistic in the way they are aptly summarized while accurately portraying the nature of each style.

1. Every good work of software starts by scratching a developer’s personal itch.

This point has proven absolutely true, at least for me. Every time I have the desire to change something or make something easier for myself, I’m lead to create the solution myself. The only reason I ever decided to make changes to i3lock and build from the source was because of a problem, and then changes I wanted to make.

1. Good programmers know what to write. Great ones know what to rewrite (and reuse).

The second point has also held true for me, rarely do I start hacking away. I first look at what’s already done and use that as inspiration or a starting point. And at this point, I’ll say that every point he mentioned resonated with me in some manner.

I found Raymond’s analysis of development structures (cathedral and bazaar) to be very interesting, and generally on point. I enjoyed that he linked different types of development to specific, well known, open source projects so that there was a bit more context.

The idea that having a large developer base would assist in identifying bugs, or as the author terms it “Linus’s Law” is also interesting. Moreover, its role as the identifying difference between the cathedral and bazaar styles really stood out to me. The release early release often mantra has obviously been successful, but I feel it is important to realize that one need not pick one style of development or another, but adapt and changed based on the needs of the project and the style/ability of its developers.

It’s truly fascinating how the bazaar style of development can seem unorganized and chaotic on the surface, and indeed it’s often baffling to realize that it works, while in reality it is a series of cogs working together to produce results quickly and cleanly.

Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.

I only wanted to mention this quote for its brilliance. For something so obvious, it’s often overlooked that elegant data structures may often hold more importance than elegant code. (Although I think both should be sought after).

Obviously the heart of the bazaar development style is the community working together, which is why FOSS is often recognized for its community-central development. However, politics can get in the way when people become stubborn or elitist in their methods. Which brings us to Raymond’s point number twelve.

1. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

It is my belief that one should seek failure. I would much rather fail quickly and often, learning from my mistakes, than taking baby steps in order to avoid failure. There is much more that can be learned from failure than success, if only one is willing to accept it.

Overall the lessons learned from Raymond’s experimentation with the bazaar style and the points presented came across as humorous and truthful. While they may not be points to live by, they should certainly be regarded and considered for each individual. The article itself is long, with each point buried in the text, so for the lazy individuals and my own future reference I will list all of the points below.

1. Every good work of software starts by scratching a developer’s personal itch.
2. Good programmers know what to write. Great ones know what to rewrite (and reuse).
3. “Plan to throw one away; you will, anyhow.” (Fred Brooks, The Mythical Man-Month, Chapter 11)
4. If you have the right attitude, interesting problems will find you.
5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
6. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
7. Release early. Release often. And listen to your customers.
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
9. Smart data structures and dumb code works a lot better than the other way around.
10. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource.
11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.
12. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.
13. “Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.” (Antoine de Saint-Exupéry)
14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected.
15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible—and never throw away information unless the recipient forces you to!
16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend.
17. A security system is only as secure as its secret. Beware of pseudo-secrets.
18. To solve an interesting problem, start by finding a problem that is interesting to you.
19. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Ethics of Free Software - Meyer

I disagree, at the very least, with how this article was phrased. There were a lot of sweeping statements and declarations. “Ethics is about right and wrong”, “In spite of the diversity of moral views, ethics includes a universal component.” These statements have no factual backup (to be fair it is hard to talk in facts when one is discussing ethics) and are way too generalized for my taste.

One cannot create a blanket solution to the “controversy” within the FOSS community, and I don’t think one is required. Sometimes things need to be determined on a case by case basis, despite the fact that they may be grouped under the same heading.

I’ll be honest, at this point I was pretty discouraged from reading the rest of the article.

A Rebuttal To Meyers

I think the author’s identification of the flaws in Meyer’s article is pretty spot on. He was also a bit more eloquent in describing them, for example:

Meyers begins his discussions of ethics by describing a list of axioms that are not ‘proven’, but presented as self-evident. This is not particularly alarming as ethical bases tend to be axiomatic in nature. However, Meyer’s assumptions of indisputable fact get into trouble quickly.

I don’t agree with everything he says however. His general disdain for calling it “The Open Source Movement” appeared to me as juvenile whining about all of these newbies joining what was once the cool kids club. This is not the first time I’ve experienced this attitude, and I find it a disturbing juxtaposition after reading the cathedral and the bazaar, where Raymond celebrates the community and the inclusion of new blood.

Unfortunately, I again found myself dissatisfied with the remainder of the article. While the author does make good points, he has a sort of lazy disdain that makes me less inclined to agree with him.

Laura Barber at 12:26PM