Brief items

The only words of hope that I can give you is that it's likely that there are so many zero day bugs in the kernel, in userspace applications, and crypto libraries (including maybe OpenSSL), that we don't have to make the CRNG impossible to attack in order to make a difference. We just have to make it harder than finding and exploiting zero day security bugs in *other* parts of the system.

Edward Snowden, late in the pages of his memoir, Permanent Record, describes his sensation at being personally introduced to XKEYSCORE, the NSA's ultimate tool of intimate, individual electronic surveillance. Among the NSA's technological tools (some of which Snowden aided in perfecting), XKEYSCORE was, according to Snowden, "the most invasive…if only because [the NSA agents are] closest to the user—that is, the closest to the person being surveilled." For nearly three hundred pages, the memoir has built to this scene, foreshadowed in the preface, in which the whistleblower-in-the-making sees behind the curtain:

I sat at a terminal from which I had practically unlimited access to the communications of nearly every man, woman, and child on earth who'd ever dialed a phone or touched a computer. Among those people were about 320 million of my fellow American citizens, who in the regular conduct of their everyday lives were being surveilled in gross contravention of not just the Constitution of the United States, but the basic values of any free society.

The steady approach to Snowden's come-to-Jesus encounter with XKEYSCORE is as meticulous as the incremental unveiling of the terror of Cthulhu in an H.P. Lovecraft tale.

It's really kind of stupid. Australia has been benefiting a lot from whistleblowers in recent years -- exposing corruption and bad behavior on the part of the government -- and the government doesn't like it. It's cracking down on the whistleblowers and reporters who write their stories. My guess is that someone high up in ACSC [Australian Cyber Security Centre] saw the word "whistleblower" in the descriptions of those two speakers and talks and panicked.

You can read details of their talks, including abstracts and slides, here.

In a post-apocalyptic future, be it nuclear wasteland or Anthropocene nightmare, a common sci-fi trope is that those able to harness old world technology will have the upper hand. Collapse OS is a new open source operating system built specifically for use during humanity's darkest days. According to its creator, software developer Virgil Dupras, Collapse OS is what the people of the future will need to reconfigure their scavenged iPhones. For now, though, he's hosting the project on GitHub and looking for contributors.

Somewhere down the road, in the not too distant future, email will simply not be an option. You can "use" it, but I can guarantee it will not be in a state where you will want to.

So we can stay in denial about this, or we can do something proactive to prepare ourselves for this inevitable result.

And when we have these conversations about how important it is to retain email based workflows, is that really to make sure we have a backup plan in case new infrastructure fails, or is it to appease "senior" maintainers like myself and others who simply don't want to change and move on?

Personally, I seriously want to change and move on from email, it's terrible.

I just want tools and pretty web pages, in fact I'll use just about anything in order to move on from email based workflows entirely.

I'm pretty opposed to the idea of forges, because this approach makes it very easy to knock out infrastructure critical to the project's ability to quickly roll out fixes. Imagine a situation where there's a zero-day remote root kernel exploit -- the attackers would be interested in ensuring that it remains unpatched for as long as possible, so we can imagine that they will target any central infrastructure where a fix can be developed and posted.

Currently, such an attack would be ineffective because even if kernel.org is knocked out entirely, collaboration will still happen directly over email between maintainers and Linus, and a fix can be posted on any number of worldwide resources -- as long as it carries Linus's signature, it will be trusted. If we switch to require a central forge, then knocking out that resource will require that maintainers and developers scramble to find some kind of backup channel (like falling back to email). And if we're still falling back to email, then we're not really solving the larger underlying problem of "what should we use instead of email."

It would also be foolish of the board to go ahead and create an "openSUSE Foundation" now if a majority of members believe the project should be called something else because if that is the case dropping the openSUSE name will just come up again in a few years and at that point changing the foundation name will be near impossible. This is just another reason why the board feels its wisest to deal with this issue now before we get into the details of creating a foundation rather then sweeping it back under the rug for another few years because its hard controversial and inconvenient.

As for-profit GPL violators, these companies financially benefit from GPL non-compliance by for-profit companies. Their litigation around GPL is a distraction from the bigger issue of companies' repeated violations of the GPL. We lament the irony that two companies have begun a fight regarding GPL compliance (and deployed immense legal resources in the process), yet neither complies with GPL's most basic provisions. Because of this, it's unlikely this suit will yield GPL compliance by either party, and makes the suit another example of how for-profit legal disputes inevitably fail to prioritize the software freedom of users. In essence, we believe their dispute is not about empowering their users with the ability to augment their devices by improving and upgrading the software on them, but rather is about who is able to keep more of their code proprietary.

Each pass is a complex work of art, mathematics and logic and may have one or more highly cited research papers as their basis. No single gcc engineer would claim to understand all of these passes; there are many who have spent most of their careers on a small subset of passes, such is their complexity. But then, this is also a testament to how well we can work together as humans to create something that is significantly more complex than what our individual minds can grasp.

HDCP support in Weston cannot take away anyone's freedoms. It does not allow building Digital Rights Managed video players that could reliably work against your will on your desktop, you can simply hack Weston to lie to them. You could even make the lying a feature and submit it to Weston upstream, if it meets the code quality requirements it will get merged. HDCP support adds the freedom to turn on HDCP encryption if you want to.