Πυροσβεστικό Μουσείο

Μια και ο Θ. δείχνει ένα ιδιαίτερο ενδιαφέρον για τα “πυροσβεστικά” σήμερα πήγαμε οικογενειακώς στο Πυροσβεστικό Μουσείο. Επειδή είμασταν και οι μοναδικοί επισκέπτες εκείνη την ώρα, είχαμε την τύχη να έχουμε πλήρη ξενάγηση από τον πυροσβέστη που είχε βάρδια στο μουσείο εκείνη την ώρα.

Το μουσείο είναι εντυπωσιακό, ειδικά εάν σκεφτεί κανείς πως προσπαθεί να καλύψει το έργο της Πυροσβεστικής από την ίδρυση του Ελληνικού Κράτους μέχρι και σήμερα. Έχει οχήματα και εξοπλισμό πριν από το 1900, μερικά μάλλιστα είναι πιστοποιημένο ακόμα και σε ποιες φωτιές έχουν χρησιμοποιηθεί. Επειδή ο Θ. έδειξε μεγαλύτερο ενδιαφέρον για τον πιο σύγχρονο (και οικείο σε αυτόν) εξοπλισμό, θα πρέπει να ξαναπάμε, γιατί υπάρχουν αντλίες και άλλοι μηχανισμοί που αξίζουν περισσότερης προσοχής.

Το Πυροσβεστικό Μουσείο είναι ανοιχτό για το κοινό Τετάρτη και Κυριακή, οπότε καλό είναι να κάνετε ένα τηλέφωνο πριν πάτε.

city

21 χρόνια.

Whither Software Engineering

The July 2009 issue of the IEEE/Computer magazine in its “32 and 16 Years Ago” section remembers that 16 years ago:

Software Engineering (p. 68) “The IEEE Computer Society Board of Governors has approved a motion to establish an ad hoc committee to serve as a steering group for evaluation, planning, coordination, and action related to establishing software engineering as a profession. The action came during the board’s May 21 meeting in Baltimore, Maryland, in conjunction with the International Conference on Software Engineering.”

In the same issue Neville Holmes writes:

“Now software engineering aims to be a branch of engineering, but is finding it difficult to be accepted as such. The problem is that other branches sensibly use the skills and talents of technicians to ensure the success of their professional work. Software engineering doesn’t; it won’t let go of programming”

It took a lot of people and effort to design programming languages and models (procedural, functional, etc) that tried to define how people should practice programming. It took only two pieces of software to make anyone think that is a quality programmer: Access and Visual Basic. So Holmes is right: Let go of programming; it is a lost cause.

After reading one of my posts, John Allen (author of “Anatomy of Lisp“) sent me his unpublished manuscript “Wither Software Engineering” [pdf] and corresponding presentation entitled “More Ballast!” which also deal with the subject of whether Software Engineering is actually a branch of Engineering. You can freely download the pdf slides and audio of an older version of the presentation (Title: History, Mystery and Ballast). In them Allen deals with the transition of traditional Engineering from an experience-based craft to a science-based discipline. Much of the historical data he uses come from “Engineering education in Europe and the USA, 1750-1930“. I have also read “Education, technology, and industrial performance in Europe, 1850-1939” (also translated in Greek) on the subject.

Basically Engineering training followed the path of:

Apprenticeship for a long period of time under the supervision of an Engineer
Study (and get certified for) the equipment of a specific manufacturer paying a considerable amound of money, and
University studies

Does this ring a bell regarding today’s IT arena? It is exactly for this reason that Allen was motivated. Mathematics and Physics transformed traditional Engineering. Can this be done with computation and mathematical logic? His presentation closes with:

It is this kind of education, not Java vocational training, that will bring McCarthy‘s 40+ year old quote to life:

“It is reasonable to hope that the relationship between computation and mathematical logic will be as fruitful in the next century as that between analysis and physics in the past. The development of this relationship demands a concern for both applications and for mathematical elegance.”

At least for programmers we are not there yet. The link between their work and mathematical logic is not obvious for all.

In the closing discussion of HDMS 2009 there was a debate whether “their stuff” could be considered as a branch of Engineering, regardless of liability issues. Alex Labrinidis said “Give us 2000 years to perfect bridge building and then come back asking for liability”. Labrinidis is wrong. Hammurabi solved the issue of Engineering liability back in 1790 BC:

If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then the builder shall be put to death.

After the discussion ended Panos Vassiliadis pointed to me Peter J. Denning‘s “Is Software Engineering Engineering?” article which concludes:

“We have not arrived at that point in software engineering practice where we can satisfy all the engineering criteria described in this column. We still need more effective tools, better software engineering education, and wider adoption of the most effective practices. Even more, we need to encourage system thinking that embraces hardware and user environment as well as software.

