FreeBSD again

Figured it's been awhile since my last post...

FreeBSD occupied a wee 45 minutes of my time this afternoon - I did a bit of brute force hacking to get X up and running - that required identifying my core pointer (/dev/ums0) and then killing the moused process that caused X to report my core pointer as "busy." Of course I got none other than the famous twm for a window manager, so I ran over to /usr/ports and built fluxbox from x11-wm. That went ok, so I fired up X again and then launched fluxbox from one of the terminals provided. That didn't go so well, and I had to go to class... I'll update this post when I actually make some more progress.

(update 2007-09-20 18:30 PDT)
Well, I have concluded, after a bit more tinkering, that it is probably more worthwhile to just wipe that installation and begin again. One thing that triggered this thought is that the slices seem to have become corrupted - they are not fixed by a reboot, which itself does not even complete properly... then they do not mount properly when I bring the system up again.

I would like to run FreeBSD or PC-BSD simply for greater exposure to "alternative" operating systems (or perhaps the OS's that should be primary ones but are just obscured by that giant in Washington). Also, I would like to become familiar with administration of those systems, and to see for myself the beauty of BSD, as so many fans claim. In my experience, BSD has the aura of being a server-oriented OS, for speed and security.

Another comment to make, after having used BSD from the command-line only, is that certain utilities, like top, take different command-line parameters than their Linux counterparts. Just something to note...

Registered Linux User #370740 (http://counter.li.org)

rsync speedup

I was curious about this number that is given after an rsync operation completes. Looking online yielded no results, so I hope to be a result that people can refer to here. When rsync runs on a directory, it goes through and builds the file list, then transfers the difference. That's what makes it so brilliant. Because it built the file list of the entire directory, recursively, it knows the entire size of that directory and it also keeps track of how much data it actually transfers. The report may look something like this:

sent 4013337 bytes received 76 bytes 39934.46 bytes/sec
total size is 5171204259 speedup is 1288.48

rsync is telling you that it actually transferred 4013337 bytes (~4MB) from the local machine to the remote machine, and 76 bytes in the other direction. It gives you an average transfer rate, and then the big number, the size of the directory that was just synchronized - 5171204259 (~5GB). The speedup number represents the Total size divided by the total data transferred in both directions (TOTAL SIZE / (SENT + RECEIVED)) = SPEEDUP. This is better termed the "advantage" of using rsync, but the developers chose "speedup" and that's what we got. You could think of it as a ratio/multiplier, since a speedup of 1 would mean that you basically transferred the whole thing with no speedup, as opposed to that example operation, which transferred 1/1288 of the total data to make up the difference.

Registered Linux User #370740 (http://counter.li.org)