And of course they'll get a commission on any actual sales. This is the same drive for monetisation that lead network solutions to direct you to advertising laden search results instead of returning NXDOMAIN.

CRIME was about TLS and detecting the request. BREACH is about detecting something about the response, that could be in the header, or not.

The DEFLATE and gzip formats allows multiple blocks of compressed data as well as blocks containing literals with no compression. Plus, just because the default implementation always looks for duplicate strings, doesn't mean you always have to do so. While it would add a heck of a lot of complexity, it should be possible for a web server to ignore duplicates that occur in sensitive strings, and output them in literal blocks so that they don't effect the frequency data of the rest of the stream. All without requiring any changes to browser implementations. This is far from simple, but could probably be done in a generic way for well known http headers.

So web servers need to disable gzip & deflate compression on any https page that might contain something sensitive? Sounds like an easy enough fix to me.

To add more fuel, Simon Hacket's teardown of the FTTN approach. The guy who ran Internode, one of Australia's largest ISPs.

Labor's NBN is much better than the Liberal plan, but it's not a utopia. There are plenty of issues with the current design that could be simplified and improved.

Line 1: Whoosh.

An ISP should provide me the ability to send and receive IP packets, routed to and from other IP addresses on the globally route-able internet. Nothing more, nothing less.

If I'm not allowed to use a connection continuously at it's peak capacity, then write the exact limit in bandwidth terms into the contract. eg no more than X bandwidth Up/Down over period Y.

Don't like it? Don't run an ISP.

On a phone, I doubt the magnetic heading is accurate enough.

Any asset bubble behaves in exactly the same way as a ponzi scheme. People who get out before the inevitable crash can make a huge profit, funded by the people who are left holding the assets. Just because it's a shared delusion with many people separately promoting it and no evil mastermind to blame, doesn't change the fact that the income people believe they are earning only exists on paper.

The biggest compression gains for video involve improving motion compensation, which may raise the decoders memory requirements, and entropy coding. Entropy coding is implicitly single threaded, and the complexity of this process will impose a lower bound on the clock speed of your decoder. While the rest of the decoding process can be done in parallel with lower powered circuits.

That's just Archaeologists speaking. They don't believe anything unless they dug it out of the ground themselves.

If you join my mailing list and ask good questions that demonstrate knowledge that you have gained from your own research, I will gladly answer your questions.

If you submit a concise patch out of the blue to address a specific problem, I'll probably accept it.

The patches you submit should concisely tell a story that I can quickly read to understand both the problem and the solution. The biggest piece of advice I can give you, is to study and understand your source control tools. If we are communicating through email & patches, we need a common language.

But if you're still learning, it's probably going to take a number of iterations to get any patch right. You need to be prepared to throw away everything you've done and start over. You need to be persistent, you need to ask the right questions.

If you were employed as my subordinate, I would invest a considerable amount of my time in training you in the hope that your future productivity would pay back my investment with interest. If you want to work on an open source project, convince the maintainers that you have a similar commitment.

Sure, use RDP instead of X11. It gives a reasonable display, with minimal latency between the client and server, and reasonably minimal complexity. Now try bouncing your network connection off the moon. Did I really hit that button? It doesn't look like it has changed.

What you really want is a local process to animate the button push. But locking you into using a motif style X11 button limits future innovation. And what about other kinds of user feedback?

Web browsers have thrived for many types of applications, as they give you a standard(-ish) rendering engine, a standard way to talk to remote applications, with a small amount of scripting support. But you can't always fit a round peg into a square hole.

So why not allow a application to run some code in a sandbox, with resource limits, and remove all other restrictions.

What I'd like to see built as a replacement for X11's network abstractions, is a sandboxed VM running on top of the display server, passing arbitrary messages back and forth with the remote application.

For example, take the llvm based pNaCl sandbox that the google Chrome team are building. Expose wayland API's for updating and displaying window pixmaps, and receiving input.

Then you could port the widget libraries from a UI toolkit to run directly in this VM without imposing any limits to creativity and future innovation. Visual feedback for a drag operation or button push can then be animated immediately on the display, while a simple event message is sent back to the host application to trigger further processing.

Plus the application developer could implement arbitrary custom widgets and have the same low latency interaction with the user.

I'm not suggesting that the entire application should be run in this sandbox, but in some cases that may be acceptable too.