Courtesy of evelynishere

Which distribution is the RIGHT distribution?  Is there such a thing?  When you start your journey with Linux you might here something like this:

- Ubuntu is the best distribution for the desktop
- Linux Mint is the best distribution for a home user and the desktop
- Debian is the best way to go because of its stability and solid base
- Mandriva isn’t as good as Mageia
- Mageia isn’t as good as Mandriva
- Red Hat is for servers only
- Distribution X is better than distribution Y!

Here’s the thing…statements like these are all BLATANTLY FALSE.  Why?  Because they’re opinions..everyone has one and they are all just that…opinions.

When you start your journey with Linux, don’t let someone else tell you what you should or shouldn’t use.  Go out and find what fits you like a glove and use that.  It doesn’t matter how large of community the distribution has (unless that is what you’re specifically looking for) or how often it updates or how many hits it has on the Distrowatch tracker.  Use what is best FOR YOU.  Only you can decide what distribution scratches whatever itch you have.

If you choose the right one, chances are you’ll be a part of that distribution for a long time.  But don’t worry, it isn’t like Indiana Jones and the Last Crusade and if you pick the wrong distribution you won’t turn into a dusty exploding skeleton.  In this situation, the RIGHT distribution of Linux is ANY distribution of Linux.  As long as you’re making a conscious effort to choose free software and use Linux, you win.

I’ve been in, around and even leading Linux communities since the late 1990′s and there is one thing I’ve found it is this:  Every single distribution has a place in this world.  Every single distribution has it’s own niche users.  Every single distribution of Linux is important. I’m sure many of you have heard or have said that Linux just needs to simplify more and have only a handful of distributions so we can concentrate on just that handful and make it be fantastic.  Unfortunately, that wouldn’t work very well and would stifle creativity.  To prove my point…what if we didn’t have small distributions at all?  That wouldn’t have a large effect on Linux as a whole right? Let’s take a look at that hypothesis…

If Small Distributions Never Were…

As an example:  Symphony OS.  It used FVWM and Mezzo for the desktop experience and it REVOLUTIONIZED the way we see and interact with files.  If you use Gnome 3, Ubuntu Unity, or KDE 4.X, you’re using concepts that Symphony OS was the first to put onto a Linux desktop.  Symphony never had a huge user base.  It never shot up the charts at Distrowatch.  It did however, push the envelope of what a desktop distribution can and can’t do.  It did push the boundaries of design.  It did push simplicity and usability to a new level.  It also did web apps before webapps were cool.  Somehow it never caught on…but I it influenced people and challenged people to push the envelope of what was possible and impossible with desktop Linux.

Small, Niche Distributions Perform a Function

Often times I have found Linux users looking for a distribution that fills a specific function.  “I just want a file sharing distribution” they’ll say, or perhaps “I just want a nice and simple desktop”, or maybe even “I just want a tight firewall”.  The beauty of open source software and Linux is that you’ll find small, niche distributions that fit the bill for all of those needs and when you use these distributions, you’ll continue to learn about Linux…and perhaps you’ll push the envelope of what is possible and not possible just like Symphony OS did.

Regardless if you choose small or large distributions, you win.  The fact is you CHOSE and weren’t force fed something by system installers and companies who think they know what is best for you.

We CAN All Get Along

Many times when we pick the flavor of Linux we like, we identify with its goals…the direction its heading…maybe even the direction the community champions.  There isn’t anything wrong with this.  The next time you experience passionate supporters of Linux, keep in mind that neither you nor they are the enemy.  If you both use Linux and open source, you both win.  Small, large,  and niche distributions of Linux operate harmoniously together and build off one another…it’s one of the unseen benefits of Linux and open source.  Beauty and power in simplicity through collaboration.  Congratulate yourself every single day for choosing Linux!

How-To Choose the Right Distribution of Linux originally appeared on Yet Another Linux Blog on November 17, 2011.

