That is a good question.

My answer hovers between two choices, "not a lot" and "no idea". The reason for this is that the translation code should be generally rather straightforward. There is a bigger cost for buffer allocation and destruction, and a smaller cost with frame update.

Each time a buffer is created or destroyed, libhybris will need to do some internal bookkeeping to match the Wayland buffers with Android buffers. Some of the under-the-hood memory allocations may be more expensive than others, so I can't say where the bottlenecks will be. For frame updates, there should be little more than simply copying and re-associating geometry values and memory handles (basically integers), since the actual buffer holding the visual content is not touched.

At least that's how I understand it. I trust we'll get benchmarks eventually.

Phoronix article is quite low on information, and even the original post at http://mer-project.blogspot.fi/2013/04/wayland-utilizing-android-gpu-drivers.html assumes some technical knowledge of graphics stack. The basic idea is actually pretty simple. I'll try to break it down.

1. The SoC vendors are willing to target only Android
2. Android GPU drivers are built against Bionic libc
3. The GPU drivers talk to hardware, and expose themselves via EGL and GLESv2
4. EGL is basically a common API for GPU memory management, buffer (region of memory used for rendering) allocation and display updates
5. GLESv2 stands in for the functionality we commonly associate with OpenGL

6. GPU drivers form a combination of EGL and GLESv2 libraries, each GPU vendor providing their own

This is where libhybris comes into play. The GPU driver libraries don't work without Bionic libc - so libhybris, while running on top of regular linux (and thus [e]glibc), keeps a private Bionic libc open for the GPU drivers' use, and redirects all the EGL/GLESv2 calls to the GPU driver libraries. These libraries run in their own Bionic universe, and tell the actual display hardware what to do.

The new part about Wayland support is just a logical extension of the same behaviour. Wayland already depends on EGL for buffer management, so "all" it really needs is a native display handler. Now as it happens, the native Android display structure can be mapped to the Wayland-EGL display structure. It's not trivial, but it's certainly doable. Thanks to libhybris, the Wayland libraries see a correct native display type and operate on that, while the Android GPU libraries see their respective native display type and thus can drive the hardware as ever before. After all, it's still the SAME hardware regardless of what operating system we may be running. Registers are registers and memory is still memory. From the GPU drivers' point of view nothing has changed.

So what has happened? In addition to just redirecting graphics stack calls to Android drivers, we are now also translating the display subsystem between two somewhat different systems.

If all of the above sounds eerily familiar, you are correct. In networking this kind of design is called a proxy, or if we're talking about link layer, it would be a multi-protocol label switch. Logically there's not much difference.

Let me get this straight, so I know we're on the same page.

There is a major vulnerability in basically ALL Postgres installations in the world. That means it has not been introduced by any recent commits. The patch(es) are not yet public, and the repositories have been made non-public while the fix is in the works.

The fix is likely delayed somewhat by the occurrence of Easter holidays. Lots of people have taken extended weekends - probably a good number of Postgres devs included. There is probably no sane way to deploy the fixed versions until after the holidays. Not everyone can afford 24/7 admins.

And you want to complain about the developers being irresponsible when dealing with this?

(For the record: I'm pretty much a full-disclosure guy, but a slightly delayed disclosure with NO IN-THE-WILD EXPLOITS for a vulnerability that is discovered just ahead of a major holiday weekend... I can live with that.)

There was a pretty good write-up on the topic more than a year ago: Who killed videogames?

It's a long read, but most of the important points are made in the first page. The rest (sadly) qualifies for TL;DR - it simply rehashes and expands on the same ideas from different angles and in more depth.

Scott Adams nailed the tunnel-visioned focus on nothing but metrics.

'nuff said.

Why not offer two "phone gateways" for your support? One for customers with existing support contract, and another for those without.

For support contract line, have a robot switchboard system that requires a valid support contract code. All other callers would have to go through a premium rate number. Sure, it adds one extra step for customers who have contracts but they probably don't need to call you too often anyway.

Keep the distinctions clearly visible in your help screen. The premium rate probably discourages useless support calls, and those who perceive a need for more frequent support can easily crunch the numbers and decide which option they prefer.

Bit of background: Finland has pretty strict privacy laws, and compiling personal detail lists, such as this, is subject to regulation. Very few care about that. What really matters is that storing such lists has certain requirements - and disseminating them is explicitly unlawful.

The leaked list is apparently a compilation of 10 (or more) smaller lists. Criminal Bureau are going after the person who compiled and published the list, and the morons who compiled the original lists will probably get off with less than a slap on their wrists.

The original compilations have been passed around via mailing lists. I'll let that sink in.

[Puts on the cynic hat]
What should be a wake-up call to enforce the collection and dissemination rules will be used to drum up the threat of Anonymous and increased possibility to get spammed. The real problem, namely the near-criminal negligence with which this type of data is handled, will be ignored.

In a nutshell: someone who had access to multiple lists exposed a systematic indifference to privacy laws and the utter ignorance of decent practices. The leak itself will be vilified, while the practices which allowed this to happen with such trivial effort are unlikely to be addressed.