By understanding the fundamental ideas that link all engineering disciplines, we can recognize how those ideas can contribute to better software production. This will help us construct the engineering reference discipline that Glass tells us is missing from our profession. Let us put this controversy to rest.”

Bertrand Meyer adds that the one sure way to advance software engineering is to “pass a law that requires extensive professional analysis of any large software failure”. Meyer is not alone. “Where are the dead bodies?” asks Derek M. Jones who also writes: “The lack of dead bodies attributed to a software root cause suggests that it is very still early days for the field of high integrity software development.”

There you have it: No dead bodies, no Engineering. Hammurabi knew that long before Engineers did.

You may now want to read “Cargo-cult Engineering” and “It’s not Engineering, Jim“.

#include <std/disclaimer.h>

Ken Thompson

Ένας καλός φίλος μου έστειλε χτες βράδυ με email ένα attachment:

Επειδή ο φίλος δεν μπορούσε να βρει κάποιον να του εξηγήσει πως βρέθηκε αυτό το name tag, ρώτησα τον ίδιο τον Ken Thompson και ιδού η απάντηση:

i dont remember exactly, but i think it was in the mid 80’s. i was invited by the government – department of science or technology or something like that. the occasion was at a time when the government was trying to require unix for sub contractors for standardization.

Ταυτόχρονα ρώτησα και τον Γιάννη Κοροβέση, έναν από τους πρωτεργάτες του Internet στην Ελλάδα:

Λοιπόν, ναι ήμουνα και παρών στο Ξενοδοχείο (Intercontinetal ?) γύρω στα 1989 μαζί με τον ΚΕΝ ήταν και ο B.Gopinath και ένας τρίτος που δεν θυμάμαι προς το παρόν.

Οργανωτής ήταν ο Γιάννης Κοζατσας του ΥΚ της ΓΓΕΤ του τότε (ΥΒΕΤ, Ε=Ερευνα)

Το πιο απλό γεγονός, μία απορία μπορεί να οδηγήσει σε κομάτια της Ελληνικής τεχνολογικής ιστορίας που είναι σχετικά άγνωστα.

Όποιος ξέρει / θυμάται περισσότερα για το γεγονός, παρακαλείται να σχολιάσει.

ΥΓ 2024/09/11 Στο twitter ποσταρίστηκε το σχετικό ρεπορτάζ από τον τότε τύπο:

sendmail: Should I use $*, $+ or $- ?

When writing a sendmail.mc rule, you can use some operators on the left hand side, like $- (match exactly one token), $+ (match one or more tokens) and $* (match zero or more tokens). You may find yourself in a situation where for example you want to use a certain delivery agent for some of your users. Normally you would write something like the following:

LOCAL_CONFIG
Kmitsos btree -m -a.mitsos /etc/mail/mitsosusers

LOCAL_RULE_0
:
R$-  < @ $=w . > $*              $: $(mitsos $1 $)  $3
R$- . mitsos  $*     $#mitsos $: $1

The above example seems to be correct, right? But what if you have a user in mitsosusers that contains a dot (.) in the user name (for example yiorgos.adamopoulos)? Because the . is a token separator (see the OperatorChars definition in your sendmail.cf), $- will not match the name. So the correct ruleset in this case is:

R$+  < @ $=w . > $*              $: $(mitsos $1 $)  $3
R$+ . mitsos  $*     $#mitsos $: $1

I got bitten by this sometime ago, and that is why I am sharing it.

What I like about the NoSQL crowd

Although I am not a big fan of the NoSQL movement (mostly because many of its advocates use arguments I do not agree with) there are a few things that I like about the NoSQL crowd and I want to write them down^*. Most of what follows stems from discussions through the years with our DBA and some friends who are members of the “Greek Database Mafia“.

For more than two decades the dominance of the relational model (even though no commercial system fully implemented it^†) was undisputed. Nobody ever got fired for choosing a commercial RDBMS for an application, where instead one would look suspicious if one dared to propose something different. This situation is no different than what Rob Pike described in “Systems Software Research is Irrelevant” for Operating Systems:

For example it took 10+ years for the R-Tree to enter the commercial systems, although it was solving a real problem. In the meantime if you were lucky and your system offered extensibility you could write it on your own.
No matter how novel the system, for it not to be marginalized it had to have an “SQL layer”. No SQL queries, no sales. Provide an SQL layer and all innovation of the product stays unused.
Ones proposal for an RDBMS purchase had to be among three or four commercial products. Anything else would likely be considered “a hacker’s choice” because “We make money! We cannot go that way!”