Permissions are important for keeping your data safe and secure.   Utilizing permission settings in Linux can benefit you and those you want to give access to your files and you don’t need to open up everything just to share one file or directory (something Windows sharing often does).  You can group individual users together and change permissions on folders (called directories in Linux) and files and you don’t have to be in the same OU or workgroup or be part of a domain for them to access those files.  You can change permissions on one file and share that out to a single group or multiple groups.  Fine grained security over your files places you in the driver seat in control of your own data.

Some will argue that it may be too much responsibility…that placing this onto the user is foolish and other aforementioned operating systems don’t do this.  You’d be right…XP doesn’t do this.  However, Microsoft saw what Linux and Unix do with the principle of least privilege and have copied this aspect from them.  While the NTFS filesystem employs user access lists with workgroups and domains…it cannot mirror the fine grained, small scale security of Linux for individual files and folders.  For the home user, Linux empowers control and security.

I’m going to go over how users and directory/file permissions work.  So, let’s setup an example that will allow us to explore file permissions.  If you have any questions, just ask it in the comments section at the end of the article.

File Permissions Explained

The picture to your left is a snapshot of my $HOME directory.  I’ve included this “legend” to color code and label the various columns.  Let’s go through the labels and names of things first and then work on understanding how we can manipulate them in the next section.

As noted in the picture, the first column (orange) explains whether or not the contents listed is a directory or not.  If any of these happened NOT to be a directory, a dash (-) would be in place of the d at the beginning of the listing on the far left.

In the second, third, and fourth column (Green, Blue and Red) we find permissions.  Looking at the gray box in the bottom-right corner gives us an explanation of what each letter represents in our first few columns.  These tell us whether or not each user, group, or other (explained in detail later in this article) have read, write, and execute privileges for the file or folder/directory.

In the 5th column (white) the number of hard links is displayed.  This column shows the number of actual physical hard links.  A hard link is a directory reference, or pointer, to a file on a storage volume that is a specific location of physical data.  More information on hard links vs. symbolic (soft) links can be found here.

In column 6 (light blue) we find the user/owner of the file/directory.  In column 7 (gray blue), the group that has access to the file/folder is displayed.  In column 8 (pink), the size of the file or folder is shown in kilobytes.  In column 9 (fluorescent green), the last date the file or folder was altered or touched is shown.  In column 10 (grey), the file or directory name is displayed.

We’re going to pay specific attention to the first four columns in the next section and then follow that up by working with the sixth and seventh by going over user/owner and group.  Let’s move on to go over all of those rwx listings and how we can make them work for us.

Read, Write, Execute – User, Group, Other

First, let’s go over what different permissions mean.  Read permission means you can view the contents of a file or folder.  Write permission means you can write to a file or to a directory (add new files, new subdirectories) or modify a file or directory.  Execute permission means that you can change to a directory and execute ( or run ) a file or script for that file or directory.

The User section shown in green in the picture above shows whether or not the user can perform the actions listed above.  If the letter is present, the user has the ability to perform that action.  The same is true for the Group shown in blue above…if a member of the group that has access to the file or directory looks in this column, they will know what they can or can’t do (read,write, or execute).  Lastly, all others (noted in the red column above).  Do all others have read, write, and execute permissions on the file or folder?  This is important for giving anonymous users access to files in a file server or web server environment.

You can see how fine grained you might be able to set things up with…For example, you may give users read only access while allowing a group of 5 users full control of the file or directory.  You may want to switch that around.  It’s entirely up to you how you want to setup permissions.

More about Groups

Let’s go through setting up a group and adding a few users to it and then assigning that group permissions to access a directory and file.

Create a file inside your home directory by opening up a shell or terminal and typing:

touch ~/example.txt

You’ve now created a file called example.txt inside your home directory.  If you are already there, you can list the contents with the ‘ls’ command.  Do that now.  If you’re not already there, type ‘cd ~/’ and you will be taken to your home directory where you can ‘ls’ list the files.  It should look similar to the following:

