Jesper Louis Andersens Ramblings

FreeBSD is very strict about its ACPI code. Noteably, FreeBSD doesn't work when the 2nd IDE channel is enabled on the X40 IBM thinkpad. This is well known and described in the archives of the FreeBSD mailing lists. The problem is that whenever you generate some ACPI event, your computer locks up. I did not check if you could break to DDB, though. It might be an interrupt hell you are going through when that happens.

Fortunately, there is a solution. Just run the PS2.EXE program downloadable as a DOS utility package from the IBM/Lenovo website. However, that requires you to have either a windows or a DOS. My X40 is stripped of that crap.

Ah, well, then you just burn an ISO, shove it into your USB CD-ROM drive and boot from it. No USB CD-ROM in this house. No Floppy either. But there is a dual-booting Windows/FreeBSD server (conveniently named orc - My boxes are named after monsters). Can we do with that and an Internet connection without breaking any copyrights?

The astounding answer is yes: Get the utility package. Unpack it in Windows. Copy the files to the FreeBSD server. Get DR-DOS 7.02 on a floppy disk installation. This is free. Pick PS2.EXE and its helper files and stick it into the floppy image via some mdconfig(8) magic and some mount -t msdos hackery. Set up a PXE boot environment (this is a DHCP server and a TFTP server). Download and extract a syslinux package (Peter H. Anvins PXE boot code for linux!). Arrange to boot pxelinux.0 and configure it to use a memdisk. Hand it the DR-DOS image. Boot over the network. BOOM! PS2.EXE can now be run.

Yes, it took a while to figure out that this was a solution. But it was fun.

I installed FreeBSD 6.1 RELEASE on my X40 thinkpad yesterday. This entry describes how to do that quickly.

