The limitation of the Zuse calculating machine

 The machines from Konrad Zuse were often referenced as innovative early sort of computers. The assumption is, that the technology was great but the world was unabe to see genius of the Z22  vacuum tubes controlled machine.

Instead of describing the legacy of Zuse by its own words there is need to revisit the technology from a technical perspective. The computers created by Konrad Zuse are an intermediate technology between calculators and Unix based computing. The only perspective under which the Z22 has to be called advanced and modern is with a focus on former calculaters.

The main task for a calculator is to add and subtract numbers. All the machines buit by Zuse are able to do so and in addition they can execute a program provided on Punched tape. The commands on the punch tabe are writen in the Freiburger code which is an assembly language. In other words, the Z22 is a programmable calculator.

Unfurtunately, programmable pocket calculator were replaced by main frame computers. Since the 1970s these computers were equipped with a dedicated operating system called UNIX which is a multi user time sharing system. This system allows to use the ressouces of the computer more efficient which means, that the costs for a user on a machine are lower. In contrast the Z22 has no operating system at all and it can't be called a computer. But its simply an advanced calculating machine. The strength is to add and subtract columns of data but it lacks in support for computing appications like word processing, networking and computer animation.

In other words, the Z22 was outdated since its release. And only to judge fair, other early calculating machines from IBM can't be called a computer. Similar to the Z22 these machines were used without a UNIX operating system and its main task was to replace office calculating machines. A computer in the modern sense goes beyond the capabilities of calculating numbers but it is working with library of programs and is used to store textual information in a UNIX environment.

Before it makes sense to explain the inner working of the Z22 there is a need provide the context in which the machine was developed. The starting point is, that a mechanical calculator (a Comptometer) is available.[1] The Comptometer has buttons to enter numbers and other buttons to activate a function like +, - and so on.

The Zuse Z22 and other machines from the same inventor are improved versions of the comptometer. They are able to process data much faster, also they are much easier to use because of the mentioned Freiburger Code. That means, entering assembly instruction shouldn't be seen as a problem but as an improvement over former interaction with a machine.

Unfurtunately, the history of computing is moving very fast. The comptometer has felt out of fashion since the 1950s.

[1] https://en.wikipedia.org/wiki/Comptometer

BEAM robotics in software

The original BEAM movement took place from 1990 until 2000. It seems that the principle has come to a dead end. Nevertheless, BEAM robots are looking interesting and it makes sense to take a closer look into the self understanding of the 1990s DIY robot movement.

At first it should be mentioned that in the 1990s there was the last great AI winter available. It was the time before the advent of deep learning and most robotics projects were canceled. During the 1990s it was impossible to build biped robots anad there was general pessism available if AI can be realized at all. BEAM robotics can be seen as a crisis phenomena towards the AI winter in the 1990s. The main principle is, to build robots without a brain. They are equipped with actuator and a battery but they do not have a program and they can't decide something. Instead the control is realized with random oscillators known as nv neurons.

For reason of simplication it makes sense to assume, that a BEAM nervous network is a normal 555 tiimer IC which generates a sine osscilator signal which is send to the servo motors. This signal will produce the forward movement. Certain input signals like touch signals and light signal can modulate the signal.

From a technical standpoint BEAM Robotics doesn't belong to AI history but its the opposite. AI is about a computer program which makes a computer think like a  human while BEAM Robotics is an electronics project without such a software.

Because the mentioned 555 timer chip can be emulated in software very well, there is no need to buid robots in physical hardware Instead the brain of a robot can be realized as a single line of code in python which is an osscilator. The same  movement of a beam biped walker can be emulated with a modern arduino microcontroller and this might explain why BEAM robotics has disapeared after the year 2000. Nevertheless, a classical analag BEAM robot looks more interesting. In the 1990s most examples were not realized with the 555 IC but with analog circuits with dedicated resistors and capicitors which produces a chaotic behavior and a chaotic layout both.

Nevertheless it should be mentioned that even physical BEAM robots from the 1990 were never intelligent or were able to do useful tasks. The movement was either realized with remote control or with randomized osscilator generators in hardware. Modern robotics can learn a lot from this approach. BEAM robotics is referenced as a minimalist attempt in creating robots. It was an ultra low cost technology without any complex hardware nor dedicated theories. Most robots were nothing but a paperclip mounted on a servo motor. So its some sort of physical artificial life.

After the year 2000, beam robotics has felt out of fashion in favor of computing oriented AI disciplines like Deep learning, Semantic web, and microcontroller based robotics. Especially the last one has replaced former DIY BEAM robotics entirely. Today entry level robots are always computer controlledd and they are programmed to fulfill simple tasks like line following or maze solving. Such a microcontroller controlled robot is more flexible than former beam robots. It allows to explore different approaches including chaotic pseudo random behavior and its much easier to rewrite the hardware. The main problem with analog CPU free robotics is that every circuits requires new parts and these parts are connected with solder similar to amateur radios in the 1950s. This is less interesting than building robots with a microcontroller and realize the logic in software.