[devnet@lostlap ~]$ ls -l
total 40
drwxr-xr-x  2 devnet devnet 4096 2010-05-24 17:04 Desktop
drwxr-xr-x  6 devnet devnet 4096 2010-05-24 13:10 Documents
drwxr-xr-x  9 devnet devnet 4096 2010-05-27 15:25 Download
-rw-rw-r--  1 devnet devnet    0 2010-05-28 10:21 example.txt
drwxr-xr-x 13 devnet devnet 4096 2010-05-26 16:48 Music
drwxr-xr-x  3 devnet devnet 4096 2010-05-24 13:09 Pictures
drwxr-xr-x  3 devnet devnet 4096 2010-05-24 13:04 Videos

Next up, let’s create a new group and a couple of new users.  After creating these we’ll assign the users to the new group.  After that, we’ll move the file and lock it down to the new group only.  If everything works as planned, the file should be accessible to root and the other 2 users but NOT accessible to your current user. You’ll need to be root for all of these commands (or use sudo for them). Since I have sudo and don’t want to continually type sudo, I used the command “sudo -s” and entered my root password to permanently log in as root in a terminal for the duration of this how-to. OK, Let’s get started:

[root@lostlap ~]$ useradd -m -g users -G audio,lp,optical,storage,video,wheel,games,power -s /bin/bash testuser1
[root@lostlap ~]$ useradd -m -g users -G audio,lp,optical,storage,video,wheel,games,power -s /bin/bash testuser2

The above commands will create two users that should be pretty close to your current logged in user (as far as group membership goes).  If the groups you’re adding the user to do not exist, you may get a warning that the groups don’t exist…no worries, just continue.  If the above commands don’t work on your system (I used Arch Linux to do this) then you can use the GUI elements to manage users and add a new one.  You won’t need to add them to any extra groups since we just need a basic user.  Next, let’s create our ‘control’ group.

[root@lostlap ~]$ groupadd testgroup

The above command creates the ‘testgroup’ group. Now let’s add the two users we created to this group.

[root@lostlap ~]$ gpasswd -a testuser1 testgroup
[root@lostlap ~]$ gpasswd -a testuser2 testgroup

The command above adds both our test users to the test group we created. Now we need to lock the file down so that only those users inside of ‘testgroup’ can access it. Since your current logged in user is NOT a member of ‘testgroup’ then you shouldn’t be able to access the file once we lock access to that group.

[root@lostlap ~]$ chgrp testgroup example.txt

The above command changes the group portion of file permission (discussed earlier) from a group your currently logged in user is a member of to our new group ‘testgroup’. We still need to change the owner of the file so a new terminal opened up as your current user won’t be the owner of example.txt.  To do this, let’s assign example.txt a new owner of Testuser2.

[root@lostlap ~]$ chown testuser2 example.txt

Now when you try to access the file example.txt you won’t be able to open it up as your standard user (root still will be able to access it) because you don’t have the permissions to do so. To test this, open up a new terminal (one where you are not root user) and use your favorite text editor and try to open up example.txt.

[devnet@lostlap ~]$ nano example.txt

Both testuser1 and testuser2 will be able to access example.txt because testuser2 owns the file and testuser1 is in the testgroup that has access to this file. However, your current logged in user will also have READ rights to it but will not be able to access it. Why? Let’s take a look at the permissions on example.txt

[devnet@lostlap ~]$ ls -l example.txt
-rw-r--r-- 1 testuser1 testgroup 8 2010-05-28 10:21 example.txt

Notice that the user, group, and other (1st, 2nd, and 3rd position of r,w,x – see the handy diagram I made above) have permissions assigned to them. The user can read and write to the file. The group can read it. Others can also read it. So let’s remove a permission to lock this file down. Go back to your root terminal that is open or ‘sudo -s’ to root again and do the following:

