Common Sense 4 Common People

Infinite Energy

This is a very important issue that I would like to inform you about today.

There is a branch of physics that deals with the concept of "New Energy". This branch of physics is not recognized by the "scientific establishment" as anything serious, but this is always the case with science. Various madmen start on various types of crazy research and the establishment calls them madmen and fools. Then some of these madmen actually produce new and valid science, so they are not madmen any more and become part of the scientific establishment.

This is the case with "New Energy". You can visit the Infinite Energy Magazine for the gory details.

Here I will give you a brief outline of one of their research branches, the one I find most fascinating. This is the so called Zero Point Energy, or more popularly Vacuum Energy.

These guys, based on quanum physics, claim that you can draw infinite energy out of the vacuum. This is a shocking idea. Disruptive innovation. If this ever becomes a reality, then the energy problem will be solved once and for all, for all ages to come.

I am not in the position to judge the physics behind these theories, or how long it may be before they make it a reality, but what I know is that there is HOPE for humanity.
The additional reason why there is hope, is that today's world CAN be saved if such an innovation appears. Thank the almighty for the Internet. If the solution is found, then hopefully it will be made public on the Internet. Noone can prevent that. Then everyone will have the infinite energy technology, it will not be one country's top secret technology so that it can dominate over the others. Everyone will have free energy. The world can be a better place then.

Enjoy!

re: My Desktop

My good friend George Adamopoulos extended this invitation to me, so here is an overview of my desktop at work:

So what can we see here?

On the right is my main workstation, with two monitors of course. The monitors are raised higher, using a dead UPS and a bunch of books, so as to reduce neck strain. On the left monitor you can see the video stream from where the capture came from. A recursive photo really, since it contains itself.
I used a Point Grey Grashoper 1394 camera and set our application to grab a frame every 5 seconds, then I picked one that was clear enough.

On the left is my laptop and in the middle is my private test PC, the one I first debug my drivers on. It's the one underneath the table, opened up of course so I can add/remove 1394 adapters easily. Please pay special attention to the light blue rubber keyboard that I bought for 4 euros (!!!) from Taipei. You can just roll it up and put it in your bag to carry along! Very convenient in that aspect, but really hard to type ultra fast with it as you get lots and lots of missed keystrokes.

At the far end you can also see my great collection of cups :-) Yeap, I am a proud cup collector!

Have fun!

Elements of Inner Change

Inner change is an issue that has in one way or the other occupied the mind of each of us, at one point or another in our lives. Becoming better persons, better partners, finding what we really want and following our heart, becoming ourselves, becoming happy.

"Am I ever gonna change?"
"Will I always stay the same?"

Do these ring any bells?

There is a lot of talk about change so I can freely add to that my own point of view.

Inner Change can happen. Inner change happens.

From my personal experience I have an idea of how it happens, but...
Although you may know how change happens, you can't force it to happen.
If it is going to happen, change will happen by itself.

This does not mean that you can do nothing at all about change. Of course you can. You can do a lot. You can do a lot, but only to prepare the grounds for change to happen. You can only prepare for change. If and when it is going to happen, change will happen by itself, almost spontaneously.

If you try to force change, you only make it harder for it to happen.
This is because what we do about change is mostly at the logical level. True inner change happens at the subconsious.

We all think we are purely logical, rational beings. We are not and we can never be. We can never articulate all the reasons why we are who we are, why we do what we do, why we like what we like, mostly because there are NO reasons to articulate. No reasons to analyze, examine and then logically substitute with new reasons that will make us somebody new. It doesn't work that way.

You have most probably heard that finding oneself in a real life-threatening situation and having a narrow escape is a life changing experience. Instantly your life flashes before your eyes, instantly you reevaluate everything and all of a sudden you are a new person.

OK, you know that, now try thinking really hard of yourself being in a life-threatening situation and having a narrow escape. Does it make you a new person? Does it change you? It should, damn it! But it won't... No matter how hard you try.
Why? Because you are NOT a purely rational being. Just accept it and play on. A logical thought like the one above cannot by itself cause inner change to happen, because... it is LOGICAL and inner change happens at the subconsious.

I said that I think I know how change happens but you can't force it to happen. I briefly covered the second part, which is the most crucial to realize. So how does change happen then?

Basically it is a truly stunning and staggering... two step process:
(1) Get new input
(2) Go to step 1.

