In the 1960's, Richard Stallman witnessed the rise of proprietary software when he was denied the source code for the firmware of a printer he was in charge of administrating. Now, because of his work over the course of nearly 50 years, we have the option of running an entirely Free Software system without lacking the tools we need.
Why did he go to the trouble?
Proprietary software arose as a tool which large corporations could use to control and manipulate their users. They used this control to obtain more money and in the process violated some of our basic rights as citizens of the digital age.
This post is about a few examples of how these violations affect users today.
How Does It Work?
Proprietary software, first and foremost, prevents users from knowing how it goes about accomplishing what it claims to accomplish. Proprietary tax software cannot be examined to be certain it truly conforms to the tax laws it purports to help users with. Proprietary antivirus software can't be examined for correctness.
For those users who are more concerned that their software works the way it advertises than they are about having someone to point the finger at when it breaks, not being able to look under the hood is not acceptable. It should concern everybody that their electrical grids and cable signals may not be run by provably reliable software.
This opaqueness also prevents those wishing to learn about software from learning through example. Children should have the benefit of knowing how their world works, including how their computer works. Don't you think?
Can I Improve It?
Traditionally, when you purchase something, you obtain the right to do with it as you will. This includes modifying it to function more effectively or more in line with the owners needs. Car owners frequently modify their vehicles for appearance, gas mileage, horsepower, or any number of other purposes. There are entire communities dedicated to modifying their game consoles.
However, proprietary software does not offer this basic right. A user who wishes that the proprietary music player he uses included a "loop" feature cannot feasibly add such a feature. A gamer who can't progress past a particular point in his favorite proprietary game cannot add new cheats to the game.
This places the users at the mercy of the software publishers and forces them to settle for software which doesn't fit their needs as well as it could.
How Do I Know it's Not Misbehaving?
Software which prevents users from scrutinizing it can get away with all kinds of dastardly behavior in secret. One of the earlier examples was the sheer amount of identifying personal information the media player RealPlayer collected from the user's computer and sent back to the company which published RealPlayer.
Today, Google Chrome, one of the most popular web browsers, collects similar information from its users for advertising and tracking purposes. Some software comes with advertising and spying software from third parties.
With the right tools, some of this misbehavior may be detected. It's not easy unless you know where to look, however. More alarming still is the fact that most users don't seem to so much as care what their programs are doing when they're not looking.
This is a small sample of the problems with proprietary software. However, it's fairly easy to come up with numerous ways in which proprietary software violates a user's liberties.
More information on the topic of proprietary software and its negative effects on our liberties may be found at the website of the Free Software Foundation.
Showing posts with label philosophy. Show all posts
Showing posts with label philosophy. Show all posts
Monday, January 16, 2012
Wednesday, December 28, 2011
The Unix Philosophy
I'm a software engineer by trade. One thing I've learned is that college is not enough to make you a good software engineer (or programmer, for that matter). You have to make a lot of mistakes yourself to get good at it.
One viewpoint which leads to a lot of such mistakes, and one which must be discarded in order to be a good programmer, is the idea that "more features is better." The result of such a misnomer is bloated software which tries to do everything and doesn't do anything very well. Not only that, but the resulting software has limited configurability and uses more resources than necessary.
The "Unix Philosophy" is a perspective on software development which is aimed at addressing this problem. It consists of a list of rules of thumb that programmers and software engineers should apply to their work. There is a bit of disagreement about some of the wording, but the spirit of the Unix Philosophy is well agreed upon.
From Wikipedia, Mike Gancarz's version of the unix philosophy:
1. Small is Beautiful
A large program has many potential points of failure. If there's a bug, it's easy to find because there's not as much program to look through as if it's a big program. Also, if it's small enough, it's easy to keep the entire inner workings of it in your head at once. It's easier to grasp. And it takes less work for somebody unfamiliar with the program to become familiar (or even an expert) with the software.
But how small is small? Let's take an example of a class of software applications generally considered to be required to be "large" -- web browsers. Sloccount (a tool for counting how many lines of source code a program consists of) reports that Firefox 8.0 (a fairly recent release) consists of 3,291,364 lines of code. Surf is a minimalistic browser which follows the Unix Philosophy. Sloccount indicates that the recent 0.4.1 release of Surf consists of 753 lines of code. That's an incredible difference.
2. Make Each Program do One Thing Well
In other words, each program should have exactly one feature. No more. No less. A program which does two things is unnecessarily complex. If you need two features, use two programs. Simple.
3. Build a Prototype as Soon as Possible
Often, this is phrased as "release early and release often." If you release a prototype, you can get feedback early, which allows you to fix problems early on.
4. Choose Portability Over Efficiency
Portability gives you more options. It allows you (and others) to test on faster hardware and slower hardware which allows you to ferret out issues nicely. Also, it will pay off later when the niche technology you decided not to use becomes abandonware.
5. Store Data in Flat Text Files
Flat text files give a lot of power to the users as opposed to binary formats. Binary formats, even if the code for parsing them is open source, just take a lot more work to work with. Flat text formats can be edited in text editors. It can't get much easier than that.
This one in particular is the subject of some controversy. Many object that databases are often times the right tool for the job of storing data, even if they do have some drawbacks such as making it more difficult to port the data to other means of storage.
6. Use Software Leverage to Your Advantage
Code has some interesting properties. One is that a useful function or library may be written once and used in multiple places. Many mistakes may be made in the process of writing software which makes it difficult to reuse useful bits of software, however. "Using Software Leverage" means making your software easy to reuse so that you don't have to rewrite it later.
7. Use Shell Scripts to Increase Leverage Portability
Shell scripts are wonderful things. They're written to run in the shell, which means they are written in the same language as the commands you type directly on the shell. A single line in a shell script can actually do a surprisingly powerful operation. Also, shell scripts can be made very portable very easily.
8. Avoid Captive User Interfaces
A "captive user interface" is one which requires (or virtually requires) a human to operate. Just about any interface which requires a mouse is a captive interface. These are not always a bad thing, but are almost always a bad thing. They restrict the ways in which the program may be used.
9. Make Every Program a Filter
A "filter" is a program which takes input and produces output without any other effects. A good example of a filter is the Unix command "sort" which takes a bunch of text (one word per line) sorts the lines lexographically, and prints out the sorted version. It does nothing but sort the input and print out the sorted version.
This is just an overview of the Unix Philosophy. There is much more to be said. There are in fact books on the topic.
But don't worry. You'll be hearing a lot more about the Unix Philosophy and applications which employ it.
Happy hacking.
One viewpoint which leads to a lot of such mistakes, and one which must be discarded in order to be a good programmer, is the idea that "more features is better." The result of such a misnomer is bloated software which tries to do everything and doesn't do anything very well. Not only that, but the resulting software has limited configurability and uses more resources than necessary.
The "Unix Philosophy" is a perspective on software development which is aimed at addressing this problem. It consists of a list of rules of thumb that programmers and software engineers should apply to their work. There is a bit of disagreement about some of the wording, but the spirit of the Unix Philosophy is well agreed upon.
From Wikipedia, Mike Gancarz's version of the unix philosophy:
- Small is beautiful.
- Make each program do one thing well.
- Build a prototype as soon as possible.
- Choose portability over efficiency.
- Store data in flat text files.
- Use software leverage to your advantage.
- Use shell scripts to increase leverage and portability.
- Avoid captive user interfaces.
- Make every program a filter.
1. Small is Beautiful
A large program has many potential points of failure. If there's a bug, it's easy to find because there's not as much program to look through as if it's a big program. Also, if it's small enough, it's easy to keep the entire inner workings of it in your head at once. It's easier to grasp. And it takes less work for somebody unfamiliar with the program to become familiar (or even an expert) with the software.
But how small is small? Let's take an example of a class of software applications generally considered to be required to be "large" -- web browsers. Sloccount (a tool for counting how many lines of source code a program consists of) reports that Firefox 8.0 (a fairly recent release) consists of 3,291,364 lines of code. Surf is a minimalistic browser which follows the Unix Philosophy. Sloccount indicates that the recent 0.4.1 release of Surf consists of 753 lines of code. That's an incredible difference.
2. Make Each Program do One Thing Well
In other words, each program should have exactly one feature. No more. No less. A program which does two things is unnecessarily complex. If you need two features, use two programs. Simple.
3. Build a Prototype as Soon as Possible
Often, this is phrased as "release early and release often." If you release a prototype, you can get feedback early, which allows you to fix problems early on.
4. Choose Portability Over Efficiency
Portability gives you more options. It allows you (and others) to test on faster hardware and slower hardware which allows you to ferret out issues nicely. Also, it will pay off later when the niche technology you decided not to use becomes abandonware.
5. Store Data in Flat Text Files
Flat text files give a lot of power to the users as opposed to binary formats. Binary formats, even if the code for parsing them is open source, just take a lot more work to work with. Flat text formats can be edited in text editors. It can't get much easier than that.
This one in particular is the subject of some controversy. Many object that databases are often times the right tool for the job of storing data, even if they do have some drawbacks such as making it more difficult to port the data to other means of storage.
6. Use Software Leverage to Your Advantage
Code has some interesting properties. One is that a useful function or library may be written once and used in multiple places. Many mistakes may be made in the process of writing software which makes it difficult to reuse useful bits of software, however. "Using Software Leverage" means making your software easy to reuse so that you don't have to rewrite it later.
7. Use Shell Scripts to Increase Leverage Portability
Shell scripts are wonderful things. They're written to run in the shell, which means they are written in the same language as the commands you type directly on the shell. A single line in a shell script can actually do a surprisingly powerful operation. Also, shell scripts can be made very portable very easily.
8. Avoid Captive User Interfaces
A "captive user interface" is one which requires (or virtually requires) a human to operate. Just about any interface which requires a mouse is a captive interface. These are not always a bad thing, but are almost always a bad thing. They restrict the ways in which the program may be used.
9. Make Every Program a Filter
A "filter" is a program which takes input and produces output without any other effects. A good example of a filter is the Unix command "sort" which takes a bunch of text (one word per line) sorts the lines lexographically, and prints out the sorted version. It does nothing but sort the input and print out the sorted version.
This is just an overview of the Unix Philosophy. There is much more to be said. There are in fact books on the topic.
But don't worry. You'll be hearing a lot more about the Unix Philosophy and applications which employ it.
Happy hacking.
Subscribe to:
Posts (Atom)