3amOpsGuy

I never read any of the "M" banks books but i read a few of his regular ones when i was a teenager.

I remember thinking at the time, the wasp factory was a book i'd not forget, yet i can only vaguely recall the plot and some events! Espedair Street on the other hand i can recall pretty much everything. It's funny what you remember.

I believe one of the guys behind this is Misko Hevery (of AngularJS). He's test-driven mad (which is a good thing IMO). I've been meaning to try Testacular / Karma out just because of the pedigree.

What else would you say is good about Cassandra?

I find the datamodel inflexible and often hard to work with for real world use cases. I think the tooling is immature and the hector API leaves me feeling depressed (pycassa and astyanx are quite a lot better).

All that said, I find cassandra to be fast, incredibly fast. 99th percentile on our 9Tb time series store is around 20ms on below par hardware.

Another thing i like is we've never had downtime, not even scheduled. We've had nodes fail, we've had datacentres isolated during disaster recovery tests, yet our cluster has continued on regardless (2 x sub clusters per region). Whatever way you stack it up, that's impressive. Remember with cassandra there's no load balancers or other shenanigans involved.

Garbage collection / virtual machine concerns are a red herring due to the mechanics of a cassandra query (certainly for CL < RF)

The fact that broken English is effective for recall, at least in some circumstances, totally fascinates me.

I'd love to capitalise on the idea somehow, just because its so counter intuitive I think. Although i fully appreciate it's not effective enough to replace spaced repetition or other formal techniques.

Yeah exactly, although its being met with slightly noisy press coverage which is counterproductive past a certain point. Ideally the time spent on this blog post shouldnt have been needed.

I guess there's still a positive to the weirdly over the top press coverage - and that is that more people are in a position to adopt these patches as they're released.

Full marks either way to the PostgreSQL project.

I don't buy it.

>> reason to grant license to drugs of questionable medical benefit in order to reward big pharma and its generous support of the political process through campaign contributions

Is a fair (although not proven) interpretation of the available data:

    1. Big pharma make very large political campaign contributions, sometimes via indirect routes which has the effect (even if not the intention) of disguising the funding source.
    2. Drugs are being tested against placebo, instead of the best available alternative. We know that unfavourable trial results are frequently not reported. It's fair to cast question on the medical benefit of such drugs.
    3. The final question is the FDA's motivation to approve such borderline drugs - ostensibly it's to provide options to doctors where the preferred treatment is not possible (perhaps adverse reaction in the patient or everything else has already been tried), your parent posits that it could be as favour to these companies.

While there's certainly no proof presented, i don't go along with the idea it can be cast aside as conspiracy theorist without some counter evidence.

One side needs to provide evidence - you or your parent, your parent's point is left open otherwise and your response doesn't counter it.

Ben Goldacre makes a strong case for not using placebo. If there's already a widely used alternative, surely they should test against the best currently available treatment, instead of testing against nothing (placebo).

The more concerning point Goldacre raises is that unflattering trial data goes missing, and this is completely ok with the FDA.

You know, sometimes the simpler solutions work best. I like this one.

I'm sitting here contrasting this against my normal approach* and the approach here is:

    1) easier to explain to others
    2) self documenting
    3) just as effective as running a caching nameserver

* i have vm hosts configured in CM to have a bunch of promises applied, one of them is to run a caching nameserver, these hosts are the only ones allowed to do zone transfers. The vm instances running on top of these have a promise applied which has them use their underlying dom0 for dns queries.

>> I do wish people understood why having relying only on even 2-week-old backups is unacceptable

Yes, but i'm not convinced you see that this is EXACTLY what you are exposing yourself to.

What if next time it's a (nasty) bug in git? A push causes corruption perhaps?

Drop the idea of using git itself to host the backup strategy. Switch to plain old backups, if space (or performance - i'd wager the kde git repos must total a good few hundred GB, if not more, if there's artwork or other binaries in there too) is an issue there would be nothing wrong with incrementals for the */30 min backups.

Yep and even if we do account for this, say by asserting a table lock or escalating isolation level, we can still run into problems in the case that there are triggers defined.

There is no direct substitute in PostgreSQL, but there are case by case alternatives AND as far as any use cases I can dream up right now, they have better (As in they are easier to debug, easier to observe and easier to tune - MySQL necessarily hides the update operation from you) semantics.

>> ... the backups were ...

But what you describe, is necessarily not a backup.

EDIT: redundant text removed

A delete followed by an insert in the one transaction - break into batches for a huge table?

