Thanks PSI, Trug and Wildfire!

I will probably remember these call-names forever as they were the initial guiding lights of my developer career.

Somewhere around 1994 our school received the first 386 computer. It had also a SoundBlaster Vibra card. It was a fantastic machine compared to the old monochrome 86 and 286 machines we had in the lab. In order to test the machine we decided to play some games or install Windows... In the end somebody remembered that he has something extraordinary that runs only on 386 machines. It was Future's Crew Second Reality demo. Unzipped the two floppy archive. Started it. Watched it to the end. We were speechless. We watched it again. And then again. And again. It was clearly addictive for us. We wanted to do the same tricks as PSI, Trug or Wildfire.

Up to that point I was not much interested in programming. Although I was learning algorithms I didn't had any practical use for them. Second Reality changed that. It was clear that if we wanted to do something similar to what Future Crew did we had to learn. In 1994 obtaining documentation was quite hard. There was no internet available for us, no access for BBS or similar sources. The only way to get some info was from older friends that were already at the university and had access to information. I collected dozens of disks with text files about assembly language,VGA graphics, protected mode, interrupts, algorithms. It was the moment I started to understand algorithms - Bresenham's Line algorithm was one of the revelations. Then slowly, in about one year, my colleagues were able to replicate most of the things we have seen in the demo. It was a great achievement for us as we did not reverse engineered the code but created a similar demo using from scratch implementations. As the 386 machine was hard to reach the demo worked reasonable well on 286 processors.

I learned a lot in that year. From programming to system architecture, from peripheral handling, low level programming and basic DSP to objects and data structures. I learnt advanced algebra because I needed it for the code and 3D stuff and improved my physics due to the fact I had to understand also the internals of particle systems. It was probably the year in which I learnt the most in the software field. The knowledge gained then proved to be useful for many years as it eased my CS studies a lot.

Again I have to thank PSI, Trug and Wildfire for opening up a world of endless choices and possibilities! I am still impressed today of Second Reality as it continues to be stunning from every possible aspect graphics, sound code. It seems that others also consider it a marvel, the demo was included in Slasdot's top 10 hacks of all time. I learnt that if you have a goal and you are surrounded by smart colleagues (Dan, Vale, Cipi, Raul, Adi, Robi) things become possible and, through percolation, unexpected, marvelous results appear.

Thanks PSI, Trug and Wildfire!

Created on 2018-01-14 09:37

Published on 2018-01-14 10:38

I will probably remember these call-names forever as they were the initial guiding lights of my developer career.

Somewhere around 1994 our school received the first 386 computer. It had also a SoundBlaster Vibra card. It was a fantastic machine compared to the old monochrome 86 and 286 machines we had in the lab. In order to test the machine we decided to play some games or install Windows... In the end somebody remembered that he has something extraordinary that runs only on 386 machines. It was Future's Crew Second Reality demo. Unzipped the two floppy archive. Started it. Watched it to the end. We were speechless. We watched it again. And then again. And again. It was clearly addictive for us. We wanted to do the same tricks as PSI, Trug or Wildfire.

Up to that point I was not much interested in programming. Although I was learning algorithms I didn't had any practical use for them. Second Reality changed that. It was clear that if we wanted to do something similar to what Future Crew did we had to learn. In 1994 obtaining documentation was quite hard. There was no internet available for us, no access for BBS or similar sources. The only way to get some info was from older friends that were already at the university and had access to information. I collected dozens of disks with text files about assembly language,VGA graphics, protected mode, interrupts, algorithms. It was the moment I started to understand algorithms - Bresenham's Line algorithm was one of the revelations. Then slowly, in about one year, my colleagues were able to replicate most of the things we have seen in the demo. It was a great achievement for us as we did not reverse engineered the code but created a similar demo using from scratch implementations. As the 386 machine was hard to reach the demo worked reasonable well on 286 processors.

I learned a lot in that year. From programming to system architecture, from peripheral handling, low level programming and basic DSP to objects and data structures. I learnt advanced algebra because I needed it for the code and 3D stuff and improved my physics due to the fact I had to understand also the internals of particle systems. It was probably the year in which I learnt the most in the software field. The knowledge gained then proved to be useful for many years as it eased my CS studies a lot.

Again I have to thank PSI, Trug and Wildfire for opening up a world of endless choices and possibilities! I am still impressed today of Second Reality as it continues to be stunning from every possible aspect graphics, sound code. It seems that others also consider it a marvel, the demo was included in Slasdot's top 10 hacks of all time. I learnt that if you have a goal and you are surrounded by smart colleagues (Dan, Vale, Cipi, Raul, Adi, Robi) things become possible and, through percolation, unexpected, marvelous results appear.

Talks, Tournaments and Pageants

Created on 2017-12-11 09:45

Published on 2018-01-09 20:05

I have recently seen lots of adds inviting developers to compete in massive coding tournaments in order to get hired as architects for quite a lot of money, considering that it is remote work.

