convert original.jpeg -colorspace hsb -resize 1x1 txt:-
Credit goes to this guy: http://stackoverflow.com/questions/7935 ... brightness
However, the Python PIL package will do this for you, the results are only a teensy bit different and you can get extrema and RMS for each channel:
>>> from PIL import Image
>>> from PIL import ImageStat
>>> im = Image.open('/tmp/image.jpg')
>>> stat = ImageStat.Stat(im)
>>> print stat.mean
[92.87710129310345, 94.48407707910751, 82.74996830628804]
>>> print stat.rms
[114.97883849032031, 116.21534866014377, 107.79289136583212]
>>> print stat.extrema
[(0, 255), (0, 255), (0, 255)]
~$ convert /tmp/image.jpg -resize 1x1 txt:-
# ImageMagick pixel enumeration: 1,1,255,srgb
0,0: (91,92,80) #5B5C50 srgb(91,92,80)
Actually I'd go with Python, because all the cool kids use Python and shells are for old people.
[ view entry ] ( 256 views ) | permalink
iface wlan0 inet static
What did work was creating an /etc/rc3.d/adhoc script and calling iwconfig directly. This might save you a lot of time:
ifconfig wlan0 down
iwconfig wlan0 mode ad-hoc
iwconfig wlan0 channel 11
ifconfig wlan0 up
iwconfig wlan0 essid "Pi"
ifconfig wlan0 192.168.0.21 netmask 255.255.255.0
WLAN0 does go down every time the other side of the link gets lost due to a reboot, power cycle, or some other problem. I'm working on a way short of a brute-force restart daemon to fix that.
[ view entry ] ( 297 views ) | permalink
- 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.
[ view entry ] ( 360 views ) | permalink
- 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.
[ view entry ] ( 377 views ) | permalink
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 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 ] ( 389 views ) | permalink
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):
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
time rsync -Wva:
delta-transmission disabled for local transfer or --whole-file
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
There are even inconsequential differences for a small file:
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
delta-transmission disabled for local transfer or --whole-file
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
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:
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 ] ( 554 views ) | permalink