You may have seen a blip swing by in posting on the site with the default WordPress posting “Hello World” displaying as a new post.  This was due to my recent migration from Site5 shared hosting to a Linode VPS.  During the switchover, the database had not been uploaded yet as I was tweaking the webserver…feedburner detected a change in the RSS when DNS switched and BOOM!  The WordPress default post popped up saying hello.  I thought I had everything planned and timed perfectly but it seems I was off because of how fast DNS switched.

I apologize if this littered your inbox or your RSS reader.  I can promise some GREAT posts coming up.  I’ve been working on a file permissions and user groups posting to help new users out.  I’ve also inherited an older laptop with a PIII that I’ll be installing Salix on soon…I’ve decided to go with LXDE version of Salix 13.  Should be quite fun to see how that performs and report about it.  I’m also investigating Linux command line downloaders that can grab files from the web for you.  So lots of stuff on the horizon.  Once again, apologies for anything odd that may have popped up.

If you’d like to know more about the migration or have Site5 shared or Linode VPS questions, please drop me a line in the comments section.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

A Blip on My Posts originally appeared on Yet Another Linux Blog on July 8, 2010.

What is Openbox?

From the Openbox homepage, “Openbox is a minimalistic, highly configurable, next generation window manager with extensive standards support.”  From using it, I often think of it as fluxbox-like with the benefits of being able to dip into Gnome or KDE for the items that I want to use.  Your desktop will then run with speed and simplicity using only the elements you want to use with it.

So…Let’s get Started…

This How-To will assume that you’re running Foresight Linux, you’re logged into Gnome and that you’re familiar with conary, the package manager for Foresight.  First and foremost, install openbox:

[devnet@lostlap Desktop]$ sudo conary update openbox obmenu obconf

This installs the needed components to run Openbox on your system. Openbox is minimal by default though so if you login to the environment now for the first time, there will be no taskbars, nothing…just a large blank area for you to work with. We will need to install some extra components to give a bit more functionality. If you’d like a panel menu, I recommend using tint2. I used to use pypanel which is a small panel written in python but this panel is no longer developed.

There are other panels that are packaged with openbox in mind for Foresight; fbpanel is available, which is a very fast and functional menu bar. I like lxpanel also, which is fbpanel with some easier configuration options. For a full list, please see openbox documentation. For our purposes here, we will install tint2:

[devnet@lostlap Desktop]$ sudo conary update tint2

Now we need to copy the default configuration file for tint2 so we can build our panel to our liking.  You’ll have to create the default path for the tint2rc configuration file.  To do this and copy the config file:

[devnet@lostlap Desktop]$ mkdir -p ~/.config/tint2/
[devnet@lostlap Desktop]$ cp /etc/xdg/tint2/tint2rc ~/.config/tint2/

Now tint2 has a configuration file in place and is ready for Openbox to start.

Let the Configuration Begin!

The hard part (install) is now out of the way thanks to the conary package manager. Now we need to configure Openbox so that it’s ready for us when we log out of Gnome. The configuration files will need to be copied to /home/user/.config/openbox.  Of course, this path doesn’t exist yet so we’ll need to create it like this:

[devnet@lostlap Desktop]$ mkdir -p ~/.config/openbox/

Visiting there now will show that there aren’t any files in this directory.  The file we’ll absolutely need to place there is autostart.sh. Other files that will be in here are rc.xml which is for obconf (openbox configuration) and menu.xml (openbox menu system).  We’ll copy menu.xml from a default copy there later.  The other file should auto-create when loading for the first time (rc.xml)

The autostart.sh file is what starts all of our services and our tint2 panel we just installed as well as setup our wallpaper and other items.  Instead of going through the options you can place in here, I’m going to share my autostart.sh to get you up and running quickly.  Please note that if you chose not to install fbpanel and use the gnome-panel or other panel instead, you’ll need to comment the pypanel line below and uncomment what you’ll be using:

[devnet@lostlap Desktop]$  cat autostart.sh
# This shell script is run before Openbox launches.
# Environment variables set here are passed to the Openbox session.
##############################################################
# Panel Section
##############################################################
# pypanel, my favorite panel for openbox
#(sleep 3 && pypanel) &
# Use the wbar Launcher if you would like.  Don't forget to install it before uncommenting
# wbar &
(sleep 3 && tint2) &

