Journal Fordiman's Journal: Linux and me
For the last, oh, ten years or so, I've had a love/hate relationship with linux (I love ya baby, but why you gots ta hurt me?)
It started with Slackware in 1992. I didn't understand why it didn't have a GUI. Of course, I was fourteen, and didn't understand that Linux in those days had to be wrought with sweat and blood.
And sweat I did. Bled a little too (case edges are sharp). And eventually lost every piece of data I had on my computer to Partition Magic 4.0. Or maybe it was 3.0. It's been a while.
Later, I moved on to other distros, ranging from Red Hat to Xandros, and even "Damn Small Linux" (an awesome project, by the by). Knoppix has been in there as the "I wanna see how my ole buddy linux is doing, but I don't wanna get too involved. I've been hurt, you know?"
It's been there since about 3.2.
Knoppix 3.2 was rough. KDE hadn't quite gotten its edges smoothed out, and Knoppix hadn't (hasn't) quite gotten the hang of a fully integrated system.
So I dabbled in DSL for a while, even built a few modifications of it. Using squashfs instead of cloop, modifying the kernel to support 256 looped filesystems, and writing software to symlink a compressed filesystem into an existing filesystem provided chintzy but effective package management similar in functionality to DSL's "Unified Compressed Image" format, but with greater functionality. While in the process, UnionFS had suddenly made my efforts pleasantly unneeded. I never finished, and instead tried out Knoppix 3.8.
And didn't have a complaint. Nor did I have a spare HD to try it on.
But 4.0 came around, and I did. So I gritted my teeth and prepared to install linux - again.
Before I begin, I must state that I'm loving Linux right now. I have a fully operational two-user (myself and root, with myself logged in automatically) debian system. (by the way, I don't care what RedHat says. I love apt.)
Knoppix 4.0 is nice. It's well polished, and even went for the slightly more slick Plastik theme as the default (a sign of someone noticing that while pretty isn't functional, most humans respond to it).
But I must complain. It didn't detect my ancient sound card automatically. (It's ISA, but 3.4-3.8 got it first try). More likely than being Knoppix's fault, I'm more inclined to blame the shiny new 2.6 kernel. It's faster than 2.4 was, granted, but it seems like the new fork is abandoning older systems. That makes me sad.
KDE's desktop icon management is poorly done in Knoppix; it creates device-mount icons for removable devices rather than shortcuts to their autofs equivalents. Easily fixed and forgiven, but it should be said.
Meanwhile, Klaus did a lovely by making the autofs umount timeout only 2 seconds long. Means you have to (rather, should; you don't _have_ to, but you'll be sorry if you don't) sync floppy writes, but I'm kinda used to doing that anyway.
In a completely unrelated note, but amusing nonetheless: four to five whole number versions later, PartitionMagic 8.0 still ruins any filesystem it attempts to resize. I discovered this when I tried to shrink my movie/music archive to minimal in an effort to convert everything to stable linux-writable filesystems. Fortunately, I had backed up my music recently, and Data Rescue PC is an awesome piece of software - one you should buy if you do stupid things, like attempting to use Partition Magic for anything more than a coaster. Seriously. You'll retain more data by wiping your partition table and rewriting it; at least that doesn't try to move data around.
One thing that amazed me: how WELL wine works. It takes a little coercion to get set up properly (it's setup utility, for some inexplicable reason, does not set up the ${HOME}/.wine/dosdevices folder. Once I had figured that out, everything worked hunky-dory.
I say this not because I was trying to run any windows applications or software. I was trying to run pogoshell.
See, I have this cool GBA linker, and I thought I was going to have to abandon it (or at least, do my GBA development / illicit library borrowing actions at my work computer). However, I discovered that the company that produces my cart had put out beta drivers for my cart.
Unfortunately, none of the multirom tools were with it. Just the "put this file on my cart" software. After getting frustrated with the speed - rather, lack thereof - of the multirom tool under dosbox, I looked into other alternatives. One was trying to compile PogoShell from source. After modifying the code a bit for compatibility (PogoShell is written in non-cross-compatible Win32 C), this nearly worked, however, I must have missed something, as it would generate a ROM, but not a working one.
After looking at the code, however, I had an idea. Even the command line apps make Windows API calls, so they must be Win32 console apps (as opposed to generic console apps - indeed, all the tools were set to compile via Microsoft's free command-line linker). So why not use wine?
After playing with wine for a bit, I ended up making launch shell-scripts for all the Win32 tools (storing their actual executables in /usr/local/lib and the shell scripts in /usr/local/bin - both are rather spartan in Knoppix 4.0, so I figured what the hell). Then I modified the bat files to be shell scripts as well, and - WHAMMO! I had my GBA linker working to full capacity again (and PogoShell beats LittleWriter's interface any day). Hell, maybe I'll even make a frontend. Couldn't hurt, you know?
I'm kinda bothered by the fact that the interface code for a GBA Development cart isn't open source. For one, it's a free driver, free software all around. For two, it's for a DEVELOPMENT CARTRIDGE. What does anyone gain by keeping the source closed (keep in mind that DevKit Advance started as a project for linux)? Third, is it really that much of a competition thing if someone, somehow, through your driver source code, duplicates your cart? It doesn't come in the realm of reverse engineering; driver source code is more or less behavior documentation for the clever; as such, it's a "dirty" source of data.
Meanwhile, opening it up means a greater range of functionality for the product. For example the program that handles the usb connection between GBA and computer has to load, do its checks, upload the multiboot server if necessary, and do its work. If the source was available, I'd modify it to work as a server. This way, frontends can work more quickly for multiple reads and writes (loading/saving SRAM, writing multiple carts or just localized blocks, etc). Littlewriter is SLOW because it has to rely on a closed library with limited functionality. (meanwhile, I KNOW that my cart supports localised block flashing. But enough.)
Anyway, I've tangentted, but the gist of it is that Linux today does a LOT more a LOT better than it did last year, and is light-years ahead of it's old place when I started to play with it. It's now my desktop system, and I love it. Not for the ability to do low-level tweaking (I do love DOING that, but having to do it is a pain in the ass), but for the ease of use if you just want to use the damned computer.
We're getting there, people. We've even got the mainstream focus. Linux: Not Just for the Server Room Anymore.
It started with Slackware in 1992. I didn't understand why it didn't have a GUI. Of course, I was fourteen, and didn't understand that Linux in those days had to be wrought with sweat and blood.
And sweat I did. Bled a little too (case edges are sharp). And eventually lost every piece of data I had on my computer to Partition Magic 4.0. Or maybe it was 3.0. It's been a while.
Later, I moved on to other distros, ranging from Red Hat to Xandros, and even "Damn Small Linux" (an awesome project, by the by). Knoppix has been in there as the "I wanna see how my ole buddy linux is doing, but I don't wanna get too involved. I've been hurt, you know?"
It's been there since about 3.2.
Knoppix 3.2 was rough. KDE hadn't quite gotten its edges smoothed out, and Knoppix hadn't (hasn't) quite gotten the hang of a fully integrated system.
So I dabbled in DSL for a while, even built a few modifications of it. Using squashfs instead of cloop, modifying the kernel to support 256 looped filesystems, and writing software to symlink a compressed filesystem into an existing filesystem provided chintzy but effective package management similar in functionality to DSL's "Unified Compressed Image" format, but with greater functionality. While in the process, UnionFS had suddenly made my efforts pleasantly unneeded. I never finished, and instead tried out Knoppix 3.8.
And didn't have a complaint. Nor did I have a spare HD to try it on.
But 4.0 came around, and I did. So I gritted my teeth and prepared to install linux - again.
Before I begin, I must state that I'm loving Linux right now. I have a fully operational two-user (myself and root, with myself logged in automatically) debian system. (by the way, I don't care what RedHat says. I love apt.)
Knoppix 4.0 is nice. It's well polished, and even went for the slightly more slick Plastik theme as the default (a sign of someone noticing that while pretty isn't functional, most humans respond to it).
But I must complain. It didn't detect my ancient sound card automatically. (It's ISA, but 3.4-3.8 got it first try). More likely than being Knoppix's fault, I'm more inclined to blame the shiny new 2.6 kernel. It's faster than 2.4 was, granted, but it seems like the new fork is abandoning older systems. That makes me sad.
KDE's desktop icon management is poorly done in Knoppix; it creates device-mount icons for removable devices rather than shortcuts to their autofs equivalents. Easily fixed and forgiven, but it should be said.
Meanwhile, Klaus did a lovely by making the autofs umount timeout only 2 seconds long. Means you have to (rather, should; you don't _have_ to, but you'll be sorry if you don't) sync floppy writes, but I'm kinda used to doing that anyway.
In a completely unrelated note, but amusing nonetheless: four to five whole number versions later, PartitionMagic 8.0 still ruins any filesystem it attempts to resize. I discovered this when I tried to shrink my movie/music archive to minimal in an effort to convert everything to stable linux-writable filesystems. Fortunately, I had backed up my music recently, and Data Rescue PC is an awesome piece of software - one you should buy if you do stupid things, like attempting to use Partition Magic for anything more than a coaster. Seriously. You'll retain more data by wiping your partition table and rewriting it; at least that doesn't try to move data around.
One thing that amazed me: how WELL wine works. It takes a little coercion to get set up properly (it's setup utility, for some inexplicable reason, does not set up the ${HOME}/.wine/dosdevices folder. Once I had figured that out, everything worked hunky-dory.
I say this not because I was trying to run any windows applications or software. I was trying to run pogoshell.
See, I have this cool GBA linker, and I thought I was going to have to abandon it (or at least, do my GBA development / illicit library borrowing actions at my work computer). However, I discovered that the company that produces my cart had put out beta drivers for my cart.
Unfortunately, none of the multirom tools were with it. Just the "put this file on my cart" software. After getting frustrated with the speed - rather, lack thereof - of the multirom tool under dosbox, I looked into other alternatives. One was trying to compile PogoShell from source. After modifying the code a bit for compatibility (PogoShell is written in non-cross-compatible Win32 C), this nearly worked, however, I must have missed something, as it would generate a ROM, but not a working one.
After looking at the code, however, I had an idea. Even the command line apps make Windows API calls, so they must be Win32 console apps (as opposed to generic console apps - indeed, all the tools were set to compile via Microsoft's free command-line linker). So why not use wine?
After playing with wine for a bit, I ended up making launch shell-scripts for all the Win32 tools (storing their actual executables in
I'm kinda bothered by the fact that the interface code for a GBA Development cart isn't open source. For one, it's a free driver, free software all around. For two, it's for a DEVELOPMENT CARTRIDGE. What does anyone gain by keeping the source closed (keep in mind that DevKit Advance started as a project for linux)? Third, is it really that much of a competition thing if someone, somehow, through your driver source code, duplicates your cart? It doesn't come in the realm of reverse engineering; driver source code is more or less behavior documentation for the clever; as such, it's a "dirty" source of data.
Meanwhile, opening it up means a greater range of functionality for the product. For example the program that handles the usb connection between GBA and computer has to load, do its checks, upload the multiboot server if necessary, and do its work. If the source was available, I'd modify it to work as a server. This way, frontends can work more quickly for multiple reads and writes (loading/saving SRAM, writing multiple carts or just localized blocks, etc). Littlewriter is SLOW because it has to rely on a closed library with limited functionality. (meanwhile, I KNOW that my cart supports localised block flashing. But enough.)
Anyway, I've tangentted, but the gist of it is that Linux today does a LOT more a LOT better than it did last year, and is light-years ahead of it's old place when I started to play with it. It's now my desktop system, and I love it. Not for the ability to do low-level tweaking (I do love DOING that, but having to do it is a pain in the ass), but for the ease of use if you just want to use the damned computer.
We're getting there, people. We've even got the mainstream focus. Linux: Not Just for the Server Room Anymore.
