Welcome to Kirsle.net!

Welcome to Kirsle.net! This is my personal homepage where I upload my software projects and other creative works, and it's where my web blog lives.

Unix Permissions on Folders

Unix permissions become somewhat of a tricky thing when they're applied to directories instead of files. This post should hopefully clear up any confusion about them (they had me pretty confused so I figured them out by trial-and-error).

On normal files, the permissions are pretty straightforward:

• Read allows you to read the contents of the file (i.e. open a text file in an editor, open an image in a viewer).
• Write allows you to write to a file (make changes and save it, copy a new file over top of an old one, etc.)
• Execute allows you to run the file as a program (for a binary or e.g. a Perl script).

On directories, the permissions get a bit trickier.

• Read allows you to list the contents of the directory to see the files inside. This is it. It doesn't implicitly allow you to read the contents of the files, or to descend into subdirectories. It only lists them.
• Write allows you to create new files in the directory or delete existing ones (even if the files belong to a different user, like root, that you wouldn't think you'd be able to delete). This only works if the Execute bit is also on.
• Execute allows you to interact with a file, or to traverse past the directory into a subdirectory (provided that subdirectory has permissions that allow you to do so). Basically, the Execute permission allows the permissions on the file or subdirectory to take effect. If the folder doesn't have Execute permissions, any attempt to do anything to a file or subdirectory is automatically denied.

So here's a breakdown of the different permission combinations and what they do for you:

• --- (000): No permissions. Can't open the folder, list its contents, or do anything with its contents.
• r-- (400): You can list the contents. You can't open the files, or descend into subdirectories. Can't create new files or write to existing ones.
• -w- (200): This is the same as ---, or, no permissions at all. The write permission is useless without Execute.
• --e (100): You can't list the contents of the folder, but if you know of a specific name of a file or subdirectory, you can interact with it (provided it has permissions that allow you to). You can cd into a subdirectory or read/write a file that has permissions for it. But no listing the directory's contents.
• rw- (600): Same as r--, you can list the contents but nothing more. The Write permission is useless without Execute.
• r-e (500): You can list the contents, access files (subject to their permissions), and descend into subdirectories (subject to their permissions). You can't create new files though.
• -we (300): This one is interesting. You can not list the contents of the directory, but you can interact with existing files (if you know their names in advance), and you can create new files in the directory and delete existing files. You can also descend into subdirectories.
• rwx (700): All permissions for the directory.

Firefox Nightly

If anyone's interested, I wrote a Perl script that downloads and installs Firefox Nightly on a Unix-like operating system.

By default, it installs the application into /opt/firefox-nightly, with a link to run it at /usr/bin/firefox-nightly. This way, it doesn't conflict with your already-installed version of Firefox. Furthermore, it will put a launcher item in your Applications/Internet menu.

You can get it from here: http://sh.kirsle.net/ffnightly

$ mkdir ~/bin
$ wget http://sh.kirsle.net/ffnightly -O bin/ffnightly
$ chmod +x bin/ffnightly
$ ffnightly

Gnome Predictions

I have a couple of rather cynical predictions about what new problems Gnome 3 could bring to Linux (or Fedora, in particular) that I feel like writing down here just so I can say "I told you so!" as I begrudgingly look into installing Arch Linux on all my computers at some point in the future.

• Obsoleting of the Gnome Sound Applet: this one seems very likely to happen within the next couple releases of Fedora. The gnome-sound-applet isn't very useful in the Gnome Shell desktop environment, because the Shell has its own built-in volume control icon on the top panel.

  The reason it's still around is probably just for the Gnome 3 fall-back desktop, where you get a two-panel layout similar to Gnome 2, which still has a decent system tray on the top panel. For Gnome 3 users without hardware acceleration, the gnome-sound-applet comes to the rescue to let these users continue adjusting their sound volume.

  But, with Gnome Shell software rendering coming in Fedora 17, the need to maintain the system tray sound applet will quickly vanish, since even Gnome 3 users without hardware acceleration will be seeing the same shell desktop with its own built-in sound applet. This sucks a lot for XFCE and other desktop users. One of my favorite things about the Gnome sound applet is the ability to increase the volume higher than 100%, which XFCE's clunky old sound mixer applet still can't do.

• Obsoleting of the Network Manager applet: I strongly hope not. But at the same time I could see this being something the Gnome developers would consider seriously. The argument would probably go a little something like this:

  "There are currently hacks in place in Gnome Shell that allows us to run the NetworkManager applet, but place its icon in the shell panel instead of the normal system tray. So, it makes sense to just program the NetworkManager to go directly to the Gnome panel instead, and no longer support the system tray version anymore. This is good for Gnome, and anybody using XFCE or some other desktop that will have objections to this change, well they can just switch to some other distro. We don't care."

  On this one, I hope I'm wrong. But due to Gnome's short-sightedness with some of their recent design decisions (ruining Zenity, anyone?) I wouldn't be shocked to see them come up with such an idea.

