Why All of You Suck - <AUTHOR> https://medium.com/@joshfester/10-reasons-why-all-of-you-suck-cd3aeb88e7d4

<comment><AUTHOR> It does not matter what I do. Of course I'm jealous. Who doesn't want $13 million? That's not the point. The point is that humans are collectively donating massive amounts of money to frivolous causes. I'm just trying to bring light to the fact that we could all be doing more to help people that truly need it (not me--I have a house, internet, food, etc).

</comment><comment><USER2> Eh?

You do a really good job advertising the cooler, but after reading this short little rant I still have no idea what it is you _do_ and why I should feel bad for not having thrown money at it.

Maybe you suck at basic economics. Maybe you should start selling coolers.

</comment><comment><USER3> For someone who doesn't seem to have a startup in any of those categories this just comes off as pretty ignorant / jealous in that people genuinely wanted a cooler more than any of your 5+ startups.

<comment><AUTHOR> You are missing the point. See my comment above.</comment></comment>


The failure of the digital computer (1998) - <AUTHOR> http://www.the-adam.com/adam/rantrave/computers.html <comment><USER2> This is remarkably similar to the sentiments I addressed in "The Tyranny of the Minimum Viable User"

[https://old.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...](https://old.reddit.com/r/dredmorbius/comments/69wk8y/the_tyranny_of_the_minimum_viable_user/)

The trade-off is one of intensity vs. ubiquity, and has pecedents, e.g., Dwight Macdonald's "A Theory of Mass Culture", 1950s.</comment>


Pierre Omidyar co-funded Ukraine revolution groups with US government, docs show - <AUTHOR> http://pando.com/2014/02/28/pierre-omidyar-co-funded-ukraine-revolution-groups-with-us-government-documents-show/

<comment><USER2> > "Glenn Greenwald's government-bashing blog"

I stopped reading at this point -- I felt I would lose my time reading the rest of the article. Keeping accountable is not "bashing".

<comment><USER3> Too bad, because I think the phrase was used to contrast the criticism of the government with the alignment of interests later in the article. The ultimate point is murky, but indicates some weaknesses inherent to "independent journalism" today.

<comment><USER4> There's absolutely no contradiction between disapproval of NSA spying and support of US foreign. The article does try to make that point and it's childlike in its stupidity.

</comment></comment></comment><comment><USER5> "When the revolution came to Ukraine, neo-fascists played a front-center role in overthrowing the country's president."

Can stop reading here (that is if you got past the point suggested by wreegab). Pure nonsense. Next thing you know the author will claim that Ukraine invaded Russia to take away Crimea.</comment>


The Neuroscience of Trust - <AUTHOR> https://hbr.org/2017/01/the-neuroscience-of-trust <comment><AUTHOR> _Former Herman Miller CEO Max De Pree once said, "The first responsibility of a leader is to define reality. The last is to say thank you. In between the two, the leader must become a servant."_</comment>


Health Insurance Costs Surpass $20k Per Year, Hitting a Record - <AUTHOR> https://www.bloomberg.com/news/articles/2019-09-25/why-is-health-insurance-so-expensive-20-000-a-year-for-coverage <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=21073443](https://news.ycombinator.com/item?id=21073443).

</comment><comment><USER3> [https://outline.com/ybpAuv](https://outline.com/ybpAuv)</comment>


Show HN: Our daily learning site, TIL, is five years old - <AUTHOR> https://til.hashrocket.com/ <comment><USER2> Your site always surfaces to the top of Google when I'm searching for the randomest things in history. Love it!

<comment><AUTHOR> That's so cool to hear! Occasionally, I do think it fills a 'hole in the internet'.

</comment></comment><comment><USER3> Super cool! Iloce the idea of learning something every day and I try.

</comment><comment><USER4> TIL your daily learning site TIL is five years old.

<comment><USER5> And it ELI5</comment></comment>


Turning a MacBook into a Touchscreen with $1 of Hardware (2018) - <AUTHOR> https://www.anishathalye.com/2018/04/03/macbook-touchscreen/ <comment><USER4> That is amazing.

I really wouldn't have expected this to work but once you read about it.... of course it would.

This is one of those things that while there maybe wasn't a 'problem' shows how knowing a few things critical, you can really solve problems / come up with solutions that nobody would have ever thought of (well I wouldn't have...).

<comment><USER5> >I really wouldn't have expected this to work but once you read about it.... of course it would.

It's a fun DIY project and you can get it _almost_ working. I suspect edge cases (stemming from different lighting conditions and imperfect finger detection) would render this method unworkable in general.

<comment><USER6> I wonder if this has ever been tentatively tested by the laptop makers, perhaps even by Apple. Surely thought about -- but tested?

<comment><USER7> There are plenty of Windows laptops with a touchscreen. In Apple's case MacOS isn't really designed for touch

<comment><USER6> No-no - I mean using the webcam and a mirror. I.e there would be a little mirror that would fold out of the screen.

<comment><USER8> I think his point was that it would be a bit silly to put this kind of solution into a product -- which is, in a word: jank -- when capacitive touchscreens are already a tried and true solution in production devices.

<comment><USER9> I often think "hand-pointing" interfaces have unexplored / unrealised potential... like, who would want a touch TV screen?! Sure, you could have the touch UX for the TV on your phone... but even better would be if you would be able to just point to the TV and _MAGIC_. The biggest problem I see is that humans aren't that good at pointing - we can only "aim" with one eye, keeping both eyes open messes it up.

<comment><USER10> I've often wondered what having one of these on a laptop, tracking space above the keyboard / in front of the screen, would be like: [https://www.leapmotion.com/](https://www.leapmotion.com/)

Gestural stuff is nice when it's transparent and guess-able. Sadly not often the case, but when it is it's pretty magical.

<comment><USER11> > on a laptop, tracking space above the keyboard

I tried doing this with the internal webcam, using a clip-on fisheye lens, and mirrors. And eventually punted, using the bare webcam only for head tracking, and adding usb cameras on sticks perched on the laptop screen. With more sticks to protect the usb sockets from the cables. And lots of gaff tape.

> leapmotion

Leap Motion has finally been acquired, so the future of the product is unclear. And it's Windows-only (the older and even cruftier version supporting linux, doesn't do background rejection, and so can't be used pointing down at a keyboard). But it has apis, so you can export the data. My fuzzy impression is it's not quite good enough for surface touch events, but it's ok-ish for pose and gestures. When the poses don't have a lot of occlusion. And the device is perched on a stick in front of your face.

> Gestural stuff is nice when it's transparent and guess-able. Sadly not often > the case

I fuzzily recall some old system (Lisp Machine?) as having a status bar with a little picture of a mouse, and telling what its buttons would do if pressed. And a key impact of VR/AR is having more and cheaper UI real estate to work with. So always showing what gestures are currently available, and what they do, should become feasible.

Even on a generic laptop screen, DIYed for 3D, it seems you might put such secondary information semitransparently above the screen plane. And sort of focus through it to work. Making the overlay merely annoying, rather than intolerable.

But when it all works, yeah, magical. Briefly magical. The future is already here... it just has a painfully low duty cycle. And ghastly overhead.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> So I was expecting one of those sensors that can turn a TV into a touchscreen with like an IR sensor or something so I checked this wondering how they were so cheap.

I was delighted to see this is so much better. Figuring out touch events from the reflection is really cool. Well done.

<comment><USER13> What they did not factor in was the cost of the software.

You can make junkyard bound stuff do amazing things when you program them right, but you pay for that programming or time spent.

<comment><USER14> The software is a "one time cost" in quotes due to maintenance etc but talking in broad strokes which wouldn't impact the claim of $1 touch

Or to put it another way you wouldnt invent a new way to desalinate seawater and then say the cost is $10/litre instead of 2 cent because of r&d on the device you made..

<comment><USER15> > invent a new way to desalinate seawater and then say the cost is $10/litre

Depends on the marketing strategy, most likely. But I like GP's point about undervaluing programmer time. It is non-free and everyone down to the programmers themselves tend to grossly underestimate its cost.

Humans are kind of expensive to keep alive and happy enough to program willingly

/That last statement had more caveats than I wanted...

<comment><USER16> It really depends on their intention, whether they consider that part of the work DIY or not.

If I paint my wall, I would generally say it costs the price of the paint, not whatever I'd have to pay to have someone do it for me.

Or what about the people who tinker with their own smart home solutions with arduinos and raspberries. If you factor in the price of work/research/coding, it would be very hard to justify not buying an off-the-shelf solution instead.

<comment><USER15> > If I paint my wall, I would generally say it costs the price of the paint

That's the mentality I'm challenging here. Mentally you don't account for the cost of your time, but from an outside perspective, you're spending it all the same.

That you have to factor in the price of labor with DIY electronics is the main reason you don't see more of those easy electronics projects available as some off-the-shelf contained product (where's my IoT API-accessible thermometer for $10!!!???).

</comment></comment></comment></comment></comment></comment><comment><USER17> Next step is to gauge the amount of blood underneath the fingernail to tell the amount of pressure being applied.

<comment><USER18> I had an idea years ago using a webcam and the 'blood under fingernail' to have a trackpadless-trackpad (i.e. same as this project but on your table).

Maybe some time-rich person will fork it and do so.

</comment></comment><comment><USER19> This is exactly what a hackathon project should be. Delightful, innovative and scoped small enough that they produce results without too much bullshit. Not the usual "world changing" hacks that end up abandoned the moment the event concludes. If only events encouraged more hacks like these.

<comment><USER20> The last hackathon I attended, the winners just built something from an Instructable that existed well before the hackathon.

My friends and I built a time machine radio (i.e. you tune it to a decade, with a knob and everything, and radio news from the decade was included if we could find it) and won best hardware hack, so it wasn't a total loss. Had a blast either way.

<comment><USER21> > The last hackathon I attended, the winners....

(Not a comment on you, but you poked the button)

While my hackathon experience is limited, I think any attempt to crown a "winner" reduces the experience. Of course, I am too sensitive because everyone can just enjoy it...but as soon as there's a winner there starts to be rules that people try to game, the are added restrictions and limits that reduce what is being created, etc. And creating is the point.

