Ubuntu Names Their Desktop After Us?

I was quite surprised this morning whilst reading my RSS feeds to discover that Ubuntu has named their most recent ‘lite desktop‘ Unity.  Surprised because we have our project, Unity Linux.  Strange that both our ‘lightweight distribution and desktop’ and Ubuntu’s ‘lite desktop’ should share a name together.

While I’m not really sure why no one threw up a stop to this in the Canonical brainstorming session that produced ‘Ubuntu Unity’ one can only have a laugh about this and hope we don’t get our pants sued off even though we named our distro first.

If things do get hairy, I’m sure we can change our name to ‘Unity Ubuntu’ or something similar to properly confuse everyone.

So, on behalf of all the Unity Linux developers, I’d like to thank the Academy and give a special shout out to Ubuntu for making our name known!  Thanks Mark!  Oh and good luck with that Unity thing! :P

* devnet removes tongue from cheek

Unity 2010 Beta 2 Impressions

As noted previously, I’ve been pretty hard pressed lately in my secular job due to migrations and other fun activities happening throughout the past few months.  I did however, get the chance to download Unity 2010 Beta 2 and give it a go.  I had some problems when booting because I was brought to a blank black screen with a mouse pointer no matter what options I passed during boot.  To get by this, I had to follow some IRC advice on #unitylinux  (thanks wile_netbook!) and change to a second tty, kill the Xserver and GDM, followed by executing do-vesa.  It’s hard to try to do it quickly though because GDM will try and restart X and switch init levels on you back to a graphical one.  To get by this, you’ll need to do the following:

Drop into a different tty.  Login as root…if you’re on the liveCD, the password is root.  Execute:

ps aux | more

Make note of the PID for X and GDM.  Write them down…replace the terms below with your PID numbers:

kill -9 PID_for_X && kill -9 PID_for_GDM && do-vesa

You now should see something other than black screen with mouse cursor.  I’m not sure how many systems this affects…but I know my Dell Latitude D630 laptop took it on the chin for this one.  Not a huge problem for a Beta…I mean, a distro can’t be all things to everyone.

Overall though, Unity 2010 Beta 2 is much more solid than Beta 1 was for me after getting by the initial X problem.  Everything works as it should as far as sound, Internet, and wireless are concerned.  I quickly removed PCmanFM and replaced it with Thunar, my file manager of choice.  I removed LXPanel and installed Tint2.  Installed Nitrogen to manage wallpaper.  Installed Parcellite to give me a clipboard,  Installed volwheel to give me a volume applet to control volume.  Installed Pragha to give myself a great music player.  Installed Irssi to allow me to get my IRC fix and put pidgin in play to IM.  I had a usable, customized desktop within about an hour.  And it’s been really solid…just as solid as my Arch Openbox desktop I run at home…which makes me feel good about this Beta.

So what else have I been working on?  I’ve been working on a large (VERY large)  tutorial on file permissions and making use of groups for file/directory access to add to the tutorials section of YALB.  This thing has been in work since last year and I’m attempting to finish it up before the months end to give a good representation of what file permissions in Linux are for and how they work with users and groups.  I’m also going to write up a tutorial on how to customize Unity 2010 Beta 2 into a lightweight Openbox desktop.  So, some good updates hovering on the horizon.  Stay tuned :D

Clarification on Foresight and Fedora

I previously wrote about a possible “rebasing” of Foresight Linux on the Fedora platform. This conjecture was a bit premature it seems as I am completely wrong on this being a possibility :) The best part about me being absolutely wrong on this is that there is still going to be benefits for Foresight and Fedora even without the rebase.

Foresight is toying with the idea of having a sub-project (completely separate from Foresight Linux base) that it has tentatively called ‘boots, a Fedora remix‘ (a play on Dora in Fedora for those of you with kids).

What would happen is that mirrorball, a tool from rPath that ‘sucks in’ repositories, would pull in a Fedora repository into a separate Foresight repository.  From there, it is fully consumable by any product/project that is hosted on rBuilder Online from rPathConary really is one of the most innovative package managers on the planet and I’ve mentioned it once or twice before (never got around to part II on one of those though).  The ability to fully suck in a RPM repository is already being done with CentOS and Scientific Linux on rBuilder Online…even Ubuntu is currently being done as well…so we have proof that it is totally possible.  Once imported, Conary takes over the management of said packages.

So what does this give Foresight?  A few things:

  1. Testing of packages in 2 communities
  2. Developer eyes/chatter in 2 communities
  3. The ability of Foresight to cherry pick packages from a large base
  4. Compare and contrast for packages from 2 different sources to track down bugs

So, as I said, I was wrong initially and I hope this clears up what Foresight plans to do.  A sub-project will be started that imports the Fedora repository changing them from (rpm to Conary) allowing Foresight to both test and cherry pick packages from a larger base hopefully freeing up a bit more time for Foresight architects.  Phew!  What a mouthful, run-on-sentence that was!

Why Conary?  How does this help Fedora?

I know some of you may be asking Why Conary?  What does it have over RPM that Foresight should suck in a repositoroy and change it to Conary packages?  The reason this is an absolute necessity is because the tools on which Foresight are built (rBuilder Online) works with Conary only…that means ISO generation and repository hosting are all mandated to be Conary based.

The other interesting part about this is that Conary blends version control with package management.  It deals with changesets as packages.  Imagine SVN…you have a local changeset that  you’re working on and the version inside the SVN repository differs from that.  You can then diff the state of your local copy to see how it differs from the remote copy.  This allows you to see the changes you’ve made and allows you to see what code may be broken.  Also, commits are numbered automagically so that you don’t have to worry about breaking things much because you can rollback to a previous known good state.

