This is literally more than a decade overdue. The very first "sucks" site I ever heard of was none other than paypalsucks.com way back in the early 2000s, and even at that time it heavily documented this and many other issues with PayPal's service.
Yeah I think the lighting in the scenes that take place in Bilbo's home tends to look bad even in the 2D standard-def 24fps trailers you can find online. It really doesn't have anything to do with HFR.
From now on, frame rate will be just like aspect ratio: another choice for the filmmaker. Some movies will still be in 24fps, some will be 48fps (or some other value), and eventually some will probably be variable from scene to scene.
As for the Hobbit, I think HFR could certainly have used a better "ambassador" film. Maybe James Cameron (who has also talked about 48fps from time to time) will do a better job of it in his next movie.
I'm guessing you'll only see 48Khz employed for recordings of real events, like musical performances, that Cirque de Soleil film they're pushing just now, and lavish documentaries in exotic locations such as nature films.
People say the same things about the DEA and IRS quite frequently. (Short-sighted people also say it about things like NPR, NASA, and the EPA.) Complaining about government waste is one of the great American pastimes.
I think there is some "vocal minority" stuff going on here, particularly with regard to the look and feel of Google's app.
For starters, far from being "fluid", Google's app consistently has a much lower framerate when scrolling or adjusting zoom level than Apple's maps app. It never even approaches 60fps even when running on the latest hardware, whereas Apple's old (and new) map application has always been really good about this, even on old & low-end hardware. So I'm really confused as to what people are talking about when they say it's "fluid". Compared to what?
As for the UI, the way Google's search input bar is positioned actually results in more of the screen being wasted than Apple's standard search bar UI. Those little slivers of the map which stick out above and on the sides are too small to be useful, so what's the point? Just pin it to the top of the screen and make it standard height like all the other apps do, thus giving the maximum amount of contiguous real estate to the actual map itself. There is a reason why Apple does it the way they do, and it's not just for looks.
I have mixed feelings about the detail view being at the bottom. I understand the idea of one-handed operation and I appreciate what they're trying to do here -- optimize for the case of browsing search results with your thumb via a combination of horizontal and vertical swipes, however I'm dubious of the value of it since you still sometimes have to reach awkwardly across the screen for certain things. Not to mention the detail view takes up more real estate than necessary, much like the search bar. It also feels somewhat disconnected from the currently selected pin due to being at the bottom, which is a problem Apple doesn't have since they put the details directly on the annotation.
Oh and of course you cannot blink without this app bugging you to log in.
Exactly. That's another reason I felt the urge to leave, particularly if I was going to start a business. I didn't want to be influenced by the bad habits of the Valley and SF. It seemed unnecessary to touch on that in this particular blog post, but maybe in a future one.
> The NeXT and Rhapsody kernels used NetBSD as the basis for their BSD subsystem
NeXT started in the mid-80s (I first used a NeXT cube in 1988), and ceased to exist in 1996. NetBSD didn't exist until 1993...
[My impression is that NeXT for a long time used the same "non-server" version of Mach that was generally used at CMU at the time (BSD code originally derived from 4.3BSD still in the actual kernel, not as a separate subsystem).]
>My impression is that NeXT for a long time used the same "non-server" version of Mach that was generally used at CMU at the time (BSD code originally derived from 4.3BSD still in the actual kernel, not as a separate subsystem).
Right, NeXtStep was derived from Mach 2.5 which had a 4.3BSD emulation layer (still running in the kernel though) on a Mach "not yet a microkernel" (Mach transitioned to a full Microkernel in Mach 3.0 when the BSD emulation moved out from kernel to userspace). When it became OS X, the BSD emulation layer was updated to 4.4BSD (from FreeBSD) and the Mach part was updated to Mach 3.0. As an aside, Apple even experimented with a Linux Emulation Layer on top of a real Mach Microkernel (mklinux http://en.wikipedia.org/wiki/MkLinux) and as the work done in bringing this up actually was put into getting Mach upto 3.0 on xnu (along with the BSD update).
The other Unix which derived from Mach 2.5 was OSF/1->Digital UNIX->Tru64 UNIX.
> Not to mention that iPads don't really have any private browsing mode.
Safari on iOS certainly does have "private browsing". Just go to the Settings app and select "Safari" from the top level and it's the first setting under the "Privacy" (just below the "General" section). When it's enabled, the browser looks different to let you know -- the normally gray bezel UI becomes black. This has been a feature ever since iOS 5.0 was released in 2011.
I just tried Panopticlick both before and after enabling private browsing in Safari (Mac OS X) and the site identified the same number of identifiable pieces of information about me. So it looks like that has no effect.
Which sort of makes sense - the info it's looking at is basically the header info. Screen size, installed fonts, IP address, and so on. It's not relying on cookies, as cookies can't be seen/read across domains (you can't tell I'm an Amazon customer if I just visit you out of the blue).
CSS may color visited links red, but they hacked getComputedStyle to return the normal color instead. So, you can't tell if that link to Amazon you just created is visited or not.
And you can no longer set, for example, font-weight:bold for visited links, because that would change the size of the element, and they decided, unlike in the color case, that it would be too complicated to get all the APIs to lie about the new geometry.
Further proof: http://youtube.com/watch?v=WlsahuZ_4oM