Erlang and OTP in Action - <AUTHOR> http://manning.com/logan/ <comment><USER2> This is on my Christmas list to my fam. I've been looking forward to reading it ever since ErlangCamp, which was organized by some of the authors, and fully awesome. If the book's as helpful as ErlangCamp was, then I expect this book to deepen my understanding of OTP, which in the O'Reilly and PragProg books seem to be more of a "if you _want_ , you can do OTP". I prefer the "this is the way it _should_ be done" approach. OTP should be the norm, rather than the exception, and a lot of new Erlang developers miss that (including myself).

<comment><USER3> You are right on target. OTP should be the norm and should be learned as a first step. Later on for curiosities sake one can learn to program without it! OTP codifies many of the best practices that experts in this type of process based concurrency model use every day.

It is nice to be finished with the book and we are really proud of it. These days we are back to Erlware, resurrecting the project from a two year hibernation, and also planning for the next ErlangCamp.

<comment><USER4> Martin, one of the problems with Joe Armstrong's book and OTP is that Joe doesn't use OTP - he always rolls his own servers - bless him. I remember everyone giving him dogs abuse for it over dinner at the Erlang Users Conference 3 or 4 years ago.

I do think we need to be all GNU/Linuxy about it and just always refer to it as Erlang/OTP.

</comment></comment></comment><comment><USER5> An aside: How bad is Erlang's string handling in practice? I primarily write server software, and Erlang would be a pretty good fit for much of what I do... but I also have to munge a lot of text pretty regularly, and I've been a little scared off by the FUD surrounding Erlang & strings.

