Blocking of ad content on the internet is a problem that the internet advertising community brought upon itself.

Huge, messy, obnoxious high bandwidth, sometimes even dangerous ads.

If the entire playing field of internet advertising wasn't as toxic as it is, we'd see a wider array of people running without adblockers.

...prolly why TFA only mentioned Amtrak employees ;)

But yes, I understand your point as well.

Question... was it an actual cut in current baseline funding, or a "cut" insofar as "we wanted $10 zillion extra for next year's budget, but those bastards in Congress only want to give us $9 zillion extra!" ?

If it's the former, I'd love to see proof. If it's the latter, then kindly take that partisan sound-bite-mimicking bullshit elsewhere.

Brings up a fun question... do Amtrak trains carry something similar to an aircraft in-flight recorder?

Dunno - it's pretty hard to account for why the dude was doing 100+ mph on a 50mph curve.

Not saying it's his fault, but at least the camera would have absolved/proven any culpability on his part almost immediately.

Now normally, cameras would be a bad idea IMHO, but this is a public service operated by public funds.

Careful! You're get foo-foo'ed by someone reward-seeking professional paper-pusher who can't even tell you what a confidence score is or why it's important in their data..

Doesn't matter. The consumer ends up paying for it in the end.

I honestly wish these mega-mergers in cable would just be stopped. Flat out.

And before someone starts quoting combined numbers of Comcast+TWC vs Charter+TWC, understand this. The final number of subscribers is largely irrelevant due to geographic monopoly.

We have enough of these mega-monopoly ISPs as it is. And all the mergers do is concentrate the money so they can afford bigger and bigger bribes to buy a permissive atmosphere in which the best interests of consumers/constituencies are not looked after.

And the only recourse? Try to vote out these money-grubbing incumbents with their newly marble-lined solid platinum warchests...

You may know the quote: "Premature optimization is the root of all evil," but the whole quote in context explains why it is so:

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
- Donald Knuth

In fact, it takes an experienced eye to know when and where to optimize, to identify that critical 3%. In the meanwhile, novices are so worried they'll miss it that they try to overoptimize everything, not having the experience of maintaining programs written in that way.

So when you see that sort of pattern abuse, especially naming classes after patterns, like -Facade, -Decorator, -Adapter, -Mediator, (and -Mixin depending on the language) realize that what you're dealing with is a novice's code, written by an amateur with no clear understanding of the entirety of their job, and adjust your expectations accordingly.

That may explain why it's still around even after it's been technologically eclipsed, in a similar vein to Java.

They're not around because they're easy to read or the choice language or any other criteria that would make sense to a developer, but rather because there was a corporate investiture. Money spent means more to a business than other metrics.

Unfortunately, so are the libel laws... interesting that TakeTwo specifically went after trademark and not libel (especially in the UK!), isn't it?

Depends... TakeTwo may have trademarks registered in the UK.

Thing is, if the film were an actual documentary instead of a dramatic play, one could easily claim "because journalism!" and then tell TakeTwo's lawyers to go pound sand.

Yeah... thinking the same thing. Without some sort of participation or backing from established researchers and vendors, this was pretty much a non-starter.

At this point, it's pretty much moot.

The tools are already out there.

Cutting off now accomplishes JACK SHIT. And all the tools will simply be mirrored outside the US.

The especially bad part? Look at the whole encryption export debacle.

Basically most of the meaningful security jobs and development will move outside the US.
Sure, we'll have in-country development, but it'll be happening in a vacuum, as nobody else will want to touch development of tools they can't legally use.
Meaning that security tools in general will stagnate in the US and slow down elsewhere as they have to now gear up for development without using resources inside US borders.

Agreed.

The whole "convention over configuration" theme is maddening, because if you don't know the conventions - or haven't figured out the new conventions that a particular project uses to drive execution and data flow, you're going to be lost. What is gained in brevity is added cost on the maintenance side. I once spent 2 days helping someone troubleshoot a currency formatting issue on a RoR app; someone had created a mixin to extend a base string class method, in a file describing a service. Fixing the code took all of 5 minutes, but finding it took forever.

With Java, it's worse now than it used to be. A decade ago, your major threat to readability was someone with pattern prejudice; those who ended up encapsulating everything in a factory-factory to factory to interface to abstract to etc, etc, etc, making every data object change require changes to 5-10 files just to surface the changes to the end methods using it, just for the sake of doing it.

Today you've got stuff like Spring. Ever try to do a manual, non-runtime code analysis of a project of decent size that heavily uses Spring, even where it's not necessary (like interfaces that will only ever have a single implementation)? Or worse, have you guys seen the OSGi development model? Let me put it this way; imagine using the original J2EE bean model, with home and remote interfaces and all that, only we've decided to use CORBA as our architectural focus. So every method can be a dependency-injected service-provided module, ready for you to call the service factory and grab an instance of the feature you want, which incidentally makes static analysis of code by humans more or less impossible.

Yes, I understand the concepts for these features, and OSGi actually has some neat capabilities (that we've had since the mid 90's via similarly laborious mechanisms like CORBA or more often, DCOM), but they do detract heavily from both the readability and maintainability of the code. If a new developer can't determine the execution or data flow for a given scenario in a few minutes, it's going to be onerous for them to maintain the system. That pain for the benefit of what we all know is the patent myth of polymorphism; that every project is going to have a need for unplanned sibling code modules in the future - it doesn't seem like a good trade off to me.

I've started to really appreciate code that I can use tools - often just the 'find in files' feature of an IDE - to trace through execution and data flow. It's becoming less and less common, and sourcing and correcting bugs is taking up more and more of my time because of that rarity. I sometimes look back on 'tricky' C code that uses/abuses pointer arithmetic and requires complex memory management, and I feel wistful for when it was that simple, that you could know what the code was actually doing. .. aww crud. I'm like a few years away from complaining about those darn kids on my lawn, aren't I?

No, no, don't get too excited: It was just a copy of Visual Basic 0.99 that some hominid left lying around.