Unity Linux is a small Linux core based on Mandriva Linux.  We whittle down Mandriva to a small base desktop to provide users with ‘just enough graphics’ to be able to login and create their own distribution of Linux with the liveCD project which lies at the heart of Unity Linux.  We’ve replaced some of the common things like uprmi with the Smart Package Manager and we’ve moved on past RPM version 4 to RPM version 5.  Version 5 gives us some really cool features as well as speed enhancements across the board.

If you’re in the mood for Mandriva goodness (control center) without the extra stuff…give Unity Linux a try as a cholesterol free Mandriva.

In February of this year, Unity Linux turned 2 years old.  With this milestone on the horizon, we were approaching the time when our hosting service was coming due for another large chunk of change.  I began to seek out different hosting plans and price them and our developers started talking fund raising.  In January, I approached a hosting company named Host Color about the possibility of sponsoring Unity Linux via providing a hosting plan for them…to my delight, they were more than happy to provide for us!

I approached Host Color because they have been a sponsor of Yet Another Linux Blog for well over a year now helping the authors here bring excellent how-to’s and editorials about Linux.  Now Host Color has offered hosting for Unity Linux and given us a fine place to hang our hosting hat.  So, please join me in thanking Host Color for providing us with our new home!

Unity Linux Gets a Sponsor with Host Color! originally appeared on Yet Another Linux Blog on March 15, 2011.

Then the worst thing that could possibly happen on my Gateway M250 happened…ALSA stopped working and there was no sound.  I started pulseaudio back up to no avail…no matter what I did, nothing worked to get sound up and running.

It was about the time I wanted to carve the sound pieces out of my laptop and throw them across the room that I decided to give everything I tried in the past one more try.

I fixed it…and I was pretty amazed that the solution was as easy as it was having spent weeks upon weeks fighting the pulseaudio issue.  I can only surmise that I made a typo in the module that I needed to blacklist.  After this arduous journey, it came down to blacklisting the modem sound card to make things work.

To do this on Mandriva and Unity Linux you’ll need to blacklist the following module:  snd_intel8x0m.  Notice the ‘m’ on the end of the standard module snd_intel8x0 for the ICH6 sound card.

You can do this by editing the following file as root in your favorite text editor:  /etc/modprobe.d/blacklist-compat

Add the following line anywhere in this file:

blacklist snd_intel8x0m

After that, you can reboot to make sure the module is blacklisted.  I know there are more elegant ways to load and unload kernel modules but this is the easiest way to get the job done for new users.  Subsequent reboots resulted in still having sounds.  Thankfully, I didn’t have to rip my laptop apart in a quest to throw the sound portions.  I sure hope this helps others out!

ICH6 Intel Sound on Unity or Mandriva PulseAudio Fix originally appeared on Yet Another Linux Blog on October 22, 2010.

I checked out Gnome 2.30 on Unity and found it to be delightful on my resources; however, Gnome doesn’t make me feel warm and tingly when I use it.  I find myself frustrated with its lack of configuration options…specifically, right click menu.  So I rolled my own using the base install of Unity.  That worked quite nicely but lacked much of the polish I became accustomed to when using KDE.  What I wanted and needed was a happy medium.   I found that happy place with TinyMe Linux.

TinyMe is based on Unity Linux 2010 and was previously based on PCLinuxOS.  It uses LXPanel, PCManFM and the Openbox Window Manager to handle the heavy desktop lifting.  The ISO I used was a release candidate and lacked much of the polish of the TinyMe stable release of the past.  Even though it’s a release candidate, I still found it quite stable and usable…especially since I know my way around the openbox window manager.

You can snag the TinyMe release candidate here:  http://distro.ibiblio.org/pub/linux/distributions/tinyme/

After a few adjustments of adding my favorite programs I was in business.

TinyMe RC 2010

Even without some of the programs that made TinyMe famous (like the TinyCC) this distro is both stable and robust which is a testament to the underlying Unity Linux core.  If this release candidate is any indication, look for GREAT things to come from TinyMe 2010′s full release…something I will be looking forward to!

TinyMe Linux For The Win originally appeared on Yet Another Linux Blog on October 20, 2010.

smart install flash-player-plugin

Next, we need to create a directory under your profile to house the flashplayer plugin and then copy it there.  I’m sure we might be able to get by with a symbolic link but I didn’t try that out…

