Hacker Newsnew | past | comments | ask | show | jobs | submit | sam_pointer's commentslogin

I can supply some anecdotally. I own two vehicles with reputations for running after neglected or minimal maintenance: a 1966 VW Beetle and a Land Rover.

The more correct way of characterising both would be that they will continue to run and function without ongoing maintenance (the proper level of which is way above a modern vehicle) until they break in a spectacular and often terminal way.

To attempt to answer your question, I think the general implication is that "old trucks" are designed for high maintenance intervals whereas Land Rovers, especially as used by the military, are designed to perform a function for short intervals with the long-term aid of a logistics chain.


> until they break in a spectacular and often terminal way

One bloke had his Citroen die in such a way in Africa... and had to rebuild it into a motorcycle to get out of where he was

http://www.dailymail.co.uk/news/article-2168061/French-elect...

https://m.thevintagenews.com/2016/05/18/emile-leray-built-wo...


> "old trucks" are designed for high maintenance intervals

I find this fascinating. To a layperson like me all combustion engines seem like they must be uniform. Thanks.


Nope. Not even close.

I have a 2001 Nissan Xterra that's been sitting in my driveway for almost 4 years with a blown head gasket because of the combination of lack of spare time, other available vehicles that I could drive, and the complexity of disassembling the engine to remove the heads. The seats and hatch area are now full of engine parts and I still have to finish taking off the passenger side head.

Contrast that with my 1987 Toyota pickup: I would have had the entire job done in a weekend with time to spare.


think notepad vs ms word. imagine if you had to debug one of them...


We did something very similar at EA Playfish, at least one alumni of which is part of the Uber engineering team.

We used a 2 column InnoDB-backed table for all of our data storage, massively sharded, and run in a 3-host master-slave-slave configuration.

At that time EC2 would routinely kill hosts without the courtesy of a poke via ACPI and as such we became very good at quickly recovering shards. In a nutshell this mechanism was to have the new host contact a backup slave, perform an lvm snap, pipe the compressed snap over a TCP connection, unroll it and carry on, letting replication take up the delta.

That enabled us to not only manage the 10 million or so daily active users of that title, but was also the platform under the 12 or so additional titles that studio had.

We had lots and lots of very simple things and failures were contained.

I think at the time we were the 3rd-largest consumer of EC2 after Netflix and "another" outfit I never learned the name of. EA being what it was, however, we were never permitted to open source a lot of the cool stuff Netflix and ourselves seemed to develop in parallel.


this is frikking awesome! do you have any of the lvm and pipe scripts publicly available ? i'm kinda struggling with building and setting up lvm on ec2 automatically and was wondering if there is any tidbits you can pass along.


Unfortunately not. That company and codebase is very much dead, and I don't own any of it. Even if I did it would be a bunch of context-less shell (in the first iteration) and then a bunch of context-less Chef (in the second platform iteration).

Things I do remember:

- We used ephemeral volumes for all data stores. This was pre-provisioned IOPs and EBS was flaky as heck back then. I can't remember the disk layout, although we did experiment a great deal.

- We took great pains to ensure there was enough space to make the snapshot (IIRC is was a telemetry/monitoring item)

- The pipe scripts were essentially "netcat".

The best I can offer is this talk: http://vimeo.com/57861199


No. That was the Syria/Iraq/Iran BGP outages from earlier today.


From experience, it is quite common to have internal code-names for Facebook games for the purposes of preventing leaks from development canvas apps and the like. These are usually related to the general gist of the game. To coin a made-up example, 'SimAir' might be called 'flying' internally.


My experience has been that the main reason is that development usually starts before marketing has even decided on the final name. You need to call your dev servers, code repository and bug tracker project something and it's often hard to change retroactively.

It's not even unusual to see multiple different working titles float around.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: