The Trials of a Linux Geek

Vixie Cron How I Loath Thee.....

2011-07-14T21:38:00.000-07:00

As some know, I work as the senior systems administrator for a company in the southeast SF Bay Area. Recently, we had to move to a new security system, after having been broken into four times in the last _four_ years.

One of the features of this new system is that it ties into our phone system to alert the building that the alarm is about to be armed. To do this, a dial out to a special phone number needs to occur at the desired hour and then voila! Instant Alert throughout our suite! So, we've setup an email to fax service that we can easily trigger by a simple email.

So I wrote a REALLY simple shell script shown below (with the fax and email addresses elided):


#!/bin/bash

set -e

echo "Sending Security Page NOW!"

/usr/sbin/sendmail -t <<EOF
FROM: SOMERANDOMSMUCK@minervanetworks.com
TO:   1234567890@fax.com
CC:   SOMERANDOMSMUCK@minervanetworks.com
SUBJECT: Alarm Set

Set.

EOF

RET=$?
if [ $? -eq 0 ]; then
    echo "SUCCESS"
fi

As I said, simple.

From there I setup my crontab on one of the Linux box in my cube to have it go off at the apropriote time, 7:55PM Monday through Friday:


MAILTO=SOMERANDOMSMUCK@minervanetworks.com

50 19 * * 1-5 /usr/bin/securityfax.sh

Tested out the script, thinking that "Hey, I'm all done". Wrong.

I come to find out that Vixie Cron can't seem to tell time! I get the alert emails at 8:31PM from the system!

At this point, looks like I'll be replacing Vixie Cron on my workstation (CentOS 5). Can anyone advise a good Cron Daemon replacement that has enough similarities to vixie cron that I won't have to relearn too much and can actually interpret time settings in the crontab as more than mere suggestions?

Qt, Nokia, and the Internet Rambling.....

2011-02-11T20:53:00.000-08:00

So, most of you who read my blog know about Nokia's deal with Microsoft. To re-iterate the best image posting I've seen on planetkde via John Layt's blog: Keep Calm and Carry On.

Yes, Microsoft has been a major negative force on computing, especially with regards to the freedoms of end users. This however does not warrant the extreme and in many ways self-defeating knee-jerk reactions that have been permeating the Interwebs oft lately on the F/OSS blogs.

Lets rather, take a wait and see approach to this. There really isn't enough information on the ground at this point in the game to know what is or is not going to occur in the immediate or even long-term for Qt Development Frameworks at Nokia. Lets trust in our friends at Nokia to gather up the information that the community is craving to know and get it ready for public consumption.

Until then, Nothing to See Here, Move Along.

What I've Been Doing Lately... Or Better Said, Coding Lately.

2009-10-13T00:29:00.000-07:00

Lately I've been doing research to get an Exchange resource working and usable for KDE. During this time, I've had to have a working trunk build since OpenSuSE's Build Service tends to have custom patches for their build of KDE that make some things not behave or look how the default KDE trunk tree acts/looks (that's not a comment that that's bad, just not my want for when I do development, but I digress...)

To facilitate this, I'd been using the shell scripts that KDE has on Techbase and on the OpenSuSE wiki to build trunk. I've found however, that my time would be better spent working on code, instead of waiting on code to compile when at home. Since I wanted something that would even fully track Qt's Git tree and email me when builds ran or error-ed out, kdesvn-build was not going to meet my needs. What came out of it was a hacky little Perl script called KDEBuilder that was fairly fragile and frankly not designed at all.

While thinking over the mess that was KDEBuilder, I realized that what I *really* wanted was something that was flexible, feature rich, and wasn't an overblown ported shell script on steroids. Out of this came the design for Direktor, a continuous build system written in a clean Perl code style (heavily influenced by the Google Perl Style guide....) To better describe Direktor, I've pasted the ReadMe.txt from the source tree below:

DOCUMENTATION FOR DIRECTOR:

Direktor is a continuous build system primarily meant for use by the KDE open source project. The goal was to create a system that built KDE and it's various dependencies efficiently and allowed the user to be notified and to monitor the progress of the builds.

To achieve these goals, Direktor can be configured to e-mail out the build announcements and build failures. This is augmented by the HTML data that is generated to create a dashboard for the build.