#############################################################
# Gnome Integration Section
#############################################################
# This section let's Gnome give us some of its desktopiness
gnome-power-manager &
nm-applet --sm-disable &
/usr/libexec/gnome-settings-daemon &
gnome-volume-manager --sm-disable &
gnome-keyring-daemon &

###########################################################
# Other Add-on's for Openbox
###########################################################
# Make your wallpaper restore to last setting using Nitrogen.
nitrogen --restore &
parcellite &
volumeicon &
################################# End ###################

Download my autostart.sh

To create the menu system file for openbox, we’ll copy from the default installation to our .config/openbox directory (so we can use obmenu…otherwise, that command will give us an error) so use the following command in a terminal:

[devnet@lostlap Desktop]$ cp /etc/xdg/openbox/menu.xml ~/.config/openbox/

Now you’re ready to login and reap what you have sown Logout of Gnome and change sessions in GDM to Openbox.  Notice that your tint2 panel starts up and has the gnome applications we recorded in the autostart.sh file above running and docked! You can add more options to your autostart.sh file and you can also edit tint2rc (in your /home/user/.config/tint2 directory) to store settings for your panel.

I’ve Installed and am Running, Now What?

Now you get to customize the Openbox menu with your favorite applications. Menus are activated by right clicking anywhere on the desktop. There are a few default applications…I choose obconf right away so that I can choose a theme I like and increase the text size since I’m using a high resolution. After that is done, I right click for the menu again and go to applications >> xterm. When the terminal pops up, I type obmenu. From there, I’ll be able to edit my right click menu.

Now instead of entering obmenu in a terminal each time, let’s add it to our right click options. In the obmenu window that you opened in the last paragraph, expand the Openbox 3 option. Find obconf and highlight it. Click ‘new item’ and add obmenu for a label, execute for action, and obmenu for Execute. This will add obmenu to your right click options so you don’t have to open a terminal each time to do things. You can also customize any of the items you find in applications…I put a few things I normally need such as thunderbird, firefox, gnome-terminal, etc. Feel free to add whatever you need…you can have many submenu’s . It’s setup is pretty straightforward.

Nitrogen, the wallpaper manager, requires a small tweak as well to get working. What I did was create a /home/username/Photos/Wallpaper directory and then loaded it up with my favorite desktop wallpaper. Good places to go for cool wallpapers are desktopography.com and vladstudio.com.  Next, install Nitrogen:

[devnet@lostlap Desktop]$ sudo conary update Nitrogen

After your first login, you’ll need to add a menu entry using obmenu to call the nitrogen browser. So create the menu entry and the action you call is:

nitrogen /home/username/Photos/wallpaper

Of course, replace ‘username’ with your users name.  This will allow you to open up all the wallpaper photos inside of that directory.

So What Have we Done?

Today, we’ve installed Openbox on Foresight Linux. We’ve given it a tint2 panel so we have a place to dock applications and we’ve customized the Openbox right click menu and added a wallpaper program called Nitrogen. Hopefully, this shows you the customizable features of Openbox and also shows you the speed that Openbox operates at. It’s a very minimalistic environment, yet one that can be very powerful.

Installation Notes of Interest

tint2

Tint2 is my newly crowned favorite panel for openbox.  It’s lightweight and is able to be configured in so many ways.  I added the sleep command inside my autostart.sh to make sure that the desktop is loaded before the tint2 panel tries to load…mostly, this is due to network manager wanting to animate while the panel loads.  This isn’t as much problem with tint2 as it is with pypanel (see below).

pypanel

Some things I’ve noticed when running openbox…network manager has problems with pypanel. I added the sleep command inside my autostart.sh and this is much better now…but there may be similar problems with network manager. It’s really NM searching for a network and it causes the panel to flicker a bit. Not a real show stopper.

Gnome-panel

Gnome-panel running inside openbox causes a few errors to pop up when I login. This could be due to the fact that I’ve started things in my autostart.sh out of order…I’m also not all together sure what is causing these errors. The problem seems to be with the docking area of gnome-panel as when I minimize programs they are not docked. Easily fixable, but annoying nonetheless.

Alternative Panels

