Status as of May 13, 2012

Real life kicked in and side tracked me a couple days (along with having to reinstall my iMac to fix broken beta updates from Apple....) All that done, I got the VM instance of the build server running again, and have written a couple scripts to simplify some mundane tasks needed for builds.

As my boss hasn't cleared a maintenance to occur at work, I'll be able to spend a bit of time this weekend getting closer to the point of being able to have all of the "core" OS build dependencies finished before building RPM and then rebuilding everything again, but this time as packages. This will also help determine whether some of the tools are fully self-hosting.

I'll update with more info as I continue.

Status update for AltimatOS - April 29, 2012

Short and quick update:

Most of the circular dependencies for the new build root are done, only a couple remain before I can start rebuilding various low level libraries to add support for LDAP and Kerberos. Happily, GCC 4.7.0 seems far less broken than the 4.5.1 and before releases (read that as less patching to core libraries to make build....) Soon we'll start reviewing the init options, and such for "suitability".

Progress on AltimatOS

Some know I've been working off and on in my time on a new Linux distribution, and today I decided to start writing up the process to allow better feedback as I work on the software and packages involved, and better show what goes into building a new flavour of distribution. To start, I guess I should cover what my goals with this are:

1. Home and Business User-centric: This means that I'll be forgoing a number of UNIX-isms in favour of user needs and wants. While the power of the GNU project's tools, KDE, and other free/open source tools are the building blocks of AltimatOS, the intent is to allow the average accountant, secretary, high school student, or end-user to easily use their computer without getting in their way, or exposing them to archaic command-line prompts to do normal tasks.
2. Desktop oriented: AltimatOS is not, and never will be a server platform. While the underside of the operating system is based on similar software as other GNU/Linux distributions, AltimatOS' design and filesystem layout are not targeted at the duties of acting as a high performance server.
3. Not another "Linux": AltimatOS is not another GNU/Linux distribution in that the normal GNU/Linux distributions mostly adhere to filesystem layouts and design philosophies that run counter to good end-user desktop and corporate desktop operating system design. AltimatOS aims to avoid many of these design pitfalls that have kept "Linux on the Desktop" from becoming a reality.

With these focuses in mind, here are the immediate goals:

1. The entire operating system must hide away the command line as much as is possible - This means that by default (unless in debug mode) the system should not expose the command-line heritage of GNU/Linux to the end-user. (Turn off the virtual consoles, disallow switching from X11 to the other consoles, etc.)
2. No normal-case configuration settings should require the command line - Printing, file-sharing, hardware configuration, security configuration, and network settings must be done graphically and should not require jumping to the command line.
3. Job scheduling (cron and others) must be graphically configured - self explanatory.
4. Filesystem layout must be simple to navigate - While the FHS and LSB standards are intended on "standardizing" GNU/Linux, they've been largely designed by UNIX engineers, which drive them from being useful to the typical end user. To this end I'm taking a page out of Apple's play book; AltimatOS will radically restructure the filesystem hierarchy to simplify the user experience. While the traditional filesystem hierarchy will be preserved with symlinks for some level of compatibility, software explicitly designed for AltimatOS should not rely on these compatibility symlinks.
5. The compatibility symlinks will be hidden from end-user view. The method by which we do so will be through patches to KDE's KIO and Dolphin to honour our distribution specific named extended file attribute: user.visibility.
6. Authentication must be done through the local LDAP and Kerberos services running on the system. The flat file method of authentication inspired from UNIX, while simple is dated and inflexible to extend.
7. In a central authentication environment, we must support LDAP+Kerberos - Simplifying enterprise integration with standard OpenLDAP and MIT Kerberos on a GNU/Linux server.
8. System configuration is tightly coupled to the Puppet configuration engine - Software packages and configuration tools must work through the custom Puppet registration on the local system, or a centrally manage puppet-master.

Today, we've our cross tools tree built, and are currently working on building the initial run-time. This will allow us to completely deviate from the SuSE installation that is acting as the cross build host inside the VM that is running the builds.

The rationale for using VMware for this is simple, While working on this, I can still have a usable system to use for my day to day until AltimatOS is to a reasonable state to use as my main desktop.

As the weeks roll on, I'll chronicle the work being done and at times may ask questions of my readers to see if you've ideas to make this even better. Thanks for joining me on this ride, comments always welcome.

Code tally....

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....

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

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....

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....

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....

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....

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.

I can haz workz GCC...

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.

The AltimatOS Logo Contest

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

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.

Making my projects known

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/.

w00t! Qt::Process FTW!

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

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.