Are We Overworked?

First of all, if you’re looking for Linux, this posting isn’t about it. Sorry. Today, I’m feeling overworked, which has very little to do with my operating system of choice.

First, a brief little anecdote.

This morning my kids drug me out of bed just shy of 9 minutes before my alarm clock was suppose to ring. They were a little rambunctious, so we played a bit before I managed to divert them with breakfast so I could go take a shower. I was ready to go 15 minutes later. Showered, shaved, and dressed. Got the kids in the car was headed off to work. My kids unfortunate timing this morning led me to be a few minutes later than I usually am. I got my first call of the day while I was still in the car. Of course, I told them I’d take care of it as soon as I was in the office as I wasn’t able to take care of it from the car. Of course that’s not entirely true as I could have sshed to the server on my phone and taken care of it, but then I would have had to stop driving. I rolled into the office about a quarter to 8:00.

I planned lunch with my former boss (I’d been reassigned to another department due to some restructuring), but I ended up having to work on something that came up at the last minute, so I grabbed a frozen burrito out of the company fridge and ate at my desk. I finished up work tonight about 8:30 after resolving an issue with a stored proc.

After work, I went for a run. As an aside, I know that many people love to run. I hate it with a fire that burns brighter than a thousand suns. Literally. I do it because if I can force myself to run, there’s not much else in my life that I can’t force myself to do. Over the course of my run, I thought about an issue I’m having at work.

How stupid is this?

I make an OK salary, but it’s sure as heck not enough to warrant a 12 hour day. The thing is, this isn’t an unusual day for me. I’ve talked with other people who are in the same line of work as I am, and it’s not unusual for them either. I’m not the only one pulling this kind of stuff in my office. Not even close.

I was flipping through channels on my radio the other day, and I ran across (involuntarily) that old Dolly Parton song, “9 to 5″. That whole song is complaining about how rough that 9 to 5 job is, but the first thought that crossed my mind was, “Man, I wish I worked 9 to 5.”

What do you think? Are we working too hard, or am I just being a whiny loser? Let me know what you think down in the comments.

Fun with File Permissions – Part 4

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 

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.

Fun with File Permissions – Part 3

Welcome to back to Mike’s 4 Days of Extreme Geekery (yes, Geekery is a word I just made up)! On Day 1 we talked about traditional Unix file permissions. On Day 2 we talked about setfacl and getfacl. Today, I want to go over chattr and lsattr!

What these two commands do is pretty self explanitory. lsattr shows you the attributes currently on a file or directory, and chattr changes those attributes. You use either + or – to add or subtract attributes.

 mike@PreciseApex:~/mike/test$ lsattr mike
 -------------e- mike
 mike@PreciseApex:~/mike/test$ sudo chattr +i mike
 mike@PreciseApex:~/mike/test$ lsattr mike
 ----i--------e- mike

The first time I found about the file attributes in Linux, I thought right away, “Hey, this is kinda like DOS!” I know what you’re thinking, and trust me if I could kick my own ass for saying that, I would. It turns out that the file attributes in DOS/Windows suck compared to the Linux version (like most things in DOS/Windows when compared to their Linux counterparts). Quick comparison will show you that DOS/Windows has 5 attributes. They are:

 R: Read Only
 A: Archive
 S: System
 H: Hidden
 I: Index

What each of these attributes does is, well, who cares. We’re not talking about DOS/Windows. The Linux version of file attributes is significantly more advanced. Available file attributes are:

 A: The date of last access is not updated (only useful for reducing disk access on laptops)
 S: The file is synchronous, the records in the file are made immediately on the disc.
 a: The file can be opened in addition to writing
 c: The file is automatically compressed before writing to disk, and unpacked before playback.
 D: The case is synchronous (see:S)
 d: The file will not be saved by the dump
 I: Can not be fixed by chattr only listed by lsattr
 i: The file / directory can not be amended, deleted, renamed or linked symbolically, not even by root.
 j: Mount file system with "data=ordered" or "data=writeback", and files are written to the log before the file.
 s: When the file is destroyed, all data blocks are being released to zero.
 T: Usable from version 2.5.46 kernel.
 u: If the file is deleted, its content is saved, it allows the user to seek its restoration.
 E: Experimental, can detect an error of compression can not be fixed by chattr, but can be listed by lsattr
 X: Experimental shows that the raw data to a compressed file can be accessed directly.
 Z: Experimental, provides information on the status of a compressed file.

As you can see, there are quite a few more file attributes that do significantly more. Some of these are more interesting than others. I’m only going to touch on a few of them that I find interesting. Of course, consult your man page for more information on the others.

The +A attribute basically locks that last accessed time to what it’s currently set at. Set this attribute, and you’re fill will be frozen in time. No more accesses will be recorded.

