Friday, January 6, 2017

Few thoughts about systemd and human behavior

I was just reading comments on a post on Hackernews about systemd. Systemd, as you might know, is a replacement for the venerable init system. Anyway, reading the comments was reading about all the same story over and over again. Namely, there are those strongly pro and those strongly con the systemd, in some cases based on arguments (valid or not) and in other cases based on feelings. In this post I won't go into technical details about systemd but I'll concentrate on a human behavior that is the most interesting to me. And yes, if you think I'm pro systemd, then you're right, I am!

Now, what I think is the key characteristic of people is that they become too religious about something and thus unable to critically evaluate that particular thing. It happened a lot of times, and in some cases the transition from controversy was short, in other cases it took several or more generations of human lives. Take as an example the Christian religion! It also started as something controversial, but ended as a dogma that isn't allowed to be questioned. Or something more technical, ISO/OSI 7 layer model. It started as a controversy - home many layers, 5, 6, or 7? The result of this controversy we know, and after some short period of time it turned into a dogma, i.e. that 7 layers is some magical number of layers that isn't to be questioned. Luckily, I don't think that it is the case any more, that is, it is clear that 7 layers was too much. Anyway, I could list such cases on and on, almost ad infinitum. Note that I don't claim that any controversial change succeeded in the end, some were abandoned and that's (probably) OK.

I should also mention one other interesting thing called customs (as in norm). People lives are intervened with customs. Anyway, we have a tendency to do something that our elders did just because, i.e. we don't know why. I don't think that's bad per se, after all, probably that helped us to survive. The problem with the customs is that they assume slow development and change in environment. In such cases they are very valuable tool to collect and pass experience from generation to generation. But, when development/change speed reaches some tipping point, customs become a problem, not an advantage - and they stall adjustment to new circumstances. So, my personal opinion about customs is that we should respect them, but never forget to analyze if they are applicable/useful or not in a certain situation.

Finally, there is one more characteristic of a human beings, and that is inertia. We used to do things in certain way, and that's hard to change. Actually, I do not think that it is unrelated to religion and customs, actually on the contrary, I think they are related and it might be something else that is behind. But i won't go into that, at least not in this post.

So, what all this has to do with the systemd? Well, there is principle or philosophy in Unix development that states that whatever you program/create in Unix, let it do one thing and let it do it right. For example, tool to search for file should do it well, but not do anything else. And my opinion is that this philosophy turned into a custom and a religion in the same time. Just go through the comments related to SystemD and read them a bit. A substantial number of arguments is based on the premise that there is a principle and it should be obeyed under any cost/circumstance. But all those who bring this argument forget to justify why this principle would be applicable in this particular scenario.

And the state of computing has drastically changed from the time when this philosophy was (supposedly) defined (i.e. 1970-ties) and today's world. Let me say just a few big differences. Machines in the time when Unix was created were multiuser and stationary, with limited resources and capabilities, and they were used for much narrower application domains than today. Today, machines are powerful and inexpensive, used primarily by a single user. They do a lot more than they used to do 40 years ago, and they offer to users a lot more. Finally, users expectations from them are much higher than they used to be.

One advantage of doing one thing and doing it well was that it reduces complexity. In a world when programming was done in C or assembler, this was very important. But it also has a drawback, and that it is that you lose ability to see above the simple things. This in turn, costs you performance but also functionality, i.e. what you can do. Take for example pipes in Unix. They are great for data stored in text organized in a records consisting of lines. But what about JSON, XML and other complex structures? In other word, being simple means you can do just a simple things.

This issue of simple and manageable and complex and more able is actually a theme that occurs in different areas, too. For example, in networking where you have layers, but because cross layer communication is restricted means you have a problems with modern networks. Or, take for example programming and organizing software in simple modules/objects. Again, the more primitive base system is, the more problems you have to achieve complex behavior - in terms of performance, complexity, and so on.

Few more things to add to the mix about Unix development. First, Unix is definitely success. But it doesn't mean that everything that Unix did is a success. There are things that are good, bad, and ugly. Nothing is perfect, nor will ever be. So, we have to keep in mind that Unix can be better. The next thing we have to keep in mind is that each one of us has a particular view on the world, a.k.a. Unix, and our view is not necessarily the right view, or the view of the majority. This fact should influence the way we express ourselves in comments. So, do not over generalize each single personal use case. Yet, there are people who's opinion is more relevant, and that are those that maintain init/systemd and similar systems, as well as those that write scripts/modules for them.

