Tag: PCLinuxOS

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

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.

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

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.

I installed PCLinuxOS 2009 recently on a Dell D630 Latitude and was disappointed to see that I couldn’t get the hardware volume (up/down/mute) buttons didn’t work out of the box. I thought a bit about kmilo, a program that was previously used for laptop buttons (thinkpad buttons though) and I searched around a bit inside the KDE Control Center for keyboard shortcuts to see if I could assign the keys manually. However, I couldn’t find any volume setting inside this menu.

Then, it hit me, I had remembered seeing volume settings before…inside kmix; there is an area for assigning global shortcuts for volume and mute! This should work for anyone running KDE 3.5.8 and above (I think). Left click on Kmix in your tray and choose the mixer button. From there, choose Settings >> Configure Global Shortcuts. Now assign the volume up, down, and mute keys manually by clicking in the blank and pressing the hardware button. This should work for a majority of people out there. For me though, this didn’t work. When pressing the keys, nothing happened. I thought I was doomed.

I researched a bit more and found that installing a program called keytouch would allow me to, at the very least, program my keyboard in any way I wanted to program it. I opened Synaptic and installed keytouch and keytouch-editor. After install, I went to Kmenu >> System >> Configuration >> Hardware >> Keytouch. It prompted me to choose my keyboard. Since it didn’t have the Dell D630, I chose the closest thing which was the Dell D800. I closed the application and now the volume buttons and mute button works! Keytouch also has the ability to manually edit and also to import keytouch ‘schemas’ to give maximum flexibility. Hopefully, this helps some of you out there that cannot get your multimedia keys working in PCLinuxOS and KDE to work!

It’s really sad when the Alpha release of Ubuntu makes the front page of Digg.com for Linux/Unix… but the release, after two years of development, of PCLinuxOS 2009…a distribution that challenged Ubuntu for the #1 ranking at distrowatch in 2007-8…goes completely without being dug at all. Well, to be fair, it was dugg by 18 people at the time of this post. This just goes to show you, all those people that accused PCLinuxOS of “fixing” the distrowatch.com rankings last year may have been a bit paranoid and way off base. Just the same, viral websites have an observable slant when it comes to things that are seen as cool so I really shouldn’t be suprised. I just wish that distributions that deserve praise got it when they deserve it…and that more got it more often for what they do.

I have a laptop with the resolution of 1440×900…so when I installed the latest TR6 from PCLinuxOS, I was dismayed to find out that when launching Firefox, it opened up in a window that was 1024 pixels. Of course, I maximized this and then closed it thinking that Firefox would remember my settings. The problem is…it didn’t remember my settings.

When I opened Firefox up again, it popped up to say hello once again at 1024 pixels. Sure, you can right click on the Firefox window bar and drill down into application specific settings via KDE (yes, it’s that configurable) but I didn’t want to have to do this…because if I did, ALL Firefox windows would open up maximized…and that includes any pop-ups as well. I also know that you can drill down even further to fix THAT problem. However, it should ‘just work’ right? You shouldn’t have to change anything at all correct? Well, I’ve found a fix that is pretty easy to accomplish…and I hope it helps the hundreds of people I found when searching through google on this.

Open up Firefox and it will open at the smaller screen size…in my case, it opened up 1024 px in width on my 1440px screen. Then, hover over the top right hand corner with your mouse until you get the resize arrow. Resize the window click dragging it to the top, right hand corner of the screen. It should ‘snap-in’ once you get close to maximized size. Now close the window, and open Firefox again. It should open up fully maximized.

I sure hope this saves someone time…because I spent the better part of a morning trying to fix this.

You’ll be looking for the ‘sections’ blank when viewing repository details and you’ll just need to add ‘testing’ to the end of the line (don’t replace the entires there already). Once that is done, click the reload button in Synaptic and allow it to refresh your local rpm cache.

Click the ‘search’ button and search for the keyword ‘kernel’. Look for the highest number of kernel that is returned. At the time of this writing, the 2.6.26.8 kernel was the newest kernel for PCLinuxOS (it has .27 patches all over in it…so it’s quite a nice kernel). Click and install that kernel and allow it to select any packages it needs to install. Once installed, you can remove the word testing from the repository (this is recommended to prevent your system from downloading ALL testing packages/updates) and click the reload button for Synaptic.

Reboot and choose the new kernel on your grub menu. Test things to see how they work. If everything is good to go, congratulations! You’ve just installed the latest kernel in PCLinuxOS.

To make this kernel the default one, you can use the PCLinuxOS Control Center and Change the Way the System Boots. I’ll cover this in a later post. Hope this helps a few of you out there. I know it is often asked on IRC.

So, HowtoForge has a perfect desktop for PCLinuxOS 2007…how about something similar for 2008 MiniMe? I won’t go into near as much detail as they do there but I’ll go over how I get my desktop up and rolling after a fresh install of PCLinuxOS Minime 2008.

Build Your Own PCLOS

So, HowtoForge has a perfect desktop for PCLinuxOS 2007…how about something similar for 2008 MiniMe? I won’t go into near as much detail as they do there but I’ll go over how I get my desktop up and rolling after a fresh install of PCLinuxOS Minime 2008.

MiniMe is the lesser known offspring of PCLinuxOS 2007 that ships with a 2.6.22.15 kernel and is a minimalistic installation of the KDE desktop 3.5.9. Texstar provides this distribution for those wanting to remaster their installations…it’s a base for other remastered projects like PCLinuxOS Gnome. Remastering and the Make LiveCD wizard enable users to customize their distribution and make a bootable backup CD with all their customizations OR release their own customized distribution. You can also use the Make LiveUSB wizard to create your very own thumbdrive PCLinuxOS.

I found it strange that no one had written anything about MimiMe-to on getting PCLinuxOS 2008 MiniMe up and running as a desktop replacement so I decided to give it a go. The aim of this article isn’t to copy Howtoforge’s great series on perfect installations…but to show how I get PCLinuxOS 2008 Minime up to a perfect installation for me. This means all web video, audio, fonts, and tools I need are installed. So let’s get at it.

What Do We Need?

First and foremost, do a complete upgrade of your fresh installed system. Open Synaptic >> Reload >> Mark all Upgrades >> Apply. It’s going to take a while to get all the updates you’ll need. Do NOT enable the testing repository until after you install your graphics driver at the end of this article…just perform a straight update from main.

Now let’s start installing stuff that is needed on a daily basis. I’m more of a lightweight type of guy so I don’t need robust office applications so my tastes may not line up with yours. Please substitute applications where you see fit…the repositories most likely have them.

To give a brief, high level overview of my daily use applications:

firefox3

Opera

K3B

konversation

pidgin

skype_static

koffice

gimp

Amarok

claws-mail

kdeaddons-kate

kdeaddons-ark

kdegraphics-ksnapshot (for taking screenshots)

Those are the high level applications I use on a daily basis to get things done. Whenever you are prompted to mark other packages for install, go ahead and and choose “mark”. Click apply and let the your daily use applications install.