Who would guess that inner change would be as simple as that???

Here is how it works. As you see, all that the process requires from you is to get new input, mainly into your logical brain. New input, new information, broadens your understanding, your perspectives, your options, your logical reasons TO and NOT TO do things.
New input will hopefully make you a bit wiser and it will prepare the path for inner change, but will not change you by itself.

As you keep on getting new input at some point a "critical mass" will be accomplished.
Now, it IS possible for change to happen. Now, it MAY happen.

Yes, but how does change happen after all?

Well, let's discuss first HOW do you get input. The input you need can only come from other humans. Not from a video game. Discuss life with your friends, open up to a total stranger you met in a bar, discuss with the barman if you will, see a psychologist, two psychologists, read books (they are mostly written by humans), any kind of book, not just psychology or self-help. Any kind of input is worthy. Any kind of input somehow contributes to the critical mass.

It is not a matter of how much input you gather. Once you are above critical mass, you are good. How much input you've got will only determine what kind of change will happen to you. Not when it will happen.

So, once again, how and when will change happen?

The missing element, the element that cannot be included in the two-step process above, is the TRIGGER.
It is an event that will trigger the inner change in the subconsious. By event I mean either an actual event (like a life-threatening car crash), something personal a friend told you, a thought that "randomly" poped up in your head, an unusual dream, or even some lyrics in a song. Anything can be your trigger.

There is no way to force the trigger to "happen". You can only be "open" to it and give it some fair chances, tempt chance. I mean sitting at home watching TV or staying awake in bed late at night thinking things over and over don't sound very triggering. Tempt chance, don't try too hard and remember to stay just a bit reasonable :-)
I mean, attempting suicide just to see how it feels like and if anyone will come to rescue you and care for you, or quickly divorcing your wife only to find out that it is her that you really love are probably "trying extra-hard" and plain silly. Take it easy, take it slow, and fate will take you anywhere you deeply intend to go.

Haven't you heard of the saying "When a disciple is ready, the teacher will appear"?
Do you see any similarities here? Will the teacher come to teach? Or will the teacher only come to trigger the disciple and make him LEARN in his heart apart from his mind and thus make him wise? The teacher's true mastery is not the knowledge of facts, it is knowing how to create the proper triggers for the disciple.

I do believe that when we are ready to learn then the true teacher always appears, because we can finally let him appear. Because finally anyone can serve as the teacher.

Similarly I do believe that when we are ready for inner change then the trigger always appears, because we can finally let it appear. Because finally anything can act as a trigger.

Have fun!
Dimitris Staikos

Embracing Confusion

I've been feeling a bit recursive the past days, so I thought I should try to explain the word "explain".
Let's start by seeing what the infamous online dictionaries propose:

Cambridge: To make something clear or easy to understand by describing or giving information about it.
Webster's:
1. Give an explanation for.
2. State by way of explanation.
3. Serve as an excuse for
Comments section: Explanations can only be given by those with understanding of the object which is explained.

Since Webster is recursive, i.e. uses the word "explanation" while trying to describe "explain" I also looked up "explanation" to see whether it included anything more thought provoking:
1. A statement that explains; "he launched into a detailed explanation"; "he demanded that I give an account for my failure".
2. Thought that makes something comprehensible.

Option (2) is good enough for my purposes, since "thought" may as well be replaced with "statement" or "description".

The operation and workings involved in communicating information from one human to another is a topic that has been extensively analyzed, although only a few care enough to study a little about it. It's mainly those to whom communication plays an important part in their profession (salesmen, politicians, managers, etc).

The rest of us know everything by definition, so we also know how to communicate :-)

So, since I by definition know everything too, I say that both the Cambridge and Webster definitions convey very little essence. Enter my vastly superior definition :-D

Explain: To make the target audience think they understand what you think you understand.

Understanding is nothing but an illusion. It can always expand and it will always expand. Confusion expands our understanding: You thought you understood, but now you are confused and don't understand. Hey, your understanding has just expanded and what previously looked solid and clear now appears complex and mysterious. Eventually you will reach a new and higher level of "solid" understanding, which may again be expanded by confusion, etc.

They routinely say "Embrace Change", I dare say "Embrace Confusion"!
And don't forget... Confusion is an illusion as well...

Have fun!
Dimitris Staikos

Like Father Like Son?

