Bye Erasmus
I have decided, after months of no development, to officially call an end to my Erasmus kernel project. I dived into the project with no aims or goals other than a vague sense of wanting to make something good. Later I thought up targets so I could use version numbers, but a plan from the beginning was needed, really. So, no more Erasmus until I have a good plan first. I do intend to start up Erasmus again one day, though when I do it'll be more-or-less a complete rewrite of the current version as, currently, large chunks of it are code copied from elsewhere which I don't really understand. Which, obviously, causes problems. Perhaps I'll meet someone interested in OS development at University and we'll start up the project again together; having had another person, if only to bounce ideas off, would also have helped me.
In summary, when I started the project I was a mediocre C programmer and pretty rubbish at ASM. I didn't understand many of the concepts I was working with, and so it's a miracle it got as far as it did.
But that will change! One day, perhaps as a microkernel (I like the way the Hurd does things), perhaps as a monolithic kernel, a hybrid, or something else entirely, Erasmus will return! I realise now that saying things like "By version 0.3 I'll have a port of zsh" was a silly, limiting thing to do. I should focus on making a good kernel, and see where I go from there, rather than focus on writing something which can run a particular Linux app.
Watch this space...
Half Term Week, and, one month of Spork Bomb
Well, one month tomorrow, but near enough.
School has ended for half term week—a whole 5 week days off, and what shall I do with this vast amount of free time on my hands? I have a couple of plans. Firstly, Erasmus. I'd like to hit version 0.1 and make a dent in 0.2 this week, as I have free time I can't really hit a snag and put off solving it indefinitely due to “schoolwork”.
Remaining 0.1 features:
- Working memory manager
- IDE driver
- ATA driver
The IDE and ATA drivers have sort of merged, which is ok, for now; I can separate them when I start on ATAPI. The memory manager is there, but doesn't work: I'm going to write one from scratch rather than just borrowing/editing code, as then I'll definitely know what's going on.
After Erasmus, fractalgen. I want to figure out how to create arbitrarily large images with gd; if I try to make one too big it complains about the size exceeding INT_MAX, or something like that. I refuse to believe gd has such a limitation that has no work-arounds when it comes to large images. I also want to start on my fviewer program, a GUI to display / zoom fractals. Smooth colour shading would be nice, but it's not really a high-priority feature currently.
Of course, there are always books. I've still got a heap of books from Christmas to read, and with 9 days before school again, I should be able to get through at least one, perhaps two. I make it sound like I try to read books as quickly as possible, which isn't entirely true: I just dislike having unread books lying around, when I re-read books, I do take my time and generally notice things I didn't the first time through.
Leading on to other forms of entertainment: anime. I have borrowed the first two seasons of Claymore which, hopefully, I'll enjoy. Claymore is about a world in which humans coexist with yoma, demons, where there exists a group of half-human half-yoma warriors, the Claymores, who protect the humans (for a fee).
Finally, after mpdspl was rewritten to be much better by sdelafond, I have been spurred into action to improve mpddp. A complete rewrite; a second version. It will be object-orientated and have much better code organisation (the current program is a mess: why I change it so very rarely), and I have a vague notion of wanting a “more powerful” config syntax. Currently each line of a config file acts as a boolean OR: including everything which matches this line, OR that line, OR another… I want to include more boolean operations, AND at the very least, perhaps NOT (that's currently worked-around by the “never” keyword) or XOR, too.
Of my plans, mpddp 2 is the one I'm most excited about implementing. I can barely remember how the current code works, so I'll most likely read through it to figure out which functions do what, and then just write version 2 from scratch.
