FreeDOS Blog

❮ Back

March, 2009

Attending Penguicon

I have been confirmed as a Nifty Guest for Penguicon 7.0, a science fiction and open source software convention. This year's Penguicon will be May 1-3, at the Crowne Plaza Hotel in Romulus, Michigan. I'm presenting at two sessions: "Linux in the Enterprise" and "Starting your own Free/open source software project." Other guests planning to attend include Wil Wheaton, and John "maddog" Hall (no relation.) It should be a lot of fun!

If you're planning to attend Penguicon, look me up. I'd love to see lots of FreeDOS friends in the audience!

University of Minnesota

If you live in Minnesota, especially in/near Minneapolis, you may be interested to know that I'll be speaking at the University of Minnesota. I don't have an exact date yet, but it will be mid-April. My talk will be about Free software development, using FreeDOS as an example. I'm looking forwards to it!

Using the wiki

I had an email discussion with someone about the FreeDOS Wiki, asking about the "help" pages that show the usage of the different FreeDOS commands. For example, the page for As I mentioned in my other email, the in the wiki was split off from the Spec. It is a reference standard only, not necessarily the command line options that can be used with the actual FreeCOM/

I split off each of the commands from the FreeDOS Spec because too many people assumed the Spec was a single "cheat sheet" that showed how to use each of the commands. And of course, that's not true; the Spec is only a reference standard, what commands must support. Which is why the entry has a simple usage.

But by splitting off each of the commands into its own page, I have set it up so that someone (Fritz? Eric?) can go into the wiki and update the command line data with the actual command line usage. That would make the wiki the obvious place for everyone to get help info, and for the Fasthelp program to pull its documentation (for example, a developer with a Linux desktop could easily script a method to pull all the wiki pages for all the FreeDOS commands, and save them as individual html pages.) The wiki conveniently puts all the content for this in <div id="content"> so would be easy to script. I did something very similar for my blog, but the div name was different (obviously.) Here's my blog example. Behold the power of AWK!

/<div class="post hentry category-/ { blog=1 } /<div/ { if (blog==1) {div++} } { if ( (blog==1) && (div>0) ) {print} } /<\/div/ { if (blog==1) { if (--div == 0) {blog=0} } }

I haven't tested it, but I think if you changed the first line to use <div id="content"> everything would work automatically.

It would be better to maintain some pointer back to the reference version, but I have to leave that to someone else since I am leaving the project in May.

Next steps in transition

I have been thinking about the next steps in the transition, so that there's a seamless transfer when I step away from the FreeDOS Project in May. Obviously, I'm still around at this point, so you can feel free to email me with questions,etc. But starting in April, anyone who tries to contact a webmaster really should get pointed to Aitor and Eric. Just to let everyone know, around April 4 I'll remove myself from the Webmasters page. I'll still be a webmaster, and I may even update pages after that time, but new contacts should go to Aitor and Eric.

I'm not sure what mail lists I'm still subscribed to, but I'm also considering taking myself off all lists except freedos-devel as of April 4.

I plan to continue updating the FreeDOS Wiki, and posting "vision" items to my blog page. However, I will try to avoid posting any news items on so others can get some practice doing that.

Moving forward

At the end of my involvement in FreeDOS, I ask myself: What does FreeDOS need to move forward? What should FreeDOS do to make it stand out?

First, I think the FreeDOS kernel needs to be cleaned up. There has been a lot of tinkering in the kernel, trying to save 10 bytes here, 8 bytes there, 12 bytes somewhere else. While the motive was good (kernel should take up the least memory possible) what's happened is that the kernel source code became more difficult to work with. DOS should be a fairly simple thing, compared to other kernels. I want to encourage some interested developer to pick up the source code and simplify it, even if that means undoing any of the memory savings.

Above all, the kernel needs to work reliably. Today, we have two branches of the FreeDOS kernel: 2036 stable, and 2037 devel (unstable). That shouldn't be ok, yet somehow we've convinced ourselves this is acceptable. Having two versions of the kernel, where the most recent branch is effectively "broken", is what's keeping us from moving forward with the kernel. Is it easier for a kernel developer to start with 2036 and re-add the features from 2037? Or is it better to fix the broken parts from 2037, to release a (working) 2038 version? I lack the skill to do any kernel development, so I never tried. I'm hoping someone with the necessary energy and enthusiasm can work it out.