Tried upgrading to OSX Yosemite. I should have suspected it was all part of the old Apple Planned Obsolescence Conspiracy:- Memory constraints on 4GB mid-2011 Macbook Air. Yosemite caches IO more aggressively, so you see memory "95% full". Theoretically this should actually help in most circumstances (since cached IO will gove way for the memory apps need to run), but everything seemed slower, especially Firefox, my most-used app.

- Fan ran at 100% all the time, any time an app was open, even when CPU was nowhere near 100%. Was it hogging the GPU? No way to tell. I did notice several "mdworker" (Spotlight indexing) processes running, probably reindexing everything for the first time. I killed them, but to little effect.

- Forcing one to hold down the power button for a few seconds to power off instead of sleep always leaves you wondering whether you did a graceful or forced shutdown. Lame.

- Lack of a real sidebar in iTunes is annoying and makes it harder to copy stuff from device to device. Others have bitterly complained about the new iTunes, although it didn't seem so awful to me.

- A few apps won't be compatible - check first.

- The rest is all eye candy. Hey, My laptop is not an iPhone.

So upgrade on older machines at your own risk. I restored with Command-R and Time Machine with zero trouble. I had some good books to read and laundry to do, so it wasn't a complete waste of time.

Bash updates have been available for Linux for nearly a week, but Apple is dragging their heels, or working on a more permanent bug fix. Despite their not-really-reassuring pronouncement that "only ninjas need to worry about this", you do need to worry about this under certain conditions:

- If you have a web server running on the Mac that uses mod_cgi and any cgi that runs bash or any script that uses the "system" or "exec" call without clearing out its environment. That's been bad programming practice for years. The fix: Disable mod_cgi. For Perl-heads, use "-wT".

- There is a DHCP client proof-of-concept, but my colleague Dr Chase tried it with Mavericks and it didn't work. Older DHCP clients might be vulnerable, but I've seen no proof yet.

Best bet - if you have a compiler installed, whether from Xcode or Ports, just rebuild bash. 4.3 has 26 patches you need to install, but it builds with no problems even on my ancient Darwin G4 running 10.5.8. Rename the existing bash and sh aside in /bin, put the compiled versions in their place, and you're done.

So I'm sleeping OK at night.

There are likely to be more patches to bash in the next few weeks as the problem that makes Shellshock possible is deeply entwined in the bash code. You will probably need to rebuild or patch bash, so save your work.

In my last job, I has a legacy Nvidia video card on one of my boxes, with two displays joined side to side. Occasionally this setup caused KDE4 to drop the side by side view and revert to a mirrored copy of one of the two displays. My stuff was still running, but hidden, and the KDE start menu was usually gone as well.

And, of course, I usually had some unsaved work in the hidden window. Fortunately, it's possible to restart the KDE randr config app from a shell, and this usually causes my display to regain its side by side configuration. You do this with:

kcmshell4 randr

Kcmshell4 can start a variety of apps and widgets. You can get a complete list of what's on your system with "kcmshell4 --list".

There is nothing wrong with your set: Why rsync is slow for large files

Monday, June 23, 2014, 03:50 PMPosted by wsanders

There's a lot of confusion and badly written questions and answers returned when you Google for "rsync incremental file transfer". Most of the babble is related to command-line fail when doing incremental backups of a directory tree. Of course "rsync -a" skips files that are unchanged between the source and destination. But that may not be what you mean by "incremental file transfer". What you might mean is - "why is rsync taking so long to transfer a large file that is unchanged except for a few lines." A good example is a log file that is getting appended to.

For this we have one of the great things about rsync: the "Tridgell Algorithm" (www.samba.org/~tridge/phd_thesis.pdf) Unless you specify otherwise, rsync will try to transfer only the parts of existing files that have changed since the last copy.

You might think this would speed up your large file transfer. But in today's world of fast networks and (usually) underpowered virtual hosts, it usually doesn't. The Tridgell Algorithm is CPU intensive, and rsync is single threaded (probably by necessity, since using multiple threads to access a single file sequentially would be rather pointless.)

Example: Times for copying a 4 1/2GB file over a fast network on a slow server:

So there you go, why you don't see much improvement from rsync's delta-transmission mode. THIS IS THE WAY IT IS SUPPOSED TO WORK. And the man page says as much:

-W, --whole-file With this option rsync’s delta-transfer algorithm is not used and the whole file is sent as-is instead. The transfer may be faster if this option is used when the bandwidth between the source and destination machines is higher than the bandwidth to disk (espe- cially when the “disk” is actually a networked filesystem). This is the default when both the source and destination are specified as local paths.