[root@lostlap ~]$ chmod o-r example.txt

Now go back to your user terminal and take a look at the file again:

[devnet@lostlap ~]$ ls -l example.txt
-rw-r----- 1 testuser1 testgroup 8 2010-05-28 10:21 example.txt

Once that has been accomplished, try and open the file with your favorite text editor as your currently logged in user (devnet for me):

[devnet@lostlap ~]$ nano example.txt

Your user now should get a permission denied error by nano (or whatever text editor you used to open it). This is how locking down files and directories works. It’s very granular as you can give read, write, and execute permissions to individual users, groups of users, and the general public. I’m sure most of you have seen permissions commands with 777 or 644 and you can use this as well (example, chmod 666 filename) but please remember you can always use the chmod ugo+rwx or ugo-rwx as a way to change the permissions as well. I liked using letters as opposed to the numbers because it made more sense to me…perhaps you’ll feel the same.

Hopefully you now have a general understanding how groups, users and permissions work and can appreciate how the complexity of it is also elegant at the same time. If you have questions, please fire away in the comments section. Corrections? Please let me know! Thanks for reading!

Linux File Permissions, Groups, and Users originally appeared on Yet Another Linux Blog on November 3, 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!

Do Package Managers Spoil Us? originally appeared on Yet Another Linux Blog on May 16, 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.

convert SMFPress.png -channel Alpha -threshold 80% -resize 120x120 thumbnail.gif

This did a quick, same-size conversion with little loss for me to display the thumbnail online.  For more information on the options I used and other options that I didn’t use, take a peek at the ImageMagick Online Help Page for convert.

Convert PNG to GIF via Command Line originally appeared on Yet Another Linux Blog on November 6, 2009.

On some distributions, the system-wide /etc/DIR_COLORS* files are removed or not present.  This results in no colors being given inside of a terminal when looking for color directories and filenames.  If you find yourself in this boat, try the following command to re-populate this setting:

devnet-> cd ~/
devnet-> dircolors -p >.dircolors

This should create a default profile for colors for your session if it hasn’t been done or was accidentally removed.  For more information on the dircolors command try ‘man dircolors’.  Please also note that dircolors command uses the environmental variable LS_COLORS to set your session.

For more information on LS_COLORS and how it pertains to the terminal/shell/cli/prompt, there are a few blog posts that do an excellent job explaining here, here and here.

Adding Color to Bash List Command Part II originally appeared on Yet Another Linux Blog on September 8, 2009.

devnet[~]$ cat ~/.bashrc
alias lll="ls -al --color"
alias ll="ls -l --color"
alias l='ls --color'<br />alias search='find . -name'
alias aterm="aterm -fg white -tr"
alias version='cat /etc/zenwalk-version'
alias dh='df -h'<br />export PS1='\u[\W]\$ '
export PAGER="most"<br />devnet[~]$

I don’t use those aliases much…others of you might do the ‘ll’ or ‘lll’ but it’s just not part of my routine.  So, I added in just after line 4 in the code above:

alias ls='ls --color'

You can do this a few different ways…with any command line editor like emacs, vi, or nano/pico. It’s really up to you. The easiest way for new users is to use a text editor:

devnet[~]$ mousepad ~/.bashrc

This will launch the mousepad text editor in XFCE. If you’re in Gnome, try gedit. If KDE, give kwrite a try. You should see something like the following window pop up for editing:

You should see in the picture above, I’ve added in the alias needed to make me comfortable.  After that, File >> Save.  You’re set!  Except, you may notice that when you type the command ‘ls’ there are no colors.  So what gives?  Well, we haven’t loaded our ./bashrc since we changed it.  You don’t have to logout and back in to get things to work though…you can do this right from the terminal:

devnet[~]$ exec bash