So, there they are. Obsoleting the sound applet? Very likely. The NetworkManager? I really don't know how likely they are to do this, but this would probably be the thing that finally pushes me to abandon Fedora entirely.

Turn off monitor from Linux CLI

I keep looking up this information and then losing track of it, so I'm posting it here for my own reference.

This command will turn off the monitor on a Linux box from the command line (sorta like what happens when you have your power saving options configured to do this automatically after a length of time):

xset dpms force off

The monitor turns off until you hit a keyboard button or move the mouse. With this info you could set up a keyboard shortcut to run this command and have something like a "lock screen button" on your netbook, to turn off the display on command and conserve battery life for a little bit longer than usual.

For a "lock screen button" that also locks the screen in addition to turning it off, a pair of commands like this may be handy:

xset dpms force off; xscreensaver-command --lock

Install Chromium OS Lime

This information is ridiculously hard to find on the Internet.

I was playing with Chromium OS using the Lime build provided by Hexxeh. The Lime build is the same as the Vanilla build (i.e. upstream Chromium source code built daily), but it has more driver support, and it's the only build that works with the wifi on my Dell Mini 9.

Getting it onto a flash drive and booting from it was easy enough just following the directions on Hexxeh's site, but actually installing it to the hard drive was a bit more difficult. It was hard to find any up-to-date information online; most bloggers were talking about Hexxeh's old "Flow" builds, so the instructions were outdated. When I specifically googled how to install the Lime build, I was still finding outdated instructions.

Everyone was saying that you just hit Ctrl-Alt-T to get a shell prompt, and run the install command. Not that easy. The only way I could get into any form of text mode was by hitting Ctrl-Alt-F2 (which I only knew to try because I'm a Linux user). But this got me into a text mode login prompt and it took me a while to figure out the right username/password combination.

The username is chronos and the password is facepunch. After that, I was stuck in a really primitive shell that doesn't support anything I'm used to (not even ls), so I went out on a limb and tried running the command bash (which got me into a more familiar Bash shell).

But the install command was no good in Bash -- it was running the GNU install command instead of the one to install Chromium to the disk. After some more tinkering, I found that if I ran crosh (Chrome shell) and then run the install command from there, it did what I want. So, I was finally able to install it to disk.

It didn't end up working out though. The system doesn't boot after installation. Oh well. But hopefully this blog post will help others find out how to install the darn thing.

tl;dr: here's how I figured out to install Chromium OS to disk:

1. Boot it from the USB drive.
2. Push Ctrl-Alt-F2 to get to the text mode login.
3. Log in as chronos / facepunch
4. Type crosh, hit enter.
5. Type install, hit enter.

Update (Mar 6): It turns out Dell has their own semi-official builds of Chromium OS for the Dell Mini 9 and 10v laptops. They can be downloaded from Dell's site here. I downloaded the Jan 3 2012 image. Following their instructions was easy enough, but I found a few differences that I'll note here:

• On the first boot from the USB, wifi drivers weren't installed, so I couldn't get past the first screen. Ctrl-Alt-T doesn't work here, so I had to use Ctrl-Alt-F2 to get to the text mode login prompt.
• The text mode log-on is chronos / dell1234 (the "dell" user didn't work). Then I was able to start bash and then execute /etc/install_wl.sh to install the wifi.
• On the second boot from USB, wifi worked and I went through the setup process. Once logged in, Ctrl-Alt-T works.

The install from Dell's image did the trick too, and I now have Chromium installed on the internal hard drive on my Dell Mini 9.

Interestingly, the UI of Dell's image looks different to the Lime and Vanilla builds. The Lime and Vanilla builds had what looked like a sort of primitive desktop (complete with a wallpaper), and the Chromium browser windows could be resized and moved around the screen. Where you'd expect the task bar to be on a Windows system, was what looked more like the Mac dock, with icons representing all your opened Chromium windows (plus a couple other icons, one that brings up a menu and one that has the Chromium icon and didn't appear to do anything).

Screenshots of UI differences:

Chromium Lime (and Vanilla)

Dell's Chromium build

Dell's build looks more like the Chrome OS I've always seen screenshots of, so I think maybe the Lime and Vanilla builds are customized a bit (or else it's just a super new UI change and Dell's January image isn't up-to-date enough).