<comment><USER22> However, you do want to show off the more interesting/higher quality projects, to encourage further work, and get the whole thing jiving (people _enjoy_ competition; it oils the machines)

The problem I think is that judges themselves are incompetent/careless — when you promote a "bad" winner, you just discourage everyone from trying, because they realize there is no value to this kind of promotion; its bullshit.

I had a similar experience in my university — some kind of business project idea competition; we submitted my lab's current project, and there were other interesting projects involved who I would have been happy to lose to.

Instead I lost to the girl with the contentless idea for edible spoons for developing countries... an idea I'd seen repeatedly in recent news cycles because some NGO in India was doing it for the last three years.

Five minutes of googling would have discovered this, but instead we simply ignored the competition since.

Attending itself was valuable, along with the half-attempt at winning — we clarified the project and ideas, and had an excuse to clean things up — so it would have been a good exercise to do yearly (and probably for the other projects involved), and the competition was healthy.

But it just takes an incompetent judge to spoil the whole thing.

There's nothing wrong with people trying to game the competition, its a natural function of competing. But the judges are meant to operate as experts, and an expert should have (some) ability to discern bullshit from something real.

<comment><USER19> Agreed. I wish hackathon judges actually understood how to question and analyze projects critically. I attended probably one of the most prestigious and well regarded college hackathons, where the grand prize was won by a project that did speech to text, then text to sign language. What nobody pointed out or acknowledged, was that __deaf people can read __. But since the project was done on a HoloLens the judges got swept away by the fancy AR and awarded them the prize.

I've become extremely skeptical of the hackathon model in general. It doesn't really produce good projects or products, it encourages an unsustainable style of working and it's a terrible place to recruit good developers. It can encourage people to build stuff, but only monkey patched, bursting with buzzwords, overly flashy projects that are thrown away at a moment's notice.

<comment><USER22> >What nobody pointed out or acknowledged, was that deaf people can read

I actually did something similarly stupid in college; for an embedded development class, my team needed a final project. I proposed a hat for the blind, with distance sensors and buzzers on the inside to inform distance from the walls and such. We also used black conductive thread on a black hat, so it was impossible to work with except for the girl who threaded it in the first place.

Easily the professor's favorite project, and I guess he still uses it as an example for future projects (and at some point he had some team extending it into some kind backpack?)

Later a friend working at a retail store selling products for the disabled contacted me about the project; apparently his boss was interested.

What no one acknowledged is that blind people are not walking into walls... the cane is far more practical, efficient and effective tool than this thing could ever be.

I had meant it to be a joke.

<comment><USER23> Rebrand this as a device for people to not waste precious time looking where they're walking, and it's a gold mine.

<comment><USER24> "Ever worried about those people who are reading their phone while walking around? Now you can randomly put this hat on their head."

