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.)

Language makes no difference In a "safe" language, the bigs are just harder to find.

I think this is a dumb argument. Let's divide up problems into "memory errors" and "logic errors", where we broadly interpret "memory errors" as "errors your language or runtime won't let you make."

This means that if you program in C, you have to deal with memory errors and whatever logic errors you make in C. If you program in another, safe, language, you no longer have to worry about memory errors and only have to worry about logic errors in that language.

That means that unless you can argue that you'll make more logic errors in your safe language, you've already won.

Furthermore, because in C you have to spend time and effort making sure you're not susceptable to memory errors, that takes time and effort away from looking for other errors. Not only that, but automated tools have a harder time dealing with C than they do with many safe languages, which means you have less tool support.

And that's not even getting into more esoteric languages where you can encode non-trivial proofs into the type system and have the compiler prove correctness with respect to certain properties.

While it might be nice to use a safe(r) language, can't we at least have a compile option in C that adds bounds checking?

That's extremely difficult to do for C. People trying to do that has resulted in multiple PhD theses and no one still has a perfect solution. If you actually want that, then use CCured, which is probably as close as it gets.

And while you're at it, how about making it impossible to execute code that isn't in the code segment and write protecting the code segment.

I'm pretty sure that's how things are now, though I could be wrong. Non-writable code has been around for ages, and non-executable data was the whole NX/DEP from a decade ago. I think that's pretty ubiquitous now. (I guess I've almost always heard of NX protecting the stack, but I assume you'd mark heap & static pages NX too.)

First: Many languages are largely or even entirely self-hosted in terms of compiler and/or runtime. This means that if they provide, say, better type safety than C, those benefits carry over to the portions of the language that are self-hosted.

Second: the directness of the problem. It's easy for a C program to allow a very direct exploit, e.g. Heartbeat. I'm not saying easy to find, or that you'll necessarily get what you want to see every time, but the bug itself is about as simple as you can possibly get. If your language runtime has a bug instead, it's much more likely to be a very indirect one, because now not only do you likely have to cause a specific behavior in the program itself, but that behavior has to trip up the runtime in a way that causes that bug to lead to something bad. This isn't really fair to say this, but consider the Heartbeat vulnerability: to have the same thing happen in a safe language, not only would the program have to have the potential for a bug (unchecked input) but you'd also have to trick the runtime into dropping its bounds check.

Sure, it's not guaranteed to cure all ills, and runtimes can have bugs. But at the same time... it dramatically raises the bar.

Arrange your source deductions and installment payments so that you don't get a refund.

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.

This is an internal door, it's not like it needs to be sturdy. Then I realized: the only time you would need a solid oak door for a bathroom.... is the little boys room at the Vatican. (I'll be here all week folks!)

Not quite. Gtk and Gnome appeared because Qt was originally proprietary. The reason why Gnome became "the default", though, was because enterprise distros like RedHat pushed for it - and that was because Gtk and Gnome were both LGPL, so closed-source software could link against them. This was not the case with Qt, which was open sourced for a long time, but was GPL rather than LGPL.

If by this you mean the various limitations surrounding Windows Store (aka "Metro") apps, then those happened very much under Ballmer. Hell, the guy have only just recently left, so what exactly has disappeared since then?

At the same time, Satya was heading Cloud & Enterprise business before becoming CEO. And C&E, among other things, includes DevDiv - and Satya has a lot of supporters there. Furthermore, note the meteoric rise of Scott Guthrie, who was always one of the more passionate advocates of a solid and modern developer story for MS (in particular, embracing F/OSS).

Did you miss the entire recent .NET cross-platform push, what with the Xamarin partnership and all?

So, basically, tax oil production - we could call that, say, "carbon credits" - and then invest those into R&D necessary for clean energy and geoengineering?