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.

Branch the source code!

You should *always* have a stable base version that can be released at a moments notice. Each feature should be developed and tested on a branch. If the feature isn't "done", it isn't merged. If you discover a bug after merging you back it out again and review how you missed it.

Pausing development of the current set of half-finished features so you can shift priorities onto something else, should be as simple as creating a new branch and ignoring the others until your next sprint.

... which works for local communications even when the internet itself is down. Importantly, this is an application that already exists. Plus everything we're doing is open source and we'll never lock any features behind a paywall.

I've been working on Serval's software for a couple of years now building the core feature set; encrypted calling and messaging, distributed phone number lookups, file distribution, software updates and installs in the field...

But since we're initially targeting android phones, we're stuck with the range limitations of Wi-Fi. So we're trying to fund the design and manufacture of a pocket sized device with much longer range (totally shameless plug).

There's still a few missing features in our software that we'll need to finish before we call it version 1.0. But with a enough funding I could easily build a P2P directory to provide services across the internet. With no centrally controlled servers at all.

Looks like the fix they have applied will cause java.lang.zip.ZipFile to throw a ZipException, indicating a format error, whenever it encounters a duplicate entry in *any* zip file, for *any* application using android's dalvik JVM.

I'm not certain that's the correct response to this issue. Should a zip file with duplicate entries always be considered invalid?

Add your exploit code to an existing apk without removing the original items, creating a zip file with duplicate entries. The original files match the signature, the duplicates are executed after installing.