That's really simplistic but I don't know the use case.

>> if you have backups of the relevant data

They didn't have that, or at least not recent enough backups.

Synching rather than snapshotting. It's a subtle difference (sync permits delete).

It's the docs are poor, the actual procedure is very easy.

Eg. if you installed php on apache, your process may be to apt-get or build from source a mod_php then get the relevant LoadModule line into your apache config.

For python you'd do the same, except you'd use mod_wsgi instead of php.

Part of the problem with python is there are so many ways to achieve the same thing. No doubt others are reading this and thinking "no, you should do x" - hell i'm feeling that myself as i type! This highlights the fact there just is:

    1) Too little documentation
    2) Too little info on what approaches work best in what situations

I think you might miss the point here, in the same way as the KDE SAs did.

What folks tend to consider the meat of ops work, often boils to a big ole boring checklist.

The problem is that you shouldn't just elect to skip a whole big section without some seriously good reasoning.

This isn't a slur on you or the KDE guys, hindsight is 20/20. I'm confident though that I'm not alone, that there are plenty of other Ops folks here who read the story and also felt the described setup violated a deep principle and just made feel ill at ease. These failure scenarios are not common, but the do happen often enough that we know to prepare for them.

As an example I'd point to how DBAs handle validation of replication - it's the same principle here.

Just for completeness, an example reason for not having proper restore procedures in place might be 'this is not the prime record copy of the data and it takes less than 24h to regenerate this data therefore this will be out of scope during restore tests'.

Where's the "who cares" comment for me to upvote.

Really, it's apple, they've peaked already. Show me the new cool thing.

Please don't read this as a suggestion apple is dead, it's anything but dead, in the same way Microsoft is.

Always happy to see more tools like this - the bigger the toolbox, the easier our lives are.

Of the various approaches I've had to depend on in recent memory, from perl scripts querying a central Db right through to eye wateringly expensive Control-M or Autosys in larger envs, It's plain old cron, fronted by config management (cfengine, puppet, chef, salt - it doesn't matter which) that has proven most dependable, easiest to train others on and simplest to debug.

It's one of those never ending tradeoffs. The premise of the parent comment strikes a chord with me.

We necessarily can't do terse and readable. To be terse enough we need to encode. Encode is just another way to say obfuscate, in this context anyway.

I wouldn't necessarily agree Perl asks for a programmer to write bad code (saying this as someone who left Perl because he was fed up with write-only code). I'd phrase it as Perl readily facilitates bad code.

Really impressed with the aesthetics, especially for such a quick turnaround. Had a peek under the covers and it appears to be well done there too.

Top marks in my book.

"Tech old-timers like myself fondly remember Windows NT and all it stood for"

This is just rose tinted glasses really.

Remember all the "there must be a better way" conversations that were rampant in the NT3/4 eras. If you're in any doubt, pick up any old IT magazine of the 90s and remind yourself what we were concerned about. Things that Windows 8 does in its stride: hardware compatability, backups, speed - these are distant memories these days.

Usability was a bigger problem then than now. Fewer people in general had any idea about computers - how many can recall a first hand experience of a new-start talking into the mouse as a microphone (or similar caper).

>> Eh, they're just logos

shakes head in dismay and wanders off

The designmodo logo is quite debian-esque. Maybe too close to debian's i'd think.

EDIT: https://secure.gravatar.com/avatar/7d9027189b18855f5f2ddeb7d...

Whoever down-voted you was a dick, there's still more decent folk than dicks though, just ignore it. And, have some karma back, good point for discussion above.

Would the probability not be less in this case? In general, less moving parts = less chance of outage. E.g. if a device is rated for 300,000 hours MTBF and you have 2 of them, their individual MTBF remains the same, but your chance of experiencing an outage in either one has doubled because you have 2 of them.

It's more the impact side of the risk equation i'm thinking of than the probability.

EDIT: typo

What happens when one of the fully loaded 1 million connection nodes goes bang? That's potentially a million users getting a poor experience.

Re-establishing a million connections at once is going to be hard on the network - the million were built up over a period of time previously yet now they're being re-established Big Bang style.

I still have the dead tree version and I reckon it's a great book.

>> digital motor

Just another way of saying brushless.

Excel Xlerator, that's the one i was thinking of with my meek "high airflow traditional driers".

The airblade hand driers are the only hand driers I've used that thoroughly dry your hands in a reasonable time frame. Even high air flow traditional driers don't come close to airblade driers.

They do depend on blowing from both sides of your hand at once though. This seems like it will double the drying time.