Sunday, February 22, 2009

The Road Ahead for Paladin

For some strange reason, February is one of two months of the year -- December being the other -- where Real Life gets a stranglehold on my free time. Music teachers in the U.S. typically put on at least one Christmas-related program each school year, so December isn't at all a surprise, but February... that one is still a mystery to me. Between the icky weather, my daughter's birthday, and replacing a vehicle, I haven't had much spare time. Most of the spare time I have had has been spent tinkering with Linux because I've been too tired to do much of anything else until yesterday and today.

Even now I'm pretty surprised by the number of bugs that have been squished since Paladin's first beta release. There will be at least one more release candidate before the final 1.0. There probably wouldn't have been quite so many were it not for so few people actually reporting bugs. The vast majority of bugs fixed have been ones I've noticed.

None of this is to say that Paladin is more or less standing still, feature-wise. The bugs from the release candidates were almost all ones which I discovered while working on the development branch. Some of the new features include support for shell scripts and rez files, lots of internal cleanups, shorter build times, and the ability to recursively add a folder's contents just by dragging and dropping.

Adding entire folders makes migrating from other build systems incredibly simple and fast, especially when groups are also created for the user. Projects which have lots of files and subfolders, like Open Sum-It, for example, all that is needed is to drop the main sources folder onto the project window, add a few include paths, and change the system libraries in the Project Settings window. It won't be much longer and Paladin will be used to build PalEdit instead of jam -- rez support is still under heavy development as of this writing.

I don't know how far I'll be taking Paladin development, really. The future is wide open in that respect, but I'll describe some of the features that I'd like to make happen most. If nothing else, it'll make for some good Sunday evening light reading. ;-)

One feature that will be added, barring unforseen issues, is a one-click backup of a project into an archive. Coupled with a command-line switch, it could make for some simple nightly snapshot files and also provide a good alternative to using revision control for those people who don't have access to CVS, SVN, or whatever.

A personal code library could also be really handy, and it's a feature that I really want to see happen. The idea is that sitting around my hard drive are some reusable classes that I've used in different applications. For me, this includes a C++ wrapper class around SQLite3, a TextFile class that allows reading of a file one line at a time, and a bunch of things that eventually made their way into LibWalter. There aren't really so many classes to warrant my own personal library -- libdw or whatever -- but there are enough of them to be difficult to manage manually, particularly if I find a bug in a frequently-used class. The solution? A personal code library without the overhead inherent with a full-blown revision control system. Not all of the details have been sorted out, but if I think it would help me personally, others probably would, too.

Code generation facilities could also speed things up in a useful way, too. BeOS C++ developers do a lot of subclassing, and it would be nice to have a way to quickly give a class a name, check a few boxes, and have the generator churn out skeleton code. Instead of using cut 'n' paste or manually typing out a MessageReceived function for a BWindow subclass, checking a box could make the genenerator spit out something like this:
 void
MyWindow::MessageReceived(BMessage *msg)
{
switch (msg->what) {
default: {
BWindow::MessageReceived(msg);
break;
}
}
}

One checkbox to get this? Sounds like a nice tool to do all the boilerplate code, if you asked me.

Basic makefile and/or jamfile generation is still on my to-do list and would make migrating to a more complex build system easier. Code completion would be a wonderful help -- I'm forever having to look up the parameters to a BListView constructor because I use them enough to want to have them memorized, but not often enough that I actually have memorized them. A preferences window and profiling support are coming, too.

All in all, there are lots of exciting things coming. I'm not crazy enough to think that it'll become the de facto IDE for Haiku developers, but if it helps a few people start developing for BeOS / Zeta / Haiku and helps grow the community a little, that'll be far more than I ever thought would happen.

Sunday, February 8, 2009

Another Paladin Release Hits Light of Day

This one sure took quite a while. Murphy seemed to be in full swing during its development -- there were quite a few instances where there just wasn't enough time. Writing the documentation took quite a while, and then my development box didn't want to work properly. Just as mysteriously, everything started working right again just this afternoon. In the process, my development machine has ended up multibooting XP Pro, Ubuntu, Zeta, R5, and Haiku. I'll certainly be able to test for compatibility, that's for sure!

This release for the stable branch really isn't anything overly exciting except for bugfixes and (finally) some documentation, but that's not entirely a bad thing. It seems like unlike most of my other projects, Paladin has had general stability issues -- almost like there are always these little niggling details which just keep cropping up. Each time something comes up, though, I'm not generally too long in squishing them.

As I am able, I'm also working on the development branch. Right now, I'd say that there are two features that I will be implementing unless there are major issues: support for adding files and groups just by dropping a folder onto the project window and build support for rez files so that I can get rid of the jam system for PalEdit.

Saturday, January 31, 2009

Dust Can Do More Than You Think

For a while, I had a problem where the LCD monitor on my main computer would suddenly start flashing from whatever it was displaying at the time to black and back about twice a second. The weird thing was that the machine itself appeared to be "asleep" (i.e. not doing anything) while the screen was black. The problem appeared to be limited to Windows.

