Nerds are strange beasts with stranger tastes.
Today I remembered how I really like AM radio. I got to work by bus, and decided to plug some noise into my ears other than the usual traffic and city noise. I always try to carry my AM/FM radio around (it's a Sony digital something (I noticed people expect brands and models of gadgets mentioned in nerdy blogs)), since I'd rather listen to something weird/new than my good old CD collection, which I actually hardly listen to. MP3 players are also not my thing, since I'd soon get fed up with the same songs all the time, or I'd loose several hours a week managing playlists. I like radio, and today I tripped on the band button and suddenly was (gladly) dragged back to the AM universe.
Static, white noise. I could listen to my GSM cellphone receiving a message before the phone announced it. I also heard the clicks and feeps of my answer as it found its way into data packets and off the air. Sometimes a bit of 60Hz signals when the bus was close to high-voltage lines. And over all that, information. I think that's what I like about AM radio. It's much too low-tech for trendy, fashionable, "pop culture" things, so all you can get is raw information and news from interesting people. Hey, I even voted (YES) in this interactive poll about whether we should pass a city law to forbid smoking on any public closed place.
As I write I also remember how my trusty radio was one of my best friends when I spent 6 to 8 months working in Brasília, only coming back to Porto Alegre every two weekends. Brasília is a nice city, but you HAVE to have a car in order to get to know it and I didn't. It was like breakfast-work-lunch-work-dinner-(work?-)sleep. For days and weeks (sometimes weekends). After the first few weeks of walking around the hotels and work, I didn't really have a lot more to do than read in my room and listen to my radio. I started trying to find the weirdest radio ever, and the candidates were usually religious radios of all sorts. They were really fun to listen to, specially during the night.
So now, as I work with IPv6, security, Unix and embedded devices, I listen to good old AM radio (and love it). Go figure.
Thursday, July 21, 2005
Tuesday, July 19, 2005
Bugs by Design
Today I just participated in this somewhat heated debate at work about the limitations of Microsoft technologies, and I remembered something I posted on an article at OpenBSD Journal. I decided to maybe recycle it a bit and repost it here, for a wider audience.
[replying to ramblings on Microsoft's buggy implementation of ACPI]
It's been a few years now that I've come to perceive such "mistakes" coming from Microsoft not as their fault, but as part of a carefully architected plan to keep the rest of the world spinning around them as much as they can.
They used to protect their monopoly position by the well known "Embrace and Extend" tactics of producing seemingly better protocols/formats only slightly incompatible with the standards. Very soon everybody else who wants to play has to bow and implement the slightly incompatible version and it becomes a de facto standard. The "Embrace and Extend" tactic got too old-fashioned and easy to spot, so now it's been recycled to something like "Embrace and Distort".
In this new "Embrace and Distort" tactic they get standards wrong on purpose so that they still get everyone to jump when they say jump. It doesn't have to be Microsoft ACPI anymore, it's just ACPI. But whoever sets out to implement such distorted standards sooner or later finds out they are heavily influenced by some "[mis-]take" (noun, 5th meaning) from Microsoft.
When people call them on it later on they can always say "Oh, but the standard is so dificult to get right!" (they distorted it) or "Hey, it's a bug!" (feature).
OK, the above sounds conspirational, I have no evidence, no facts, blah blah. Whatever. It's just my opinion.
[replying to ramblings on Microsoft's buggy implementation of ACPI]
It's been a few years now that I've come to perceive such "mistakes" coming from Microsoft not as their fault, but as part of a carefully architected plan to keep the rest of the world spinning around them as much as they can.
They used to protect their monopoly position by the well known "Embrace and Extend" tactics of producing seemingly better protocols/formats only slightly incompatible with the standards. Very soon everybody else who wants to play has to bow and implement the slightly incompatible version and it becomes a de facto standard. The "Embrace and Extend" tactic got too old-fashioned and easy to spot, so now it's been recycled to something like "Embrace and Distort".
In this new "Embrace and Distort" tactic they get standards wrong on purpose so that they still get everyone to jump when they say jump. It doesn't have to be Microsoft ACPI anymore, it's just ACPI. But whoever sets out to implement such distorted standards sooner or later finds out they are heavily influenced by some "[mis-]take" (noun, 5th meaning) from Microsoft.
When people call them on it later on they can always say "Oh, but the standard is so dificult to get right!" (they distorted it) or "Hey, it's a bug!" (feature).
OK, the above sounds conspirational, I have no evidence, no facts, blah blah. Whatever. It's just my opinion.
Friday, July 15, 2005
Unix-Fu
Yesterday I assisted a good friend in extracting some lines from a database dump in fixed-width format, so that he could validate the dump before importing it into another database. He is a full-fledged DB person, grand master in PL/SQL and all. Yet he has only some practical Unix experience, and only knows some key commands for manipulating big text files so that he can check his database dumps.
He had already checked the start of the file with head -10000, and now was checking the end of the file with tail -10100, in order to get the last 10,100 lines (records, in a DB dump) from the file. For some reason his sample file was coming out with only about 79 lines, so he sent me a message to ask for help.
We checked what Unix he was using (uname -a) and behold! It was HP-UX, which I use almost daily at work, so it would be easy to check manpages and all. I asked him to count the lines in the file (wc -l), and the big dump had 15,700,000 lines in it. It was clear tail should find the last 10,100 lines from the file without problems. We looked at file size (ls -l) and it was just under 4GB. Since he was at a 64bit machine, this should not be a problem.
I took a look at tail's manpage on a local HP-UX machine, and then easily found the source of his problems: HP-UX's tail operates on a fixed 20KiB buffer, and surely we found that his sample file was exactly 20KiB in size. Given his limited experience he thought this would be the end of it, but I promised to message him back some other command line that would extract the last 10,100 lines he wanted.
I quickly looked at awk's manpage (I should exercise my memory better) and sent him 'awk "NR >= 15700000 - 10100" dump_file.txt > sample_file.txt'. It crunched the file for a while and after a few minutes exited leaving a perfect sample file for his validation. He was all happy and took note of this command on his notepad. I thought it was it.
Later in the day he sent another message, stating some records were broken and he was trying to find lines which did not have the expected 259 character length. What I liked about it is that he was already peeking awk's docs and was trying 'awk "length =! 259" dump_file.txt > broken_recs.txt'. I told him it was != instead of =!, and he quickly found the broken records the database dumper had generated. I really enjoyed the fact that he took my small awk tidbit and was already improving on it. I explained to him that if he handled textual database dumps frequently, awk would be his life saver, and he asked if I could send him docs and examples.
I recognized that in some sense he had gotten to a newer level in his practical Unix experience, and jokingly told him we would later have his ceremony where he would receive his new Unix-Fu belt. Unix-Fu belts stuck on my mind during the rest of the day (not for the first time, though: I once sent email to ThinkGeek proposing they create cool Unix-Fu, Korn-Fu and Perl-Fu belts, but never had an answer), and today I decided to take a look at the Kung-Fu belt degrees and mimic that with Unix-Fu knowledge and experience.
So here's my initial proposition at a Unix-Fu belt system:
White Belt: Has a few commands written on a notepad, retypes them when needed with little variation but is starting to perceive the power of the command line and wants to learn the path.
Yellow Belt: Knows about variable substitution and shell redirection, able to create simple pipelines to achieve some interesting data manipulations. Still gets some Useless Use of Cat Awards, though. Can create small scripts with their sequences of simple pipelines and a few temporary files. Reuses some sed and awk tricks from the written notepad.
Orange Belt: Has picked a preferred shell and read its documentation several times. Uses all kinds of substitutions on the command line, and knows when to use ', " and \ to achieve the necessary level of escaping and substitution. Creates networked shellscripts. Never sees a ^H again and is fully able to understand and [ab]use X. Read Sed&Awk three times.
Green Belt: Perl. C. CVS. Contributes to free software projects. Understands Unix history and picked a Unix variant of choice with reasonable argument.
Blue Belt: Has created some unique commands for personal use and shared with friends. Started some free software projects, based on those commands. Contributed full userlevel features to their Unix of choice. Has ~/bin as the first element of $PATH.
Purple Belt: Knows every config file in /etc and installs perfectly tight Unix systems. Frequently recompiles their Unix of choice, creating custom installation images. Creates LiveCD images of their Unix of choice to carry around.
Brown Belt: Understands the static and dynamic binary formats of their Unix of choice, has enhanced and fixed bugs in basic libraries such as libc, libm and libz and has implemented a few network services, with and without inetd. Is capable of creating auto-generating shell command lines of the third degree.
Black Belt: Has developed considerable features and fixed bugs at kernel level for at least one Unix variant. Has fought and won SMP race conditions on device drivers without resorting to big locks. Recompiles their Unix of choice with a bigger limit for command lines.
Or maybe we should split the art of Unix-Fu in styles: User Style, Admin Style and Developer Style, this last one having two variations: the way of the process and the way of the kernel. but that's for another day.
He had already checked the start of the file with head -10000, and now was checking the end of the file with tail -10100, in order to get the last 10,100 lines (records, in a DB dump) from the file. For some reason his sample file was coming out with only about 79 lines, so he sent me a message to ask for help.
We checked what Unix he was using (uname -a) and behold! It was HP-UX, which I use almost daily at work, so it would be easy to check manpages and all. I asked him to count the lines in the file (wc -l), and the big dump had 15,700,000 lines in it. It was clear tail should find the last 10,100 lines from the file without problems. We looked at file size (ls -l) and it was just under 4GB. Since he was at a 64bit machine, this should not be a problem.
I took a look at tail's manpage on a local HP-UX machine, and then easily found the source of his problems: HP-UX's tail operates on a fixed 20KiB buffer, and surely we found that his sample file was exactly 20KiB in size. Given his limited experience he thought this would be the end of it, but I promised to message him back some other command line that would extract the last 10,100 lines he wanted.
I quickly looked at awk's manpage (I should exercise my memory better) and sent him 'awk "NR >= 15700000 - 10100" dump_file.txt > sample_file.txt'. It crunched the file for a while and after a few minutes exited leaving a perfect sample file for his validation. He was all happy and took note of this command on his notepad. I thought it was it.
Later in the day he sent another message, stating some records were broken and he was trying to find lines which did not have the expected 259 character length. What I liked about it is that he was already peeking awk's docs and was trying 'awk "length =! 259" dump_file.txt > broken_recs.txt'. I told him it was != instead of =!, and he quickly found the broken records the database dumper had generated. I really enjoyed the fact that he took my small awk tidbit and was already improving on it. I explained to him that if he handled textual database dumps frequently, awk would be his life saver, and he asked if I could send him docs and examples.
I recognized that in some sense he had gotten to a newer level in his practical Unix experience, and jokingly told him we would later have his ceremony where he would receive his new Unix-Fu belt. Unix-Fu belts stuck on my mind during the rest of the day (not for the first time, though: I once sent email to ThinkGeek proposing they create cool Unix-Fu, Korn-Fu and Perl-Fu belts, but never had an answer), and today I decided to take a look at the Kung-Fu belt degrees and mimic that with Unix-Fu knowledge and experience.
So here's my initial proposition at a Unix-Fu belt system:
White Belt: Has a few commands written on a notepad, retypes them when needed with little variation but is starting to perceive the power of the command line and wants to learn the path.
Yellow Belt: Knows about variable substitution and shell redirection, able to create simple pipelines to achieve some interesting data manipulations. Still gets some Useless Use of Cat Awards, though. Can create small scripts with their sequences of simple pipelines and a few temporary files. Reuses some sed and awk tricks from the written notepad.
Orange Belt: Has picked a preferred shell and read its documentation several times. Uses all kinds of substitutions on the command line, and knows when to use ', " and \ to achieve the necessary level of escaping and substitution. Creates networked shellscripts. Never sees a ^H again and is fully able to understand and [ab]use X. Read Sed&Awk three times.
Green Belt: Perl. C. CVS. Contributes to free software projects. Understands Unix history and picked a Unix variant of choice with reasonable argument.
Blue Belt: Has created some unique commands for personal use and shared with friends. Started some free software projects, based on those commands. Contributed full userlevel features to their Unix of choice. Has ~/bin as the first element of $PATH.
Purple Belt: Knows every config file in /etc and installs perfectly tight Unix systems. Frequently recompiles their Unix of choice, creating custom installation images. Creates LiveCD images of their Unix of choice to carry around.
Brown Belt: Understands the static and dynamic binary formats of their Unix of choice, has enhanced and fixed bugs in basic libraries such as libc, libm and libz and has implemented a few network services, with and without inetd. Is capable of creating auto-generating shell command lines of the third degree.
Black Belt: Has developed considerable features and fixed bugs at kernel level for at least one Unix variant. Has fought and won SMP race conditions on device drivers without resorting to big locks. Recompiles their Unix of choice with a bigger limit for command lines.
Or maybe we should split the art of Unix-Fu in styles: User Style, Admin Style and Developer Style, this last one having two variations: the way of the process and the way of the kernel. but that's for another day.
Thursday, July 07, 2005
God is Z
One day the young apprentice approached the Master and said:
"Master, if I take zero to mean evil, darkness and ignorance, and one to mean good, light and understanding, does that make God a flip-flop?"
The Master contemplated the question for a clock cycle and said:
"My young padawan, if you take zero and one to be your relatives, that makes your own mind to be the flip-flop, constantly bouncing over a series of random-looking bits, ever further from the quietness of the idle loop. God, on the other hand, or the absolute, mind you, is then the high-impedance state. Neither good nor bad specifically, but either good or bad when it comes to be."
Upon hearing this the apprentice was enlightened.
"Master, if I take zero to mean evil, darkness and ignorance, and one to mean good, light and understanding, does that make God a flip-flop?"
The Master contemplated the question for a clock cycle and said:
"My young padawan, if you take zero and one to be your relatives, that makes your own mind to be the flip-flop, constantly bouncing over a series of random-looking bits, ever further from the quietness of the idle loop. God, on the other hand, or the absolute, mind you, is then the high-impedance state. Neither good nor bad specifically, but either good or bad when it comes to be."
Upon hearing this the apprentice was enlightened.
Wednesday, July 06, 2005
Why Yoga and Unix?
One of the things I enjoy the most are unifying theories or principles, and naturally things that derive from unified, simplified or synthetic concepts.
After being raised a catholic christian, studying Buddhism, being exposed to spiritism, having a glimpse of Taoism and Zen-Buddhism, going a bit christian again with the luteran church and then falling in love with Discordianism, I stumbled upon Yoga (Raja Yoga, not the body-stretching-with-a-warm-fuzzy-feeling type) and couldn't help but stare in awe at the origin, the unifying principles of about all other religions, so plain, so easy, so simple. It's like KISS applied to religion/existence.
On the technical side, I was raised with 8bit computers, the type that had ROM-BASIC and would boot in a second to a very intriguing prompt. I learned BASIC from the books that came with it (my father helped since he once programmed in FORTRAN in punched cards), and in about a year I was programming in assembly and reading about computer architecture. I like bits, and combining bits. I like putting simple things together to accomplish complex things. I get offended by being exposed for too much time to icons and GUIs. This means I like systems where I can boot into a programming environment, and where I can go down to the bits if I want to, and combine things together in complex ways. This obviously means I like Unix, where I can have several programming languages out-of-the-box, where I can treat myself to the expressiveness of a carefully crafted command line, where the system tries its best to get out of the way so that you can combine tools in unpredictable ways.
I see in both Unix and Yoga one of the key concepts of elegance, and that's simplicity. Just the right dose of basic unifying concepts, and a universe of combinatorial explosion to analyse.
I hope you enjoy the posts as much as I will enjoy writing.
After being raised a catholic christian, studying Buddhism, being exposed to spiritism, having a glimpse of Taoism and Zen-Buddhism, going a bit christian again with the luteran church and then falling in love with Discordianism, I stumbled upon Yoga (Raja Yoga, not the body-stretching-with-a-warm-fuzzy-feeling type) and couldn't help but stare in awe at the origin, the unifying principles of about all other religions, so plain, so easy, so simple. It's like KISS applied to religion/existence.
On the technical side, I was raised with 8bit computers, the type that had ROM-BASIC and would boot in a second to a very intriguing prompt. I learned BASIC from the books that came with it (my father helped since he once programmed in FORTRAN in punched cards), and in about a year I was programming in assembly and reading about computer architecture. I like bits, and combining bits. I like putting simple things together to accomplish complex things. I get offended by being exposed for too much time to icons and GUIs. This means I like systems where I can boot into a programming environment, and where I can go down to the bits if I want to, and combine things together in complex ways. This obviously means I like Unix, where I can have several programming languages out-of-the-box, where I can treat myself to the expressiveness of a carefully crafted command line, where the system tries its best to get out of the way so that you can combine tools in unpredictable ways.
I see in both Unix and Yoga one of the key concepts of elegance, and that's simplicity. Just the right dose of basic unifying concepts, and a universe of combinatorial explosion to analyse.
I hope you enjoy the posts as much as I will enjoy writing.
Subscribe to:
Posts (Atom)