Brief items

This is the reason actual cryptographers and security engineers are very skeptical when a random company announces that their product is "secure." We know that they don't have the requisite security expertise to design and implement security properly. We know they didn't take the time and care. We know that their engineers think they understand security, and designed to a level that they couldn't break.

Getting security right is hard for the best teams on the world. It's impossible for average teams.

Anyway, elections are a very tricky problem to do securely. It is a nearly impossible task. But there are lots of things that you clearly should not do, and for some reason, the e-voting manufacturers seem to want to do all of them, and don't seem particularly apologetic about any of it. And, while in the past the idea of hacking an election may have seemed far fetched and conspiracy-minded, these days... not so much. This is a key issue concerning our democracy, and the most incredible thing is how flippant many people are about all of this. Computer security professor Matt Blaze, who knows more about any of this than anyone reading this points out that "in the more than quarter century I've been doing computer security, I've never encountered a problem space nearly as difficult or complex as civil elections."

And yet, we're letting people who don't understand even the slightest bit of the problems and challenges run the show. What a mess.

Come on, don't you remember back when reflashing for the cause was fun?

Hopefully these results show that it is perfectly possible to have containers that are more secure than hypervisors and lays to rest, finally, the arguments about which is the more secure technology.

The presumption is that (at least for US-based CPU manufacturers) the amount of effort needed to add a blatant backdoor to, say, the instruction scheduler and register management file is such that it couldn't be done by a single engineer, or even a very small set of engineers. Enough people would need to know about it, or would be able to figure out something untowards was happening, or it would be obvious through various regression tests, that it would be obvious if there was a generic back door in the CPU itself. This is a good thing, because ultimately we *have* to trust the general purpose CPU. If the CPU is actively conspiring against you, there really is no hope.

The distribution wants to be stable, free, near the cutting edge, accessible and minimal. It also pulls in ideas and software from at least four other projects. It's quite an odd combination and as a result I'm not entirely sure what use cases Hyperbola is targeting. People who want a libre distro like Trisquel, but prefer pacman for package management? People who love the manual approach of setting up Arch, but with Debian-like security updates? Hyperbola is so weird I can't help but appreciate it, but I'm not sure under what circumstances I would consider it the best tool for the job.

As the oldest distro around, Slackware has been very influential. The earliest releases of SUSE Linux were based on Slackware, and distributions such as Arch Linux can be seen as philosophical heirs to Slackware. And while its popularity may have fallen over the years—the slightly younger Debian has 10x the number of subscribers on its sub-Reddit, for example—it remains an active project with a loyal fan base. So happy 25th birthday, Slackware, and here's to 25 more!

We can improve the whole with each little thing that we improve. The fact that a task is large, with many parts to it, shouldn't put us off from starting it anyway. Hell, who'd have thought a collection of volunteers could develop and maintain a complete operating system...?

Howdy there, fellow cyber denizens; 'tis I, Alyssa Rosenzweig, your friendly local biological life form! I'm a certified goofball, licensed to be silly under the GPLv3, but more importantly, I'm passionate about free software's role in society. I'm excited to join the Free Software Foundation as an intern this summer to expand my understanding of our movement. Well, that, and purchasing my first propeller beanie in strict compliance with the FSF office dress code!

You know that Perl has you when you start looking for admin tasks to automate with it. Tasks that don't need automating and that would be much, much faster if you performed them by hand. When you start scouring the web for three- or four-character commands that, when executed, alphabetise, spell-check, and decrypt three separate files in parallel and output them to STDERR, ROT13ed.

Satellites may seem an extreme case, but the same goes for any large scientific studies and many things in the aerospace industry. You can still find inflight TV systems on major plane lines that will reboot themselves to some Red Hat Linux 7 logo.. an OS that was EOL over a decade ago. There are similar items in industrial controllers for making textiles, plastics, and other items.. the devices are large and expensive to replace so will run whatever software was in them for decades. They will also require software which interfaces with them to be 'locked' in place which can have a pile on effect where you find that you need to have some new computer system be able to run something written in Python 1.5.

I expect that a LOT of systems are currently written to work only with Python 2.7 and will be wanting software for it until the late 2030's. The problem is that very few of them are have plans or ability to pay for that maintenance support. While it is very late in the game, I would say that if you are relying on python for such a project, you need to start budgeting your 2020 and future budgets to take in account of paying some group to support those libraries somehow.