If you take a look at the graphic below, the spike in the middle will probably stick out quite a bit.  Oddly enough, the spike I noticed in CPU percentage used (which is regulated for VPS at Linode) also spiked up disk usage…mainly because I began to swap when cpu/ram use skyrocketed.  All of this happened with Ubuntu 10.04 installed.  CentOS was the first distro I tried but I quickly switched to Ubuntu when I spotted a really nice how-to in the Linode document library.  Oh, and please excuse my horrible gimp skills on the image below…it was a quick and dirty editing of the image:

cpu usage

After switching to Ubuntu, I began receiving alarms for my account due to the high usage of CPU and disk.  I attempted to tweak settings and configuration files for about a week and realized it just wasn’t going to work for me.  I switched to Debian Lenny and the move was a positive as is reflected in these pictures.

disk usage

I was hoping Ubuntu 10.04 would fit for me since it is a long term support (LTS) release.  CentOS is my normal server distribution of choice and I really wanted to branch out and go with something different.  I used a Linode Stackscript for WordPress for CentOS but elected for vanilla installs of Ubuntu and Debian aftwards (I didn’t like NOT knowing what was installed when I first logged in…call me a control freak).

I just found it interesting that Ubuntu 10.04 did so horribly in this instance.  After investigating, I found a couple of likely suspects:

1. Default Apache install in Ubuntu leaves a lot to be desired..even after tweaking both it and PHP for days I couldn’t get them to lay off the resources.  Even switching to mpm_worker and FastCGI did little to settle things down.
2. Ubuntu swappiness is bad…it is set at 60 (I use 10 normally) and it swapped every chance it could get…it’s set by default to swap more than it should.
3. mod_php on Ubuntu is hungry for all your cpu and ram and disk; be warned!

Debian, as the parent distribution of Ubuntu, would most likely suffer from the same problems…except it doesn’t.  Things are working great with it and I’d recommend it for any of your server needs!  Has anyone else seen this oddity with Ubuntu 10.04?  If so, please drop me a comment below.

Related posts:

1. A Blip on My Posts Hello everyone! You may have seen a blip swing by...
2. Do you…uh…Use Linux? I ran across the flash video above (note: I’m not...

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

Interesting Statistics originally appeared on Yet Another Linux Blog on July 13, 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!

Related posts:

1. Foresight and Fedora, ClarkConnect Becomes ClearOS Foresight and Fedora (aka “boots, a fedora remix”) Last week...

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.

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!

Related posts:

1. Foresight and Fedora, ClarkConnect Becomes ClearOS Foresight and Fedora (aka “boots, a fedora remix”) Last week...

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.

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.

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

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

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

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

I’ve written a guide for new users on how to understand the vitrol that rabid zealots spew in Linux communities ^[2]

Those problems are all very easy to see…but these articles deal with only the tangible problems in these areas.  What are the reasons these problems exist?  Is it because of one or two individuals?  Is it mob mentality?  Are people just waking up on the wrong side of the bed?  I don’t think these reasons get down to the core of what the real problem is…the hidden problem…of zealots in the Linux community.

The Hidden Problem

The hidden problem is Narcissism…people think that what they have to say about a given subject makes the most sense and is 100% correct (or at least more correct than others’ POV) and it’s one that is hard for people to talk about…because anyone that writes or blogs has to be a little bit narcissistic.  People don’t like talking about problems they’re guilty of.  I know I am guilty of it…and I’m still going to talk about it.

With social networking riding a tidal wave right now, the era of the narcissist moves on, unhindered, on the interwebs.  Subscribe to my twitter feed…what I have to says in 140 characters or less is a MUST READ!  My facebook page will keep you updated on EVERY little thing I decide to post unless you edit me out of your news feed.  Sites cater to the egocentric tendencies of anyone plugged in.  So what happens when you get a bunch of narcissists together sharing a common goal?  “My distribution is THE BEST out there and no other point of view matters!”  That’s right, you get zealotry in the purest form.

This has slowly begun leaking into Linux communities during the past few years as Linux is tried out by more and more people and becomes more available to people who aren’t technologically advanced.  Bottom line is, more people are trying Linux now than ever before.  This makes the user pool larger and more diverse.  Where there are more people though, there are more narcissists…and birds of a feather flock together.

Take narcissism with a twist of mob mentality and the powder keg in Linux communities is set to blow.  The zealots seethe and team about in forums, IRC, and on blogs across the internet looking for a place to show how right they are and how wrong the person posting information is.

Oh, I admit it…I have a narcissist streak in me…I want people to read this blog.  I want people to follow me on twitter.  I want people to pay attention to what I say…it’s part of being a blogger…but I don’t think that my distribution of choice is any better than yours.  In fact, I know it’s not.  Just like my car isn’t any better than the one you drive and my clothes are so last year and aren’t as good as yours.  I offset my narcissism with realism…I understand that what I think isn’t the only point of view out there…I don’t think I’m 100% right all the time.

I also don’t go out on the web and try to find others who think my view is the best view and then try to push my egocentric viewpoint to others.  I don’t create a community of zombie thinkers who all believe my viewpoint is the best out there.  I’m not forming any mobs for my mentality.  I’m not flocking together with birds of a feather.  I’m a part time ego-narcissist I guess.

The first step is admitting that you have a problem.  The second step is having some good old fashioned manners, respect for others, and above all…tolerance and realism.

Solution to the Problem

When you’re standing in line at a bank, would you cut in front of someone in the line?   Most likely you wouldn’t.  Personal conflict is something we as humans avoid most of the time.  So, why is it when you’re driving you don’t mind cutting someone off and do it regularly?  It’s because the personal aspect of that motion has been replaced into an impersonal one…the car becomes a protection from that personal conflict that would happen if you had done the same thing in a bank line.

To fix the problem this presents on the web and in Linux communities, think about others (not yourself) and in doing so, become less narcissistic.  Apply this thinking to commenting and blogging and facebooking and tweeting.  Imagine that you are face to face with people saying the things you’re typing.  If you wouldn’t say things like that in a face to face situation, don’t say them.  Remember that tolerance of other viewpoints makes you a better person…AND smarter.  How?  Albert Einstein is largely considered one of the smartest humans to ever walk the earth.  He often gathered with other intelligent people to debate and discuss various topics that interested him.  In doing so, he caused those he debated with “to sharpen and refine their understanding of the philosophical and scientific implications of their own theory.”  Remember that everyone does NOT have to share your viewpoint…what works for you may not work for them.

Lastly, no one cares if you sat down in your office or are eating a peanut butter sandwich.  We subscribe to feeds and twitter accounts for meat and potatoes posts…not 1 liners that tell us you’re in the bathroom of a bakery on 96th street.  So, you zealots out there…you know who you are…take this opportunity to reflect on yourself (your favorite subject) and try to replace your narcissism with realism, tolerance, and good old fashioned manners.

And no I don’t think any zealots will be converted by this post…it’s more of a rant than anything else…and rants are one of the reasons why I have a blog   Well that and because what I say is more important than anyone else and my viewpoint is 100% correct 100% of the time of course.

No related posts.

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

Zealots and Narcissism originally appeared on Yet Another Linux Blog on December 21, 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?

Related posts:

1. Foresight and Fedora, ClarkConnect Becomes ClearOS Foresight and Fedora (aka “boots, a fedora remix”) Last week...
2. 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.

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

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.

Related posts:

1. Rethinking Home Servers Since my first home-built server (a PI 75Mhz behemoth) I’ve...

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

Slackware and Zenwalk originally appeared on Yet Another Linux Blog on June 4, 2009.

advanced search

This gives us a great opportunity to organize our developer blog feeds and developer resources for the end readers to drill down to the information that is important TO YOU. You’ll be able to search through feeds using the search function on planet or click on tags to display similar content.

So not only is this a new look, it’s a whole new set of features and functions:

• Supports RDF, RSS, ATOM feeds
• Imports and exports OPML
• AJAX powered tagging of feeds and items
• Supports themes and plugins
• Search in your feeds
• Basic i18n support
• Committed to web standards: renders XHTML/CSS
• Gregarius is FREE software and is released under the GPL

Now not all of these features and functions matter to end users, but they do give Unity Linux developers an opportunity to provide you with a good planet experience…that is, getting the most information in the least amount of time with the least effort!

Look for more great improvements soon!  We’re working furiously all the time to make this the best Linux core out there!

Related posts:

1. Unity Linux Theme Refreshes I’ve been pretty busy lately with theme design for the...
2. What Is Unity Linux? There’s been a lot of confusion about exactly what Unity...
3. Unity Linux Automates Build Process The guys over at Unity Linux have created and developed...

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

The New Planet Unity originally appeared on Yet Another Linux Blog on April 28, 2009.

I have decided – after running Foresight for two months – to no longer use Foresight Linux on my systems. Let me say however that I found the experience interesting and dare I say – challenging. Everyone in the IRC channel was great – very friendly – and most tried to be helpful.

I thought it might be helpful and instructive to provide an explanation as to why I am not going to use Foresight any longer, rather than just disappear. Hopefully, in doing so I may contribute to Foresight becoming a better distro that I might want to run in the future. So, here goes ….

Concerns With Foresight Linux

Conary: When you read about conary it all sounds very exciting and innovative with many really good features. However – when you install Foresight and actually use conary – it doesn’t take too long to realize that unless you are a developer or very involved packager – very little of conary’s goodies really touch you or help you (with the exception of rollback).

However – it’s negatives do impact you as a user:

1. It is very complex and difficult for the average user to understand and use with any effect
2. It is hard to locate individual packages and make sure you have what you need when things are failing to work right
3. The idea of ‘group’s puts numerous things together making it somewhat confusing to sort out when a dependency is not met for an app you really need.

Development and QA: To be very honest – the development of this distro ‘seems’ from my perspective to be done as a fun project – almost a ‘toy’ if you will – for the creator and a couple of his ‘close’ friends. Everything seems to be about advancing to the next version of things – the constant cutting edge challenge of adding in the latest or something really new – without ever really QA’ing and stablizing the existing released code. So problems users are having never really get fixed properly. And this leads to the next concern ….

JIRA: This is the issue tracker for Foresight.  By and large – it appears that issues that don’t personally effect the developers are ignored. I personally have an issue in the tracker concerning sound – which has been there for over 30 days and no one has done anything with it. I finally figured out what was causing the break – but it requires the devs to fix the code. But they have not – and ignore the issue because it works fine for them. Many people have complained about sound issues – but the developers are concerned always with developing the latest code for the next cutting edge release instead of stopping to fix the broken code and solve problems. Poor QA – poor response to user problems.

Conclusion: So – Why Use Foresight? Given the above issues that concern me, I must ask the inevitable question – “Why use Foresight then?” And frankly – I can come up with no compelling reason to do so. Outside of cutting edge gnome – it offers me nothing I cannot get elsewhere – in debian or slackware or archlinux, etc. And those distros are more stable – address issues that are legitimate user concerns – work hard to QA their distros – and in general put out a more user friendly product. The truth is – it’s all linux. So what really counts then is product presentation – QA testing – responsiveness to user problems – and stability providing the ability for the users to do actual work with their linux systems without always trying figure out why something doesn’t work. These things all need real work in Foresight Linux.

The result for me then is that I have returned to Debian. I wish only the best for Foresight Linux and it’s developers and users. I hope some of the issues that have led to my decision will be addressed and that one day I might come back and give it another go. I believe there’s a lot here to like and a great deal of talent. Thank you for your patience with me.

Sincerely,

Theoden

Related posts:

1. Clarification on Foresight and Fedora I previously wrote about a possible “rebasing” of Foresight Linux...
2. Foresight, rPath, LiveCD, and Unity Linux Most, if not all, top distributions of Linux ship a...
3. Foresight and Fedora, ClarkConnect Becomes ClearOS Foresight and Fedora (aka “boots, a fedora remix”) Last week...

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

An Open Letter to Foresight Linux originally appeared on Yet Another Linux Blog on March 16, 2009.