Archive for July 2012

Will Your Next PC Be a Google Nexus?

Will your next PC be a Google Nexus? A recent “ask maggie” column addressed the question, “Is Google headed toward an Android Nexus PC?” Her conclusion was “when Google challenges Microsoft or Apple on the traditional computing OS battlefield, it won’t likely be armed with Android.”

I disagree.

Where Android and ChromeOS are Today. It’s Competition Too.

Today, Android has taken the dominant position in smart phones, and the number two position in tablets. It’s advancing at a break neck speed, and has easily surpassed it’s only real competition. It’s spread to a significant number of other platforms, such as music players, car stereos, TVs, gaming systems, and even wrist watches and reality augmentation devices. No other operating system in history has done something like this.

ChromeOS has only just begun, and has seen amazing advances since it’s introduction. It started out as a glorified browser, and now has added application functionality and remote storage capability. It also has the ability to run applications through Citrix, making it a feasible stand-in for a Microsoft or Apple based operating system anywhere in the Enterprise market.

Windows has stagnated over the last decade, accomplishing very little of value considering the ten years it’s had to do it. A recent Vanity Fair piece referred to it as “Microsoft’s Lost Decade“. Windows got some flashier graphics in Vista and 7, and then traded them for a travesty of a user interface in Windows 8.

Apple hasn’t done much better on the desktop than Microsoft. OSX has added an App Store type interface, but other than some graphical changes, there’s no significant changes to OSX since it’s arrival in 2001.

Our desktop operating systems have stagnated. Improvements are measured in baby steps rather than leaps and bounds, if they’re improvements at all.

ChromeOS or Android? Where does Nexus Figure into this?

The question that has to be asked now is, why Android? It’s not even a desktop operating system. ChromeOS is. Shouldn’t it be ChromeOS that replaces Windows and OSX, not Android?

True, ChromeOS is the desktop operating system. Android has always taken it’s position on other kinds of systems, never the desktop.

It really comes back to why Google decided to do two different OSs to begin with, and what their plans were.

The Nexus Consolidation.

The thing that no one seems to be taking into consideration is Google’s plans. Maybe it’s because it’s not convenient, or maybe it’s just because their memories are short. We need to think back to 2009. In an interview with CNET, Sergey Brin was asked about ChromeOS and Android, and why the two seperate Operating Systems. His reply was that Android and the Chrome OS “will likely converge over time.” In fact, the two operating systems share a common Webkit and Linux foundation.

Today, we’ve already seen Google add the Chrome Browser to the Android operating system. Much of the ChromeOS functionality is already incorporated with Android Jellybean. All that remains is the right hardware to bring the two operating systems together.

This is where Nexus comes in.

Nexus systems are designed by Google to Google’s specifications. It could be that the first Nexus “PC” could be a hybrid device, similar to the Motorola Atrix or the ASUS PadFone. We’ve already seen such a hybrid type system with Ubuntu for Android. When in “phone mode”, it’s Android. When it’s docked, it becomes a more desktop type system. Google’s moves to combine the functionality of the two OSs would make a move like this easy. Both systems are already Linux. Both systems already have use WebKit. Both systems are already Google.

The Nexus Solution.

A Nexus based PC would solve any number of problems with the PC. Files would be stored in the cloud, making it infinitely more secure and easily backed up. Lost hardware could be shutdown and wiped from a distance. A dock at home and a dock at work would be all that’s required. Your pocket is your new laptop case. Any location with a dock is a your home workstation.

Google has already gotten themselves into a position to implement a consolidation of Android and ChromeOS. All that Google needs now is the hardware. This is why your next computer just might be a Nexus computer.

Tux: Modern Olympic Champion

Tux: Olympic ChampionThe Olympics are known throughout the world and have been going on for centuries. The first Olympic games were thought to have occurred in the sixth century BC, and it consisted of foot races only. It started as a race for young women to compete for the honor of being a priestess for the goddess, Hera. A second race was run for young men for the right to be a consort for the priestess.

A lot has happened since then.

This year, the Olympic games are being held in London, and champions from all over the world are attending in the hopes of taking home Olympic gold.

One champion there is nothing like the others, and you won’t see in any of the events. It’s Linux.

When the Olympic Games needed a server to host their web page, they chose to rely on the same server that anyone in the world can download free of charge. Linux. The web services are provided by Apache and PHP, the database by MySQL. Like other Olympic competitors, the demands placed on Linux will be high. The website will be responsible for distributing stats for all of the events, receiving their information and making it available to other organizations to broadcast. That includes the event video distribution organization. You know all that information you see on the bottom of your television screen during the broadcast? That will be coming from the Linux server.

Don’t be confused though. There were other runners in the race. The Olympics could have chosen a Microsoft Server, or a traditional Unix server. They could have run their DBs on MSSQL or Oracle, but they didn’t. They chose a LAMP server.

To me, this shows a great deal of faith in the Linux environment. The Olympics chose to use the same software you can download from the Internet free of charge for their mission critical needs, and the world is watching. If Linux stumbles, the world will see. If Linux runs it’s race with speed and grace (which I am pretty sure it will), it will be a great victory for Linux.

Here’s to Olympic Gold in 2012.

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.