Linux is my primary operating system. I used it on the servers, desktops, laptops, netbooks, and even mobile phones since approximately 1997. I’ve tried a number of distributions over the years, and even created a couple myself. I still look around sometimes to see what others are up to. But most of my machines are running some sort of Red Hat – either a quick and easy Fedora Linux, or a stable and secure Red Hat Enterprise Server, or a cheaper CentOS alternative.
And while by now I am very comfortable in the Linux environment (both graphical and command line), I still discover a lot of new and interesting things about it. When I come across something worthy, I usually share it with the rest of the Open Software world, using this category.
Here is a brilliant passage from an article “Too Smart for Git“:
Git follows Linux’s philosophy of refusing to protect you from yourself. Much like Linux, Git will sit back and watch you f*ck your sh*t right up, and then laugh at you as you try to get your world back to a state where up is up and down is down. As far as source control goes, not a lot of people are used to this kind of free love.
Excellent!
Via this rant, I learned about this report, which shows who contributes the most to the Gnome project. I knew that Red Hat was doing a lot of Gnome, but I never knew how much it actually was.
Red Hat are the biggest contributor to the GNOME project and its core dependencies. Red Hat employees have made almost 17% of all commits we measured, and 11 of the top 20 GNOME committers of all time are current or past Red Hat employees. Novell and Collabora are also on the podium.
Way to go, Red Hat!
Once in a while there is a need to see the tree of processes on a Linux system. When such a need arises, I usually run “ps auxw –forest“, which results in something like this (partial output, top only):
Today, via this blog post, I’ve learned that there is another way – “pstree“. This command accepts a number of parameters, but in its simplest form, results in something like this (partial output, top only):
On my Fedora box, /usr/bin/pstree is a part of the psmisc RPM, which is the one that brings /usr/bin/killall to the system.
I was going through Fedora Planet stream when I noticed this blog post about converting Flac files to mp3 on Linux. That reminded me of a couple of folders with files that I can’t listen to in my car. So I thought I’d convert them now, especially that I have the guide handy it only consists of a couple of steps. I tried and it worked, except that default options used resulted in the mp3 file of 128 kbps, which is a rather low quality. So I played a bit with it and ended up with the following shell flac2mp3.sh script:
#!/bin/bash
# Convert flac file to mp3 with best quality VBR
for file in *.flac
do
base=`basename "$file" .flac`
# Convert flat to wav
flac -d "$file"
# Convert wav to mp3 with variable bit rate, best quality
lame -V 0 "$base".wav "$base".mp3
done
As mentioned in the comments, it creates variable bit rate (VBR) mp3 files with maximum quality.
Update: The moment I finished this blog post I felt weird. It was almost like I did it before. And indeed. I should have searched my own blog before posting. Here is the post I did five years ago which has pretty much the same script in it.
While investigating an unrelated issue on our backup server, I came across an interesting discussion about gzip vs. bzip2. I was surprised to read on how much slower bzip2 is. I even tested it on our server. And as expected, I saw the huge difference.
$ du -sh home 819M home $ time tar czf test.tar.gz home real 3m29.741s user 1m4.026s sys 0m5.629s $ time tar cjf test.tar.bz2 home real 11m38.751s user 6m19.259s sys 0m7.237s $ ll test.tar* -rw-r--r-- 1 leonid users 365987716 2010-06-29 13:08 test.tar.bz2 -rw-r--r-- 1 leonid users 390655750 2010-06-29 12:56 test.tar.gz
For such a small difference in size, the compression time difference is huge! Of course, I should play with more parameters, repeat the tests several times, and test the decompression time too. But the above test is still a good indication. Way too many scripts out there use the default parameters and substitute gzip with gzip2 without any testing. That’s obviously asking for trouble.