dwheeler

I think there is a plausible argument, believe it or not. See my essay "Why are Humans used as Batteries (a power source) in the Matrix?" https://dwheeler.com/essays/humans-batteries-matrix.html

Abstract: "In the fictional world of The Matrix, I propose that the machines might use the humans as a power source (as “batteries”) not because the humans are a good power source, but because doing this allows the machines to avoid committing genocide - as would otherwise be required by their laws. This compromise could have been necessary to prevent a machine world civil war."

I'm sad you had that experience. I haven't used the forums. I have created some scores, and I thought it was fine. Ymmv.

I've been a happy user of MuseScore, music notation software which has a gui, is cross platform, and is open source software: https://musescore.org/en

I gladly recommend it to others.

A Tex like approach is available via Lilypond, though I have not tried it so I have no experience to share.

LFD 121 ("Developing Secure Software") is the Linux Foundation’s FREE course on secure software development fundamentals. This post discusses a bird’s-eye view of the course and its topics; why every developer should take it; and how its material has continued to be updated and remain relevant.

Quite amusing!

> Crafted from the finest plastic, the NotFriend will never go out of style.

This is obviously correct since it was never in style. :-)

In other words, they failed to do end-to-end testing in some cases. They tested pieces, but not the full system they released.

If you don't test each config update, by definition you didn't test it.

Rust has many nice properties, but it can panic too. You should still test the whole system before each release if it's critical.

The Crowdstrike report explains why it crashed, but not how it passed final end-to-end testing. There appears to have been many tests of piece parts (unit testing), but that's not the same as testing the full system.

I would think all the end-to-end tests of the full system would have been instantly detected the problem and prevented it, because it would have failed all the end-to-end tests.

Did I miss something? Did they never test the complete system as deployed? Looks like it, but maybe I misunderstood something.

This doesn't require all software used by Switzerland to be open source. Per the article:

> This new law requires all public bodies to disclose the source code of software developed by or for them unless third-party rights or security concerns prevent it. This "public money, public code" approach aims to enhance government operations' transparency, security, and efficiency.

The encodings we use today have a surprisingly deep and complex history. For more, see: "The Evolution of Character Codes, 1874-1968" https://ia800606.us.archive.org/17/items/enf-ascii/ascii.pdf

Crowdstrike released a change that should have been caught by automated testing. That does require an explanation, I think, and a change to prevent recurrence.

Interesting article.

It does remind me of an old joke about English conjugation rules. For example:

I/we are persistent.

You are obstinant.

He/she/they are pig-headed.

Awesome story! I love hearing about surprising and interesting solutions.

Explainability is a wonderful property. However, as far as I can tell, the most accurate models do not support explainability (by accuracy I mean "most likely to give correct answer"). There are reasons other models are more popular.

If that's true, we are confronted with a classic trade-off: what is more important? Explainability or other properties like accuracy?

I suspect in that in some high-consequence areas explainability will be the most important property (and possibly mandated by law), even though it has lower accuracy. For the rest, accuracy will be more important.

Sadly, I think there is good reason to believe that this trade-off will continue. I hope I'm wrong about that.

> C was hardly a performance juggernaut in the 1980's, any junior Assembly coder could easily outperform the outcome of the C compilers.

I think that's not especially relevant. The issue is that most other higher level programming languages had poorer performance and/or inserted undesirable mysteriously-timed lags in performance. Fortran had excellent performance, but Fortran at that time couldn't handle many constructs that C can. Some Common Lisp implementations at the time had reasonable performance, but the garbage collectors often inserted pauses (ugh!), and many were expensive at the time too.

Also: The 1980s was the rise of the IBM PC-compatible (and the Macs too). These were machines whose underlying chips matched C decently well (they had hardware-implemented large stacks unlike the 6502), however, these machines were underpowered compared to what some people wanted them to do. This also had a rise in Unix servers, where C was their native tongue.

I appreciate the direct nod to security. But as written I doubt it's enough. The goal is to "enable" secure programming, and C already meets that goal since it is theoretically possible. The problem is that busy human developers are not good at being perfect. There are far more ways to get things wrong, and minor mistakes become far more serious problems in C and C++ compared to other languages. I do wish the group good luck!!

For a comprehensive set of recommended compiler options for hardening C and C++ programs, see this OpenSSF guide: https://best.openssf.org/Compiler-Hardening-Guides/Compiler-...

No, you can bring GPLv3 code into software with other licenes such as the MIT license.

I consider "posted on YouTube" the same as "posted on the Internet". Youtube is basically a comm channel, they don't vet for accuracy nor do they claim to.

Look instead at the channel. Some channels make serious efforts to cite their sources and justify their claims; others do not. It's hard, but where you can, try to prefer the first.

CGP Grey has a delightful video explaining this:

"The Secret City inside of London Revealed" (2012) https://youtu.be/LrObZ_HZZUc

Highly recommended.

Ruby is packaged for all significant Linux distros. It isn't installed by default in many, but installing it is a trivial one-time command, and it takes relatively little space.

This patch uses heuristics that seem dangerous to me:

> The 9P filesystem protocol relies on stateful file opens which map protocol-level FIDs to host file descriptors. The FreeBSD vnode interface doesn't really support this and we use heuristics to guess the right FID to use for file operations. This can be confused by privilege lowering and does not guarantee that the FID created for a given file open is always used for file operations, even if the calling process is using the file descriptor from the original open call. Improving this would involve changes to the vnode interface which is out-of-scope for this import.

Where would you use something with such unreliable heuristics??

It is an issue for Python, though this specific issue isn't the main issue for Python.

More generally, it's even harder to routinely call programs while connecting them with pipes and ensuring that the programs run in parallel. It's a pain to routinely call other programs and get results Python. It takes many many lines of Python to do tasks that are clearer one-liners in shell... and vice versa.

Python and shell are different; each are good at different things.

Thanks so much, that means a lot.

> Has anyone actually found a good use for filenames containing newlines?

They're great for attacking systems, because so many programs aren't prepared for them. Any program that uses filenames as keys (and there are many) can have this vulnerability if the input validation has a weakness.

I don't think there are any legitimate uses. They also make it unnecessarily hard to write robust shell scripts.

I suspect he's heard by now. :-)

But I think it's worth clarifying why certain phrases are used. Saying "there is no dark side of the moon" is also wrong.. once you realize that "dark" has multiple meanings. And since the moon has been around for a while, there are some very old phrases relating to it.

I agree! You can blame me for some of those proposals :-), my thanks to the POSIX team for getting this out the door.

The sed -E option makes it easy to portably use extended regular expressions.

The find -print0, xargs -0, and read -d provide portable ways to securely process lists of files. They were already widely implemented, but now they're officially part of the spec and can be counted on being present in many other places.

It's worth remembering that in the phrase "dark side of the moon", "dark" means "hidden" not "unlit". The dark side gets the same amount of light as the near-facing side. See dark OED definition II.11.a. (1532–): "Hidden from view or knowledge; concealed; kept secret." https://www.oed.com/dictionary/dark_adj

I disagree. We still cannot combine the key theories of the quantum and relativistic world. We don't understand whatvwe currently call dark matter and dark energy.

However, it's not clear how to make progress in these areas.

Wow. At first I thought it was just rambling. Now I'm alternating between "that's amazing" and "get help".

I've found that using a simple unique integer id as the key usually works well. Integers are easy to explain and are simpler to enter than uuids. There are always ttade-offs, but if there are no other compelling issues, simplicity is best.