From Software Bloat to Minimalism

Maciej Ceglowski has a fascinating blog post in which he argues that the popular form of Moore’s Law (“computers always get faster and more capable”) is beginning to break down, but it does not matter because “the devices we use are becoming ‘good enough’”. However, as Ceglowski points out, stagnating computing power turns software bloat into a serious problem. We have gotten used to very sloppy design practices that are no longer viable:

Developers and designers together create overweight systems in hopes that the hardware will catch up in time and cover their mistakes.

As soon as a system shows signs of performance, developers will add enough abstraction to make it borderline unusable.

I agree that the time has come to abandon bloat. Over the last few years, I have been moving away from bloat towards minimalism in the software that I use. This began with moving from Windows to Linux, but soon I realized that modern Linux distros also contain a lot of bloat. Over time, I took several additional steps to reduce bloat:

  • Moved from Ubuntu to Xubuntu to get rid of the bloated Gnome/Unity desktop. Maybe I must move to Lubuntu or even Arch Linux someday.
  • Switched away from Thunderbird to notmuchmail for email.

  • Weaned myself away from Microsoft Office and LibreOffice to Latex/Beamer for documents and presentations.

  • Abandoned spreadsheets and started using R data frames as spreadsheets. Nowadays, I use spreadsheets only in the classroom.

  • Started using Emacs as a replacement for many GUI environments. Emacs is now my file manager, the development environment for R, Latex and Python, my notmuchmail client, and occasionally my web browser (Emacs-w3m).

  • Recently, I have been working towards moving to Conkeror as my main web browser. Conkeror is not only lightweight, but it also provides a complete keyboard based interface for those who hate the mouse (it is created by the author of Ratpoison).

My office machine dual boots into Windows and has all the old bloated software (both Windows and Linux) available alongside the minimalist alternatives. But even on that machine, I never find myself tempted to go back to the old mouse friendly software that is just a click away. The main reason is that I have experienced at first hand how much the mouse slows one down. A bit of Ratpoison is a wonderful productivity booster.
Continue Reading

Advertisements

A computer hacking 30 years ago

Hacking computers was a very different game 30 years ago. Tim Berners-Lee had not yet invented the World Wide Web, and Microsoft had not yet created the Windows 3.x operating system. Like my fellow students at the Indian Institute of Management, Ahmedabad, I did all my computing on a VAX mini computer running a dialect of Unix called VAX/VMS. The computer itself was in a locked glass room, and we worked from a couple of dozen dumb terminals in two neighbouring rooms.

There was one printer for all of us. This line printer could print only text, but we were all thrilled that it could print lower case also unlike its predecessor which printed only in upper case. When we gave a print command, the job sat in a print queue until the operator came along (a few times a day), switched on the printer and started the print queue. For each print job, the printer printed a banner page with the name of the user and the name of the file before printing the file itself. This made it easy for us to locate our printout in the stack of paper that came out of the printer.

If you visited the printer early morning, you would see lots of printouts of the previous day still lying around because they had not yet been collected, and you could browse through them if you liked. Nobody was stupid enough to printout intimate correspondence. And since this was decades before Angry Birds, none of us had any delusion that the shoddy Fortran code that we wrote could ever be monetized.

When you submitted a job to the print queue, what happened was that the file was copied to a specific spool directory (it might have been something like /var/spool/lp/, but I have no recollection of the exact folder). When the print queue was started, the printer daemon looked at this folder, printed out each file in turn and deleted the file after printing. Many of us had figured out that everybody had read access to the spool folder (I guess the permission was something like 775). This meant that each of us could look at the spool folder and see what files were queued for printing and also whether our file had been printed or not. More interestingly, everybody had read permissions on the individual spool files also so that before the file was printed (and deleted) we could also read the file or even copy the file elsewhere to be read at leisure. We did not think of this as such a big thing because the printouts were lying around in full public view anyway.

One Monday morning, a friend of mine sitting at the next terminal asked me whether I knew anything about the Management Game that was played the previous day (Sunday). I told him what I knew – the entire computer centre had been booked for the Management Game on Sunday and I could not use the machine. Each team had a separate terminal allowing them to perform some analysis using the Management Game software before taking their decisions. The game was played in several rounds each representing one month. In each round, the teams chose their pricing and investment strategies for that month. At the end of the round, each team received a printout of the detailed results for their team and a summary of the performance of all teams. My friend listened to all this explanation and told me that I was missing the point – I was forgetting the print spool folder. Any team that knew about the print spool folder could read the confidential data about all other teams! The organizers had ensured physical security of the printer room, but neither knew nor did anything about the spool folder.

To this day, I do not know whether any team did misuse the spool folder during that Management Game. One half of me says that some players certainly knew about the spool folder and were not of the kind that would hesitate to exploit such opportunities. The other half of me says that if they did access the spool folder, it would not have been to win a silly Management Game, but it would have been to brag about how they outsmarted the organizers. I did not hear any of this bragging, but then I rarely frequented the kind of evening gatherings where such boasts would have been more forthcoming.

When I think about it today, I realize that what looks like a harmless flaw in one context can be a fatal vulnerability when the system is used for a different purpose. On my current Linux system, the spool folder /var/spool/cups is readable only by root, so it does not have the vulnerability that the VAX machine had. But it has a different problem: the files are not deleted after printing. So anybody who boots the system with a Live CD can read every single file that I have printed during the last year or more. This is a threat model that I had never considered earlier, but having thought about it while writing this blog post, I now know that I should run a cron job to empty this spool folder periodically.

Installing QuantLib-Python Quantitative Finance Library in Windows

QuantLib is a high quality open source C++ library for quantitative finance. There is also a mechanism (based on SWIG) to use this C++ library in Python without knowing any C++ at all, and this makes QuantLib extremely useful in the classroom: Prof. Vineet Virmani and I have a working paper about our experience with such classroom usage. Installing QuantLib-Python in Linux is trivial; many Linux distros have QuantLib-Python in their repositories and one can just install from there without having to worry about building them from source. Even if we want a later version than what is there in the repositories, building QuantLib-Python from source is quite straightforward – the usual ./configure, make, sudo make install dance works nicely for QuantLib and installing the Python part is just a question of running setup.py.

But to use QuantLib-Python effectively in the classroom, the students also need access to it and almost none of them run Linux at our Institute. Installing QuantLib-Python in Windows is a non trivial task since most of the students do not also have commercial development tools like Visual Studio either. This blog post describes the solution that we came up with for this problem using only free tools.

That leads to the question whether free means free as in free beer or free as in free speech. Coming as we did from the Linux world, we began with the free speech model. Later we realized that those who use Windows have anyway reconciled themselves to the free beer model and building QuantLib-Python is easier under this approach. On the other hand, the free speech approach allows us to build everything on one machine and distribute just the final binary library since everything that we are using comes with a redistribution licence. I will describe both approaches in this post.
Continue Reading