mkdir -p ~/.mozilla/plugins && cp /usr/lib/mozilla/plugins/libflashplayer.so ~/.mozilla/plugins/

That’s it, it should work now.  I’ve done this on 32bit Unity Linux 2010.1 on a Gateway M250.  Hopefully this helps out someone out there

Midori, Flash, and Unity Linux 2010 originally appeared on Yet Another Linux Blog on September 8, 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

Ubuntu Names Their Desktop After Us? originally appeared on Yet Another Linux Blog on May 10, 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.

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.

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

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

Unity 2010 Beta 2 Impressions originally appeared on Yet Another Linux Blog on January 15, 2010.

1. Unity-Linux.org
2. Planet.Unity-Linux.org
3. A new forum theme called SMFPress @ forum.unity-linux.org

Uniformity was the key ingredient to the stylings.  I’m trying to match everything to the front page theme at the main site page.  Using the color pallete from that site, I worked on creating a theme for our forum and then gave planet unity a facelift as well.  We’ll test out the planet capability a bit longer (see how updates go) before we ultimately conclude to use it.  However, the forum and main site are finished products.

Let me know if you find any bugs or have any problems with the theme.  If all goes well I’ll start on a wiki theme for our documentation site

Unity Linux Theme Refreshes originally appeared on Yet Another Linux Blog on November 9, 2009.

Foresight Linux is the exception.

Now, this isn’t because they don’t WANT to have a Live CD…they do.  The problem is that rPath, the creators of rBuilder Online, have discontinued the Live CD image creation type.

There was no announcement…no news posting…no clue dart thrown toward Foresight for this discontinuation.  There was only a comment on a single bug in the rPath issue tracker just this past May…Formally discontinued…which in my opinion, is a HUGE mistake as far as community goes.  Why? Because a community is a solid base on which to stand for any distribution or toolset for open source.  rPath has essentially dismissed a feature that the community would find valuable and in the process alienated anyone who finds this feature valuable or desirable.  But I’m not here to talk about whether or not people want to develop their own distributions on rBuilder Online using rPath tools nor the incentive to do so…I’m talking about Foresight. 

So, what incentive does rPath have to help Foresight by fixing it?  Not much…I’m sure there will be those that argue: “rPath has customers and their first allegiance needs to be to them” and those people would be right.  But can’t the Foresight community pick up the torch for Live CD building  on rBO and develop it as a community effort?  Can’t a license be found that it can be released under that would prevent forking?  Can’t it be modularized as a ‘plug-in’? I don’t pretend to know the answer to those questions…I just think that Foresight will continue to suffer as they have been for many, many months now with respect to not having a Live CD.

I’m sure that there will also be those out there saying “but Foresight has a bunch of Virtualized Images to choose from!! No one really cares about a Live CD!!” and I’d say you’re halfway correct.  Developers don’t really care about a Live CD…but those that Foresight attempted to attract…the end user…they DO care about having something they can ‘try before they buy’.  It is my belief that Foresight would be a crap-ton more popular if they had a Live CD.

So What Solutions Are There?

I don’t think rPath will suddenly fix the broken Live CD creation in rBO.  I don’t think they’ll release the code anytime soon (though this is more likely than a fix).  So in the meantime, what if Foresight helped out with LiveCD project that recently was taken over by Unity Linux?  Both Unity and Foresight are Red Hat like distributions and use similar file structures and OS organization.  I think that if Foresight were able to integrate LiveCD onto the distribution, a huge niche would be filled.

Where to Start?

Being involved both with Foresight Linux and Unity Linux gives me a unique perspective on what areas of collaboration could be developed.  One thing is for sure…having both distro development teams onboard would be a huge boon to LiveCD development…and Foresight could suck in SRPMs quite easily from Unity to hit the ground running right away.

I am by no means offering to be the head of this project because I can’t even begin to know where it would start or finish.  I’m just offering a workaround to a problem I’ve seen Foresight have for longer than it should have.  I know the Unity Linux guys would welcome anyone wanting to get involved with helping LiveCD development.  Would Foresight be open to this?  I can’t answer.  I hope so…Foresight needs a Live CD if it hopes to attract more people to it…and that’s something I’m keen on seeing.  Is this something you’d like to see as well?

Foresight, rPath, LiveCD, and Unity Linux originally appeared on Yet Another Linux Blog on October 14, 2009.