Anyway, I'll stop here. My general opinion is that we are in 21st century and we have to re-evaluate everything we think should be done (customs) and in due course not be religious about certain things.

P.S. Systemd is not a single process/binary but a set of them so it's not monolithic. Yet, some argue its a monolithic! What is a definition of "monolithic"? With that line of reasoning GNU's coreutils is a monolithic software and thus not according to the Unix philosophy!

Saturday, December 31, 2016

Retro computing resources

From time to time I like to search on the Internet stuff related to retro and vintage computing. This time my interest was (again) resolving around a wish to try Xenix. Namely, Xenix was a Unix variant written by Microsoft that could be run on IBM PC XT with 8086 microprocessor. While searching where to download Xenix, I stumbled on a WinWorld site which has many other vintage operating systems available for download. So, a lot of stuff to try. Later, I discovered that there is also software shipped as part of a MAME ROM package. You can browse it here.

Obviously, to try them it is necessary to have an emulator. Note that virtualization solutions like QEmu, VirtualBox, VMWare and similar don't fit here because they emulate modern hardware, or they only virtualize existing hardware. So, I tried to find emulator that emulates PC XT/AT, but also emulators that would allow me to run software for other platforms. After half day search, I decided to write this post with everything I found so far.

One site with some kind of a database of a different emulators is Zophar's Domain. It isn't particularly up to date, but nevertheless it lists a lot of emulators with different categorizations so I think it's very useful. Later, I found several other similar sites:
Zophar's site helped me to find emulator for IBM PC XT/AT, namely PCE. This particular emulator emulates a lot more hardware than just IBM's, and what's more interesting is that the author already prepared different configurations for you to download and try. Specifically, there is Xenix 2.13 to download and try. Just one note, these archives are for Windows machines, so if you are - like me - on Linux, download first PCE's source, compile it and then use it instead of provided EXE files. Anyway, I tried it and it worked flawlessly.

As it turns out, there are some other IBM PC XT/AT emulators:
  • The first one is 8086tiny. It claims to be the smallest emulator there is. But, I haven't had a lot of success in trying it.
  • In case you want something that runs within a Web browser, then you'll be interested in PCjs, i.e. JavaScript emulator. Source is available here. This one seems to be actively developed at the time this post was written.
  • The MAME emulator.

And this last one is interesting enough for me to devote few paragraphs to it. MAME is emulator that emulates multiple different machines. What was interesting to me is to try several ones:
In each case I had to find appropriate ROM files. In the end, the most useful site was Emuparadise. After downloading zip files, I unpacked them into a directory named after the machine as identified in MAME itself and then started the emulation like this:
mame -rp . orao
or in case of Amstrad
mame -rp . pc1512
In each case the option -rp specifies that the current directory should be searched for rome files, while the other argument is driver/machine to be emulated. Note that ROM files will be searched for in the directory named as driver/machine. It happened in some cases that not all ROM files were present, but I managed to find them in other archives on the same site.

For the end, here are some additional interesting links I stumbled on:

Tuesday, November 1, 2016

Short Tip: Find files with non-printable ASCII characters

I have a directory full of different files obtained from the Internet and it turned out that some of them contain UTF-8 characters because of which indexing didn't work. So, I had to find all files that contain such characters. The solution I found was the following one:
LC_ALL=C find . -name '*[! -~]*'
This command will print all filenames with embedded unicode characters represented as question marks. Few facts about this command:
  1. Assignment (LC_ALL=C) temporarily switches to C locale during the execution of find(1) command. The effect of this is that find(1) will not interpret multibyte utf8 characters, but strictly byte-per-byte input.
  2. find(1) will then search for file name that don't contain printable ASCII characters. To see this, take a look at a glob pattern. First and last star mean that the square brackets can be anywhere within the file name. Square bracket, on the other hand, specifies class of characters outside (exclamation negates range) of a range from space (ASCII code 32) to tilde character (ASCII code 126).
The output of find(1) command will include question marks in places where byte (ASCII char) has a value below 32 or above 126. In order to see what unicode character is in the particular place, you can pipe output to, e.g. cat(1) command, like this:
LC_ALL=C find . -name '*[! -~]*' | cat
This will work because cat(1) command will have unicode encoding selected (the value of the variable LC_ALL isn't changed for it) and will properly interpret and output multibyte sequences used in utf8 coding. Actually, if you want to nitpick, cat isn't going to interpret anything but will initialize terminal to properly handle utf8 characters which will do actual interpretation. 

About Me

scientist, consultant, security specialist, networking guy, system administrator, philosopher ;)