skysight-inc/HackerNews huggingface dataset:
While testing would have been quite difficult, any simple canary release or timed release mechanism would have prevented this / limited the damage. At such mission critical systems, applying any global change in a such manner is asking for it, Devops can also be SPOF, this seems one such case.
Yup. People seem to be overly critical with automated car failures.

Personally, i think automated cars are going to easily be better than humans in the working cases (both human and ai are concious). Next, i expect to see fully operational backup systems.

Eg, if a monitoring system decides that the primary system is failing for whatever reason, be it bug or unhandled road condition (tree/etc), the backup system takes over and solely attempts to get the driver off the road, and into a safe location.

Humans often fail, but often can attempt to recover. And, as bad as we may be at even recovering, we know to try and avoid oncoming traffic. Computers (currently) are very bad at recovering when they fail. I feel like having a computer driving, in the event of failure, is akin to a narcoleptic driver - when it goes wrong, it goes really wrong. Hence why i hope to see a backup system, completely isolated, and fully intent on safely changing lanes or finding a suitable area to pull over.
Thank you for the detailed reply. I didn't mean to imply aws/spark was the wrong tool for your workload - was just curious about your comment on trying on a big ec2 node w/o mentioning dedicated HW.

Judging from comments I've seen online, many people appear to be unaware of the overhead aws introduces. That doesn't mean one shouldn't use aws, just that one should be aware of the tradeoffs :-)
It also showcases the great thing about self-driving cars. Even though accidents will happen, when it does there will be plenty of sensor data and logs which can be examined to find the exact cause in a post-mortem. An improvement to the software can then be made, and millions of cars deployed can all effectively learn from a single accident.

With humans, the amount of knowledge gained and the collective improvement of driving behavior from a single accident is low, and each accident mostly provides some data points to tracked statistics. With machines, great systematic improvements are made possible over time such that the remaining edge cases will become increasingly improbable.
> More to do with comfort vs. performance than gender.

Could you expand on that? Which bikes are on the comfort side and which ones on the performance side of the tradeoff?
not all young people use a vocal fry; it is learned; it is increasing; a lot of people find it annoying.
This was somewhat expected after Microsoft released a first-party React Native plugin for their Visual Studio Code IDE a couple weeks ago:

https://github.com/Microsoft/vscode-react-native
The current bar is just anything not in the genus Homo and would likely extend to any 'humanoid' species.

A wolf doesn't really care about the relative intelligence of the rabbits it kills, but has a natural kinship between other wolves or wolf-like creatures which more-or-less extends to, "I wont kill you for food unless I'm starving."
> Off-Topic: Most stories about politics, or crime, or sports, unless they're evidence of some interesting new phenomenon. Videos of pratfalls or disasters, or cute animal pictures. If they'd cover it on TV news, it's probably off-topic.

This is about politics. It is off-topic. You can argue how the rules are written, but as they currently stand, this is off-topic, by definition.
CaptionBot doesn't really know what to make of Winged Doom: http://imgur.com/86uwKfa
You can test it against the actual network; if something goes wrong, you'll have downtime, but you'll be prepared to get it all back up.

Or, to test whether the "prevent errors from going to new places" works, temporarily configure the new places to ignore new configs; if the system works, no messages will be sent there; if the system doesn't work, they ignore the message and you learn about a bug.
I have to say I agree with the casino's lawyer:

"Baccarat is a game of pure chance," Christopher Pymont, Genting’s lawyer said in court. "It is not a game of skill, it is not a game of mixed skill and chance."

"You are not supposed to know what is coming out of the shoe," he said. "Those are the rules."

That said, the court doesn't seem to agree that it's quite so cut and dried, essentially saying that if Ivey didn't have the croupier rotate certain cards for him (manipulating the cards via the croupier) and instead had some other method of identifying high and low cards then it would not have been cheating.

Of course, as Daniel Negreanu puts it (bluntly): "Big fish sets all the rules, okays all the rules, they need to eat it when they get beat and not be whiny biatches about it."
It does feel a little unfair; I have a huge advantage, no doubt.

I basically tried every other method I knew of, even encouraging Kyle to file the suit under seal to keep it private as long as possible. When the guy stopped talking to me, and to Kyle, and to Ron, and Cruise need to proceed with the lawsuit so that they could close the merger, I felt out of options. Today they lifted the seal on the suit.

