Index ¦ Archives ¦ RSS > Tag: linux

Linux Top Origins

(I was recently asked about Linux top. Here is my response.)

Back in the second half of 1991, someone posted about a new Unix like operating system. It was an instant hit for those of us lucky enough to be connected to the Internet. At my university's several computer labs we had good access to a variety of systems, especially large numbers of Sun workstations, some Windows/286 PCs, and a big Pyramid system shared by students and faculty.

If you wanted something Unix like on your own PC there wasn't much choice. The front runner was Minix which was very expensive for students. It was also for the 8086 and didn't take advantage of more than 1MB of RAM or memory protection, plus had single threaded filesystem access making that slow too. There were a big set of patches for the 80386, but they weren't officially supported.

Linus started out with some assembly language hosted by his Minix system that explored the 80386 task switching instructions. It didn't take too much more before it could run processes and access the filesystem. It was just for fun. It was simple, effective and just what so many people were looking for with no barriers to participation. Releases were frequent as people scratched their own itches.

One thing the fledgling Linux didn't have is getting a list of running processes. (It also didn't have sound, mice, networking, gui, or a whole bunch of other normal stuff yet so that wasn't a big omission.) You had to press the Scroll Lock key and it would spew some stuff on the console showing the running processes. That wasn't a huge burden since it only supported 63 processes total. You can still see the descendent of the scroll lock diagnostics by using the SysRq key with t for tasks.

It was also very common to download the source for various parts of the system as they frequently changed to keep up to date with system calls and semantics. For example this included bootloaders, compilers, C libraries, text editors etc. You'd want to recompile everything on each Linux kernel release which took a while. And often you'd want to know if something got stuck, or if things really were proceeding.

Branko Lankester released a version of ps that was a quick hack. Instead of adding "proper" support for getting a list of processes, he added an ioctl to the keyboard driver (since all systems had one making it easy to access).

While ps is nice, it only gives you a snapshot of the system and no idea about what is happening over time. I was already familiar with top and wanted that to monitor the system. The existing top had no hope of working on Linux so I wrote one from scratch. It was pretty much the simplest way of wrapping ps so that it sorted the processes, and then output as many would fit on the screen. That is why the documentation always mentions Branko and his ps.

I did add some unique things over the top I had used. You could specify which fields were shown and in which order. There were less than 26 so I used the letters of the alphabet. It could be saved to a $HOME/.toprc so you didn't need to reconfigure each time you ran. The same configuration was preserved for many years by future authors.

I released my top in early 1992. I then had a 6 month work placement where I no longer had access to a machine I could run Linux on. Others then took over top, updating it as Linux matured, exported process information more sensibly, removed some inefficiencies I had coded, all leading up to what you have today. I would be shocked if any of the original code survives. I am still listed in the credits though.

top was developed on an 80386 system running at 20MHz with 4MB of RAM. It had a 100MB hard drive of which 80MB was used for DOS and 20MB was allocated for Linux. I used vi as the text editor, and had to figure out various library usage (eg dealing with the terminal) by reading library source code.

Category: geek – Tags: linux, history

Lifecycle of a Linux distro

There seems to me to be a pattern for how many Linux distributions gain prominence and then fade away. Here is a family tree up until 2012. Doing a distribution is a lot of work needing components like installers, package managers, pulling in upstreams regularly, configuration, security etc.

The genesis is a need not being met. It is fascinating what these have been historically ranging from how stable/fast moving they are, how they are built, preferring certain software (eg a particular gui like KDE), wanting a certain kind of community, targeting certain users or uses, and numerous other reasons.

What this means is that as a distro starts it has a reason, a focus and a way to see what work is necessary. The problems start once it becomes successful. It becomes a lot easier to add "one more thing" to the distro such as another package, another configuration option or even good old fashioned feature creep. This will gain more users and make the distro better.

But the larger distribution, more users and wider scope makes the distribution harder. The hardware it is used with, the software it interacts with, changes in upstream and the users all lead to far more work. Every change breaks something, but not changing pieces also breaks due to changes in others. The symptoms of this show up in the bug trackers with increasing numbers of open or abandoned tickets.

Some distros respond by narrowing their audience (eg charging for it, restricting use cases, narrowing hardware and software etc). Others have their developers pull back into the work they are most interested in leaving the other parts languishing. Sometimes politics break out as various parties fight for what they think is important.

Ultimately, people then see their needs not being met causing a whole new cycle of distros.

Category: misc – Tags: linux

Contact me