Now try giving the ‘ls’ command a try again and you should see that it is in color.  I know a lot of the more advanced Linux guys out there are probably saying, “why’d he waste a post on this!  It’s easy” and you’d be right for a majority of users out there…I hope that this post finds some new user out there that may be stuck for an answer on how to do this.  One final note on this as well: You will have to do this as the root user and change /root/.bashrc in order for your root user to also have color.  Thanks for reading!

Adding Color to Bash List Command originally appeared on Yet Another Linux Blog on June 5, 2009.

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!

Laptop Multimedia Keys and PCLinuxOS 2009 originally appeared on Yet Another Linux Blog on March 17, 2009.

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.

Force Firefox to Remember Initial Window Setting in KDE originally appeared on Yet Another Linux Blog on February 10, 2009.

This article is from 2006!  The information here may not be the most current.  You can visit an updated version here!

Doesn’t sound like anything new right?  Well, some people may not know of this method.

Normally, to host your own webpage you would need to spend around 7 bucks to purchase a domain.  Next you would need a hosting plan that usually runs around 3-15 dollars per month to serve up your web pages.

What most don’t realize is that you can skip these steps all together…you don’t need to get dedicated Windows or Linux Hosting (this blog is hosted on dedicated hosting…but started out in my apartment!) to serve pages up to your friends and family.  You absolutely do not need to get domain name services through a provider.  You can even host your own webserver using a dialup connection (that’s right…I said dialup) although. I don’t recommend it (but I’ve done it using 56.6kbps).

Why would you want to do this?  My reply…to stay connected to friends and family…perhaps throw up a gallery so that your grandparents can see pics of your new dog/car/tinfoil hat.  Sure, you could waste my time with MyWaste..er..space and be barraged daily by advertisers and solicitors…or you could roll your own web host, install a gallery or website, and provide media to your friends and family without costing yourself a dime.  That’s right, NO COST (except time spent getting it running).  Just remember, your website might not survive a digging or slashdotting if you run it yourself.  Keep that in mind  So without more chatter, let’s get to the meat and potatoes of things:

Do you cringe at the thought of buying a domain and putting up with the headache of trying to make sure your IP address is up to date with your domain?  Do you hate the 40 dollars you spend on DNS service each year to resolve your IP address to your hostname?  Read on and learn the the flat-broke-and-busted way of maintaining a fixed hostname for your IP…even if you have dialup.

I’ll divide this up into 2 sections.  The first will deal with Linux.  The second, Windows.  This is only something that I’ve found easy to do and the price is just right (it’s free).  The only thing that I recommend is a dedicated internet connection (cable, DSL) but even this is not necessary as dialup can be used.  I recommend that you use the Linux way of doing things since it is more secure and doesn’t require a restart every time you patch it.

*note: I’m assuming that you aren’t behind a firewall/proxy of any kind and that your ISP doesn’t block port 80 traffic.  If your ISP blocks port 80, see the appendix at the end of this article.

LINUX

No matter what version of Linux you run, chances are that you’ll be able to install the apache webserver.  This is good news as over half the websites of the world are run by the extremely efficient and speedy apache. I’m not going to address the specifics of how to set up your website…only how to get it a fixed address without buying a domain.  So, you have your pages dropped into your webservers public directory…good.  Now, how to resolve your IP…lets say it is…25.24.4.166 (for our example) and you want it to have a host.name.com to bind to.  Easy to resolve.  Go to http://www.no-ip.com/index.php and sign up.  You can get a site from noip that is like yourname.theirdomain.com/.net/.info.  They have cool names like sytes.net and servebeer.org…even workisboring.com

You’ll be able to choose your own top level name…for instance, Ithink.dnsiskinky.com could be your new domain name.  Next download a client from the download tab: https://www.no-ip.com/downloads.php


The linux client is a tar.gz source and is simple to install. Follow the instructions when installing.  You may have to install compilation tools (devel packages like GCC) to install the client.  You now are the proud owner of yoursite.theirsite.com and your IP will ALWAYS update (as long as noip.com is up) each time you log on/sign on/beam up or whatever it is you do.