And, I think it's time people talk about these things publicly. They are a rising undercurrent, but I would have preferred to talk about them in the general case.
Fortunately, ideas and attitudes are contagious between groups of people.
What's so bad about prefacing the meeting with "Sorry guys I'm expecting a call at some point today so if my phone goes off I'll need to leave to answer it"? Some people must surely be expecting calls from someone of an unknown number every day individually, but I would be surprised if it was a large number of people.
The first one is alarm fatigue. Like the "Terror Thermometer" or whatever its called where we're in eternal mauve alert meaning nothing to anyone. All our changes are color coded as magenta now. Or its turned down such that one boring little ip block isn't a major change. After all, it isn't. Of course you (us) developers could run crazy important multinational systems on what to us networking guys was one boring little IP block who cares about such as small block of space.

The second one is covered in the article, their system for that purpose crashed and then the system that babysits that crashed and then whatever they use to monitor the monitors monitor system didn't notice. Probably showed up in some dude's nightly syslog file dump the next day. Oh well. If your monitor tool breaks due to complexity (as they often do) it needs to simplicate and add lightness not slather more complexity on. Usually monitoring is more complicated and less reliable than operating, its harder computationally and procedurally to decide right from wrong than to just do it.

The odds of cascaded failure happening are very low. Given fancy enough backup systems that means all problems will be weird cascaded failure modes. That might be useful in training.

When I was doing this kind of stuff I was doing higher level support so see above at least some of my stories are weird cascaded impossible etc. A slower rollout would have saved them, working all by myself I like to think I could have figured it out by comparing BGP looking glass results and traceroute outputs from multiple very slowly arriving latency reports to router configs with papers all over my desk and multiple monitors in at most maybe two days. Huh, its almost like anycast isn't working at more sites every couple hours, huh. Of course their automated deployment is complete in only 4 hours, which means all problems that take "your average dude" more than 4 hours of BAU time to fix are going to totally explode the system and result in headlines instead of a weird bump on a graph somewhere. Given that computers are infinitely patient, slowing down the rollout of automated deployments from 4 hours to 4 days would have saved them for sure. Don't forget that normal troubleshooting places will blow the first couple hours on written procedures and scripts because honestly most of the time those DO work. So my ability to figure it out all by myself in 24 hours is useless if the time from escalation to hit the fan was only an hour because they roll out so fast. Once it hit the fan a total company effort fixed it a lot faster than I could have fixed it as an individual.

Or the strategy I proposed where computers are also infinitely fast, roll out in five minutes, one minutes to say WTF, five minutes to roll back, 11 minute outage is better than what they actually got. Its not like google is hurting for computational power. Or money.

I'm sure there are valid justifications for the awkward four hour rollout thats both too fast and too slow. I have no idea what they are, but the google guys probably put some time into thinking about it.
I think you may be overthinking 3 a bit. You only need to use the new bot enough to get enough info for the normal ranking method to work. Some simple solutions:

1. When a new bot is added, always use that bot first. This assumes that the user added it intentionally despite already having bots for that function.

2. If bots are ranked too closely, pick one at random.

3. If bots are ranked too closely, ask the user which to use. Have an option for setting that as default. If you have an Android phone this should feel familiar. This is how Android handles different apps that handle the same function (i.e. what app should open when you click the mailto link).
Organized labor creates an opportunity for collusion between management and the union leadership. My grandfather was a union worker who his colleagues selected to represent them. Management offered him the opportunity to make several times what he makes as part of a deal that would give the others negligible increases. He declined, but I have met union workers who complain that the union leadership and management collude. Knowing what happened to my grandfather, I do not doubt it. If you have an employer that intentionally undervalues you, they are going to aim to use the union to ensure that they continue to do that. If collectively people overvalue themselves, they tend to get their positions terminated by outsourcing.

If people think they are underpaid, they should each ask management to correct it. If management does not value all or some of them enough to do that, those that are undervalued are better off leaving for greener pastures.

That being said, after a certain amount of income, more income does not equal happiness. Rather than be a slave to trying to get more, I am inclined to ask myself if what I am doing is worthwhile, if what I make is over the minimum required for happiness and if what I make is fair under the Nash Equilibrium. If all are yes, I am fine with it. Others might be happier if they do that too. If they are working in an industry that pays below what is necessary for happiness (and this probably increases with dependents), they should find another career.
Has anyone ever run :help iccf?

Remember to donate to uganda guys it's the only thing Bram asks for in return for this software.
better test -- if you have seldom-exercised edge-case functionality that you can't figure out how to test, remove those features.
What does a failed autopilot look like? Would a pilot do any better with an "aerodynamic stall"? I know little about planes and it seems like that'd be a big problem with or without a pilot driving.
The status of the biggest API in healthcare
What would happen if someone had the Tesla for databases? What if it had a way to query data that was also vastly better and simpler? (This wasn't mentioned in passing in the comments on our application since we're not ready to show it, but it exists and is reflection of the language.) If you squint you could imagine that taking off and eating a large portion of the market.

