Amazon hired employees to tweet nice things about it - <AUTHOR> https://www.sfgate.com/technology/businessinsider/article/amazon-fb-ambassadors-program-pay-nice-things-13182172.php <comment><USER2> Astroturfing is a big problem because it poisons the entire well - people stop trusting the entire system and then eventually move on to something else. Without strong moderation or social mechanisms ("Prove you're not a cop!") all anonymous or near-anonymous social networks eventually run into the problem of getting flooded with bad actors, all the reasonable people leave, and then the network is left with nothing but bad actors playing in the muddy remains.

A well crafted post in HN can make a lot of money, and it is happening every day. Its only because of the strong moderation here that those posts are either taken down, or are already indistinguishable from being a regular post from a well-meaning person.

</comment><comment><USER3> [https://news.ycombinator.com/item?id=17831943](https://news.ycombinator.com/item?id=17831943)

[https://news.ycombinator.com/item?id=17835871](https://news.ycombinator.com/item?id=17835871)

</comment><comment><USER4> "While Jeff Bezos' wealth has increased $260 million every single day this year, he continues to pay many Amazon employees wages so low that they're forced to depend on taxpayer-funded programs such as food stamps, Medicaid and public housing to survive"

Privatice profits, socialize loses. Amazon has a PR problem with its employees, but the rest of the citizens should be also worried because they are paying for it.

</comment><comment><USER5> Not surprised in the slightest.

Political candidates already do this to minimize their weak points and capitalize on their opponents'.

Countries already do this to save face when they're doing something that purchases bad will, like killing folks at a border wall.

There's no way to tell whether a comment on the internet came from a hireling, an outsourced firm, a bot, or a real person who genuinely feels or believes what they're saying.</comment>


McMenu: Do-It-Yourself McDonald's Restaurant Recipes - <AUTHOR> http://www.epicconstructions.com/mirror/mcd/ <comment><USER2> I always figured these fast-food-at-home things were more for novelty than anything else. I mean, here's a recipe:

      1. Purchase fresh ground beef.
      2. Cook it up.

...that is ~100 percent guaranteed to taste better than anything MCD's will give you. Add thousand island if you're picky.

<comment><USER3> Someone always feels the need to say something like this these days, when McD's is being discussed. If we call ourselves hackers we should question everything and notices the meaning behind these weird social rituals.

Please don't be offended, I do it too and am not claiming to be above you.

My take is that McD's is currently the symbol for poor people food. Poor people are both money-poor and time-poor, so fast food is one of the few options they have.

When people criticise MCD's, they are usually just signalling that they are not poor.

<comment><USER4> There are tons of good for you, cheap, quick to make meals if you have access to the most simple kitchen. A simple salad, sandwich or bowl at spaghetti at home is cheaper at McDonald's and much better for you. Lack of time shouldn't be a justification for fast food. When I worked in an office it would take longer to go out and get food than it would for me to pack a lunch and eat at my desk.

<comment><USER3> Sure, but they don't give you the serotonin rush that McDonald's does. The fat+salt+sugar+carbs+MSG combinations is a very affordable drug these days. With more resources you can adopt healthier pleasures. Poor people don't have that luxury.

It's very easy for people with confortable lives to prescribe rational choices for the less fortunate, as if they were characters in the sims. But they are human beings with all the usual human flaws like the rest of us, and they want their day to be less miserable, like we would.

<comment><USER5> Please don't perpetuate the myth of the MSG placebo effect here. It's a cultural meme with no basis in science [1, 2]; glutamate is widespread [3], yet nobody complains of "green tea headaches".

[1][http://www.sciencedirect.com/science/article/pii/02786915939...](http://www.sciencedirect.com/science/article/pii/027869159390012N)

[2] [http://onlinelibrary.wiley.com/doi/10.1111/j.1745-7599.2006....](http://onlinelibrary.wiley.com/doi/10.1111/j.1745-7599.2006.00160.x/abstract;jsessionid=FB418E2F4DBF2C5491A20CD9296B9E89.d04t03)

[3] [http://en.wikipedia.org/wiki/Glutamic_acid_%28flavor%29#Conc...](http://en.wikipedia.org/wiki/Glutamic_acid_%28flavor%29#Concentration_in_foods)

</comment></comment></comment></comment></comment><comment><USER6> Problem is these recipes are only a guess at what is in most things, and others they only suggest similar tasting items. None of these are spot on exact, and Mcdonalds differ the ingredients in many things based on region and country. For example , where I live they use beef in the sausage patty and not pork. So really all this is , is an "alternative" recipe book for things maccas sell.

</comment><comment><USER7> I wanted to make McNuggets from this but im stuck in the shop looking for

       1/2 teaspoon Accent?#060;/nobr>

<comment><USER8> It says that's monosodium glutamate ("MSG"), a somewhat controversial flavor- enhancer. See <http://en.wikipedia.org/wiki/Monosodium_glutamate>.

You should be able to find it in any decently stocked grocery store, I'd imagine.

If that fails check any Chinese/Asian food stores, they often have it in larger packs.

<comment><USER7> To be fair, I was poking fun at the encoding in the document.

That being said, where I live this is called E621, but I probably wont rush out in search for it, I dont even particularly like mc food :\

<comment><USER8> Oh. It was just a single '?' the first time I read it in the article (i.e. "Accent?"), so I (of course) assumed your quoting was making it even worse, but ignored that. :)

</comment></comment></comment></comment><comment><USER9> That is a lot of MSG!

<comment><USER10> Heck yeah it is. I don't know anyone who keeps Accent / MSG on hand...

These are simple recipes, and I think the value to people who enjoy this style of food is learning about how to do the onions, where a bit of mustard or Miracle Whip comes in, etc. Most people would not put mayo on a burger nowadays, but it can add a lot (and provides a nice moisture barrier).

<comment><USER11> I keep MSG on hand for all dishes that involve meat. It's easy enough to get at most Asian/Indian stores and when combined with properly seared meat, is amazing.

</comment></comment></comment><comment><USER12> I prefer just briefly frying a steak, and using a nice fresh baguette for bread.. So much better!

</comment><comment><USER13> I dont know about the deluxe sauce in USA , but here in france it is awesome , always wondered how it is made.</comment>


One in Ten Adults in US Has a Food Allergy, but One in Five Think They Do - <AUTHOR> https://neurosciencenews.com/food-allergy-belief-10429/ <comment><USER2> See the full paper, but expect to be disappointed in that too. [https://jamanetwork.com/journals/jamanetworkopen/fullarticle...](https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2720064)

There are strong hints in the paper that the authors believe only IgE-mediated reactions kill, and that this unspoken assumption undergirds the whole paper. This is false, other histamine reactions cause edema and kill, and at least one non-histamine reaction (Bradykinin) can kill as well.

In any case, it's very unclear how they managed to distinguish "false" allergies, unless by rates of IgE reactions.</comment>


Crime Over Time: Visualizing Crime Data in Chicago - <AUTHOR> http://www.socrata.com/blog/crime-time-visualizing-crime-data-chicago/

<comment><USER2> Well, I'm not sure what the point of this was. My team at the Chicago Tribune has been working on visualizing and explaining Chicago crime data for quite some time. Here's one of our biggest projects, which pulls in (I think) the same data Socrata used, as well as our own tracking of shootings, homicides and suburban crime data: [http://crime.chicagotribune.com](http://crime.chicagotribune.com)

How we built it: [http://blog.apps.chicagotribune.com/2013/02/28/the- chicago-c...](http://blog.apps.chicagotribune.com/2013/02/28/the-chicago- crime-site/)

More about the suburban crime data: [http://blog.apps.chicagotribune.com/2014/01/31/displaying- cr...](http://blog.apps.chicagotribune.com/2014/01/31/displaying-crime-data- for-chicagos-suburbs/)

Hopefully one of my coworkers will join in here who's more knowledgeable than me, but remember crime data, such as what Socrata is displaying, is just a snapshot of crimes that have been reported. It could mean those crimes were just more enforced at that time, or more people decided to report crimes, etc. It is not a crime victimization survey.

</comment><comment><USER3> It's always really important to understand what you're analyzing when dealing with crime data. In this case this is when crimes are reported or when arrests are made. That's not the same thing as when the crime occurs. So the spikes for burglary in the morning and at lunch hour are more likely because that's when people notice the crime has occurred and call the cops, not when someone is actually breaking in. And the prostitution trends are probably when the cops are choosing to be out and about arresting, which might not at all be correlated with when the most illegal activity is actually happening.

It's interesting that the author thinks the spikes on the first of the month are bad data, but that the huge spike in sexual assault on Jan 1 of each year is valid data. I wouldn't doubt that there are slightly more sexual assaults on new year's eve, but on the order of 10x more than any other day of the year? That doesn't seem right. I'd guess there are more nuances about how sexual assaults are reported or logged that are at play here.

</comment><comment><USER4> I did (some of) this with chicagocrime.org in 2005... :-)

...and I've since learned the error of my ways. It's just too misleading to do these types of overly simplistic data reports. The data set is flawed in many ways, including:

* Data model. The Chicago crime data only has a single date/time field. For many crimes, such as break-ins, the victim/reporter isn't able to pinpoint an exact time; they might just provide a time _range_. That doesn't jive well with the data model.

* Data mistakes. I dealt with public record databases extensively from 2005-2012 (Washington Post, chicagocrime.org, EveryBlock). Government data sets (like any data sets!) contain mistakes, which are compounded when you do aggregate queries.

* Systematic police department effort to reduce crime numbers through data trickery. See the amazing recent piece by Chicago Magazine: [http://www.chicagomag.com/Chicago-Magazine/June-2014/Chicago...](http://www.chicagomag.com/Chicago-Magazine/June-2014/Chicago-crime-statistics/)

All in all, obviously this post is harmless link bait at face value, but more thought should be given to these issues. Open govt. data is a good thing, but it's healthy to be skeptical.

(Note chicagocrime.org is no longer around, as I redirected it to my other project, EveryBlock, several years ago: [http://www.holovaty.com/writing/chicagocrime.org- tribute/](http://www.holovaty.com/writing/chicagocrime.org-tribute/))

</comment><comment><USER5> The presentation of the data is extremely confusing, especially with the lack of titles and axis names. Does each bin between each month represent a year from 2001 to 2013? On some charts, like narcotics and criminal sexual assaults, you switch to weekly bins with no indication at all.

<comment><USER6> I was going to say the same thing.

I don't know how to say it without coming off overly negative, but those graphs read like textbook examples of what not to do.

Thankfully, there's no shortage of good, free resources for learning these things [1].

1: [http://datasciencemasters.org/](http://datasciencemasters.org/)

</comment></comment><comment><USER7> Socrata and Statwing are both very useful services, but without some domain knowledge and a good understanding of how the data was collected, even the best tools won't get you valid insights.

</comment><comment><USER8> What's with the spike in sexual assaults on the first of every month? Some reporting artifact?

<comment><USER5> I checked the data myself and I believe it's a coding error on his end. I'm not seeing a spike in December or January for Criminal Sexual Assaults. (it's worth noting that using a month function on a null date usually results in a 1 being returned (January))

Here's what I'm seeing with the data: [https://www.icloud.com/iw/#numbers/BAJdMdQ8oUn9yYC- REmBpZlzD...](https://www.icloud.com/iw/#numbers/BAJdMdQ8oUn9yYC- REmBpZlzDDlXE7j3N3SF/Criminal_Sex_Chicago)

<comment><USER9> What's wrong with this link? It says Firefox (v29.0) is not supported and if I chose to ignore that, an error occurs.</comment></comment></comment>


Uniscoot Hovercycles (electric unicycle) - <AUTHOR> https://uniscoot.com <comment><USER2> > You must follow all applicable local laws.

I love how the video shows someone riding this thing on the sidewalks in SF, when this is not following applicable local laws.

<comment><AUTHOR> Its allowed on some SF sidewalks (e.g. near the Embarcadero) at slow speeds and all sidewalks if you are under a certain age.

It can be operated as slowly and safely as a wheelchair and the SF cops won't give you any trouble if you go slowly. I am not a lawyer and this is not legal advice.

I am currently working to petition classification of this new class of personal transporter for sidewalk use.

<comment><USER2> > if you are under a certain age.

The age is 13, and the person in the video was not.

> Its allowed on some SF sidewalks (e.g. near the Embarcadero)

There are shots of civic center, and market street.

> It's can be operated as slowly and safely as a wheelchair and the SF cops > won't give you any trouble if you go slowly.

It can also go 12MPH? I am less worried about the rider going slower than the pedestrians that are endangered by the rider.

<comment><AUTHOR> > It can also go 12MPH?

So can many motorized wheelchairs which are much larger and arguably more dangerous.

On Market street I often see people going over 10mph on large motorized wheelchairs with heavy speakers, which is an obvious safety hazard.

Safety has a lot to do with the speed at which you use your transportation devices and the amount mass in motion.

<comment><USER3> He/she seems focused on following the law and you seem focused on skirting the law. I don't think "people in wheelchairs can do it so why can't I?" is a good look.</comment></comment></comment></comment></comment>


How iFixit Became King of the iPhone Teardown - <AUTHOR> https://motherboard.vice.com/en_us/article/7x4wxx/ifixit-iphone-x-teardown-behind-the-scenes <comment><USER2> I wonder if they buy stock than.</comment>


Ask HN: Do generic landing pages ("we create solutions") work? - <AUTHOR> When looking for work I often find it difficult to figure out what a company does, because they just say they make "solutions to create business value."<p>Are those considered effective and what is the thinking behind them?<p>(This mostly happens with agencies/consultancies.) <comment><USER2> Probably not.

It is hard to advertise a consultancy because you are generally under N.D.A. and if you really helped Company X improve margins by 35%, the last thing Company X wants is for Competitor Y to improve margins by 35%.

The dominant paradigm in software development is "gather requirements", "design something", "code it", "test it", "deploy it" and it is a pretty bad paradigm with a 2/3 failure rate in the field.

However, customers seem much more comfortable to stick to something familiar rather than follow a highly opinionated approach which is best of breed for some particular range of problems.

Many companies like that also have a sales approach which is driven by person- to-person sales and the goal of the web site is not to "knock people's socks off" but rather to not introduce any additional objections. (i.e. it is all black because the even though the head salesman is the most conventional guy you've ever met, the web designer is a lolligoth.)</comment>


'Spot': A Robot That Could Help Doctors Remotely Treat Covid-19 Patients - <AUTHOR> https://www.npr.org/sections/coronavirus-live-updates/2020/04/24/844770815/meet-spot-the-robot-that-could-help-doctors-remotely-treat-covid-19-patients <comment><USER2> Maybe I'm missing something, but I don't see how Spot eliminates the potential for virus transmission, especially if it's performing up-close checking of vitals on multiple patients.

Granted, Spot can't contract or respirate COVID-19, so it doesn't need a mask or a gown, but unless it's taking a rubbing alcohol bath between each patient visit, couldn't the virus still be transmitted via surface contact?

<comment><USER3> I'm assuming that they can use some relatively harsh chemicals on the robot that wouldn't necessarily be safe for a person. And obviously not being able to respirate the illness is a significant improvement.

</comment></comment><comment><USER4> I do not understand the purpose of this. Can't the patients simply make a video call with their smartphones?

I mean, if spot had a small barrel with brandy around his neck, just like the St. Bernhard dogs allegedly did, now that would be something...

<comment><USER5> Something simpler can work just as well or much easier and this holds for many many problems or tasks. To do dishes, we do not have robot arms holding a brush but dishwashers. Think of a Roomba vs. robot with a sweeper etc. Instead of a robot stocking shelves in a super market, just have home delivery and cut out the shelves entirely. Cooking robots vs. microwave meals.

The issue with all of the above is that each of those can only do 1 task (and do it well). Humans can do multiple things well while reusing the same bits for multiple tasks. A mopping and a vacuum robot are very much alike and share a huge portion of the software and hardware. <strike>Robots</strike> Tools like a Roomba need to be cheap enough to warrant their cost for a task you only need a X times a week/day/moth/year. So, a Roomba is has to be cheap enough. Spot (and other robots) are more expensive but also more versatile and should be capable of doing more tasks.

But, finally, robots bringing beer, yes, the holy grail of robotics!

</comment></comment><comment><USER6> This is your monthly reminder that Boston Dynamics is exceptionally good at product demos.

It remains much less clear that they're any good at anything _else_.

Also, Spot looks like a Houndeye to me, so i keep waiting for it to make "wheeeennnnnnn BAM" noises.

<comment><USER7> > It remains much less clear that they're any good at anything else.

They are also exceptionally good at building impressive robots.

<comment><USER6> Not to be too blunt here, but: besides very impressive numbers of youtube views, what have those robots accomplished, in a "we have deployed X thousand of these in the following Y situations" sense, since 2006?

I'm (way more than) fine with blue sky work, and BD deserves credit for not building weapons, but at the same time there's an impedance mismatch here.

<comment><USER8> If you're interested Adam Savage was allowed to use a 'Spot' robot for several months and shares some observations and information on actual usage on his youtube channel.

[https://www.youtube.com/watch?v=R-PdPtqw78k](https://www.youtube.com/watch?v=R-PdPtqw78k)

<comment><USER6> [https://techcrunch.com/2019/09/24/boston-dynamics-puts- its-r...](https://techcrunch.com/2019/09/24/boston-dynamics-puts-its-robotic- quadruped-spot-up-for-sale/)

reading between the lines, as of Q4 last year they're still in _extremely_ early in any meaningful deployment. Lease-based alpha access to select customers, "hey we don't have to send a 12-man team out every month anymore", and carefully PRd information is certainly some kind of progress, but it's not anything like normal use.

<comment><USER8> Definitely not normal use, probably something akin to controlled alpha or beta testing. The only recent article a saw about the fall 2019 trials/leases was this article that didn't provide any meaningful details on usage.

[https://www.officer.com/command- hq/technology/article/211286...](https://www.officer.com/command- hq/technology/article/21128615/electronic-law-enforcement-and-robotic- equipment)

</comment></comment></comment></comment></comment></comment><comment><USER9> If I saw this escapee from a Metal Gear game coming in to check up on me, my first instinct would be to run, or perhaps hide under the nearest cardboard box of sufficient size.

<comment><USER10> Also makes me think of Half Life

</comment></comment><comment><USER11> I wonder if it would make sense to use the telepresence bots from Double Robotics for something like this. It seems to have similar capabilities (I'm assuming there aren't many stairs on the hospital floor) and costs an order of magnitude less: [https://www.doublerobotics.com/](https://www.doublerobotics.com/)

</comment><comment><USER12> I wonder how it is cleaned. Parts of it look like they might be hard to clean effectively. Is it water resistant and capable of being (safely) sprayed down with a disinfectant?

</comment><comment><USER13> Why not have wheels?

What is it that makes spot better at telepresence, telemedicine, remote vital inspection, internal delivery or disinfecting hospital rooms than, say, a roomba platform?

</comment><comment><AUTHOR> The main picture seems like something out of a science fiction nightmare

<comment><USER14> We've been living in a science fiction nightmare since 2016, I think.</comment></comment>


The Central Limit Theorem and Sampling - <AUTHOR> https://luminousmen.com/post/data-science-central-limit-theorem <comment><USER2> > According to the central limit theorem, the average value of the data sample > will be closer to the average value of the whole population and will be > approximately normal, as the sample size increases.

This is a pretty loose statement of the central limit theorem. Sample averages converge to the population average by the strong law of large numbers (almost surely, under some mild conditions). The central limit theorem is a statement about the differences between sample averages and population mean. Multiply the differences (sample avg. - pop mean) by sqrt(sample size) and let sample size go to infinity to converge to a Normal distribution. (under some stronger conditions).

</comment><comment><USER3> This is 1st year undergraduate statistics and has nothing to do with data science. The graphics are cute though. I'm sorry for being so blunt.

</comment><comment><USER4> > this is true regardless of the distribution of population

Nope. Not true for all the distributions. For example, stock prices cannot be used in central limit theorem.

Distributions must have second moment, in other words, have finite variance.

</comment><comment><USER5> It is easy to find this material. This link adds nothing to the vast amount of tutorials in probability.

<comment><USER6> They are giving sampling examples as if I, as a data scientist - would be sampling actual human population.

Give me real examples of data sampling in the wild - how did you obtain this and that dataset? How did you clean up data x? How did you infer that the API provider's server was misconfiguring the parameter X and therefore 10% of our cashflow was attributed to Wednesday last week instead of today?

This feels more like wikihow.</comment></comment>


Ask HN: When will we stop writing UI by hand? - <AUTHOR> Designing UI is complicated. You need to think about your users and the context in which they will interact with the software. You need to support many different form factors, input methods, preferences, accessibility concerns, locales, etc.
Then, you need to implement it on a bunch of different platforms, all using their own UI framework and tools. It can easily take months to build the UI of a simple app across multiple platforms.
At the end of the day, you end up with a mostly static UI that only supports cases you could predict in advance. Even if your service is top-notch, people might go with a competitor because you don't support their language, or you don't support collapsing discussion threads.
When you think about it, most UI is 'one size fits all'. People got used to that, and most people accept a mediocre user experience because they don't know how to build their owns. The few that are able to build an app that fits their needs, quickly discover the chicken-and-egg problem and end up being the only person using their app and service.
When I talk to people doing UI, nobody even considers that such a thing could be automated. All they look for, are tools that make it easier for them to build their arbitrary UI by hand. This saddens me.
How come isn't UI automated? How come don't people complain about how mediocre most software experiences are? This seems so much obvious that I suspect I might be missing something. <comment><USER2> Some enterprise software already works like that (especially to generate Web/mobile/desktop versions from the same code & description).

But I bet you can tell when you look at it that it has been fit to a limited set of templates, instead of each screen being "properly" designed. There is a lot of devel-in-the-details with UI, even if the general style is similar.

And I would argue against software being "one size fits all". Different styles approaches might make software unattractive for some users, but in the same way can be the critical decider towards your software for other users. Look at the mountains of different text editors out there. They all edit text completely fine and have tons of overlapping features, but they still can be a near religious topic.

> _Even if your service is top-notch, people might go with a competitor > because you don 't support their language, or you don't support collapsing > discussion threads._

You can't automate support for different language. And other people might use a competitor that doesn't even have threads, because that's their preferred style.

<comment><AUTHOR> > Some enterprise software already works like that (especially to generate > Web/mobile/desktop versions from the same code & description).

Can you name a few?

> And I would argue against software being "one size fits all". Different > styles approaches might make software unattractive for some users, but in > the same way can be the critical decider towards your software for other > users. Look at the mountains of different text editors out there. They all > edit text completely fine and have tons of overlapping features, but they > still can be a near religious topic.

I meant that software that currently exists is 'one size fits all', and that we should get away from this.

> You can't automate support for different language. And other people might > use a competitor that doesn't even have threads, because that's their > preferred style.

Not if software can adapt to its user's needs.

<comment><USER2> > _Can you name a few?_

I know SAP has internal tools that do that. Can't remember the name right now, but you might be able to find presentations on it online.

> _Not if software can adapt to its user 's needs._

I haven't seen a forum software that was switchable between threadable and linear in which both views worked well, simply because they are used differently and you miss context if you use a different view.

</comment></comment></comment><comment><USER3> Why don't you start by describing how your theoretical UI generation would work?

<comment><AUTHOR> You start with a semantic graph of knowledge.

Then people use the universal query interface to pick a node (abstract or concrete) from the graph.

Then they repeat the step above to pick another node from the graph.

Once they have 2 nodes, they can pick an edge (relationship) that works between those two.

There is your basic interaction, where people can communicate semantic statements.

You can easily expand from there.</comment></comment>


Help me add FreeBSD/amd64 build support to .NET CoreCLR - <AUTHOR> https://github.com/ajensenwaud/coreclr

<comment><USER2> #!/bin/bash isn't a Linuxism. #!/bin/sh and then relying on Bash features is.

#!/bin/bash just means your port has to depend on shells/bash, which is pretty reasonable.

<comment><USER3> Except by default, bash from the Ports tree gets but into /usr/local/bin/bash. An easy fix for users, but a better hashbang would be #!/usr/bin/env bash

<comment><USER2> Whoops. You are right. I don't know how to edit my comment...

</comment></comment></comment><comment><USER4> So much mindless discussion about "Linuxism" and incorrect usage of bash.

So little apparent willingness to help out. Kinda disappointing really.</comment>


Show HN: Torchbear – fast, safe, simple, and complete(R) Rust scripting engine - <AUTHOR> https://github.com/naturallymitchell/announcements/issues/1 <comment><AUTHOR> The GitHub issue has links to Twitter, Hacker News, Reddit, and LinkedIn at the bottom. I need your help voting for those.</comment>


Matt Mullenweg: I'm Worried That Silicon Valley Might Be Destroying the World - <AUTHOR> http://pandodaily.com/2012/05/24/matt-mullenweg-im-worried-that-silicon-valley-might-be-destroying-the-world/ <comment><USER2> Yeah sure, there's this impending Euro zone collapse, millions of death due to famine in Africa, rampant obesity throughout the world, decades of war in the middle east. What really is destroying the world is an internet software feature 99% of the planet never heard of.

Should I use dental floss tonight or not? Because you know, I like to ponder about the important things in the world.

<comment><USER3> I don't really think that tone is needed here on HN. Matt does bring up a valid point. Ability to concentrate will be a differentiating factor in an information age defined by the ability to create efficiently.

<comment><USER4> I think the tone is just a reaction (and an appropriate one, at that) to the hyperbole in the title. Just saying "the title is a bit of a hyperbole" would actually make for a worse comment.

<comment><USER5> Its not appropriate here. Snarky/sarcastic comments just encourage more of the same, which degrades the conversation. Also, its not really a comment on the subject of the article (which has something useful to say), but on the headline (which is poor).

Appropriate for Reddit/Slashdot, not HN.

<comment><USER6> Sarcasm is one of the most sophisticated modes of communication. Sanctimony is not.

</comment></comment></comment></comment></comment><comment><USER3> The title is obviously hyperbole, but I think it's a fair point - I believe there was actually a discussion last week or so here about how the key differential in the workforce will be able to focus for distinct periods of time.

I'm actually still resisting a smart phone (much to my friends' chagrin), because while I'm at the computer 10 hours a day, the rest of the time, I actually enjoy not "having" to check my email, twitter, facebook constantly because of push notifications.

<comment><USER7> >I'm actually still resisting a smart phone

I would say the same thing, except that resistance implies that there's a significant chance that I'll give in.

No matter how it's spun, I'm not putting a GPS spying device in my pocket.

</comment></comment><comment><USER8> He's completely right in his reasoning, but just like a lot of pessimistic predictions made about people, this one doesn't take into account the human ability to realize and fix something like this if it becomes a real problem.

I quit using a cell phone once I realized it was killing my concentration (and a Palm Pre is a hard thing to give up). I haven't used Twitter in months, Facebook sees me like once a week, and my email is quickly sorted (with the help of Webos 3.0's amazing mail client) once in the morning or whenever I feel like it.

I have a feeling a lot more people will try this in the next few years (and they'll love it).

<comment><USER9> I think that you're partly right, and it ties in with one of the points in pg's essay about addictive technology[1], that societies eventually develop antibodies to addictive new things. The problem (also noted in the essay, which grows more frightening the longer I think about it) is that most of the people who succumb to the addictive thing will not change their lifestyle to overcome it. Meanwhile, many companies in Silicon Valley are working to make their products as addictive as possible, soaking the most vulnerable users for the most money. The poster boy for this behavior is Zynga, but you see it everywhere.

What's the solution? Maybe we need to try harder to add addictive properties to activities we value. Or maybe we need a cultural movement away from things that are low-value and addictive to things that are high-value but not very addictive. It's difficult, because almost anything that's fun is potentially addictive. Reading, coding, and exercise are all valuable and can all be addictive. Not all addictions are equal. Running for two hours a day is probably better than playing Farmville for two hours a day.

I think that Matt's comments hit home because we're often in a position now of building things that lock people into harmful addictive behaviors. We all have to ask ourselves whether the work we do is valuable, or just lucrative.

[1] <http://www.paulgraham.com/addiction.html>

<comment><USER10> I like your idea for solutions a lot and think there's some great room for ideas to brew from there.

After reading GTD for Hackers[1], I kept thinking about ways to keep the momentum going after the initial excitement wore off… perhaps gamifying email and/or tasks (I hate that word, but it works).

[1]: <http://gtdfh.branchable.com/>

</comment></comment></comment><comment><USER11> Joe Kraus did a in depth analysis of tthis phenomenon in his _We're creating a culture of distraction_ [1]

[1] <http://joekraus.com/were-creating-a-culture-of-distraction>

</comment><comment><USER12> It is amazing how people develop antibodies when exposed to a treat. When I traveled around the world one of the worst thing you could think is: look, this water source is safe to drink, all locals do and they are fine. I did learn the painful way.

As an early adopter of mail, facebook and tweeter(back from the early days, "hey, HN could you test my idea?") I had to develop antibodies for distractions and I don't use tweeter, for facebook anymore(mail only at the end of the day). Reading only HN briefly. It works like a charm.

</comment><comment><USER13> "to the detriment of creativity and productivity."

I don't think those are necessarily the only or most important things losing out to all this "panem et circenses", which is really what a lot of these things are. Distraction has been used for a long time!

</comment><comment><USER14> Maybe Matt hasn't heard about turning something off. Matt is worried that engaging technologies interrupt peoples lives and disrupt productivity and creativity. He is probably right, until you realise you can disconnect yourself from these notifications.

Its like Twitter. It can be horribly distracting and engaging. It can interrupt your work and even conversations you may be having. At the same time you can turn off whatever app you have and it will disappear completely from your life until you turn it back on.

The majority of people know their limits and can decide how much they want a specific app/technology/whatever to impact their day-to-day lives.

<comment><USER3> >The majority of people know their limits and can decide how much they want a specific app/technology/whatever to impact their day-to-day lives.

I would say _some_ people know their limits, but if you look at the number of people who walk around with their eyes glued to their iphone, I'd really question that the _majority_ do.

<comment><USER15> Ten minutes at a busy intersection in downtown San Francisco will yield frightening results.

<comment><USER16> I do that too, I stay out of traffic, and I don't see the problem. Of everyday experiences I'd just as soon miss out on, staring at another DONT WALK sign is near the top of the list. When I want to spend time being creative, I wander around a park aimlessly and ignore my phone; navigating busy streets is just enough hassle that it doesn't work for me.

</comment></comment></comment></comment><comment><USER17> Mullenweg should be more concerned about how his software causes users to do more work than is necessary.

People prefer posts with photos that scroll, not a slideshow (WordPress Gallery). Many posts I do (mainly the ones about Occupy Wall Street) can have over one hundred photos. These photos have to be placed one-by-one _manually_. There is no "Place All" button that just plops them all into a post (we have bulk upload now, but not bulk Place).

If he is so concerned about making the world a better place, he can start _there_. That is something he can actually _do_.

<comment><USER18> WordPress is open source, you know. You could write a plugin or patch the core code to add any features you'd like.

Why wait for Matt and his team to do it for you?

<comment><USER17> I'm using the free WordPress service, not the free self-hosted version.

</comment></comment></comment><comment><USER19> This is the reason I keep my phone on silent. Not even vibrate anymore, but silent. Keeping distractions under control has greatly improved my mental well-being.

</comment><comment><USER20> Technology and elements of our modern lifestyle such as multitasking really do make our brains less tolerant to stillness and slowing down. So he has a great point.

Plus it wouldn't hurt if people though about the WHY of what they are dOing

</comment><comment><USER21> That headline isn't hyperbolic at all.

<comment><USER22> I think you mean: There has never been less hyperbole in a headline, in all the history of the world.

</comment></comment><comment><USER23> The premise paints a terrible picture of people, such that they aren't the ones making a completely volitional decision about how they want to spend their time. If people want to spend their time reading blogs and Twitter, who are you to say otherwise? It's not your choice, it's not your life, it's none of your business.

Might as well question whether soap opera's, tabloids, espn, disney, movies, television in general, music, and just about every other form of entertainment and media stimulation are destroying the world. After all, isn't modern music crap? Was FRIENDS really worth spending all that time watching? Who really needs to watch 50 NFL games per year? Could there be a greater waste of time than NASCAR? Most movies are an extreme waste of time because they're so terrible, so why make them?

It's a completely absurd premise, and it applies just as well to all media as it does to Twitter or Facebook or Wordpress.

<comment><USER24> I don't think the premise is absurd at all, and it need not paint a terrible picture of people.

There are often two camps when it comes to topics like this - the free-will proponents who posit that people's behaviors and choices are based on their own conscious, controllable volition. Then there are the contextualists, who would have us believe that people behave as the system dictates and can be held blameless for their failings.

The truth is, naturally, somewhere in between. We can suggest that people are negatively influenced by certain things without denying them free will and personal responsibility.

> _"It's not your choice, it's not your life, it's none of your business."_

Note that Mr. Mullenweg didn't suggest that systems be designed to actively curb this behavior. There are no Big Brother nor Nanny State overtones to this at all.

> _"If people want to spend their time reading blogs and Twitter, who are you > to say otherwise?"_

Again, nobody has tabled that we should _disallow_ people from reading blogs all day. Mr. Mullenweg seems to be feeling guilt that he's helped create something that may have a negative overall impact on many of its users.

Imagine if you've created the world's most addictive cigarette and completely cornered the market. People all around the world are lighting these things up by the packloads. You wouldn't feel any concern, or even guilt? Surely this is not as simple as "these people are adults, if they smoke like a chimney it's their own damn fault". That logic applies just as easily to crack cocaine or war, and represents the most extreme end of the "free will" argument.

> _"and it applies just as well to all media as it does to Twitter or Facebook > or Wordpress."_

And it does. This is the nation that, after all, invented the TV dinner and the couch potato. In fact, TV's influence on society is a _big_ can o' worms. If Mr. Mullenweg wants to feel better about his role in the creation of new media, he may want to take note that the Internet is the first thing in 50 years to get people off the damn couch and onto a far more interactive, more informative medium. The Internet has some serious information addiction problems that we're just scratching the surface of - but IMO it beats the pants off what it replaced.

Information addiction _in general_ does not have me overly concerned about the future of society and the Internet. What _does_ worry me is the growth of the personalized web - we are very, very rapidly sailing into a future where a person would _never_ have to hear a single word of dissent to their own beliefs. This troubles me more than any other issue that faces the Internet today.

<comment><USER25> > _"... we are very, very rapidly sailing into a future where a person would > never have to hear a single word of dissent to their own beliefs. This > troubles me more than any other issue that faces the Internet today"_

I concur. I don't think this is limited to online interactions either. There were stories a few years ago of how people in the real world were increasingly moving to be near like-minded people (and the negative effects this had on reinforcing their world-views). Wish I could find the story but no luck.</comment></comment></comment>


But Can You Tell Me What This Is and Why I Should Care in 80 Characters or Less? - <AUTHOR> http://micheleincalifornia.blogspot.com/2014/08/but-can-you-tell-me-what-this-is-and.html

<comment><USER2> I think there's a random effect that's much larger than the title. I've seen submissions that look perfect for HN, with perfect titles, never make the front page just because nobody saw them on /newest. (And I'm not just talking about my own submissions.)

I also think the rule about using the original title even if it is bad is often taken too far, and then dang has to come along and fix it.</comment>


Beating Interpolation Search & Binary Search - <AUTHOR> http://dr-josiah.blogspot.com/2010/06/beating-interpolation-search-binary.html

<comment><USER2> Try boost::unordered_set. You'll average O(1) time. We just converted an app that was using binary_search on a sorted std::vector to boost::unordered_set and the time difference was dramatic, especially on larger containers, but slightly slower on small ones:

1 string: binary_search (28 seconds) unordered_set (36 seconds)

1,000,000 strings: binary_search (127 seconds) unordered_set (60 seconds)

<comment><AUTHOR> boost::unordered_set is an in-memory hash table, not unlike std::hash_set (which may save you some download/link time). Note that the blog post discusses your options when your data is too large to fit in memory.

Most hash tables operate under the assumption (based on good hashing and probing algorithms) that hashed key collisions are somewhat common. If one were to apply hashing to this problem (data on disk), the data file would necessarily grow (hash tables rely on empty space to reduce the probability of collisions), and would still require at least 1 disk seek+read, but likely more depending on the characteristics of the particular hashing algorithm used.

Actually, since the original problem specified uses md5s as the key, arguably the best hash probe sequence and chaining would be something similar to interpolation search; which the index still beats.

</comment></comment><comment><USER3> This is more or less the approach used by Lucene and a few toy search engines I've written over the years, including, most recently, dumbfts.

</comment><comment><USER4> tl;dr: use B-Tree indexes.

<comment><AUTHOR> I mention that in the post, get specific with the characteristics of the particular B+Tree that we just constructed, and even link off to the relevant Wikipedia entry. :)

<comment><USER4> Then the tldr is right. Not sure why the down votes though.</comment></comment></comment>


Google tracks your movements, like it or not - <AUTHOR> https://www.apnews.com/828aefab64d4411bac257a07c1af0ecb/AP-Exclusive:-Google-tracks-your-movements,-like-it-or-not <comment><USER2> Discussed extensively yesterday:

[https://news.ycombinator.com/item?id=17749330](https://news.ycombinator.com/item?id=17749330)</comment>


Move Loot (YC W14) Brings Furniture Consignment Into The 21st Century - <AUTHOR> http://techcrunch.com/2014/01/28/yc-backed-move-loot-brings-furniture-consignment-into-the-21st-century/

<comment><USER2> >"For some reason, the company can't accept mattresses, sofa beds and recliners."

Besides the typical mystery stain concerns, the larger problem is bedbugs. You bring one used matress with bedbugs into your warehouse, and you could infect your entire inventory.</comment>


Everything you need to know about cryptography in 1 hour - <AUTHOR> http://www.bsdcan.org/2010/schedule/attachments/131_crypto1hr.pdf <comment><USER2> I think I can sum up the fundamental difference between my take on crypto (run away!) and Colin's ("use OAEP padding instead of PKCS!").

When Colin thinks of crypto he thinks of things like Tarsnap, which was built and designed to embrace cryptography; cryptography is part of the reason it exists. It is not an afterthought.

When I think of crypto, it's about all the places crypto pops up in normal non-secure CRUD-webapp situations. Like the guy who uses crypto to effect single-signon without sharing databases between apps. Or the team that encrypts URLs instead of implementing access control. Or the team that uses AES to "secure" a viewstate cookie.

If your goal is to produce a system like Tarsnap, which from day one is going to receive attention from security people because it is a security tool, I have less of a problem with Colin's recommendations.

But if you're trying to build client-side database-free single signon (ab)using crypto as a tool, this slide deck is terrible. Follow every piece of advice in it and you will very likely still produce a system that is _easier to break than if you hadn't used crypto_.

</comment><comment><AUTHOR> On Thursday afternoon I gave my talk 'Everything you need to know about cryptography in 1 hour' at BSDCan'10. Two HNers (as far as I know -- there might be more?) came to hear me speak, but several other people here have said that they would like to see talk but couldn't attend; so here's my talk slides.

I understand that a recording will go online somewhere at some point, but I'm not entirely sure of the details about that.

<comment><USER3> Since I've only the slides, I have a question about the following point:

> DON'T: Put FreeBSD-8.0-RELEASE-amd64-disc1.iso and CHECKSUM.SHA256 onto the > same FTP server and think that you've done something useful.

I take it the FTP got compromised and people simply regenerated the checksum for a modified image?

Wouldn't signing the checksum file solve the problem? Using different FTP servers for distributing the image and the checksums makes mirroring probably difficult.

<comment><AUTHOR> _I take it the FTP got compromised and people simply regenerated the checksum for a modified image?_

I'm not aware of any problems with FreeBSD FTP mirrors being compromised recently. I wanted an example of data-adjacent-to-hash and most of the audience was FreeBSD people, so I figured that I'd go with an example close to home.

 _Wouldn't signing the checksum file solve the problem?_

Yes. Or just relying on the FreeBSD release announcements, which contain SHA256 hashes and are signed.

</comment></comment></comment><comment><USER2> The repeated advice in this talk not to use block cipher modes that provide both encryption and authentication (which also follows from the advice not to use CBC-MAC) is contrary to a _lot_ of professional best practice advice, very much including NIST, and represents Colin's opinion more than it does a consensus on the issue.

It is easier to get something wrong when it has more moving parts. You are less likely to screw up EAX-mode AES --- presuming your library "just does it" for you --- than you are to screw up CTR-mode AES _and_ HMAC-SHA256.

The rest of the talk looks great, although I flinched when I saw the CTR recommendation, because CTR is also really easy to screw up.

Obviously, the comments about SSL are crazy. But you expect that going in to a Colin talk.

<comment><AUTHOR> _CTR is also really easy to screw up_

That recommendation wasn't about avoiding 'easy to screw up'. That one was about avoiding 'almost impossible to avoid having your key stolen via a side channel attack'.

 _Obviously, the comments about SSL are crazy._

Do you disagree with either of the following two pieces of advice?

      DO: Use SSL to secure your website, email, and
      other public standard Internet-facing servers.
      DO: Think very carefully about which certificate
      authorities you want to trust.

<comment><USER2> I disagree with the assertion that SSL is a bad protocol. It's an ugly protocol, but that's because things that are elegant are rarely secure.

And, of course, I disagree with your reasoning about authenticated encryption. You're saying, "you're exposing your block cipher to direct attack by overloading it to both encryption and authentication". But it's probably exposed to side-channel attacks either way. Meanwhile, the implementation flaws that people end up with in naive HMAC systems break far more systems.

I suspect this is another example of the impedance mismatch between your academic approach to this and my "having to slog through people's terrible crypto on a monthly basis" approach.

<comment><AUTHOR> _It's an ugly protocol, but that's because things that are elegant are rarely secure._

Funny, my experience has been exactly the opposite.

 _But [your block cipher] probably exposed to side-channel attacks either way._

Exposed, yes. Exposed to attackers who don't hold the MAC key, no. Exposed to chosen-ciphertext side channel attacks, no. These distinctions matter.

 _having to slog through people's terrible crypto on a monthly basis_

I do this too. But I try to educate people so that they write slightly less crypto.

<comment><USER2> Are you consulting now?

<comment><AUTHOR> Yes.

<comment><USER2> Good to hear it. I think you'll come around to my way of thinking soon enough. =)

</comment></comment></comment></comment></comment></comment></comment><comment><USER4> As somebody who's not already a crypto expert, I found those slides next to worthless by themselves. I suspect that the speaker put a lot of extra explanation into them during the talk to explain why TLA1 is better than TLA2, but it doesn't come across at all in the text.

As an example, I'd read an article about timing attacks, so I knew what the author was getting at in the slide about rewriting that loop. If I saw the slide without any background, I'd have been left scratching my head since it doesn't make any attempt to explain the actual issue.

Let us know when the audio is available. I'll keep the slides around until then.

<comment><AUTHOR> _I suspect that the speaker put a lot of extra explanation into them during the talk to explain why TLA1 is better than TLA2, but it doesn't come across at all in the text._

Yep. There's a practical limit to how much text you can put into slides and have them still be useful; I decided that it was more useful to have the recommendations in the slides and the reasoning orally than vice versa.

<comment><USER5> Is the audio of the talk available online? A cursory googling of bsdcan sources didn't yield anything.

<comment><AUTHOR> The audio was recorded, but I don't think it's available yet.

</comment></comment></comment></comment><comment><USER6> Great slides, some comments though.

I feel they focus too much on "use process X and algorithm Y".

The difficulty is not to choose the algorithm or the process, but to understand what kind of problem you're dealing with in the first place. In other words: threat modeling. There isn't a single slide about threat modeling, unless I'm mistaken.

If your error boils down to using SHA-1 instead of SHA-256, that's trivial to fix and you won't be exposed to real world attacks anytime soon.

Talking about side channel attacks on a hyperthreaded core is just going to confuse the audience. This is a very sophisticated attack that require the attacker to be able to run code on the target machine. If that's your only vulnerability, consider yourself happy.

<comment><AUTHOR> _The difficulty is not to choose the algorithm or the process, but to understand what kind of problem you're dealing with in the first place._

I agree, up to a point. But there's no way you can teach that sort of understanding in 1 hour. :-)

The purpose of this talk was to provide a checklist for developers of what they should and should not be doing.

<comment><USER2> But, for instance, you recommended CTR-mode AES-256, but didn't discuss:

* How to set the counters so that counter/IV can't collide and destroy your security

* What metadata your messages need to include to make them not replayable

* How to canonicalize your messages so that the process of packing, authenticating, encrypting, decrypting, and unpacking doesn't change the intent of a message.

I think that may be what the grandparent comment is getting at.

<comment><USER7> Excellent points. I would much rather have seen a talk on the hard issues such as these. Choosing an algorithm is simple if you already handle the above issues -- you've already heard a lot about AES by then. On the other hand, choosing AES-CTR as Colin recommends in the talk without handling the above issues is exactly where most developers are today.

Put another way: find me one crypto library or application implementing CTR mode that got all the above issues right but used a poor block cipher (not AES or 3DES).

</comment></comment></comment></comment><comment><USER8> One point I think crypto-people need to hammer home to non-crypto audiences is that they should not encrypt and transmit anything that will remain sensitive for more than 5-10 years via any form of encryption relying on factoring, one- way hashes, etc.. (Pretty much everything classical short of one-time-pads exchanged in person.) Credit card transactions? Fine. Affairs? State secrets? Not fine. If you're interesting enough, your coded messages will be archived and cracked within a decade or two (or less).

A lot of crypto algorithm's are theoretically secure for thousands of years (or longer) assuming an eavesdropper has access to existing algorithms and classical hardware with Moore's law scaling. Unfortunately, it's currently non-existing attack algorithms you really need to worry about. Advances are relentless. Then there are things on the horizon like quantum computing...

<comment><AUTHOR> Quantum computing is overrated. So far all it has told us is that 15 = 3 * 5 with high probability.

While Shor's algorithm demonstrates that integer factorization is in BQP, there are very good reasons to believe that many other problems are not; a large enough quantum computer may break RSA, but it won't break everything.

<comment><USER8> My point was that you don't need Quantum computing to break all existing crypto algorithms within a couple decades. QC just makes matters that much worse.

(Downplaying Quantum Computing ostrich-style is very popular in classical crypto circles for some reason, but that's a topic for another day!)

</comment></comment></comment><comment><USER9> > * SSL requires that you decide which certificate authorities you want to > trust.

One subtle point is that governments can force seemingly great certificate authorities to give them a certificate so that they can do man-in-the-middle attacks and still have a reasonable "trust chain" that you can look at in your browser. More details of this "compelled certificate creation attack" at <http://cryptome.org/ssl-mitm.pdf>

If I had to bet, I'd say most serious attackers aren't bothering to break crypto math or even weak implementations but are rather focusing on this approach by getting a CA to give them a good cert to spoof another site and it'd go practically undetected.

Ultimately with crypto (or anything else) you have to implicitly trust somebody (e.g. Mozilla Foundation) or something (your processor to correctly execute a program or your quantum crypto box to not behave maliciously). As long as this is the case, you can't have perfect security.

Great paper of "Reflections on Trusting Trust" : <http://cm.bell- labs.com/who/ken/trust.html>

</comment><comment><USER10> >Don't even dream about storing your user's passwords on your server. No, not even if they are encrypted.

While I always follow this when it comes to ssh logins, how do you suggest doing this for webapp logins? force everyone to use client certificates? mod_auth_kerberos? (hell, for that matter, kerberos keeps user passwords on the keyserver)

I'm working on bringing my web bits up to snuff, and I'm seriously considering forcing the use of client certificates. That, or just saying 'fuck it' and writing a ncurses billing app that you ssh into. no web interface at all.

Both of those solutions might work okay for me because I have a highly technical userbase, and my marketing is strong enough (or rather, I have other bottlenecks that are bad enough) that I can turn away some customers, but I don't see them working for most web applications.

<comment><USER11> I think he's saying don't store the users' actual passwords, store salted hashes instead :)

<comment><USER12> Well, more explicitly PBKDF2 or scrypt. Some people might take "salted hash" as MD5(password+salt) or something.

<comment><USER10> so the point here is just something that is slow to calculate? I mean, once the attacker has the hash, he can start trying random passwords against it. Sure, with a completely random password, that takes a while. But with a password a human can remember?

So PBKDF2 or scrypt just slows down the process of checking a users password against a hash, right? That does make sense in that it does slow down an attacker (and combined with a strong user password it seems like it could be secure) but it doesn't solve the essential problem that humans are not good at remembering random things, and there is a limit to how slow your 'check password' function can be in production. your attacker can almost always be assumed to have more computing resources than you do.

<comment><USER12> An attacker has to brute force the whole universe of human-friendly passwords. So 1000x the computation is a lot more painful for the attacker than for a legitimate user who only uses the operation occasionally (create/change password and login).

Additionally, salts protect against attacks that use pre-calculated tables.

I haven't read Colin's scrypt paper, so I'm not sure if its strategy differs.

<comment><USER10> Right, but if your password is an English word concatenated with a number, you might really be looking at the attacker getting it in the first 10,000 guesses, which isn't much if the password can be checked on your webapp box in less than half a second, (in that completely made up case, even if the attacker only has the same resources as you, the password would last an hour and a half) considering 1. the attacker probably has more compute resources dedicated to the cracking than you have dedicated to logging in, and 2. the attacker doesn't mind waiting all day for a login. (I mean, I'm assuming the attacker has other compromised hosts to use in the cracking effort.) I think it's a losing battle.

I'm not saying that slowing down the checking of a password has no value; Clearly it has much value. Without it, even a strong password would be brute forced quickly. I'm just saying, I am missing how it solves the problem of weak passwords.

The real problem here is that I know I can't remember a sufficient degree of entropy. Sure, there are all sorts of ways to fake it; take the first letter of every word in a sentence, but that's not exactly random, either. I know a guy who, for a pass phrase, would use a 24 line block of text from some project Gutenberg title. I doubt that was any more secure than 4 or 5 random characters.

<comment><USER12> Yeah, I don't think a KDF makes arbitrarily bad passwords OK. They just move the needle and thus increase the cost of the attack. In many cases, the derived key can be cached by the legitimate user, so you can throw a few seconds at it on the user's machine.

10000 * 1s = ~2 hours cpu time, but that's a terrible password -- common words plus 3 digits means 1000 * 10000. 26^6 * 1s = ~10 years CPU time -- a few thousand bucks on EC2 -- that's getting better for what is still a pretty weak password. In any case, straight MD5s are super-fast. At 1e5-1e6 MD5s/second or more on a modern CPU, paying the compute cost for a 1 cpu-second KDF can be several orders of magnitude stronger than MD5(password+salt).

<comment><USER10> Yeah. But really, I was hoping someone had come up with a way to make something like client certs usable. a six character completely random password (even if it's all lower-case without punctuation) is a damn sight better than your average password.

Can you tell me more about allowing the user to cache the derived key within the context of web applications? that would mitigate the limitation I was describing (where how slow you made the password check was limited by what delay a user would tolerate when logging in.)

<comment><USER13> I don't think this is really suitable for web applications. Javascript _really_ sucks at crypto (due to the lack of suitable data types), and requiring Java wouldn't fly with too many people (Flash is sort of in-between, I guess?). There is a very large constant factor here, so and since the whole point of this key derivation stuff is to make an attacker work harder...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I don't suppose you're planning to tie these recommendations up into an open source C99 library with an NaCl-like crypto_box interface? Oh, and can I have a pony too? :)

<comment><USER7> Better, add AES and SHA-256 support to NaCl. With your insight into preventing side channel attacks, it would be a great combo.

<comment><USER12> I could be wrong, but I don't think NaCl is portable anywhere but x86 or x86_64. ARM needs good crypto too. Though I suppose we could ask for ARM support in NaCl too since we're asking for ponies :)

Also, does NaCl support signing? I think crypto_box offers "authentication" which is a slightly different promise.

<comment><USER7> No signatures yet. See this summary I wrote a while back for more info.

[http://rdist.root.org/2009/07/14/nacl-djbs-new-crypto- librar...](http://rdist.root.org/2009/07/14/nacl-djbs-new-crypto-library/)

</comment></comment></comment></comment><comment><USER3> _DO: Use a 2048-bit RSA key, a public exponent of 65537, SHA256, and MGF1-SHA256._

How can I set the public exponent when generating a key? man gpg wasn't helpful.

And why this particular number? I can see that it's 2^16+1, but I don't understand the advantage of this number compared to others. (Although I've been taught that people prefer small values for _e_ now.)

<comment><AUTHOR> That was explained in the audio part of the talk. :-)

Short answer: A long list of attacks in the past have been much harder with large public exponents; using 2^16+1 instead of 3 is a bit slower but is likely to make you safer if someone else gets smart in the future.

<comment><USER3> Thanks for answering my curious questions so far. =)

Since I messed up formatting earlier, my first question about generating keys with this particular exponent was hidden:

Do you know how to generate such a key pair using gpg (or another tool)? Or is this done automatically?

<comment><USER12> For OpenSSL command line:

      openssl genrsa -f4 2048

<comment><USER3> Thanks, OpenSSL actually uses 0x10001 by default for _e_. I'll use it instead of GPG from now on to generate keys.

</comment></comment></comment></comment></comment><comment><USER14> How is this good code?

x |= MAC_computed[i] − MAC_computed[i];

Shouldn't one side or the other (of the minus operation) be MAC_received[i]?

<comment><USER15> And why is the original way of not completing the for cycle for some keys wrong? Is the difference between checking the whole array and checking only lets say first byte measurable? Especially when considering that this would probably be done over a network?

<comment><USER16> Timing attacks like this have been successfully used against a few gaming consoles.

<comment><USER7> In particular, a memcmp()-style timing attack was successful against the Xbox360 CPU. This is a multi-Ghz processor.

</comment></comment></comment></comment><comment><USER13> Could you expand a bit on your comments about Poly1305 ("too difficult to implement" - but Bernstein has a library, right?) and Blowfish ("DON'T use")?

<comment><AUTHOR> Yes, Bernstein has written code for Poly1305; but bus factors are bad. If you decide to use Poly1305, at some point you're going to want to use it on a new CPU or in a different language, and you'll find that DJB's code won't work for you.

You should avoid blowfish because it has a 64-bit block size.

<comment><USER17> What does "bus factors are bad" mean?

And as long as I'm asking questions, what about bcrypt for password hashing?

<comment><AUTHOR> "Bus factors" refers to how many people need to get hit by busses before there's nobody left who can work on something. In particular, a bus factor of 1 is a very bad thing to have.

<comment><USER13> Although it's mitigated somewhat by the fact that Bernstein is passionate and has been a reliable maintainer in the past. "Bus factor" is typically an euphemism for "someone is going to pay this employee more than we do".

<comment><USER18> I'd call that a cacophonism, though, unless you truly prefer that they get hit by a bus.

</comment></comment></comment></comment></comment></comment><comment><USER19> The manifestation of this crisp thinking is tarsnap. The best linux backup product I have ever seen.

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER20> I'll be interested to hear the thoughts behind the "Probably Avoid" recommendation on DSA and EC signatures. They're both attractive in some situations because they produce much shorter signatures than RSA.

The recommendation for AES-256 over AES-128 runs contrary to Schneier's advice. It makes it hard for the non-experts when the experts can't agree...

<comment><AUTHOR> DSA and EC both have benefits in some _rare_ circumstances. That's the 1% of the time when you ought to consult a cryptographer.

I'm aware that my advice concerning AES does not match Schneier's advice. I don't think he takes side channel attacks seriously enough.

<comment><USER2> He also thought "cube cryptanalysis" was going to break most modern ciphers. Do you think he's a serious practitioner? I think he's a pundit.

<comment><AUTHOR> I think Schneier does less cryptography now than he used to, but I would still say that he's much more than just a pundit.

<comment><USER2> I'm interested in why you think that (I'm in listen mode here, not argue mode).

<comment><AUTHOR> Hmm. I'm having trouble putting my finger on anything really concrete right now. More than anything else I'd say that it's just a general impression from how well in touch he seems to be with current events.

<comment><USER7> He was part of the SHA-3 team that proposed Skein. I think he also coauthored a paper on some advances in attacks on hashes with Kelsey recently.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Am curious as to why to use "x |= MAC_computed[i] − MAC_received[i];" instead of the block-wise comparison. Wouldn't the x |= approach be _less_ secure, because two (or more) differences _may_ cancel each other out? (am assuming that |= == ||= in Ruby, or a bitwise OR)

<comment><USER22> No, not possible for differences to cancel. The bitwise OR of a bunch of things is zero only if all of the individual things are zero. The difference between two things is zero only if they're equal. Therefore, the final value of x is zero only if all the elements of MAC_computed and MAC_received match.

(And -- the main point here -- how long it takes to do the calculation should be totally independent of what's actually in the arrays: no early termination, no operations that take different amounts of time depending on how many elements match, etc.)

<comment><USER21> ah, bitwise or, was thinking incorrectly for some reason. And early termination makes sense, thanks! Didn't think of that.

</comment></comment></comment><comment><USER23> What's wrong with Elliptical curves?

Seriously, are there some known attacks against ECDSA? And what of DSA2?

<comment><USER22> I'm neither Colin nor a cryptographer, but I think elliptic curve cryptography (1) involves more complicated ideas and code (which might therefore be easier to get wrong), and (2) is subject to more patent claims, than its rivals, without any obvious big benefit to outweigh those facts. [EDIT: oh, and because of 1 and 2 ECC is used less, and therefore your implementation mightn't have had its bugs and design flaws so thoroughly shaken out.]

Certicom has ~130 ECC-related patents. You probably don't want to have to crawl through them all making sure that your code, or someone else's code that you're using, doesn't infringe (and won't be found to infringe by a not- necessarily-infallible jury if you get sued anyway).

[EDIT again: actually, ECC does have a claimed big benefit, namely not needing such long keys. But one might reasonably be worried by the possibility that an algorithmic breakthrough some day might suddenly make longer keys necessary...]

<comment><USER2> ECC is _extremely_ well studied and implemented almost by default in embedded settings. There are providers of it other than Certicom.

The reality is, you need to consult a cryptographer before you implement _any_ public key system. RSA and vanilla DSA are also spectacularly easy to screw up.

<comment><AUTHOR> In an embedded environment I would probably use ECC. I believe that I mentioned this in my talk; certainly I mentioned that my advice was for the context of software on general-purpose CPUs.

Unusual environments need special treatment.

<comment><USER2> ECC vs. RSA is a place where you certainly know better than me; I have that list of things Kaliski said not to do wrong with ECC and very little else. I also think we probably don't disagree very much about ECC.

Where I know we do disagree: public key crypto is a threshold over which I would not be OK implementing a custom cryptosystem. If I need public key, it's GPG or nothing. I am terrified of public key crypto.

<comment><AUTHOR> I didn't intend for my audience to be implementing everything themeselves. Knowing that OAEP is better than PKCS padding is useful even if you don't write a single line of code, because it helps you select the right library to use.

</comment></comment></comment></comment></comment></comment><comment><USER7> Overall, I think this talk best applies as a starting point for learning about crypto. Take Colin's recommendations as signposts to underlying research. Why would he dislike DSA? Hint: it requires a secure RNG at signing time while RSA only requires one at key generation time.

[http://rdist.root.org/2009/05/17/the-debian-pgp-disaster- tha...](http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-that-almost- was/)

However, I don't think he achieved the stated goal of teaching you enough to become a crypto implementer in 1 hour. I disagree with a lot of his conclusions. But you'd have to learn more than the slides hint at to have a discussion on the details why.

Some specific comments on the slides.

### Common failures and their causes (2):

I find it interesting that he characterized a timing attack in Keyczar as "stupidity" while a cache-based timing attack with HTT was "unusual environment". Same thing with SSL renegotiation. I think all of these were subtle flaws and easy to overlook. The SSL bug was around for at least 10 years. HMAC timing attacks were not as widely published as they are now, but instead were part of common lore to cryptographers.

The WEP vulnerability was almost certainly not "unusual environment". Sure, there were power and cost constraints in the WEP design, but what was unusual about it was that the crypto was obviously designed by a group with no crypto experience and no public review. Using a varying key with RC4, something it was known to be weak to, was an example of "using a tool wrong" and more similar to the AWS v1 signature bug you found.

The only "unusual environment" was that the specialized and closed field of IEEE wifi design led to non-cryptographers designing crypto. There was nothing unique to the environment that a good crypto person would have had an inherent problem with.

I don't think this list is a good categorization of types of crypto bugs.

### Authentication/Signing (5)

Confusing terminology. I use "integrity protection" or "authenticator" for MAC and "signature" only for public-key signatures. They are two very different processes, even though they share some goals.

### Hashes (8)

It was funny to see SHA-1 in the "don't use" list next to MD4, for example. I agree it's best not to use it for new designs, but there's a world of difference between SHA1 and MD4, especially if you have to use SHA1 for legacy compatibility.

### Symmetric authenticators (10)

I think CBC-MAC should be on a "don't use" list, not "avoid". If you put SHA1 on the "don't" list, it's even more important that CBC-MAC be put there. Which will be broken sooner: HMAC-SHA1 or an arbitrary CBC-MAC implementation or use?

### CTR mode (17)

Based on his previous comments, I think Colin advocates CTR mode due to its supposed resistance to side channel attacks. However, it is not a panacea. See this paper by Josh Jaffe on how to use side channel attacks against CTR mode. It's quite interesting how AES's structure makes it more vulnerable to his particular attack.

[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.93.6...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.93.6851)

<comment><USER2> By citing CBC-MAC as "DONT USE", do you include CCM mode (which is popular)?

I see clear practical reasons to avoid CBC-MAC (there's an incredibly easy and devastating keying mistake to be made with it). But you have more insight into the theoretical problems than I do.

</comment></comment><comment><USER24> Slides look great and so is the presentation. May I ask what you used to prepare them?

<comment><AUTHOR> LaTex beamer, with the Warsaw theme.

<comment><USER25> Seems to have become the standard in mathematical circles.

</comment></comment></comment><comment><USER26> There is a typo "which which" on the 2nd "Side channel attacks" slide.

<comment><USER27> Slide 5, line 2: "The ciphertext is the data _we_ evil people get to see." [emphasis added]

(Admission that there is something to the beef with the old BSD logo ? ;-)

<comment><AUTHOR> Oops. Freudian slip, I guess. :-)

Thanks!

<comment><USER27> Thank you for the guide - the dos/don'ts, from someone who knows, are exactly what's first needed in this minefield.

(And Muphry struck me too - it's in page 6. I double checked the number and then typed the wrong one ...)

</comment></comment></comment></comment><comment><USER28> I found some of the information in this presentation to actually be wrong. The guy repeats himself, and at two points he even contradict himself. I also didn't like that a very large portion of it was presented with a very fervent zeal, replacing actual knowledge of _why_ and _why not_ with useless favorism and indoctrination; the guy is a zealot, and that's a very, very bad ingredient in any serving of important information.

I would not recommend this particular presentation to anyone.

add.: Thanks for the downvote, Colin :D Oh boy...

<comment><USER5> Hackermom, you sound confused about the downvotes. To provide a bit of background: Colin Percival has a doctorate in computer science from Oxford, has won the Putnam, has been FreeBSD's security officer for years, and discovered the hyperthreading leak noted in this presentation. Most people who've been on Hacker News for a while trust his judgement.

I'd like to think we would all--cperciva included--welcome specific criticisms or errors, but by claiming they exist without naming them, you're asking us to take your word over his. Your score reflects the fact that you haven't earned that.

<comment><USER2> Careful. Colin Percival isn't David Wagner or Dan Boneh or even Daniel Bernstein. He wrote a paper on a side channel attack during a window of time when everyone was writing papers on microarchitectural side channel attacks, wrote a pretty cool paper on a password derivation function, and, like the authors of SSH, Tor, and DESLogin (none of them professional cryptographers), built a bunch of cryptography into a well-understood Unix networking problem.

I very much respect Colin and fully expect him to kick my ass in arguments, but, _in particular_ , I find a good portion of his advice _does not square_ with my professional experience; in other words: he's saying things that lay developers have already heard, and, empirically, lay developers produce very bad crypto.

<comment><USER5> It's funny you'd say that, because you're one of three-ish people on HN I weight equally with cperciva on security issues. But my explanation doesn't depend on his being one of the top 10 security guys in the world; just on his being orders of magnitude more reliable than an average Hacker News reader, like the one who I responded to.

Even that is more than required by the fundamental message I'd hoped to convey; which is "making something and sharing it can be useful; giving non- specific criticisms from a noncommitted, unassailable position is not useful." Reputation is simply bayesian evidence with which one can weight an otherwise- unsupported claim.

</comment></comment></comment></comment><comment><USER29> i kinda found this presentation to be chock full of "i am right, you are wrong" "i know better than you" et cetera. it's as if he's trying to coerce people into using what -he- thinks is best and what -he- prefers, but not really caring for sorting out the facts or explaining the details to give people a big enough picture to make educated choices of their own. "just go with this and that, trust me it's the best". no question actual knowledge is in there, the guy knows cryptology, but this seems to be a slide for indoctrinating people into sharing his preferences in crypto, not for teaching, and i personally find it to be the completely wrong approach.

<comment><AUTHOR> _i know better than you_

Well, I _do_ know better than my audience. That's why they came to my talk. :-)

</comment></comment><comment><USER30> <http://www.norvig.com/21-days.html>

there ain't anything called learn it in x hrs/days</comment>


Lessons from Google's First Rollout of Google Fiber - <AUTHOR> http://www.fastcompany.com/3036659/elasticity/lessons-from-googles-first-rollout-of-google-fiber

<comment><USER2> What's with the random links in the body of the text that don't go anywhere? Am I blocking some critical piece of ad-serving javascript?</comment>


The inventor of the SR-71's rules for project management - <AUTHOR> https://en.wikipedia.org/wiki/Kelly_Johnson_%28engineer%29#Kelly_Johnson.27s_14_Rules_of_Management <comment><USER2> I resent calling Kelly Johnson merely the inventor of SR-71. He was the father, the project manager and the organizational hustler who found Skunk Works and defined it's working culture. He was a legendary aviation engineer but also really _understood_ how to get a team of experts to produce results and to co-operate with the manufacturing and operations to create feats of engineering.

He found and ran a lean organization on grit and triftiness when toyota production system was taking it's baby steps in japan.

I heartily suggest Ben Rich's 'Skunk works' to anyone who gets a kick out of a true story what it actually means in terms of output when an innovative engineering team actually works lean... in hardware.

<comment><USER3> That's an excellent book.

Kelly had a few other rules. One was that the engineers, the machinists, and the airframe must be physically close, preferably in the same building. That way, if a part wasn't working, the assembler, machinist, and designer could all get together at the airframe and figure out what to do about it. HP also had that approach to work in their glory days.

Another Kelly saying was "Kill problems, don't wound them". If some part is causing problems, don't make one that has fewer problems, redesign it so the problem goes away completely.

<comment><USER4> The "kill problems, don't wound them" idea reminds me of the idea in programming to make invalid states unrepresentable. It's not always possible to redesign problems away entirely, but if it is possible, it is a good thing to do.

<comment><USER5> Absolutely. A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible.

For example, the JSF C++ guidelines say not to use 'l' suffixes on numeric literals, because they look like a 1. D simply makes the 'l' suffix illegal, use 'L' instead.

<comment><USER3> _A common approach to programming bugs is to try and educate programmers to not make particular mistakes. A more effective approach is to redesign the language so those mistakes are impossible._

Exactly. That's why I'm bothered by Rust being _almost_ protected against memory errors, and Go being _almost_ protected against race conditions. Even if you give up some performance, it's a big win to eliminate entire classes of errors.

(Still, both are way ahead of C/C++ in this area. So far, I don't think there's been a CERT advisory for a Go program. Rust is too new to be attacked yet.)

 _It has been (7) days since the last CERT security advisory for a buffer overflow in a C /C++ program._

<comment><USER6> Rust fully protects against memory errors (and data races, for that matter).

Having "unsafe" is necessary for making useful software and, in fact, it is also present in most other safe languages: Python, Java, Haskell, etc.

<comment><USER7> Unsafe is useful and necessary for many things, but most of the time it is easier to avoid it.

However it is disingenuous to claim unsafe is necessary for making _any_ useful software.

<comment><USER8> Howso? Without unsafe, you can't do what you need to do. That's the definition of "necessary for making useful software."

<comment><USER7> Can you define "what you need to do"?

For instance, if I want to download/parse an html webpage or make some sort of web crawler or bot, why would I need unsafe?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> "Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised."

The lack of this is the #1 problem with professional software engineering.

<comment><USER10> Supervised! Yes, that's exactly the right word to use!

Instead of 'leader', 'manager', 'director', 'president' and all those pointless buzzwords. If all you are really going to do is forward emails and approve leaves.

Supervisor is the right word to use.

<comment><USER11> Administer I like. A busy office can really do with a good quality administrator. My best bosses have been precisely that.

</comment></comment></comment><comment><USER12> From the link: According to the book "Skunk Works" the 15th rule is: "Starve before doing business with the damned Navy. They don't know what the hell they want and will drive you up a wall before they break either your heart or a more exposed part of your anatomy."

any examples out there?

<comment><USER13> In a more recent example, the F35 Jet is having delay and cost overrun problems. I hear that one of the reasons is that there is 3 different version of the same jet and it may have been cheaper to design 3 completely different planes oriented toward each niche.

The 3 configurations are:

A) Conventional takeoff and landing (CTOL). A normal fighter jet, intended to replace the F16.

B) Short takeoff and vertical landing (STOVL). This model essentially has a big fan in it to allow it to hover and land on aircraft carriers.

C) Similar to A, but with larger, foldable wings and a stronger tailhook for landing with a carrier arrestor cable.

Model B is intended for the Marine Corp, and C is intended for the Navy.

Now I admit that I am fairly uninformed about military hardware and design, but I think something can be concluded from the F35 program issues.

<comment><USER14> If I remember correctly, the Marines use amphibious assault ships that don't have conventional runways (such as on Navy aircraft carriers) to take off/land on thus the need for a VTOL aircraft. A VTOL wouldn't be necessary for a Navy aircraft carrier (example: F18 Super Hornet). Another example of this is why the Marines wanted to keep the Harrier around for so long before it became too problematic and expensive hence why they wanted VTOL capabilities on the F35 JSF (also another factor in the cost/time overruns).

<comment><USER14> Citations:

[1] [http://foxtrotalpha.jalopnik.com/7-things-the-marines- have-t...](http://foxtrotalpha.jalopnik.com/7-things-the-marines-have-to-do- to-make-the-f-35b-worth-1560672069)

[2] [http://www.funker530.com/397-billion-spent-on- the-f-35-fight...](http://www.funker530.com/397-billion-spent-on- the-f-35-fighter-jet-is-it-worth-it/)

</comment></comment></comment></comment><comment><USER15> Point 6, "Don't surprise the customer", is the foundation of all good project management. To manage that requires knowledge and communication in all aspects of what you're doing. It's not a guarantee of success, but its definitely something to aim for.

</comment><comment><USER16> when it comes to DOD management rules, nothing beats Heilmeier's Catechism: [http://en.wikipedia.org/wiki/George_H._Heilmeier#Heilmeier.2...](http://en.wikipedia.org/wiki/George_H._Heilmeier#Heilmeier.27s_Catechism)

</comment><comment><USER17> It is telling that the SR-71 has not been replaced with a better and faster plane.

It appears that without Kelly and his organization, the government/contractor world is simply incapable of the task. In spite of material sciences advances, computing and CAD advances, etc., not only can today's system not produce an improved version, it would not even be able to match the specs of the SR-71 in a new design today.

Of course some may say that the successor may exist but is so secret no one knows of it, but that is extremely unlikely. If it existed whoever created it wouldn't be able to resist taking credit.

<comment><USER18> Or...hyper-velocity, fly-over, manned surveillance platforms have been replaced by increasingly sophisticated surveillance satellites, non-fly-over surveillance technology (e.g. SLAR) and unmanned drones, making an undoubtedly immensely expensive, manned SR-71 follow-on superfluous.

That or we got stupid since Kelly died. One of the two.

<comment><USER17> No doubt, satellites can perform the role of the SR-71.

My point is that the system we have in the US could not create a new SR-71 class airplane right now, in my view. It would run over budget, miss the performance targets, and be cancelled.

<comment><USER18> Actually, satellites alone can't do what an SR-71 can. Satellites aren't an ad hoc intelligence solution, since they are periodic in their orbit and can't image something they aren't on-station to see. But combined with other tech, they replace the SR-71 nicely.

As to your "point", it's trivial to say "we can't do something" when we haven't tried.

</comment></comment></comment></comment><comment><USER19> I find HN's infatuation with SR-71 kind of amusing. I think the site should have a logo that's the SR-71 flying over a globe or something similar. If you think about it the Y logo kind of looks like an SR-71... :)

<comment><USER20> It's not just the SR-71, also that ancient, straight-winged laggard the A-10. The internet loves these two aircraft.

<comment><USER21> The SR-71 was an impressive engineering feat because it successfully brought together a bunch of really crazy tech and got it to _work_. All of this with a relatively small team and stone-age (by modern standards) computational ability.

The A-10 was an impressive engineering feat because it _perfectly executed_ a very boring and conservative design. It did one thing, did it very well, and was so reliable it arguably put its producer out of business.

If I had to draw a comparison to software, I'd compare the SR71 with Erlang, and the A-10 with Postgres.

<comment><USER22> Call the A-10 late 90s / early 2000s MySQL. Sinfully ugly and gets the job done.</comment></comment></comment></comment>


Show HN: Classpert – A search engine for online courses - <AUTHOR> https://classpert.com <comment><AUTHOR> Hi HN !

This is Felipe, FJ and Thiago from Classpert ([https://classpert.com/](https://classpert.com/)). We've built a (free) search engine for online courses. Our intention is to help people search and find courses that most suit their personal and professional needs.

The idea is to offer an ultimate platform for comparing different and relevant aspects of online courses such as price, duration, providers, ratings, audio language, subtitles, etc. We believe the wide variety of courses and platforms available is an obstacle to the user's optimal choice.

From a software standpoint, we faced 2 main challenges when building Classpert. 1) Crawling providers: Since we wanted to be the most accurate possible, crawling is the best option (instead of using affiliate feeds and APIs). The crawling engine is built using Ruby and PL/SQL 2) Building the search engine experience (VueJS)

From a business standpoint, we launched our MVP in December 2018 and are still working on our platform to give the best experience. This is why we'd love to get HN's feedback. Thanks for taking the time to read this :)</comment>


Chick-fil-A is ending donations criticized by LGBTQ activists after backlash - <AUTHOR> https://www.businessinsider.com/chick-fil-a-ending-donations-criticized-by-lgbtq-activists-2019-11 <comment><USER2> The next logical step is for Chick-fil-A to be open on Sundays. As it is, they have thrown away the kernel but are still clutching onto the husk.</comment>


Ask HN: What will HN be able to do in 10 years from now? - <AUTHOR> <comment><USER2> Upvote on mobile without having to hit a 10x10 px triangle.

<comment><USER3> The new unvote/undown feature offers a more than palatable workaround.

</comment></comment><comment><USER4> If the last 10 years are any indication, it will look and feel the same as it does now, but will have a few minor features added.

</comment><comment><USER5> Hopefully not too much more. I come to HN for the content, not the features. Features distract ;-)

</comment><comment><USER6> A machine learning driven HN to automatically post URLs , blogs , news articles etc based on whats trending on the web, and be able to engage users in comments sections , act as moderators as well as facilitate insightful discussions.

<comment><USER7> > based on whats trending on the web

Kardashians?

</comment></comment><comment><USER3> It'll be getting on a bit, so hopefully it will have made it into a management position by then.</comment>


Build your very own submarine starting from $50,000 - <AUTHOR> http://www.ivccorp.com/kits.html

<comment><USER3> Note that this sub is open to the water in the bottom which means that the air pressure is the same as the water pressure. That means you have to take all the same precautions as divers in terms of depths, ascent rates and making sure you don't get the bends.

<comment><USER4> if it ever turns over, does all the air bubble out of it?

<comment><USER5> Reading through the specs, it seems that it's designed with that in mind - <USER2> center of mass is much lower than the center of buoyancy.

</comment></comment></comment><comment><USER6> One of Copenhagen Suborbitals (<http://en.wikipedia.org/wiki/Copenhagen_Suborbitals>) co-founders first build this submarine.

<http://en.wikipedia.org/wiki/UC3_Nautilus>

Pretty cool guys too.

<comment><USER7> _This submarine was Peter Madsen's third submarine design and is the largest privately built submarine in the world._ \- Wikipedia

False. This article from 2007 [1] discusses the highly secretive company where billionaires go to buy their luxury submaries, which apparently run up to 65 meters [2].The Nautilus goes only to 17.76, if its wikipedia article is to be believed.

[1] [http://money.cnn.com/2007/08/02/lifestyle/luxury_submarines/...](http://money.cnn.com/2007/08/02/lifestyle/luxury_submarines/index.htm) (incidentally, one of the most instantly fascinating things I've ever read in my life)

[2] <http://www.ussubmarines.com/submarines/luxury.php3>

<comment><USER8> I would guess that the story was pr spin, and since they or any owner has provided proof of a craft larger than 18 meters, that it's all theoretical. Would be amazing if there are private craft out there like they describe, but I'd need more than some renders and there word to believe it.

<comment><USER7> Well it was published by CNN, which is one of the largest media organizations and generally considered reliable.

I've gotten 3 responses trying to throw cold water on my post, which was just me sharing something that I thought was exciting. I don't get it.

<comment><USER9> > Well it was published by CNN, which is one of the largest media > organizations

true

> and generally considered reliable.

CNN may be considered "reliable", but it isn't.

<comment><USER7> FIne, but claiming the story I linked to about a company that sells private submarines is false, without any evidence, is just an arbitrary assertion, and should be dismissed. As should all arbitrary assertions. I guess I should have just said that.

<comment><USER9> I'm confused - why is it wrong to make an arbitrary assertion in response to an arbitrary assertion?

Are you suggesting that we should take a link to a CNN story as something more credible than an arbitrary assertion?

<comment><USER7> _Are you suggesting that we should take a link to a CNN story as something more credible than an arbitrary assertion?_

Yes, absolutely. If you think CNN just goes around making up stories, you are wrong. Snarky comments aside, CNN is a reputable news organization. To claim that a completely plausible CNN story is wrong, evidence is needed.

<comment><USER9> > If you think CNN just goes around making up stories, you are wrong.

It's interesting that you assume that that claim needs no supporting evidence.

Are you really sure that CNN doesn't "go around making up stories"?

> CNN is a reputable news organization.

That may be, but reputable news organizations do make up stories.

> To claim that a completely plausible CNN story is wrong, evidence is needed.

Or what?

I'm sympathetic to your argument, but it's not nearly a strong as you think that it is.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Great, this is just what I needed to transport a bunch of coke from my hookups south of the border. (google: cocaine submarine)

<comment><USER11> Narco-subs are designed more for stealth than recreational diving (poor viewports, lots of cargo, old narco subs were just semi-submersible). Anyways, they cost about $2 million to build according to wiki, so they are sort of out of our price range. But you might be able to get a used one on the cheap from your coke dealer...

For recreation, I think this wouldn't really beat just plain old snorkeling, or even scuba for the more involved. Its more like a rich-guy toy.

<comment><USER7> Yeah, this would not have the stamina to be a narco-sub. As in, it goes too slowly and runs out of air too quickly. (I say this based on its apparent similarity to scuba technology, not out of narco experience.)

In fact, if it works like I think it does, you should be able to go down farther for longer periods of time with scuba equipment (esp. if you use something like nitrox). I could be wrong though... this is out of my 20,000 leagues. (oh ho!)

<comment><USER12> "you should be able to go down farther for longer periods of time with scuba equipment (esp. if you use something like nitrox)."

This is wrong - nitrox doesn't let you go down _farther_ for longer periods [1]; in fact, oxygen toxicity happens at a shallower depth on nitrox than on regular air.

[1] <http://en.wikipedia.org/wiki/Nitrox#Oxygen_toxicity>

<comment><USER7> Good to know. I am a recreational diver but obviously not nitrox certified. :D

</comment></comment></comment></comment></comment><comment><USER13> I prefer these: <http://tritonsubs.com>

</comment><comment><USER14> I'd have thought that the underwater "plane" designs would be cheaper, more fun, and safer than this.</comment>


Ultimate tic tac toe - <AUTHOR> http://vikeshkhanna.webfactional.com/ultimate/

<comment><USER2> Looks like the first player has a significant disadvantage.</comment>


JSXBIN to JSX Converter DMCA Takedown by Adobe - <AUTHOR> https://github.com/github/dmca/blob/1dc576384cdcf2938aca792d83ad1921d30cc0ec/2016-03-11-Adobe.md <comment><AUTHOR> Quote from the repository:

> JSXBIN is a binary format of JSX, which is a superset of JavaScript made by > Adobe for automating certain tasks in Adobe products such as Photoshop. > Sometimes it's useful to decode and read JSXBIN files but since there's no > official decoder available, here is an alternative instead.

Archive of the README: [https://archive.is/MsJht](https://archive.is/MsJht)

Is this a legitimate takedown request?</comment>