DESIGN:
Originally, Direktor was only a simple Perl script that would naively build KDE trunk and announce simple e-mailed snippets to an email address. This became fairly ungainly as time went on with the need to add in Qt4 to the build. This is when it became obvious that the build methods needed to be more abstracted away to allow any software (including KDE's base dependencies if so desired) to be built with this system.

To facilitate this, Direktor was re-factored to use description files to detail various aspects about the build and source control system per module or project. These description files are nothing more than INI files with required entries to make the system work.

A typical description file follows:

fig. 1: qt4.direktor


# Direktor 1.0
name = qt
repository_type = git
in_source_build = TRUE
source_repository = git://gitorious.org/+kde-developers/qt/kde-qt.git
source_directory = \$HOME/sources/qt-kde
prefix = \$HOME/installs/qt-kde
configuration_flags = -qt-gif -debug -fast -no-separate-debug-info -system-libpng -system-libjpeg -system-zlib -dbus -webkit -plugin-sql-mysql -nomake examples -nomake demos -prefix \$QTDIR
environment = QTDIR=$HOME/installs/qt-kde \
              PATH=$QTDIR/bin:$PATH \
              QT_PLUGIN_PATH=$HOME/installs/trunk/lib/KDE4/plugins:$QTDIR/plugins \
              PKG_CONFIG_DIR=$QTDIR/lib/pkgconfig:$PKG_CONFIG_DIR \
              LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH \
              QTEST_COLORED=1
configuration_command = configure
build_command = make
build_flags = -j2
install_command = make install

As can be seen, this allows the system to be very versatile with builds allowing one to build any package. The configuration_command, build_command, and install_command options allow can be any conceivable valid Linux command, even
scripts.

The fields in a direktor file are required. Lets review the fields and their format:

# Direktor 1.0
This is the description and format version of a description file as used by this application.

name:
This is an arbitrary string value. It is mainly used to present information about the module to the user.

repository_type:
This is a string value that takes one of the following values: svn, git, file, cvs, or p4. This tells Direktor which type of repository the module lives in. The file option tells Direktor that the source is not in a revision control system, but rather is a release tar.bz2, tar.gz, tgz, or zip archive.

in_source_build:
This attribute takes either a TRUE or FALSE. This boolean value tells Direktor to build the binaries from within or outside the source directory. Increasingly, many of the open source applications are built outside the source directory.

source_repository:
This is the location of the source repository or the full path location of the archive that contains the sources of the project to build.

source_directory:
This is the location where the unpacked or checked out files will be placed on the local hard disk.

prefix:
This is the prefix where the resultant binaries will be installed to.

configuration_flags:
These are the flags to pass to the script or application called to configure the source tree for compilation.

environment:
This describes the environment variables and values that must be set to allow the build of the source code to complete correctly. These are placed one per line with the continuation character being the forward slash.

configuration_command:
This tells Direktor what command or script to run in the source directory to configure the source code for compilation.

build_command:
This tells Direktor what command or script to run from the build directory to compile the source code into binary object and executable code.

build_flags:
This instructs Direktor to use the requested flags with the command to build the source tree. In many cases, this is to instruct the compiler to use non-standard library or header locations, or to do the build in parallel allowing the job to complete faster.

install_command:
This instructs Direktor what command or script to run from the build directory to install the resultant binaries produced in to the prefix earlier specified.

Note that any time an environment variable is requested that has a dollar sign in it must be escaped to properly be interpolated by the shell that is invoked by Direktor.

REGISTERING MODULES:
To register the modules, simply add the module direktor file names without the .direktor extension to the .direktor.modules_registry located in the build user's home directory. The header line declares the major series of Direktor that can read this format. An example .direktor.modules_registry follows:

fig. 2: .direktor.modules_registry:


# Direktor 1.0
qt4
kdesupport
kdelibs
kdepimlibs
kdebase
kdepim
kdemultimedia

WORK FLOW:
When Direktor starts, it clears the current environment and then sets up the global parameters defined in it's configuration stored in the home directory of the user running the build. This file is called $HOME/.direktor.cfg, and is in an extended INI format.

fig. 3: .direktor.cfg


# Direktor 1.0
[GENERAL]
user = somebody
group = users
registry = $HOME/.direktor.modules_registry
announce_start_via_email = 1
announce_builds_via_email = 1
announce_errors_via_email = 1
announce_completion_via_email = 1
use_dashboard = 1
; these next two are mutually exclusive!
use_watcher_to_dispatch_builds = 0
use_scheduler_to_dispatch_builds = 1
; needed for any non-generic initial repo setup that you will need. Remember,
; this gets run if the lock file $HOME/.direktor.firstrun does not exist.
first_time_startup_script = firsttimesetup.sh

[EMAIL]
from_address = someone@somewhere.net
to_address = somelist@somewhere.net
cc_addresses = bob@somewhere.net,bugs@somewhere.net
subject_prefix = MY BUILDER

[DASHBOARD]
html_upload_path = somehost.somewhere.net:/home/builder/public_html/
upload_user = someone
upload_cioher = arcfour

[WATCHER]
email_inbox = scm-monitor@somewhere.net
action_to_take = queue_all

[SCHEDULER]
queue_file = \$HOME/.direktor.schedulerrc
action_to_take = fullbuild

Once the global configuration is loaded, Direktor checks whether it was started in interactive or daemon mode. Once the execution mode is determined and acted on, Direktor scans the modules_registry to see which modules it needs to retrieve and build.

After it knows which targets to build, it loads the .direktor file for the given target in. Then it announces the start of the first target to the pre-defined E-Mail address and acts on the required options accordingly by setting up the additional environment needed for the compilation of the sources in this target, checking out or downloading the sources to the local disk and unpacking it if needs be to the source directory, configuring the sources, running the build command for the source target, and then installing it into a predefined prefix. Along the way, if any of the steps fail, an E-Mail announcement is sent out to notify the user building the code that the build has failed.

While this is all going on, Direktor will generate HTML pages to display the current status of the builds, including whether a build is running, the target's build completion status (success or failure), and when the build is done, what warnings were output during the compilation.

If the compile fails, the compilation log is displayed back to the last successful portion of the configuration, build, or installation.

CONTINUOUS BUILDS:
The most significant feature of Direktor is it's ability to run automatic and prescheduled builds with user specified actions. The two modes of this allow it to be used for continuous build assurance allowing projects to assure that all commits to a branch that is monitored to always build.

The first method, using the watcher system, requires that a post-commit action be set on your source control system to notify Direktor when a check-in has occurred which is delivered to a selected address configured for retrieval by a fetchmail-alike and then processed by procmail, or similar application. During the processing by procmail, the message is piped to our watcher script which then asks the scheduler to start a build as soon as the current server is idle and sends an email notification to a selected e-mail address that a commit to one of the modules has caused a new build to be queued. This very literally will on very active repositories cause the build to always be queued, so be sure that is truly the desired outcome.

The second method kicks off builds at predetermined clock times. The schedule is re-read every 15 minutes to add newly desired times that may have been added to the specified configuration file. Note that no two builds can run at the same time, so be sure that the schedule is long enough to accommodate the completion of all builds.

Sprint-A-Thon!

2009-10-02T19:00:00.000-07:00

What has two homes on either side of the planet, attracts geeks by the storm, and the letter Q?

No, not a rabid Qbert collector, rather Qt Dev Days!

This year, to start things out right we've managed to acquire through the clandestine (ok, maybe not so much....) work of the Nokia Qt Development Frameworks division (formerly known as Trolltech) F/OSS Community Manager, Knut Yrvin, a small stash of passes for KDE developers to the event. We thought what better way to draw in interested KDE developers than to hold a pre-Qt Dev Days Sprint?!

What will the sprint cover, you might ask? Well, we're interested in hearing (hopefully sooner than later) what YOU, the KDE hacker wants to work on/brainstorm on at this sprint! To better get an idea of whom will or will not be coming, please stop by our Facebook event page and RSVP. If you choose not to use FB to let us know, feel free to leave a blurb on my blog. Thanks :D

UPDATE: Hmmm, it would seem I for got to post the LINK to said FB event..... Here you go: Facebook Dev Days Sprint.

Update....

2009-08-21T23:58:00.000-07:00

Thanks to Brad Hards' quick intervention, I have a tarball of a recent SVN snapshot for OpenChange. I'll build the code and start working on reviewing the API tomorrow.

Stuck....

2009-08-21T23:25:00.000-07:00

This is a special request:

The last couple days, the OpenChange project's website has fallen off the 'Net. As one of the steps in getting my development environment up is installing libmapi++ (which no distribution seems to have packaged at all), I'm stuck. If anyone knows the folks maintaining the OpenChange project's website, please find out what is going on. Also, if anyone has a current check-out of the libmapi++ tree, please let me know so I can get it from you. Thanks.

You may now return to your regular blogging enjoyment.

Trudging Through Another Build....

2009-08-20T00:46:00.000-07:00

After spending an evening getting my development environment updated to trunk, I think I've come to a few conclusions: 1) I need to learn more about CMake, 2) learn how to deal with missing headers better (thank you ervin) 3. don't resort to sledgehammer methodology as quickly to fix a problem, 4) work on my my patience level more.