You could say that databases outside academic research had come to a halt. You don’t believe me? Just ask Yannis Ioannidis who uses to say that “Databases are dead“^‡ in the most emphatic way when he wants to stir things up in a conversation.

And this is what I like about the NoSQL crowd (== implementers, advocates and integrators) . They do not care about established standards. They are not afraid to experiment in a “real environment”. Some of them may focus on a single problem and solve it well. Others may aim at a wider range of problems. But no system is stopped from being developed and deployed because it not “SQL compilant” or not relational. And even though some of these solutions resemble CODASYL^o, once again there is action in the field.

But please people, stop marketing them as a “one solution fits all”. For we will again end up in a stagnation era, just like when everyone was storing stuff in an RDBMS for lack and fear of better suited solutions. They do not invalidate relational systems. They fill in the gap left by them.

[*] – As I had promised.

[†] – By the way, did you know that GROUP BY works outside of the “relational box”?

[‡] – I have heard him say this while giving a speech.

[o] – “one usually gets a low-level record-at-a-time DBMS interface“, says Mike Stonebraker.

Open Systems Security – an Architectural Framework

“In the old days” when security information was scarce and many of us began shaping our security mentality (be it white, gray or black) by reading “Improving the Security of Your Site by Breaking Into it” and the Computer Security FAQ and running tools like iss and Crack. I think it was there that I first read about Arto Karila’s PhD thesis. Even though it is an OSI based document, it helped understand basic concepts. However there were two problems with the document:

It was hard to find, and
It was in a weird PostScript format that even modern versions of ghostscript refuse to display.

With the help of a friend I managed to transform it to PDF and upload it to Scribd: Open Systems Security – an Architectural Framework

Of historical value mostly.

Update 2013/04/13: Now available at https://github.com/a-yiorgos/karila

Device drivers in Java?

The following tweet by @DSpinellis:

#USENIX @AnnualTech M. Renzelmann Decaf: Moving Device Drivers to a Modern Language (Java). He says performance impact is 1%

talks about “Decaf: Moving Device Drivers to a Modern Language” which describes a system where large parts of a driver can be written in a better language than C, the example here being Java.

I was certain that this was not the first time I had read about such an idea. This weekend I was able to go through my archive and find out the reference. Back in January 1997 in the NT Insider (Volume 4, Issue 1) Peter Viscarola, while criticizing the multitude of startups founded by anyone who could code a Java applet (this was a pre-dot-boom era remember) wrote:

It’s obvious that we are missing a real opportunity here to capitalize on the convergence of these trends. We need to immediately fund a start-up company to develop a package for writing Windows NT drivers in Java. THINK of it! We could have processor architecture independent device drivers that don’t even need to be recompiled in order to support X86, PPC, and Alpha machines! Amazing! We could create a visual driver development environment, complete with cute animated assistants. And, the drivers could probably have a visual component to them, so you could actually see your toaster-oven driver doing its work. Cool! THEN we could all be challenged, and have fun, and get rich at the same time. Wow! Why didn’t I think of this before?

It would be nice if we could see Peter’s views on the subject 12 years later.

re: The Humbling Power of P v NP

academia_vs_business — Some engineer out there has solved P=NP and it's locked up in an electric eggbeater calibration routine. For every 0x5f375a86 we learn about, there are thousands we never see.

In “The Humbling Power of P v NP“, Lance Fortnow urges theorists to try and solve P v NP “not because you will succeed but because you will fail” . This is the Kobayashi Maru character test for theorists it seems.

So what about non-theorists?

My answer is: So what if a problem is NP-complete? Does this mean that we are going to use that fact as an excuse to not solve it, or present a lousy hack as a solution? Or do people think that such problems do not come along the way of “a real professional”? They do, but theorists are trained to recognize them when they see them.

Just like theorists then, “practical computer people” must try to solve (using whatever tool they see fit) an NP-complete problem (like the TSP for example). Not because they will solve it optimally, but because there will always be a better solution. And by seeking it and understanding that “computation is a nasty beast” they will become better ~~programmers~~ professionals.

Update: You should also read:

Asking Questions…

We have seen that nobody should be afraid to ask a question. One of the first lessons I got from the USENET is that “Silly questions are the ones never asked”.

Today’s snail mail included the latest issue of NT Insider where Peter Viscarola in his column (Peter Pontificates) deals with the whole “asking a question” issue again:

Being a noob excuses stupidity. In fact, being a noob totaly means asking stupid questions. However, being a noob does not excuse lack of engineering discipline. As an engineer, I simply cannot understand how a fellow engineer can ask a question without at least attempting to put their question in its proper context.

How rightfully said.