<comment><USER2> Working with strings in Erlang hasn't been much of a problem for me. The re module's ( [http://erldocs.com/R14B/stdlib/re.html?i=0&search=re](http://erldocs.com/R14B/stdlib/re.html?i=0&search=re): ) regular expression handling is pretty decent, and it takes binaries, iolists, and of course normal strings (just lists of ints).

Erlang strings are just lists of ints, but it's important to know the speed consequences with dealing with the ++ operator, or lists:flatten (which is supposed to be pretty slow, or so I've heard - never personally benchmarked). Binaries, on the other hand, are more like typical strings in other languages, and don't have the same performance penalty.

I'd say: play with it, do some benchmarks, and see how it fits for you. It's pretty easy to tinker with things on the Erlang Shell (like any REPL) so go for it. If it doesn't work well enough for you, ask the Erlang Mailing list, which is pretty good at ferreting out speed improvements (recent relevant optimization thread: [http://www.trapexit.org/forum/viewtopic.php?t=19541&post...](http://www.trapexit.org/forum/viewtopic.php?t=19541&postdays=0&postorder=asc&start=0&sid=1f3dad84c9fa26085ca2b631425fae34) ).

And if all that fails for you, then you at least know you gave it a shot and can rule it out.

Personally, I think the language is freakin' awesome.

<comment><USER2> I just did a followup test to see just how the re:replace function did with converting a 16kb text string with a BBCode parser I've written in Erlang, and on my crappy laptop it did 1000 conversions in 12 seconds. Further, I'm not running the high-performance version of Erlang, nor did I do any attempts at parallelization optimization.

Surprising to me was that the performance difference between binaries and strings wasn't too much different.

Module: [https://github.com/choptastic/Yabbie/blob/linux/site/src/lib...](https://github.com/choptastic/Yabbie/blob/linux/site/src/lib/bbcode.erl)

(keep in mind, this is built with the Nitrogen Web Framework in mind, so if you want to run it stand-alone, you can comment out the include lines and it should work just fine).

      (firstname.lastname@example.com)9> bbcode:benchmark("l4d.txt",1000).
      [{binary_time,12841.423},{string_time,12888.905}]

So 12000 milliseconds for 1000 iterations each. A few millisecond difference (46 millisecond difference) isn't much of a difference.

<comment><USER6> That measurement would probably be more useful if stacked against same in Java / Python / Ruby / etc.

Writing the parser itself in Erlang seems expensive; passing text through discount (<http://www.pell.portland.or.us/~orc/Code/discount/>) in an otherwise Erlang system seems like a good neutral measure.

(and then 100k threads doing same concurrently)

<comment><USER2> Absolutely. Perhaps I'll do a more elaborate comparison between a few other languages just to see.

</comment></comment></comment></comment></comment><comment><USER7> I already own the book, but I wanted to let others know that it is the Manning 'Deal of the Day' today (12/05/10.) You can get it for $25 if you enter promotional code dotd1205ccb when you checkout.

<comment><USER8> Also, the somewhat-related RabbitMQ in Action is half off today, with code n3050. (After reading the first chapter, it puts zeromq in perspective, if you search HN discussions about it.)

</comment></comment><comment><USER9> On the topic of Erlang books... does anyone know what the story is with Geoff Cant's "Mastering Erlang: Writing Real World Applications"?

It was due out around October from memory, but seems to have slipped into limbo.

[http://www.amazon.com/Mastering-Erlang-Writing-World- Applica...](http://www.amazon.com/Mastering-Erlang-Writing-World- Applications/dp/1430227699/)

</comment><comment><USER10> I'd go so far as to say that this is one of the best technical books I've read. I'd been interested in Erlang for a while, but found building anything in OTP somewhat baffling. I read this and it clicked. I just wish the rest of Erlang's documentation was even half as good as this.

</comment><comment><USER11> If you're doing marketing supposably for friends, you could at least link to a blog post about the book.

</comment><comment><USER12> I like Joe's, and the o'reilly book better. The examples aren't that great on this one and unlike the book claims the other books do cover some OTP. Read this one only after you've read the first two books, but even then I don't know if it was worth it.

<comment><USER6> I have all three, and think they're complementary. I like Joe Armstrong's book, but don't think it's very good as a reference - it jumps around too much. The O'Reilly book is better organized, but with both, OTP comes in kind of as an afterthought. I'm glad to have another that focuses primarily on it, because there are too many details about paths, deployment, etc. to just have one chapter about it 2/3 of the way through. I didn't realize how many common issues OTP completely handles until the presentations at ErlangCamp.

<comment><USER13> My thoughts agree. I made it about halfway through the other two books before things kind of fell apart and I didn't really know how to _apply_ Erlang IRL.

Just bought this and hoping it completes the picture.

</comment></comment></comment><comment><USER14> I don't think I'm doing anything illegal here, by posting the coupon that Manning sent out for free yesterday to the subscribers to the "Deal of the day" list. This coupon will permit to buy this book (paper and pdf) for 25$: dotd1205ccb

I _highly_ suggest this book, it's definitely one of the best about Erlang. I also suggest subscribing to the ML, some books from Manning are great (thinking about the joy of Clojure for example).

</comment><comment><USER15> The only book that covers OTP in depth. Cesarini and Armstrong one are equally essential for learning Erlang programming.

</comment><comment><USER16> I hope you like the book and checkout what else we are working on : erlware.org and erlangcamp.com

</comment><comment><USER17> I have been working through the book, and I'm just getting into the meat of it. I'm tempted to skip ahead to the JInterface chapter though to noodle around with some erlang powered graphics.

</comment><comment><USER18> quite excited about reading this, I have been hearing some excellent feedback about this book already.

</comment><comment><USER19> Great book on Erlang/OTP teaching from an OTP perspective. Must read if you're into Erlang at all.

</comment><comment><USER20> Great book to learn OTP!

</comment><comment><USER21> OTP has to be one of the poorest chosen acronyms in the computing industry. It has been used as 'One Time Pad' for decades.</comment>


Cartographer – A real-time simultaneous localization and mapping library - <AUTHOR> https://opensource.googleblog.com/2016/10/introducing-cartographer.html <comment><USER2> Just to exercise some nitpicking as a graduated cartographer:

While _mapping_ is as ambiguous as it gets, _Cartographer_ seems to be quite the misnomer, since cartography is not about data collection, it's about representation (-graph-) of the data.

 _Geodesist_ would be a more analogously fitting, yet arguably ponderous term in my opinion.

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

<comment><USER3> It takes the sensor data as an input and outputs a representation. It "makes a map", so the name is a decent pun.

<comment><USER4> This is an annoying habit of my fellow programmers.

Thinking that a decent or not-so-decent pun would make a good project name.

</comment></comment></comment><comment><USER5> Very cool -- would've loved to also see monocular SLAM support, but sounds like that may be coming later.

For people interested, there are a couple of very interesting projects and studies on how to do just that:

* Direct Sparse Odometry: [http://vision.in.tum.de/research/vslam/dso](http://vision.in.tum.de/research/vslam/dso)

* LSD-SLAM: [https://github.com/tum-vision/lsd_slam](https://github.com/tum-vision/lsd_slam)

LSD-SLAM and Cartographer both support ROS so perhaps integrating the two would be fairly straightforward (using LSD-SLAM's monocular features with Cartographer for SLAM).

<comment><USER6> PL-SVO is also a very new and interesting approach to watch out for. They open sourced the stereo slam version and claim the monocular one is on the way.

[http://mapir.isa.uma.es/mapirwebsite/index.php/people/164-ru...](http://mapir.isa.uma.es/mapirwebsite/index.php/people/164-ruben- gomez)

</comment></comment><comment><USER7> Cool! As I suspected, it's based on the Ceres nonlinear optimization library that they released a few years ago, originally built for Street View: [http://ceres-solver.org](http://ceres-solver.org)

</comment><comment><USER8> Ive not yet had a chance to run this. Does this include Semi-dense mapping, or is it hobbled with sparse only?

ORB-SLAM was claimed to have included in their github repo the semi-dense, and then faked everyone out with "too bad, not in there". In other words, worthless.

<comment><USER9> The map is fully dense. No feature extraction is done on the LIDAR data.

</comment></comment><comment><USER10> Does anyone know what is the cheapest, fairly reliable Lidar that could work with this library? I'm not looking for amazing accuracy, but for something to start a hobby project with.

<comment><USER11> I think the Microsoft Kinect is still the most accessible and cheap option for experimentation.

<comment><USER10> I am looking for something smaller than kinect, that's easier to mount on a moving platform and requires less power.

<comment><USER12> I've got the Structure sensor [http://structure.io/](http://structure.io/) . They have an OpenNI2 library so you can use it on a Linux based system

<comment><USER10> Looks nice. I wish it supported more than iPad.

<comment><USER12> Well you can use it on Android as well, but it is a bit tricky to do on non rooted devices. I did a proof of concept a while ago ( [http://www.ferienvillaflorida.de/labs//3d/android/stereovisi...](http://www.ferienvillaflorida.de/labs//3d/android/stereovision/2015/01/30/announcing- structdroid.html) ) but never found the time/motivation to develop it further.

But I guess most people who think about using it for a small robot will probably connect it to a Raspberry Pi anyway

</comment></comment></comment></comment></comment></comment><comment><USER13> In the second video, why does the map go blank (other than the path traveled) at about 0:43, and then it seems to start from scratch again?

I'm also not familiar with the "cloudiness" of poorly mapped areas.

I'm familiar with what the ROS Navigation stack/rviz looks like when it does mapping, though as a user rather than an implementer. Maybe I'll find the cycles to actually play with implementing this library someday soon.

<comment><USER14> Floor changes, I believe.

<comment><USER9> That's correct. The operator carried the backup up/down a stairwell.

</comment></comment></comment><comment><USER15> Excited to try it out and see how it goes.

Out of curiosity, does anyone know of some good mailing lists for this (SLAM/similar)? I don't always have time to scan HN for new releases, but I'd still like to stay on top of things.

<comment><USER9> You could try following the ROS News blog. Lots of new research comes with a ROS implementation.

</comment></comment><comment><USER16> very very cool. My thoughts, after briefly browsing the paper and code:

\- The killer feature is to avoid a particle filter to improve performance on larger maps. May not have much improvement over gmapping if you're not bounded by CPU/map size

\- the launch file only uses lidar and raw imu data, but not wheel odometry. Makes sense for a backpack I guess, I wonder if it would be trivial to make it take a odom sensor msg.

\- the paper mentions the neato lidar, and they're using it at 15m range (?). Must be very tolerant of sensor noise.

will have to try it on my robot when I get home.

<comment><USER9> There is support for odometry. Take a look at the TurtleBot examples.

<comment><USER16> ah, it's in the dynamically loaded config file. That should be perfect then.

</comment></comment></comment><comment><USER17> I am unfamiliar with this type of technology. After r3ading a few of the comments, would it be accurate to say that the mapping drones from Prometheus utilize a variation of this software?

<comment><USER18> Yes, Prometheus drones use a visible laser (albeit too slow to rotate to give coherent data) like a LIDAR, this is one of the possible sensor for SLAM.

</comment></comment><comment><USER10> What's the quickest way to do something useful with this library? The docs are minimal, I have no idea how to start, hos to get to something similar to this video?

<comment><USER9> I suggest installing ROS. Once you have it installed, you can follow the documentation in the cartographer_ros repo to get some demos running.

</comment></comment><comment><USER19> Is it me, or is this technology really scary? I mean it is cool and everything, but what good can come out of it? On the other hand, bad scenarios easily come to mind, like: "Lets drone him, he can't hide because we have it all mapped, inside out". Am I paranoid?

<comment><USER20> > what good can come out of it?

Yes, you're paranoid. A drone doesn't need to map out a museum before lobbing a missile at it. An autonomous vacuum cleaner, on the other hand, would probably love to know for sure that it has covered the entire surface.

Personally, I'm imagining a little ball that I rent from the hardware store that rolls around my house for an hour and spits out the blueprints of my house so that I can feed it into a VR program for choosing furniture.

<comment><USER21> That's what our company does already...kind of. Except we do it with an iPhone only and don't give you a scan yet - though we have proven we can build scans from videos. I won't spam the comment but we exist.

<comment><USER22> Can you link to your company's website? This sounds interesting.

<comment><USER21> www.pair3d.com</comment></comment></comment></comment></comment>


Ask HN: How do you cope with political stress (and get work done)? - <AUTHOR> In many countries, it seems like we're living through a time of political turmoil. Here in the US, of course, there's the election and associated shenanigans. I'm personally not in a situation I can get more involved, given Covid, kids, and a parent with a terminal condition. Still I feel guilty I am not doing more.<p>Do you have a way for tuning out / coping with the ongoing political turmoil to get work done? <comment><USER2> A few things that I have found to help myself:

\- I have stopped visiting r/all and r/popular on reddit, and instead I have curated a more niche collection of subreddits unrelated to news or politics.

\- I set time limits for how much news/day and news/week I consume. These are hard limits. No "one more story", or the FOMO starts to creep in. I try to limit to no more than 3 days/week, no more than 1 hr/day.

\- I have tried to curate my news sources using mediabiasfactcheck.com, choosing those with high factual reporting and low loaded-word usage.

\- Friends and family have all agreed that we avoid political conversations as much as is reasonable.

\- I long ago ditched /all/ social media (I guess if you consider HN, or my reddit account with 0 comments, a social media -- I have those still). But no FB, no LinkedIn, no Twitter. Those three in particular wreaked havoc on my psyche and I feel like I've truly improved my life by removing them.

Guilt is a hard emotion to deal with, and even harder to give advice about because of how differently it manifests in each person. I hope you find some things that help you cope.

<comment><AUTHOR> Hacker news is a pretty fantastic signal to noise social media source. Reddit can be pretty good though not great depending on the sub. But twitter and Facebook are just terrible for histrionic takes on everything...

</comment></comment><comment> pickle-wizard I've been donating to political causes that I support.

</comment><comment><USER3> Not watching / reading news and not getting involved in political discussions online helped me a great deal!

</comment><comment><USER4> It's not a concern for me.</comment>


Gandi is celebrating its 15th anniversary – 100k prizes (domain name, hosting…) - <AUTHOR> https://15.gandi.net/

<comment><AUTHOR> Game rules

The game is open to everyone, but our oldest customers will have an advantage. We've set it up so that the number and value of the prizes you can win is based on the age of your Gandi account. For example, if you have been a Gandi customer for 10 years, you can win up to 10 prizes, with a limit of 3 per day. If you're not yet a Gandi customer, don't panic: you can sign up for free today and still win discounts on domain names and hosting.

How to play: From March 30 to April 3, 2015, we will distribute 1,500 gifts on our website at the top of every hour, between 4 a.m. and 6 p.m. PDT. To participate, just log in at the beginning of a round and click the big "play" button. If you're lucky, you'll be presented 3 prizes to choose from. You'll only have 20 seconds to choose, so act fast!

The prizes will be awarded in the form of promo codes, valid until May 1, 2015, which you can use yourself or share with friends.

___

Between 50,000 free domain names, 10,000 Simple Hosting instances, 1 billion IaaS hosting credits, and our fabulous t-shirts, there will truly be a landslide of prizes given away every hour during our anniversary week.</comment>


Why are we being encouraged to teach programming to a 3 year old? - <AUTHOR>

Why are we increasingly trying to teach 3 - 5 year old toddlers programming? <comment><USER2> Is there anything wrong with exposing them to how things are created? Admittedly programming involves a massive level of abstraction but it needn't be C or Javascript. Even if they don't do it, its good to let them know its possible.</comment>


GraphQL Patent Infringement Issues - <AUTHOR> https://github.com/facebook/graphql/issues/351#issuecomment-330574513 <comment><USER2> You should rename the thread "Gitlab put on hold their GraphQL implementation due to Facebook patent" for better visibility.

Gitlab Senior Director of Legal Affairs said:

      "If we were to allow this license, it could lead to potential future conflicts with software licensed under Apache. Also, we could be impairing the future rights of our customers. Essentially, this is not really an open source product based on the implications of the license. While there is no payment of cash, payment is in the form of giving up future rights."</comment>


Dev Zines – A list of zines for developers and resources to make your own - <AUTHOR> http://zines.dev <comment><AUTHOR> It's Small Press Day today in the UK and Ireland, so shops, activists and organisers are coming together to celebrate all things self and micropublished. It inspired me to put together this collection of development zines created by some of the smartest zinesters around. Enjoy!</comment>


Storing Bandwidth with Superdense Coding - <AUTHOR> http://strilanc.com/quantum/2014/05/03/Storing-Bandwidth-with-Superdense-Coding.html

<comment><USER2> Bandwidth can be stored in this manner only for as long as qubits can be stored. At present, most quantum memories realized in experiments have a storage time of well under a second. Some last slightly longer, but with big tradeoffs. Stopping decoherence in quantum memories is hard enough that it will likely be a very long time before classical bandwidth becomes the bottleneck!

<comment><AUTHOR> Relevant, though not yet practical: quantum error correction [1]. There's a threshold we have to get over, then it gets a lot easier.

 _edit_ and a reddit commenter mentioned this link saying that the current record for storing a qubit is 39 minutes [2]. Which is about three orders of magnitude larger than I would have expected, if you discount "just shoot the photon into space!" solutions.

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

2: [http://www.livescience.com/41217-long-quantum-bit- achieved.h...](http://www.livescience.com/41217-long-quantum-bit- achieved.html)

</comment></comment><comment><USER3> Though I appreciate the idea of 'storing bandwidth' by just sending lots of qubits ahead of time, that ignores the extra communication overhead needed of tracking them: When Bob receives a qubit from Alice, he needs to know which of his qubits it's paired with. That implies that Alice needs to send not just her qubit, but also some kind of identifier that will allow Bob to match up the received qubit to its proper Bell pair. That identifier, and any protocol overhead needed to keep these identifiers in sync between bob and alice, will consume bandwidth, and reduce the 2x gain.

<comment><USER4> Wouldn't you just be able to pair it in a FIFO order?</comment></comment>


Public keys are not enough for SSH security - <AUTHOR> https://blog.cloudflare.com/public-keys-are-not-enough-for-ssh-security/ <comment><USER2> Reading the first paragraph it's not entirely clear to me if the authors actually understand public key cryptography or SSH public key auth. (I suspect they do, but they certainly don't make that clear, maybe because FUD is how you push a product.)

> If your organization uses SSH public keys, it's entirely possible you have > already mislaid one. There is a file sitting in a backup or on a former > employee's computer which grants the holder access to your infrastructure.

Public keys are public... You mean mislaid a secret key right? And even if an attacker gets ahold of a secret key file, it's still protected by a passphrase (unless of course you use an empty passphrase)...

> Should that happen, how would you respond and revoke the lost SSH key?

By removing that public key from authorized_keys.

Edit: To be fair, I missed this qualifier:

> If someone is able to compromise a team member's laptop, they could use > _keys on the device that lack password protection_ to reach sensitive > destinations.

Okay, not using a passphrase is a bad idea, but that doesn't mean "public keys are not enough for SSH security", right?

<comment><USER3> You have to draw a line somewhere, otherwise we might as well say "don't run SSH at all".

If worrying about a private key leaking is that much of a threat, institute key rotation policies and have people generate a new key pair every month and push the public key where it needs to go and remove the old public key a month after that. Agents allow multiple keys, making this easy to handle on the client side, and if you don't have a way to track and push keys to servers, you should. The one month overlap should be plenty of time for people to get a new key generated even allowing for vacations and most extended absences, and it's not that hard to fix if someone misses the deadline.

<comment><USER4> I'm not really convinced that key rotation is an effective mitigation. Sure, it helps with some classes of threats, but if you're worried about the ones it does protect from you should imo be worried about the others as well.

Like, it mostly protects against an attacker trying to get access from an old machine, but doesn't protect from a device with no disk encryption or weak disk encryption (likewise with key passphrase) being stolen outright within the month's window, or an old key being found within a month.

<comment><USER3> > but doesn't protect from a device with no disk encryption or weak disk > encryption (likewise with key passphrase) being stolen outright within the > month's window, or an old key being found within a month.

Well, it also doesn't protect against the key being exposed within that month and used immediately. That's what makes it a mitigation and not a protection. But against the example class of threats that were presented ("There is a file sitting in a backup or on a former employee's computer which grants the holder access to your infrastructure.") which seems to indicate leaking of private keys over long periods (and the long period is what makes it non-obvious it's leaking), I think it works quite well.

The alternative is to move to a centralized authentication system, but that's got its own set of problems which makes it more of a trade-off than an extra set of practices which mitigates the problems inherent with the current choice. For example, there almost always needs to be a way into the server without network access for network related problems. You're now have the same problems inherent with managing local logins on servers (albeit a much smaller set of logins, maybe one), but maybe it isn't through SSH public keys, and is much harder to change. Will that get rotated? Will that password get changed after someone leaves if it was shared with them?

</comment></comment></comment></comment><comment><USER5> Cloudflare trying to inject themselves into the middle of yet another core infra component. Shameless.

</comment><comment><USER6> As an alternative solution to the SSH key security concerns raised here, I use a Yubikey as a smart card for my SSH access. This way, even if my laptop is compromised, an attacker has to physically steal my Yubikey (and know the PIN on it).

If interested, I followed this guide to set it up: [https://github.com/drduh/YubiKey- Guide/blob/master/README.md](https://github.com/drduh/YubiKey- Guide/blob/master/README.md)

</comment><comment><USER7> Other things you can do for smaller teams:

\- When provisioning keys, ensure that team members put a unique, strong pass phrase on the file

\- Set up two-factor verification via the google Authenticator PAM module

</comment><comment><USER8> > Should that happen, how would you respond and revoke the lost SSH key? Do > you have an accounting of the keys which have been generated? Do you rotate > SSH keys? How do you manage that across an entire organization so consumed > with serving customers that security has to be effortless to be adopted?

The problem presented above and the solution they offer seem like miles apart.

The number of ssh keys is likely finite in an organization. It shouldn't be hard to keep track on those.

Instead, you're supposed to integrate a complex process?

Encrypt your data, add a passphrase to the key, have admins keep record.

Does CF have little faith in admins?

<comment><USER9> Diaclosure: I work at Cloydflare. Administering 1 machine easy. 10 machines with 100 users a bit more effort. 1000 machines and 10,000 users. Hard. That's on top of integrating with your LDAP source of truth.

<comment><USER3> No, it's not. I've written multiple key management and push systems over the last 15 years. It's a 50 line Perl script, if that, and that's with groups and server roles.

Scales perfectly fine with hundreds of servers and tens of users, but that's just with a flat text config file, keys separated in their own dir, and no parallelization.

I've done LDAP auth and querying before, I don't see this being all that hard.

</comment></comment></comment><comment><USER10> I was about to joke "Coming soon: SSH through Cloudflare"... but that's in fact exactly what it is.

You might be able to save money on Cloudflare by literally just mailing all your keys to the NSA every week.

</comment><comment><USER11> Exposed private keys are are problem. But there are several open source solutions for this. I recommend keymaster ([https://github.com/Symantec/keymaster](https://github.com/Symantec/keymaster)) as it is designed with madatory 2FA and a user flow that does not require you to leave the CLI. (I am one of the contributors)

</comment><comment><USER12> No real mention of key passphrases, except that a team member might forget to use one.

It seems to me that the title is not really true for individual users or small teams - modern OpenSSH passphrases are good enough to protect against theft.

<comment><USER13> What is a modern passphrase? Or modern OpenSSH?

</comment></comment><comment><USER14> [https://en.wikipedia.org/wiki/Tokenization_(data_security)](https://en.wikipedia.org/wiki/Tokenization_\(data_security\))</comment>


Ask HN: how could email be better? - <AUTHOR>

How could email be better?
Right now a lot of people just leave emails unread and then come back to them. This seems inefficient.
Does treatment of emails depend on what kind of email you receive? (e.g. facebook messages vs. broadcast emails) Meaning it needs to be split up more? <comment><USER2> With the growth of social media email notifications (from facebook, twitter, asw, etc...) I wake up every morning to about 40 emails. A method to filter these into groups - event type emails which include fb, twitter and broadcast emails versus personal emails would make my life so much easier and my email a lot less cluttered.

Another way to improve email is to find a way to deal with unread emails- so you need some sort of 'interim' board where you can drop emails you want to deal with later on.

Obviously these are only a couple of ways that email could become a better and more efficient tool...I am certain there is scope for more suggestions.</comment>


Show HN: Golang service to read records from kafka and write to elasticsearch - <AUTHOR> https://github.com/inloco/kafka-elasticsearch-injector <comment><USER2> Thanks for that!

</comment><comment><USER3> Awesome!</comment>


The Unfinished History of U.S. Freeway Revolts - <AUTHOR> https://www.citylab.com/transportation/2019/07/freeway-revolts-interstate-highway-system-data-urban-history/594082 <comment><USER2> > _Most famously, in New York City the writer and urban visionary Jane Jacobs > took on Robert Moses, rallying community opposition to his grand plan for > the 10-lane Lower Manhattan Expressway that would have destroyed parts of > Little Italy and SoHo._

The biographer Robert Caro paints a maddening picture of how Robert Moses decimated communities in NYC with his highways with effects that live on today. Moses did so with a disregard and even callousness for freeway placement, even when it would have made more sense _not_ to have it run through a vibrant community.

The Power Broker is the best book I read last year. It is enlightening, frustrating, and at times enraging. It is 1344 pages. I recommend the audioboook.

[https://www.goodreads.com/book/show/1111.The_Power_Broker](https://www.goodreads.com/book/show/1111.The_Power_Broker)

<comment><USER3> I've been wishing for years that this would become available on Kindle. My commute wouldn't allow me to easily lug around such a tome, so I have yet to read it despite its obvious quality. I don't understand why a book publisher would hold out on an ebook version yet have an audiobook available...

<comment><USER2> Interesting. I see that Amazon does not have an ebook of it yet there appears to be an epub on library Genesis so depending on your scruples...

<comment><USER4> Download it and mail a check to the author.

</comment></comment></comment></comment><comment><USER5> I have family in Saint Louis and we visited the City Museum which has various artifacts and historical anecdotes about the city.

Over and over they would show something really cool, like the old baseball stadium, townhouses, trolleys, neighborhoods and it would end with, "they were all demolished to build highways".

Saint Louis itself is now the definition of a suburb-city, lacking character with a very small walkable downtown, and everyone has to drive to get from strip mall A to strip mall B. Very sad what the car did to that city. Even my family who lives there recommends not moving there.

</comment><comment><USER6> >The revolts did help usher in federal policy changes that prioritized local input, historical preservation, and the environment

Which seems to be leading to infrastructural stagnation as no city or state seems to be able to please the local stakeholders enough to build anything (not just highways).

<comment><USER7> no, that's mostly because infrastructure is grossly underfunded and we built so much unsustainable urban sprawl we can't afford to rebuild it

</comment></comment><comment><AUTHOR> It seems crazy today that anyone thought neutering cities with freeways was a good idea in the first place.

[https://www.newyorker.com/magazine/2019/07/29/was-the- automo...](https://www.newyorker.com/magazine/2019/07/29/was-the-automotive- era-a-terrible-mistake)

<comment><USER8> Freeways were designed in part to help the US army traverse the county in times of war. Before freeways, the US did a transcontinental trip with all kinds of vehicles including a young Eisenhower who saw the importance of fast transit.

They were essential in the event on an invasion. I guess they could've been made federal and not usable by civilians.

<comment><USER9> That was the motivation for the interstate system at a national level, but not the reason access freeways were put directly through the center of a number of cities. There's not much military usefulness in something like the I-345 spur that cuts through downtown Dallas, or the now-demolished Cypress Street Viaduct through Oakland. If you just wanted a national road network, it would've been cheaper to bypass dense urban areas. Those kinds of urban freeways had more to do with postwar planners' ideas about the future of housing/working/commuting.

<comment><USER10> We're discussing the decision-making of people in the US in the 1950s, correct? If communists take control of a dense urban area and throw up barricades to block the more narrow streets, there is military usefulness in having a freeway passing through that urban area.

It is also theoretically useful in case of a railway strike.

<comment><USER11> This was the 1950s. If it was even slightly conceivable that Communists would take a city somehow, after an amphibious landing across a distance the world had never seen, and the city had not already been reduced to rubble by incoming ICBMs or strategic bombing, it would have been destroyed by a stay- behind nuclear mine.

<comment><USER12> The Communists were big on revolution. As in, from the inside, done by the workers of the target country themselves, usually with a lot of foreign help but no full-blown foreign invasion. It may seem implausible now, but many countries had already fallen to revolutions, and it was not unreasonable at the time to think it might happen in the U.S.

</comment></comment></comment></comment></comment></comment><comment><USER13> Good stuff. Led me to a couple of surprisingly detailed Wiki articles. In many cities the interstate project was greeted like an invasion. Often because of elimination of ethnic neighborhoods in the guise of 'urban renewal'.

[https://en.wikipedia.org/wiki/Highway_revolts_in_the_United_...](https://en.wikipedia.org/wiki/Highway_revolts_in_the_United_States) (US scope)

[https://en.wikipedia.org/wiki/Highway_revolt](https://en.wikipedia.org/wiki/Highway_revolt) (worldwide scope)</comment>


The Increasing Importance of Container Security - <AUTHOR> http://www.waratek.com/news/virtualization-review

<comment><USER2> The new solution is called "Locker" and was released at a Microsoft event-- guess who is the first major backer? ;-)</comment>


Indoor Plants: A $1.7B Industry. Here's how I'd start a D2C business - <AUTHOR> https://simonblogs.substack.com/p/-signal-a-17-billion-industry-ready?r=3stu8&utm_campaign=post&utm_medium=web&utm_source=hackernews <comment><USER2> Plant sales are one of those weird things that are really tactile and personal. Buying a plant feels a lot closer to adopting a puppy than buying a commodity.

<comment><AUTHOR> Yeah, you're absolutely right. That's one of the reasons buying seeds (imo) is more fulfilling than buying a plant.</comment></comment>


A big ICO team is a bad sign - <AUTHOR> https://www.bitcoinbeginner.com/blog/big-ico-team-red-flag/ <comment><USER2> A blockchain and a company are not the same thing.

A blockchain shouldn't need trust but a company absolutely does need it. Until the product is built you have no idea if they're even going to produce anything.

If they have a number of known entities in the space willing to peg their name to it, that's at least a modicum of trust that they aren't going to just take the money and run. It's not much, but it's something.

I'm sure you could cherry pick a few blockchain based startups with extremely small all engineer teams that you absolutely should not trust above some of these ones.

If team size is indicative of anything it's indicative of just how much money is being poured into anything blockchain based. Whether that's good or bad, I don't know.

Lastly, the writer simply scanned the company's team page and decided "at least 4 of them look like they might be able to write code"? What exactly is that expertly produced opinion based on?

</comment><comment><USER3> You mean like what happened with Ethereum Coin?</comment>


Oz government rushes its anti-crypto legislation into parliament - <AUTHOR> https://www.theregister.co.uk/2018/09/19/oz_anticrypto_legislation/ <comment><USER2> It's obvious the 5 (9/14) Eyes are coordinating this and have been doing it for a while, way before starting to make public statements together about it.

They are trying to make it look like "everyone's doing it" while also rushing the laws so that there is no proper debate (which would no doubt result in rejection of the proposals, and they know it).</comment>


And why Rust's await should be a method after all - <AUTHOR> https://www.hardmo.de/article/2019-05-06-await-method-afterall.md <comment><AUTHOR> For some reason the title got screwed up. It should be "How and why".</comment>


Any hackers in Boston looking to get involved in a growing start up? - <AUTHOR>

I started a company about a year ago. Outsourced the development, did the marketing, grew it to 5,000 users, have some paying customers and lots of interest from others.
I'm looking to bring on a tech lead to help improve the product and service. I can offer equity in exchange for your skills. Right now I've met with some of Bostons top Vcs and Angel investors and have interest from both parties.
Anyone interested please feel free to email me (in profile) or post your email and I will email you. I'm located in the Northeast and would prefer finding someone also in the Northeast, but am open to anything.
Thanks! <comment><AUTHOR> I should also mention I have deep, intimate knowledge of the industry we service (its a B2B service) and lots of connections that will help us grow!

</comment><comment><USER2> svedlin at gmail dot com</comment>


Exploits start against flaw that could hamstring huge swaths of Internet - <AUTHOR> http://arstechnica.com/security/2015/08/exploits-start-against-flaw-that-could-hamstring-huge-swaths-of-internet/

<comment><AUTHOR> This is interesting too: [https://www.isc.org/blogs/about-cve-2015-5477-an- error-in-ha...](https://www.isc.org/blogs/about-cve-2015-5477-an-error-in- handling-tkey-queries-can-cause-named-to-exit-with-a-require-assertion- failure/)

I'm curious to see how this will shake out. Have all the big players upgraded already?

-Is there a way to weaponize the exploit, instead of just crashing the server?-

Edit: I read the POC header comment, it says no.

</comment><comment><USER2> Here's a PoC I found on GitHub: [https://github.com/robertdavidgraham/cve-2015-5477](https://github.com/robertdavidgraham/cve-2015-5477)</comment>


Good source control check-in habits - <AUTHOR> http://richarddingwall.name/2008/11/23/back-to-basics-good-source-control-check-in-habits/ <comment><USER2> And this is why I love git: I can use fine-grained check-ins locally to keep detailed track of my work, but squash everything together into a sane set of commits when I push upstream.</comment>


Why I Believe the American Dream Just Died - <AUTHOR> http://fortune.com/2016/04/22/why-i-believe-the-american-dream-just-died/ <comment><USER2> I can't tell if the author is including retirement investments. $200k isn't exactly enough to retire at 65.

</comment><comment><USER3> It's called a dream because you'd have to be asleep to believe it. -George Carlin</comment>


The EIF has frozen funding to new UK VCs - <AUTHOR> http://uk.businessinsider.com/the-eif-has-frozen-funding-to-new-uk-vcs-and-cancelled-an-angel-investment-scheme-2017-5 <comment><AUTHOR> I dislike the hyperbolic way this is portrayed in the article but anything that makes funding harder for the UK tech scene can't be a good thing, even if it's not official policy for these instituitions.</comment>


A brief rant on the future of interaction design (2011) - <AUTHOR> http://worrydream.com/#!/ABriefRantOnTheFutureOfInteractionDesign <comment><USER2> This is probably my all-time favorite article on the internet. I've brought it up in conversation dozens of times when referring to ways to control computers. It's why I don't really use phones for anything beyond answering phone calls and handling urgent tasks when I'm not at home/office. I just feel like I have very little control over these devices, unlike the massive control with a keyboard or mouse, or even better, a fork and spoon when eating dinner (although despite its high degree of control, you can't control a computer with them).

Tech innovators and its users/consumers need to think outside of the box more often for ways to control computers. Given a physical UI device, you can place it on a spectrum of "computer-friendly to human-friendly". Touch screens are computer-friendly because it's trivial for computers to understand and developers to interact with. The downside is that users feel distanced from their control, so it is difficult to use efficiently. But developers are smarter than users at UI---the difficulty should be put on them instead, to control their software/OS.

I've imagined things like stress balls with "electric muscles" for feedback to control various applications, a cube with the ability to change its texture with suction/servos, and things like [https://roli.com/products/seaboard](https://roli.com/products/seaboard) or [https://www.expressivee.com/buy-touche](https://www.expressivee.com/buy- touche) except for general computing applications rather than music performance. Who knows what could be invented if customers could be convinced their computing experience can be improved with better physical interfaces.

<comment><USER3> As a fan/user/creator of modular synthesizer stuff and design observer in general I can usure you that you are quite definitly not the only person that feels like this. Vinyl record sales have surpased CD for the first time again not long ago, people crave for physical interfaces, modular synths and everything hardware is getting more popular despite the ton of plugins you can get for your music software. People are going back and build physical interfaces for menu-diving-synthesizers from the 80s like Yamaha's infamously unprogrammable but amazing sounding DX7.

People are rediscovering mechanical keyboards etc.

Modular synthesizers are a wonderful playground for physical interface design. Because of course you want to expose a lot of functionality of your module, but on the other hand your panel will get big and your module will end up taking up a lot of space. Of course you can get away with using a screen and an encoder but hoe wrll can you use it live while making muic then? Of course you can add 20 dials, but maybe 3 clever ones that abstract over those 10 in just the right ways are better? Also: people might not use your module for a month, how can the design remain in their head just enough to kick a spark?

Physical interfaces. Use them blindly, shile wearing gloves, in your pocket.

<comment><USER2> A have a few thousand HP of Eurorack and definitely agree that modular synths are easier, more fun, and more interactive to control than most other interfaces. But even then, they're clunky for some things, and I feel that there are _further_ designs that can achieve control even more efficiently.

<comment><USER3> I agree. There is even more possible and not all modules are really well designed (e.g. why did Dieter Doepfer feel the need to swap around the otherwise identical inputs between his SEM- and Wasp-Filter?). Other modules just don't go far enough. many lack attunoators/attenuverters (for economical and space reasons).

You have to really fight to get a decent physical interface, to get a good one takes even more.

I believe the future of modular interface design lies especially in more visual feedback which makes usage easier and more intuitive and systems more reliable during live usage. There we can learn from modular and semimodular synths from the software side.

</comment></comment></comment></comment><comment><USER4> It's sad that since this article was first written, the trend for dumbing down both the hardware and software we use every day has only continued.

When I was a kid, I used to love experimenting with programming. I first learned on a ZX81, with a magnificent 1KB of RAM, typing in simple games programs from books every session because there was no storage device to save them. That experience, that joy of being able to _create_ something fun, sparked an interest in what these amazing technologies we have invented can do.

Some of my slightly younger friends were lucky enough to have more powerful systems like the BBC Micro available by the time they reached that stage. Those were brilliant because you could connect _anything_ to them. When they were writing simple LOGO programs at school, they didn't just draw a circle on the screen, an actual mechanical turtle with an actual pen would draw a circle on a real piece of paper, right before their eyes.

Now I want to offer that same joy and intrigue to the next generation of my family. Today's ubiquitous computing devices are phones and tablets, each with numerical specs many orders of magnitude bigger than that ZX81. That little boy typing in listings from a book now has multiple decades of professional programming experience to share.

And yet, I can't sit down with my own child and write even the most simple game on those devices, because for all their theoretical power, they lack even a rudimentary programming interface. In some cases, I can't even write a game myself on another system and port it, because the whole ecosystem is closed off.

How is it that in a time when children seem, often all too soon, to be carrying around more processing power in their pockets than a supercomputer had when I grew up, they still can't enjoy the sense of freedom and discovery that I experienced with my little ZX81 and its 1KB of RAM and no storage device in the 1980s?

<comment><USER5> They can!

If you're on iOS, have you tried Pythonista? It's $8 on the app store, uses Python as the programming language, features an IDE, and a UI library so budding programmers can write video games.

For those on Android and the technically minded, a rooted Android tablet offers far more options for on-device programming. There's likely an equivalent to Pythonista in the Google app store as well.

(No affiliation; I'm sure there are other apps that are similar, that's just the one I know of.)

<comment><USER6> You don't need to root Android (or even go outside the app store) to have a wide range of on-device programming options (you might need to engage developer mode for many of them, but you can do that without root.)

<comment><USER5> I'm sure you're right, but I've moved away from Android. Are there any apps in the Google store that you know of, or would personally recommend?

<comment><USER6> Well, RFO-BASIC! is an interesting modernized BASIC with relatively full integration with phone features that is available on the store (you have to get the non-Store version for SMS features, thought).

It's the thing I've seen that off the top of my head seems most related to your comment.

</comment></comment></comment></comment></comment><comment><USER7> Victor is one of the people behind Dynamicland, the "live paper"/"room is the computer" startup that was shut down recently. That was on HN last week or so.

Fancier input devices seem to have come and gone. They peaked in the 1990s, when you could see a lot of them at SIGGRAPH. My favorite was the magnetically levitated sphere in a bowl. It was like a 3D joystick/trackball with force feedback. It was really cool. It never sold. There were lots of gadgets like that. An animator friend had a workstation with a keyboard, a knob box, a button box, a joystick, a trackball, a tablet, and two screens. Some of the people doing Jurassic Park had a model dinosaur where you could move all the joints, the computer could read the angles, and the on-screen image moved to match. None of this ever caught on. Even 3D joysticks are rare. Game controllers with two joysticks caught on, but those joysticks are abstractions of what's on screen, as, for example, steering, not direct interaction.

I tried Jaron Lanier's original gloves-and-goggles VR system. You couldn't do much with the gloves. That was pretty much true in later glove systems. Autodesk fooled around with VR in the 1990s, but determined that gloves and goggles were not going to make CAD easier.

Lack of force feedback is a huge problem with gloves. Without force feedback, it's like trying to work in oven mittens. Much of human precision is tactile feedback. Without that, precision work is slow and tiring. As everyone who's soldered surface mount parts under a microscope knows.

Back in the 1990s, when I was working on collision detection and physically based animation, I considered building an input device I called "The Handle". The Handle was to be a jointed arm, like a robot arm, with a grip handle on the end as an input device. A servomotor system (or, for cost reasons, I was thinking brakes only back then) would provide tactile feedback. The handle itself would have the ability to split, like pliers, so you'd have something to squeeze.

The Hammer could potentially simulate pliers, tongs, wrenches, hammers, etc. Do simulated auto repair. Assemble Meccano. This would have been what Victor is calling for.

Could it be built? Yes. Would it sell in volume? No.

That's the problem.

<comment><USER8> I tried out the 3D Systems Touch Haptic Device a few years ago, which sounds a bit like a simpler variant of your "handle".[1] It was quite good. Feels really strange, but good, to be interacting with things "inside the screen".

[1] [https://www.matterhackers.com/store/l/3d-systems-touch- hapti...](https://www.matterhackers.com/store/l/3d-systems-touch-haptic- device/sk/M12PCJ5U)

<comment><USER7> That's one of the very few devices in that space ever to be produced in volume. Small volume, but a real product.

</comment></comment></comment><comment><USER9> Though this has been discussed many times, I must say the trend of using touchscreens to replace dials and buttons on cars is extremely worrying. It's entirely an aesthetic and cost saving decision at the expense of safety and UX.

<comment><USER10> > I must say the trend of using touchscreens to replace dials and buttons on > cars is extremely worrying

Most are going back on that. It is just that what is currently being sold was developped years ago.

<comment><USER11> I'm lucky that my car was made in the in between period, so all touch screen controls have physical controls as well.

I use the physical controls, especially when driving. But my navigatrix prefers the screen, primarily because she likes the visual feedback. (Not enough of the physical controls in my car have things that light up to let you know something's happened.)

</comment></comment></comment><comment><USER12> This brings to mind the phone ringing in the middle of the night. You pick it up and add mumble into the receiver and the conversation begins. But no, now the phone rings in the middle of the night (assuming it isn't text / Slack / email / etc.) and you pick it up and then try to focus your eyes on the screen to figure out WHAT is happening and then HOW to answer. It seems the massive leap forward in the CAPABILITY of our phones has actually caused them to stumble backwards in PRACTICAL usability.

<comment><USER13> So, has anyone made a "old school smartphone dock"?

What I want is a dock I can put my smartphone into and then the old phone interface takes over. Preferably one with links to 1-2 other docks in the house so all three ring if I get a call.

Pick up the physical receiver, say hello. Talk. Say goodbye, hangup. No screen interaction at all.

<comment><USER14> The cordless phone system I have lets you make/receive calls via your cell phone from any handset in the house. It connects via Bluetooth, so isn't a dock, but the functionality is similar to what you're suggesting.

Mine is an older Panasonic system, but I'd be surprised if other manufacturers didn't offer something similar.

<comment><USER13> Like this? [https://shop.panasonic.com/cordless-corded- telephones/cordle...](https://shop.panasonic.com/cordless-corded- telephones/cordless-telephones/KX-TG7875S.html)

<comment><USER14> Yes, mine is very similar.

Though, (and I should have mentioned this in my original comment, sorry) I've never actually used the functionality in question, so I don't know how well it actually works.

</comment></comment></comment></comment></comment><comment><USER15> Instead of a single spectrum from computer- to human-friendliness, picture a triangle with the third vertex being "task-friendliness" or task specificity. The author is advocating a return to human-friendliness, but what he describes is more like task-friendliness.

I've become somewhat obsessed with ergonomics after a long battle with chair pain. In my mind, true human-friendliness does not require new interfaces for every task (although it may require a slightly different interface for each _human_ ). Every computing task may very well be handled best by a person sitting in a chair at a workstation. That wouldn't be bad design IMO; computers are, in fact, general purpose.

If we can get to a point where each computer user is able to use their computer comfortably for 8 hours straight, without pinching a nerve or a blood vessel (yes! it's possible!), then I would consider that a human-friendly design.

I'm not talking about iPads here - the author is totally right that these devices don't seem to be made for human beings.

<comment><USER16> As far as I understand, remaining in a static position for 8 hours straight during the day and another 8 hours straight while asleep is pretty bad for many parts of the body irrespective of what that position happens to be.

People need to be occasionally changing position, moving about, getting their circulatory system working, getting their muscles working, focusing their eyes at a longer distance, etc.

We can improve people's experience with sit–stand desks, frequent short breaks, periodic longer breaks, a daily commute requiring walking or other exercise, etc., but reducing the total number of hours people are staring at screens every day would also be generally helpful. It isn't all that great to exclusively work at even the most ergonomic possible computer workstation.

<comment><USER15> There's truth to what you're saying, but it implies you have to accept a certain level of pain or physical discomfort if you work in a seated position, and the only way to manage the pain is to get out of your seat. But there are types of pain that can't be managed that way. Those injuries have to do more with sustained muscle tension caused by bad equipment than just sitting, and will continue to get worse until you change your equipment to eliminate the tension.

</comment></comment></comment><comment><USER17> A few things come to mind. First, I've been reading a lot on the science behind Montessori education, and there's a lot to support the idea that our brains are much more active when we're physically interacting with something. Would be logical to assume that the richer the physical interaction, the more meaningful the connection.

Second, reading Jaron Lanier's somewhat recent book on VR I was struck by how far ahead of its time the 'data glove' was. Early VR may not have had the dazzling eye-candy of today's graphics, but on interactivity we just seem to be catching up. (As an aside, I never realized the Nintendo PowerGlove was basically Data Glove 'lite'; developed by VPL.)

Edit: Third, I recently read Carl Sagan's "The Dragons of Eden" which he wrote in the 1970s. It's about the evolution of the human mind. It's SO worth reading today, even if its outdated and proven wrong at times by contemporary discoveries. One thing that really stood out was this idea that it wasn't so much that humans evolved and then invented tools – but that perhaps tools shaped our evolution as much as we shaped tools. Invent a simple tool -> use the tool -> brain develops as a result -> invent even more complex tools -> etc.

</comment><comment><USER18> A thread from 2013: [https://news.ycombinator.com/item?id=6325996](https://news.ycombinator.com/item?id=6325996)

Discussed at the time: [https://news.ycombinator.com/item?id=3212949](https://news.ycombinator.com/item?id=3212949)

</comment><comment><USER19> > With an entire body at your command, do you seriously think the Future Of > Interaction should be a single finger?

What if you don't have an entire body at your command?

The plus side of "pictures behind glass" is that it's a fairly well standardized interface — the software has to adapt to that homogenized hardware, instead of you fighting to adapt to the hardware. (Or, more accurately, you adapt to it once, instead of once for every type of object you want to interact with.)

If interactive experiences all start to require a good range of motion, bodily sensitivity, and ability to instinctively interpret the interface, there's a risk it could be incredibly alienating for many. Unless we design with that consideration from day one, it could make adaptivity harder than it already is.

I went looking for Bret Victor's take on this question because I was certain he would have thought of this already. So far I only found this:

"Channeling all interaction through a single finger is like restricting all literature to Dr Seuss's vocabulary. Yes, it's much more accessible, both to children and to a small set of disabled adults. But a fully-functioning adult human being deserves so much more."

[http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesi...](http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/responses.html)

I find it sad to read that. Those with access issues deserve so much more too. There's already a huge access gap. If we're going to champion new modes of interaction, we should fight hard not to make the gap bigger still.

<comment><USER20> This may be controversial view, but I'm with Bret Victor on this. Of course, we should do as much as possible to make everything accessible to everyone. But we should _not_ strive for a single universal interface that's accessible to all, because that's sacrificing both the best and the average case for the worst case.

Consider books and vision loss. The tried-and-true solution to make books accessible is printing them in Braille. But nobody in their right mind would be suggesting we should only ever print books in Braille, because then it's equally accessible. It would be more "fair", but it would also be a ridiculous waste for the 99.5% of the world's population[0].

If we were to equalize all our technology and processes across all accessibility issues, our civilization would collapse - it would mean nothing depending on body motion, on body sensitivity, sight, sound, speech, taste, pain. The union of all existing disabilities is a life of a rock.

So since we can't really have a truly universal interface[1], we may as well give up on trying to design technology to the lowest common denominator, losing most of the benefits it gives, and instead design it to play to the strengths of human body. Fallback options should be available where possible, but at some point we have to understand that until medical technology homogenizes our bodies, not everyone will be equally suitable to every task.

(And I say that as someone who has always dreamed of being a pilot or an astronaut, but for whom that career path was cut off by large nearsightedness early in teenage years.)

\--

[0] - "36 million people are blind" according to [https://www.who.int/news- room/fact-sheets/detail/blindness-a...](https://www.who.int/news-room/fact- sheets/detail/blindness-and-visual-impairment)

[1] - At least not until a proper brain-computer interface exists, and we all interact with everything using our thoughts.

<comment><USER19> Thank you for this perspective. You changed my mind about this.

</comment></comment></comment><comment><USER21> There are some gaps in reasoning, but overall I think the point stands.

The biggest omission is the key advantage of "Pictures Under Glass": they can be defined purely in software. Because of that, I don't think they'll ever stop serving a role in our device interactions. No amount of space-age physical device design could've supported the smartphone's explosion of apps without pictures under glass or some equivalent.

With that said, we could definitely benefit from moving some of the more constant/widespread interactions back to physical controls. Buttons and switches on smartphones are always appreciated. And don't even get me started on cars, where there's little need for a vibrant developer ecosystem and a _ton_ of need for non-visual interface comprehension. I also think the Apple Watch's "crown" is one of the more interesting recent examples of a tactile interface that doesn't sacrifice open-ended software development.

<comment><USER22> Re: _Buttons and switches on smartphones are always appreciated._

I disagree, I'm always accidentally bumping or pushing them. Plus, they usually do tasks that are not my top tasks. I'd like to reassign some of them to my favorite actions.

</comment></comment><comment><USER10> I'd like to extend this to fucking VR. All VR experiences lack one thing: full body haptics. Take something inspired from the "Pacific Rim" cockpits ( [http://i.imgur.com/DLze6j7.jpg](http://i.imgur.com/DLze6j7.jpg) ) so you can have some contraption giving you a huge freedom of movement and haptic feedback everywhere. That'd make some games a lot more immersive and physical.

<comment><USER23> The reason games don't feel physical is not because of which senses are being stimulated, it's how they are stimulated.

If the game is just waiting for your hand to enter a bounding box, that's a 0-dimensional interaction, which feels like nothing. If you could hear your fingers getting close to things, and see the angles between your body and other surfaces, sense through visual texture the relationship your body has with different fields, you would register those things a "physical" experiences.

Touch doesn't feel like touch because it's your fingers, it feels like touch because it's rich and continuous and textured and perfectly grounded in body- space.

You can make proprioaudiovisual experiences like that too, it's just hard and there are easier ways to make video games that make money.

The science is clear that our brains don't care which sense data comes from, they just care about the structure of the data.

Although there are anatomical structures that make some senses better at processing one structure than another, they don't prevent the brain from using those senses for other schemas, if the environment demands it (injury, prosthetics, etc)

</comment></comment><comment><USER24> This is great! Really shows what we have today is a reductionist approach to only using our finger on a 2D surface as opposed to utilizing all our motions, muscles and senses to interact with technology in 3D space.

<comment><USER25> Personally, I think it's a bit asinine.

Rather than decry anything that resembles what we have today as old-fashioned and not futuristic, it should first be asked _" why are screens so common today?"_

We've been using our hands for years- keyboards, trackballs, mice, joysticks, custom wheels for driving games, the nintendo light gun for duck hunt, and so forth. Take that- and combine it with something else that should be jumping out at you from the article: _every picture with a hand shows it holding a different object_.

Screens are multi-purpose. They are perfect for scenarios where one control must meet many needs (compared to the pictured hammer, which at best meets two). Let's say that we could imagine some multi-purpose, tactile, 3 dimensional interface... say, like a hologram from Iron Man or Star Trek. Now compare that to the article's mention of Alan Kay's doodle pre-integrated circuit. The difference is huge... we don't even have the physics knowledge to describe how a tactile hologram could exist at safe handling energies, let alone in open air, as described by those fictions. Comparatively, Alan Kay combined things that already existed... battery, circuits, screen and keys, and imagined what could happen if they were smaller and portable.

We had things much more similar to what he drew decades before we had the ipad; the ipad is merely an incremental improvement over some of my own childhood toys, not to mention what was already available a few years after his own drawing, such as the Speak and Spell ( [https://en.wikipedia.org/wiki/Speak_%26_Spell_(toy)#/media/F...](https://en.wikipedia.org/wiki/Speak_%26_Spell_\(toy\)#/media/File:Speak_&_Spell_\(original_style\).jpg) )

<comment><USER26> The most honest answer?

Because putting a damned capacitice touchscreen is cheaper than even one good button.

I spent non-trivial amount of time to find devices that have tactile, physical interfaces. I certainly paid a premium in all cases. Because putting a capacitive layer and an LCD is god damn cheaper, for the reasons you describe.

It's not that the screens are better, or even good. It's that they are so versatile that they are the cheapest, lowest common denominator option for interaction design.

In a sense, Star Trek predicted this, as at least part of the reasoning behind flat panel touchscreens everywhere was that it was very, very cheap prop to make compared to complex physical controls.

The touchscreen is the natural evolution of unending drop down menus that require several trips through every time you do some operation, because the application development had no time for UX research.

<comment><USER27> This just isn't right. It's not the cheapness, by far. The iPhone didn't revolutionize the world because it's cheaper - it did in spite of it.

It revolutionized the world because a big screen means:

\- More content you can view at once

\- More flexible and powerful apps that can have more, more intuitive controls and display more information

\- Touching an app directly and interacting with it directly means you can manipulate apps far more intuitively, quickly, with direct feedback (remember scrolling webpages before touch with tiny ball wheels or up/down arrows? yea, it sucks)

Resistive touch screen sucked, but capacitive were more expensive and were the game changer. I think you have it backwards.

<comment><USER20> iPhone "revolutionized" the world[0] because it gave people a portable computer that combined multiple separate devices into one, with (added retroactively) possibility for extending it with further capabilities.

This justifies _a_ smartphone in its current form. It does not justify why your car stereo is operated by a touch screen.

The truth to p_l's comment is plainly evident if you look at household appliances of today. You'll note that ovens and washing machines don't even have touch screens. They have touch panels with fixed image underneath (same with pre-CGI Star Trek interfaces). They're an UX nightmare, but are used precisely because capacitive touch detection is very cheap (doubly so at low fidelity required in these cases) - it's just a plastic/metal sandwich with zero moving parts.

\--

[0] - iPhone is the one that's most remembered, but not the only phone in that space in its era.

<comment><USER27> Sure, I was just responding to the parent post though. As for a touchscreen in your car, I expect people have different preferences there.

<comment><USER26> A big problem is that you don't really choose a car based on whether it has touchscreen or not. And then there's the aspect of "distracted by the shiny" which has to be tempered by having experience with touchscreens

</comment></comment></comment></comment></comment></comment></comment><comment><USER28> Back when touchscreens started to become popular i remember some talks about a 'tactile overlay' to touchscreens, essentially a grid of tiny bumps (pixels, though at a much lower resolution) that would 'pump up' and 'flatten' just enough to provide a tactile feel to the otherwise glassy screens.

What happened to that?

</comment><comment><USER29> I almost made a comment in this article about using Deep Learning and Motion Tracking to have computers better understand our gestures so we can interact visually.

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

At some point AR and VR will finally provide us the overwhelming need. Then we'll wonder why we didn't think of it sooner.

At the moment, we're stuck in the "a keyboard and mouse are better" stage.

<comment><USER30> You can't just drop the idea of Deep Learning into a problem as a magical solution.

What does visual interaction entail and what is stopping that from having already been trialled during one of the previous (and current) attempts to get vr to work for people?

<comment><USER29> If you can use Deep Learning and CNN's to drive a car, you can probably use it to recognize different hand motions.

[Update]

I found a link where someone tried to do a simplified version of this:

[https://towardsdatascience.com/tutorial-using-deep- learning-...](https://towardsdatascience.com/tutorial-using-deep-learning-and- cnns-to-make-a-hand-gesture-recognition-model-371770b63a51)

<comment><USER31> It's certainly possible to recognise hand motions (see e.g. Leap Motion), but I think hand motion recognition is pretty hard to use effectively without haptic feedback telling you what you're touching and where. Ideally actuated like [1] but for your whole hand, not just a stylus. I don't think technology is anywhere near that. The device in [1] pushes back against you, physically stopping you from moving through virtual objects.

[1] [https://www.3dsystems.com/haptics- devices/touch](https://www.3dsystems.com/haptics-devices/touch)

<comment><USER23> You don't need haptic feedback, just good feedback. There's plenty of bits in an audio stream alone to give the brain the control feedback it needs. You'd be surprised how few degrees of freedom we use for grasping.

</comment></comment></comment></comment></comment><comment><USER32> I noticed this while experimenting with VR and hand-tracking. Without tactile or precise auditory feedback, the experience was hollow, even with relatively high-fidelity visuals and tracking. You can never feel like you are somewhere else - or something immaterial is with you - until a full sensory experience coalesces, even if it's "low resolution." Until then, the result is landing in an experiential uncanny valley.

On another note, we should also be looking at accessibility when approaching this research. Contrary to that last little bit at the end, not everyone has full use of their bodies, or even of their hands. I just finished listening to an NPR segment about inner-city youth dealing with permanent disability as a result of gun violence, and the unique challenges presented to them. Perhaps with people like them in mind, the mass solutions we eventually end up with will be better for focusing farther upstream than nerve endings.

<comment><USER33> > You can never feel like you are somewhere else - or something immaterial is > with you - until a full sensory experience coalesces, even if it's "low > resolution."

I'm not sure I agree with that. Games like Beat Saber and the old demo of Budget Cuts have really made me feel like I'm inside another world, particularly when I was newer to VR.

I say "not sure" because we're not necessarily talking about the same thing—the above are "games" or at least "experiences", not "interfaces. You don't really touch anything in Beat Saber, except for the blocks where a strong rumble is sufficient. Harder to do that in a UI.

<comment><USER34> In a fitness experience, you can imagine the resistance at least, which is what I wind up doing in beat saber to increase my heart rate and calorie burn. It is actually an interesting problem: can the mind imagine the feedback that really isn't there, causing muscles to work harder even if they don't have to? For some people at least, the answer is yes, though I bet it would be hard for others. But shadow boxing, katas, and so on, have shown that imagining resistance has been around for awhile.

We can kind of imagine tactile feedback already in a UI, and vibration is effective in reinforcing that illusion. Perhaps the way forward is to further play around with fooling the brain (via some kind of cognitive interface) rather than somehow reproducing real feedback.

<comment><USER20> Vibration is key in current VR experience, IMO. Having spent many hours on Beat Saber over the past few weeks, I can say that the only reason my brain recognizes that I hit something with the blade is the little controller buzz that activates at the right moment.

As for adapting yourself to the game, I keep having to focus on preventing myself from using my wrists too much when playing. Given that my goal is calorie burn, I do my best to use my whole arm (as if wielding a real blade). I've noticed that I do create "impact resistance" myself too.

<comment><USER34> It took awhile to stop us g wrists, but now I imagine it as some immensely satisfying glaive work.

BoxVR is another game where imagining feedback is crucial, more so actually with their fitness focus. Their inaccurate calorie counter is completely motion base, so wider faster movements will drive that up as well. Honestly, BoxVR (custom with lots of fast songs) is now more important than BeatSaber to my daily workout, because I'm able to get a lot more effective motions in. On the other hand, I can't play it with the toddler around (if he got in my way, he could really be hurt by the gestures I'm doing).

</comment></comment></comment></comment></comment><comment><USER35> This is why I dislike touch screens in cars so much: You have to look at them. We have 100 years of experience with car user interfaces that don't require you to take your eyes off the road, but we threw all that away in favor of these shitty pictures under glass.

</comment><comment><USER36> I feel my Nokia 3210 in highschool had a much more intuitive UI than the latest iPhone... and it was trivial to use without looking at it, since your hands could navigate the keys...

This isn't possible anymore with _sliding pictures under glass_...

</comment><comment><USER37> I remember this Bret Victor piece from 2011 and I was thinking about it recently when Google announced Soli for the Pixel 4. [https://www.cnet.com/news/project-soli-is-the-secret-star- of...](https://www.cnet.com/news/project-soli-is-the-secret-star-of-googles- pixel-4-self-leak/)

Soli and other gesture-based technologies seem like at least an incremental move to using motion that Bret Victor was advocating for in 2011.

<comment><USER38> to me that seems like the same problem, since you still don't touch anything, the only feedback is the computer doing something (or not)

that said, I'm definitely curious to see how it performs in the wild

</comment></comment><comment><USER39> I think maybe the principle is that we want to be able to transfer as many bits/second of data as possible. We have the computer->human interface down, because screens can already emit more information than humans can process. But human->computer we can only go so fast. This is partly limited by how many fingers we use to do the input. I can type faster on a keyboard than a screen. But I think the main issue people are worried about is that humans can only think so fast. So if the interface requires asking humans for input too much, it will take forever. So instead you try and guess what the humans want. And if you do this well enough, then the input method doesn't matter. Some people say they can type better on their phones because they can use swiftkey. So I think most visions of the future are thinking about AI, and intelligence, and asking "what will we be able to guess without asking the human first?" And this is where they think interaction design is going.

Another point of fact. Such a machine requires less bps from the human. That is, it requires them to do less thinking, which most people will prefer. And if you're trying to predict the future, "machines will require less thinking (but be more mass market)" is a pretty safe bet.

Sandwiches are very fancy things, as everyone knows. But I expend a lot of mental effort getting the cheese slices in the right thickness. I'm sitting there focusing on making sure I don't deflect the knife too deep or too shallow. This is a very fancy task. But many people prefer specialized cheese slicing devices, because they makes more precise slices, and because they require less mental effort. So expect UI to follow the same trend, from general tools requiring complex input to particular tools requiring simple input.

</comment><comment><USER40> Haptic, resistive gloves will merge the tactile with the digital in VR applications. Just like touchscreens, they will serve as a single device that can simulate an infinite number of different controls. Give 5-10 years for the tech to miniaturize and mature. [https://haptx.com/](https://haptx.com/)

</comment><comment><USER41> Embodied cognition is definitely a thing: [https://en.wikipedia.org/wiki/Embodied_cognition](https://en.wikipedia.org/wiki/Embodied_cognition)

And in software development, the primary bottleneck is thinking. Anything you can do to enable greater clarity of thought is going to have huge leverage. So I think this is a super promising angle.

Bret's actively developing his ideas at DynamicLand: [http://dynamicland.org](http://dynamicland.org) But clearly it will be quite some time before that tech becomes viable in the real world.

Now I'm wondering if there are simpler ways to use the rest of my body to facilitate thinking. Like, I can't mount lasers and network connected cameras on the ceiling... but maybe there's some software that can use a webcam to do simple gesture recognition mapped to bash scripts or something like that.

</comment><comment><USER42> The benefit is of "Pictures Under Glass" is the flexibility - it is extremely easy to change the picture to align to almost any use case. It is extremely difficult to have the same flexible interface with something that is tactile and can manipulate its own shape to be appropriate for the task.

<comment><USER43> In 1968 the iPad also seemed extremely difficult, though.

</comment></comment><comment><USER44> > Are we really going to accept an Interface Of The Future that is less > expressive than a sandwich?

Great line.

<comment><USER22> Probably written by a hungry author.

</comment></comment><comment><USER45> The article focuses on the use of hands, but a visionary future technology might focus more on voice and NLP. This is something I have worked for some years:

[http://www.smashcompany.com/technology/the-advantages-of- a-n...](http://www.smashcompany.com/technology/the-advantages-of-a-natural- language-processing-interface)

</comment><comment><USER22> I predict the UI of the future will be via brain implants that allow one to control an app with just thoughts. It may become a necessity in order to keep up with other countries that may have less qualms about the ethical side of surgery and intrusion.

</comment><comment><USER46> I think we are in transition faze. Current future ideas assumes that we will have same interface and hand driven intersections which may not be true. Increase of IOT devices and voice controlled interfaces have different story to tell.

</comment><comment><USER47> 2011

</comment><comment><USER48> The video anchoring the article shows as unavailable for me. Is there an alternate place to view it?

<comment><USER49> Same here, I googled the url of the embedded video and it seems to be a concept video by Corning:

[https://www.youtube.com/watch?v=6Cf7IL_eZ38](https://www.youtube.com/watch?v=6Cf7IL_eZ38)

</comment></comment><comment><USER50> The condescending tone of this article does not help it whatsoever.

Not to mention the huge gaps in logic that cause it to jump from merely a misguided attempt to rail against well established conventions for interfaces to an active argument for those interfaces still being good.

</comment><comment><USER51> ahh was really hoping this was something new from Bret

</comment><comment><USER52> Aw, I was hoping it was a new essay by Bret. Needs (2011) in the title.

<comment><USER53> Brett victors talk innovating on principal([https://vimeo.com/36579366](https://vimeo.com/36579366)) and more so actually Greg Wilsons talk from the same conf ([https://vimeo.com/9270320](https://vimeo.com/9270320)) marked a pivotal moment for me in my work ethic. It really motivated me to expect better from the tools i use around every day.

<comment><USER54> Similar rxn to those talks. Also, if ever someone knew how to write an "evergreen" post (ie, one that holds up over time), it's Bret Victor.

His "Ladder of Abstractions" is a great example:

[http://worrydream.com/#!2/LadderOfAbstraction](http://worrydream.com/#!2/LadderOfAbstraction)

<comment><USER55> I really enjoy his writing, but I think he has a way to go before he's in the same league as Homer, Plato, Lao Tse, and Shakespeare!

<comment><USER54> haha, those guys sure knew how to write a good blog post!

<comment><USER55> Yup! They got people still clicking on their posts hundreds or even thousands of years later

</comment></comment></comment></comment></comment></comment><comment><USER5> There's a (2011) missing from the title here, at least according to the title graphic.

<comment><USER18> Added now!

</comment></comment><comment><USER56> Tiny grey sans-serif font means you hate my eyes.

Extra-ironic on a rant about interaction design.

</comment><comment><USER57> Seems pretty easy to write an essay saying "screens are old news, let's use our hands!" containing not a single word about how that would work, technically or design-wise.

I'm going to write an essay saying "screens are old news, let's use free- floating holograms like in Iron Man!" with no indication how that would even be possible, and see if I can get on HN.

<comment><USER58> The author of the essay is the founder of [https://dynamicland.org](https://dynamicland.org) which implements what he's talking about in this article.

<comment><USER57> None of the things BV has worked on -- smart tiles or putting pieces of paper under a camera/projector -- do ANYTHING AT ALL like what he's talking about here. They don't change their size, shape, weight, feel etc. in response to data. Because that would be incredibly hard. I don't think you should get points for saying "we should do this impossible thing, that would be better."

I must admit I find BV's writing to be really facile... like he'll compare a piano app on the iPad with a real piano and shit on the entire idea of the iPad... without addressing the obvious point that an iPad can be a million things other than a piano.

<comment><USER43> His point is not about what we should do, it's about what we should _aspire_ to. He's criticizing a video showing a Vision Of The Future, not the current status.

> shit on the entire idea of the iPad

That's not at all what he's doing. He's saying the iPad was the Vision of the Future in _1968_. Now the iPad is here. It's no longer part of the Future, and we should stop talking about it as if it is, because we need to reach beyond it.

> I don't think you should get points for saying "we should do this impossible > thing, that would be better."

When the other contenders at visionaries are saying "we should do this thing that has already been done", saying "we should do this impossible thing" _is_ worthwhile.</comment></comment></comment></comment>


How to Build a Website with Go and API-First CMS Gentics Mesh - g-mesh http://getmesh.io/Blog/How+to+build+a+website+with+Go+and+API-first+CMS+Gentics+Mesh <comment><AUTHOR> I'm a total novice to web design, but I really want to build a website for my training and nutrition consulting business. Based on this review [http://www.webbuildersguide.com/website-builders- reviews/wee...](http://www.webbuildersguide.com/website-builders- reviews/weebly-review/) , I'm leaning towards Weebly. As far as I've got it, Weebly is probably the easiest drag&drop website builder available in the market nowadays.

</comment><comment><USER2> Go is a rising multi-purpose programming language, primarily used for server- side applications because of its speed, concurrency and ease of use. It has a built-in and production-ready template engine and a HTTP server, which makes it an excellent choice for web applications.</comment>


FOXX – A Javascript Application Framework - <AUTHOR> http://www.slideshare.net/arangodb/foxx

<comment><USER2> Seems like a less mature, but hopes to be more serious approach than CouchApps [http://couchapp.org/page/what-is-couchapp](http://couchapp.org/page/what-is- couchapp)

<comment><USER3> It's definitely more serious than CouchApps ;) We concentrate on APIs only – the goal is therefore a little different from CouchApps.

If you're missing something, please ping me via the Issues [https://github.com/triAGENS/ArangoDB/issues?state=open](https://github.com/triAGENS/ArangoDB/issues?state=open) or via email lucas at arangodb dot org

</comment></comment><comment><USER4> For anyone wondering, here is the official site: [http://www.arangodb.org/foxx](http://www.arangodb.org/foxx)</comment>