After committing the fix from being the guinea pig for the fix, I'm onto building kdepim, and then I'll start working on getting the code fixed for the openchange resource so it compiles.

Answering Questions.

2009-08-18T10:44:00.000-07:00

Just so those that are curious know, I'll repost my response to the over a dozen comments to my posting last night......

Just a small fyi for those that have been commenting:

Yes, my aim is for 100% parity with Outlook's capabilities with MAPI. This means that Mail, Contacts, Calendar, Notes, Journal, Public Folders, Tasks, and Projects are on my TODO list.

Whether this will use openchange for all of that functionality has yet to be decided based off of testig and feature completion.

Also, I think I should make it clear: the code I'll be working on was started in development around 2007 by Brad Hards and continued by Alan Alvares for his 2008 GSoC project. This WILL be an akonadi resource that talks Extended MAPI/RPC to the Exchange server and DBUS back to the Akonadi session daemon. Where necessary, I might call things in the various libraries from the Samba4 project to mimic an Active Directory backed Exchange client to make my work easier, we'll see if I have to do that or if I can rely on some things from LDAP..... Onwards and Upwards :)

With this, I need to stress that it won't be instant progress on this, so please all, be patient :)

Hello planetkde!

2009-08-17T20:59:00.001-07:00

This is my first posting on the planet (I hope... the aggregator doesn't seem to be showing my feed.... Here goes crossing fingers....)

Some people in the community may know me as the guy that likes Perl, Qt, KDE, and does a hell of a lot of IT administration at a very un-KDE job. I've helped out at a few F/OSS related events around the San Francisco Bay Area, including hosting lodging for three of the people that helped at the O'Reilly OSCON event earlier this month.

A large portion of the stuff you'll read about from my feed will be related to my (mis) adventures with getting KDE integrated with Exchange 2003 and later. I'll get into that a little more in the next post.

KDE, PIM, and MAPI

2009-08-17T20:36:00.000-07:00

Enough acronyms for you? I thought so.... For those that might not have heard, I'll be taking on the challenge of getting KDE PIM fully Exchange capable. This comes from my desire to kill Outlook and Entourage from my life and not force me to use a tool not integrated very well into my desktop of choice (Evolution).

So what is MAPI, you might ask? Well, MAPI stands for Messaging Application Programming Interface, which is the tier one option if you want a mail client to talk to Microsoft's Exchange server. This interface has gone through a number of changes over the years and thus far has been an elusive target for F/OSS projects. Lately a project called Openchange has been working on a library that much of my work on kdepim will be focused around integrating into KDE. This library covers all of the mess of having to write our own library to get access to these servers. As some know, this library is already used in a native MAPI method in Evolution that was released recently in the routine releases of GNOME. I'll just leverage that work and make KDE just as accessible to Enterprise users stuck in an MS powered shop.

I'll try to cover all the things I do to make this a reality, so stay tuned, Fun stuff ahead :)

APP-Get Progress

2009-08-02T03:18:00.000-07:00

I've gotten the code for the SourceManager mostly done, need a dumper function at this point and then I can utilise it in app-update. After that LWP code will be high on my list as I add the DownloadManager functions.

Code tally....

2009-05-13T00:38:00.000-07:00

While this normally falls under the "pissing match" category, I thought this would be fun to show how much code can be shaved off of a project that is written in pure Perl versus C++ and a Shell wrapper. The old genbasedir from Apt-RPM clocks in at 1650 lines of code, not counting the includes in the C++ source files. The NEW genbasedir.pl from APP-Get clocks in at 473 lines of code. A whopping 2/3 code reduction alone. Mind you, I could have cut corners, and trimmed the code down even further, however after looking over the code that genbasedir from Apt-RPM have between the shell script and the two C++ files, there are more than a few areas that look dodgy and lack proper error checking. Tomorrow, I'll move most of the functions from genbasedir.pl to a module to make it unit testable. Stay tuned to further developments :D

Reworking genbasedir....

2009-05-10T14:55:00.000-07:00

To make genbasedir easier to work on in the future (when we move to using some SQL engine for the data store for metadata), I reworked the functions to allow us to use an integer based pkgId instead of using the string name. This should speed up the dependency map functions in app-get considerably when doing package look ups since string comparisons aren't the fastest operations in the world in any language.

As an aside, I've gotten buy in from Jeff Johnson, the maintainer of the version of RPM at www.rpm5.org to add in some Debian inspired tags to make my work on app-get easier. :)

New APP in town :D

2009-05-07T22:46:00.000-07:00

Just an update, I'm working on a new dep solver for RPM and the eventual general successor OPM. The utility is called APP-get, a clone of apt-get that doesn't rely on private API in the underlying package manager to work and crufty code that Apt-RPM does. To get a feel of how APP-get will retrieve the metadata, I've been reimplementing genbasedir.

At this time, I've much of the new genbasedir written. It writes out a new plain text database format for binary and source package metadata called a lst.db. Each file is a single table of fields delimited by three pipe characters in a row. With this new set of lst.db files, a person can generate the metadata using standard UNIX tools if they so wish (though I don't know why you'd want to, since genbasedir does such a nice job of it :D).

While writing this, I've been studying the dependency map algorithms used by Apt and SmartPM. Armed with the knowledge of how they determine the dependencies, I should have a fairly easy time of writing the dependency manager in APP-get.

As I've been writing the code, I'm noting a lot of places that I'll be able to clear out Debian-isms from the design, which makes the codebase and design far simpler. At the same time, I'm seeing features I'd like integrated into RPM5 to make some aspects simpler, such as package priorities.

In Apt-RPM priorities are implemented as a kludgy list file (rpmpriorities) in /etc/apt/ that is checked for a string representing the name of a given package that uses a YAML-like format that defines packages according to named priorities which are more like the Essential tag in dpkg. I'd like to change this to be INSIDE the package's header to allow distributions to mark certain packages that don't normally have a require against another as Priority: Essential, or Priority: Normal. Also if this was merged into the header of the package, it would allow rpm to gain the ability to stop people from shooting themselves in the foot with rpm -e or app-get remove.

Well, enough chatter for now. Look forward to more progress on APP-get.

Updating to a new build root....

2009-03-31T23:58:00.000-07:00

Yes, this is necessary (sadly). GCC 4.1.2 and Binutils 2.17 is fairly old at this point, and isn't safe to build KDE 4 against from what I've found due to linking and visibility bugs. At this point, I'm documenting my work in a script to allow future build roots to be built far faster for the update and security trees that will be following.

Updates....

2008-09-24T23:50:00.001-07:00

The build root is coming along, and the AltimatOS Installer is also seeing much needed love. On other fronts, we finally have our registered PEN from the IANA to allow us to create the necessary schema for LDAP in AltimatOS.

Outside AltimatOS, I've been working a lot lately, which has slowed some things up, but never fear, I will get a release out eventually. :D

Back in the saddle....

2008-08-28T00:35:00.000-07:00

It's been a while since I've blogged... Since then, I've gotten a new job and started working on doing updates to the various packages in AltimatOS. Sadly, this means that I need to build a new build root since updating to glibc 2.8 almost killed my install. Let the builds begin!

Testing. 1, 2, 3....

2008-07-22T00:17:00.000-07:00

I've finally gotten the last of the package conflicts that APT can detect fixed. Tomorrow will be an installation test into a directory to see if AltimatOS' packages can actually be installed from scratch.

Linux programmer for hire...

2008-07-09T12:32:00.000-07:00

This is one of the few times I'll post a personal message up here...

As of 11:30AM PDT, I was let go at Google. This means I'm an unemployed Linux coder/systems administrator. If anyone knows of decent employment in the SF bay area, please let me know ASAP.

First post while booted into AltimatOS....

2008-05-24T00:02:00.000-07:00

PAAAAAIIIIIIIIINNNNNNNNNNNNNNNN!

There be bugs a-plenty. We really need bugzilla up like NOW.

I can haz workz GCC...

2008-05-11T15:39:00.000-07:00

For the last week, I have been fighting against the GNU Compiler Collection and MJPEG Tools. Seems that there are two major bugs in GCC 4.1.2 20070110, both related to C++ code.

One is a visibility support bug, where the compiler will erroneously mark visible symbols hidden, and the other is a templating bug where redefinitions will cause an Internal Compiler Error. While the first bug would likely have caused my KDE builds to be broken, the second was blocking building kipi-plugins, since mjpegtools is a dependancy on it and does some strange redefinitions to work around a bug in the GNU Debugger.

Happily, after updating GCC to the 20070305 revision (which techinically updated us to the unofficial 4.1.3 release of GCC) mjpegtools and others seem to build as they should.

Adventures in Packaging....

2008-04-16T23:21:00.000-07:00

RPM hasn't changed much externally to the user since 1996 when it was first released. Nor has it changed much for people wanting to package up software with it. Internally however, it has changed a great deal, especially with how it discovers dependencies.

As time has gone on, RPM has become more and more aggressive in discovering what dependencies a package has, including it's calls to GNU only features in the C library. This wouldn't be a problem if your C library was from before 2.5 if you had packages that had been build by both RPM 4.4.6 and 4.4.8, however this is not the case on AltimatOS; we use glibc 2.5.

Because of this, I get to wait on glibc to build again. This does not make me a happy panda....

Same old task...

2008-04-09T20:29:00.000-07:00

For a few months I've ignored the state of our packages for AltimatOS. Well, today that changes. We're not far from a public beta and we've yet to get KDE built, let alone fixing any broken dependencies in the repository, which would make it near impossible to release, let alone install.

As I'm currently the only person on the project, I've turned my attention from the installer to work on our packages. So, at this moment, I'm building KDE 3.5.9 with a wealth of patches to make the experience a little better for our users.

This will take a while to sort out the last of the packages before I can get back to working on AI unfortunately. Due to the state of the repository and AI, etc. I now implore the free software community: if you want to help; have ever wanted to work on a Linux distribution, please get in touch with me at greeneg aT altimatos DoT com to volunteer.

Looking good....

2008-04-02T23:08:00.000-07:00

I've almost all of the code done for the user interface of AI, and at this point can focus on one of the more important features for release of the installer: kickstart mode.

The back end of the installer is intended to write the kickstart file as it goes so we can just read in the actions requested and act on them in the later portions of the installer. This also allows users to clone systems easily and effectively by installing once on a canary and then copying the kickstart file to a pen drive and running the installer on the new box with the pen drive attached.

Stay tuned for updates on this, since this shouldn't take too long to add in. ;)

The AltimatOS Logo Contest

2008-03-30T03:17:00.000-07:00

OK, as people probably have noted from the logo in the upper corner of AI, the temp logo I threw together in 20 minutes is nothing more than Konqueror's Crystal Icon with AltimatOS in ElsiaInline, Thin font. This has been fine for a preliminary placeholder logo, but as I am getting closer to completing AI's user interface and finishing the packaging needed to get AltimatOS ready for it's preliminary beta, I feel it's not enough.

Because of this, I'm pleased to announce the AltimatOS Logo Contest! We're looking for a logo that emphasis the beauty and extensibility that makes up our OS. While some would throw Tux in there, please don't. We are not designing another Linux, but a coherent operating system; one designed for the average user, not the tech.

So you may ask, what's in it for me as the artist?

Well, the grand prize winner will walk away with both an ASUS Eee PC and every release of AltimatOS' planned commercial releases for free. This means that we'll send you one of the first discs mastered of the final releases at each release, without charge for shipping. The second and third place submissions will be given the first release edition of AltimatOS Desktop Edition on DVD for free.

And now for the rules:
1. All artwork submissions must be original artwork, without exception.
2. We require all submissions to be in digital formats (SVG, PNG, etc.)
3. Vector images are preferred.
4. If your work has been selected as the winner, it becomes the exclusive property of YggdrasilSoft, LLC. At that time, we require that all original sources for the artwork be sent to us and copyright and trademark rights be transferred to us. This also means that you may not in anyway keep copies of the artwork without prior consent of YggdrasilSoft, LLC.
5. If your artwork is not selected as the winning piece, we will destroy our copy to ensure that we do not violate your rights to the artwork.
6. During the contest you will grant us the right to place your artwork on display on our website(s) for open commentary.
7. The artwork should match the style of the Crystal Icon Set as designed by Everaldo for the KDE project.
8. This contest will run until July 4th, 2008. At the end of the contest, the core team for AltimatOS will judge the artwork based on the effectiveness of branding and beauty to select the new logo for our operating system.

There, done with the stuffy part! Happy vectoring! :D

Progress

2008-03-29T16:21:00.000-07:00

The simplicity of Qt and KDE never ceases to amaze me... With far less lines of code than if I'd been using something like WxWidgets or MSVC, I've a rich interface for an application. See the screenshots:

As can be easily seen, I've a fair amount done, and these aren't even recent screenshots. On the backend, we're likely going to be using INI and YAML for kickstart files. INI for the main portions and YAML for the partitioner though that is still under consideration.

Syntax bitches!

2008-03-28T01:31:00.000-07:00

Ok, I guess I need to read the docs on a class BEFORE just assuming that it'd work the way other Qt/KDE classes work.... Case and point KListViewSearchLineWidget (say that ten times fast, I dare you...)

Unlike most classes in KDE which take the parent as the first entry, it takes the KListView that the search will be tied to. This is, in my opinion, the epitome of inconsistent code design :( After spending two days getting that widget to display and run properly, I finally broke down and read the documentation.

Yeah, yeah... I should have read the fine manual earlier, but I had gotten lulled into a false sense of thinking that "this is KDE code, it'll be logical with how it handles constructing the object and it will be consistent". This learns me one....

Making my projects known

2008-03-13T20:54:00.000-07:00

Today I finally updated the www.kde-apps.org entry for Phinos (Phinos Installs the OS), which died a grueling death when I was so rudely shoved out of the PhoeNUX OS project. Now, it is reborn as AI, the AltimatOS Installer.

As before with Phinos, I aim to allow AI to be distro agnostic, with welcomed help from the community. The code is much cleaner now, whereas before it was a wreck being my second major project in PerlQt.

If you are interested in taking a look at the sources (as there hasn't been a finalized release yet) see http://svn.tabris.net/repos/ai/.

On the act of moving....

2008-03-13T18:54:00.000-07:00

Moving from one place to another might seem like such a nice thing to do, however at this point, I'm finding that I'm hating the "doing" aspect of it more and more...

Today I spent the day cleaning the old apartment just so I can get the entire 3500 USD deposit back from them. This is only _one_ of many aspects that I really loath in the process. The packing, unpacking, breaking stuff in the move, eating up my time.....

You'd think that after two cross continental moves, and 12+ moves while at college, I'd be used to it somehow. Guess I'm just getting tired of it.

w00t! Qt::Process FTW!

2008-03-11T19:45:00.000-07:00

I've worked on getting the backend to CuteDisk as used by AI, AltimatOS' Installer, to use Qt::Process for grabbing info from the OS for the disks, and Holy Mother of God is it fast! No more UI blocking, no more nashing of teeth trying diligently to get Proc::Simple to behave while interacting with RPM, just the snappy processing of commands :D

As you can clearly see, I'm geeked :)

Progress

2008-03-10T22:02:00.000-07:00

I've been working on AltimatOS' installer and website over the last few evenings and things are shaping up. :)

Since talking to ossi, I've managed to get QProcess to behave with PerlQt reasonably well. This has allowed me to finally setup a fair amount of the CuteDisk backend code, and keep the AI user interface free from blocking.

On the web front, we've actually gotten a decent amount done. This allows me to focus my attention on AI, PHADS, and Foreman Build Daemon so we can get things done for our goal of an early May installable beta of the OS for people to start banging on. See www.altimatos.com for more details.