Brief items

Note that these prices are for offensive uses of the exploit. Zerodium -- and others -- sell exploits to companies who make surveillance tools and cyber-weapons for governments. Many companies have bug bounty programs for those who want the exploit used for defensive purposes -- i.e., fixed -- but they pay orders of magnitude less. This is a problem.

Of course, these solutions highlight the tricky nature of GCHQ’s proposal. Note that in order to take advantage of existing vulnerabilities, GCHQ is going to have to require that providers change their system. And of course, once you’ve opened the door to forcing providers to change their system, why stop with small changes? What stops the UK government from, say, taking things a step farther, and using the force of law to compel providers not to harden their systems against this type of attack?

Which brings us to the real problem with the GCHQ proposal. As far as I can see, there are two likely outcomes. In the first, providers rapidly harden their system — which is good! — and in the process kill off the vulnerabilities that make GCHQ’s proposal viable (which is bad, at least for GCHQ). The more interest that governments express towards the proposal, the more likely this first outcome is. In the second outcome, the UK government, perhaps along with other governments, solve this problem by forcing the providers to keep their systems vulnerable. This second outcome is what I worry about.

Malicious apps hosted in the Google Play market are trying a clever trick to avoid detection—they monitor the motion-sensor input of an infected device before installing a powerful banking trojan to make sure it doesn’t load on emulators researchers use to detect attacks.

I've been telling kernel developers for years that if they have a test code they used when developing a kernel feature that they should share it with us (LTP community) and we will turn these into automated tests and maintain them for free. LTP is also used in many QA departments around the word so such tests will end up executed in different environments also for free. Sadly this does not happen much and there are only few exceptions so far. But maybe I wasn't shouting loudly enough.

Perhaps I have a tinted view at this point, but I think Fedora has to outgrown the Change process. At the very least, turn it into something that is far less rubber-stampy and more coordinated and planned. Things like the yearly GCC rebase should be fundamental requirements that drive other actions, not something that has to be remembered to be filed in on a wiki every year as if we suddenly would stop doing that if the page didn't get created one time. E.g. we know we'll update GCC in a similar window of time year to year, so if we know that then perhaps we can use it to start articulating what a Fedora Platform really means. Perhaps we use that to drive a lifecycle for a particular ring/platform/whatever that other applications can build and rely on.

I happened to sit in on two talks today that had pieces that resonated with me around affecting change, and how we tell ourselves we work in some particular way but in reality we are doing something else. We keep circling around a lot of things in Fedora that we want to investigate or change or improve, but then we continue to do the same things day in and day out. Perhaps instead of looking for completely new ways to do things, we can look at what we *really* do and not what we tell ourselves we do, and correct or build from those things towards what we want.

To be clear, KDE is a wonderful piece of software and my first recommendation to most non-technical computer users who ask me for advice on using Linux. But software often grows to use the hardware you give it. Software developers tend to be computer enthusiasts, and use enthusiast-grade hardware. In reality, this high-end hardware isn’t really necessary for most applications outside of video encoding, machine learning, and a few other domains.

[...]

My 11-year-old laptop can compile the Linux kernel from scratch in 20 minutes, and it can play 1080p video in real-time. That’s all I need!

One of the more pernicious myths about language design is that if something surprises a beginner, it must be a bad idea. The reality is that beginners are the worst people to judge what is good or bad or consistent, because they don't have the knowledge or experience to recognise deep consistency or flaws in an feature.