OTOH, it is my wish that no one use MS Powerpoint anymore. It is dated and ugly

There's not a lot of good choices. And by "not a lot", I mean... pretty much 0, to be honest. Keynote might be one, but I haven't really used it and my standard line is that I don't want to spend a thousand dollars on presentation software, even if it does come with a free computer. (My other standard line -- re. Hackintoshes -- is that I try to have grown out of pirating and if Apple doesn't want me to give them money for a working legit copy, then fine, I wont.) Some other options like some of the HTML presentation libraries are kind of intriguing, and I haven't had cause to play around with them -- but I'm tempted they wouldn't be worth the added hassle of using separate programs to make a bunch of images and then having those images sit around in separate files.

And as tired as PPT is, Impress is still basically shit in comparison. PowerPoint is pretty much the best of a bad lot, IMO.

Yeah, he has a AlthoughYouShouldHaveAlreadyRealizedThatExceptionFactory

Seriously, for performance reasons this dev-team bypassed malloc of all things; do you really want to assert that they wouldn't have bypassed a bounds-checker?

How would they have bypassed the bounds-checker? About the only way would have been to say int[] all_my_programs_data = new int[1000000000] and then write an interpreter for their own language that uses that array as its data store!

Let's take the example from XKCD: "HAT (500 letters)". To read past the end of the "HAT", they would have had to manually copy that string to some communal store, like all_my_programs_data, and then read past the end. Aside from completely ignoring the language runtime and implementing your own on top, in a language with enforced bounds checking you would not have been able to read past the end of "HAT"!

I've only clicked on your reply a couple minutes ago, but aside from "change the language runtime to no longer enforce bounds checks", I literally cannot think of any other way you would bypass a language's bounds checks.

Everything else, like overruns, overreading, etc is a result of that decision.

No it isn't! It's almost entirely orthogonal!

The OpenBSD malloc that they bypassed makes exploits of already compromised programs harder; that's why Theo refers to "exploit mitigation". If OpenSSL didn't have the overread to begin with, the fact that they replaced malloc would be a questionable decision but wouldn't have led to any exploit. And even with a hardened allocator (or most hardened allocators, anyway), the exploit is still there, it's just much harder to get anywhere near as much confidential information.

That's the only way that they aren't orthogonal: the two mistakes reinforce each other on OpenBSD. In all other respects, they are completely independent.

While I broadly agree with your argument, I have to point out that the heartbleed exploit was due to the OpenSSL devs forgoing the system's malloc implementation and rolling their own abstraction for performance reasons.

No. No it wasn't. The Heartbleed exploit was a classic buffer overread bug that would have been prevented by any language with bounds checking.

On OpenBSD only (for some definitions of only), this bug would have been rendered harder to exploit because of OpenBSD's hardened allocator. An additional problem was OpenSSL's custom allocator and their lack of testing with the system one. Had they not done that, it would have been much harder to exploit on OpenBSD -- but only OpenBSD would have been helped (again, for some definitions of only), and the root cause of the Heartbleed bug was still there.

"DevOps people don't necessarily have good understanding of the underlying issues of the production environment."

You should train them better, then.

Because the point of "devops" is exactly so they understand the underlying issues of the production environment.

Show me an OS with more than 1% market that has a kernel and network stack that is not written in C/C++.

