:wq

Why?

ex/vi had ':x' (and ':x!') since its very beginning, which has the advantage of not 'touching' the file gratuitously when no changes were made.

There's also the 'ZZ' command while in visual mode.

Are you also using 'cat | grep'? This parrotting of 'geek creed' signs is really getting on my nerves -- better don't show up with your 'wq:' tee-shirt in my neighborhood ;-)

except it's not true that all working interpreters are direct c interpreters. plan 9's rc implements a virtual machine (which it even bootstraps) and interprets the virtual machine.

How come? When was that true?

Looking through the source code of rc (http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/rc/) there is absolutely nothing of the sort.

It's a simple interpreter that creates some intermediate bytecode out of the syntax tree, and then execute it in a stack machine.

Very much like mawk or such.

You probably have vague recollections about limbo/inferno, go or other similar failures they've churned out since then.

Native code, for example, refers to code in its binary (processor-specific) form. No processor that I'm aware of knows how to run C code natively - it has to first be taken from its portable format and translated into native (assembly and then machine) code. It's not a matter of when or how that translation happens; processors simply don't speak C.

You still don't get it.

Running your Python code is not just a matter of 'translating', 'interpreting', whatever they say in tutorials. The problem is that your program needs /at runtime/ some bloated, slow VM written in C and it will still need it even if you compile your program into native code. It simply cannot work without it.

By comparison, if I compile C program for the attiny13a, I get some dozen or hundred bytes to put into its memory to run through them, and that's it.

And the situation wouldn't change no matter how many compiler passes I do, or what "abstraction level" I use, or whatever. It's still very much an assembler, even if I was producing machine code from flowcharts, koans or gestures.

Claiming that hardware can run C natively is quite a reach. Your definition of what it means to run a language natively is so broad that it encompasses a large number of programming languages (if not all of them).

It's not about the number of passes of the compiler or if a language is supposed to be portable or not, but about the "virtual machine" abstraction a language is assuming, and how far is that from what typical hardware has to offer.

To run any Lisp or Python program, no matter what interpreter/compiler you use, you need to implement garbage collection, reflection, run-time code evaluation, etc.

Those features are neither light-weight, trivial nor scope-limited, unlike software routines implementing integer multiplication/division (on alpha) or a floating point emulator (on most arms) -- that are needed for a full C implementation.

And if you strip your language of those complex features, you also lose the 10x productivity you like to claim, and you simply get a C without pointers.

And most hardware is able to run C natively -- C is just a glorified assembler. And ISAs which didn't map nicely to C, like pdp10, are long gone.

Anybody would love a system programming language other than C, less anchored in single-threaded '70 pdp11 concepts and idiosincrasies; but as long as there isn't any, stop pitching your slow bloated language-of-the-day, and pretending that with enough kool-aid and meditation, you can replace C with Java or Python.

Also, android has a linux kernel, which means iptables-based firewalling works

Not necessarily.

On my phone the kernel was built without iptables support.

I had to beg for the modified kernel sources, wait 3 months to get them, and then waste a lot of time to learn about the stupid idiosyncrasies of 'android is not gnu', just to get that standard linux feature working.

If I were a programmer

That's the problem: you're not.

and found that completely unacceptable, I could always choose not to work on such an important project critical to the security of so many.

That the old tired meme used to keep honest competent people out of critical jobs; but unlike generals and politicians, programmers able to work on OpenSSL don't grow up in trees, so you will have to make do with (almost) the same people and stuff your "incentives" and "reactions" up your ass.

I do have to wonder if the task was made easier given the purpose of the server. After all, I'd think it wouldn't get traffic at all except for those people responding to the challenge.

On the contrary, it may have made things harder.

Reading the private key relies on forcing malloc() to reuse some small block from the free block list with a lower address than the block containing the key, insteading of simply carving a new block out of free memory (with an address higher than the key).

That may be easier to do on a busy server, because you don't have to send millions of queries just to fragment its memory; you may just assume that malloc is already reusing freed blocks, and exploit the algorithm it uses to do that (eg by manipulating the length of payload to let it allocate some unusual size block for which some gap just before the key is the perfect fit).

I have met a lot of them, and while they are extremely friendly people, they are also staunchly conservative when it comes to things like cochlear implants and what they see as the erosion of Deaf culture.

Does a cochlear implant let one hear as "normal" people do, or at least as much as an 80-old with a hearing aid?

If the answer is "not quite", then they have all the reasons to be conservative.

This bug would have been utterly trivial to detect when introduced had the OpenSSL developers bothered testing with a normal malloc (not even a security

This is simply not true, stop spinning it.

Even if OpenSSL is using system's malloc, with all its mitigation features, the bug still works. The attacker just has to be more careful, lest he should read freed() and unmapped memory, and so cause a crash and (supposedly) leave some kind of meaningful trail.

They just included it as delivered by the OpenSSL people (BTW, OpenSSL is a different project, no relation to OpenBSD).

A simple code changes review would have caught such an obvious bug (trusting without checking a buffer length parameter received over the network).

As to their memory randomization thing and how OpenSSL worked around that by wrapping malloc(), that's a red herring; if you're able to read the whole process memory by 64kb, there's no problem to follow all pointers in the manner of a garbage collector, or simply mine it following known patterns.

Was it automatically enabled?

The Soviets most certainly did have state mandated atheism. You could get sent to the gulags for admitting to or demonstrating your religious beliefs.

When was that?

AFAIK, the Orthodox Church was very much scaled back, but its priest, seminaries, etc were still payed for by the State, and just as in tsarist times, the Church was an active & enthusiastic organ of the totalitarian state (the clergy ranks were even assimilated to ranks in the secret police).