The first thing you should read is the PXE Jumpstart Guide by Alfred Perlstein. This guide describes how to set up a PXE boot environment on another host. In particular, I downloaded the ISO, mounted it via mdconfig(8) and extracted it to an NFS mount point. Then I set up a DHCPd, a TFTPd and put a pxeboot environment into the TFTP server. It then boots, fetches a kernel and mfs_root via NFS and then proceeds to execute the kernel with the mfs_root as the root filesystem (To do this, consult Alfred's guide, its vfs.root.mountfrom theres the special hint to give the kernel).

With a new FreeBSD, you download a complete ports tree via portsnap(8) and extract it so you have an environment to build from. Then you install portuprgade to manage ports easily. Now, I have a list of stuff I want, so I just supply this list to the portupgrade tool named portintall(8). The system is now happily building the ports I need.

To track security errors in packages, we are using portuadit. This gives a system which can check your box for eventual security problems quickly, so you can take measure of what to do. This is one of the first thing I install.

There is a number of utility-stuff I always install. This list is zsh, screen, sudo and emacs. It more or less gives you a system you can work with, though there is no X environment at the moment.

Next, I fire away a portinstall of the gnome2 port. This gives me a gnome environment. After that I switch to using X for all of my work.

From there on, I keep adding stuff ad-hoc when I need it. Gnome2 installs most of the stuff with long compile-times. Most other stuff I need can be done in a matter of minutes. So this is usually done afterwards when I need it.

One thing I find to be very powerful in FreeBSD is the ease of installation. If you use packages, Debian and FreeBSD is about the same in installation speed. You you don't get all the irritating linuxisms with it!

Enough praise. My parents are not going to get a cat. Both kittens were counted for when they saw them today. I am sitting at my parents because my bike broke down. There was a hole in one of my tires. I utterly hate to mend holes. There is about no fun in doing this, but it has to be done...

My parents are contemplating getting a cat. They do not know it yet, but they will eventually get one. That will make them have 2 dogs and one cat again.

Asking deeper, they had already thought about it. They will get that cat. Your hear me! They will!

I have not done many great projects that became tremendous successes. Rather, most of what I have started has slowed to a halt and never been put into something which other people could use. Due to this fact, I have built a knowledge around how not to do stuff.

I have attempted to compile these things into a big list and then post it for everyone to see. Maybe the information can be useful to someone else than me. I must sadly admit, that I see these things again and again in software projects. It is a shame, because the things should be fairly obvious and none of them should be counterintuitive.

Item #1: Embrace the 2nd effect

The 2nd effect is when you have built a fairly robust version 1.0 of your software program and are aiming for a total rebuild. Then suddenly everything should be crammed into your program. Your discussion and analysis sessions brainstorm on wicked things to add to the software. And everything must be ready for a 2.0 release.

This even happens on new projects in the planning phase. You see it all the time, where the software needs to do a lot of stuff, has outrageously many requirements, or where people are just keeping on adding features while planning. Stuff to look out for:

• We need a complete LISP interpreter as a configuration and extension language embedded into the behemoth.
• It should have web 2.0 connectivity via XML-RPC or SOAP and have XML-schema defined for each kind of operation. This quickly grows out of hand, beware!
• You can't find any spot in this code where we just need to apply the KISS (Keep it simple, stupid) principle.

Item #2: Embrace the NIH syndrome

The NIH (Not invented here) syndrome is when you have to build everything yourself and never base your work upon the shoulders of other giants. This is a fairly irritating thing not to do. You end up reinventing the wheel for a lot of the code. And your code has had less testing than any kind of library out there.

Further you waste your valuable time on a decoy operation: Getting a library built. That moves your focus from the real task at hand, namely building a tool you need.

Item #3: Embrace every library there is because

Embracing a complete pre-configured framework stack for instance, will tie you up in some axis. This is the main reason for the numerous different frameworks for web development. To name a few: RubyOnRails, Django, Turbogears, Zope. Each of these has certain advantages and disadvantages, so there exist more than one. There is also the NIH syndrome at work.

Importing a lot of libraries means dependence of your software. It might put off some people. So loading a library for doing just part of what the library does might be overkill.

The alert reader will have noticed the opposite directions of Item #2 and #3. The lesson is that there is a golden middle which you should hit. It is hard to hit it right the first couple of times, but with experience, you will be better and better at just knowing when to steal code or when to build yourself. The quality of existing libraries might be a reason, but remember it is often far easier to submit patches for bugs to a library than it is to reinvent it yourself.

If the API of the library pisses you off, then you should probably be thinking of shielding the library from the rest of your code so you can interchange it later on. If you create a tight intercouple between your program and the library you risk problems later on. However, do not see these problems as unsolvable. Even with tightly intercoupled libraries it is often possible to change code so you get free of said library.

Item #4: Argue the small points

If your project group always discusses smaller fine points in the code and never discusses the big parts, then your project is doomed. There are many ways to do small things and it is seldomly so that one way have a serious advantage over the other. It is rather hard changing the big picture later on, however. Keep this in mind when discussing things.

Do not discuss a fine point for more than 5 minutes. If it takes longer to convince the other party your case might not be so good after all. I have been in one particular project where most of the discussion took place over the placement of a comma in the documentation. Had the members of the project just spent time on correcting bugs instead of arguing...

Item #5: Dismiss refactoring

Forget about refactoring. Always take your code and just add to it what is needed. This will cripple your code gradually until nothing can be added to the code base. At that point, you will begin contemplate rewriting the whole mess again in a new setting.

Refactoring is about keeping your code agile in the sense that it welcomes change. You need to have a proper canvas to work on when adding things. It is often the case that clever refactoring can do wonders to your code base. You should, however, note that it is not about fixing code, but rather about redesigning and reimplementing the stuff that doesn't work totally.

Item #6: Don't think about your development environment

Forget about development environments. Forget about a CM system like CVS, SVN, Darcs, Mercury, Git etc. Forget about having branches of production and development code with tags along the way. Forget about having a baseline and working branches. And most importantly, forget about having a test environment and work directly on the live production system.

Item #7: Rambo your code: One-army is the way!

Forget about collaboration. Code should be written in one-man armies! Forget about the additional kick that can be, when more people are working together on a project. Rather, than focus on one project with 3 people, focus on 3 projects with one man on each. One-man army projects tend to die a slow painful death, but what the hell...

Today I installed Gnome again. KDE left me in a sad state of mind. Also, I forgot Porcupine Tree from the listing in the last entry.

Today, I post the 11th entry. This means the blog system should begin to rotate entries. I do not actually know if it does so yet, but I'll check and fix it, if it does not do it the right way.

It is fun to see how much faster Gnome is compared to KDE on this desktop. Much less code to run through it seems.

Music needs to make the mind work. I love music where harmonics, rhytm and the groove is central. Polyrhyhtmic arrangements especially makes my mind a bliss. Here is a list of what I listen to at the moment:

• King Crimson
• Tool
• A Perfect Circle
• The Mars Volta
• Opeth
• Massive Attack
• Rage Against the Machine (Audioslave doesn't count)
• Soundgarden
• the Stone Temple Pilots
• Nine Inch Nails

I initially begin my programming with C. I had the standard BASIC things before, but it was more about understanding how BASIC worked than how you create programs. C was a good and fine language. I liked it a lot. There was a section in the book about C++, the new grand thing, and I did like many of the ideas they showed there, like operator overloading, function overloading, classes etc. However, the book emphasized C, and I was happy to code C for some time.

None of the programs I wrote from that time have survived (you will thank me for that), but I do remember building a text adventure game, without structure, and I do remember it was a mess to maintain.

At the age of 16, I began learning Standard ML. I think this is the reason I am so much for functional programming. My first real programs with style were written in Standard ML. I was happily oblivious to most of the problems programmers will face, since SML maintains a lot of the hassle for you. I learned about type systems and how it can help a programmer. I learned about what a higher order function was. I learned the module system and at last I understood the functor. I do believe this knowledge has changed me forever. C doesn't look nice to you anymore, after exposure to SML.

The latter years, I have delved into a number of programming languages: Python, Ruby, OCaml, Haskell, Scheme and Perl probably being the most important. Java "came along" as it was one half of the standard courses at DIKU (The other half is in SML, heh). This day, I find myself most content with the languages of Ruby, Python and Scheme. These languages are the ones that let me do most stuff in a quick manner, and I think that my precious time is the one that should be valued the most.

I Do like Haskell for its beauty, but I do not like it for most programming tasks, however. The Haskell problem is a couple of things:

• Lazy evaluation. This is a killer for your understanding of the run-time of your program. It is devastating to your understanding of space-consumption. I generally find it more irritating than a help for what I usually work with.
• Monad transformer stacks. These are beautiful beasts, but they are hard to maintain, when one of your inner functions suddenly have to throw an exception. You will then have to rewrite large parts of your code such that the transformer stack is maintained. Grrr.

I Do like SML, and was involved in the porting of the MLTon compiler to the NetBSD and OpenBSD platforms. But I still think we lack a nice "bare bones" compiler which looks a bit more like what Scheme48, Chicken or PLT Scheme is in the scheme world.

If you may ask, it is all about the build environment. Standard GNU autotools might be made in the Abyss, but they do the job and makes it fairly easy to port a program to another architecture. This is not the case of most SML compilers out there. They have their own big build systems.

Then there is the SML library effort which is lacking seriously. Without a big library of standard stuff and bindings, no-one is going to use your language this day. There is so much (admittedly crap) code out there, which you rather want to link with than compete against. This is a driving factor for productivity today. "No XML processor by default?". Tough luck, then the language doesn't hold.

It has come to my attention that PLT scheme can do what I want. It has some nice design by contract features. I'll test it out later this evening and see if it is fitting with my purposes

One sad thing with the scheme community is the divergence into different smaller communities. This way, it is next to impossible to make something general. Hopefully, we can come a good deal of way to kill that with R6RS.

I am also very eager to try playing a bit with MrFlow. It seems to be a nice thing and using that for construction of systems seem rather interesting. I can hopefully catch bugs and no-brainers before the code is compiled.

At mongers.org, we have a guy named Michael Knudsen. He is a very comptetent guy with a homepage on which he links to an article written by Philip Chu. It is named 7 habits of Highly Effective Programmers. In fact, there is much more than 7 rules in the thing. There is maybe 30 or 40 rules, but all of them are deliciously nice.

I intended to down something similiar, but it is much easier to link directly to a true master of his art, rather than trying to build something equal. I, personally, am very interested in software development methods; in particular about programming.

I am currently thinking a little bit about a scheme macro which lets you define functions as Eiffel contracts. By using this, it would be possible to write software with an extreme amount of assurance. Also add unit-testing into it. This can of course easily be done with a scheme macro. Further direction would be to add some funnier stuff to it, like the QuickCheck framework of haskell.

Ah, the wicked imagination

Modern website construction is much different from the old days. Yet, so few people seem to grasp what it is all about. I still see too much code written in HTML 4.01 with a traditional or loose class. There are fewer HTML 4.01 strict pages. Even fewer XHTML 1.1 pages again. But you only have half of the cool stuff if you think XHTML anyway.

The cool thing about CSS was the separation between structure in the document and the layout of the document. Used correctly (see The CSS Zen Garden), it is possible to generate enormously nice web pages with complete separation of layout and structure. You will be able to change your style in no time, just by altering the CSS. Furthermore, your graphic artist, multimedia designer or similiar does not have to dig around inside the code to change styles.

I propose to teach people the next level. The separation between information and structure. The blog here is written in Atom (This is the information part), structured via XSLT into XHTML1.1 and then applied with a style sheet. And lo and behold, now RSS/Atom readers can read the blog without having to know about structure.

When information and structure is separated, information becomes machine readable. And with the amount of information today, we need machine readable websites. The next logical step will be to use RDF on the site. This is on my TODO list, though it is not more than a imaginative design thing. I do not have a clear grasp of how to apply it.

Today, I added a XSLT stylesheet for cutting the latest 10 entries off from the blog and put it into an atom feed. See the endavours at the address split.xsl. I plan to extend this piece of code to contain month cutting as well. It should be possible with the EXSLT extensions I'd say.

I plan on research a bit into journal entry editors. There must be some generic XML format for pushing journal entries to a backend for feeding further to the site you have. Or so I think. If there is not, there must be another nice way, that makes up with the (tedious) task of writing directly in the XML blog file.

The date format used by Atom is the basic date format used by various XML Schema validators. The strftime() string is:

+%FT%TZ

The EXSLT defines some date-handling functions and Aristotle Pagaltzis placed some of it into the public domain. I have taken this and have used it to parse dates and present them better. While I was working on this part of the XSLT I changed the production to a nicer XHTML Version 1.1 rather than the mockup I started with. Hopefully you will like it more this way.

When I originally began programming, I was very unproductive. I had all these projects I would love to do and I began all of them. The problem was that none of the projects flourished. Usually I found the programming abandoned after a few days, because I lost interest in the program again. One could say that the program must have been unimportant. It will happen that you suddenly realize your program is insignificant.

The first advice is to cut down on the amount of programs you wish to write. You need a truly good idea, or you have to solve a problem better than what others have done. You need to focus on choosing the right project. Thougts are rather free and not as time-consuming as building a software project, gaining enough momentum, handling bugs, handle social relations in case you wish to publish it as an Open Source endavour, etc.

Next, when you come to the realization that the world actually needs your program, you should concentrate on what I call the spine of the program. Every program has a point of concentration which make the program go round. This is what I mean by spine. You should focus on constructing the spine before you focus on other parts. You get something that does something quicker.

You should not be afraid to use libraries en-masse. You get something quicker that way and having something quickly is the important thing here. If you find the library to be bad, you can either choose to patch it (and send the patch result upstream), or you can replace it with something better later to cut on requirements.

Forget about performance. Programming time is paramount when starting out. Optimizing the program can easily be done later. Further, profiling is much better at showing the performance hogs than you ever will be. Divination is hard and harder still for programs.

Try to live inside the 4-hour rule: Get something up in 4 hours. If you can't do that, you will need to shift your focus from the program to a missing module in your favorite language. You spine should be mostly glue code. If you find yourself beginning writing module code, you have either chosen the wrong programming language for the job, or your time is better spent on getting the module up first. You can then alter the goal to be writing the missing module instead. This is important, since if you break the 4-hour rule, you might end up with nothing if your attention-span is as low as mine.

When the ball starts rolling, embrace short development cycles. Eric S. Raymond wrote release early, release often in the Cathedral and the Bazaar. It is important to stress that an iterative process tends to be far more effective since you change smaller parts of the code all the time.

Regarding design, I like to imagine I have certain functions at my disposal and see what I can do with them. In Scheme this is done by making up new languages and write code in them. Then you can extend scheme to contain the language with a couple of macros and some helper-code around it. Also, playing with an imagined language extension will make you seed eventual defects before you even begin writing code. I have caught many bad designs in this way.

Regarding reading, you should definitely think a bit about what Paul Graham has to say.

I guess I should tell the world how this blog came to life. It all began with a homepage. The homepage was that of the schemer Jens Axel Soegaard. I liked the layout, but I have no interest in some big daunting blog tool.

Rather, I want simplicity. But the style was nice. Now, the easiest thing to do is to steal the style. So I did. With the style, I stole the general XHTML layout as well. Then the HTML was transformed into an XSLT stylesheet transforming Atom feeds to XHTML. With this finished, it is piece of cake to write a makefile around it for quick publishing.

As I only used 2 hours on this, there is a lot of holes in the idea. The most important is that additions of blog entries will make the feed very big over time. It is easy to fix, however, by creating an Atom to Atom XSLT transformation which cuts out the relevant part for the feed and then have the whole page generated for the homepage. I do not think I can produce enough material anyway. If I can, I will break the document via XSLT, Scheme or similiar tool and have multiple links to the older entries.

The intent is to produce a strictly-for-simplicity system. I won't be adding anything before it shows to be a problem. I intend to make entries describing the changes, when I do them. For now, you can browse the files that are there (The makefile is not worth it yet):

The atom feed

This is the atom feed which is the main file I write new entries in. I use

date
					  +%FT%TZ

for generation of dates.

The XSLT stylesheet transformation

This is what I call for Atom -> XHTML conversion.

I have decided to start up a blog yet again. This time I have decided to do it in the right way at the beginning and build a web-page on a simple foundation rather than on a big evil foundation.

The premise is a hand-crafted Atom feed bound with a XSLT stylesheet generator for building the XHTML output. This actually works. We can go in different directions from here. Editing of atom feeds could be made more automatic than it is now. There is a number of performance optimizations possible. And so on. The important part today is the availability of something.

Building this took 2 hours, more or less. It is a stable foundation we can build on from here. There are a number of things I would like to do to the pages, but as a start, this serves well.