I'd argue that's bad too. (Some sample evidence: Linux kernel buffer overflow (2013). Linux KVM buffer overflow (2013). Remote Linux buffer overflow that could potentially lead to arbitrary code execution (2014). Integer overflow seemingly leading to buffer overflow in FreeBSD (2013). Windows 8 double free vulnerability (2014). etc.) There needs to be a small kernel of code that is in something very low-level, but honestly most of what is in current OS "kernels" (and I don't think that term applies to a piece of software with tens of millions of lines of code) doesn't have to be. Java isn't the right thing and maybe you don't even want something GC'd, but I also think C isn't either.

With so called "safe" languages people are less vigilinte because they can get away with being lazy and not really understanding what is going on.

[Citation needed]

In my experience, this might be true if you start talking about performance. It becomes easy to create and discord oodles of objects on the heap unnecessarily or whatever.

But I don't find myself becoming less vigilant when I'm working in a more abstract language. I find myself thinking more about the problem and less about implementation details.

Don't know... I got it from here. I'm not even sure I clicked the link. Anyway, the article doesn't include either "EITC" or "earned" in it.

Considering that 47% of Americans have a true tax liability of zero or less and that is caused mainly because of those "credits and stuff", then yes, the vast majority aren't straightforward but it is true that the IRS has all the necessary info once you enter all the required SSN.

First, the 47% is unusually high because of the recession; usually, it's a bit lower. Second, while you're true that most of the remainder will get the zero income-tax liability from credits, there's a substantial minority who don't have income enough to get above the standard deduction (e.g. students and non-workers). Finally, like you acknowledge, I don't think that "has credits" even maps very well to saying the return isn't straightforward for purposes of this discussion.

A good coder with skills in secure coding will do fine with C.

I conclude from this and the list of security vulnerabilities in real life that there is no such thing as "a good coder with skills in secure coding."

Or at least no such thing as a project that only employs or accepts contributions from such programmers.

No. The IRS does not know everything required to do your taxes. See also charitable contribution deductions. I could list dozens of other income, deductions, or credits the IRS is incapable of accurately calculating due to the lack of first hand knowledge

The statement was that was true of "For the vast majority of the people in the US", not "everyone."

"Vast" is an overstatement, but it is probably true of a majority of filers. Most deductions don't apply, because only about 1/3 of filers itemize their deductions in the first place; the remaining 2/3s then won't be able to take that charitable contribution deduction. There are still credits and stuff that are more likely to apply to people who don't itemize, but I figure it's still a substantial portion.

I briefly tried to find data on what proportion of returns are 1040EZ vs the others under the assumption that those who file the 1040EZ fall into the "the government has all the info it needs" category, but didn't see any. (Depending on how broadly you interpret things, you could go even broader than the 1040EZ -- e.g. to file for education credits you need the 1040A, but those figures are still reported on a 1098T.)

It amazes me that people *still* give the government interest free loans. Getting money back via your tax return is bad. I strive to owe the government the maximum amount I can each year without penalty.

This is what I said yesterday about this:

Here are a couple reasons why I don't worry too much about this:

1) Especially right now, that money wouldn't earn much elsewhere, especially if you put it into a safe investment. If you just keep it in a bank account, for most people it's probably barely worth it. (The average refund is about $3000 in 2011, the date I happened to see. Put in an online savings account with 0.95% interest (the highest MMA/savings on bankrate.com) and you'd make a whopping $15.48 over the course of the year. I guess that'd buy one person a decent dinner or so.)

If this was in 2007 or something when you could get a 5% account, things would be different. (That'd be $387.)

(I guess that is the federal-only figure. Would be slightly higher with state refunds, though at least for me those have always been much less.)

2) Fewer things to worry about come tax time. There are penalties for under-withholding, at least in some conditions. Overwithholding a little protects you from these.

3) I am not even sure if it's legal to decrease my withholding, for example. I've claimed the exemption that the W-4 instruction allows, and I don't even know if it is legal for me to claim more, or if there is another way to reduce withholding. I've looked into it a little bit, but it's not worth my time to look into the various IRS pubs.

The freelist is not an "exploit mitigation countermeasure",...

He was being somewhat sarcastic, because OpenBSD's allocator is in contrast to

Read overflows don't kill canaries, so you wouldn't detect it except for with an unmapped page--a phenomena that doesn't happen with individual allocations smaller than 128KB in an allocator that uses brk(), like the default allocator on Linux and FreeBSD

and does try to separate allocations specifically to mitigate Heartbleed-style vulnerabilities.

In other words, the OpenBSD allocatior does have exploit mitigation, and the OpenSSL freelist acts as a countermeasure to those mitigation capabilities whether it was intended or not.

The comment even says that it's done because performance on allocators is slow.

It says it's slow on "some platforms", yet they disabled it on all and then didn't test the alternative.

But of course everyone knows it's way better to quickly implement a dramatically awful security vulnerability than to do things slowly and correctly.

(NaCl isn't C, I will point out, and is closer to a better Java implementation than it is to compiling and running C.)

I will weaken this statement a little bit. I assert it's closer to a better Java implementation than it is to a standard industrial C implementation. You could make a C implementation more like NaCl's, but depending on how you look at it (1) it would still make Java and Flash look like Fort Knox because it doesn't even try to protect against Heartbleed-like vulnerabilities, or (2) it would satisfy the constraints of "a safe language", but no one really uses them and I don't know of any industrial compilers that implement NaCl-style protections for standalone programs.

In fact, those two are among the most exploited pieces of userspace software on the OS.

Coincidentally, they're also the two applications that are internet-facing the most. Oh wait, that's not a coincidence at all. If you put C into that role, and let your browser download and run C programs, the result would make Java and Flash look like Fort Knox.

(NaCl isn't C, I will point out, and is closer to a better Java implementation than it is to compiling and running C.)