Given that we all need to relax a bit these special days, I won't blog about Writing Debuggable Code yet. Rather I thought I should share a photo I shot almost two years ago, when my son was just 19 months old.

Have fun!

Dimitris Staikos

Demystifying Device Driver Development (DDDD)

It just occurred to me recently that most people don't really have a clue about what it is that Device Driver Developers (DDDs) do for a living. Since I am a DDD myself, among other things, I thought I should make an attempt of describing what I do in a way that Common People can hopefully digest.

Since I enjoy making wannabe hilarious Tom & Jerry dialogs, I will try to put it in a dialog between Jerry the Technical Interviewer and myself. I will intentionally wear the hat of the anti-social, psycho-path, under-the-hood programmer and let Jerry extract all the information from me in a criminal-interrogation like style.

Here we go...

Jerry: So you are a DDD.
Me: Yeap.
Jerry: Can you tell me what it is that you do?
Me: Yeap.
Jerry: I mean you build device drivers right?
Me: Yeap.
Jerry: What exactly is a device driver?
Me: It's just a piece of software that controls a device. Don't you know that? Are you wasting my time?
Jerry: Yes, I guess I do, ehhh I mean I do know, but what exactly is a device?
Me: That's an interesting question so I will dignify it with an answer. A device is a clever piece of hardware. To make things simple, imagine that a device has a little CPU of its own, a CPU that can execute various tasks depending on the hardware at hand.
Jerry: Wow64, there is a CPU on these things? A CPU on a PCI card that I buy off the shelf?
Me: Duh, but of course, how else do you think they would do any useful work?
Jerry: I thought the computer's CPU was the only CPU in the block.
Me: No, devices have CPUs and depending on the hardware they can be pretty sophisticated.
Jerry: That's awesome! What can you tell me about these little CPUs?
Me: For starters, they are not little. Most of them can do several tasks at the same time and they can be pretty darn fast.
Jerry: Hmmm, wherever there is a CPU, there is a program right?
Me: Yeap.
Jerry: Well, where are the programs that these CPUs execute? Firmware stored in flash memory may be?
Me: You'd wish.
Jerry: Please elaborate, I'm getting really curious here.
Me: OK, if you insist... These programs are generated by the device driver.
Jerry: Pardon me?
Me: The programs that the device CPUs execute are generated by the device drivers. Clearer now?
Jerry: Wow64!
Me: Indeed.
Jerry: Generated by the device driver... In what language?
Me: That was a good one! Machine language of course.
Jerry: You mean mov ecx,edx and the like?
Me: Well, in a sense yes. Each device CPU has its own machine language.
Jerry: You are kidding me right?
Me: No way. Don't be an idiot.
Jerry: So the device driver builds machine language programs for the device CPU?
Me: Actually, it's even worse than that. These CPUs usually have many sub-CPUs, execution contexts we call them. The device driver generates programs for several (if not all) execution contexts. Each program is called a context program.
Jerry: Wow64 once again! And where are these context programs located at runtime?
Me: Well, in most cases in main memory, the little thingy you call RAM. Sometimes devices may have onboard memory for storing these programs, but in most cases it's just RAM.
Jerry: In RAM? Wait wait... And how can the device CPU read from RAM? Can it handle virtual addresses and the like?
Me: Man, you are really something! Virtual addresses? What are you talking about? When was the last time you heard the term "Physical Address"? These are the kind of things these CPUs can swallow.
Jerry: Physical Address? What are YOU talking about? Are we talking about DOS here?
Me: LOL. Please realize NOW that devices are what's called "Close To The Metal". They don't and they won't understand virtual crap of any sort. They operate at the PCI level, so they will only understand PCI-level physical addresses.
Jerry: Then how does it all work?
Me: Well the device driver allocates some piece(s) of memory where it intends to store the context programs and then kindly asks the operating system to give it the physical addresses of these pieces of memory. The OS happily obliges and then the device driver prepares the context programs, using physical addresses wherever a jump is required. When the context programs are ready, the device driver sets the Program Counter register on the various sub-CPUs of the device and then starts these CPUs. Ain't it cute?
Jerry: Wowowowowow64!!! That's super cool.
Me: Yeap.
Jerry: If I understand well, the device driver is like a mini operating system for a device, right?
Me: You couldn't phrase it better.
Jerry: Now I realize why being a DDD is so tough! You have to write a mini OS of your own and make the device do your bidding!
Me: Yeah, but the truth is making the context programs and handling their operation is the easy part.
Jerry: Huh? And what is the difficult part?
Me: ERROR HANDLING.
Jerry: Please please, please elaborate!
Me: Well, it's no big deal for an experienced DDD to write a device driver for a well behaved device. The tough thing is to write a driver that does not malfunction or crash the OS in the presence of device errors. These do not happen often so it is really hard to test the error handling code. Actually if you write ANY decent program, user mode or kernel, error handling largely amounts to 50% of the code. If it does not amount to 50% in your code, then you haven't done enough error handling. No developer likes error handling (with the exception of myself of course). It's boring, it's nasty, it's creepy. But unless you do it and you TEST it throughly you can't write decent software. For device drivers this is even more crucial, since in the presence of device errors the best thing that you can hope for is that the device stops functioning (we call it the device is dead). However in the majority of cases (at least in Windows) you get an OS crash.
Jerry: And how do YOU test your error handling code?
Me: That's a trade secret.
Jerry: Com'on now...
Me: I keep an arsenal of malfunctioning devices at my office. Everyone in my team has strict instructions to immediately hand me any device that appears to be malfunctioning. They are my secret treasure.
Jerry: But how can you be sure that your driver handles correctly all possible errors?
Me: I am not.
Jerry: You're NOT???
Me: Well, why do you think it is that people still get BSODs when something unusual happens? Even if you get a driver developed by a team that takes error handling very seriously, they can't test everything, simply because they haven't seen everything yet. So you get BSODs.
Jerry: I am shocked. This is brutal.
Me: Well, as I've said elsewhere BSODs are a blessing. As far as your complaints are concerned, please pass them on to the device manufacturers. If they would put some "test mode" into their devices and make them fail randomly then MY job would be MUCH more easier. But these things would have to go to the chip level and then they would have a significant added cost as you realize. So practically everyone in the industry operates in a "hoping for the best" mode.
Jerry: ...
Me: You can't imagine what I have to go through to make buggy devices operate correctly. In your mind the term "bug" is most probably related to software, but let me break some news to you: There are COUNTLESS bugs in hardware chips and devices, and poor DDDs like me have to struggle hard to ship a decent driver only to have lusers scream their lungs out at ME when they get a BSOD. They scream because probably I didn't handle 100% correctly all the bugs in the hardware chips. But who am I supposed to scream at? Texas Instruments? Intel? You get the picture.
Jerry: Well, I can only say that under this new light I have a whole new appreciation for the work you DDDs are doing.
Me: Darn right you should.
Jerry: My special thanks for this enlightening interview.
Me: May the force be with you.
Jerry: Any last minute advice for Common People who use PCs?
Me: Don't add more RAM to your PC unless you know what you are doing.
Jerry: Excuse me? Don't add more RAM? What harm could additional RAM possibly cause???
Me: I will describe that in a separate post, when I feel like having mercy on the masses. For the time being I know, and you don't. Huh!

