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 15, 2015
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.
Subscribe to:
Posts (Atom)
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.