There are quite a few alternative panels out there.  Fbpanel is one.  Perlpanel is another.  Fbpanel and lxpanel are available in the Foresight repositories. You can also add other launchers like wbar if you so desire.

Screenshot

Openbox on Foresight

Related posts:

1. Adding Color to Bash List Command Part II I previously blogged about how to add color to the...
2. Unity 2010 Beta 2 Impressions As noted previously, I’ve been pretty hard pressed lately in...
3. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...

Related posts brought to you by Yet Another Related Posts Plugin.

Installing Openbox on Foresight Linux originally appeared on Yet Another Linux Blog on May 30, 2010.

Just look at this medium over the past few decades and you’ll always find a TV series or movie that is a glass reflection of what is happening in the real world.  Movies and TV have the power to elicit strong emotional responses (i.e. The Notebook_or_insert_another_chick_flick_here) , invoke the ire of opposing groups (i.e. Expelled: No Intelligence Allowed), and even inspire people to unite under a common goal.  Anything that powerful and influencing with the reach that moves and TV have is a force to be reckoned with.

Stagnant Development and Stagnant Thinking

When development on something stagnates and no further advancement happens, often times that technology is abandoned.  An example of this is how voice-over-IP is changing how we do phones.  With Skype, Vonage, Google Voice, asterisk, and other amazing services the consumer is innovating while phone companies flounder.  Soon in the future we will see phone companies change to become absorbed by ISPs.  The same is true of Television companies.  With the onslaught of new media on the web and the ability to stream video from point A to point B, conventional media producers are being forced to become innovative to stay relevant.  The problem is that they don’t want to innovate.  They’d rather sit back and let the old way they operate things be the ONLY way they operate things.  A prime example is NBC’s fall from grace; from first to worst with no sign of improvement.  Time and time again they prove that they don’t “get it” at all…even up to NBC CEO Jeff Zucker saying that Boxee is stealing content from Hulu when they play videos…using this logic:  Opera, Safari, Firefox, and any web browser is “stealing” content by visiting Hulu.com and playing videos…because Boxee uses Mozilla Firefox to play Hulu’s content.

When big television finally gets this…they’ll get on board and they’ll be seen less negatively and more positively.  The first Television company to  fully partner with Boxee to offer full episodes will win.  What does winning mean?  It means that the PR exposure will be such a huge shot in the arm that the company will benefit across the board.  It also means that they get rich metrics on what people are watching, how often they watch, and when they are watching…all without even needing a Nielson ratings.  The first company to do this, in my opinion, will be the company all other broadcast corporations will chase.

How Boxee Harnesses the Power of Movies and TV

Boxee tames that reality shaping force for you.  Boxee changes the way you are entertained.  By changing how something is used or consumed, you change all those the thing reaches.  Instead of TV being brought into your home…YOU are bringing TV into your home on your terms.  Studios need to know that to gain control over something you sometimes have to give up control.

Boxee crawls the web for you and brings all television it can find (think CBS, ABC, NBC, Hulu, Netflix, clicker.com, tv.com) into a single interface.  You play your show in Boxee and can even rate it and/or share it.  People can subscribe to your boxee feed and know what you rated a movie or television show and perhaps watch it themselves.  However, the real power of boxee is the single interface.  This gives people the ability to launch a single program that can find TV for them.  The entry barrier to watching TV online is thus lowered.  That means that Boxee is a POWERFUL tool for television and movies…one not being utilized by those markets.

Boxee is taking a cross platform approach to things as well…it’s freely available for Linux, Windows, and Mac platforms.  This allows Boxee to be something EVERYONE can experience.

Boxee IS changing the entire world, one television at a time.  If broadcasting corporations don’t recognize this and work with Boxee…I’m afraid they may be left out in the cold during this change.  What do you think?  Does Boxee have the power to change the world?

If you’d like to know more about getting started using Boxee, please visit

http://www.howcast.com/videos/310743-How-To-Get-Started-With-Boxee

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Boxee is Changing the World originally appeared on Yet Another Linux Blog on May 25, 2010.

Slackware for those of you that don’t know, has no dependency resolving package manager. Previously, a good attempt was made with swaret and that was my first jump into package managers with dependency resolution all together when it came out…but Swaret is no longer being maintained and doesn’t really work well anymore.