Now let's take a random situation: You have a business that makes widgets. You have customers, suppliers, parts, etc. Do you store that information in Word as text? Of course not. You either have a spreadsheet or database, right? Text is great for a novel or a poem... but not for data. That would be crazy.

Currently, the web is still a big collection of text documents. How optimal is that? Deeply sub-optimal. The number of people going to the Google homepage is declining because people are now just going directly to the database that represents what they're looking for. Looking to buy a home? You go to Zillow or Trulia and query their database. People want data, not text. 95% of the web wants to be data.

Now imagine if that company mentioned before had significant market share. The authentication is common across all of these databases, they all have the same API (the language), and so instead of appearing as many databases, it appears as one large database of everything. Suddenly a network effect kicks in and if you have something you want to be discovered (which is what the web consists of) it makes sense to join in.

The next Google won't be better text search but instead something completely different -- it will be data. And the web will become essentially a massive database. I don't know who will get there, no one can know, or how it will happen, but it will happen; it's waiting to happen.
He's a highly intelligent person who has been around the block a few times - I'm not exactly sure how old Elf Sternberg is, but he had already been a net.luminary for some time back when I first discovered usenet. He's not saying "this is stupid" because it's new and different; he's saying "this is stupid" because he's seen this particular decision made before, and he has a pretty good idea where the story is going to go from here.
They don't have to be safer than driving is today. They can be significantly less safe while still being an improvement for society because drivers will be able to focus on other activities while travelling instead of wasting that time focusing on driving the car.
I am very familiar with that process myself. :)

While a cached intermediate for offline use is a very real possibility, providing top quality service without use of our server system would not be feasible with the current device market. Server-side we can use hardware that is optimized for this kind of processing, without being constrained by device or browser limitations. Without that the service quality would degrade sufficiently to tarnish our product’s image and turn people away.

One example of this is the one you provided: the quantity of training required for accurate answers. If we need to keep this metric tight, relying on random ARM processors and sandboxed single-threaded javascript is not the way.

Datalba’s CEO is in the process of collecting early test users, and has been receiving large quantities of test media for use with the prototype from several of them.

Yes, there are many opportunities in the enterprise market for this. The immediate interest is in bringing a quality service to the world that many people will benefit from. The needs of enterprise customers are largely a subset of that goal, and the parts that aren’t can be handled in a given contract or agreement.

We have been working with and building on the latest in deep learning research, and have become quite proficient with designing and building these technologies.

While we will undoubtably be exploring payed options, I fully expect that to make this product a real success that there needs to be as few barriers to access as possible for the user. Degrading accuracy based on a paywall, the most seemingly economical choice, would alienate the majority of users before they have a chance become highly engaged.

Additional value-adds such as auxiliary services could be monetized, but so far we have managed to collect a number of expressions from consumers that this leads to a very ‘pushy’ presentation. While more market data is needed, it is clear this is territory that should be tread lightly.

The remaining option that is most clear is to monetize in ways that don’t directly make demands of our customers. It would be possible to produce very sophisticated market data from the information our service will collect, something that our partners are likely to find very valuable.
Contracts will not prevent people from using leverage that they have or being opportunistic. It's helpful for sure (just like locks on your house are). [1]

[1] This comes from experience in business (traditional business) for more years than for example SAMA has been alive with a wide variety of characters.
YouCompleteMe (a vim plugin) uses clang to understand C++ code.
Absolutely.

Many of my friends look at me as if I just lost my mind - "but, but... low interest rates are good for everybody, right?".

It is an uphill battle, but I keep at it :-)
I didn't know legal documents could be funny.

"Mr. Guillory emerged from the shadows with his hand out within days of the March 11, 2016 news that General Motors Company (“GM”) intends to acquire Cruise. As explained below, Mr. Guillory should put his hand back into his pocket; he does not have any stake in the Company."

Maybe Jeremy could go build his own company. There's plenty of wealth to create, you don't have to take.
Spit balling here...

For progressive rollouts, what if config changes where pulled instead of pushed?

Each system would be responsible for itself updating, verifying (canary, smoketest, make sure other systems successfully updated, etc), bouncing, and then rolling back as needed.
The author's choice of video games to compare is extremely disingenuous. He says:

"When a quality game releases it sees a spike in usage and attention but is then shelved as players move on to the next thing. Such as Portal, Braid, and Dragon Age. However, some games break this cycle and go on to become highly valuable and lasting franchises; games like Counter-Strike, Minecraft, and League of Legends."

