A while back, I started playing around with conky. It’s a really cool piece of software that lets you do some truly amazing things. It ties in tightly with lua, so if you’re familiar with it, you’re already a step ahead of me.

conky lets you add all sorts of information to your desktop. You can add processor monitors, heat monitors, uptime, disk utilization, network activity, the works. I’m not really particularly good at it, and I can still cobble something together that looks pretty nice (imho).

If you’ve got a couple minutes of free time and you really want to add some pop to your desktop, I’d suggest hitting The Google and digging up some information on conky. You’ll be happy that you did.

When I started using Linux back in the late 90s, I started out with FVWM95. It’s almost identical appearance to Windows 95 was very enticing to me. I was using Windows 95 most of the time, and the fact that Linux with FVWM95 was free was really cool. After FVWM95, I moved to Enlightenment with Gnome for the cool theming capabilities. Eventually the Enlightenment portion of Gnome faded away and I was just using Gnome.

I liked Gnome. Originally I was drawn to FVWM95 because it was so similar to Windows 95, but I liked Gnome because it wasn’t.

A desktop battle started between Gnome and KDE. I figured that if Gnome and KDE were competing, it was a good idea to try KDE as well, so I threw it on a computer and gave it a try.

The first time I tried KDE, I didn’t like it. That’s probably an understatement. Many people liked it, but to me, it was terrible. I ran back to Gnome pretty quickly. I’ve never really left Gnome since then. I’ve tried KDE probably a dozen times since that first time, but I never stuck with it. Every time I tried it, my initial dislike was only reinforced.

I’ve always loved the customizability of Linux. I love browsing the Desktop Screenshots on deviantART. There are some truly creative individuals there, and some of the things they do with Linux are amazing to look at.

What does that have to do with the story? I’m getting there, I promise.

One day, when I was browsing through the latest screenshots, something happened. I saw some of the really impressive screenshots were running software I didn’t recognize. After digging a little deeper, I discovered that they were running KDE. This surprised me quite a bit, but it inspired me to give KDE another shot.

I’m currently running Ubuntu 12.04 on my primary system, so I just dropped to the command line, fired up apt-get, and minutes later, KDE was installed. I fired up the new DE, and was greeted by a fairly unfamiliar environment. It took a little bit of getting used to, but after a few hours of use, I found that I was really enjoying using it.

Wait, what?

Yep, I was really enjoying using KDE. I liked the DE that I’d been virtually repulsed by for more than a decade.

I’ve noticed a few oddities with KDE installed on Ubuntu, mostly because I’m still using KDM as my login screen. To get a more full experience of KDE, I put Kubuntu 12.10 on a spare USB key, and booted my laptop with it. Of course, everything automatically detected and the laptop started with a full KDE experience.

Not only did I enjoy using it, it’s awesome. Unless something drastically changes in the next couple months, I expect I’ll rebuild my primary system to run on Kubuntu 13.04.

And we’re back for Day 4 of the Fun with File Permissions Nerdathon! On Day 1 we covered our standard DAC permissions. On Day 2 we covered getfacl and setfacl, and on Day 3 we covered lsattr and chattr. Today we’re going to close out our run by taking a quick look at the sticky bit!

I’ll admit right out of the gate that I know the least about the sticky bit than any of the other day’s topics. If you see something I get wrong, don’t hesitate to correct me in the comments. I’ll update the post with the correct information.

So stick bits really started out in Unix in the 70s. You can still find pictures of it with big hair and bell bottoms. The original idea was that it was meant to be used on executable files. When the bit was flipped, the executable file would stay resident in memory so that it could be quickly loaded again. There were issues with it, like when you had to update those executables, you had to remove the bit, upgrade the file, and then replace the bit.

The functionality evolved. Linux has never supported this implementation of sticky bits.

Today, sticky bits are used to protect files from being removed when you give another user full rights to the file. So, how does this thing work?

Setting the sticky bit is easy. You just use the chmod command just like you did back on Day 1:

chmod +t test

This will set the sticky bit on a file, or in my case directory. Doing an ls -al from inside the test directory you’ll see this:

mike@PreciseApex:~/test$ ls -al
total 28
drwxrwxr-t 2 mike mike 4096 Jul 20 20:15 .
drwxr--r-- 56 mike mike 16384 Jul 20 19:20 ..
-rwxrwxrwx 1 mike mike 0 Jul 20 20:15 file

In that directory, I’ve created a file called (originally), file. You can see that file has full read write execute privileges. You can also see the permissions on the . directory above oddly end with a “t” instead of an x or a – like you’d expect. That tells us that the sticky bit is active. If you were using the sticky bit on a file, a lowercase t would indicate that it’s not executable, and an uppercase T would indicate that it is.

So, let’s try to kill this file.

I login with my wife’s account (shhhhhhhh), and do an ls -al in the same directory:

amy@PreciseApex:/home/mike/test$ ls -al
total 28
drwxrwxr-t 2 mike mike 4096 Jul 20 20:15 .
drwxr--r-- 56 mike mike 16384 Jul 20 19:20 ..
-rwxrwxrwx 1 mike mike 0 Jul 20 20:15 file

Things look pretty much the same in this account. You can see the lowercase t on the end of the directory permissions, but other than that, it looks like I’ve got full rights to file. I can open that file, modify that file, and save that file. No problems, even from my wifes account. Where the sticky bit comes into play is when I try to delete the file. An rm -f results in:

amy@PreciseApex:/home/mike/test$ rm -f file 
rm: cannot remove `file': Permission denied

Dun dun dun. Permission denied. If I do the same command from my user?

mike@PreciseApex:~/test$ rm -f file 
mike@PreciseApex:~/test$

No errors. The sticky bit will allow the owner of a file, and root (or a user with equivalent rights) to remove the file. If you want to remove the sticky bit from a file, it’s as easy as:

chmod -t file

And so our four days of Fun with File Permissions come to an end. I had a great time writing about this. It seems on the surface like it would be such a dry subject, but there are so many fun intricacies that it’s so exciting to experiment with. Please, if I didn’t cover something that you could have liked to see me cover, please mention it in the comments.