How does this help you?  Well, if you’re like me, you have a dynamic IP address.  If you connect to the internet via cable, dialup, or dsl…you also have a dynamic IP address.  Dynamic means that it will change from time to time without warning.  So by binding yoursite.theirsite.com to your IP address…you don’t ever have to worry about what IP address you have anymore.  Instead, you’ll always be able to connect using yoursite.theirsite.com.  You can host a webserver using Apache and a virtual host (also known as a Virtual Private server or VPS Hosting) in this style as well (look for another how-to on this subject later) so that everyone can visit a shiny website at yoursite.theirsite.com.

WINDOWS

First you need a free and clear webserver since one is not included by default with windows. You can download Apache for this as well OR try the Abyss Webserver.

Interestingly enough, Abyss is also free!  I ran it while my linux machine was being worked on (bad hard disk…it was a Quantum 200MB drive from 1913…had to upgrade) and it worked just great off of Windows XP.  Download that puppy and install it.  Make sure you read all of the documentation and familiarize yourself with how Abyss does business.

The next step…getting a hostname… is even easier than the linux method because you don’t have to manually install the noip client…they have a windows installer.  Go to http://www.no-ip.com/index.php and sign up.  Choose the domain name you would like (see above examples in Linux section).  Next, download the noip client from the download tab: https://www.no-ip.com/downloads.php but this time choose the windows client.  From there, you’ll be able to install this with a simple double click.  Fill in all of your information (pretty self explanatory) and make sure that it will run with each time you sign on.  You’re set! Your IP will now resolve to the yourchoice.theirhostname.com

CONCLUSION

You don’t have to spend a dime to keep a domain bound to your IP.  This is perfect for the home user who just wants a gallery or homepage.  It’s even good for someone who has a weblog or enthusiast site.  I would not recommend this to anyone who has a business and wants to run a site.  Just remember that the best things in life are free.  Thanks open source!!!

PS: It’s always good form to put a link of the stuff you are using on your website to direct traffic back to your software provider.  When I used noip, I included a noip link on my mainpage and also an abyss webserver icon as well.  It’s just good form and some companies/software providers necessitate the use of their logo or a link on sites that use their software/code.  Just be a nice person and give a linkback to them.  Good luck! Have fun!

PSS: Also, please note that having hosted my own webserver for quite some time (circa 2001) I’ve found Linux and Apache as a combination to be more secure, faster, and more stable than any webserver I’ve hosted on the Windows Platform. I included information on Windows mainly to introduce you to the concept of free and open source software. If you thought getting a webserver for free was great, think about getting a whole operating system! Give it a try, you don’t even have to install it (use a Live CD).


APPENDIX

If your ISP blocks port 80 traffic, your webserver won’t work.  Before deciding that your ISP is blocking however, make sure your firewall has the appropriate rules to allow incoming traffic.  You can do a quick add to IPTABLES in the following manner:

iptables -A INPUT -p tcp --dport 80 -j ACCEPT

iptables -A INPUT -j DROP

If you’ve opened up the appropriate ports and things still don’t work, it will be safe to say that you’ve determined the ISP is blocking port 80.  How you can get around this conundrum is to switch the listening port on the webserver to a different one and redirect traffic there.

1. See how to do this for IIS Webservers
2. See how to do this for Apache Webservers (normally in /etc/apache2/httpd.conf but your distro may vary.)
3. See how to do this for Abyss Webservers

If you still have problems, drop me a line in the comments section.  I may not be able to answer all questions but I can most likely get you to a person/place/thing that can.  Have fun and thanks for reading!

This article was originally published on July 13, 2006 and has been updated and reposted.

Host Your Own Domain and Webserver originally appeared on Yet Another Linux Blog on December 13, 2008.