Since Slackware has no real dep resolving package manager…it’s one of the last ‘true’ Unix like Linux versions out there. Back in the early to mid nineties…things were exactly like this. If you wanted to update your Linux version…you stepped through it manually and tried to get things to work. What was great about Slackware was making your own Slack packages with source…no dependency resolution but in the process of making the package you’d have all the dependencies eventually installed. In this entire process, you became VERY familiar with your system…how it booted, what run level things occurred at, how cron jobs worked, etc. You were baptized by fire so to speak…you were to sink or swim.

As I said, this got me thinking…do we rely on dependency resolving package managers TOO much? They’re cliché now of course…run of the mill. Back in the 1990′s though rpm was the only true package management system around…and rpm was never designed for internet consumption. The guys who wrote rpm had in mind CD and floppy upgrades. Fast forward to now and we have zypper, pacman, urpmi, deb, and conary…all built with online repositories in mind. Do these managers take the heavy lifting away for new users? Do they spoil them?

Do systems break less with easier resolutions due to package managers? Does it mean that the new user of today won’t be as experienced as the old user of yesterday?

I think it might.

Users in the past had to chip away and reassemble with less documentation and no package manager. This meant that the user of yesterday ripped apart systems and packages to discover how they worked and which cogs fit where.

The user of today follows step by step instructions and the software is given a sane set of defaults by most package developers when said package is installed.

Does this make for lazy users?

I don’t think users are lazy per se…but as previously stated, spoiled ones. And it’s no fault of their own…it’s the direction the software has taken us. Now the questions we need to answer are:

1. Is this direction the correct direction we should be heading?
2. Are there better approaches to package management that don’t follow the model we have currently (other than Conary)
3. Can we come up with a system that doesn’t make new users spoiled?

I think I’m of both worlds…I started off with no package manager but managed to ride the wave of Red Hat 7.2 and above followed by Mand{rake,riva} and PCLinuxOS. I’m both spoiled and unspoiled. I know what it takes to manage a system without a conventional package manager but I also know how much time it can save me to use one. I sometimes find myself wanting less though…less and more. Less time and more hands on gutting the system. I think I’m in the minority though.

How about you, as a reader of this article? Do you think new users are spoiled by conventional package management systems? Do you see solutions or have ideas we can discuss? Is this really just a process we can improve or is there any programming to be done? Please sound off in the comments section!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Do Package Managers Spoil Us? originally appeared on Yet Another Linux Blog on May 16, 2010.

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!

* devnet removes tongue from cheek

Related posts:

1. Unity Linux Automates Build Process The guys over at Unity Linux have created and developed...
2. Unity Linux Theme Refreshes I’ve been pretty busy lately with theme design for the...
3. Unity 2010 Beta 2 Impressions As noted previously, I’ve been pretty hard pressed lately in...

Related posts brought to you by Yet Another Related Posts Plugin.

Ubuntu Names Their Desktop After Us? originally appeared on Yet Another Linux Blog on May 10, 2010.

I knew from experience in the mid-nineties that Slackware was probably the most Unix-like distribution out there…I felt at home there quite a bit after learning the *nix ropes on Solaris 2.0.  So we configured a Slackware 8.1 dual processor tower server he was lucky enough to acquire as our home firewall-all-around-great-linux box.  He took his beginning steps there and flourished since our Air Force job already had us jumping around in a VAX/VMS mainframe.  We had many late night hacking sessions attempting to get things to work or compile there.  We also had a multi GB shared hard disk (unheard of at the time!) shared over samba.

After I got moved out, I continued to keep the Slackware box up to date.  I moved onward to Slackware 9.  Samba operated like a champ and Slackware was a great routing system and dhcp server.  Then I discovered ClarkConnect and loved the web interface.  I could do things in half the time!  I could do them over the web from work without SSH tunneling!  All this appealed to me at the time.

I continued to run ClarkConnect from that point on and have continued to all the way up to when it changed to ClearOS this past year.  Indeed, I have ClearOS now as my central server.

The only problem is that I’ve suffered 2 of the most catastrophic losses of files in my samba shares when running ClarkConnect/ClearOS…and I didn’t draw the lines together  on these separate incidents until just recently.