A really interesting one is the +c. This is an on the fly compression. If you add the +c attribute to an empty directory, everything you write to that directory will be compressed as if you stuck it in a file using gzip9 compression. One odd thing about it is that ls -l doesn’t show a darn thing. You can’t see the compression. I’ve heard that you can see it with a du, but when I was playing around with it, I didn’t see that.

I have to say that my favorite is the +i. I’m not sure what the i stands for, but I’m going with “Immortal”.

mike@PreciseApex:~/mike/test$ lsattr mike
----i--------e- mike
mike@PreciseApex:~/mike/test$ rm mike
rm: remove write-protected regular empty file `mike'? y
rm: cannot remove `mike': Operation not permitted
mike@PreciseApex:~/mike/test$ sudo rm mike
rm: cannot remove `mike': Operation not permitted
mike@PreciseApex:~/mike/test$ sudo rm -f mike
rm: cannot remove `mike': Operation not permitted

With the +i attribute set, this file can not be deleted. Not by the owner, not by root, not by anybody. You have to be root (or equivalent) to set this attribute, so no messing with your admins on servers you don’t own, but still fun.

The last two kind of have to be taken together. +s and +u. If a file with the s attribute is deleted, the blocks where it lived are zeroed out and written to the disk. Bye bye file. Good luck retrieving that one. In contrast, the +u makes sure that the files information is saved just in case you want to undelete it later. +s and +u are opposites. Oddly, you can set both flags on a single file. Not sure what that would do. If you know, throw it into the comments.

That’s an extremely high level view of the file attributes in Linux. I could probably spend weeks on these two commands going over what they do, but I have the feeling that I’d probably lose most of you in that amount of time. Tomorrow, I’m going to take a look at sticky bits! Bound to be fun!

Fun with File Permissions – Part 2

Now, where were we? Oh yea, so the day before yesterday (I know I said I was going to do this daily, but the series finale of Eureka was on!) we covered what’s commonly thought of as the traditional Unix file permission. Permissions are applied using chmod, and can be seen as a -rwxrwxrwx at the front of the line after doing an ls -l.

OK, that’s all well, and good, but what do you do if you want to grant permissions to just a single person, or add different permissions to multiple groups? That’s where the crazy combo of setfacl and getfacl come in. I have a test file called “test”. If I do an ls -l on the file, I see these permissions:

-rw-r----- 1 mike users 0 Jul 15 22:35 test

So, this tells us that I’m the owner, and users is the group the file is assigned to (my group being the default). So, with these permissions, I can read and write to the file, anybody in the group users can read the file, and no one else can do anything with the file. Standard 640.

At this point, if I use one of our commands, the getfacl, I’ll see a little bit different information, but still basically the same:

# file: test
# owner: mike
# group: users

But what if I want to give my wife permissions to that file, but no one else in the group users. One possibility is that I could create a separate group with just my wife and I in it and assign that group rights, but then the users group loses rights to the file. The simple solution is to just add my wife using this command:

setfacl -m u:amy:rx test

If I do an ls -l after this command, there’s only one slight change to tell us that we’ve done anything.

-rw-r-----+ 1 mike users 0 Jul 15 22:35 test

You can see now that there’s a + after the standard -rwxrwxrwx. This is a good sign. It means that our command was successful. If you were to do the getfacl now, you’d see this:

# file: test
# owner: mike
# group: users

You can see now that the user “amy” has been added to the permissions of the file. If you were to do an ls -l command, you’d see that the group permissions would be replaced with the value in the “mask” field. This value reflects the last permissions applied to the file. A similar command can be used to add groups:

setfacl -m g:plex:rwx test

This gave full permissions to any users in the “plex” group. Now my getfacl looks like this:

# file: test
# owner: mike
# group: users

Through all of this, if I were to do an ls -l, the mask on that line would now show the permissions of the “plex” group, not the user “amy”.

-rw-rwx---+ 1 mike users 0 Jul 17 21:23 test

And if in the end, you decide that you would rather return to the standard -rwxrwxrwx Unix type permissions, it’s as easy as this:

setfacl -b file

After that command, the + is gone, and the getfacl returns to it’s defaults.

 -rw-r-----  1 mike users  0 Jul 17 21:23 test
# file: test
# owner: mike
# group: users

Really, this is just scratching the surface. There is so much more that you can do with this, but again, I’ve gone on too long. Tomorrow (probably), I’m going to cover lsattr and chattr, and the day after I want to take a look at sticky bits!

Fun with File Permissions – Part 1

First, a little side story. I like messing around with my Linux computer. I have fun just seeing what the operating system can do. I like to talk about what I find, probably because learning new things excites me. I get giddy when I find out something new about something that’s familiar. Unfortunately, in my house, no one cares but me. I sometimes try telling my wife about it, but to say she doesn’t care is an understatement. She doesn’t even pretend to pay attention when I’m talking any more.