The same is true with Conary…you can rollback to previous known good states.  You can also diff each changeset locally with the remote repository.  Now imagine this with Fedora packages…if something is broken, chances are Foresight will find a fix for it much more quickly than someone in Fedora…a single command can diff the previously known good version with the broken version and find out the shortcoming.  Or perhaps a known good verion in Foresight that isn’t Fedora based might be used to diff the Fedora RPM version and find out the differences in them.  In all, it’s going to help developers track down problems faster.  This helps Fedora…they now have a small number of Foresight developers who will be working with hundreds of popular Fedora RPMs looking to see if they work or are broken.

Most of the benefit will be measurable in Foresight because they’ll be able to use just about any package Fedora creates…but the Foresight community is FULL of very capable developers…guys that really know what they’re doing.  If they can make this a collaborative effort Fedora will gain exceptionally smart developers as well…even if testing packages on a different platform, they’ll have eyeballs on these packages and if a fix is found or made for them they will definitely go upstream to Fedora.

Hopefully, this puts things right from my initial wrong.  I don’t claim to be an insider for Foresight…I just know a lot of the people involved and ask questions a lot….I also pay attention to the developer mailing list.  If you have any questions, please leave a comment and I’ll attempt to track down answers for them :D

Slackware and Zenwalk



I’ve been distro shopping lately.  I had become complacent while working with PCLinuxOS because everything just works when using it.  With nothing broken, I had nothing to fix :(  This is a good thing, unless you want things to break every once in a while so you can learn to fix them.  I know, I’m a glutton for punishment.

After some initial toolings in Arch and Gentoo, I settled on Slackware…which was my first distribution I tried ever in 1995.  It felt good to be coming back to Slackware…there is a simple elegance about it.  It’s ultimately fast on just about every system I’ve put it on.  I really like the unix like rc files Slackware has; to me, it’s simple to get things working.  This could be because I cut my teeth on Solaris…but then again, I think it’s much easier to manage system services by making an rc file executable (chmod).  Sure Red Hat style is ok with ‘service name start|restart|stop’ but I really like going into a directory, listing it out, and seeing all my services that execute on startup in green.  Maybe it’s my nostalgia getting the best of me.  I’m sure that’s it.

Regardless, I stuck with Slackware only a short while because I was interested in XFCE (not that Slack doesn’t have XFCE…just that I wanted to see a distro that prides itself on XFCE) and decided to give Zenwalk 6 a try (I’ve tried Wolvix already…it just didn’t click with me).  I’d heard nothing but good things about this distro and it is Slackware based, which makes all the nostalgic parts of me tingle.

I installed and all I can say is WOW!  It’s a fantastic implementation of XFCE regardless of distribution.  The Slackware speed and rc system are there, greeting me on each startup/login.  XFCE is done brilliantly there and really feels like a superb implementation.  Updating is a snap with netpkg, something I haven’t had any experience with…it does the job nicely though.  Overall, I’m quite satisfied with Zenwalk and will be sticking with it for a while.  I’ll post back from time to time with any tips or tricks I might find as I’m stretching my legs so to speak in my new environment.

Zenwalk 6, slightly altered

Project Unity Updates

Just a few updates on the new project named Unity…

What is Unity you ask?  Unity Linux strives to be a solid core for the mklivecd project. We hope that numerous distributions of Linux that want to make use of functions such as mklivecd and remasterme will base their distributions on our small core. Our methodology is to keep it simple, keep it open, keep it free, and keep it updated!

Some distributions you may see based on Unity Linux: Granular Linux, Producer Edition Linux, TinyMe Linux, TinyFlux Linux, Unity e17 (formerly PCe17OS), and many others.  One of the others I speak of here that might base on Unity is SAM Linux.  For those of you that don’t know, SAM has been doing its own thing for a while now and the ability to have a small core without lots of dependencies with the ability to remaster and mklivecd is appealing to many distributions and remasters out there.  Hopefully, our core will do well for everyone involved.  Thus far, SAM is keeping it’s eyes open and looking at Unity to see where it goes.

So, lots of development is happening right at this moment…and we still have lots to go.  Our developer ranks have swollen to around 29 members now…so we’ve got a GREAT group of people all working toward the common goal.  Right now, our developers want to get a core iso out the door so that everyone can have a common desktop to work on (for our docs guys, for our rpm rollers, for our kernel hackers) to make sure we’re all on the same page.

We’re also beginning to form teams…or at least talk about teams :)  I think soon we’ll see dedicated team leads come out of the development ranks to step up and develop in their individual area.  If you have questions or concerns or comments about Unity Linux, please drop me a line below!

Sign Up for Unity Linux RSS – Get notified when we release!

Sign Up via Email for Unity Linux Releases 

New Project: Unity

I’ve been working on a new project the last few days.  We’re calling it Unity.  What it will be is a new Linux distribution that takes an incremental approach to desktop Linux.  It will provide a central core and use the mklivecd scripts that PCLinuxOS uses and it will provide a base from which to build just about any desktop you want out there.

Hopefully, this building block approach will work for us.  Currently, we’re operating behind closed doors.  Soon though, we’ll have some kind of public face to this thing.  When we do, I’ll post follow-up information.

Those of you that follow me on the web know that I recently gave up control of MyPCLinuxOS, the community projects site for PCLinuxOS.  I cited personal reasons for giving this control up.  One of those personal reasons was to become involved with this new endeavor.  I hope to help make this into something great!