The first loss came when an entire samba share was completely eradicated…13GB of music was just gone.  The second loss happened just the other day when tons of scanned pictures just VANISHED into thin air.  Each time these happened, I was using ClarkConnect/ClearOS.  Each time it happened a few users reported instability in the forums of those distributions.  I am not sure how it could have happened and I was caught completely off guard on the second time…my backups were not yet configured since it was a new server.  The first time it happened…I didn’t know the value of having a good backup routine.  So each time, no backups   Lesson learned the hard way but learned nonetheless.

I recall running Slackware on my server and NEVER having the problems I have had with ClarkConnect/ClearOS.  This got me rethinking my home server design.  Servers should be the epitome of stability.  One should be able to migrate from one version of the operating system to the next with few hiccups.  When considering each of these it is very apparent that I should be running Slackware core on my main samba server.

I will be making that transition in the next week or two and moving to a Slackware core based server.  I’m not sure what to use for backups across the network (I usually mirror the drive to an NTFS drive in my Windows based multimedia server) nor backups locally to other hard drives.  If you have any suggestions, I’d really like to hear them.  Also, I’d like to know what readers consider using for a server.  Please vote for your favorite below and drop me a comment letting me know specifics and thanks for your help!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Rethinking Home Servers originally appeared on Yet Another Linux Blog on April 17, 2010.

You can use the tar command to make this a snap.

Tar combines multiple files into an archive and you can use it to preserve permissions and file structure and then you can compress the archive to save space.

tar -c --recursion -p --file=backup.tar directory

The -c flag creates an archive for us.  –recursion goes through all subdirectories.  The -p flag preserves permissions on all the files.  This is handy if you have certain folders or files that you need to sticky with individual users or groups.  The –file flag is the option for outputting to a file name.  You can also add multiple directories that you’re zipping up like the following:

tar -c --recursion -p --file=backup.tar directory1 directory2 directory3

After you have the file output as backup.tar it’s time to compress it.  The most standard way to do this is to use the gzip command:

gzip backup.tar

This command will output backup.tar.gz to the current directory which will take up less space than that of a standard 1-to-1 copy.  There are many other flags and options that you can use with the tar command.  For an in depth look at those flags and options, check the tar man page by typing ‘man tar’ in a terminal or view it online here.

UPDATE:

Commenter ‘jack’ has offered a few extra flags to combine the archiving and zipping into one command:

tar -c -z --recursion -p --file=backup.tar directory1 directory2 directory3

The -z flag will gzip the archive after you’ve used tar to create it.  Substituting -j in for -z above will bzip the archive.  Thanks for the tips jack!

Related posts:

1. Convert PNG to GIF via Command Line I installed a bare bones Arch Linux system today and...
2. Installing Openbox on Foresight Linux My friend Og Maciel originally introduced me to Openbox a...
3. Adding Color to Bash List Command Part II I previously blogged about how to add color to the...

Related posts brought to you by Yet Another Related Posts Plugin.

Backup Directories and Subdirectories Preserving File Structure originally appeared on Yet Another Linux Blog on April 14, 2010.

Very interesting stuff…much like what rMake does for Conary and Foresight Linux…but applied to RPM’s instead of conary changesets.  Just the same, it’s interesting that such a small team of developers are showing their prowess in development and making strides toward building a robust developer community.

Related posts:

1. What Is Unity Linux? There’s been a lot of confusion about exactly what Unity...
2. Foresight, rPath, LiveCD, and Unity Linux Most, if not all, top distributions of Linux ship a...
3. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...

Related posts brought to you by Yet Another Related Posts Plugin.

Unity Linux Automates Build Process originally appeared on Yet Another Linux Blog on April 12, 2010.

I thought I’d talk today a bit about that.   I’d like to talk a bit about what Unity uses for it’s ‘guts’.  I’d also like to dispel some myths surrounding Unity.  Lastly, I’d like to talk briefly about how Unity is doing all it can to further Open Source and Linux by contributing to projects it is involved with.  The reason I know so much about this topic is that I’m the webmaster and host for the Unity Linux Project as well as one of the documentation team members.  So, let’s take a look first at what Unity Linux is…

What is Unity Linux

