I think people really misunderstand Bertrand Meyer. His view of OOP is not the normal 'code reuse + do things automatically' pablum. The central point of his book, to him, the central point of OOP, is code contracts. How's that for a mind-warp?

Have you been reading the "Clean Code" book? lol (or rather, have your coworkers been reading it and berating you because of it).

I like to divide code into two categories, code that 'does stuff' and 'glue code.' The goal is to minimize the glue code as much as possible, while still maintaining flexibility.

If you follow the rule of the Linux kernel development, "Each function should do one thing and do it well," then your code will be a lot closer to flexible almost immediately, even without building a framework around it.

I think you need to be a team player in order to write readable code. By definition, writing readable code means you are thinking about how other people will understand it.

Here's some.

First level is to be able to get the computer to do what you want. If you can do that, you have a career as a programmer.

Most people don't make it that far, so it's something. The next level is whether you can write readable code. A lot of programmers never learn to write readable code, but a good number of them do.

The next step is writing flexible software. Some programmers stuff everything into design patterns and think they made it flexible, but they're wrong. Other programmers try to make everything generic thinking it's flexible, but they're wrong (also, their code is probably hard to read). But writing code where small changes take little effort, and bigger changes take more effort......that is a rare skill indeed.

There are other ways of looking at it, but that's one way.

Perhaps the research could help over time those distinctions exist and pair like-minded people together.

I thought most modern games already had systems to at least try and match players with similar skill levels.

Why not let abuse take place online in virtual environments?

Because it sucks and leads to much more offline abusive behavior by otherwise good people after they have been repeatedly harassed.

Instead, this psychology of banning and throttling likely leads to more offline abusive real-life suffering.

The opposite is true. Because the natural abuser is inclined to fight through any system thrown at them, throttling and other attempts drain their energy more than simply letting them post would, leading to more relaxed (or at least less) behavior offline.

Not to mention, we all know that trolls online are probably losers who would never in a billion years have the nerve to say or do anything offensive offline...

If you think managed languages will prevent you from leaving security vulnerabilities, you are either not writing significant server software, or your software has vulnerabilities.

The hardest security problems to solve aren't the overflows, it's the features given to users. Think of VB macro viruses, that spread wildly in a managed language. Wordpress is another example of software written in a managed language with tons of exploits.

There are so many examples of exploits in managed systems that it's a display of ignorance to claim otherwise. .Net is especially bad in this regard, not because C# is inherently more insecure, but because the community applauds and encourages ignorance, and even makes people feel bad for knowing things. See this presentation for an example. Notice (for example) his micro-agressions against people who understand garbage collection. The implication is you don't need to think about it, C# will take care of memory.......which if you take seriously, means you'll be leaking crap all over the place and someone like me will have to come clean it up for you.

Yeah, like anyone can actually read and understand OpenSSL. Perhaps it would get studied more if someone entered it into next year's IOCCC.

It was in the low 50's (about 11C) outside on game day.

The balls were found at 10.5 psi, and the minimum Regulation pressure was 12.5 psi.

So, 84% of regulation pressure means (since pressure is proportional to temp, all other things being equal) that the balls would've had to be inflated in a 338K environment. Which is 150F.

I suppose the Pats could've inflated the balls in a sauna, but it's rather unlikely that the Refs would've failed to notice that the balls were hot enough to burn them when they checked the temps before the game.

In other words, no, the Pats cheated. Did their cheating matter in the end? Nope, the Colts sucked so much that day that the Pats could've played fair and won.

Alas, playing fair isn't something they're all that familiar with.

Also, please note, it's not enough to call gethostby functions for this bug to be a vulnerability. For it to be a vulnerability, you need several things:

1) A (more or less) specific sequence of function calls. Merely calling gethostby* itself won't do it.
2) The eventual call to gethostby on a string supplied by a hostile user.
3) Have another buffer hostile users to fill (not overflow).
4) A weakness of your program structure that allows four bytes to reference the other buffer.
5) Include a service that runs things on the command line.

Exim allowed all of those. You might be able to get away without number 5 present, but the program would need some other weakness to make it exploitable.

You read incorrectly, I'll quote it again: "Most servers don't do a dns lookup of a remotely supplied address.

One of the examples they used was ping. Of course ping does a DNS lookup of the address supplied by the user, but unless you have inetd in a really weird configuration it won't be started remotely. If ping crashes, or even executes arbitrary commands because of a specially crafted command-line, it's not a security vulnerability.

Here's a better explanation of the flaw. It's actually a fairly limited vulnerability:

With only being able to overwrite 4 bytes max, you would think not much could be done, and indeed, mostly they were only able to make things crash. Most servers don't do dns lookup of a remotely supplied address, but mail-servers can, to verify the sender is correct.

Astonishingly, even without being able to write assembly shell-code, they were able to get the Exim mail server to execute arbitrary remote commands. That is the only vulnerability found so far.

People who think that Java (or C#, or Python) language will fix their security problems write more security bugs than C programmers who work around the weaknesses of their language.

Similarly, people who think Java (or C#, or Javascript) will fix the problem of memory leaks, are probably leaking memory all over the place. Recently I've been fixing a bunch of memory leaks in Javascript.....if you attach something to the DOM, make sure you have a plan for getting it off, otherwise you're probably leaking.