Hackers are positive people

I was looking around at the movies coming up and looked into "The Social Network" which led me to Wikipedia for Mark Zuckerberg.

Once upon a time, I wrote a book about how computers work -- meant for the everyday person and trying to explain/show how the various parts of computers worked together. Although unpublished (and probably unnecessary anymore), one of the chapters dealt with hackers. According to Wikipedia, Zuckerberg said that hackers are people who aren't afraid to break something in order to make it better.

Personally, I would go a bit further. I would say that hackers are people who are curious about how software works, aren't afraid to break it, and who want to make it better (in the past, this often meant more efficient and faster, nowadays it more often means more features). At any rate, it is a positive purpose -- Bill Gates Jr., Wozniak (also a hardware tinkerer), and others are all hackers. I am also a hacker and proud of it.

So, why does the word "hacker" have such a negative connotation? Leave it to the sound bite. It sounds good and the media, rather than going into more detail as to what was actually done (which might bore a majority of their viewers/readers) just lumped all people working on software as hackers. This includes a sub-group of hackers which does NOT have such benevolent motives -- the "crackers". Crackers work to exploit the inherent weaknesses of software structure to allow misuse.

Crackers are a pain in the rear -- they do things for their own egos and pocketbooks and make the rest of us have to deal with their behavior. Hackers have made the fusionfalls (a current favorite of my kids), the facebooks, the Linuxes, and the spreadsheets possible (among thousands of other software programs). Hackers have found a home in the open source community but, for the most part, remain in individual obscurity.

Where did they go?

Well, I decided to be inspired by one of the Blogs I follow -- "The Retirement Bubble" and accept the fact that I just am not going to be a daily blogger. So, I headed to my blog and "ZAP", my last blog was no longer there. In fact, my stat counter for visits (which I watch not go up very fast ) went backwards from 184 to 121.

I'm sure that things of this nature happen to you, also. What can the reason be?

Well, first, of course, there is the jello-like consistency of memory. I could have just imagined that I posted a blog entry last month. People look at memory as the chronicle of the past but it just doesn't really work that way. If you think about doing something enough times, with enough detail, it will blur the boundary between "memory" and "dream". Given an amount of elapsed time, that boundary may easily disappear. I know people who have very fixed "world views" and you can tell them "yes" to a question and, because they just "knew" you were going to say "no", they will HEAR "no" and remember "no". This is a bit more severe of a split between "memory" and "dream". The bottom line is -- one cannot really rely on memory

But, do I think that is what happened? No. Of course it could be vanity -- "other people may not remember correctly but I certainly do". No, the main reason I don't think that was the case is because of the stat number. Everyone has certain areas where their memory is well exercised and more reliable. My stepdaughter can remember what someone wore for a given date within the past few months and practically forever about what SHE was wearing. Other things aren't so important to her and she just doesn't remember. For me, it is numbers. I can visualize that "184" in the stats area and I'm pretty sure it isn't a false memory.

There are some aspects to irregular posting that are certainly suspect. For example, some of the formatting aspects of this blog seem to be strange to me -- but, for that, I will just blame my memory and not doing this blog often enough.

Assuming that I'm not crazy and my memory is not totally faulty, where did the blog go? Two possible avenues seem to rise to the surface. One, a system crashed and the disk got backed up (which, for Google, does seem a bit scary to think that backups are unreliable). Two, I didn't do something correctly to commit the blog into permanent status.

Actually, there is a third possibility but paranoia just isn't my thing. "Someone" could have removed it. Since the blog was concerned with firmware and quality control (and Toyota) I guess that there is a little weight to that but I don't really believe it.

At any rate, my last blog vanished and I'll have to think about it a bit to start over the chain. The last blog was on embedded software (firmware) and quality control. The next was going to be about embedded software on cars, unit testing and system testing -- and the difficulties of fully system testing real-time software for interconnecting modules (groups of software). And the next was going to be quality control and testing in general.

However, since the first of the series has vanished I guess I'll think it all out again.

Google, if you're listening -- maybe YOU can find out what happened to my last blog .

Ready, Set, Stop

We've probably all seen a car in an intersection -- rear end over the crosswalk and front end partially blocking the outside cross traffic land -- and they just stay there, never getting a green light to go. Or perhaps they have stopped 30 feet behind the crosswalk and they're stuck (and you're stuck behind them). There really is no mystery -- they are beyond the range of the sensor in the road and the traffic light system doesn't know they exist.

Traffic light systems are ideal for computer programming assignments. The basic system is very simple but it can be increased in complexity to understand more and more possibilities of design. I have used such systems as examples in a couple of my books.

The simplest form of traffic light is a blinking four-way stop (red lights). Not much of an advantage over a four-way set of stop signs except more visible in the dark. The next version can make use of a simple mechanical timer and set of switches (rather like many mechanical pool pump timers). The timer can revolve at a fixed rate and close contacts with the appropriate lights in the traffic system. It probably proceeds like

Green Red
-t- Red
Yellow Red
Red Red
Red Green
Red -t-
Red Yellow
Red Red
and back to the beginning. The "-t-" indicates some type of delay -- the length of time that the green light stays on for that direction. Note the two times that both directions are Red. This is very important for safety reasons.

This simple mechanical system has a timer and a set of connections to lights. The timer is an input and the connections are outputs. Mechanical systems can be designed to allow for a beautifully complex set of conditions but the actual construction becomes more and more precise and difficult to mass manufacture. It is much cheaper, and easier, to start adding microprocessors and programs to handle more complex operations.

With programming, the inputs are often extended to a clock, a set of timers, and one or more sensors. These are all concerned with events that affect the output -- which may be extended to include walk lights in addition to traffic lights. The programming may start taking into account the day of the week, time of day, whether it is a holiday, how many cars are waiting in a lane, and many other options. Once again, it can get pretty complex -- but most of the complexity is hidden in the programming and, thus, mass manufacturing is still possible (even reduces the cost per unit when more are made).

So, the car is stuck because the sensor no longer can tell it's there and it cannot use that as an event to trigger a light change.

Why go into all this detail? Who cares? Well, I find it interesting in itself but it's also a good prelude to talking about embedded processors in cars and the relation between complexity, sufficient testing, and safety which is definitely in the news of late. See the next blog .