Unity Linux is not a conventional distribution of Linux.  It’s a core on which developers can build their own distribution of Linux.  We’ve set out from the start to provide an excellent minimum graphical environment that gave developers “just enough graphics” for them to create something.  The smaller, the better.  We elected to go with Openbox because of it’s size and stability.  We selected using Mandriva as our base because of the number of packages they provide and the quality of those packages.  We pushed lxpanel as a minimal panel because it provides just enough functionality for distro developers to see what they’ve installed after they’ve installed it…it also is familiar to most people whereas Openbox right click menu’s may not be.  All in all, our target for the core release is developers.  We’re not designing this basic desktop to be used by end users.  We’re not trying to win any awards with our awesome minimalistic desktop skills.  Why would we do this?  To answer this, you have to take a look at our developers.

One of our developers, Kdulcimer, is the lead developer of TinyMe Linux.  A few years ago, he created a fantastic minimalistic “remaster” of PCLinuxOS.  It was wildly popular and continues to be so today.  Kdulcimer was one of the first developers that elected to go with Unity Linux for his core.  Our other developers saw what Kdulcimer did with his distro and how small he made the core.  They learned from how he did things and applied it to Unity.  Thus, Unity has a small base…as evident by both the beta releases.  Upcoming release candidates will be very much the same.

Lead developer gettinther does a good job explaining what Unity is:

One of the big issues facing small distros around is that there’s a limitation in the ability of each group to maintain a healthy up-to-date core.  Most people prefer to focus on the DE / user interface, working on the look&feel rather the the internals.  Those distros end up with stale core which in turn causes numerous “hard-to-find” issues.

Most of the distros with us existed before Unity, like Tinyme, Sam (abandoned project now), Granular, Synergy (formely eeepclos).  The idea is to create distros only insofar as “presetting desktops by people who love those desktops”.  Rather than having a “one shoe fits all”, we decided to provide a core module and look after maintaining it.  Each branch distribution joins the team and has full developer access.  For Unity to become a full fledged distro means favoring a DE over others.  By limiting the scope to the core product (we maintain the various DE too but leave the DE specific changes to the branches).  It makes it a little more difficult to install stuff but it also means that all DE are looked after.

As far as the user is concerned, it means the each branch has their word in the development of the core which ensures that the distro is well supported.  It pools the efforts of each distro who would otherwise be on their own so means a large development team and as such better packages.

So Unity Linux is a base on which to build.  A foundation for “remasters” to build from.  But what is a remaster?  What technologies does Unity use? Let’s take a look at the internals of Unity next.

Unity Linux Internals aka Guts

When we initially set out to not only have a small graphical base but also to wrap around the LiveCD project.  For those of you who don’t know what LiveCD is..you can visit the old berlios.de project page:

The project features automatic hardware detection and setup, and utilises compression technology to build a LiveCD from a partition much larger than would typically fit on a CD. (Up to 2GB for a normal 650MB CD.) When booting from this LiveCD, the data is transparently decompressed as needed. LiveCD now supports udev.

Currently,  Mandrakelinux and PCLinuxOS are supported as a host for creation of the LiveCD, i.e. we are only able to create LiveCD’s from a MDK or PCLinuxOS install. The LiveCD scripts are still beta, and bugs are being eliminated. Your help and feedback are appreciated!

The set of scripts allows a person to make a liveCD copy out of their desktop for backup purposes or as a standalone linux distribution.  When you create that new ISO or backup ISO, you have ‘remastered’ the master copy.  So the livecd scripts are really just a set of tools that allows a user to create something new or backup their existing desktop as a live CD.

The project at berlios was taken over by Didouph as lead developer just before Unity was formed.  There hadn’t been much work after Tom Kelly left the project quite a long time ago, but Didouph was optimistic.  When he joined Team Unity, he placed LiveCD development on the back burner and worked hard with the graphics team on logo development.

Later, it became apparent that in order to keep creating a great distribution that could remaster itself, we needed to make improvements to the code of LiveCD.  First off, it needed 64bit support.  Secondly, it needed better detection than what it had.  Third, it needed to have internationalization work done.  Fourth, it needed to support higher kernel versions than what it did.  All those things have been accomplished with internationalization still being worked on.

