I think that's a lie, the truth is everybody thought there were so many eyes on the code they all glazed over and nobody really looked. After all, if this was my company and the line was "Well everybody who works here has access to the source repository so I'm sure that someone would find it..." there'd be plenty alarm bells going off in my head. For sure, bumping into buggy code is often the way you find out about bugs but for security critical code it's review, more review, audits, all that really boring red tape that counts to stop it getting through in the first place. If the rumors are true, the NSA caught on pretty quick which is because they have lots of smart people getting paid well to look for exactly these kinds of issues. This is not magic. But it's the kind of boring shit you usually have to pay people to get done.

Except for corporate sponsored positions - which also typically have their own agendas - the work that gets done is the work people feel like doing. If what you need is 50% development, 50% review but 90% of what the people involved are interested in is the development of their own pet features well you don't have any authority to boss people around. You can ask the reviewers to be a bottleneck which will quickly turn sour, you can ask them to rubber stamp it faster or you can add people who really shouldn't be reviewers but you can't hire more qualified reviewers. Waiting a few years for someone to stumble into it just isn't a good process, no matter how much people pretend this proves how OSS "works".

That would be true if high level languages only offered the default implementation but usually they have a special implementation like SecureString in .NET, it'll let you do the exact same thing. For bonus points it'll also encrypt the data in memory in case you have to keep it around a little while, sure it's a bit of security through obscurity but it won't be trivial to find with a memory dump. The issue is more that people who aren't aware of the issues won't ever think to look for or use these classes, but they're available.

At the start of the war holding slaves was not unconstitutional, each state made their own laws and there was slavery on the Union side as well. The United States simply did not want 30% of their population and 70% of their exports seceding away, it would totally cripple their economy. The Emancipation Proclamation in 1863 - long after the war started - was just directed at the slaves in states in rebellion, those under Union control still remained in slavery. In short, it was a wartime measure to cripple an armed rebellion and recruit soldiers to their own side. I'm sure the Lincoln movie is not the most accurate historic source but there was huge doubt if the proclamation had any force once the war was over or if they'd all be returned to slavery.

There was huge resistance to passing the 13th amendment even with the southern states broken away, it was rejected as late as 1864 and only passed with the smallest possible 2/3rds margin (119-56) through the House in 1865 before the South rejoined. And that was only after years of negros serving in the Union army and dying for the north, at the start of the war... no. The abolitionists might have been on the rise but in 1860 support for slavery was alive and well all over the United States. They might have climbed to the moral high ground during the war, but initially it was a simple case of the government fighting down a rebellion like any other.

In case you've been sleeping under a rock for the last year, the target of the NSA is everyone. Not that they put you on the same level as the Chinese military of course, but nobody's under their radar and if they can grab your data or metadata easily they will because you could be a terrorist or at least the friend of a friend of a friend of a terrorist. It's not that the average joe would stand a chance if they threw everything in their arsenal at us, but those "zero day exploits, side channel attacks, social engineering, and TEMPEST techniques" don't come free and using them highly increases the chances of exposing them. The question is more like "Does NSA grab all the TrueCrypt containers used as backup on Dropbox/GDrive/whatever and rifle through everyone's data?" than "If the NSA really wants the contents of my laptop, would this really stop them?"

If we had anti-gravity cars like those in "The Jetsons" then I think it'd be fine, we'd need some kind of virtual lane system with upwards/downwards corridors as a heads up display and an emergency parachute (space capsule style?) to save your ass but it'd work and you could stay to sane consumer speeds with high speed high altitude "interstates". Anything that depends on wings for lift though has to stay at very high speeds and can't practically stop for anything, even if you have a VTOL system hovering for even an extremely brief time will burn through your fuel in no time. If you think it's bad now, wait until slamming the brakes is not an option.

I know what rhetorical means but really, there's so many obvious ways. Take a piece of string, tie down one end and draw a circle in the sand with the other. Now use the same piece of string to measure out the circle. You'll get an approximation of pi more than good enough for any practical purpose, the only thing "special" about it is that numbers that aren't fractions like pi, e and the square root of 2 was fucking with their understanding of math. Even the ancient druids of Stonehenge could map out a circle, long before Euclid.

Well, he's using the only sales argument he has from the customer's point of view. From the store's point of view though they won't sell it at the same price you get online because they need to pay for location, staff, deal with shoplifters and books that go stale and unsold that need to be taken off the shelves again. It's better for them not to take your business rather than open up Pandora's box and have people coming in expecting to be price matched, taking up sales rep time and getting angry if they're refused. And if word got around you could get it cheaper just by pointing to a webpage on a smartphone, other people buying it at normal markup could feel cheated and generate a lot of negative publicity about you. As sales pitches go it's a honest one, but it's not the real reason why they won't price match.

Well that's maybe relevant for those coming from another European language or reading old English texts, but to users only interested in contemporary English that's more of a historical curiosity. Their challenge is that the rules aren't consistent, which is often traceable to its historic roots. For example let's take the word steak, it's a loanword from Old Norse steik which is why the "ea" in steak is different from that in peak, leak, beak, weak or freak. Of course every language has a few foreign words that don't follow the normal rules but English has it dialed up to 11.

It's a photo/video camera that might have been on, not even stupid crooks would leave that potential evidence behind.

English keeps the pronunciation of the language they took it from, which means it's a smattering of Britons (~Welsh, -450), Anglo-Saxons ("English", 450-1066), Normans (~French, 1066-), Gaelic (~Scottish, ~Irish) with some Norse from Scandinavia, and through the British Empire it's picked up words from most of the world's languages by now. While "English" has pronunciation rules, unless you're a professor of etymology (the history of words) it's easier to just learn each word than trying to find a pattern.