But from an aestihic perspective, modern arduino based robots are looking a bit boring. Most examples are realized with a brick on top of a wheel chasis which is standardized. Another major criticism against microcontrollers is that this technology forces the programmer to think into a certain direction. The typical question is mostly which sort of java program is needed to fulfill a task. This perspective prevents that possible non programming alternatives are investigated.

The advent of BEAM robotics

Between 1990 and 2000 there was a short period in robotics which was working different from academic robotics. So called BEAM robots were invented by Mark W. Tilden and according to the self description, it works with analog electronics like solar cells and mechanical beauty.[2] Indeed, most of the robots are looking completely different than any robot before. The most dominant property is the absence of a program controlled computer.

Unfortunately, the BEAM movement has stopped after the year 2000, in favor of classical DIY robotics projects based on the Lego NXT brick and Arduino microcontrollers. What is possible from today's perspective it to reverse engineer the former BEAM movement with the goal to understand why it was started.

Around the year 1990 there was no robot available in the university domain who was able to walk with 2, 4 or even 6 six legs. In contrast, BEAM Robots were able to do so. A BEAM walker can walk while a BEAM snake imitates the locomotion of an animal. The explanation for these advanced movements are located in the nv neurons, which is special term for the logic inside a BEAM robot.

In a more elaborated language a BEAM robot is an oscillator realized in hardware. Components like capacitors, resistors and triggers are combined into analog circuits known as Central Pattern Generators. These pattern generators are normal phase modulated feedback loops. From a mathematical standpoint such a pattern is equal to the sinus function on the time axis which produces a certain behavior for the servo motors.

The interesting situation is, that the same rhythmic movement can be generated without an analog circuit but with a classical MS excel sheet which calculates the Sinus function and has some parameters to adjust the height and length of the output. After adjusting the parameters the resulting function will make the robot legs walk forward.

In other terms, Mark W. Tilden has invented a sinus tone generator build in analog circuits. That is the reason why a BEAM walker doesn't need a complex computer program but the motor signals are realized with a more simpler principle, similar to early analog music synthesizer.[1]

[1] https://en.wikipedia.org/wiki/Analog_synthesizer
[2] https://en.wikipedia.org/wiki/BEAM_robotics

Numbering photos with the Luhmann id

 Facebook is the largest photo sharing website in the world. The amount of daily uploaded pictures is at least 300 million per day. The best way to manage this amount of information is filename which is working with an alphanumerical key. Example:

1_holiday.jpg
2_christmas.jpg
2a_christmastree.jpg
2b_Deliciouscake.jpg
2b1_recipeforcake.png
3_sport.jpg
3a_photoofshoes.jpg

The numerical ID for each photo remains the same. It is given once during the creation. New photos can be added to the collection by choosing the id according to the existing system. The files are sorted by its similarity. In the literature the concept is described as hierarchical clustering of images

Homecomputers until the 1990s

 Before the advent of today's PC technology which is dominated by Windows and Linux operating system there was a much smaller community available of computer enthusiasts. From 1980-1990 most of todays computer hardware and software was invented in the first place and the magazines which were introducing the subject to a readership were sometimes very well informed. In that period two dominant computer systems were available which was the Commodore 64 and the MS DOS PC.

At first it should be mentioned that on IBM PC hardware until the year 1990 the well known Windows operating won't be running fast enough. The only available operating system for early DOS Computers was DOS itself which is a single user, single tasking operating system. In comparison to the Commodore 64 advantage was that it was much easier to write software for MS DOS than for the C64. 8bit homecomputers with 64kb and less main memory and without any harddrive are not capable in running compiled C programs. The only sense making programming technique is the Assembly language. In contrast, early MS DOS PC until 1990s are working fine with c compilers. These large scale programs including the build in libraries can be installed on the small hard drive (less than 100 MB) and it is possible to write and debug software direct on a MS DOS PC.

The reason why this workflow is described in detail is because its working the same like modern programming workflow in the 2020s. That means, in the last decades the programming itself hasn't changed that much. Typing in C code on a 286 PC and compile it into machine code or typing in java code into a mto a more recent 4 core PC is based on the same abstraction mechanism. The human programmer has a set of libraries and combines existing functions into a new software.

Somebody may argue, that the difference between Assembly language and Turbo C is small because both programming language were invented decades ago. This assumption is wrong. Learning assembly from scratch and write larger software is very complicated while the same task in C can be handled easily. The difference is that the C language is a problem oriented language while assembly is hardware oriented. The typical assembly program is written for a certain CPU and a certain adress space in the main memory, while c program are written around a certain domain like a game or a word processing applications.

