I am a HUGE sci-fi fan. Having just finished the last book in the original Dune Series, Chapterhouse Dune I can now say without a doubt (not that I ever had any) that Frank Herbert is a phenomenal author and one of the greatest science fiction writers of all time. Not only does he seamlessly intermingle religion, politics, prophecy, technology, laws and governance, genetics, sociology and many many many more profound topics into one flawless epic, his writing style does so in a fashion that astounds. In some ways he is a mystery writer, not in the conventional "murder mystery", but one such that in each book, the reader is revealed subtle clues as to the plans and plots of various characters, as well as the profound underlying themes and lessons of the books. It is not until the very end of each book, almost always within the last 10-20 pages of the 400+ page volumes, do we finally discover the full plot in all its glory, and often Herbert's writing allows us to deduce the final conclusions just moments before it is revealed.
Chapterhouse Dune ends with several major cliffhangers. Unfortunately Herbert died before he could complete his saga (why does this always happen to the great authors, conspiracy anyone? ;-) ). His son and another author attempted to finish his works with prequels and finally two sequels wrapping up the original saga, but based on online reviews and past experiences w/ similar situations, I am choosing not to read the followups and leave the questions hanging like so. Overall while each book has its strengths and weaknesses Chapterhouse was one of the better ones, overall places so in the series:
- Heretics of Dune
- Chapterhouse Dune
- God Emperor of Dune
- Dune Messiah
- Children of Dune
Not that I dislike Children of Dune or anything, it just does not beat any of the others, especially Heretics of Dune whose insanely deep philosophical and political themes combined with an intense action packed conclusion make for one of the greatest science fiction novels of all time. Perhaps this ordering will change on another pass through the series. For now I'm onto a bit of Issac Asimov (who is legendary, but who I've never read anything by (beside the profound short story The Last Question - make sure you don't skip to the end! )) and Orson Scott Card.
So over the last week or so, I've been having a fun time learning all the subtle issues w/ autobuild as I try to setup a nightly build cycle for the oVirt team. Most of the issues stem from the fact that we're primarily developing on a non-master GIT branch and oVirt has quite a few dependencies which makes setting up a consistent build environment tricky. Not only that, but since I'm on a team working on an active project with lots of developers, I can't exactly commit autobuild.sh a million times trying to get it to work (more after the jump).
There are times every person discovers something simple that makes life so much easier that they wonder how they lived without it. SSHFS is a very simple and subtly-named utility that allows you to mount files systems via ssh. Since ssh supports the file system operations anyways, using sshfs is trivial, nothing has to be done on the server side, and the client merely needs to install sshfs (eg yum install sshfs) and run
sshfs user@hostname:/ mountpoint
Feel free to specify a different directory to mount, and make sure the user running sshfs is the owner of mointpoint. This can be done as many times as needed on any machine (eg they can be cascaded such that sshfs'ing into one machine provides filesystem access to many. And combined with simple symlinks and what not, editing files on a large number of machines, using local tools and editors is a cinch.
Earlier today I tried may unsuccessful attempts at installing Fedora 9 on an expiremental developer workstation that has alot of kinks. After upgrading the bios, I booted w/ the F9 live dvd only to find X would not start. I was able to get around this by running the liveinst command to start the installer from the command line, but alas every time I arrived at the "enter root password" screen my keyboard went kaput, and no longer responsed (moving it to another USB socket doesn't help, and since it works up to that point and with my laptop, I have a feeling its either a USB controller issue or more likely an issue w/ X running under the installer). To get around this I simply ran liveinst --text to run the installer in text mode, and had no problems installing after that. Good luck!
As I started to get back into lower level / compiled languages for work (starting to hack on libvirt) and personal side projects, I needed to more efficiently debug my applications and libraries, as printf's don't cut it and the command line gdb iterface was getting annoying (*gasp* I know, its a first, my desire to use a gui over the command line ;-] ). The Data Display Debugger (DDD) is a great frontend to GDB and is a cinch to use. Simply append "-g" to the gcc/g++ command you run to enable debugging output (or append "-g" to the "AM_CXXFLAGS" directive if using Automake) and then compile. Next you will have to run the generated executable (really a wrapper shell script which finalizes the compilation and linking process) at least once to generate the true binary (named lt-name in the .libs/ subdirectory). Use ddd to debug this executable by running ddd .libs/lt-name (ddd can be install via any major distro repo)
(more after the jump)
After a long, frustrating week of simple things that should be working, not, it is refreshing to have the reverse scenario happen. More specifically, before today I have never had a wireless card work on Linux right out of the box. Perhaps its a testiment to Linux's ever-increasing hardware support and strong developer community, or perhaps D-Link is to be given credit (though I doubt it; I used to have a D-Link wireless router and it was the worst possible device, quickly switched to the Linksys one I have no and never went back), but the D-Link WDA-1320 pci based WIFI card worked right out of the box. Thats right, no drivers to hunt down and install, no man pages to read, just plugged it in, used network manager to select my wireless network, specified my password, and whala! I was surfing.
I very much recommend this card to any Linux user who is looking for the simplest and most pain free wireless experience on Linux.
I love Linux but hate when things don't just 'work out of the box' (definitely not a Linux-only problem though). Well, recently I bought a PC off ebay to use for a media center I'm setting up and ran into some woes with the Ethernet card. I always expect wireless problems but it has been years since I had an issue with a wired network card. Alas, after quite a bit of Googling I found my answer ( here ) and figured I'd share it incase anyone else was wondering.
Dirvish is an easy to use backup system based on rsync. Having recently setup an external encrypted usb drive to store backups, mounted at /mnt/backup1, I setup backups for target directories on my local system using Dirvish (of course, if it were not in early development, I would use Snap but alas its too early to trust critical system operations to it). The entire process is fairly easy, there being two files which you need to modify, as well as creating a cron job to run dirvish daily. I'll keep it brief and simple here, use this great guide if you want more info. Before we begin, recognize a 'bank' is a directory where multiple vaults are stored. A 'vault' holds the configuration and the actual snapshots of the filesystem(s).
A few months back I wrote an article on how to create and access an encrypted hard drive in Linux. Recently I've been setting up a large external usb drive to store nightly backups and couldn't figure out how to load the unencrypted device /dev/mapper/enc from the encrypted device /dev/sda1 post-boot (eg the usb drive wasn't turned on until the computer was completely started up). Lo and behold the answer was right in front of me, in my very own article, eg. step 3 or running the cryptsetup command:
cryptsetup -c aes-cbc-plain -d /etc/enc-key create enc /dev/sda1
I was under the impression that this altered the drive somehow, but does not in any way, it merely loads the unencrypted partition, from which point the user can mount the filesystem. I suppose a warning should go here, because I presume its possible (tho I have not tried it) to load the encrypted partition with a different key and thus the unencrypted partition will be "illegible", eg. the computer thinking its just random data. Any reads or writes to it will most certainly destroy any stored, encrypted information.
Anywho, it took me a little while to figure this one out, so I figure it might be useful for anyone else in the same situation.