Thinking it was a problem limited to Windows -- like a driver problem or something -- I decided to spend quite a bit of time in Linux for a while to confirm my suspicions. As it turns out, there was a different problem -- the screen went black as if it had been put to sleep to save power, only there was no waking it. In fact, I had to do the magical Alt+PrintScreen REISUB reboot. Upon reboot, the boot text was garbled.

I couldn't find anything anywhere on the WWW about it either problem. I figured the card was bad, so eBay to the rescue with a Geforce FX5700 256MB to replace my 5500 for $35. Not bad. I'm still waiting on the card, though, so I was going to grab an old temporary card (ATI All-In-Window Radeon 32MB) to stand in until it arrived. When I pulled the 5500 out of the case, lo and behold, an entire family of dust bunnies had taken up residence in the cooling fan of the card! I figured this might have been the problem, so it got a careful once-over with compressed air, a quick replacement back into the machine, and... everything seems to have gone back to abnormal.

Moral of this story: dust bunnies aren't just cute, they're electrically delicious.

Sunday, January 25, 2009

Viruses, Spyware, and Trojans, Oh My!

I wear a great many hats at school. Amongst them is the all-around computer geek fix-it guy. In the last three weeks, I've had to remove spyware from two machines, and I'm currently in the middle of a complete reinstall on a colleague's home machine as a personal favor. The cause? Conficker, a.k.a. Downadup. Sigh. I tire of this kind of stuff. It would also be the reason why I highly favor other operating systems. Then again, the source of the infection was a keygen for some software. People looking to get commercial software for nothing seem to forget that pirates and software crack teams don't distribute their stuff out of the kindness of their hearts. The son of my colleague asked me what antivirus program I'd recommend. My first response, as a somewhat-pointed joke, was "Linux," but I wish I'd been able to reply with "Haiku."

Thursday, January 15, 2009

Easy Remote Linux Logins with FreeNX

With my having to fuss with networks at school and having a couple of machines at home, there have been a few instances where being able to remotely log into another machine has been a significant convenience. There aren’t many options out there unless you want to pay money:

  • RDP (aka Windows Terminal Services) – Free only for the client. As far as my limited experience has been, this is quite nice, fast, and it even supports audio. The only problem is that the licensing is quite draconian and it only is available on the server editions of Windows or a pay-for version for *NIX.
  • X11 – X was designed for network-transparent sessions. The only problem is that it’s not secure and setting it up over SSH is a pain.
  • VNC – Lots of good things here – free servers and clients for just about any platform you can think of and setup is pretty easy in most cases. The problem? It’s a bandwidth hog.

Enter the Italian company NoMachine, which offers its commercial NX Server for remote access under for Linux and its ilk with open source libraries. These libraries implement the NX protocol, which is more or less a way to both secure and speed up remote login connections.

As far as my experience has taken me, it hasn’t seen anywhere near the popularity that VNC has. I find this strange – VNC tends to be slow – even with compression – and is not secure on its own. It can also be a little weird to set up sometimes, as was the case for me setting up UltraVNC on a Windows box at school yesterday.

Perhaps it’s just me, but FreeNX deserves more limelight than it has received, if my setup experience from earlier today is any measure. Part of the ease of installation was thanks to http://www.drtek.ca. The main part of the site seems to be in French, but one page was both in French and English. Compliments of its author, I received listings for the repositories that I needed and was able to install the server with one command. Because NoMachine offers NX clients for both Windows, Linux, OS X, and Solaris, I went to NoMachine’s download page and grabbed the Windows and Linux versions. Just to test to see if things worked, I installed the Linux client on the server machine and tried to log into a regular terminal login and it worked – a little too easily for Linux, in my opinion. I tried a GNOME login from my windows box with the same results. I’ve come to accept the amount of tweaking that Linux requires in most cases, so when it just seemed to work, I was a little suspicious, but everything works as expected.

For a short summary, here’s the entire install process:

  1. Open up /etc/apt/sources.list and add the following lines to the end:

    # Ubuntu FreeNX Repository for Hardy
    deb http://ppa.launchpad.net/marceloshima/ubuntu hardy main
    deb-src http://ppa.launchpad.net/marceloshima/ubuntu hardy main
    deb http://ppa.launchpad.net/freenx-team/ubuntu hardy main
    deb-src http://ppa.launchpad.net/freenx-team/ubuntu hardy main

    # Ubuntu FreeNX Repository for Intrepid
    deb http://ppa.launchpad.net/marceloshima/ubuntu intrepid main
    deb-src http://ppa.launchpad.net/marceloshima/ubuntu intrepid main
    deb http://ppa.launchpad.net/freenx-team/ubuntu intrepid main
    deb-src http://ppa.launchpad.net/freenx-team/ubuntu intrepid main

  2. Update the list of packages kept on your machine by hitting Reload in Synaptic or sudo apt-get update from the Terminal
  3. Install the freenx-server package, either from Synaptic or from the Terminal using sudo apt-get install freenx-server .
  4. Grab the necessary clients from NoMachine’s download page and install on the machine of your choice.
  5. Marvel at the lack of work required.

There is still the ability to tweak the configuration until the Second Coming of Christ, as is typical of Linux, but this is only needed if you want remote printing (which I haven’t tried… yet), sound, or certain other things like setting up a remote login cluster or something. If you just want to be able to log in, you’re done. Ain’t that nice.