One ongoing question kernel developers face is the best way to delete data so no one else can recover it. Typically there are simple tools to undelete files that are deleted accidentally, although some filesystems make this easier than others.
Alexander Holler wanted to make it much harder for anyone to recover deleted data. He didn't necessarily want to outwit the limitless resources of our governmental overlords, but he wanted to make data recovery harder for the average hostile attacker. The problem as he saw it was that filesystems often would not actually bother to delete data, so much as they would just decouple the data from the file and make that part of the disk available for use by other files. But the data would still be there, at least for a while, for anyone to recouple into a file again.
Alexander posted some patches to implement a new system call that first would overwrite all the data associated with a given file before making that disk space available for use by other files. Since the filesystem knew which blocks on the disk were associated with which files, he reasoned, zeroing out all relevant data would be a trivial operation.
There were various objections. Alan Cox pointed out that hard drives have become so smart these days that it's hard to know exactly what they're doing in response to a given command. As he put it, “If you zero a sector [the disk is] perfectly entitled to set a bit in a master index of zeroed sectors, and not bother actually zeroing the data at all.” Alan said that the disk simply had to accept user inputs and return the correct outputs, and everything happening behind the curtain was entirely up to the hardware manufacturer.
Russ Dill pointed out that a lot of user programs also made it more difficult to know exactly where a file's data was on disk. The vim program, for example, created temporary backup files, as did many other programs.
There was not much support for Alexander's patch. But I imagine the ability to delete files permanently will come up again at some point. For kernel features though, the goal always tends to be doing a thorough job that, in this case at least, would indeed outwit the government overlords' efforts to recover the data.
There's an ongoing debate about cgroups, between the group of people who want to implement cool features and the group of people who want to ensure security. The security people always win, but the debate is rarely simple, and sometimes a cool feature just needs to be rotated a little in order to match the security requirements.
For example, Aleksa Sarai wanted to add a cool and useful feature limiting the number of open processes allowed in a given virtual machine. This would prevent certain types of denial-of-service attacks. The problem, as pointed out by Tejun Heo, was that an open process limit doesn't correspond to any actual limit on a real system. And, there's a strong reluctance to put limits on anything that's not a true resource, like RAM, disk space, number of CPUs and so on.
On the other hand, as Austin Hemmelgarn said, process IDs (PIDs) were an actual limit on a real system, and Tejun agreed it might make sense to allow them to be limited within a cgroup. And because that could be used to limit the number of open processes, everyone could end up happy. But the feature had to be presented as limiting an actual system resource, rather than limiting a relatively arbitrary characteristic of a system.
The tracing system has been showing signs of outgrowing its infrastructure lately, and Steven Rostedt recently posted some patches to fix that. Up until now, the tracing directory used DebugFS. But as Steven said, tracing needed to create and remove directories, and DebugFS didn't support that. So, tracing had been using various hacks to get around it. Steven's solution was to create a new filesystem called TraceFS, specifically for the tracing system.
There were no major objections, but there were some technical obstacles to get past. In particular, Steven discovered that the perf system was hard-coded to assume that the tracing system used DebugFS, so that had to be fixed before TraceFS could go into the kernel.
Other issues came up; for example, Greg Kroah-Hartman suggested basing TraceFS on KernFS, and Steven considered that for a while. But it turned out that KernFS had a lot of cgroup-related complexity that TraceFS didn't need, and Al Viro remarked, “It's not a good model for anything, other than an anti-hard-drugs poster ('don't shoot that shit, or you might end up hallucinating this').” Ultimately, Steven decided against KernFS.
I've touted the awesomeness of Calibre in the past (www.linuxjournal.com/content/calibre-cloud). And although the Web-based calibre2opds still is an awesome way to access your eBook library, using a native Android app is even smoother. If you have your Calibre library on your local network, using Calibre Companion ($3.99 in the Google Play Store), your Android device connects to your library like a device connected via USB. It's possible to load books directly onto your device without syncing your entire collection into the cloud!
(Image from the Google Play Store)
I admittedly still use calibre2opds in combination with Dropbox to make my library accessible remotely. But, if you're concerned about your books being on the Web, Calibre Companion is a local network solution. Check it out today at https://play.google.com/store/apps/details?id=com.multipie.calibreandroid.
I personally like Google's Chrome interface. It's simple, fast, elegant and did I mention fast? Unfortunately, I don't like how locked down the Chrome OS is on a Chromebook, nor do I like its total dependence on Google. I also don't like the lack of ability to install Chrome easily on generic hardware. Thankfully, Budgie is here to help.
If you like the simplicity and speed of the Chrome interface, but want a full-blown system underneath that deceptively simple GUI, I urge you to give Budgie a try. You either can download the Evolve-OS (evolve-os.com), or just install the PPA into a standard Ubuntu system. I simply typed:
sudo apt-add-repository ppa:evolve-os/ppa sudo apt-get update sudo apt-get install budgie-desktop
Then log out, and when logging in, choose the Budgie desktop instead of Unity. You'll find a very Chrome-like interface but on top of a full-blown Linux system instead of Chrome! The preferences are fairly simplistic, but the entire interface is designed to get out of the way and let you work. Due to its blazing-fast speed and ease of use, the Budgie Desktop is this month's Editors' Choice. Give it a try today!
I love Bitcoin. Ever since I first discovered it in 2010 and mined thousands of them, I've been hooked on the technology, the concept and even the software. (Sadly, I sold most of those thousands of Bitcoin when they were less than a dollar. I'm still kicking myself.) One of the frustrations with using Bitcoin, however, is that the blockchain has gotten so large. It currently weighs in at a little less than 20GB, and it takes about a week to download the first time you do so. There are ways to jumpstart the download with a bootstrap file, but still, it's a huge undertaking to run the standard Bitcoin client.
Enter MultiBit.
Although it doesn't have the entire blockchain, MultiBit does have all of the security and encryption the standard Bitcoin client does. Because it reads the Bitcoin network in real time, it takes seconds to sync up as opposed to days. Sending and receiving Bitcoin with MultiBit is fast, efficient and secure. Oh, and it's open-source, multiplatform and under constant development! If you want to run a local Bitcoin client, but don't want to download the entire blockchain, check out MultiBit at multibit.org. (Also check out Electrum, a Python-based alternative at electrum.org.)
I currently have the flu. Not the “sorta queasy” stomach flu, but the full out Influenza with fever, aches and delirium-ridden nightmares. Bouts of crippling illness tend to be my only chance to play games. Thankfully, since I'm such a terrible gamer, being sick doesn't really hurt my skills very much!
Today I was playing Torchlight II from Runic Games. I realized it was just as simple for me to run this new, awesome game on Linux using Steam as it is for any Windows user. Thanks to the Humble Bundle sales, I have dozens and dozens of games that aren't cheesy knockoffs, but are actual versions of real games. I think Steam plays a big part in getting more and more games released for Linux, but whatever the reason, it's a great time to be a gamer in an open-source operating system!
The screenshot here is just a section of my past Humble Bundle game purchases. The Humble Bundle (which I've mentioned before) is a great way to get inexpensive games. When you add Steam, you have yet another way to play and buy games that work natively on your Linux system. If you're a gamer, or just have the flu, go download some games:
...than to understand Linux permissions! Honestly though, that's not really true. Linux permissions are simple and elegant, and once you understand them, they're easy to work with. Octal notation gets a little funky, but even that makes sense once you understand why it exists.
Users and Groups:
First I need to address that Linux does have ACL support for file and folder permissions. It's not how things work by default, however, and ACLs were added to address the fine controls needed for some situations. Most Linux systems rely on standard POSIX permissions. That's what I'm covering here.
Every file has an owner and a group membership. If you type ls -l, you'll see the owner and group on all the files and folders in your current directory. POSIX permissions allow you to control read, write and execute abilities for the user, group and a third set of users, “other”. Using those three aspects on three different sets of users allows for some fairly complex “who can do what” on a filesystem.
Figure 1 shows an example of what a file listing looks like. I've separated the different sections showing which fields are which. Note the first field is usually either a “d” or a “-”; the former appears on directories, and the latter appears on regular files. For files, the permissions make straightforward sense. If the “read” bit is turned on, it means that user (user, group or other) can read the contents of the file. If the “write” bit is set, it can be written to, and if the “execute” bit is set, the file can be executed. Execute bits are usually set on binary files or on scripts you want to run directly.
Figure 1. Example File Listing
On folders, the permissions work almost the same: read means the ability to see what files are in the folder, and write is the ability to save a file into the folder. Execute is a little less obvious. When the “execute” bit is set, it means the user or group can change into the directory. So the cd command will work as long as you have execute access to a folder.
Changing Permissions:
Although Linux systems usually come with fairly sane standards for what permissions files are created with, it's often necessary to change them. For that, you use the chmod tool. The format is to use:
chmod u+rw,g-r,o+rwx file.txt
Granted, that's a fairly complex example, but let's break it down. The letters before the + or - are u for user, g for group and o for other. Then you either add or take away (+ or -) whichever aspects you desire. It's not required to specify all three user definitions, and they can be lumped together like this:
chmod ugo+rw file.txt
It's also possible to leave “ugo” off if you want to change user, group and other at the same time. So the following examples all do the same thing:
chmod ugo-rw file.txt chmod -rw file.txt chmod u-rw,g-rw,o-rw file.txt
Although the “ugo” format is fairly robust, it's sometimes very complicated to craft the string of pluses and minuses to get the exact permissions string you want. That's where octal notation comes into play. It's a little more confusing, but far more convenient once understood.
Octal Notation:
In Figure 2, you can see I've shown the numeric value of each permission bit. By simply adding the numbers, it's possible to create any possibility of permissions with three numbers. Figure 3 shows a few examples of how those can be figured out.
Figure 2. Numeric Value of Each Permission Bit
Figure 3. Creating Permissions
So with octal notation, the following two chmod statements are functionally the same:
chmod ug+rw,ug-x,o+r,o-wx file.txt chmod 662 file.txt
Although it's not a requirement to use octal notation for setting permissions, it's usually the way it's done.
I urge you to play with chmod a bit until you get the results you expect when using octal notation. Then, just for fun, see if you can string together a bunch of pluses and minuses to get the same results!
Linux permissions are simple, elegant and allow for some very flexible file-sharing options on a filesystem. We use them most often when installing Web applications, because the Web server runs as a particular user, and that user (or group) needs to have access to the files it's attempting to serve.
If you want to be free, there is but one way; it is to guarantee an equally full measure of liberty to all your neighbors. There is no other.
—Charles Schurz
It's not the things we do in life that we regret on our death bed, it is the things we do not.
—Randy Pausch
Getting fired is nature's way to telling you that you had the wrong job in the first place.
—Hal Lancaster
Little by little, one travels far.
—J.R.R. Tolkien
You can't deny laughter. When it comes, it plops down in your favorite chair and stays as long as it wants.
—Stephen King