While you are definitely right that people could go a long way by not ignoring compiler warnings and by running static analysis, a language like Rust can detect errors that C cannot detect, because the code just plain doesn't contain the information. And even for errors that can in principal be detected, it's a lot faster and easier

Furthermore C is not intrinsically faster than any other compiled language with not-too-dynamic memory management. That's a question of the compiler.

And OpenSSL should be written in something tighter than Rust. If you absolutely must have a few hundred lines of performance code, then write them in whatever you need to write them in... which probably means assembly or even microcode, not C. But most of something like OpenSSL is nowhere near the performance path for either the crypto or the overall application. In fact, an office application probably has more performance-critical inner loops in it than your average crypto library.

Now, GPUs... well, you're never going to get any decent security with anything resembling a contemporary GPU anywhere remotely near the attack surface, so the first step there is to stop doing psychotic things like exposing OpenGL to JavaScript downloaded from the Web...

"Developers generally do not want to become security auditors; they want to receive the results of audits..."

There's something wrong with that. The center of attention is in the wrong place.

The whole idea is that you write the thing to be secure to begin with; the security is part of the fabric of the whole construction. Audits are secondary, however useful they may be. If you think of security as an auditing or testing process, all your audits or tests will do is tell you that you don't have security. ... and, really, you can go a long way toward being secure just by being correct for all possible inputs. Which is actually kind of an interesting challenge if you approach it on those terms.

I'm not saying it'll appeal to everybody, but at least for me, and I suspect for a lot of people, there's a lot more appeal in trying to capture perfection in your code tp begin with than there is in auditing anything, let alone responding to audits. Procedural stuff like that does indeed suck, and I know; it's been a big part of my life.

Yeah, but the problem is that people tend to take your "hobby" code and use it for their jobs. Which is their fault, not yours, but still causes bad problems.

... do you have to be to work on something like that?

If you want to send a non-repudiable email message, then fucking sign it yourself with PGP or something. DKIM has no special legal status, and less actual evidentiary value

And DKIM didn't have anything at all to do with people being more accepting of emailed documents, anyway, nor did it change any legal situation. FAX is completely unauthenticated and at least as easy to forge as email ever was, but people accepted it because they were used to it. When they got used to email, they started accepting email too.

What DKIM did do was to make email harder to repudiate by accident, through the back door, with a change introduced for a completely different purpose. It's completely legitimate to undo that, especially when there are better ways for a user to opt in to non-repudiation.

If you're going to go that route, why represent the code as a text file at all? Make it a binary AST on disk, and make the editor convert it to and from text. It could work, except that you'd have to retool the entire world to support it.

However, as long as programs are text, you have to require humans to enter some text to tell a compiler where, say, a block of statements ends. If you do that using some random characters like curly braces, some human is going to have to type those. That human (or more likely the text editor) is also going to type whitespace to make the program readable. You're requiring the work to happen twice, and putting two different representations of the same information into the file on disk.

For that matter, if you wanted, say, Python to have curly braces and semicolons and no indentation at all, you could have your editor present it that way. Nobody cares if you do that, so long as you write out a properly formated Python file in the end (and make sure you don't change things that are significant to SCM when you don't mean to).

So why are extraneous printable syntax characters, or whatever else you want to do to indicate where things begin and end in code, any less "code presentation preferences" than whitespace? If you really, truly hate significant whitespace that much, you can have what you want as a simple matter of programming.

The only real difference between indentation and explicit printable separators is that at least some kind of indentation seems to be an almost universal human preference... even in languages where all the sugar characters have to be there anyway. People are actually willing to do double work to get indentation even when it doesn't matter to the compiler. It's important enough that basically all large projects have formal rules about really picayune details.

A simple editor can only really maintain one or the other, so it makes sense to use the one that most people rely on, and not to require manually maintaining two different representations of the same information in the disk file. A complicated editor can do whatever you want once it loads that file.

Since that color coding assists and ultimately matters to how humans decode the document, then it had better damned well be what the computer uses to decode it.

If that color coding were part of the actual program text, as opposed to being something that the editor tags on when you load the file and that vanishes when you save the file and close the buffer, then that would in fact be right. If the convention in the language were that variable names were entered in red, and you entered them in green, and that were going to show up on my screen when I viewed the code, then that should be a compiler error.

But in fact the color isn't part of the program in any way. It's ephemeral stuff, added at load time and stripped at save time. What the color coding does is actually to make the machine's view more visible to the human.

Syntax and whitespace really matter in lots of formats invented by human, for humans.

Yes, I can decode the shitty mangled English syntax that a lot of people use on Slashdot, but that doesn't mean it's easy or reliablie. It matters.

As for whitespace, the reason you see so much significant whitespace these days is that humans had already started routinely adding rigidly formatted whitespace to languages where it did not matter to the computer, because it made reading it easier for the humans. You can't easily read anything with a block structure unless it has indentation. And if that indentation matters is what you use to decode it, then it had better damned well be what the computer uses to decode it.

HTML has a bunch of markup intended to create significant white space for human consumption.

How fucking smart can something be if it wastes its time on Slashdot?

Sounds more like they're trying to eliminate competition for overpriced paid hotspots run by people they control.

The creeps have been slow to start enforcing it, especially in these most obviously idiotic cases. If you'd asked them 14 years ago whether this was what the law was about, I bet the would have denied it (while furiously masturbating).

Peddling stolen snake oil. Wow.

I mean, fuck everything and everybody involved in this story in any way.

What is this "proper price" of which you speak?

If I were nVidia or however you spell it, I would raise the price of the early cards myself, until demand no longer exceeded my available supply. There is absolutely zero practical or ethical problem with that. You let these people put all kinds of bizarre conditions on how you can use the product, and then you worry about the price?

It's called waiting until you have enough product before release,

How the actual fuck would that help anybody? Not everybody can get a card, so make sure nobody can get a card?

I don't think white reproduction is going to make you any smarter. It's a pity. We're all hoping against hope for something that works.

The beams are in fact vaguely conical, although of course they don't actually have sharp edges, and do have weird lobes, because you can't make a wave propagate along a sharp cone any more than you can make it propagate in a sharp cylinder.

The -3dB beamwidth of a 15GHz Ku-band beam from a better-than-realistic 0.5m parabolic reflector is about 3 degreees. In reality, a receiver on a plane could probably detect the beam out to at least 6 degrees off center if it were strong enough to be received from a satellite, and more like 9... but let's say you have a crappy receiver and can only detect them from 3 degrees. If you are flying over the area at 30kft, that means you can detect them anywhere up to about half a kilometer off your flight path. If you run a 1km grid over a city, you'll detect all of them.

Of course, you'll then have to locate them; you need to narrow in on a given source after you detect it. That is not in any way difficult. The fact that they're nice and narrow and don't overlap each other that much works to your advantage. Point sources are great, because you they lead you, as it were, to a point. Stars are also point sources, and are routinely located to fractional-arc-second precision.

If you are really using a dish a couple of meters across, the beam will be considerably tighter... but the dish will be very hard to hide visually, and will cost too way much for most people. The whole appeal of high bands is that you can use them without having to build fucking Arecibo to direct your signals. And even at a couple of meters, I still doubt your beam will be tight enough in practice.

In fact, completely ignoring the antenna, if your electronics are not very good and very well shielded the omnidirectional leakage from your ground station will be enough to let somebody locate it just by driving around the streets in a van.