Reinventing the Wheel
I found something neat today called ReactOS. The goal is to recreate an open-source successor to Windows XP based on the Windows NT kernel. The analogy has probably been done to death, but it sounds a lot like another open source OS that re-implemented an existing one. It sounds like a great idea, or at least a very ambitious one, intending to put a stranglehold on Windows’ security holes and optimize the hell out of it. Interestingly, they had this to say of a group of operating systems that already accomplished this:
Modern incarnations like Mac OS X put a fancy graphical user interface on top of UNIX, to hide system details and focus mainly for beginners and likely advanced users are left out in the rain. In contrast, various Linux and BSD flavors have been put together originally for server usage and are therefore very console centric. Most advanced features cannot be accessed from the basic graphical user interface. Almost all UNIX flavors retain some of the original design flaws and binary compatibility between various versions is usually non-existent
Now, it’s probably a bad idea for me to argue with a group of people who are capable of building their own operating system, but there are some flaws with these arguments. We’ll deal with Mac OS X first, because it’s the easiest, and applies to all the popular *nix windowing environments:
Hiding in Plain Sight
Though the terminal is probably the most easily-recognizable tool to get past the GUI, it’s not the only one. Most windowing environments provide a processor viewer similar to top, a log viewer, and even a SELinux policy generator with my copy of Fedora. It’s true that a GUI is meant to hide the complexities behind something simpler, but advanced users are hardly forced to deal with a Fischer-Price OS when more advanced tools are so readily available.
The assertion that server versions are the polar opposite is at least partially true; the most powerful features tend to require some advanced tinkering, after all, it’s a server. It’s hard to simplify that which must be equal parts accessible to trusted clients and guarded against those who aren’t. Some efforts have been made to putting a friendlier face on administrating network services, and while I’m a fan of Mac OS X Server’s admin tools, others simply prefer the control afforded by the more venerable terminal.
The final argument about legacy flaws and binary incompatibilities may as well be true. These operating systems have all been around for a long time, and the potential for junk to pile up (not unlike my closet) is a given. Are these issues so entrenched as to make it impossible or merely difficult to overhaul? Is the solution to renovate, or throw out decades of hard work and begin fresh? I don’t envy the people staring down these decisions. Binary incompatibilities is an issue I’m barely qualified to touch on, so let’s leave it there.
As for ReactOS:
In contrast to UNIX, ReactOS was designed for people familiar and comfortable with the Windows environment. Everything can be done through the well known Win32 user interface and advanced users are free to automate tasks with scripts or use the console.
“Everything,” which I’m assuming they don’t mean literally, can be done through the GUI, and advanced users can write scripts and access the console. This all sounds rather familiar. ReactOS sounds like a very cool project, but I think we’ll have to disagree about the current state of *nix operating systems.
Pointing Fingers
An array is useful, and a pointer is useful, and if a pointer pointing at a dynamic array is more useful yet, then surely a dynamic array of pointers must be made of awesome sauce. Cocoa has spoiled me a bit, what with NSMutableArray acting as just the ticket, but at a probable expense. Complexity and abstraction layers are the enemy of framerate, so I’ve turned to C arrays to solve a time-sensitive problem. After a couple hours of poking around, I’ve found a solution, though I can’t tell if this is elegant, hackish, or just downright silly:
typedef struct {
GLuint *texturePtr;
} TextureStruct;
TextureStruct * allTextures;
So what’s going on here? Originally, the plan was to have an array of GLuints to keep track of loaded textures (there’s no sense of loading the same data twice on a handset with little memory after all). The array doesn’t know how big it will be at compile time, and more importantly, it might grow or shrink during runtime, so a declaration of GLuint * texture; seemed like the logical thing. Problem is, arrays hold data, but this array must hold pointers. Wrapping the pointer inside a struct and then declaring a pointer/array of the new structure does the trick, but it feels crude.
It’s a strange feeling though, that the actual data doesn’t have any central location. A texture is loaded when an object needs it, but the texture doesn’t belong to the object, nor does it belong to the above structure/pointer/array monstrosity. It just hangs out.
OpenGL ES from the Ground Up
Back in developer land, I’ve found something terribly interesting. A fellow by the name of Jeff Lamarche has written up an OpenGL ES tutorial geared towards iPhone Devs. OpenGL has always terrified me, so this will be a great resource. Better yet, OpenGL, as hinted by the word “open,” is intended to be a very portable cross-platform tool, so the lessons learned should be equally portable.
New Ground
A few days after deciding to embark on this crazy plan, it occurred to me that perhaps I should get used to running a real Linux distro on my MacBook if I’m to make this work. Sure, Mac OS X is pretty UNIX’d up, but the goal here is to get used to something a little more unfamiliar. The MacBook was happily running Ubuntu (Intrepid Ibex) a few months ago, but was sadly just a curiosity at the time and didn’t get much love. So, about a month ago I formatted the drive and threw on Jaunty Jackalope which mostly pleased except for one big problem: gksu crashed and crashed hard.
It’s a bit of a show-stopper, since this is the process by which admin access is granted through the GUI, meaning that the whole system grinds to a stop whenever the system tries to do something like install an update to patch bugs. On the other hand, this can’t be affecting every Ubuntu user, or there would probably be a lot more talk about it. Chances are, there’s a very specific set of circumstances that conspire to invoke the bug, and I’m just unlucky enough to match said circumstances. The whole thing could probably be fixed up by patching the system via command line instead, but after a week of this I had already moved on:
Instead of getting familiar with just one distro, why not a few? Ubuntu was nuked and replaced by Fedora 10. This might seem a slightly crazy idea with Fedora 11 just around the corner, but the purpose of this exercise is after all to get used to installing and using different distros, so why not? Fedora also supports HFS+ out of the box, which is tremendously cool. Not only can I mount my Mac OS X partitions, but it even supports the directories’ permissions. Better yet, Fedora apparently is one of the focuses of the *nix admin course. Sold. So far so good, and only getting better.