Have fun!
Dimitris Staikos

Hardware stack

I am a device driver developer and Unibrain, the company I work for, produces what's called a software stack. In plain text this means several pieces of software that are layered, one on top of the other. Each piece uses the services of the layer below it and provides services to the layer above it.

In Windows kernel programming the concept of "device stack" is prevalent. One device object attached to another device object, attached to another device object, etc.

This is a pretty common concept in software engineering.
Mind you, software stacks in the above sense have nothing to do with the "stack" data structure.

Although I am not a hardware engineer, as far as I can tell a concept similar to a software stack does not exist for hardware. Hardware components are definitely combined together, but the combination usually is on a side-by-side basis, not one layer on top of another on top of another etc.

If you search the Internet with "Hardware Stack" you will mostly find items describing hardware support for the stack as a data structure.

Anyway, one day, being in a funny mood, I decided to implement my own a hardware stack or device stack if you prefer. Here's what it looks like!

Btw this is a really expensive stack (five digits in USD).

Have fun!
Dimitris Staikos

Minimum Minimum

Suppose that you have a thingy called something like "Minimum Amount of Time that must elapse after the occurrence of event X before Event Y is allowed to occur".

Now you want to turn this thingy into a setting in your program, so that your users can try out different values and find the ones that suit them best. However, for practical reasons, you will only allow a range of values.