The only negative point of the C language are the hardware requirement. C assumes that an entry level 286 MS DOS PC is available which has 600 kb of RAM and a harddisc of 10 MB and more. Its not possible to run  a compiler with less RAM and without a harddrive. Even if some C compilers are available for the C64, it can't be used in reality for writing programs. The cause is that a compiled C program is much slower and will need more RAM than a hand coded assembly program.

The main difference between the C64 and the MS DOS PC Is, that C64 programmers claim that Assembly language is a here to stay. This assumption is the result of the lower hardware of the C64 which prevents to use any other programming language than Assembly. Even if its possible to write Assembly program on the MS DOS PC most programmers prefer a c compiler because the language allows to increase the productivity. Especially if a graphics library is available and the programmer is familiar with the computer its possible to write simple games in a short amount of time, very similar to what today's programmer can archive. in other words the existence of a c compiler is the single cause why MS DOS PC have replaced 8bit homecomputers.

Benchmarking operating systems

 Before different operating systems can be compared against each other there is a need to define a scale for an objective judgment. Possible measurement in the past are: number of users, size in Megabytes, or easy of usage.

One important measurement isn't mentioned in the list which is hardware support. Device drivers are a seldom investigated subject in operating systems but they have a great impact on the success or failure of an os. The main difference between Linux and KolibriOS isn't the programming language (C vs. Assembly) but its the hardware support. Linux supports out of the all graphics cards, while KolibriOS is restricted to VESA modes. Linux supports wifi cards while KolibriOS has only support of ethernet cards.

Even if someone likes the idea of using the KolibriOS for daily usage he will notice that most of the hardware isn't working. So he will decide against the system. The main reason why Linux is rejected in favor of Windows can also be explained with device drivers. The support in Windows is better, and additional features like power savings are supported in WIndows, while Linux has only basic support which is provided with a delay of 3 years after new graphics cards are available.

Let us assume that are no existing operating systems available but the goal is to write a perfect operating system from scratch. The core feature for a desktop OS is to support all the hardware out of the box indlucing the advanced features like certain resolutions and Energy saving modes. Each operating system is judged by this ability.

The reason why device drivers are usually ignored as a benchmark criteria is because this important subject is difficult to realize. Programming the device drivers for all the hardware is a large project. Even in the Linux project (which is the largest open source project today) there is no enough manpower available for this task. The assumption is that around 250k different hardware devices are available and programming the drivers for all of them need will produce a binary blob file of 1 gigabyte an more.

A collection of device drivers is the core element of any operating system. Any other part like a c++ compiler, a GUI environment or certain application software can be added later. in case of doubt existing source code can be recompiled for a new operating system, but the device drivers can't. They have to be written from scratch.

Different operating systems are working with different philosophy how to create the device drivers. In the Windows ecosystem the assumption is, that hardware companies are producing the code in a closed source fashion. Linux assumes that a group of voluntiers are writing the hardware drivers for the Kernel while KolibriOS says that the hardware drivers are written in Assembly language for only basic devices like an ethernet card and USB mouse.

The main reason why desktop opeating system are hard to program is because the endless amount of hardware available for desktop PC. There are hundreds of different graphics cards, network cards and soundcards availalable. And each card has multiple parameters which can be changed. Apart from the VESA standard which wasn't updated since decades there is no hardware standard available and every new  hardware has a need for a new driver. Without a driver the device won't interacting with the computer or it will consume too much energy. So we can say that a device driver is the single point of failure in an operating system.

An additional problem is that device drivers are usually written in Assembly or in hardware level C which is both complicated to master and the amount of experts in this subject are low. This makes it unlikely that entire desktop operating system can be created from scratch. In contrast to writing application software, a device driver is needed by any user group. No matter if the PC is used for writing in a letter or programming something in both cases there is a need for a graphics driver otherwise the PC won't work at all.

In summary a device driver collection is difficult to program, has a huge code size, is needed by every user and has to support 250k different devices which results into a very complicated project. Only large organizations have the manpower to create operating systems but not amateurs.

Introduction to the Linux operating system

Books about the Windows operating system are assuming that the user has never seen a computer before and needs guidance for most tasks. The typical windows book explains, that a computer consists of a mouse, a USB interface, a printer and a monitor and the user is asked to start a program or modify settings in the menu.

It doesn't make sense to transfer this language style to Linux operating systems because Linux wasn't created for computer newbies but for experts. The simple difference between both user groups is, that computer newbies can't program in Python while computer experts are able to do so. As a consequence the typical book about Linux should assume that the user is familiar with the Python language.

The positive effect is, that the explanation what Linux is about can be shorten drastically. Linux allows to execute self written python programs, consists of a powerful package manager and is distributed for free. If the user have no need for such functionality he probably doesn't need open source software and is recommended to use existing Windows software.