When we initially took over the ‘modernization’ of LiveCD we didn’t all flock to berlios to do so.  Work instead began when we gave a small sliver of our own SVN over to LiveCD.  It made sense geographically for our developers to have the ability to commit code in the same place instead of at a third party (berlios); the reason being, we needed many commits fast and didn’t want to wait…we were ready to move forward with it immediately.  We snagged the GPL’d LiveCD code and located it on our SVN.

Since Didouph was the maintainer of LiveCD, we felt it only natural that Unity would lend a hand to him and his project by taking over development.  An entire team working on LiveCD would mean greater output and more advancement.  Thus, Unity maintaining the LiveCD project was born.  Anyone is welcome to take the code and use it how they seem fit.  We’re working on getting LiveCD it’s own proper SVN or Git repository at a public site away from Unity Linux…if you’d like access (read only) to LiveCD SVN, drop Unity Linux a line via their contact page.

Common Myths Surrounding Unity Linux

Heard any good ones lately?  If I don’t cover the ones you’ve heard here, please leave me a comment and I’ll address yours specifically.

Myth #1 – Unity Linux is just PCLinuxOS rebranded

Most of the developers of Unity Linux were contributors to PCLinuxOS during the time that Texstar had stepped away.  As contributors, they were not part of the developer team.  They had limited access to the core, iner-workings of PCLinuxOS.  How do I know?  I was a developer…the main web developer…for PCLinuxOS and I monitored all mailing lists, all websites, and even was chief of MyPCLinuxOS.com.  There were very few people on the development team of PCLinuxOS that are now part of Unity Linux…because the PCLinuxOS development team was kept small.

When Unity Linux initially was started, the contributors and developers that were involved grabbed a ‘snapshot’ of the PCLinuxOS repositories and began working on bringing packages to updated versions.  They quickly ran into trouble because PCLinuxOS used such an outdated toolchain that many new packages wouldn’t compile with it.

After some discussion, developers abandoned PCLinuxOS packages and instead worked with Mandriva packages.  This allowed Unity to move forward sans old toolchain and outdated core.  Now most of this stuff doesn’t matter to the end user…they just want a stable environment.  But the Unity Linux developers wanted to push forward with the latest kernels, the latest rpm version, and the latest smart package manager versions.  Doing so required massive leaps forward even from Mandriva.

As you can see, while Unity Linux originally started with a PCLinuxOS fork, they abandoned that fork and rebased on Mandriva.  They now stay inline with Mandriva development.  If you have Mandriva and Unity Linux questions, please stop into the Unity Linux chat channel on Freenode: #unitylinux and ask proyvind questions…as he is the Mandriva Linux representative that works with Unity Linux

Myth #2 – Unity Linux Stole mklivecd aka livecd from PCLinuxOS

This is a pretty funny one and I’ve seen quite a few references to ‘stealing’  GPL code.  First things first:  You cannot ‘steal’ GPL code.  It just can’t be done.  Secondly, the LiveCD project was stagnant and had a SINGLE developer working on it.  That developer joined Unity Linux and all 25+ developers there decided to help him make some progress on it.  In the meantime, they took the initiative to make improvements.  For example, they gave it 64bit compatibility.  They gave it have better detection.  They took the code and gave it better international language support.  All those things are made available for FREE to any distribution wanting to download a snapshot from SVN.

Now, if anyone has a claim to LiveCD as ‘theirs’ it would be Jaco Greefe who was the principal on the project LONG before any distributions other than Mandrake aka Mandriva even worked with it.  Texstar grabbed what Jaco’s project mklivecd and used it to create the original PCLinuxOS 2003 release.  This release was based on Mandrake 9.2 at the time and a few other Mandrake developers began to debug the script through the creation of PCLinuxOS.  Mandrake was a trademarked name, so Texstar named it PCLinuxOS.

As you can see, if any one distribution has claim to mklivecd, it would be Mandrake aka Mandriva which was where the script creators came from.  It’s also where the script was first made useable.  However, claim that Texstar made it into a nice package with PCLinuxOS…that is totally true.  What we’re doing now by developing it is making sure it continues to progress into the future with 64bit support and even when udev is dropped from Linux…no matter what, we’ll make sure it works…and hopefully it will work for more than just Mandriva derived distributions.

There have been many attempts by Unity Linux developers to get other distributions that use mklivecd involved with the development of it.  That invitation is always open to any and all distributions that use it.