I was playing around with Linux file permissions the other day. I’ve been using Linux on my personal desktop for over a decade, and I use it at work as a developer. I’ve never spent a lot of time where I was the one who administered a multi-user environment, so file permissions were always the basics for me. In my playing the other day, I found a whole bunch of new things that I never even knew existed, and since my wife would rather watch paint dry than hear me talk about file permissions in Linux, I’m turning to you.

I’m sure most people reading this post are familiar (at least superficially) with Linux file permissions. Simply doing an “ls -l” will show you the long listing format of the current directory. The very front of the line will show you the permissions of each file in the list. An example:


The top entry is a file, the second is a directory. Whether that file is a directory, link, or regular file is represented by the first character. – means that it’s a file, d that it’s a directory. Extremely simple. The next nine characters are broken down into three characters each representing the file’s permissions.

The first three characters are the owner’s rights, the second group of three is the Group’s rights, and the last group of three is the rights of everybody else.

What the example above shows us is that the owner of the file can read, write, and execute the file, the Group and the average user on the system only show execute rights. For the directory, the owner can read and write, but no one else can do anything at all.

These rights can be changed using the chmod command at the Linux command line. There’s a GUI to do this too, but I’m not going to deal with it right now because I really don’t feel like it. chmod uses a numeric combination to determine what rights to set. An example:

chmod 755 filename

This command give the file these rights:


Basically, it gives the owner full rights to read, write, and execute. Everybody else can read and execute, but no writing.

Maybe I should be embarrassed by this, but for years I didn’t understand what the 7s or 5s or whatever represented. It seemed like arbitrarily assigned values. I was wrong about that, and the way that those values are arrived at is really ingenious in it’s simplicity. Let’s count a little bit in Binary:

1 = 001 = --x
2 = 010 = -w-
3 = 011 = -wx
4 = 100 = r--
5 = 101 = r-x
6 = 110 = rw-
7 = 111 = rwx

See what I mean? Brilliant in its simplicity.

There’s so much more to go into, but I’ve already gotten fairly long winded about this tonight. There will be at least two more parts to this little adventure I’m on. Tomorrow I want to cover getfacl and setfacl, and the day after lsattr and chattr.

If there are any more subjects on file permissions that you’d like to see covered, please let me know in comments and we can add more days.

iFanatical Idiocy

A bit of a rant here.

I ran across this graphic on CounterNotions (I only bother to link because this guy has Apple so far up his rectum he’d probably sue me for copyright violation if I didn’t link to him).

This graphic is a perfect example of the thought process of many iFanatics I’ve run across. Ever wonder why so many of them think that Android is a copy of iOS?

For some reason, Windows/Microsoft is now the source of inspiration for anything that has grass. Apple is the source of inspiration for anything that has icons. Google can only be Search.

Does this  make any logical or technological sense? No, not even a little. Don’t even bother trying to tell them that.


Just wanted to make a quick note about the #boycottapple thing going on on Google+ and on Twitter. I’ve read several people saying that boycotting Apple is dumb, and that the real problem is with the patent system. To the people pointing out that the patent system is broken I have one thing to say.


We know this people. We’re not stupid. Here’s the issue though.

The patent system is broken for the entire software industry, so why isn’t anybody boycotting EA? Why isn’t anybody boycotting Adobe? Why isn’t anybody boycotting Attachmate?

The answer is easy. EA, Adobe, and Attachmate aren’t acting like assholes. Apple is. Apple is the one going “thermonuclear” on their competitors, and they’re the one using the broken patent system to do it.

Does the Software Patent system need to be fixed? I’d argue that it doesn’t need to be fixed so much as thrown out altogether, but I think we all agree that it’s broken. That’s not the point of the #boycottapple “movement” (if you will). The point is that Apple is being a bad player, and because of their behavior, they should be boycotted.

Android: Intent on Winning

I doubt many people were not aware of Apple’s latest announcements concerning iOS. Of course Apple again held their little party and pomped and circumstanced all over. This is to be expected. Pretty much any company making an announcement will do virtually the same thing. What concerns me is the reaction to these announcements in the media.

I ran across a comparison over on PCWorld.

First of all, the comparison itself is bogus. The author took only the features that Apple announced that were new about iOS, and compared other platforms to that list. This automatically gives iOS the upper hand. If I were to list the new features of Android or even Win7Phone and compare those to another platform, it’s going to appear as if the OSs being compared are falling short. Unfortunately, this is pretty normal behavior for PCWorld. There are quite a number of Apple fans on staff and they conceal it rather poorly, if they make an effort at all.

Second of all is the small portion of the chart that I pulled out and posted down below (headers left intact for ease of understanding).