The reason why the market share of Linux is much smaller is because the amount of programmers is small. What we can say for sure is that non programmers won't feel comfortable with Linux. Its not about a certain windows manager like gnome vs xfce and it is not about the position of the start menu, but without programming skills in at least one language the Linux OS doesn't make sense for the user.

From a programmers perspective it is pretty easy to understand the Linux operating system. In comparison to write a medium size software project in Python, the interaction with Linux is much easier. There is no need to call a method in a python program, nor implement a recursive function, but the installation of linux is gui driven and apart from clicking on some buttons no further skills are needed. 99% of existing software engineers are able to install and use Linux with ease.

Let us take a closer look into the numbers. There are 1000 million PC worldwide available and around 27 million programmers. This ratio of 2.7% is the maximum market share of Linux on the desktop. It is not possible to growth the market share of Linux above this level because this would imply that non programmers have installed Linux on the desktop PC in favor of Windows.

The Linux kernel as a device driver repository

 Most of the lines of code within the Linux project are about device drivers. Its not about about 1000 lines of code, nor 1 million lines of code but device drivers need around 20 million lines of code within the Kernel. Instead of analyzing what the drivers are doing from a technical perspective there is a need to describe the philosophy.

In classical closed source operaring systems, the device driver is provided by the hardware manufactorer. A certain company is producing a flatbad scanner and has to deliver the hardware itself plus a 3.5" floppy disc which contains of drivers to run the hardware. The same issue is there for a mouse, an usb stick, a camera and so on. In the 1990s it was common that device drivers where delivered on physical discs inside the box of the hardware. The end user was asked to insert the disc into the pc and run a program which was mostly setup.exe to install the drivers. Then and only then the hardware was working.

More recent version of Windows are installing the needed drivers in the background without human interention. The Windows operating system detects with plug and play which hardware is in use and downloads the drivers from the internet. These drivers are mostly writtein in C language and compiled into executable binary programs.

In contrast the linux kernel is working with open source hardware drivers. The Kernel is basically a collection of drivers for getting access to all the devices like cd-rom, ssd, ethernet card and so on. The shared similarity between Windows and Linux is that somebody has write all the drivers. Within the Windows ecodsystem this task is handled decentralized. Each company has to write its own drivers and doesn't explain to the public what the code is about. In contrast, Linux is working with a centralized model. There is only a single kernel and all the drivers are in the kernel.

The focus on the device drivers might explain why apart from the major three operating systems (win, linux and macos) there are no alternative projects available for desktop PC. Everybody who likes to establish a new operating system has to make sure that all the hardware is working with this operating system. The only way for doing so is to write all the needed drivers from scratch. This will take a lot o man years. Because of this single reasson there is no Forth operating system, and smaller projects like Haiku are not working well enough for production machines. The cause is, that most devices won't work with these devices. That means, the proud user of the Haiku OS is plugging in an USB stick into the PC but nothing happens. The OS isn't detecting the hardware and has no executable driver for this hardware.

The major cause why device drivers are released as closed source for Windows is because it is a time consuming task to write the software. A single expert programmer is able to create around 10 lines of code per day. Even if the programmer has access to all the hardware specification and has a lots of experience he will need months up to years until the driver for a certain device was written. It doesn't make sense for a hardware company to release the software as open source because the source code including the ability to write code for new devices is a asset for a company which can't be shared with other comapnies.

The Linux ecosystem is working the opposite way. Its a mandatory rule that all the code has to be released in the open source version. If a certain driver is not available then the device won't work with the kernel. The result is, that the quality of the hardware drivers in Linux is lower and that the amount of drivers is lower. There are lots of hardware available which is supported in Windows but not in Linux. Its not of technical requirements but because of the ecosystem and especially the time consuming effort to write a driver in C.

Suppose it would be possible to create a universal device driver in 10k lines of code which can interact with any possible hardware. Then it would be pretty easy to create new operating systems from scratch. All what is needed is this single device driver and some additional programs can be added. Unfurtunately there are technical limitations which prevents that such a universal driver can be realized. Existing computing hardware is so complex and so different that any single device will need a dedicated driver.

Let us estimate how many different hardware devices are available. suppose a single device like an ethernet card is controlled by driver with 10k lines of code. There are 20 million of codelines in the Linux project for hardware drivers., so the total amount of different devices is 2k. It is equal to a large museum fully equipped with computer hardware from floor to ceilling. In addition, modern computer hardware is more complex than previuos models For example the avarage mouse is equipped with infrared sensors while the typical mouse in the 1990s was using a simple rubber ball to detect the movements. So we can estimate that in the future the complexity will grow further which results into more different devices which have a need for more codelines.