Myth #3 – Unity Linux wants to steal away users from other distributions of Linux

The main reason this isn’t true is that Unity Linux targets DEVELOPERS.  We don’t target end users.  If end users like Unity, GREAT!  If not, we don’t worry about it.  Unity Linux has derivative distributions called “branches” that work to target the end user.  Unity Linux itself is targeted squarely at distribution developers and advanced users who want to be able to use the mklivecd scripts.

Myth #4 – Unity Linux DOESN’T use PCLinuxOS at all in development

This is half true.  We don’t ‘use’ PCLinuxOS to create things…we use it as a mirror synch.  Paul Grinberg, a developer on the team, has a PCLinuxOS box that he doesn’t use.  During the initial setup of Unity Linux, we based things on PCLinuxOS before purging and switching to Mandriva.  Since the developer mirror server (referred to on the mailing lists as the dev server) still ran PCLinuxOS and Unity Linux didn’t have a release yet, we saw no reason to change it.

As Unity Linux still has no stable release as of March 29, 2010, that developer mirror server still runs PCLinuxOS and pushes uploaded packages developed on a Unity Linux server to various mirrors for propagation.

In other words, the PCLinuxOS server Unity Linux uses is just a web server.  It will be replaced with Unity Linux when 2010 is released.  Until then, taking the time to wipe it out and repopulate it would throw a kink in the flow of package development so developers have put this ‘to-do’ item as something to be accomplished after stable release.

Unity Linux and Open Source

Unity Linux does a great job of contributing to projects upstream.  As an example, David Smid, a Unity Linux developer, is also a Smart Package Manager (SPM) developer.  This allows Unity the ability to test the latest and greatest SPM and get things quickly patched/fixed/redesigned.  Other projects such as mklivecd are developed openly by Unity Linux and contributors are welcome.  Unity Linux contributes bug finds to Mandriva through use of the Mandriva Cooker repository.  Unity Linux developer Paul Grinberg contributed Google Map integration for MirrorMon, which you can view on our Mirror Status Page, back upstream to the creator of MirrorMon.  Unity Linux also contributes upstream to rpm5.org.

Unity Linux also has a working partnership with Yoper Linux.  Why?  Because Yoper Linux uses many of the same core technologies (Smart, rpm5) that Unity Linux uses and because the lead developer, Tobias Gerschner, is an all around great guy .

You can see everything that Unity Linux works on by visiting our repository:  http://dev.unity-linux.org/projects/unitylinux/repository

Development is done in the open, not behind closed doors:  http://groups.google.com/group/ul-developers

Unity Linux strives with an almost rabid will to keep everything in the open for users and branch developers so that they are not left wondering what’s going on with their distribution.  The Developers continue to try and engage other distributions to work with them and will continue to do so in the future.

Closing Thoughts

Unity Linux doesn’t target the same users as your average distribution of Linux…they’re after the more savvy users out there.  The ones that want to create something and make something from the core image.  Users that like to tinker and mess and break things.

Unity got off to a rough start with much FUD slinging and accusations.  Hopefully, the actions you see that Unity has taken to keep it’s project open will show the intent of the developers…to make a great core on which others can branch from all the while remaining open and free for everyone.

Related posts:

1. Foresight, rPath, LiveCD, and Unity Linux Most, if not all, top distributions of Linux ship a...
2. Unity Linux Theme Refreshes I’ve been pretty busy lately with theme design for the...
3. Unity 2010 Beta 2 Impressions As noted previously, I’ve been pretty hard pressed lately in...

Related posts brought to you by Yet Another Related Posts Plugin.

What Is Unity Linux? originally appeared on Yet Another Linux Blog on March 29, 2010.

Use Whatever You Want

I ran across the flash video above (note: I’m not taking content and embedding it here…you’ll need to click on the image to be taken to the author’s site) a while back and have never posted a link to it.  It’s pretty funny and if you look around on ubergeek’s site, you’ll find a couple of other interesting things like the awesome flash game “Penguin Blood Ninja Fiasco” which I think is just genius.  So give this a look-see…you won’t be sorry.  Guaranteed to brighten even the darkest open source supporter’s day.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Do you…uh…Use Linux? originally appeared on Yet Another Linux Blog on February 19, 2010.