See how the Facebook and Twitter integration for Android is listed as “3rd party apps only”? To me, this is implied inferiority from the creator of this chart. It screams “iOS does this better because it’s integrated and in Android it’s not!” This couldn’t be further from the truth.

Let’s get the easy stuff out of the way first. The chart is technically correct. Android doesn’t build Twitter or Facebook support directly into the Operating System. Instead it does something much better. Intents.

An intent in Android is a mechanism allowing for apps to communicate with each other. This includes the OS itself.

Using Intents, Android can create very similar functionality to what iOS users see when Apple integrates a service into the OS. Not being integrated is it’s greatest strength. This allows for Android to give integrated type functionality to any application installed on the device. Facebook, Twitter, Foursquare, LinkedIn, you name it.

Because the service isn’t integrated, the OS is a lot more versatile.

Allow me to propose a hypothetical. In the not very distant future, Apple trots out iOS6 on it’s new iPhone, complete with it’s neat and spiffy Facebook integration. Shortly after that, there’s a social revolution. A new player appears on the scene. Let’s call it MyFace. Because of several new and really cool features MyFace offers that Facebook doesn’t, users leave Facebook in droves. Facebook becomes a ghost town. iOS users are now finding this new Facebook integration almost entirely useless. Android users simply delete the Facebook app from their device and install the new and really shiny MyFace app. Intents allow for MyFace to be instantly integrated with the device. A year passes, and Apple finally gets around to updating their OS to implement MyFace, removing the now defunct Facebook, only to find that MyFace is old hat. It’s been replaced with a new service, SpaceBook. Android users simply remove MyFace from their device, install SpaceBook, and go on with their social lives. iOS users are stuck waiting, again.

Now, is this analogy plausible? Well, two new and dominating social networks over the course of a two years is pretty far fetched, but that’s not the point. With Android, it doesn’t matter how fast the industry changes. Android changes just as fast. Intents allow for that to happen. iOS is not nearly as agile. It’s slow and dependent on Apple to move it forward.

To often today I’m seeing journalists holding up one of Apple’s greatest weaknesses as if it were one of it’s greatest strengths. Make no mistake, iOS is a dinosaur. It just doesn’t know that it’s extinct yet.

iPhone and Galaxy S III – Not the Same

Just a quick note to the iFans out there that are claiming that Apple’s iPhone 4s and Samsung’s Galaxy S III look so much alike. Look again!

Keep in mind that the following statements actually came from a real message from an iFan.

Virtually all Android devices have 3 or 4 buttons on the bottom, yet Samsung made a single Home button in the middle and faded the 4 buttons so that the surface of the device closely resembles that of the iPhone.

No it doesn’t.

Almost all Android devices use USB, but Samsung made their connector to look virtually identical to that of Apple’s 30 pin cable.

No they didn’t.

To an extent devices are going to look similar. It’s the nature of the type of devices we have now. Perhaps separately these minor things wouldn’t be noticed. But combined they show a desire to tell potential customers that their devices are just the same.

These devices are not “just the same”. No amount of repeating Apple’s lies will make that true. Next time, try facts.

Looking Back…

My Dad was born in 1923. He was the 3rd child, and the oldest boy. He had one younger brother and two older sisters. He grew up in California and Washington States. He had jobs like being a hired hand in an apple orchard. I think he swept floors at one point. He wasn’t royalty by anyone’s standards. I’d say that his upbringing was pretty normal for the times.

I sometimes ask my Dad to tell me stories about when he was a kid. I get all sorts of crazy tales. Riding his bike down the biggest hill in town. Shocking people by hooking up a coil to the frame of his car and waiting for people to bump into it. Running away from home for a whole summer to work the next town down the road, only to come back home for school. All those stories bring a smile to his face. He rarely tells one without laughing.

The stories suddenly dry up around 1941. He would have been 18 years old at the time, and the Japanese bombed Pearl Harbor. On December 8th, the United States of America officially joined World War 2. It wasn’t long after that my Dad joined the Navy.

He and many of his friends. Not all of them made it back.

There are very few stories from that time of his life. I know he was stationed in the Philippines for at least part of his stint. I know he was on some of the naval aircraft that flew in combat during that time. I know he was on at least two aircraft that were shot down. He also was a aircraft mechanic for at least part of it. If he talks about these years, it’s rarely with a smile on his face. Quite often, he has to pause when he remembers a particular individual. More stories than not have tragic endings.

This year, my Dad will be 89 years old, and to this day those memories bring him sadness the likes of which I have never known, and hope never to understand.

What I do know is this. Tonight, when I tucked my own two sons into bed, warm, safe, and secure, I owe my Dad and thousands more individuals like him a debt of gratitude that can never be paid.

All I can do is say “Thank you” for all that you’ve given. Thank you for keeping my family safe and free. We don’t say it nearly enough.