Or in banking terminology, GNOME is too big to fail. Sorry, ever since Qt went LGPL in 2009 I've wished they'd go away so you can actually build a modular desktop, but as long as there's two competing languages it's almost impossible to build common components without going to awkward workarounds like D-Bus. Not even the kernel would work well with kernel modules written in C++, Java and Python, not that there's anything wrong with them as languages but as modules to a C program. Otherwise I expect the in-fighting will continue until Google pulls an Android and leaves GNOME, KDE, XFCE etc. to be a Nokia N900 niche in the desktop market. Not because it's technically the best solution, but because Google has a certain Steve Jobs effect too - if they tell everyone desktop Android is the next big thing devices, developers/applications and users will follow.

Well, first of all since OpenSSL is an open source project, I doubt staying anonymous was an option as you can go back and check git logs and mailing lists.

So the takeaway here is that OpenSSL has a review process that lets "quite trivial" bugs in the input validation of a high security product through, that's comforting

If you were a spy agency trying to get a vulnerability into OpenSSL, do you think it'd be on the first patch? Fix some insignificant bugs, get trusted, introduce seemingly innocent but deeply flawed code and trust that it gets rubber stamped through. He the first of three authors on the Heartbeat extension which for some reason includes an arbitrary size, arbitrary content data block where a simple PING/PONG would confirm the connection is still alive. I'm not saying he is a plant, but I am saying that everything he says is exactly the same as a plant would say to excuse his backdoor as a honest mistake. I mean, could you do it any better if you tried? Create a side channel by passing large chunks of data back and forth between the client and server, then create a flaw to pass the state buffer instead. It smells to high heaven.

If you have a natural owner that's just providing access to it I'd agree, references (or constant references) are great but in this case I'd disagree. If it's for example an application form the form itself is ephemeral, but the information in is not. If you submit it, I want the form to pass the information by value and self-destruct cleaning up after itself. Once it reaches some kind of data owner, it can pass the application by reference through processing steps. For the same reason references are not so good for display, for example you have a function to display an invoice. If some other process on the back-end deletes the invoice, you suddenly have a reference to nowhere and it could crash as you try getting more details or see the next page. In short, don't pass a reference unless you know the source will live longer than the reference.

Logical in some kind of binary-compulsive-autistic way. If you have some kind of fuzzy state like say raising a child where the answer is somewhere between "Let them do everything" and "Don't let them do anything" it makes geek heads hurt. Half our jobs is taking fuzzy requirements and turning them into rigorously defined, deterministic rules that defines behavior down to the last bit, it's our job to take a round peg and squeeze it until it fits a square hole. You also see it in geeks trying to reduce everything down to some oversimplified set of axioms, like free speech. Maybe we don't think threats or companies being able to lie in commercials or or kiddie porn is okay, but some will take it all the way to bizarro-world where Hitler didn't kill any jews unless he personally choked one to death, he was just exercising his free speech.

At least most geeks will agree there's a "street smart" too, maybe a little bit derisively but it's also a recognition that everything isn't in a book and being able to practically deal with situations as they happen in real life and interacting well with other people and your surroundings is a good thing and is important to function well in real life. Or I think maybe that's two things really, one is the practical side like knowing how to survive in the wilderness versus having read a book on how to survive in the wilderness and the other is dealing with people and animals with emotions. Your computer is your obedient slave, you tell it what to do and it executes it, it doesn't need a "please". It doesn't need motivation. It doesn't need buy-in or an explanation for what it's doing. If you think "HR" degrades people, you should hear the wetware's opinion on IT...

Depends on the type of coder, I've met too many old coders who try to keep the memory use low, performance high but code complexity is terrible because it's all one giant spaghetti ball of code.

For example now at work I've created a system which has a single master procedure( productionId, datasetId, stepId ) where NULL in the last two means all sets, all steps. I know some of the steps would be more efficient if merged, I know some contain one-time setup (but is hard to extract out) that's repeated many times when I run them on all datasets but for development it's a bliss. I can rerun a single step for a single set, a single step for all sets, all steps for a single set, I can easily time them (start and finish, per step, per set) and see what's making it choke not to mention if there's an error it's in a narrowly defined piece of code not the many-thousands-of-lines script it's replacing. A coworker of mine is starting to work on it setting up another production type and he loved the structure because it was so easy to grasp, even if he's only looked at a few steps.

Another feature I like is passing objects instead of values through layers. For example, say you have a form that has a string and a radiobutton but needs to have another UI element added, let's say a checkbox. If you pass the values as ( string, radioButton ) you have to change signatures everywhere. If you have an object FormValues, add the checkbox and pick up the value where it's needed. Is that efficient? Probably not, I guess I'm often passing ten values around when I only need two. But it saves a lot of pointless coding time when I find out that oh, I have to increase that from two to three. Defensive coding that makes it easy to expand or change functionality beats hardcoding every time.

I started out with a C64 which had 64kB of RAM, I'm not going to do that if we're talking about a million or a billion objects. But there are still people stuck in that mode where it's like every byte matters and it just doesn't. Make code that's easy to work with (verbose for clarity and descriptive names, but compact using standard functions and generic code where possible) and about 95% of the time it'll be worth more than trying to make it machine-efficient. A lot of "hardcore" developers dismiss abstractions as simplification for the simpletons and real developers code right on the metal, maybe not in assembler anymore but they kind of want to. It takes a real change of mindset to write code for coders, not code for the machine. Of course it must run in acceptable time with acceptable resource use, but that's often a low bar these days.