Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×

Comment Re:Who knew? (Score 3, Insightful) 62

Seriously. I have a 450 mile drive ahead of me. I will be driving on Thanksgiving, not the day before.
Not because Google told me to, but because I'm not a fucking idiot.

Driving ON the holiday is much, much easier than driving the day before.

Another tip: The day before a 3-day weekend, the local news will run a story about how cops are cracking down on speeding over the holiday weekend. This is bullshit intended to scare you into compliance - police presence on the roads will be greatly reduced.

Comment Re:Ask the credit card for a refund (Score 1) 307

You're a retard. Here's how it works:

I go to my credit card's website.
I log in.
I click on the support link.
I click on the claim link.
I file a claim stating that a charge was unauthorized.
I get a letter in the mail.
I sign it.
I send it back.
I get my money back in a few days.
The merchant eats it.
The merchant has the option of taking me to court.
The merchant won't take me to court.
If the merchant takes me to court, I'll win.

Comment Re: Better go kick WSUS into a sync... (Score 1) 178

About 40% of my servers would have serious issues with that. From SAP systems to certain SQL jobs. That would be a resume writing event.

SAP? SQL? Party like it's 1999! For me, having it matter whether any given server suddenly fails would be a career limiting move. We push-restart patches to services every week or two, and if that affects a customer in any way TSHTF.

You're a dumbass if you think SAP and SQL are relics.

Further, you're a dumbass if you think redundancy, load balancing, etc. solve the problem. They add reliability to the replicated services by moving the single point of failure out to a different box (the load balancer, the VM server, the border switch, the ISP, or even all the way out to DNS) while adding complexity and cost and increasing the impact should the new single point of failure fail.

Further, they intrinsically impact customers by providing different data to different customers until shit syncs up and cascades throughout all the hosts. This isn't done with magic or tachyons - it takes time. This is why we have transactions and brokers in SQL. This is why distributed and replicated systems spend so much effort trying to make sure their clocks are synced up.
Redundancy is nice when you need to manage those services, but it doesn't solve the inherent problem. Nothing can. When a user wants X, they can't get X if is X down. They can get Y, which may or not be the same as X at the given time.

Anything handling critical transactions is redundant in exactly the opposite way from what you describe. Redundant, hot-swappable power, network, CPUs, RAM, storage, etc. for a single instance that is the arbiter of transactions from many sources. Mainframes are still around because we solved this fucking problem decades ago. Your approach is the cloud approach - make services redundant and push the single point of failure out. When in normal operation, different users get different shit at the same time - you simply can't use this model for critical transactions. When (not if) shit fails, shit fails hard. Hell, Azure just went out.

Comment Re:It's just wrong (Score 3, Insightful) 335

This.
The halting problem is about determining whether a general program will terminate or not.
When you already have a defined program (and machine in this case) in front of you for review, then you can determine whether or not it will halt, whether or not it works, and whether or not it is evil. You have to actually test and inspect it, though. You can't run it through a pre-built automated test and be sure. That is the only consequence of the halting problem.

The authors make the following leaps:

We can't know if a program will ever terminate.
(False - you can, you just can't do so with a general algorithm written before the program.)

Therefore we can't know all of the things a program can do.
(False - you know all inputs and outputs and their ranges. You can't know all possible sequences if the program runs forever, but you can know each individual state.)

Therefore we can't trust that a program isn't malicious.
(False - you can trust it to a degree of confidence based on the completeness of your testing.)

Therefore programs shouldn't be given the capability to do harmful things.
(Stupid - this isn't a logical conclusion. What if we want to build malicious programs? We can and do already. Further, if our goal is to not create malicious programs, then simply having a confidence level greater than when giving humans the same capabilities, it's already an improvement.)

Slashdot Top Deals

Intel CPUs are not defective, they just act that way. -- Henry Spencer

Working...