This means that there is a minimum value for this setting and a maximum value.
What do you call the minimum value of this setting?
Naturally it's "The Minimum Minimum amount of time that ...".

Equally naturally its maximum value is the "Maximum Minimum ...".

And if you have a whole list of different events, Y, Z, ..., that may occur after X and each has a configurable minimum elapsed time, what do you call the minimum amount of time after X occurs that any event is allowed to happen?
This is the minimum of the various "Minimum-Minimums", so naturally it's "The minimum minimum minimum amount of time that ...".

And if you have lots of different X events, X1, X2, ...Xn, that define limitations on the elapsed times before other events must occur, what do you call the minimum amount of time after any Xi event occurs before any event is allowed to happen???

By now, if your stack hasn't overflowed, you should be able to realize that it is "The Minimum Minimum Minimum Minimum ...".

Pure common sense, right?

Have Fun!

Programmer DNA

Today I came across a very interesting article about why it is hard to program, with which I wholeheartedly agree.
Joel talked about student's inability to understand C pointers some time ago in his article about interviewing. Leave alone recursion or concurrency.

Here's what I think:

• Not everyone can become a good++ programmer.
• It's not a matter of practice or study alone.
• It's a matter of having some crucial abilities or not having them.

I don't think it's arrogant to claim the above.
It holds for programming in the same way it holds for many other demanding professions.

Could I ever become a weight lifter just by trying?
I wasn't built for that. No matter how many steroids I inject, I won't ever be able to bench press 150kg.

Could I ever become a successful composer? I can't recall from memory any 5 minute song, how could I ever come to compose music?

Could I ever become a mathematics professor? Although I like math, theorems and equations don't ring in my ears, they are not my native instruction set.

This is the best analogy I can come up with. Each of us has a native instruction set, embedded in our DNA. Activities that are compatible with this instruction set can be carried out with the highest degree of efficiency. Other activities less so. Some activities might be seriously incompatible, causing serious degradation in overall performance.

Back to programming. If programmers had professional licenses like doctors do, then I know a couple of people whose license should be immediately revoked. Irrevocably revoked. Programming is not their brain's native instruction set; not in their DNA. They don't really understand what they are designing and what they are implementing. How it will behave, how it will perform, how it will be tested, how it will need to evolve and expand, etc.

No, I am not being harsh here. Some say there is an extremely high demand for software developers, so not everyone has to be that good.

WRONG. DEAD WRONG.

In my previous job I spent around 40% of my time bug fixing or completely redesigning and rewriting code written by people whose programming license should be revoked. What good did it do that these people worked for the company? The company paid their time plus 40% of mine for a work that could be done in less than 40% of my time, had I done it myself from the beginning.

That's why I insist on having top programmers on my team.

Have fun!

Undefined Behavior (NMI quiz - Part 2)

It has been some time since my last Tom & Jerry dialog.

Jerry: Hey Tom, could you help me out here? I am kind of confused...
Tom: Sure thing Jerry! I'd be glad.
Jerry: Do you happen to know what "Undefined Behavior" is?
Tom: Well, isn't it when the results of an operation are unpredictable?
Jerry: I know, but isn't that a definition for this kind of behavior?
Tom: Uhmmm, I guess so...
Jerry: So, you have just defined "undefined behavior".
Tom: Uhmmm, I guess so...
Jerry: So, what's undefined about it, since you just defined it?
Tom: I hate it when you do that! Leave me alone!

Undefined Behavior is a funny term, a misnomer if I am allowed to say.
If you ask me, there is NO such thing as "Undefined Behavior"
Even random behavior is not undefined. It is defined as random.

Instead, there is behavior undefined BY someone.

If you read about Undefined Behavior on WikiPedia you will notice the following in the first paragraph:

... the specification leaves the results of certain operations specifically undefined.

It is the specification that does not define the result of the operations, so implementations are free to do what they feel like, plus tell no one about it (if you are required to document it then it is implementation-defined).

What does all this have to do with NMIs? Well, by now it should be evident.

The NMI I got bitten by last month was caused by "Undefined Behavior", as described someplace inside the OHCI 1.1 specification.

In my case, up to that point in time, the undefined behavior our code was stepping on was not undefined at all. It was perfectly stable and correct behavior. But one day, given the proper hardware combination, it decided to flip and do an NMI instead. Cool, but still perfectly defined :-)

So to answer the quiz, yes, it was once again the software's fault :-)

Have fun!