Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Imagination Technologies's MIPS group, in the past of other companies such as Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Thursday, October 15, 2015

Google Chrome browser shows corrupted content on Mac OS X – DisplayLink Support

Google Chrome browser shows corrupted content on Mac OS X – DisplayLink Support: "This issue is due to the browser attempting to use hardware acceleration functions not currently available on virtual screens."



I got bit by this bug - disabling hardware graphics acceleration in Chrome, but not elsewhere, fixed the problem, as recommended by DisplayLink.



I wonder why the DisplayLink cannot hook the acceleration calls, and report ion error when applied to their display?



But I also wonder why Chrome does not check the capabilities of the display.  Here, the problem is probably confusion, since some of my displays have acceleration, and some do not.   Heterogeneity - gotta love it!  



Q: why does MacOS expose use of accelerators to apps?





'via Blog this'

Thursday, October 08, 2015

OSX HFS+ case insensitive by default - a security bug waiting to happen

I was having problems installing cpanm modules on my MacBook.

Turns out I have had a script ~/bin/CC in my path since circa 1980. cc plus some pleasant defaults. It has worked from UNIX v6 through v7, Eunice, BSD 4.1, 4.2, 4.3, SVr4, Xenix, Gould UTX, Linux, cygwin... and it failed for the first time on MacOS, infinite recursion. 

I wondered if HFS+'s case insensitivity could be exploited for a security hole. Googling reveals that the problem has already been encountered article.gmane.org/gmane.linux.kernel/1853266itworld.com/article/2868393/… January 2015 Although fixed in Git, this is an exploit waiting to happen, for Mac users who have ever installed software from some other UNIX-like case-sensitive system. For that matter, it is probably a potential security hole for code ported from case sensitive iOS to Mac OS X.