The best thing about it is, the people who need and want the device aren't the ones walking around reading their phone, it's the ones who can't help but mind someone else's business - and this merely feeds their need rather than satisfies it. So there will be an never-ending market of unsatisfied busybodies.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> [https://www.playosmo.com/en/](https://www.playosmo.com/en/) <\-- this also uses a mirror to refocus the built-in camera but on another surface, not the screen.

</comment><comment><USER26> Hmm, given camera is on top, computing homography and rectifying the perspective image would give fairly good precision around the camera, falling off quickly with distance, likely not being very useful at the bottom of the screen. Also, it's likely sensitive to both ambient light and the dominant light on the screen, in dark rooms with dark themes it might be pretty off, as most computer vision algorithms need constant tuning for changing conditions.

<comment><USER27> Maybe you could add an IR LED that could be observed by the webcam, but not in the visible spectrum. I'm not sure if the MacBook webcam includes an IR filter or not. It wouldn't help the precision, but might make the camera less susceptible to changes in ambient light.

<comment><USER28> Even 5$ webcam include a IR filter, the image quality without is pretty awful, so I'm pretty sure that apple webcams have it.

<comment><USER29> I recently shined a remote control into my late 2013 macbook pro's camera and I totally saw the ir light. Not saying that you're wrong, I don't know if there are filters but only for certain specific wavelengths or something like that.

<comment><USER30> Remote controls are pretty bright IR, so it could be just that it only blocks up to a certain brightness.

<comment><USER29> Makes sense. Direct IR light is probably harder to block.

</comment></comment></comment></comment></comment></comment><comment><USER31> Wow, this is a great idea! Looking at the video, looks like the latency isn't great; what kind of problems should be solved for this to have a ~100ms latency?

Rewriting it in C/C++/Rust instead of Python would be one... Any ideas?

<comment><USER32> Slightly off topic, but C/C++/Rust are always the go-to languages when talking about high performance. People love the speed of C but it's so bare-bones that they move to C++, or it's too dangerous so they move to Rust. But those are much too complicated, so people came up with Zig and Nim and D instead, but those are very _far_ from C, even though they're not _as far_ as C++ and Rust. So I'm wondering, are there any languages _almost as close to C_ but _slightly_ safer and _slightly_ less bare-bones? Because I like C a lot, I think it's a great language with an excellent simplicity, except for some slight rough edges.

<comment><USER33> Crystal? Hasn't reached 1.0 though.

<comment><USER34> I think Crystal is garbage-collected, right?

<comment><USER35> Yeah, the whole language is designed around it. Impossible to remove without rewriting it from scratch: [https://github.com/crystal- lang/crystal/wiki/FAQ#language-x-...](https://github.com/crystal- lang/crystal/wiki/FAQ#language-x-has-feature-y-why-dont-you-have-such-feature)

</comment></comment></comment></comment></comment><comment><USER36> Wow! This is really creative. Gets my gears turning on all the other applications for using opencv as an interface!

</comment><comment><USER37> I love this. When I was young I saw a hack for an Amstrad which added light pen support. If I recall it effectively synced with the scans on the crt which tells you your coordinates. I wanted to build it so much as a kid, but never could. It's the sort of thing that really fired my imagination and helped me fall in love with computers.

</comment><comment><USER38> I wonder what the field of view is like. The demos only show it being used towards the middle of the lower half of the screen - can the camera really see the top left or right corners?

<comment><USER39> From the conclusion:

> With some simple modifications such as a higher resolution webcam (ours was > 480p) and a curved mirror that allows the webcam to capture the entire > screen, Sistine could become a practical low-cost touchscreen system.

</comment></comment><comment><USER40> The hovering aspect of this makes it something quite special, a feature normal touchscreens don't have. I imagine css ::hover elements would feel nice with this.

</comment><comment><USER41> Maybe next someone will build a "camera keyboard" for my iPad. Turn any surface into a keyboard with a camera and machine vision.

<comment><USER42> Do you mean similar to a projection keyboard[0] but without actually projecting a keyboard onto the surface and using the integrated camera?

[0] [https://en.wikipedia.org/wiki/Projection_keyboard](https://en.wikipedia.org/wiki/Projection_keyboard)

<comment><USER43> Ooh, how about this?

1\. Point a camera at a surface (be it a piece of paper or whatever).

2\. Write/print a word on that paper and use CV/OCR to parse it.

3\. Detect when a person has pressed on that word and exec the command specified by the text.

Instant macro pad?

<comment><USER44> 4\. Scatter bunches of 'rm -rf /' pieces of paper at your local wifi hotspot.

<comment><USER45> I see, you thought the same as I did. :-D

</comment></comment></comment></comment></comment><comment><USER46> Is anyone found a stylus that works with the macbook's trackpad? The usecase is to be able to draw some diagrams during video calls/screencasst.

Trying to avoid the wacom/tablet path to keep it lightweight :)

<comment><USER47> I bought a case in India for my Kindle Paperwhite which came with a stylus [1]. That stylus works, and works quite well with my 2015 MBP.

[1] - [http://www.proelite.co.in/Amazon-Kindle/All-Amazon- Kindle-10...](http://www.proelite.co.in/Amazon-Kindle/All-Amazon-Kindle-10th- Generation-2019-Slim-Smart-Flip-case-Cover--Deep-Blue--with-Stylus-Pen--Not- Fit-Paperwhite--id-3984513.html)

</comment></comment><comment><USER48> Very neat! I am wondering whether it could also recognize multiple fingers and thus sort of emulate multitouch gestures, although my guess is latency is not great with one finger already, so this might not work well.

Als interested to see how it works with different lighting and how dirty the screen can get before recognition fails because the reflection is too "muddled" ;)

</comment><comment><USER49> One issue I imagine is coverage. How do you get decent horizontal resolution on top and on bottom of the screen?

Either you have a mirror that converts your webcam into ultra wide angle so you cover the top edge of the screen (which you pay for by poor resolution on the bottom) or you decide not to cover the whole top area (which is where most window control elements are).

The video action all happens on the lower half of the screen for a reason.

A solution would be some sort of orthographic lense, that basically splits the sensor into multiple distributed lenses to avoid the FOV problems. This however would be not trivial to get right without serious tools.

<comment><USER50> Use a pinball, not a flat mirror, and map back to something like a flat plane before processing. The registration is a bit harder, but not by an intractable amount.

</comment></comment><comment><USER51> Long time ago there was an ad PC vs Mac. PC guy had usb camera tapped on top of his head, claiming how PC are entering new modern age. Mac had camera build in. This kind of feels similar.

</comment><comment><USER52> Pure brilliance. While many commenters seem to focus on computer applications this could be very viable solution for industrial environments for touch controls.

</comment><comment><USER53> That is great!

On the topic of touchscreen Macbooks, I've been using my Mac a lot less since I've spent a lot of time on a touchscreen Windows laptop. It is super handy! A lot of times when using the Mac I'll absentmindedly drag something on the screen only to be disappointed. Apple's resistance to the idea reminds me of their stubbornness on the single button mouse. Admitting you're wrong is not a weakness.

<comment><USER54> What hardware do you have? All the touchscreen windows laptops I've tried have the responsiveness and accuracy of a touchscreen from 1990.

<comment><USER55> Resistive touchscreens which were dominant in 1990 typically have higher accuracy than the capacitive touchscreens of today. But they have terrible usability because you have to apply pressure to the screen to use them.

</comment></comment></comment><comment><USER56> And they called it Sistine, which flabbergastingly shows that coming up with a good name for something is indeed possible.

</comment><comment><USER57> This probably needs [2018] in the title?

</comment><comment><USER58> Stunning out of the box thinking. Fantastic idea and implementation. Color me impressed.

</comment><comment><USER59> This is super interesting, I'm about to undergo a small DIY smart mirror project and wanted touchscreen capabilities but all the hardware solutions seemed impractical and expensive. This might be a super easy way to make that work.

</comment><comment><USER13> It's a good idea and great implementation.

However I do strongly feel that touchscreen is the opposite to productivity, maybe usability to the end users, but definitely not what developers need/want.

<comment><USER60> It helps older users who have trouble with the mouse/touchpad.

<comment><USER61> A touch screen is definitely a more approachable method to interact with computers for people who are not as tech literate. My grandma had a computer for years and only kind of used it. Then she got an ipad from a relative and she uses everyday, from casting netflix to her chromecast to reading ebooks she rented from the library.

I may not prefer touch screens but they can be a complete game changer for some users.

<comment><USER62> There is nothing wrong with touch screens when they are horizontal like a tablet. Vertical touch screens like on laptops or desktops are not ergonomic, and especially so for the elderly.

<comment><USER63> Entirely horizontal touch screens have the same problems as trackpads/keyboard/mice (or piano playing) that they can have in terms of wrist strain/RSIs (including carpal tunnel), and sometimes elbow movement strain/RSIs (including things like "tennis elbow").

Vertical touch screens trade the more traditional wrist/elbow strain/RSIs for other arm/elbow/shoulder strain/RSIs (including things like "gorilla arm").

Given the nature of repetitive stress, the growing consensus seems to be __not __that one orientation is better than the other, but that a _range_ of orientations, and a mixture of movement types / input methods is better. For instance, move your arm some to touch a vertical screen, to mix things up from mouse movements and keyboard movements.

</comment></comment></comment></comment></comment><comment><USER64> This is great. I notice it's Python 2, could this be ported to Python 3 easily or some inherent issue in upstream deps?

<comment><USER65> While I understand the desire for a unified Python ecosystem as much as anyone - this kind of pettifogging is not going to convince anyone to switch to Py3.

Consider if the authors of the article had used (for example) Ruby - <USER2> probably wouldn't ask why they didn't do it in Python3, so why do you do it if they write it in Python2?

<comment><USER66> I think they asked in a respectful manner, so I don't see anything wrong with their comment really.

Python 2 will be EOLed soon.

[https://pythonclock.org/](https://pythonclock.org/)

4 months 25 days 5 hours left until Python 2 is retired. After that point it will no longer be maintained by the Python project.

Of course Linux distros and companies will keep Python 2 running for years to come because of all of the tools that are Python 2 only.

New projects ought to be written in Python 3. However, in this case my guess would be that OP probably used Python 2.7 because macOS ships with Python 2.7 preinstalled.

So if we could, Apple are the ones that we ought to speak to. Convince Apple to ship macOS with Python 3 pre-installed.

</comment></comment></comment><comment><USER67> Incredible. And here I thought a good assortment of lollies at the local corner store was the best $1 could do

</comment><comment><USER68> I hope this hack get's so popular that the folks at Apple finally makes a MacBook with a proper touch screen.

</comment><comment><USER69> I normally hate touchscreen computers, but this project and its implementation are really cool.

</comment><comment><USER70> Could we just add some shiny window tint foil to normal laptop screens to achieve this effect?

<comment><USER30> This is a normal laptop screen. What do you mean?

</comment></comment><comment><USER71> This project makes laptop vendors selling touchscreen laptop with premium price cry.

</comment><comment><USER72> Curious what kind of CPU usage the OpenCV code requires on the backend...

<comment><USER73> There is some well-informed speculation about latency up-thread, but I've tinkered with OpenCV from time to time. Specifically, I used ROS and OpenCV to do face detection on a netbook in about 2012. That worked out pretty well - <USER3> would track multiple faces in realtime. Edge detection is a different algorithm, but isn't super likely to be the origin of the latency issues they're having. It's just a threshold check over a window of a few (e.g. 3 or 5) pixels, multiplied by the dimensions of the image.

</comment></comment><comment><USER74> What sorts of improvements could you do if you used a stylus instead?

</comment><comment><USER75> _The basic principle behind Sistine is simple. Surfaces viewed from an angle tend to look shiny, and you can tell if a finger is touching the surface by checking if it's touching its own reflection._

This is especially true of MacBook screens!

</comment><comment><USER76> Yay now their software can see everything on your screen.

<comment><USER77> As opposed to a driver that may have greater permissions?

</comment></comment><comment><USER78> This could be extended for multitouch too, yeah?

<comment><USER79> Yes, but it would have a possibly annoying limitation of occlusion making the multi-touch fail at some positions. Fingers very close to the camera would appear huge and occlude everything else.

</comment></comment><comment><USER80> This is really f'ing cool. Nice work!!

</comment><comment><USER81> Is this something he should have patented?

<comment><USER30> The main idea was probably patented decades ago. There have been optical touch screens around for ages (that use multiple cameras for good multitouch, and edge IR illumination to make detection more reliable and precise).

</comment></comment><comment><USER82> That... is a _hack_! Awesome :D

</comment><comment><USER83> Now, that is just smart.

</comment><comment><USER84> whoa! amazing. out of box thinking

</comment><comment><USER85> Brilliant

</comment><comment><USER86> Well done!

</comment><comment><USER87> Prototypes are cool, but I think this is dead.

Anything that requires tons of visual calibration is serious work. Both for the programmer and the computer.

It worked for a planned demonstration, but I imagine this would be impossible for Mass production. And I wonder if the users found it useful due to latency and accuracy problems.

<comment><USER88> The authors didn't publish thinking "this is going to rock the world, it's ready for mass production"... More along the lines "hey fellow hackers, we found a way to emulate a touch screen at 1% of the price".

<comment><USER87> But if the latency and accuracy isn't great, did they solve anything?

<comment><USER89> They weren't trying to solve anything. They wanted to see if they could make it work, and they did.

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

<comment><USER91> >Are reposts ok?

>If a story has had significant attention in the last year or so, we kill reposts as duplicates. If not, a small number of reposts is ok.

That post is from over a year ago, and didn't get much traction.

<comment><USER92> Although it was indeed posted over a year ago, 239 points is certainly traction.

<comment><AUTHOR> Missed the old post. Thought reposts were rejected automatically (like on Reddit).

<comment><USER92> FWIW it does, although it's fussy and only works on posts in the last few days.

tbh Reddit's repost detector causes more problems than it solves (it still triggers if the original post was removed).</comment></comment></comment></comment></comment>


Do you want to work on ads? Or change life? - <AUTHOR> http://www.scribd.com/doc/2516662/We-want-you-on-board

<comment><USER2> While the startup itself does sound cool, this link is not informative and little more than a dressed-up employment ad.

Suggestion - instead post a blog entry or link to a page describing what you're doing and why we absolutely have to join. You can do better than 5 bullet points on a scribd document.

<comment><USER3> At least they put in a bit more effort than last time: <http://news.ycombinator.com/item?id=125209>

<comment><AUTHOR> Fair points =)

Check out our more detailed posting here: <http://snaptalent.com/ads/88/>

</comment></comment></comment><comment><USER4> I feel uneasy about sending my data to an anonymous email address, to be honest.</comment>


Show HN: Mybema, the result of what'd happen if Yelp + Zendesk collided - <AUTHOR> http://www.mybema.com

<comment><AUTHOR> Creator here. I've been building this for a long time, in fact this is still my first project from 2 years ago when I started teaching myself rails. The landing page is ugly, I know, but sign up and the rest of the site isn't that bad. promise.

This is a site aimed at helping consumers find awesome brands that will provide genuinely good service. It's also got the functionality for consumers to resolve issues directly with brands (instead of having to do so on Twitter thereby freeing up their social channels to be social). So it's reviews, discovery, and resolution which is why I think of it as a mini zendesk and Yelp amalgamation type of platform.

Speaking of which, if you run a startup, please mail me at email@example.com from your startup's domain address so I can get you started with a customer support platform and everybody can win :)

AMA/ I'd love some feedback (and some users!).

<comment><AUTHOR> Oh yeah, in ancient Greek law courts, bemas were raised platforms that two parties stood on to present their arguments and disputes. Hence the name.</comment></comment>


Hey Silicon Valley, the British are coming - <AUTHOR> http://techcrunch.com/2013/06/14/svip/

<comment><AUTHOR> I don't like this. We, in the UK should be doing more to support and improve our entrepreneurs. Not sending them off to America.

As the article says, some of the students will find ways of staying.</comment>


Salted Password Hashing – Doing it Right - <AUTHOR> https://crackstation.net/hashing-security.htm <comment><USER2> This article looks great for anybody who wants to know the details. But "doing it right" is much simpler, and doesn't really need an article:

"Use an accepted key derivation function, such as PBKDF2, bcrypt or scrypt".

All the work described is encapsulated into the concept of a key derivation function. Telling people to go into the details is like telling people how to do encryption by describing how to implement AES and Twofish. Don't go there. Find a library that implements a key derivation function, and use it. PBKDF2, bcrypt and scrypt are all fine.

<comment><USER3> It's a little premature to be recommending scrypt. There have been some posts on openwall suggesting it may be weaker than bcrypt, although it is also still a work-in-progress. I'd hold off until it is more battle-hardened before either recommending it or using it.

<comment><USER4> Link for that? All I find is mentions of its weakness when used with very small amounts of memory (like Litecoin's silly decision to go with 128KB).

<comment><USER3> Sorry for late reply, the post I was thinking off (and didn't revise before posting) is [http://www.openwall.com/lists/crypt- dev/2012/09/02/1](http://www.openwall.com/lists/crypt-dev/2012/09/02/1)

Search for the word "weaker"

<comment><USER4> Thanks - that's actually the post I was thinking of. Considering on most modern machines scrypt will likely tune itself to use 512MB, a 1MB buffer's pretty small, but it would be interesting to know where the cutoff for significantly-better-than-bcrypt might be. I expect most sites could throw 16MB at logins without much difficulty (as suggested further in that thread).

</comment></comment></comment></comment></comment><comment><USER5> That's a lot of code in the PHP example! To use bcrypt you can just do this:

      password_hash($password, PASSWORD_BCRYPT)

From version 5.5 that is, but you can get a compatibility library for older versions.

<comment><USER6> I was wondering how bcrypt can be secure while not requiring a salt to be passed in, since the article devotes so much time to salts. I found the answer here: [http://stackoverflow.com/questions/6832445/how-can-bcrypt- ha...](http://stackoverflow.com/questions/6832445/how-can-bcrypt-have-built- in-salts).

Basically, bcrypt randomly generates a long, probably-unique salt for every hashed password, and the salt is stored along with the hash by simply concatenating it to the string (e.g. "randomsaltZdR3/passwordhashMP2tA"). To check an incoming password against the stored hash, bcrypt splits the stored string on '/' to extract the salt, hashes `password+salt`, and compares that hash against the one to the right of '/' in the stored string.

<comment><USER5> The PHP function produces output compatible with the crypt() function, which has not only the salt and the hash, but also includes the type of algorithm and the bcrypt cost.

This means that you just whack the hash and the password the user entered into password_verify(...) and it will tell you if you have a match - you don't have to keep track of the four parameters.

The beauty of that when a stronger algorithm comes out or you want to increase the cost factor of your passwords, you just change the hashing code and you don't have to do anything fancy to not break all your old hashes.

You can also use the password_needs_rehash(...) function once you verify to see if you should rehash the password to bring it up to the new level.

<comment><USER7> In general, using the defaults (mcrypt_create_iv() using dev/urandom for the salt and bcrypt with a work factor of 10 are specified with PASSWORD_DEFAULT in the curreent implementation) along with password_needs_rehash() will keep you up to date with no "retouch" necessary. When the default changes, password_needs_rehash() returns true, and you then rehash with the new defaults. All you need to do is make the db column wider than necessary for the current defaults to put maintenance off into the future. (The only real problem is that the hash function truncates passwords at 72 characters at the moment, which will force you to pre-hash the user value with something like SHA256 for very long passphrases.)

</comment></comment></comment></comment><comment><USER8> Question: Is there any reason to prefer bcrypt over pbkdf2, or vice versa?

I can see that scrypt has an obvious advantage over both, since it is memory- intensive unlike the others. But when comparing bcrypt with pbkdf2, I can't seem to find any reason to prefer one over the other.

bcrypt is everyone's darling at the moment, but why so little love for pbkdf2? PHP 5.5, for example, bundles a very convenient password_hash() function that defaults to bcrypt, whereas hash_pbkdf2(), which is also new to PHP 5.5, won't even generate a salt for you.

Is pbkdf2 broken in some way, or do people simply not trust it because it's just a bunch of iterations of sha256?

On the other hand, has anyone discovered a weakness in bcrypt and/or the underlying blowfish algorithm?

On my computer, pbkdf2 with 20,000 rounds of sha256 takes about as much time as bcrypt with a cost factor of 10.

<comment><USER9> The long and short of it is that PBKDF2's assumptions are better vetted, but bcrypt is stronger _if_ its assumptions are correct.

<comment><USER10> Exactly what do you mean by this?

<comment><USER9> That PBKDF2 has been more extensively studied, but it has lower memory requirements. So the chances of a surprising vulnerability being found in bcrypt are higher, but failing that, it is the better option.

<comment><USER10> In what way has PBKDF2 been more extensively studied? It's the product of a standards effort, not academic research. bcrypt was introduced in a refereed Usenix paper. I'm not suggesting bcrypt is particularly rigorous either, but I'm unclear on what "study" you're referring to for PBKDF2.

I'm also unclear on which "assumptions" you believed bcrypt depended. Could you be a little more specific, please?

<comment><USER9> I'm just going by what I've read elsewhere, and I don't have citations on hand. I'm not a security expert, I just try to listen to security experts.

So if you say bcrypt is as well vetted as PBKDF2, I'm going to defer to your judgment and update accordingly.

<comment><USER11> What's maybe more relevant is that PBKDF2 is explicitly called out by name as the Proper Thing in various standards, so it's less work to use it in environments where people care about those standards.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Which cryptographically strong hashing algorithm to use? It depends on situation. I think adaptive one ( PBKDF2, bcrypt, and scrypt) should be used all the time. PBKDF2 if you want to hash on devices with limited computing power, bcrypt and scrypt on standard servers.

Other one like SHA256, SHA512 are supposedly for fast, cryptographically strong hashing. At least that's how I view it.

> If you have special security needs, enforce a minimum length of 12 > characters and require at least two letters, two digits, and two symbols.

I hate when passwords require certain patterns. See [http://i.imgur.com/hvyziAx.png](http://i.imgur.com/hvyziAx.png) from USCIS.

And I think there is one point missing: limit the max number of characters for the password. As shown in Django's password DoDS attack, don't allow long password takes up 1MB.

<comment><USER13> > I hate when passwords require certain patterns.

I think people started doing this when passwords were typically short, to increase the search space. Although one unwanted side effect is that it also reduces the search space, since if you know that pattern requirement then you know not to brute force anything that doesn't have two letters, two digits etc.

But assuming a required pattern of a certain length does the job (whatever the system administrators think "the job" is), I wonder how much longer a password needs to be, with no pattern requirement, and be as difficult or more to crack than the shorter patterned password.

<comment><USER12> I think a good password would be something like, instead of writing the letter "a" in ascii, you use "a" in another encoding (I forgot what that called). I supposed no one ever thought of cracking such password yet.

The worst I have seen is from USCIS. See this image: [http://i.imgur.com/hvyziAx.png](http://i.imgur.com/hvyziAx.png)

<comment><USER14> > I supposed no one ever thought of cracking such password yet.

Good luck with that!

</comment></comment></comment></comment><comment><USER15> I have question. Is salting solution like hash_function(salt_hardcoded_in_app + password_string + user_unique_salt) bad? Does adding hardcoded salt reduces security of app? Why? Thanks for any info on that.

<comment><USER16> i usually add pepper like you're describing prior to bcrypting. my thoughts being that it adds a bit of security in case your db gets compromised but not your server/code. the chance that one happens without the other may be slim.

<comment><USER17> They don't need to compromise your server/code. They just need to be able to create an account (with a password they know) before they dump your database. Then it's just a matter of brute-forcing the 'pepper.'

<comment><USER16> yes, but the pepper still must be brute forced, and to do so requires that each attempt is run through bcrypt.

if you store the user_salt and the output of bcrypt(code_pepper + known_pass + user_salt) in your db, guessing the pepper requires comparing the bcrypt() output of every random pepper. you are as unlikely to brute force it as the plaintext pass of other users.

this type of pepper is essentially a mechanism for key stretching [1]

[1] [http://en.m.wikipedia.org/wiki/Key_stretching](http://en.m.wikipedia.org/wiki/Key_stretching)

</comment></comment></comment></comment><comment><USER18> Seems to be down, here's the google cached version: [http://webcache.googleusercontent.com/search?q=cache:S76Yg0P...](http://webcache.googleusercontent.com/search?q=cache:S76Yg0P_ArEJ:https://crackstation.net/hashing- security.htm+&cd=1&hl=en&ct=clnk&gl=uk&client=ms-android-google)

</comment><comment><USER19> It's always shocking to me how many people just assume that a login/password system should store everything in plain text. This was a pretty good explanation of the right way to hash.

One problem though with this guide, some experts think it makes sense to add some extra computation to make it a little bit more difficult to compute the hash, for example creating a hash loop which rehashes 10,000 times or something similar.

In the past, I've found the following php tutorial really well written, and comprehensive:

[http://forums.devshed.com/php-faqs-and-stickies-167/how- to-p...](http://forums.devshed.com/php-faqs-and-stickies-167/how-to-program-a- basic-but-secure-login-system-using-891201.html)

<comment><USER20> I remember the incident when the League of Legends server got hacked and the attackers got all the passwords in plaintext. After that my google account almost got hijacked because I reused passwords - lesson learned :D (To be honest, I didn't expect one of the largest online games to have such incompetent programmers) This guide is a must for everyone who handles user passwords.

<comment><USER21> That has happened to me as well, when Dropbox leaked passwords (they claimed only emails leaked... bullshit). I reseted the Dropbox password right away, but someone had access to my Steam account with the same password and purchased a game. I was able to get a refund, but my password probably got into some forum, every other week or so someone attempts to login into my Steam account (Steam now requires a token sent by email to login from a different computer).

Lesson learned, never reuse passwords.

</comment></comment></comment><comment><USER22> Node.js password hash module, node version >= 0.11.11. [https://github.com/fundon/pbkdf2](https://github.com/fundon/pbkdf2)

<comment><USER23> How is this better than the built-in pbkdf2 in node?

[http://nodejs.org/api/crypto.html#crypto_crypto_pbkdf2_passw...](http://nodejs.org/api/crypto.html#crypto_crypto_pbkdf2_password_salt_iterations_keylen_callback)

<comment><USER22> Node.js stable version(0.10.x) can not change algorithm. [http://nodejs.org/api/crypto.html#crypto_crypto_pbkdf2_passw...](http://nodejs.org/api/crypto.html#crypto_crypto_pbkdf2_password_salt_iterations_keylen_callback)

</comment></comment></comment><comment><USER24> Question: that article suggest to hash passwords client side too. This has any security advantages?

The only one that I can think of is that an eventual MITM can't sniff your password, and then try to reuse it with other sites (as he only has an hash specific for a site, and not your password). Is that all?

"If you are worried about the computational burden, but still want to use key stretching in a web application, consider running the key stretching algorithm in the user's browser with JavaScript." make it sounds like I can use a lighter hash-solution server-side if I use key stretching client-side (at least to me, non native here so probably I'm just reading that wrong).

<comment><USER25> IMO Hashing on the client side is a terrible idea. There is now no way for the application to check the complexity of the password on the server side. Relying on client side controls to do the same is almost useless.

<comment><USER26> Why do you think it's useless? Not transmitting the password in plain text is clearly a win, and you can do whatever checks you need on the client side just as easily. (If a user wants to fool whatever checks you have, they can do that whether or not you have server-side checks--it happens all the time.)

<comment><USER27> It's fairly useless: If an attacker can sniff your connection he can just submit the encrypted password he sniffed to the server. The only win you have is that the attacker can't see the password itself, a potential bonus when people reuse passwords.

However, if you can sniff the connection you can probably alter it and inject javascript that submits the clear-text password to the attacker.

<comment><USER26> We are just talking about scrambling the password. You would still be using e.g. SSL/TLS or TLS-SRP for the transport. There's nothing "useless" about it.

<comment><USER27> Well, useless as in "added implementation complexity and no gain". It won't hurt much either, but you could be spending your time better elsewhere, for example in tuning your SSL/TLS-setup.

<comment><USER26> No. There's absolutely a gain. A big one, too. The main reason it isn't done today is not that it isn't useful, but that it's too slow to run e.g. bcrypt on the client without native browser APIs. WebCrypto will change that by adding PBKDF2 as a module accessible from JavaScript.

The main reason we encourage people to use key stretching algorithms on the server is that, if an attacker gets access to a database of password digests that aren't very strong, they can trivially be reversed.

Doing this key stretching or "password scrambling" on the client side simply moves the processing burden from the server to the client. There is nothing less secure or less useful about it.

<comment><USER28> There _is_ , if you don't again hash the passwords on the server. This is why new password-hashing proposals like [Catena]([http://eprint.iacr.org/2013/525.pdf](http://eprint.iacr.org/2013/525.pdf)) include an official "server relief" mode where the majority of the hashing is done on the client side, but there's still a final server-side transformation step.

Until such time as these things are readily available, recommending that people do client-side hashing is absolutely going to result in trivially poor implementations.

You might want to consider that if these problems were as trivial as you seem to believe, there would _already exist a library vetted by cryptographers_ to do exactly that.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> The java version instantiates a new SecureRandom instance every time it creates a new salt. While I don't think this hurts the randomness of the salt, it's an unnecessary performance hit.

<comment><USER30> As far as I know, that behavior is best practice. An instance of SecureRandom does not automatically receive new entropy over time. If you desperately need to keep using that same instance, you have to keep seeding it.

<comment><USER29> You can use a SecureRandom implementation that uses the underlying entropy pool for every call, or you can use an ordinary implementation of SecureRandom and call getSeed(numBits) instead of next(numBits), or as you mentioned, you can call random.setSeed(random.getSeed(NUM_BITS) every once in a while. Finally, if you are on linux the default SecureRandom provider will mix urandom with the prng output on every call to nextBytes, so there's no need to reseed at all.

Anyway you look at it, there's no good reason to instantiate use a fresh SecureRandom instance every call.

<comment><USER31> As this is a tutorial, the snippet will likely be copy-pasted into production code running on God knows what OS by someone who can't imagine why there could be a problem with seeding from the system clock. Using a fresh instance allows the code to be portable, noob-friendly, and concise, which are important traits for its context.

</comment></comment></comment></comment><comment><USER32> ...or you can consider going password-less: [https://news.ycombinator.com/item?id=7283650](https://news.ycombinator.com/item?id=7283650)

</comment><comment><USER33> SRP [1] is a very nice alternative for storing password hashes in the database. As an added bonus, it prevents MITM attacks which steal user passwords before they reach your servers. Meteor [2] JS framework successfully uses SRP for authentication.

[1] [http://srp.stanford.edu](http://srp.stanford.edu)

[2] [http://docs.meteor.com/#meteor_loginwithpassword](http://docs.meteor.com/#meteor_loginwithpassword)

<comment><USER10> Browsers don't support SRP, which means that if you want to use it, you'll need to deliver it via Javascript. SRP is particularly tricky to get right; a substantial fraction of the SRP implementations we've looked at have bugs that cough up authentication bypass. SRP verifiers are easier to crack than bcrypt hashes (though harder than trivial salted hashes). And finally, it's not much of a win; you get the same or better protections simply by running your login over HTTPS.

<comment><USER34> Would you mind expanding on that a bit? I mean, what kind of authenticsation bypasses you found? I am using SRP (for non-web stuff) and it would be good to know/to check whether I am affected by those problems.

</comment></comment></comment><comment><USER35> The part about having to use HMAC for keyed hashing is (hopefully) going to be obsolete soon. SHA-3 is explicitly designed to be safe under the H(key+message) usage.

</comment><comment><USER36> Just had a quick port of his example to Go.

[https://bitbucket.org/pkg/passwd/src/27f970fbcc05c0c6c258600...](https://bitbucket.org/pkg/passwd/src/27f970fbcc05c0c6c2586000dd083f606bd0a9e2?at=master)

Anyone fancy taking a look to see if I understood correctly?

EDIT: Specifically, should the PBKDF2 "key", not be used for something (like HMAC) rather than being used as the hash itself?

<comment><USER37> Alternatively, Go's bcrypt implementation has a very simple API:

        hash, err := bcrypt.GenerateFromPassword([]byte(password), 10)

        err := CompareHashAndPassword(hash, []byte(password))

There's also a Cost(hash) function that you can leverage to re-hash passwords with a higher cost.

</comment></comment><comment><USER38> There are many things wrong with this article. You can't hash secrets like this because hash functions are iterative. You should be using HMAC. Here's a good explanation [http://benlog.com/2008/06/19/dont-hash- secrets/](http://benlog.com/2008/06/19/dont-hash-secrets/)

<comment><USER27> The article you're referencing speaks about extension attacks. The attack allows you to extend a plaintext and calculate the appropriate hash if you know the original hash and the last parts of the original plaintext. These properties do not apply to password. You could extend the original password and calculate the appropriate hash in theory, but that doesn't help the attacker since the password hash is known and in the database.

As a matter of fact, the article you reference even says so: " "Don't Hash Secrets" is not always entirely necessary. In the password example, you can hash a password as long as you salt it correctly".

Using a HMAC may be useful since you can add an extra secret that's only known to a separate server or a HSM. The original article describes that in the section titled "Impossible-to-crack Hashes: Keyed Hashes and Password Hashing Hardware".

</comment></comment><comment><USER39> This is a great article though I knew most of what is said.

I'd like to find the same thing for encrypting all the data of users in a DB.

</comment><comment><USER40> If an attacker already has access to your user's table (as is implied by most of the situations in this article), then they probably have your whole database. What else is there to lose? Why would an attacker bother to use _any_ method to match passwords to hashes? Don't they already have everything they could want?

<comment><USER20> No, they do not. Maybe an important person's password hash gets leaked and they want to extract the password to check other sites for reuse to get into other systems. Now you say reuse is dumb, and I agree, yet a lot of people do it because they're lazy. This is just an additional stepping stone to make a malicious hacker's life harder.

</comment></comment><comment><USER41> For anybody who doesn't need this much detail, there's a great intro to this topic in the Web Dev course on Udacity: [https://www.udacity.com/course/viewer#!/c-cs253/l-48666069/m...](https://www.udacity.com/course/viewer#!/c-cs253/l-48666069/m-48673622)

</comment><comment><USER42> >Always display a generic message like "Invalid username or password." This prevents attackers from enumerating valid usernames without knowing their passwords.

If you have a password recovery page, couldn't attackers use that to test usernames?

<comment><USER43> Not really. If you mean actual password recovery, then I'd consider the site broken anyhow. If you mean password reset - any site worth its salt in security displays the same message regardless. Usually something like "If the account was found, an email will be sent shortly." I ran into one recently that simply said "An email has been sent" regardless of what was entered, which threw me off a bit as I was entering the wrong email address for that site and wondering why I wasn't getting their email....

<comment><USER44> How about a registration page instead? Are you going to not tell the user whether the registration worked or not? I've never seen a site that does that.

I've seen tons of sites that tell you "invalid username or password" but will happily tell you if the username is registered if you try to register it. It adds no security and just inconveniences users.

<comment><USER31> Respectfully, just because hackers can drive a truck through your app doesn't mean they should get to fly a plane, too. Its also easier for your users if you put a CAPTCHA in you registration form rather than your login form. This can mitigate large-scale fishing for usernames. Granted, that hacker who is going after a single poor soul who uses your service won't even feel the speedbump. But s/he is the toughest adversary, and the least common.

</comment></comment></comment></comment><comment><USER45> This isn't "Doing it right".

A. Your Salt should ALWAYS include a feature you have to store anyway about the user that would be unique to your service. Use multiple if you need to. This applies no matter what Hash mechanism you use. Also include a calculated value that isn't stored.

Example:

UserName + PassWord + User ID + CreationDate + <Numerals from a Base64 encode of the users first and last name>

Don't put all of this in the same database, so that a Data Breach won't give an attacker all the data they need.

No Rainbows for that combination. If a user changes their user name update their hash.

This is why in good services you have to provide your password when changing your username even when you are logged in.

B. To Validate the User Name:

Step 1 is always "Check that the password meets your password Criteria. If you have a requirement that passwords are 6-24 characters, contain 1 upper, one lower, and one digit, then make sure the password has those before you do anything else. No database lookups for bad passwords. No running bcrypt on a 4 megabyte section of post data. This is how you keep Denial of service attacks from crushing your service.

C. MD5 and Sha1 are only bad because there are rainbows for them, and because you can calculate every possible combination of values for a user/pass quickly if you know a single user/pass in the system you can calculate the salt methodology if you have access to the source code as well.

I won't tell you to use either of these, but if you lose your source code, and two databases worth of data so they have user, pass, and user data, you did something else horribly wrong, or it was an inside job and nothing would have saved you. (bcrypt is expensive if you have millions of users a day logging in and not any more secure if you did the other things above.)

<comment><USER46> IMHO this is all unsound advice.

No sane system follows the "store the data in multiple places" design; you'd need to pull it all back together to validate the password anyway, and a breach is extremely likely to compromise a system that can do exactly that.

Similarly, creating a salt from a calculation rather than, say, taking 128 random bits, is not going to help, nor is depending on the secrecy of the source code ever a prudent choice. It will certainly produce less entropy than the latter, will not produce a different salt across password changes, and is just very, very hacky.

<comment><USER45> A calculated value means you need source to figure it out. Only PHP and JS/Node scripters assume that their source isn't safe in an attack. The rest of us assume that our compiled code is safe.

(Over generalization, but if people can get your source code basically there is zero you can do to keep them out)

Storing data in more than one store is a best practice.

Your random 128 bits have to be stored somewhere. That means an attacker needs only the database, not the source. In any large scale environment you likely have multiple machines. When a machine gets taken out of service at your hosting provider your database might still be on it when it hits the dumpster. If your source code is on another machine it doesn't matter.

The same is true of the Private User Data and the passwords. two locations means you need two breaches to do anything.

<comment><USER47> The cracking community, unlike the bulk of the mainstream programming community, has not lost the art of disassembling executable code. Hiding source code provides negligible additional security.

<comment><USER45> "Source" or "Execution". Your Database isn't on the machine executing the code.

A breach of your Data should not be a breach of your code.

<comment><USER9> It still confers a negligible advantage. If the attackers have gotten into your data server, why shouldn't they be able to get into your application server just as easily? All you're doing is slightly inconveniencing the attacker before they can derive your salt wholesale.

Always remember: a secure system is secure _even if_ the attacker can see your source code. Any work you do based on assuming the opposite is a waste of time.

<comment><USER45> Really? How about because my database server could be something like DynamoDB that I don't own. Why would the execution and the Data server have the same vulnerabilities. The whole reason to have two servers is so that you can say. "The only thing that can talk to the database is a server on the 'Inside'", but injection attacks mean you could possibly exploit the data server with no access to the execution server.

<comment><USER9> Even so, you're proposing a very low entropy salt. If the attacker can crack one or two weak passwords, they can start limiting their search space immediately, and crack more passwords. As they gain more examples to work with, they will be able to work out how your salt is derived, and then they can start looking for salt collisions based only on the data that is stored in the clear.

At that point, your attacker has not only the ability to derive the salt and attack each password individually, but potentially the ability to generate rainbow tables for subsets of users with identical (or largely identical) derived salts.

The point is that at best, you're _adding_ a term to the overall hardness of the attack. When you use something like bcrypt, you are _multiplying_ the hardness of the attack. There is no comparison between what you've proposed with MD5 or SHA-1 and simply using bcrypt on a random salt, even if the latter has your source code in the latter but not the former.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER48> Pretty good article, I especially like the idea behind doing linear time comparison using XOR.

Although, the XOR comparison implementation seems flawed as it will only compare min(supplied password length, existing password length); which would allow the attacker to identify the existing password length by providing a sufficiently long password. Instead the existing password should be padded to the length of the supplied password in order to hide the length of the existing password.

My issue with the XOR comparison implementation is irrelevant as password hashing should use stretching (ex. PBKDF2, BCrypt, SCrypt) which means the hash of the supplied password and that of the existing password would be the same length.

The implementation of the PBKDF2 is also flawed.

Iterations: The recommended PBKDF2 iterations has long surpassed 10,000 (it's closer to 100,00 now). See here: [http://security.stackexchange.com/questions/3959/recommended...](http://security.stackexchange.com/questions/3959/recommended- of-iterations-when-using-pkbdf2-sha256)

The rule of them is that given a sufficient length salt, the number of iterations should take about 8ms on the hardware it is running on.

Salt Size: The recommended salt size is 128-bits/16 bytes (not 24). See here: [http://security.stackexchange.com/questions/17994/with- pbkdf...](http://security.stackexchange.com/questions/17994/with-pbkdf2-what- is-an-optimal-hash-size-in-bytes-what-about-the-size-of-the-s)

That stackexchange question also recommends using SHA512 as it requires 64-bit arithmetic operations which GPU's are supposidly not great at.

I believe I read stackoverflow and most big websites store about 24 bytes of the hash. The salt is generally prefixed to the hash and that is stored (ex. salt size 16 bytes + password hash 24 bytes = 40 bytes).

If I wanted to version a stored password, I'd simply use the first byte as an indexer to select a password hashing function instead of prefixing the hash with the number of iterations which seems non-portable.

Even if you do everything right concerning the hashing of passwords, account security extends beyond passwords - such as alternative methods of authenticating (forgot password, secret questions, authentication tokens). OWASP is a great authority in regards to this: [https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet](https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet)

<comment><USER10> Constant-time comparisons of password hashes are a regular feature of password hashing discussions, mostly because timing attacks are one of the few crypto attacks that developers can get their heads around immediately. But they're practically irrelevant to password hashing†. It does not matter if you use a constant time comparison for your password hashes; to see why, try to design the actual timing attack on the password hash compare (if you've never done this before, start by demonstrating to yourself that you can design a timing attack against an HMAC comparison).

The OWASP site's password storage guidance is particularly bad, and I recommend that developers avoid that page altogether. The page began as a litany of very bad advice (reversible encryption, salted hashes), and when it was pointed out that secure password hashes like scrypt were the right answer, the authors decided instead to "teach the controversy". OWASP is very political, and not managed by computer scientists.

† _The post we 're commenting on inaccurately says that the hypothetical timing attack it describes has been done before, but links to Boneh's TLS timing attack paper. My guess is that the password hash attack the author was considering has never been tried; among other things, it stipulates a password hash oracle for the attacker._

<comment><USER49> Simply: performing a timing attack against a hash function implies performing a second-preimage attack against the hash function.

</comment></comment></comment><comment><USER50> Password hashing with salt was one of the things I first implemented when switching to Node.js 3 years ago. It's an essential part of local password storage.

</comment><comment><USER51> Nice reading, bookmarked.

</comment><comment><USER52> Very helpful and well written article.

</comment><comment><USER53> No Perl example? Sob :(

<comment><USER54> Dry your tears! A Perl example can be found in the synopsis of this fine POD file:

[http://search.cpan.org/~gray/Crypt- Scrypt-0.05/lib/Crypt/Scr...](http://search.cpan.org/~gray/Crypt- Scrypt-0.05/lib/Crypt/Scrypt.pm)

</comment></comment><comment><USER55> site down. yet again a static html file is served from a private server.

<comment><USER56> Excuse my ignorance, can you please elaborate. What's the alternative?

<comment><USER57> He is probably suggesting that it should be served from large CDNs so it wont go down

<comment><USER58> hn could do that on behalf of the sites it links: [http://www.coralcdn.org](http://www.coralcdn.org)

</comment></comment></comment></comment><comment><USER59> nice article. password hashing - doing it right && cracking it right

[http://www.linuxx.eu/2014/01/how-to-hash-and-crack-unix- pass...](http://www.linuxx.eu/2014/01/how-to-hash-and-crack-unix-passwords- in.html)</comment>


Venezuela's Currency Has Had its Biggest Monthly Collapse - <AUTHOR> https://www.bloomberg.com/news/articles/2016-11-24/venezuela-s-currency-just-had-the-biggest-monthly-collapse-ever <comment><USER3> Often on HN's you'll get someone asking why a company has to continually grow revenues/profits. And the person is usually convinced once someone else comes along and lays out an argument that goes along the lines of....

If you consider a market with two companies.

Company A that doesn't grow revenues or profits and company B that continually grows revenues and profits, which one would you invest in?

The answer is obviously once you realize that each company doesn't exist in a vacuum but is instead competing with other companies for the same investment dollars.

Currencies markets work in a similar manner in that you are never talking about a currency but rather you are explicitly talking about what a currency is worth with respect to another currency, or often implicitly with respect to the US dollar.

It's actually pretty amazing to think about the currency markets and how they are constantly reweighing each currency with respect to every other currency such that each currency has the correct valuation with respect to all others such that there is no available arbitrage opportunity.

So its not that the markets or wall street is being "mean" to Venezuela or punishing it, but rather they are trying to find the right balance of how many Boliviars one should get for each USD.

Unfortunately, there is a giant feedback loop that often means once a countries currency gets depressed enough they almost have no choice but to print money just to buy/import the essentials required for life. And this printing of money just has an feedback that increases inflation even more until its impossible to get out from without a bankruptcy, just google "Zimbabwe trillion dollar bill".

<comment><USER4> You seem knowledgeable. Why can external currency changes (USD to bolivar) cause such strong inflation internally? I would think that at some point no one in the country can buy an iPhone, but how does that turn into no one being able to buy milk (or other essentials)? Do countries really rely so strongly on the international market for essentials?

 _edit:_ I could see a terrible scenario playing out where domestic goods are now so damned cheap for anyone not in the country that the producers are incentivised to ship their stuff overseas to rich foreigners. It could be the domenstic buyers that are the only people who get screwed. This is all terribly complicated.

<comment><USER5> "Why can external currency changes (USD to bolivar) cause such strong inflation internally?"

Simply because 'most things' that are sold in Venezuela are either imported - or depend on imports.

The Bolivar is crashing against all currencies, not just the USD - <USER2> anything: parts, fuel, TV's, entertainment - it all has to be imported, and it all got expensive.

'Internal inflation' can happen when there are more Bolivars floating around than before - even without outside currency markets to validate the price.

Ex: if there are 1 Trillion Bolivars in existence, and the government simply prints '1 Trillion' more and dumps them on the market. Guess what happens to prices? They will basically double every where.

So your shoes that cost 100 Bolivars, now cost 200.

<comment><USER4> I think the part I missed was why the solution to a crashing currency is to print more money. Let's say Venezuela cannot produce widgets, but they are necessary to modern living. Venezuela's currency drops in half, so now widgets are twice as expensive to a Venezuelan. Given a fixed exchange rate, as the government of Venezuela I could just double the amount of money all my people/companies have and everything would be fixed, but wouldn't that just lower the exchange rate again? Is there some lag in the market during which they can spend the new money at the old rate? At any rate, it's the Venezuelans and their corporations who need money. How does printing more money fix the issue of that poor citizen/company who is reliant on widgets?

It's becoming clearer, but I'm still confused.

<comment><USER6> The government has obligations in bolivars -- staff wages, pensions, payments to private businesses, and (in countries with trustworthy currencies) loan repayments etc.

They can print money to fulfil those obligations, effectively giving public sector staff a pay cut, pensioners a reduction in the value of their pension, etc.

<comment><USER5> "They can print money to fulfil those obligations, "

Not really.

By 'printing money' they are simply 'taking value away from those already holding Bolivars'.

Printing money is just devaluing the Bolivars already in circulation - so you can think of it as a 'tax on cash'.

You can print paper, but you can't 'print' economic value and production.

Printing money to pay gov. employees is basically a 100% sign to everyone in the world that 'this economy is destroyed' \- and that they should shut down all operations, cut their loses, get all their money out and exit in every way.

So it's a pretty bad signal.

<comment><USER7> You're exaggerating a little. Everybody prints money. It's what central banks do, it's what gold mines do. It's not a bad thing, it's how economies are managed. (completely free markets are a bad thing and anyone that tells you they aren't either doesn't have understanding of economics or is an extremist or both)

You can run a tightly managed economy successfully but it's hard. Very hard. Completely free markets are cruel but corrupt tightly managed economies are moreso. It also becomes difficult to determine the difference between a completely free economy and a corrupt managed economy because without regulation the former tends to concentrate power until it becomes effectively or actually the latter.

Sometimes the only thing for a collapsing economy to do _is_ print money. It's what a failing state will do to prevent itself from becoming a failed state. It's not sustainable but it's like falling off a mountain, you have to do _something_ and devaluing your currency to keep your economy somewhat functional can be the "right" thing to do for a while.

<comment><USER5> "Sometimes the only thing for a collapsing economy to do _is_ print money. It's what a failing state will do to prevent itself from becoming a failed state. "

No, this is upside down.

Printing money to pay debts, salaries - is what a 'failing state' will do to absolutely guarantee they will fail.

Central banks don't print money - they trade bonds or other assets in exchange for currency, and they do so at a rate to allow monetary expansion as the economy grows.

Cynically, you could say 'government issues debt, which is bought by central bank in exchange for $' which is very much like printing money, but it's not quite.

And 'gold' ... the amount of gold is so small it doesn't really affect anything.

A 'failing state' needs to restore confidence in it's institutions in order to get out of the hole, the last thing it can do is print money willy nilly.

The anti-populist measure would be to cap/cut government salaries, 'de facto' default on bonds - this is obviously a bad signal, but not as bad as printing money. A 'quiet default' i.e. signalling that 'there is no way we can repay so you'd better negotiate with us' is the pragmatic thing to do.

<comment><USER8> ah, interesting. My understanding of central bank practices was that 'government issues debt, which is bought by central bank in exchange for $' == printing money - but they are not synonymous?

So if you no longer have the paper trail of things being bought and sold, who keeps track/makes public the amount of currency in circulation in this case?

If simply printing more money is a bad signal, why not just keep it secret?

<comment><USER7> [https://en.wikipedia.org/wiki/Fractional- reserve_banking](https://en.wikipedia.org/wiki/Fractional-reserve_banking)

There's a paper trail. It's just that when the Fed buys something the money is pulled from thin air. When the debt is paid back the principal returns to thin air, the profit goes to the US Treasury.

Not all government debt is purchased by the treasury though – it only does that in special circumstances to moderate the financial system. Most of is is purchased domestically and much of that by other pieces of government.

And you can't keep it secret. It's like supply and demand. More money means prices naturally raise because more people have more money to spend and will be willing to pay a higher price.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Here's the worst part: "Venezuela has maintained strict currency controls since 2003 and currently has two legal exchange rates -- known as the Dipro and Dicom rates -- of 10 and 661 bolivars per dollar used for priority imports. On the black market, where people and businesses turn when they can't obtain government approval to purchase dollars at the legal rates, the bolivar has weakened 69 percent over the past year."

Whoever is buying dollars (or dollar-denominated goods) at the "official" exchange rate is making a killing. And will do so for about 6-9 months, before the entire thing collapses.

<comment><USER10> >Whoever is buying dollars (or dollar-denominated goods) at the "official" exchange rate is making a killing. And will do so for about 6-9 months, before the entire thing collapses.

It's been like that ever since the currency controls were implemented in 2003, it is fairly well known that most if not all of the high ranked government officials (who have unlimited access to preferencial exchange rates) are behind the currency "black" market. The same government officials have their fair share of cash stashed away in tax havens.

This is beyond hope, corruption is not only endemic anymore but a neccessity for survival, unfortunately this will only end with blood, I believe international interference is a must in this case.

<comment><USER11> Err no, we can actually solve this issue ourselves. It was about to happen about 3 weeks ago actually. We just need the massive street demonstrations again and it will end.

I think international interference in this kind of issues end up causing more trouble than solutions. It ends up becoming a contest of whose side is supporting who. Just look at Syria.

</comment></comment></comment><comment><USER12> Last I heard, the people are waiting all day in line to get basic things like food and medication. Can someone explain how this country hasn't collapsed yet? Crime must be through the roof.

<comment><USER13> Crime is indeed very high - murder rate per capita is 15 times higher than in the U.S. or 70 times that of United Kingdom.

It is so high that the government has stopped publishing statistics, and also so high that "authorities would assign judicial police to Caracas area morgues to speak with families. At that time, they would advise families not to speak to report the murder of their family member to the media in exchange to have the process of recovering the victims body in an expedited manner. It was also reported that police would intercept the families of the victims and take them to the library of the University Institute of the Scientific Police (IUPOLC) where authorities offered families ways to "streamline procedures and advise them not to give information to the press in return for their aid"*

[https://en.wikipedia.org/wiki/Crime_in_Venezuela](https://en.wikipedia.org/wiki/Crime_in_Venezuela)

The government also banned private handgun ownership in 2012. The number of murders has grown by about a third since that.

<comment><USER14> What? UK to US is 70:15?! How savage.

<comment><USER15> UK to US is 15:70, no?

<comment><USER13> Yes, approximately. Homicide per year per 100 000 people:

U.K. 0.9 U.S. 3.9 Venezuela 62.0

[https://en.wikipedia.org/wiki/List_of_countries_by_intention...](https://en.wikipedia.org/wiki/List_of_countries_by_intentional_homicide_rate)

<comment><USER16> To add a bit more perspective, the US is also an outlier amongst developed nations, who are almost all under 2.0. That 3.9 is not 'normal' (though it is something of an improvement on previous rates).

<comment><USER17> It's a lot more nuanced than that as well with the US. A very small portion of the US population lives in a location with a murder rate at 3.9 or higher, because murder in the US is hyper concentrated (a few areas of Chicago have more murder annually than all of Japan). People like to pretend the US is a wasteland of murder, when in fact the very extreme majority of people in the US live in areas with murder rates comparable to Canada.

<comment><USER18> Is murder in other countries not concentrated? I can draw circles over a few areas in Japan and say "these areas here have 100% of murders, the rest of the country has a murder rate of zero".

<comment><USER17> If you step outside of the major US cities, the murder rate per capita plunges. That variance in the US is far beyond what you see in other developed nations (eg Britain, Sweden, Finland, France, Belgium, Germany, Japan, etc). It's so bad that if you just brought the three dozen worst urban sub-areas down to normal as compared to the rest of the city in question, you'd reduce the total US murder rate more than a full point.

<comment><USER19> >if you just brought the three dozen worst urban sub-areas down to normal as compared to the rest of the city in question, you'd reduce the total US murder rate more than a full point

>three-dozen

That seems like a lot of areas to say "just". If it's that easy to bring it down, do it in actuality rather than coming up with hypothetical scenarios where the US doesn't have such a high murder rate.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Here's a recent, long New Yorker article on Venezuela, Maduro, Chavez, Polar industries, crime, China, oil, inflation, Cuba, America, Colombia, taxi drivers, Halliburton, and a bunch of other things I don't remember.

[https://www.newyorker.com/magazine/2016/11/14/venezuela-a- fa...](https://www.newyorker.com/magazine/2016/11/14/venezuela-a-failing- state/)

<comment><USER21> That was an interesting read; thanks for sharing. I'm always fascinated reading the latest exposes on the Venezuela saga.

</comment></comment><comment><USER22> Venezuela's problems stem from several issues, and there's sufficient political invective about them that a clear discussion is difficult.

An earlier HN post addressed the question of Venezuela's refusal to simply default on its loans, as another South American state, Argentina, did: [https://news.ycombinator.com/item?id=12057616](https://news.ycombinator.com/item?id=12057616)

In another earlier thread, I suggest strongly that the problems Venezuela is facing are far more characteristic of a failing end-stage oil state than of the inevitable failure of Communism, for which China and Vietnam offer possibly interesting counterexamples.

[https://news.ycombinator.com/item?id=12541955#12545819](https://news.ycombinator.com/item?id=12541955#12545819)

<comment><USER23> Im not sure what it means that Venezuela is failing because of 'end stage oil' rather then socialism. Does Venezuela not have tons of oil reserves? If they fail to develop these and all the other resources then that clearly because of bad policy stemming from at least a nominal socialist agenda.

<comment><USER22> That's partially addressed in the comment I'd linked to above from an earlier post.

Not all oil is equal. The single-strike wells of the Persian Gulf which poured fourth 70,000 barrels of oil _per day_ of light sweet crude, _and are still producing nearly a century later_ (see the First Oil Well of Bahrain for example) are quite different from the lower-grade, hard-to-pump crude Venezuela has, or the production profile of a hydrofracked well.

Put simply, you want to consider the _net costs of production_ , including the _energy costs of production_ (EROEI -- energy returned on energy input) which are considerable for Venzuela. Also, incidentally, for the "largest ever" onshore US discovery of Texas shale oil announced a week or so back.

For Texas, the average per-well extraction is 20 barrels/day. These low- production wells are known as "stripper wells", and operators will literally turn on and off the pumps in response to the price of oil if it exceeds their ongoing production costs -- fuel or electricity for the pump jack, plus depreciation.

[http://oilpro.com/q/1775/many-barrels-oil-does-well- produce-...](http://oilpro.com/q/1775/many-barrels-oil-does-well-produce- daily-texas)

I don't have a per-well production statistic for Venezuela, though national production has held steady at about 2.5 mbpd since 2004.

[http://www.indexmundi.com/energy/?country=ve&product=oil&gra...](http://www.indexmundi.com/energy/?country=ve&product=oil&graph=production)

There are a few end-run oil exporter scenarios. One, the "export land model" by Jeffrey Brown looks at the total _domestic_ consumption of exporting countries, and sees a tipping point where domestic demand accounts for all production.

There's another scenario, in which the total financial accounts of an exporter are taken into account. Here, the problem is that when the global oil price falls below the costs of production in a country, it literally cannot afford to pump oil from the ground, and finds itself deprived of foreign cash flows. The classic case of this is the Soviet Union in the 1980s. Having based its national budget on the high price of oil in the 1970s, it was caught in the double bind of large flows of new fields (North Sea and Alaskan North Slope), as well as a plummeting global oil price with the 1980s supply glut. As much as anything, Saudi Arabia defeated the Soviet Union.

That story's been played out in several Arabian states, including Egypt and Syria (both minor oil producers), Yemen, Lybia, Tunisia, and, yes, Venezuela. Texas, North Dakota, and Alberta, Canada are all running into the problem of development predicated on $100/bbl oil in a world of $45/bbl WTI.

I don't care _what_ your governmental or economic system is. If you're basing your economy on massive sales of extractive resources and the price falls out from under you, you're sunk.

Saudi Arabia has been making very interesting noises about its finances for the past few years. Keep in mind that KSA are essentially a family-run state / business. The House of Saud runs the country and owns the country's largest company, Saudi Aramco, accounting for over half the country's GDP. I'm not sure exactly what you'd call a state in which a single unitary power bloc controls the major economic unit, but it doesn't strike me as terribly democratic-market-capitalist.

I've also poked around the Heritage Foundation's Index of Economic Freedom and measures of per-capita wealth, to find some interesting bits. Dig around [https://dredmorbius.reddit.com](https://dredmorbius.reddit.com) for more on that.

Again: the heated rhetoric tends to cloud more than clarify understanding of what's going on here. I say that without either defending _or_ denegrating Venezuela. I'm simply interested in understanding it.

[http://www.ibtimes.com/saudi-arabias-2016-budget-creates- new...](http://www.ibtimes.com/saudi-arabias-2016-budget-creates-new-normal- only-part-solution-economic-crisis-2246638)

<comment><USER23> I am pretty sure well run oil company could still operate profitable in Venezuela. It is no Saudi Arabia that is for sure, but I still think you can not blame all the problems on just oil export prices.

I would agree that Saudi Arabia is not democratic or all that capitalist. Socialist don't have a monopoly on bad government.

How well a country is set up you can see what happens when their main export tanks, Venezuela was clearly terrible and instead of reacting and adjusting, they started looting the big companies, enforce exchange controls, escalated inflation and did many other idiot things that hurt the country badly.

We don't know yet how the Saudis will deal with this if it ever comes to that.

</comment></comment></comment></comment><comment><USER24> Can't believe there are populist parties in Spain defending this model and trying to import it.

<comment><USER25> Sanders praised it. As a Venezuelan in SF, I've had my fair share of arguments where I've had to defend the perspective that Venezuela isn't a socialist paradise.

"These days, the American dream is more apt to be realized in South America, in places such as Ecuador, Venezuela and Argentina, where incomes are actually more equal today than they are in the land of Horatio Alger. Who's the banana republic now?" \- [http://www.sanders.senate.gov/newsroom/must-read/close- the-g...](http://www.sanders.senate.gov/newsroom/must-read/close-the-gaps- disparities-that-threaten-america)

<comment><USER26> GOP would have had a field day with Bernie had he been nominated instead of Clinton.

<comment><USER27> Just like the Democrats had a field day with Trump: Great entertainment, but the outcome wasn't all that fun. Bush would have been less fun, but he would have lost.

</comment></comment></comment></comment><comment><USER28> This is madness. I can't believe people can live in such a nightmare. Isn't there any opposition or can't just people there revolt? Or maybe army makes a coup?

<comment><USER29> Might be easier for people to rise up against the government if guns weren't banned in Venezuela!

<comment><USER30> Guns are only banned for normal citizens. The para-military forces that support the government are very well armed.

This is one of the reasons you don't see people in the poorer areas protesting. They are scared of these groups.

<comment><USER11> You mean the armed thugs. Calling them paramilitary forces gives them too much dignity. They are thugs on bikes that will probably end up dead by the time they reach their 30s.

</comment></comment></comment></comment><comment><USER31> It is sad that some year ago 1 usd would be like 2000 bolivares (I don't know the exact amount, but bolivares were almost the same value as colombian pesos). They decided to create the "bolivar fuerte" which was 1000 bolivares, so 1 usd would be 2 bolivar fuerte. With the bolivar fuerte price drop, the usd is now above 2000 bolivar fuerte, so in a matter of years, Venezuelan money is worth less than a thousandth it was worth less than 10 years ago.

</comment><comment><USER32> The weird thing is that Maduro has so far refused to default out of some sense of pride. The bond market has already priced in the inevitable default.

<comment><USER33> There was speculation that a substantial amount of the national debt is actually held by regime insiders, who benefit enormously from the high interest rates. A default would stop that racket.

I can't remember where I read that, so take it for idle speculation.

</comment></comment><comment><USER34> Sounds like problems in USSR</comment>


3D Orienteering Map - <AUTHOR> https://routegadget.net/3d/pukkamaki/ <comment><AUTHOR> Hold LMB - _to rotate_ ;

Hold RMB - _to move /drag_;

Scroll mouse wheel (or hold both mouse buttons and move mouse back and forth) - _to zoom in /out_.

P.S.: There are few more examples.[0]

[0] [https://routegadget.net/3d/](https://routegadget.net/3d/)</comment>


MIPS R3000 - <AUTHOR> https://en.wikipedia.org/wiki/R3000 <comment><USER2> MIPS is a fun architecture (other than the delay slots that plagued early RISC ISAs) and implementing a subset of it on an FPGA is still a pretty common undergraduate university course project. I was kind of amazed just how simple it is to get a basic CPU working, though even the 1988 version was quite a lot more sophisticated than the class project version (multiple cache levels, having an MMU, probably much better branch predictor, etc).

<comment><USER3> Why does everyone seem to hate delay slots? I understand that it makes writing assembly more annoying but most people use a compiler anyway.

<comment><USER4> It makes the hardware implementation more complicated. The delay slot was perfect for the 5-pipeline original design. Once you try to push this to out of order execution (executing more than one instruction per cycle), the delay slot just doesn't make any sense.

<comment><USER5> That's my understanding as well. Software-wise, I, for one, have not had issues with reading or writing code with branch delay slots -- automatic nops, at worst. I guess it all depends how early in one's development they were introduce to the concept of delay slots.

</comment></comment></comment></comment><comment><USER6> I'm honestly confused - why is a wikipedia page about an old computer architecture on the front page of HN?

<comment><USER7> Because it's interesting! I think it is, at least.

From the guidelines:

> What to Submit

> On-Topic: Anything that good hackers would find interesting. That includes > more than hacking and startups. If you had to reduce it to a sentence, the > answer might be: anything that gratifies one's intellectual curiosity.

</comment></comment><comment><USER8> It's still my favorite RISC processor and the only one that I actually liked coding in assembler (SPARC wasn't fun at all).

<comment><USER9> How annoying were the branch delay slots?

<comment><USER10> You could always put NOPs into delay slots by default and replace them later with something more useful.

<comment><USER11> no, you could not "always" find something useful to put there later. gross exaggeration

<comment><USER12> You misunderstood parent. They meant you can always nop the branch delay, and you might find something more useful for it later

<comment><USER11> that may have been what they wanted to write. unfortunately they wrote something wrong and misleading instead. i understood what they wrote perfectly well and the implication therein isn't, somehow, my fault

<comment><USER12> The "always" qualifier does not apply to anything after the "and". Why do you assume it does? You are being very combative and pedantic so I assume you have a diehard rule for this that you can reference? Like some english grammar handbook?

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Alternative history time: what if MIPS R4000 hasn't been killed by Pentium? Would we be running R10000-compatibles now?

<comment><USER14> Even more fun alternative history: What if Motorola didn't end 68000 with the 68060?

68060 released earlier than the pentium, and regardless it had about twice the performance per clock. But then Motorola decided to abandon 68k to focus on PowerPC.

Going further back: What if IBM picked 68000 over the 8086 for the PC?

I'm hoping RISC-V will put an end to x86. It's about time.

<comment><USER15> I thought motorola did their own RISC chips, the 88000.

<comment><USER16> They did two that I know of, the 88000 and M.Core. The 88000 had some issues (I do believe floating point) and was really expensive.

</comment></comment></comment></comment><comment><USER17> I remember reading a computer architecture book that used a fictional MIPS instruction set and used washing and drying clothes as an example of how to pipeline / do parallel instructions. Does anyone remember the name of that book?

<comment><USER2> That description probably applies to several computer architecture books, but the one I read was like that and called "Computer Organization and Design: The Hardware/Software Interface".

<comment><USER17> This is the book. Thanks for your help

</comment></comment></comment><comment><USER18> I loved this CPU, programming it using spim, then actually getting to write some PSX code.</comment>


Ask HN: starter books for learning about grammars, parsers and compilers? - <AUTHOR>

I'd like to get a solid footing in the concepts and formalisms that underlie libraries such as instaparse[1], PEG.js[2] and the SSA approach taken in Clojure's core.async library[3].
Working with those libraries, reading source code, and referencing Wikipedia is a great way to learn, but I'd like to take in some worthwhile books, lecture series, etc. as well. While I'm not opposed to "pure theory" treatments, my preference would be for resources that provide a good mix of theory and concrete examples.
What recommendations do other HN readers have in this regard?
[1] https://github.com/Engelberg/instaparse
[2] https://github.com/dmajda/pegjs
[3] https://github.com/clojure/core.async/blob/master/src/main/clojure/clojure/core/async/impl/ioc_macros.clj <comment><USER2> Basics of Compiler Design is quite theoretical, but it's available online for free: [http://www.diku.dk/~torbenm/Basics/](http://www.diku.dk/~torbenm/Basics/)

<comment><AUTHOR> Thanks! Someone in #clojure on freenode recommended the same, possibly even yourself.</comment></comment>