OSX Yosemite Fail 
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, which theoretically should help, 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, 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.

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

- The rest is all eye candy. Basically, 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.

[ view entry ] ( 3 views )   |  permalink
Fixing Shellshock / Bashhole on Macs 
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 the 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.

[ view entry ] ( 62 views )   |  permalink
Starting KDE4 Settings from the Command Line  
I have an legacy Nvidia video card on one of my boxes, with two displays joined side to side. Occasionally this setup will case KDE4 to drop the side by side view and revert to a mirrored copy of one of the two displays. My stuff is still running, but hidden, and the KDE start menu is usually gone as well.

And, of course, I usually have 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".


[ view entry ] ( 119 views )   |  permalink
There is nothing wrong with your set: Why rsync is slow for large files 
There's a lot of confusion and badly written questions 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:

time rsync -va (etc):
delta-transmission enabled
4763951706 100% 125.50MB/s 0:00:36 (xfer#1, to-check=0/1)
total: matches=69025 hash_hits=103974 false_alarms=0 data=130595
sent 552238 bytes received 406893 bytes 8093.93 bytes/sec
total size is 4763951706 speedup is 4966.95
real 1m58.382s
user 0m38.945s
sys 0m11.891s

time rsync -Wva:
delta-transmission disabled for local transfer or --whole-file
native_stderr.log
4763965456 100% 56.92MB/s 0:01:19 (xfer#1, to-check=0/1)
total: matches=0 hash_hits=0 false_alarms=0 data=4763965456
sent 30 bytes received 4764547173 bytes 50418488.92 bytes/sec
total size is 4763965456 speedup is 1.00
real 1m33.719s
user 0m46.032s
sys 0m26.128s

There are even inconsequential differences for a small file:

rsync -va:
delta-transmission enabled
1059189 100% 202.02MB/s 0:00:00 (xfer#1, to-check=0/1)
total: matches=1034 hash_hits=1038 false_alarms=0 data=373
sent 6240 bytes received 4679 bytes 7279.33 bytes/sec
total size is 1059189 speedup is 97.00
real 0m0.290s
user 0m0.044s
sys 0m0.013s

rsync -Wva:
delta-transmission disabled for local transfer or --whole-file
trace.log
1066221 100% 48.42MB/s 0:00:00 (xfer#1, to-check=0/1)
total: matches=0 hash_hits=0 false_alarms=0 data=1066221
sent 30 bytes received 1066517 bytes 711031.33 bytes/sec
total size is 1066221 speedup is 1.00
real 0m0.246s
user 0m0.042s
sys 0m0.022s

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.

So, we love Tridgell's Algorithm, but is isn't always faster.


[ view entry ] ( 312 views )   |  permalink
Welcome "Pinkpi", a Raspberry Pi Wireless AP 
Wow, that was easy: http://learn.adafruit.com/setting-up-a- ... cess-point

I didn't have to specify a driver in hostapd.conf because Raspbian 7 knows about the Wifi dongle already (RT5370) and although Ladyada suggests rebuilding hostapd the v1.0 that comes with the distro seems to work.

That USB dongle is a $9 Ebay-crap winmodem that I hope to get working. So I can take Pinkpi on trips to the backs of beyond that don't have intenetz, only dialup.

[UPDATE: There is no hope of getting a winmodem working on a Pi, unless you know how to write codecs. The various "linmodem" projects are highly dependent on the X86 architecture. If you want a winmodem really cheap, let me know, this one is useless. Pppd does work on a Pi, if you have a modem that talks serial. You can use a serial USB dongle, or, for the more adventurous, the Pi GPIO pins.

[ view entry ] ( 817 views )   |  permalink
Parted Is a Time Machine 
The rules for making new filesystems are only getting more complicated in RHEL/Centos 6. It's like going back in time to 1990...

[ view entry ] ( 508 views )   |  permalink

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | Next> Last>>