Portal, Braid, and Dragon Age are all single-player games. Counter-Strike, Minecraft, and League of Legends are all multiplayer games, and the latter two continue to receive significant updates from their developers.

There are very few single player games that manage to have staying power, to be replayed again and again. Halo and Half Life both managed it for a while, but no more.

On the other hand, multiplayer games tend to last for a pretty long time, unless their players are cannibalized by another game in the series (Call of Duty, Battlefield).

That said, there are definitely fads in gaming. Look at something like DayZ or Left 4 Dead 2. The "zombie shooter" game seems to have gone out of style, and these games haven't held up as well as something like LoL, CSS, or TF2.

Oh, and of course the ultimate game with a community is Starcraft. People still play Brood Wars today.
Meta: What's with all the down-voting these days? Down-voting is not for disagreeing. If you do, engage the debate.
Currently, it's a fork. Do you have plans to merge it in the main react-native repo? When?
We've had memory safe, high-level languages, top notch crypto and secure, verifiable operating systems for more than 30 years. Other than crypto, none of these innovations have been adopted beyond small niches. The real trend (think IoT) seems to be to deploy more connected devices that are less secure than what came before. I think hacking has a bright future.
If you are thinking that the lawyers wouldn't want you to say something you probably should have not barged ahead and become public with this type of situation. What do you expect will happen exactly? That the "aggrieved" party will read it and have a change of heart?
chaos monkey?
Android users: do you get a lack of memory/resources error when you try to take a pic instead of selecting from gallery? It is a silly bug where the camera activity kills the browser activity that called it.

Google: we cannot move forward with 'Progressive Webapps' if you guys don't fix these silly bugs.

Take-picture-do-something is a common feature of webapps like here Mr CaptionBot!!
Using separate programs like eqn. (http://www.kohala.com/start/troff/v7man/eqn/eqn2e.ps)
I do not see how. You need to want to do it and if you want to do it, you will find a way. Not everyone cares about OSS enough to want to do it.
Thanks for the thoughtful questions. Here are my thoughts on your questions

1. The incentive for a developer is to get better exposure. This is working with the assumption that the metabot has a larger userbase than individual chatbots. In general, the incentive is similar to what causes an online store to setup a 'store' on amazon's market place or retail sites to list on a price comparison engine.

2. As regards the second point, my thoughts when writing the was that it will infact be a direct pass through i.e. the metabot will not need to bother about the structure or nature of the requests/response but will instead focus on knowing about the bots and their capabilities. If it does this effectively, it theoretically pipes all requests for a specific task to the same bot to complete. This comes with it's own complexities as well.

3. To rank bots in the same doamin, an option is to guage the satisfaction of multiple users of the bots. For instance if a bot is faster to complete a flight reservation and the 'user' confirms to the metabot that it is satisfied with the service, that's a positive signal. This can be compared across multiple bots to measure the effectiveness of each bot.

4. Indeed, I agree it will be challenging. But I think the challenge is less of structuring the queries. If the meta-bot acts primarily as a pipe, its most important task is to identify who handles what and know the state of the conversation.

There are a lot of kinks to be worked out though...
I doubt the commenter means that, since the word "should" implies ethical reasoning which is presumably not a capability of most non-humans.
yeah, but isn't it in a similar way as to how a human is a 100% cellular endeavor?
GCE downtime just means people lose money, it's not life-or-death. Skimping on QA in order to reduce costs and get to market faster is a perfectly reasonable decision when the consequences are so mundane.
Since I am on a roll, toss out "engineer" and go with "developer" or "programmer". In the world of real-honest -to-Uncle-Bob-engineers, a senior engineer has a license and is often legally responsible for the work done under their supervision to the point of direct personal liability. That's why in a Civil Engineering context "I,II,III" make sense, there's a progression of credentials and responsibility.

Choosing "engineer" also says something about culture. Combined with a no formal credential job description, there's a cultural tension.

Incidentally, I gave up on a meaningufl use of "architect" years ago.
Unfortunately, it suffers from the huge problem of not having any comments, which was what the original poster was pointing out. Configuration is code that happens to be interpreted at runtime. Having to dig through uncommented code at two in the morning sucks, especially when you're trying to figure out why your automated code and/or config generator just failed. Yes, having to write a config file by hand sucks, however, there are still enough cases out there where you end up having to do just that, and JSON makes the problem of keeping them lucid all the more difficult.
man pf.conf .. always works :)
I am personally using tcng, which is a configuration language that already makes tc much more usable.

tcng on $ourceForge: http://tcng.sourceforge.net/

Source code mirror by Debian (if wary of downloading from $ourceForge): https://packages.debian.org/source/wheezy/tcng
I am happy to hear that. :)
Pet Cloning Service