It evoked me a medieval tournament in which the knights were fighting and showing off their skills in order to conquer the heart of a lady and obtain her hand into marriage.The tournaments were always bloody and had only one winner. The skills proven there are not the skills that sustain a family, the skills for durable builds. It was just a display of weapon usage mastery, not a display of strategic vision, abilities to provide food or care for offspring.

Does this style of competition works for hiring architects or any other role?

For the sake of the argument let's define what is the role of an architect. It is quite hard to define it exactly but the architect should be a technical lead with hands on expertise, up to date with technologies and experienced enough to coach others. More important he has to be a good communicator.

So how would one measure these skills? You can measure the coding skills or the design abilities but for sure many of the other non-technical characteristics of an architect are hard to be measured objectively in a tournament. Coding is for sure a very important aspect of the job and should be measured the same way as with programmers. But how do one measures the technical insight? How do one measures experience? How about the capacity of teaching and explaining? These are also important qualities and often do make the difference between equally gifted technical individuals. Well, in a tournament how can one measure them as it is time boxed, zero sum game, check the correct answer type of contest. It reveals nothing about personality, it just proves that the candidate is a fast coder. Even in reputable companies as Google and Amazon the interview is in person, it has human touch, is customized for the candidate. I, for one, love to hear and learn from people. I love seeing their train of thoughts, debating solutions offering alternatives. Interviewing and hiring is not a pageant, is rather a matchmaking, it is not a zero-sum game. In the end the idea is that everybody wins. The "knight" will get the princess and the princess will get the most suitable candidate not the most muscular code-gladiator. Talking opposed to tournaments and pageants gives immediate feedback gives side channel information as body language, capacity to relate. Maybe these are not really important for remote workers but are important for these who have to interact with people.

If this applies for architects then for sure it applies to project managers, to creatives, to business analysts. Some skills cannot be judged just in the terms of a pageant/contest. Some things are not born in sparks of inspiration but come in time through idea sharing and debating, the spark is the result of percolation of a sufficient number of ideas.

Path towards future

Created on 2018-01-09 18:49

Published on 2018-01-09 19:54

I am a long time Unix (Linux mostly) user. I have started with Linux somewhere in 1995 having the first distribution on about 40 1.44 MBytes disks. After about one week of struggle I succeeded to run fvwm under X. Then I become a fan. Everything seemed natural and easier in Linux than in DOS or even Windows.

As the time passed I learnt more and more about Unices. I worked with FreeBSD, OS-X and Solaris. Each of these had some features that I really wanted to be available in Linux.

When I first worked with Solaris 10 I hated SMF. But after some time I discovered that it was better than the BSD init or SystemV init on Linux. I liked the declarative approach and simple dependency between services. I looked for some similar solutions on Linux but I was not able to find something at the same level. Apple's launchd was promising but licensing issues and plist editing were show stoppers. Upstart seemed always half cooked, somewhere between init and SMF. OpenRC was good but quite niched. So when "systemd" appeared I felt that it really happened for Linux to gain a major uplift. systemd solved many things I was missing in old init systems. Automatic daemon restarts and monitoring (I used to have monit for this), uniform syntax for service startup files (INI syntax is easier to maintain than XML especially over slow lines to remote systems using vim), device management, no more fancy shell scripting in the files, programability (it offered APIs). Working with systemd made some of the mundane tasks of creating installable packages bearable. When I started to use ansible tools I also remarked how easy was to control the behaviour of the system through systemd interfaces and tools. Farewell init! I have never looked back on it since then. Frankly I do not understand why people hate systemd so much. For me it solved most of the issues so I am on its bandwagon.

Another thing I wished for is easy install of application as OS-X drag and drop. On Unices this is still problematic. Deb, rpm and other package formats are managed by a myriad of tools (yum, dnf, apt, aur, zypper, pkg, ips, ...) each one with different syntax and options. A nightmare. Then, around 2008 I discovered GoboLinux, a distribution that really did something in the direction of simpler package management. Gobo abolished FHS and offered a better alernative. Every application is installed in its own directory and from there is symlinked to a central location. Traditional Unix directories are hidden from the user at kernel level hence offering a clean view over the system. Pretty neat. Even nowadays some things as flatpack cannot achieve this.

A third thing I wished for was dtrace on Linux. Solaris, FreeBSD and OS-X have it but on Linux there was no similar software. Not even something as mdb was available on Linux. Dtrace made the supervision of systems easy. It was lightweight and extensible. I was able to monitor realtime priority processes on Solaris with as little as 5% performance hit. Only recently dtrace started to be developed on Linux but it's not yet ready for primetime. That's kind of sad as it would be invaluable in the current context of cloud application where metrics and performance are crucial for scalability decisions. Dtrace would enable telemetry at a very low cost even for applications that were not built with telemetry options.

I have the impression that Linux is slowly moving towards something more future oriented while still keeping ties with its Unix origins. I do not feel that these are breaking Unix philosophy but rather offer an up to date tooling while holding the same old truths and principles in place.

As Arthur Schopenhauer said: "All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident". The same in my opinion will happen with some of these. They will become parts of the next generation Linux distributions overcoming all the present opposition.