πfs – the data-free filesystem!
πfs is a revolutionary new file system that, instead of wasting space storing your data on your hard drive, stores your data in π! You’ll never run out of space again – π holds every file that could possibly exist! They said 100% compression was impossible? You’re looking at it!
Linux Weekly News notifies:
At the June 8 meeting of the Fedora engineering steering committee (FESCo), the group decided that Fedora 16 will ship with Btrfs as its default filesystem. Btrfs is a relatively new copy-on-write filesystem with many interesting features such as read-only and writeable snapshots, multiple device support for RAID, online filesystem defragmentation, and more, though it is still marked as experimental in the kernel. “AGREED: Feature is approved. Will add some base critera to the page to be met by feature freeze. This is just a swap of ext4 to btrfs for default, not change of lvm or other parts of default.“
As noted in the comments, Btrfs is marked as an experimental feature in the kernel. As also noted in the comments, many other features which were marked as experimental were brought into production and that seemed to work fine.
While I personally have no knowledge of Btrfs stability or readiness for production, I am slightly worried by that move. First of all, ext4 – current default filesystem – works fine for me and for everyone I know. Why fixing something that works? It seems that Btrfs is a better choice for server platforms. And while Fedora is mostly used on the desktop, it is still a testing platform for Red Hat distribution which is, in fact, a server-oriented line of products.
On another note, Fedora 15 upgrade was a bumpy ride. Again, not just for me, but for everyone I know. Switch to Gnome3, sysctl, and other changes didn’t quite work out of the box for many people. Btrfs might do the same. I think it’s better to push such a change at least to Fedora 17. Let people recover slightly. Focus instead on fixing things which are broken. Let people regain confidence in Fedora distribution and its upgrade paths. Please.
I came across this blog post which praises text modes for /bin/chmod.
There are two ways you can change file permissions in Unix – one is using
chmod‘s symbolic (text) modes (likechmod ug+x file), the other is using the octal modes (likechmod 0660 file). It turns out that symbolic modes are more powerful because you can mask out the permission bits you want to change! Octal permission modes are absolute and can’t be used to change individual bits. Octal modes are also sometimes called absolute because of that.
I have to agree, they are superior. However I feel like the article needs more examples. So here we go.
Use “u” for user, “g” for group, “o” for others, and “a” for all, or you can use a combination of letters, similar to how you do for access rights:
$ chmod ug+rw *.php
This will make all .php files in current directory readable and writable by both user and group.
Use several permission changes within one command. Just separate them by comma.
$ chmod a-rwx,ug+rw,o+r *.php
The above will reset permissions on all .php files to readable by all and writable only by user and group.
And my favorite and most used example, which would be tricky with octal permissions is the “X”. In recursive change mode, “X” will affect executable bit only on directories. Difference by illustration:
$ chmod -R a+x /some/path
The above will add executable bit to all files and folders under /some/path.
$ chmod -R a+X /some/path
But the above will add executable bit only to folders under /some/path. The files will remain as they are.
Here is a productivity tip from the you-don’t-want-to-do-this department:
You don’t want to wait for a filesystem check to finish, when it’s working on a 200 GByte partition.
Hopefully, this tip explains the 5-hour downtime that the server experienced from today’s morning and until now.
As you might know, podcasts are like radio shows recorded and distributed digitally (read: mp3 and RSS). Since pretty much anyone can record a show and distribute it over the Internet – everyone and their brother do that.
The file sizes of some podcasts are huge. There are shows that last for more than an hour and include pieces of music and stereo special effects. I’ve seen this eat up more than 50 MBytes each.
Since I only have a 128 MByte memory card (and about 20 of those MBytes are eaten by software intallations and other data), I was looking at ways to minimize the file sizes of the podcasts that I wanted to listen to.
Continue reading castogg.sh – make podcasts smaller