Why Your Desktop Won't Be Running Mir/Wayland Anytime Soon - <AUTHOR> http://shnatsel.blogspot.ru/2013/03/why-your-desktop-wont-be-running.html <comment><USER2> This post seems to be slightly misinformed about Wayland. I can't say much about Mir as I'm not as familiar with it.

1\. You can use OpenGL, OpenGL ES, Software, etc. to render windows in Wayland and most likely in Mir.

2\. 2D acceleration depends on the widget toolkit and not Wayland. Wayland doesn't do 2D acceleration or need to do so since it is only responsible for compositing windows (which is as fast in 3D). If 2D acceleration is used to draw these windows, it isn't affected by the use of Wayland or X11 in any way. Wayland has a public mailing list that has much more reliable info than Phoronix and LWN.

3\. This is probably the most interesting point raised. Providing xrandr functionality in wayland is much easier than in X11. This is because you have to support a lot of legacy features in X11 that you don't in Wayland.

4 (I added this one) Throughout the article, he seems to assume that no drivers will support Wayland. Wayland was buit to reuse most of the X11 drivers by being able to use DRI2. Mir seems to be able to take this one step further by being able to leverage existing Android drivers (there was a prototype of this in Wayland a while back).

I would like to finish by saying that I agree with the premise but not for the reasons given. The reason you won't see Wayland and Mir in a distro this year is because X11 is tried and tested. You don't replace something that critical to the user experience on a whim: you make sure it works and works for everyone first. Having said that, you will see Wayland and/or Mir faster than you'd expect.

<comment><USER3> I completely agree. Some interesting factoids:

1\. Arch already has Wayland in its official repositories.

2\. KDE already has preliminary support

3\. Intel is driving Wayland development, so integrated cards will likely work without a hitch

4\. Systemd was another large change with lots of FUD, and it's already default in high-profile distros (OpenSUSE, Fedora and soon RHEL 7). Even Canonical's on board.

This article is mostly FUD. I think we'll see a relatively stable KDE on Wayland this year. I doubt the Wayland team is that optimistic, but it's moving at an incredible pace.

</comment></comment><comment><USER4> Speed, to a certain extent, doesn't matter. What matters is intelligent drawing. Double-buffering updates, not showing partially laid-out screens, etc. Software rendering is plenty fast for the relatively simple drawing that makes up a typical application's user interface, and EGL does support the most essential bit of hardware acceleration--bit blit (using the image as a texture).

<comment><USER5> For touch interfaces the lag between input and render is critical, and double- buffering if done wrong can kill you.

Software rendering an opaque rect may be fine, but add in some big semi- transparent overlays and performance drops.

<comment><USER4> Only to the extent that it's not fast enough, which it clearly is given that iOS doesn't hardware-accelerate CoreGraphics. Anything done wrong can be bad, but flicker is really really bad. Pretty much only Apple gets it right in that regard (maybe Jellybean, I haven't used it much).

<comment><USER6> Apple gets it right because they cache prerendered textures so aggressively on the GPU. In this regard software rendering versus hardware rendering doesn't really matter much, since actual rendering happens so infrequently.

</comment></comment></comment></comment><comment><USER7> Point 1 is incorrect: You can use the full-desktop (non-ES) openGL with egl with no problems - just pass 'EGL_OPENGL_API' to eglBindAPI.

I don't know how good the support for this is from different drivers, however.

<comment><USER8> There is also Regal, a library that implements GL on top of GLES2. So it should still be possible even with only GLES2.

</comment></comment><comment><USER9> AFAIK, OS X has been running fine (not super-fast, but acceptable) without 2D acceleration for 13 years.

Also, doesn't Compiz still have some tearing or artifacting during window resize? Wayland is supposed to eliminate that.

<comment><USER10> I'm confused, I thought 2D acceleration was introduced with 10.4. I'm not a Mac user, so I'm not sure, but Wikipedia (<http://en.wikipedia.org/wiki/Quartz_%28graphics_layer%29>) seems to agree.

<comment><USER9> "Quartz 2D Extreme ... still remains disabled by default" Somebody correct me if this is wrong.

<comment><USER11> IIRC, Quartz 2D Extreme (later referred to as QuartzGL) had to do with hardware-assisted rendering/compositing of things like text and certain primitives and, afaik, most of that is still not turned on in shipping OS X and likely never will be. (Again, iirc: it turned out to not provide much benefit compared to the substantial trouble of making the output the same between different video cards.) Perhaps some of that has moved to OpenCL to get the same effect but from a more appropriate layer? I really don't know.

But when you drag a window around or invoke Mission Control, etc, all of that is "Quartz Extreme" (a marketing label that hasn't been used much in a while), which is hardware-assisted and has been since 10.2. Is rendering of the shadow cast by each window accelerated, and if so, how? Again, not sure.

<comment><USER9> I'm pretty sure that I'm using the same definition of 2D acceleration as the original poster. We're not talking about compositing.

<comment><USER12> EXA and XRender (the 2D acceleration in X.org that the original poster is talking about) is just 2D compositing. It is not about drawing line primitives on the graphics card.

No mainstream 2D rendering system (not X.org, not Mac OS Quartz, not Windows GDI/WPF+DWM) uses any graphics acceleration to draw 2D primitives. In some cases, drawing may be done to graphics card memory (to avoid needing to copy to graphics memory later) but that's it (see CALayers on the Mac). The lines and other primitives are all CPU determined. This is still just a compositing layer.

The intractable performance problems of the Mac's Quartz 3D Extreme are exactly _why_ drawing is always done by the CPU -- it is actually faster to do this work on the CPU. You'd link a graphics shader might help but performance metrics prove otherwise.

The article itself is badly confused (on this point and others). X11/X.org has no advantage in this regard.

<comment><USER13> "No mainstream 2D rendering system (not X.org, not Mac OS Quartz, not Windows GDI/WPF+DWM) uses any graphics acceleration to draw 2D primitives."

That isn't entirely true. Windows has Direct2D for graphics and DirectWrite for text after all.

Direct2D and DirectWrite were first introduced for Windows Vista and 7 using Direct3D 10. Windows 8 expanded it using new features found in Direct3D 11.

You can see the high performance and fluid animations it brings in many of the Metro applications. Desktop applications need to migrate their existing code of course. IE and Firefox have done this already.

[http://blogs.msdn.com/b/b8/archive/2012/07/23/hardware- accel...](http://blogs.msdn.com/b/b8/archive/2012/07/23/hardware-accelerating- everything-windows-8-graphics.aspx)

<comment><USER14> And there's no reason we can't have the same kind of library on linux, except one that would render using OpenGL. In fact, if I'm not mistaken, Qt already supports rendering using OpenGL.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I think the author mostly has a point with regards to backwards compatability; however, mobile app development is already centered around OpenGL ES graphics, so I don't see it as a major stumbling block for new code. Of the three points he made, the shift from XRandr to mode-setting sounds like the most potentially troublesome.

There was a presentation on the mode-setting architecture at FOSDEM in February, I'm going to look at it now: [http://www.phoronix.com/scan.php?page=news_item&px=MTI5N...](http://www.phoronix.com/scan.php?page=news_item&px=MTI5Nzc)

</comment><comment><USER16> I think article is completely missing the point. For now MIR is going to use X server as backend. Priority for Canonical is to create single API portable between Android and Linux Desktop. Sure Android compositor will eventually replace X server, but it will be just side effect.

<comment><USER17> I think everything you said is incorrect.

<https://wiki.ubuntu.com/MirSpec>

<comment><USER18> It is. Km looking forward to having to deal with people talking out their ass for months like they did and continue to do about SecureBoot. If you don't understand it, don't comment. Its kinda like how the anti-Wayland falsehoods from the MirSpec doc continue to be parroted. Started from ignorance and perpetuated by it.

</comment></comment></comment><comment><USER19> Re OpenGL: If I understand this <https://wiki.ubuntu.com/MirSpec> correctly, libhybris is what is currently used to cobble together the use of SurfaceFlinger as a compositor for Ubuntu Touch. Ubuntu intends to pull this compatibility with Android's HAL, more specifically the GPU drivers, into mir, which will enable mir to be binary compatible with GPU drivers written for Android, which support OpenGL.

Mir has specific goals for hardware and binary driver compatibility and Canonical has demonstrated proof of concept by using SurfaceFlinger as a compositor for Ubuntu Touch.

<comment><USER9> AFAIK Android drivers support only OpenGL ES, not regular OpenGL; that's the problem he's talking about. As similar as they may be, apps written for one will not run on the other.

</comment></comment><comment><USER20> Screen rotation is probably essential, but is screen resizing? I'm not sure it is. I think we're all just used to it.

<comment><USER21> But this just points out an inherent trait in most software, if you are trying to replace something older, you better _at least_ have feature parity, and some killer feature to drive adoption.

In Wayland, I can easily see the ability to run an X server on top as a motivator, but in the end the killer feature needs to be performance and a tide of new software targeting EGL / WaylandInput insteaf of GLX / XInput.

<comment><USER22> _if you are trying to replace something older, you better at least have feature parity_

Which is why there has been so much fuss. I haven't kept up, but has the Wayland project changed their tune on networkable graphics? I will grant that X could use some uncrustifying, but I think the general gist of the OP is correct: there is just so much that X offers that Wayland and Mir _will_ have to catch up to (assuming they can, which requires not just time and effort, but forward thinking on design and architecture).

And as for performance, my N900, a _four years old phone_ , runs X just fine. The sad experience I have had with software (including OSS), is that the newly born projects are _almost always_ designed without paying attention to efficiency, usually through a lack of awareness because people are so used to fast hardware these days.

<comment><USER21> > has the Wayland project changed their tune on networkable graphics

You mean "provide a flag in ssh to forward a rendered window?"

They were talking about having hooks so a VNC server could act as a compositor for windows that it can forward over the VNC protocol. That would be a much better solution than raw pixel buffers like X forwarding had.

<comment><USER23> X forwarding is just a tunnel for the normal X protocol, which is both higher- level and provides much more functionality than a raw pixel buffer.

<comment><USER21> What extra functionality is available in networked X that is not available over a VNC pipe?

</comment></comment></comment></comment></comment></comment><comment><USER18> That's weird, Weston runs fine on my desktop with nouveau and Intel on my Macbook Air. Oh, and non-Xlib GTK apps too. And apparently Chrome too though I haven't had a chance to confirm this yet.</comment>


Management Isn't a Promotion - <AUTHOR> https://blog.newrelic.com/2016/05/17/engineering-management-different-jobs/ <comment><USER2> I don't know how I feel about the trend of claiming engineering and management is equivalent. Perhaps in pay they are, but the real question is power and except at the very top (CTO/CIO) I doubt engineering has a lot of broad power and discretion. Engineering doesn't cast vision the way management does. Principal Engineer and Sr Director/VP are on paper equivalent jobs, but I wager there are at least _some_ decisions a PE needs Director approval on (where the reverse is never true).

I don't think that's actually a terrible thing. Some people are better at refining others' plans and then implementing; others are great big-picture or ducks-in-a-row planners. There _should_ be multiple tracks for different skillset buckets. But to say they're equivalent isn't really true.

<comment><USER3> Ideally, I think they should be equivalent and both should require buy-in from the other on major decisions. Making management decisions in a tech company without intimate knowledge of what can and cannot be done, and in specific time-frames is ridiculous (in the cases where the decision relies on engineering), just as making technical decisions without intimate knowledge of what the market wants, needs, and will respond to is ridiculous (in the cases where it affects products in the market).

<comment><AUTHOR> Well said, I agree completely.

</comment></comment></comment><comment><USER4> The why does it pay more? Is it because people think it's a promotion? Are the skills for management less "tangible" and harder to adquire? Or maybe it doesn's really pay more and it's just the places i've seen.</comment>


Show HN: Easy magic-link authentication – Cierge - <AUTHOR> https://github.com/pwdless/cierge <comment><AUTHOR> Hi there! Cierge is an OpenID Connect server that handles user signup, login, profiles, management, social logins, and more. Instead of storing passwords, Cirege uses magic links/codes and external logins to authenticate your users.

You can find a good list of FAQs on our our GitHub page or try a demo here: [https://cierge.azurewebsites.net](https://cierge.azurewebsites.net)

<comment><USER2> nice! I like that it's even done in dotnet!!

Does it support active directory for an external out of the box?

<comment><AUTHOR> Sadly nothing out of the box for AD. However, Cierge uses OpenIddict, so this might be helpful: [https://stackoverflow.com/questions/38470683/is-it- possible-...](https://stackoverflow.com/questions/38470683/is-it-possible-to- use-openiddict-and-ldap-together)

<comment><USER2> awesome! thank you very much!</comment></comment></comment></comment>


Thank HN: Image Processing for Everybody - <AUTHOR>

Thanks to the feedback through HN we are proud to announce a first update (ImagePlay 6.0.0-beta.4 [1]) fixing bugs [2] discovered by you guys. Enjoy!<p>[1] http://imageplay.io/#download [2] https://github.com/cpvrlab/ImagePlay/blob/master/changelog.md <comment><AUTHOR> [http://imageplay.io/#download](http://imageplay.io/#download)

[https://github.com/cpvrlab/ImagePlay/blob/master/changelog.m...](https://github.com/cpvrlab/ImagePlay/blob/master/changelog.md)</comment>


An nginx.conf for 2017: HTTP/2, IPV6, HTML5 SSE, load balancing and more. - <AUTHOR> https://certsimple.com/blog/nginx-http2-load-balancing-config <comment><AUTHOR> Author here!

Biggest discovery when researching this was due to the ALPN requirement in Chrome [1], openssl 1.02 being required for ALPN, and the vagaries of Linux distro release schedules, Ubuntu 16.04 is the only LTS distro than can serve HTTP/2 to Chrome users.

When they're eventually announced, RHEL/CentOS 8 (Fedora already has the necessary openssl) and Debian 9 will also work. But right now Ubuntu is your only bet unless you want to build and maintain your own openssl. Which you don't.

[1] [https://bugs.chromium.org/p/chromium/issues/detail?id=527066](https://bugs.chromium.org/p/chromium/issues/detail?id=527066)

<comment><USER2> For Debian 8 (Jessie): There's a newer build of Nginx in jessie-backports with static OpenSSL 1.0.2: [http://serverfault.com/questions/775298/debian-jessie- nginx-...](http://serverfault.com/questions/775298/debian-jessie-nginx-with- openssl-1-0-2-to-use-alpn-rather-than-npn)

<comment><AUTHOR> Interesting. What's the maintenance policy for jessie-backports? If it's best- effort it might be better to avoid suggesting people use it for a package as frequently updated as openssl.

<comment><USER2> It is indeed best-effort. You can follow along on packaging in [https://packages.qa.debian.org/n/nginx.html](https://packages.qa.debian.org/n/nginx.html) and [https://packages.qa.debian.org/o/openssl.html](https://packages.qa.debian.org/o/openssl.html) as well as backports' security mailing lists.

Given what I'm seeing on the Nginx build currently in backports, I might rely on backports for dependencies, but I'd seriously consider building your own Nginx from source and/or pay attention yourself to security warnings.

</comment></comment></comment></comment><comment><USER3> the configuration they provide is wrong on many things

1/ it says "An nginx config for your first million users",

but: worker_connections 768;

2/ html5-sse.conf:

proxy_buffering off;

bad idea for a loaded server / backend

proxy_cache off;

will enable proxy_cache, which is not defined anywhere, so this will actually fail to validate - and proxy_cache is already disabled when you're doing proxy_buffering off;

3/ https.conf:

resolver 22.214.171.124 18.104.22.168 valid=300s;

bad idea to trust anything but a local resolver, why do you trust internet to tell you IP addresses where you will go for ssl stapling info?

<comment><AUTHOR> 1/ The article doesn't claim to support one million concurrent users. Top level directives are Ubuntu/RHEL defaults, but if you have a preferred scalability config please file an issue!

2a/ buffering is well known to break SSE. As the article notes, if you're not using SSE you should disable that include.

2b/ I thought the config parser would have caught this but didn't. Filed [https://github.com/certsimple/nginx-http2-load-balancing- con...](https://github.com/certsimple/nginx-http2-load-balancing- config/issues/1) and fixed.

3/ If you think your own DNS server is going to be better maintained than Google's, sure. But not everyone else would.

<comment><USER3> 2a/ ok, I misread what was the intention, maybe it's a good idea then

3/ it's not about "better maintained", it's about trusting the internet on sensitive data, which you should never do, because dns is easily spoofed and nginx resolver was not written to operate in a hostile environment. if you don't have a local caching resolver on your machine (which you should), even trusting your cloud provider dns is better than trusting goog one. nginx documentation even says " To prevent DNS spoofing, it is recommended configuring DNS servers in a properly secured trusted local network. " on [http://nginx.org/r/resolver](http://nginx.org/r/resolver)

<comment><AUTHOR> You're right: checking this out further, the nginx resolver seems to have a bunch of issues [1] which is concerning.

I've modified the config accordingly.

[1] [http://blog.zorinaq.com/nginx-resolver- vulns/](http://blog.zorinaq.com/nginx-resolver-vulns/)

<comment><USER3> Yep - the warning clause in the documentation is there because of those issues.

thanks!</comment></comment></comment></comment></comment>


WeWork-owned Meetup confirms restructuring, layoffs - <AUTHOR> https://techcrunch.com/2019/11/04/wework-owned-meetup-confirms-restructuring-layoffs/ <comment><USER2> Meetup has gone from a place where you could actually find people who shared your interests and to develop long-term friendships, to a place where lonely singles try to find love or a one-night stand, or you can go to "profesional tech meetups" where companies try to hire you under the guise of sharing interesting tech experiences.

</comment><comment><USER3> Does anyone have better alternatives to meetup? Apart from the salesy events I still find plently of good events. I use it for pickup tennis games, hiking groups and the off data science meetup.

</comment><comment><USER4> After they restructured their payments so anyone that RSVPs to a meetup needs to pay $1, I don't think the site will last much longer. They should have fired the person that made that decision.

<comment><USER5> > anyone that RSVPs to a meetup needs to pay $1

Not sure what you mean by this. Article doesn't mention anything like that, and it's definitely not a current feature.

<comment><USER6> Reported as a "trial" strategy recently. [https://www.theverge.com/2019/10/15/20893343/meetup-users- fu...](https://www.theverge.com/2019/10/15/20893343/meetup-users-furious-new- rsvp-payment-test)

<comment><USER5> Well that's patently stupid. Hard to believe more than 5% of attendees would be willing to pay a penny for a signup.

Also, the $200M valuation is bonkers, there's no moat and no reasonable earning potential. Meetup should be a small scale self-funding service.</comment></comment></comment></comment>


Houston: "In 18 Months, You Are Going To See Little Dropbox Buttons Everywhere" - <AUTHOR> http://techcrunch.com/2011/11/05/founder-stories-houston-dropbox-buttons-everywhere/ <comment><USER2> This trend worries me. We're starting to see a collection of "sealed apps" that only explicitly support specific cloud-based services instead of connecting to the local machine's operating system or managing services. Facebook becomes popular and then we start seeing sites that only take a Facebook. Dropbox becomes popular and we'll start seeing apps that treat Dropbox as their only filesystem. What happens to those of us that like basic authentication and filesystems that don't run through centralized, closed platforms?

<comment><USER3> That's the point of these moves, and it seems to me that the stable equilibrium is one of consolidation of these services due to strong network effects. The alternative seems to be something similar but without lockin - some sort of interoperable open standard that anyone can build to? You probably need a very powerful almost-monopoly-level company (ie Google, Microsoft in the 90's) to commoditize all of this stuff with open, interoperable standards/software. Too bad Google seems to be pulling back inside its walls recently, with all of its culling of the unprofitable arms of its business.

<comment><USER4> I think WebDav could be part of that answer.

Imagine that I configure a webdav server (dropbox, one on my own server, whatever) on each of my devices once, and have a 'my cloud' button on sites, in apps, etc instead of a 'Dropbox' button.

<comment><USER3> The interoperable solution needs to be easier to set up and/or much cheaper than Dropbox/Facebook/etc. though. Any interoperability standard will have to be obvious to normal people to have a hope of being a real selling point and make people strongly averse to signing up for a non-interoperable service, and WebDAV doesn't seem to be anywhere near there.

<comment><USER4> I think you are missing the 'part of' part. To get an interoperable solution for cloud storage, you need a shared protocol for cloud storage, but

a) it the only thing you need.

b) I do not see why the normal users would have to be able to set up a server providing the service. Normal people do not run a mail server or know anything about POP or IMAP, but they can (sometimes with a little help from their email provider) set up er devices to work with any email provider.

If WebDAV were as wide-spread as POP and IMAP, we could have a world where, say, an iPad had a setting where one entered the URL of a WebDAV provider, a user name and a password, and the iPad apps then use that dropbox by default instead of hard coding a way to connect to DropBox.

Having an easy way for people to set up a WebDAV server at home would help getting there, but isn't strictly necessary. What is necessary is that a significant fraction of cloud storage providers agree on a protocol. For that to happen, I think those providers must feel threatened by a large provider (or maybe not; IIRC, Dropbox already has WebDAV support)

With that in place, the final step would be to get device OS manufacturers to support that user setting. That might be the largest stumbling block.

<comment><USER3> I think that in order for interoperability to happen, interoperability needs to be a visible and well known feature. If it's not, a market leader has little incentive to make it easy for people to migrate to their competitors.

But if Dropbox already supports it, like you say, maybe it'll actually happen. Now we need to find the WebDAV for universal login - OpenID in its current form is pretty clearly a failure at this point.

<comment><USER4> Yes, that is why I think it would require a sufficiently large part of the market to be afraid to be on the losing side that could make them combine their strengths.

As to that Dropbox WebDAV support: I just checked, and unfortunately, I was wrong (<http://www.dropbox.com/help/62>). There is third-party WebDAV support for dropbox (dropDAV.com), but that, IMO, barely counts.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> That transcript should, you know, get cleaned up. You know, to remove filler words:

      And Making, you know, delivering on that at a much bigger
      scale. Working with, you know, great partners like HTC. And
      other folks and developers to help, you know, put Dropbox,
      you know, help, you know, where Dropbox can help make, you
      know, all these other products better.

<comment><USER6> The worst part is, transcriptionists usually leave out filler words during the transcription process unless they're specifically told to transcribe "verbatim". It's not like the transcript needs to be cleaned up after the fact, it probably could have been transcribed that way in the first place. Unless it was an automated speech-to-text transcript in which case my observations are irrelevant.

<comment><USER7> A buddy of mine is a journalist and this is routine in that profession as well. Of course, as TC is fond of explicitly reminding us (verbatim!): they aren't journalists. Neither transcriptionists, either, apparently.

<comment><USER8> CaptionBox is a SaaS provided by SpeakerText (speakertext.com). They don't transcribe themselves.

<comment><USER7> Eh, they hired 'em. The words are appearing under the TC masthead.

</comment></comment></comment></comment></comment><comment><USER9> I was wondering the same thing as Eric when he asked about "everything is already on the cloud". Not sure if I'm really convinced that Dropbox can thrive in a post-filesystem world, but Drew's awesome so I'm sure they have some secret-sauce plan.

(reposting from TC article)

<comment><USER10> Taking "everything" literally, most of us still have stuff on our harddrives, even among the earliest of adopters, let alone the mainstream (where the actual money is).

The post-filesystem world will occur with or without dropbox - but someone will lead it and make a bunch of money, and dropbox is well-positioned to be that leader.

After the post-filesystem world has fully arrived (which will take a few years), it will settle down and become commoditized, and dropbox (or whoever led) will only be making residual profits - but there's nothing stopping them and partners from adding features and benefits, and innovating atop the platform (e.g. the developers mentioned in this article).

</comment></comment><comment><USER11> >But will Dropbox's strategy be strong enough to fend off popular sites like Instagram and Twitter, which also store digital content submitted by large user communities? Or put more bluntly "five years from now, will I even need Dropbox?" asks Schonfeld.

I'm not sure it's fair to compare Dropbox to something like Twitter or Instagram. I think they only store photos, while Dropbox can store whatever files you need it to. I'd say the majority of people would probably store photos and videos, but there are some who like to back up important documents, books, and other work.

</comment><comment><USER12> Considering my use of NoScript and RequestPolicy I bet I won't.

</comment><comment><USER13> I think it's entertaining how Dropbox assumes that customers prefer to throw everything into one place instead of "siloed" data. When I choose to open the Facebook/Twitter silo, I am being social, when I open the MS Office silo, I am being productive. As much as I'd like to churn out code while browsing my friend's status updates, I don't. Dropbox needs to focus on making their service easy-to-use and invisible to people who don't care to see how it works. Making something well-known and well-seen does not make it well- adopted.

<comment><USER7> _Making something well-known and well-seen does not make it well-adopted._

No, but neither does being invisible.

</comment></comment><comment><USER14> This is the worst piece of interview footage I've every seen. Why is the interviewee shot at the profile? Why do I care to see the interviewer head on?

I stopped watching after the second zoom in on interviewee.

<comment><USER15> Yeah it's pretty bad, they break a lot of rules I learned in Film school.

</comment></comment><comment><USER16> Am I missing something obvious? What would you do with this Dropbox button that is going to be everywhere? OK, I can think of a few instances when I would want to send something directly from the web to my Dropbox, but I can't actually imagine that it would be so often it would change the way I interact with the product.

<comment><USER17> There are a number of iOS apps that make use of Dropbox as a backend storage service and I imagine dropbox buttons in apps would do something similar: anywhere you have an app that needs to store photos or documents they link to your dropbox account to give you an easy in/out method of moving data around.

<comment><USER18> Yeah we are using Dropbox as syncing / backup in our iOS and Mac budgeting apps currently. To his(Houston's) point, you set it up and then if you throw your phone in the river it doesn't matter. Go get a new phone and you have all of your data.

As space continues to get cheaper, I could see using Dropbox exclusively for storage at some point in the future. Not just a few things I want backed up, but storing everything there. Then any computer I pick up has everything I could ever want or need. Currently it's far too expensive for me to do that though. That is where the real power to "having little Dropbox buttons everywhere" would be for me.

</comment></comment></comment><comment><USER19> Great idea -- "add to dropbox" buttons, but 18 months--seriously?

<comment><USER20> Ya, I hope it doesn't take that long for them to implement. Keep in mind that the interview started out with Erick asking Drew:

 _What do you need to do in the next 18 months months, to not squander this opportunity._

So Drew may have just been responding to this later question in the same context.</comment></comment>


Ask HN: how much does it cost to crawl 1M sites? - <AUTHOR> What is the cheapest api or other solution ? How much more does it cost to crawl sites with javascript ?<p>thx <comment><AUTHOR> I think i made an unclear/wrong question. I wish to crawl about 1M pages (rather then sites)

so 1M http get requests.

I was hopping there would be some solution for 100$ lets say

<comment><USER2> $0. Crawl from your computer at home.

</comment></comment><comment><USER3> Depends on which sites. Some of my websites have 200K pages. Some have just three.

<comment><USER4> Also depends on what you want to do when you crawl them. I guess if it's a million sites it is going to be median distribution of number of pages. But I don't know that information is available anywhere. I think the http archive used to tell you the number of pages on sites, but now it just tells you page sizes.

[https://httparchive.org/reports/state-of-the- web?start=lates...](https://httparchive.org/reports/state-of-the- web?start=latest&view=list)

of course page sizes might also be important dependent on how you crawl and what you do with the data.</comment></comment>


Parallax Demo - <AUTHOR> http://davegamache.com/parallax/

<comment><USER3> Well, not exactly.

You made the fatal UI mistake --and by fatal I mean absolutely unusable for a great % of users-- of tying your viewport scroll to a fixed incremental +1 tick on the scroll wheel. If a user is using a MacBook touchpad, it's way, way, way faster than a user using a mouse or scroll-wheel, or any other custom scrolling device.

Here's an example of a site doing it the right way: [http://www.spaceneedle.com](http://www.spaceneedle.com)

The key is to ALWAYS normalize your scroll, regardless of platform or device. Not only does it make your scroll values uniform, it provides a much smoother experience for the user.

The way this has been historically solved is to capture the mouse scroll tick, and then apply a multiplier on the expected result to induce easing, and then pipe that result into the scroll position of your container. All of this should take place within a requestAnimationFrame.

In JavaScript it's as simple as

position += (targetPosition – currentWindow.scrollTop) * easing // generally between 0 and 1

This classic inching equation is your friend!

If you were to revise your demo by implementing the above (about 5 minutes of work) it would look absolutely phenomenal.

<comment><USER4> yes, the scrolling was unbearably slow on my computer (ubuntu + chrome).

The cool thing about that space needle example was I could middle mouse button scroll with momentum too.

The middle mouse button does nothing on the posters example, so that's another feature to add.

<comment><USER5> Middle mouse button works fine in Firefox on Windows 7 for me.

</comment></comment></comment><comment><USER6> Parallax... that word does not mean what you think it means.

These are just fancy scroll effects. Parallax would have been things in the background moving slower than things in the foreground. Your background is simply static.

</comment><comment><USER7> Wait, you mean there's more to that page than a single still image (with title overlay), and it was a broken flash/overly-fancy-javascript that it looked[1] like?

/me checks again after reading this thread.

WOW. That's horrific. Not only does it give ZERO indication that there is actually _content_ there besides a background image/title.

The scrolling is not only bad per-click the z-axis mouse buttons, as cnp said. This same nonsense makes Page{Up,Down} only "scroll" (advance the animation) like an inch. In fact, the only way this even seems to approach "usable" is if you hold down the key for autorepeat, which gives it a constant "frame-rate".

This type of intro is yet another example of a style of design that _really wishes_ the web/HTML wasn't a "document" with hierarchal markup, and try to force movie/tv style over how it is seen.

As others have said - should have just been if a flash intro/video instead.

From the end: "Really, anything is possible …"

Ok, I made the zombocom reference in a reply below before seeing that - now I almost wonder if this is some sort of waaaaaay-too-subtle parody or something?

[1] _Extra_ broken, because the site detects browser width and overlays the ENTIRE PAGE with a black screen that says:

"Whoops! Right now this demo doesn't handle resizing or browsers less than 1000px wide. Reload this page or get on a laptop!"

So because a potential source of layout problems, such as my browser in a portrait-mode-like aspect ratio and too narrow for the background image, it's better to slam the door so the user sees nothing? How nice. If I'd seen the "broken" version, I might have had to _drag my window a bit bigger_. Or how about "background: center 100% no-repeat fixed url(...);"?

<comment><USER8> Hey - thanks for the feedback. For what it's worth, it's a demo. The entire point was a "quick" demo for the Medium post that I wrote about creating performant parallax sites: [https://medium.com/@dhg/82ced812e61c](https://medium.com/@dhg/82ced812e61c)

I totally understand the demo is limited in its implementation, but the point was never to be a perfectly polished site. It was to demonstrate the ability to achieve smoother animations tied to scroll.

That said, perhaps it was shortsighted of me to assume it wouldn't be judged on all platforms/devices/OS's.

</comment></comment><comment><USER9> Ironically, there is barely any parallax on this website, just scroll-based effects...

<comment><USER10> I find that the term "parallax" is largely used to just mean scroll base affects in certain contexts now.

</comment></comment><comment><USER11> Like most parallax, pretty much unusable on a trackpad without scrolling at 100 flicks/second.

<comment><USER8> Hey - I just halved the scroll distance. Unfortunately, I didn't have anything to test on except a MacBook since I'm traveling. It sounds like the scroll ratio to movement was too small...perhaps now it's a bit more friendly.

</comment></comment><comment><USER12> Why not just have a flash intro?

<comment><USER13> This pretty much nails the obnoxiousness of parallax scrolling sites. It looks super cool from an aesthetic viewpoint, and these transitions are gorgeous, but as a user I just really fucking hate it. Parallax is the modern web's gaudy Flash interface.

<comment><USER7> You can do _anything_ with a parallax scrolling intro! Anything at all - <USER2> only limit is yourself.

With a parallax scrolling site, you can to _anything_. The infinite is possible with parallax scrolling! The unattainable is unknown using parallax scrolling!

</comment></comment></comment><comment><USER14> This feels exactly like the kind of thing we will look at in a few years and say "How 2014."

</comment><comment><USER15> In response to users calling this a Macbook-trackpad-only approach: this felt horrible on my MBA. I could only get through an animation in one go with a forceful swipe (the kind of maneuver I _never_ use during casual browsing). Fellow designers, heed my plea: don't do this, ever. Having some subtle animations happen as I casually scroll is one thing, but this is a usability nightmare. I shudder to imagine what this experience must be like with a scroll wheel.

</comment><comment><USER16> How "right" can it be with zero Mobile support?

</comment><comment><USER17> Not everyone browses the web with a MacBook trackpad.

</comment><comment><USER18> "Whoops! Right now this demo doesn't handle resizing or browsers less than 1000px wide. Reload this page or get on a laptop!"

</comment><comment><USER19> It took me over 20 seconds to get through that.

20 seconds of parallax = 20 parsecs

That's even more than the Kessel Run.

</comment><comment><USER20> It's fun how non-smooth these designed-for-Macbook-trackpads sites are with anything other than a Macbook trackpad.

<comment><USER21> As a user on a MacBook Pro... it wasn't smooth. Inertial scrolling speedup causes problems, at multiple points I 'stopped' partway through animations.

It's a pain. Don't do this stuff, it just makes things worse. If you want to do this make them work like separate screens so that scrolling doesn't work, you can only click to navigate.

Computers have been training me on what a scrollbar does for 20+ years. _DON 'T_ try to change it now.

</comment></comment><comment><USER22> I'm on a 1920x1200 display running chrome full screen, and it says "Whoops! Right now this demo doesn't handle resizing or browsers less than 1000px wide. Reload this page or get on a laptop!"

I don't think this counts as Done Right.

</comment><comment><USER23> I think parallax done right would actually work on a mobile phone. Parallax effects make a lot of sense on a mobile phone that physically changes it's angle based on your motion. Not including mobile is wrong right out the gate, IMO.

</comment><comment><USER24> Good attempt but still very jumpy during transitions and going back and forth causes elements to be misaligned. I'm using Chrome.

</comment><comment><USER25> Very cool but the "Share with Twitter" button doesn't contain the URL of the page. Just FYI.

</comment><comment><USER26> Well, this was not smooth at all on my trackpad.</comment>


'I'm Rich, but I Understand the Frustrations People Have' - <AUTHOR> https://www.theguardian.com/politics/2017/apr/15/steve-hilton-im-rich-but-i-understand-the-frustrations-people-have <comment><USER2> I was once asked by someone who is rich to "define rich"... because they felt that they were not rich.

My definition is "If you can solve a problem by throwing money at it, then it isn't a problem"... that's when you are rich.

Think about the difference between poor and average and rich. Poor people try to skip things like car insurance and health insurance. Average people budget for car insurance and get health insurance through their job. Rich people put up a bond for insurance (thus paying no premiums) and have a health "concierge" who arranges visits to doctors who are "on call". Rich people can pay for these services because they don't pay house insurance (if the house burns down you buy another), car insurance (put up a bond), car expenses (company pays), travel costs (company pays), taxes (stock, investments, tax write-offs), etc. Rich people don't have bank accounts, they own the bank and makey money by lending money.

Problems in life treat us all the same. Your window breaks (poor: cardboard and duct tape, average: call a window repair place, rich: the housekeeper deals with it), your sink leaks (tape, plumber, housekeeper), car won't start (bum a ride, call AAA, your driver handles it), etc. Rich people just throw money at the problem by paying people to solve it.

The only problems rich people have are ones that money can't solve, such as demands on their time and persistent health issues. What poor and average people don't realize is how much demand there is for a rich person's time. Companies want you on their board (so they can get connections to your other board member companies). People want you to show up for charity events (so you can write a check). People want to give you perks (first class lounges so you buy first-class seats). Ultimately under each benefit is some attempt to get money.

Ultimately though, money can't solve certain problems such as health issues or the death of friends and relatives. Or time issues, such as being given an award (so you have to show up), or asked to give a keynote speech (so you have to show up), or being hounded by reporters who want to know how the rich and famous live.

So how do you know if you are rich? If you can solve the problem by throwing money at it and you do... then you are rich.

<comment><USER3> That seems like a reasonable division into three strata. You could divide it into a lot more than three. Each movement upward leaves one set of problems behind and may introduce new things that would not have been realistic considerations before.

I'm 'average' in your classification, as are most people I see on any regular basis. What you've called 'poor' would describe the time I was unemployed or my college days but is now a fair ways away. What you've called 'rich' seems impossibly out of reach barring some unlikely windfall.

Within 'average' though, there are upward movements that would be nice. I've paid off all loans except my mortgage. It would feel pretty great to pay off the mortgage and not owe anybody any money.

I live in a moderately expensive city. It would be great to feel like I could just move somewhere more expensive like New York City or San Francisco if I wanted to, own a home, and take advantage of the opportunities there.

It would be interesting to see a description of many strata from someone who has researched this, and see what problems are solved and what people's main concerns are at each one.</comment></comment>


Show HN: Work Club – come work with us at coffee shops around the SF Bay Area - <AUTHOR> https://outofoffice.app/workclub <comment><AUTHOR> Hey guys, Dave here from Out Of Office. At Out Of Office we're a 100% distributed team, so we're aware of the pitfalls of working remote. It can be isolating, lonely, and often times hard to start the day. That's why we started Work Club - our way to get a little extra motivation to get out of the house and start the day.

It's super simple: sign up for work club notifications, find out where other people are working, show up, get your stuff done.

We host 1-2 Work Clubs a week at cool places in the SF Bay Area (coffee shops, breweries, co-working spots). You can sign up to be notified of future events, or if you're interested in hosting your own Work Club, you can send me an email (contest details in my HN profile). Hope to see you there!</comment>


OVH sales lockdown over: no longer a budget box host - <AUTHOR> http://www.soyoustart.co.uk/

<comment><AUTHOR> Although that is a pretty good deal. Shame about the Kimsufi's though, very useful things they were.

<comment><USER2> Their Kimsufi line is still very much alive at [http://www.kimsufi.com/fr/](http://www.kimsufi.com/fr/) \- there's a 10 Euro install fee, but otherwise they're still just as cheap as they always were (more or less).

<comment><AUTHOR> Très intéressant! I wonder why the UK domain is being sent to the new range...</comment></comment></comment>


Major unsolved problems in theoretical computer science - <AUTHOR> http://cstheory.stackexchange.com/q/174/7013

<comment><USER2> Discussion from two days ago: <http://news.ycombinator.com/item?id=3541932></comment>


Zombie Cookie: The Tracking Cookie That You Can't Kill - <AUTHOR> http://www.propublica.org/article/zombie-cookie-the-tracking-cookie-that-you-cant-kill?utm_source=et&utm_medium=email&utm_campaign=dailynewsletter&utm_content=&utm_name= <comment><USER2> I assume the major trackers (Google, Facebook, etc.) are probably using this, browser fingerprinting, something like evercookie, and a few other tricks I don't know yet. They're also probably buying data through back-channels you can't block, e.g. server logs from major news sites. But I'm just some nut-job in a tinfoil hat. Would any people here with actual first-hand knowledge care to share?</comment>


Linus Torvalds won't do github pull requests - <AUTHOR> https://github.com/torvalds/linux/pull/17#issuecomment-5654674 <comment><USER4> Fun Fact:

If you tack '.patch' onto the end of a Pull Request you get a 'git am' compatible patch file complete with the email address that Linus complains is missing ;)

<https://github.com/torvalds/linux/pull/17.patch>

EDIT: I should note this works on any _commit_ as well. Take this commit from Casbah (the Scala MongoDB driver I work on) - [https://github.com/mongodb/casbah/commit/990a36fbde69db26689...](https://github.com/mongodb/casbah/commit/990a36fbde69db26689b9bcf680719928f6c11c8.patch) \- removing .patch gives you the normal web based github commit page.

<comment><USER5> Great! Didn't knew that! How did you get to know that?

<comment><USER6> IIRC they had a blog post about it at some point. You can also add .diff to get a slightly different format.

</comment></comment></comment><comment><USER7> The man wrote git for use on the Linux kernel. Trying to argue with him about how to use git with respect to your tiny patch to the Linux kernel seems... like missing the point on a great many things. The rules for submitting kernel patches are laid out in great detail. Do you really thing arguing with the gatekeeper is going to change anything?

<comment><USER8> I think people are arguing for two reasons:

1.) Linus is being a bully. There's a difference between speaking your mind openly and using rhetorical force to invalidate contrary views.

2.) The kernel requirements can be whatever those who control the kernel demand. That's just common sense. Making the leap to declaring that only one text wrapping approach is objectively correct is delusional.

If Linus simply said "The github pull request interface makes it impossible to follow the kernel commit guidelines, and we are not open to reconsidering those guidelines" there'd be no argument.

<comment><USER9> 2\. He clearly stated his reasons why his text wrapping approach is objectively superior (not correct). If you think he's delusional, point out the criterion he has failed to consider, or explain how some other system meets any of his criteria better.

In response to the pull request he did simply say "I don't do github pull requests." and explained why, and basically said he would if github supported commit messages in the appropriate style. He never insulted the pull requester. He called whoever is this "Joseph" person a moron, and now we have no idea why.

<comment><USER10> Apparently "Joseph" deleted his comment (very un-git-like of GitHub to make deleting a comment without a trace so easy). I checked all the other participants above where "Joseph" posted and found a Dan, but no Joseph.

<comment><USER11> Reddit[1] found the "Joseph" in question, his comments are still visible in his public activity stream: <https://github.com/pirtlj>

[1] [http://www.reddit.com/r/programming/comments/tionj/linus_tor...](http://www.reddit.com/r/programming/comments/tionj/linus_torvalds_doesnt_do_github_pull_requests/c4n49r8)

<comment><USER9> Thanks, good find!

So, if @pirtlj said that in response to Linus's first comment, then he was way out of line, and something should have been said. Maybe Linus didn't say the exact right thing, but I doubt I would have been able to say much better. Hopefully @pirtlj learned more than that he shouldn't have said anything (although even that would be a good thing, I think)

</comment></comment></comment></comment></comment></comment><comment><USER12> I don't mean to be overly critical, but is it just me or are the 'godfathers' of computer science starting to sound like cranky old men?

I mean....ok....this pull request being inferior to the way HE (the creator of Git) imagined it (or implemented it) is a bit petty imho.

What's with the complaining? I am sure this is not the first time I have heard him complaining about something on Github or some other 'new technology'. The same goes with Crockford and his semi-colon.

Edit: Although, I must confess that it is annoying when the creators of a service that you use totally blow off your suggestions (esp. when that service is built on your own creation).....so I am torn on this one. Still has the 'annoying old man complaining feel' to it though.

<comment><USER13> It's all about context. To someone who only knows PHP the opinions of most polyglot programmers seem cruel and elitist. Put me in a room full of Moodle developers and everyone will come away thinking of me as "that cynical guy who is always trashing everything we do".

Are people so averse to acknowledging the bounds of their own experience that they discount other views over a hint of emotion? Does every cantankerous remark need to be taken so personally? Why is it so important to be inoffensive? Does all advice need to be delivered as positive encouragement?

<comment><USER12> I think it is subjective - unfortunately.

With a bigger microphone comes greater responsibility.

I am not taking Github's side on this particular issue - but this issue struck a bigger tone (for me)...where I have seen those with a larger microphone (by virtue of who they are) seem to be complaining louder (publicly) in recent history. It could just be that their microphone has gotten louder - but if it has, to a large extent they have a responsibility to be more conscious.

Imagine if Obama complained about the food at a bakery down the street that he went to - that would effectively kill that establishment. As a patron, does he have a right to complain about disgusting food? Absolutely...as someone with the largest pulpit in the world? Definitely not. There are other means he could use to get his message across.

Then again, I am not comparing Obama's pulpit to that of Torvalds, but I think it makes the point sufficiently.

<comment><USER13> Yes. Opinions, passionately delivered, will correctly be perceived by some as inflammatory or unfair.

Each observer can decide if the remark is appropriate or not. We are more likely to forgive Linus on his "home turf" than Obama singling out a particular business.

This highlights the problem, not everyone thinks critically about context so you end up with people writing off good practices because the advocate was mean and/or avoiding a bakery because the president complained.

</comment></comment></comment></comment><comment><USER14> Man, now I feel like a total hack. I love the github pull request. I do insist that my devs use a good style (i.e. first line is a summary and wrap at 80 chars) but I love the user interface for looking at diffs and doing a code review. I had no idea it was inferior until reading this and now I find myself in the awkward position that I don't care. Have I really become the guy who values an efficient team process more that adherence to esoteric specifications. God, I can't believe it's come to that.

<comment><USER15> The pull request as a mechanism for "here are some changes to look at" for a small project isn't the same thing as "Here are the USB stack changes for the 3.4 merge window".

The kernel has a mature, rigorous and well-defined development process[1]. Things that don't fit well into that model just aren't going to be successful, even if they work well in other contexts.

[1] [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git...](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=Documentation/development- process)

<comment><USER15> It's also worth pointing out that the "pull request" in question here was a 2-liner addition of a USB device ID that should have gone to a subsystem maintainer anyway.

</comment></comment></comment><comment><USER16> I don't understand why people are upset with Linus's writing style. I considered what he wrote to be quite polite. He was merely stating his standards in terms of what he would and wouldn't accept (and github pull requests are on the "won't accept" list). He even explained why he wouldn't accept it.

Furthermore, the patch was deficient in other ways. (a) it was missing the Signed-off-by: header, and (b) it should have been sent to the linux-bluetooth mailing list or one of the Bluetooth maintainers, with the linux-bluetooth mailing list cc'ed.

<comment><USER17> I think it was comments like "The fact that I have higher standards then makes people like you make snarky comments, thinking that you are cool.

You're a moron." that people thought impolite. The comment he responded to appears to have been deleted, however, so I can make no judgement about how appropriate that was. I'd like to think it was completely appropriate -- I do agree with you overall that his other comments were reasonably polite.

<comment><USER18> I don't remember the exact wording of the comment that was deleted, but I did see it and I remember it making me feel very angry, despite that I wasn't even involved in the discussion. My personal belief is that Linus' response was quite classy in comparison, especially given that others in the conversation weren't stepping up to take issue with the comment.

</comment></comment></comment><comment><USER19> It's instructive to read Linus's commits to his hobby project "subsurface":

<https://github.com/torvalds/subsurface/commits/master>

Even if I can't code like Linus, I can at least try to write commit messages like his…

<comment> why-el It always puzzled me why his commits (and in fact standard commits) ought to start with a verb that is not in its past form. When I started using git four months ago (such a newbie), I would write something like "Fixed this" instead of "Fix this". Anybody with more insights on this? I am just curious.

<comment><USER20> If you think of the change set as the subject, so the question is 'what does this do?' and the answer is 'fix X' then it makes more sense. Past tense suggests you might be thinking of it as a journal or something that you're not supposed to do with git due to rebase etc.; each commit ought to stand on its own.

That said I don't think this is significant enough to add up to a compelling reason either way.

<comment><USER21> Sorry, pardon the ignorance, but how does past tense imply something that would be affected by rebase? It may not be linear history, but it definitely happened in the past. I guess I always looked at more as: "here's a patch", "what did you do?" If it's just a tomato/tomato thing (yeah, that doesn't come out well in text), just let me know.

<comment><USER20> Because rebase, and rebase -i especially, gives you the ability to break your patches into discrete this-one-one-goddamn-thing patches (which is awkward in a "oh, you committed it? Then you committed it forever" SCM like Perforce or SVN), you should do so. It makes it a lot easier to review than the "so this does X, but also fixes some syntax errors and adds logging" style. And that means you should make the patch comment reflect what it is doing. Some errors here are inevitable but it's something to which I aspire.

Edit: to be a little clearer; your traditional SCM has a write-once-never- change model for the trunk of development. This has a problem in a peer review situation, and the problem is this: I may go forth with the best of intentions to decompose things into discrete patches. But when you get down to brass tacks, changes to the system tend to happen in any given order--you might discover a latent bug when testing your feature that has nothing to do with your feature. Now you have two choices: you can wait and commit nothing until everything is great, which means you're not integrating with the mainline, which means that integrating will be incredibly painful, which leads to locks; or you commit as it comes in the moment, which is much better for integration and much easier to back out partial changes and generally get all of the non- backup elements of an SCM, but which is the very devil to peer review. With rebase -i, it is quite easy to commit in the second style _in the moment_ and then clean them up for peer review later; that is the ability to revise history means you can make decisions immediately without worrying that they will be cast in stone forever and ever anon.

I wasn't always this much of a hardliner on the subject, but my current job uses Perforce as the main SCM and I have realized that I disagree with almost every decision Perforce makes across the board. I still use it, because any SCM is way better than no SCM and I don't want to explain git to everyone else, but my actual development occurs with git-p4.

<comment><USER21> Thanks for responding. I don't think I necessarily agree, but then again I rarely rebase because I distinctly dislike rewriting history, but I think I understand the rationale a bit better.

</comment></comment></comment></comment></comment></comment><comment><USER22> Well here's the thing: Linus is right.

Linus does not hesitate to criticize and always think about things before declaring them cool.

Oh he makes errors like everybody. He's usually not always very nice in messages (read LKML and you'll understand). But he's usually right and he's usually not writing random things because "it is trendy".

So GitHub is trendy. Linus doesn't care. Linus cares for the good features and pull isn't one of them in his eyes. And then again, I think he's right. Pull in GitHub is crappy.

But what's missing from his message is the _reason_ why the GitHub pull is crappy. I'm sure he knows, but he's using half words. Here's the reason:

If GitHub enforced proper pull messages PEOPLE WOULDN'T USE IT. Why? Because it's the easyness to fork and pull that make GitHub successful. So you see, pulls have to be _DEAD EASY_. And that means also "single text field, no enforcement of anything".

So yeah. GitHub won't fix it, because it'll be bad for their business.

<comment><USER23> I really don't understand why GitHub _should_ fix it, though. It's not like it's impossible to put on a README or something else in a prominent place that pull requests need to follow certain standards.

With Linus' current work flow (pull requests via e-mail), it's still perfectly possible to have a horribly structured pull request, and so they've added on rules beyond what the technology can do for how pull requests ought to be formatted. I'm failing to see why the same rules can't be applied to GitHub.

Linus _invented_ Git, and it's perfectly possible to have single character commit messages in Git. I'm not quite sure why it's a failing of GitHub that it takes a similarly loose approach to how it deals with pull requests.

</comment></comment><comment><USER24> I hope the github folks get involved in this. I'm specially interested in what they have to say about why they decided to go with what Linus calls _their own totally inferior version_.

Love this no-nonsense style, but let me say that it's no only the style, but that Linus has enough on his side to back it up.

<comment><USER25> You only love the style because he has enough on his side to back it up. Anyone else that acted like Linus does on a regular basis would be considered childish and arrogant.

I'd take Github's version of any feature, any day, over the official git version, any time they differed - Git is a notoriously user-hostile piece of software interface-wise, and pretty much the only thing it has going for it on the usability front is Github.

<comment><USER26>
         Git is a notoriously user-hostile piece
         of software interface-wise

It's funny you say that, because Git is the only version control system where working with branches, forks and merges in big projects is not only doable, but in 90% of the cases painless. You can't really appreciate Git until you've tried doing the same tasks in Perforce, SVN and CVS. No other similar software has the same painless approach to branching and merging, not even other distributed systems.

Also, its interface is hostile because it requires the user to understand a little about its internals. You may disagree that this is good design, however it gives you unprecedented control over the repository, which you need often when the shit hits the fan. Also, Git is freakishly fast and efficient. Much like C, an interface done with taste, but that doesn't appeal to those with weak hearts. And the fact that such projects as Linux are maintained with Git, projects which have a huge number of contributers, it's a true testament to Git's awesomeness.

And btw, considering how version control is one of the most important tools at your disposal, if not the most important in big teams, stop reading those SVN 2 Git tutorials and go read a freaking manual. It's worth it, because you'd be amazed at how much power it has under the hood.

<comment><USER27> > Also, Git is freakishly fast and efficient. Much like C, an interface done > with taste

I don't agree with the second claim and the first one does not explain it being that way. What is so tasteful about this:

        # delete
        git remote rm ...
        git branch -D ...
        git tag -d ...
        git rm ...

        # rename
        git remote rename old new
        git branch -m old new
        # can't git tag ...
        git mv

No - it may be useful, it may be fast, it may be efficient. But the interface sucks completely and is very inconsistent both between the commands and in what is each command's responsibility.

<comment><USER26> First of all, all of these commands make perfect sense to me. I don't know why exactly, but I've never used a version control system that made more sense than this. I never really felt like I'm home with Perforce and SVN. Neither with Mercurial, although Mercurial is better than most.

        git remote rm

This deletes the reference to a remote repository. The difference between Git and SVN here is that in Git you can have _multiple_ remote repositories with which you can communicate.

This comes in handy when pulling and pushing to/from multiple people. Imagine swapping code between you and your colleagues, doing experiments, doing code reviews, and so on. It also comes in handy when you're dealing with Heroku, or when you've got an "open-source" core that's pushed to GitHub and another branch with proprietary additions that you push somewhere else.

Also, all commands for managing these repository references start with "git remote" and to find out how to do something with them you just do "man git- remote".

        git branch -D

This deletes a local branch. It has nothing to do with the above. It does not use "rm" because that can be the name of a branch and this command is heavily overloaded.

        git tag -d

This deletes a tag. It is consistent with the above command, as "git branch -d" (lowercase D) is also supported, but uppercase D means that the deletion is forced, even if the branch was not merged. Again "rm" was not used, as that can be confused with the name of a tag.

        git rm

Deletes a file, but you don't have to use it. If you're confident about your editing skills, you can just commit all the deletions with "git commit -a ..." ... git will also be smart enough to detect a file rename, even though you did a deletion + addition.

"rm" is also the name of the command that does the same thing in Unix, being associated with the removal of files.

         git remote rename old new

As I said, "git remote" manages references to remote repositories. This just renames the reference named "old" to "new".

You could say that they should have used "mv", like in the case of "git mv", however this is not a "move" command. This is just plain renaming.

         git branch -m old new

This renames the local branch named "old" to "new". It is indeed inconsistent with the others, but that's because the "git branch" utility has been overloaded a lot. This command does confuse me from time to time.

         git mv

Like in the case of "git rm", this command does a "mv", while registering the action in Git. It is also not necessary if you're doing a "git add . && git commit -a".

"mv" does make sense here, as it is the name of the Unix command for moving files.

And a final tip for beginners: use the "man" pages. In a terminal input any of the following commands when you need help ...

        man git-remote
        man git-branch
        man git-tag
        man git-rm
        man git-mv
        man git-push
        man git-pull
        man git-reset
        man git-checkout
        etc...

<comment><USER27> Sure they make sense if you have it in front of you and want to know what they do. They stop making sense when you want to write them - why do you have to have different way to deal with each type of an object. Either stick to -d/-D convention, or rm/rm --force, or delete/delete --force, or something else... just don't mix up calling conventions just because you operate on a different kind of object. Same goes for listing things, renaming, etc.

My point was about inconsistencies rather than not being able to figure out which command did what.

</comment></comment></comment></comment></comment></comment><comment><USER28> From his "subsurface" project README.

 _Also, please write good git commit messages. A good commit message looks like this:

Header line: explaining the commit in one line

Body of commit message is a few lines of text, explaining things in more detail, possibly giving some background about the issue being fixed, etc etc.

The body of the commit message can be several paragraphs, and please do proper word-wrap and keep columns shorter than about 74 characters or so. That way "git log" will show things nicely even when it's indented.

Reported-by: whoever-reported-it Signed-off-by: Your Name <firstname.lastname@example.com>_

</comment><comment><USER29> I also do not care for the pull requests, for much the same reasons. I like there is a way to bring a branch to a maintainer's attention and updating its commit range in event of updates before it is accepted, but the way messages that result from merging in the code is irritating, so I end up just using "git pull" to do the trick once the branch looks good to me.

</comment><comment><USER30> Can someone point me to the tool that comes with git for pull-request functionality?

<comment><USER31>
        git request-pull

If you'd like to see an example, this will generate the text of a request sending the top few commits in your repository (assuming the origin / master convention)

        git request-pull master^^^^^ $(git config remote.origin.url)

<comment><USER32> A tip - you can use master~5 instead of master^^^^^.

<comment><USER31> Thanks! I expected someone might save me the time of looking that up.

</comment></comment></comment></comment><comment><USER33> For people wondering why Linus said "You are a moron" to a particular user named "Joseph": The comment he was replying to was deleted. <https://github.com/pirtlj>

in one of his comment, "I did not realizes that Linus' shit does not stink. Thanks for clearing that up..."

Apparently, even if a comment gets deleted from a Github discussion, it still sticks to your public activity.

</comment><comment><USER34> Considering Linus _created_ git, if I were running github I'd tend to listen to whatever he had to say about it...

<comment><USER35> Devil's advocate:

Considering GitHub _popularized_ git, if I were in charge of git I'd listen to what the GitHub guys have to say about it.

<comment><USER7> Depends where. Projects like the linux kernel (obviously), Xorg and Firefox had all moved to git before github ever showed up. It was well on it's way to popularity all on its own merits

<comment><USER36> Firefox uses doesn't use git.

</comment></comment></comment></comment><comment><USER37> Jesus, watching some of the little snowflakes on here whining about how Linus chooses to run his repository is seriously disheartening. When did the the tech community get infiltrated by so many prima donnas and drama queens? If you have a problem with Linus' style or how he chooses to use the tool he made, build an alternative (if you can...) or swap over to a different stack and get on with your life. Stop whining.

</comment><comment><USER38> It's 2012 and we're still arguing about line breaks and 80-character lines?

<comment><USER39> It's 2012 and Gmail can't consistently reflow lines in emails between its flagship web client and its flagship Android client... so yes, it would appear so.

<comment><USER40> What?

<comment><USER40> Okay. Thanks for the downvote, so I'll ask again, "what?". I don't know what you're talking about and have never experienced anything that might fit that description. Can you offer an example.

<comment><USER39> Sorry to see you downvoted.

Reflowing refers to reconstructing lines broken by line wrapping. Here's the example I was referring to: Grab a couple of unwrapped paragraphs of lorem ipsum (make sure there's no explicit newlines) and email them to yourself as a plain-text email using the desktop web gmail interface. You will notice that when you open the email in your inbox, it shows up with line breaks - <USER2> sent it with explicit newlines after ~80 characters. (Use Show Original if you want to confirm.)

Now open the same email in the Gmail app on Android (I'm using Gmail 2.3.6 - the newest available on my Androids 2.2 and 2.3.6). My Android screen, like most smartphone screens, isn't wide enough to hold all 80 characters in one line, it's more like 50 or 60 characters. Gmail wraps the email to fit, which is expected and desirable. The problem is it keeps the original linebreaks at 80 characters, resulting in two linebreaks. Every other line is short at 20 or 30 characters and the email looks very jagged. Reading it is very uncomfortable. It gets really messy when you have quoted text, particularly with interleaved response style.

There's actually a whole bunch of standards or semi-standards and techniques around doing this kinda stuff. Standalone mailers have been doing reflowing and format=flowed for a while now. Sad to see Gmail drop the ball on this.

</comment></comment></comment></comment></comment><comment><USER41> antirez via twitter: "Linus, I'm with you. Preserve your bastion of code quality as it's something rare and rapidly fading away."

<https://twitter.com/#!/antirez/status/201065752395124737>

<comment><USER42> Linux and code quality? I think you may be confused.

<comment><USER43> Please name one project out performing Linux kernel in terms of your definition of code quality. I'd like to have a surprise.

<comment><USER42> Define code quality: braindead GNU extensions such as nested functions - <USER3> uses that, How about the separation of DM and MD due to ego's, how every driver without a lib (such as libata) warranting a few exceptions has to rewrite boilerplate for basic things - frame buffer drivers are a good example. How about the syscall bugs - look into glibc if you feel like gouging your eyes out or jemalloc for more tame code. Linux itself is more an ecosystem of code and not a single project some parts are good while others are very very bad.

<comment><USER44> C nested functions were explicitly banned from Linux.

What are the others?

</comment></comment></comment></comment></comment><comment><USER45> I get the point he's trying to make and completely agree with it, but the way he presented his issues just made me lose respect for him a little bit ... I just wish someone that respected was able to present his views in a way that younger developers could emulate.

I can't help thinking tons of "rockstar/ninja" developers out there are going to embrace this abrasive style of disagreeing with people and totally rationalize it by thinking well "that's how the guy who wrote Linux does it, so that's how I'm going to do it"

Someone that well respected should (and this is my opinion) never have to reach to the level of addressing someone so far-removed from the heights they've attained, as a 'moron', when simply ignoring them would do. But I'm nobody important, so what the hell do I know about anything ...

<comment><USER46> This was mentioned as a concern when Steve Jobs died:that budding ninja technologists would try to emulate his puportedly nasty management style.

Fortunately, I think this sort of nastiness is self-limiting. The only really egotistical, nasty rock star I ever worked with destroyed himself, much to the delight ( and with some assistance from) his colleagues. I think that would be be a far more likely outcome than a nasty rock star continuing their ascent with a bad attitude.

</comment></comment><comment><USER47> That's pretty relevant comment. GitHub pull request system is great if you want to attract a bunch of script kiddies to participate on your project. For serious work, not so much.

<comment><USER48> I would say the same about github's forks-as-top-level-entities system.

Forking a project is a huge deal. Forking a git repository is no big deal.

Github does the former, and it encourages too-broad forks, and at the same time, discourages coordination and contribution with the original project. Nearly all forks should be short-lived and completely subsidiary to the main _project_.

<comment><USER49> That's a lot of opinions and much less arguments (no offense). Would you care to explain the motivations behind the opinions?

<comment><USER48> Forks -- as top-level named entities -- draw attention and resources away from the original project, possibly leaving both projects with too-few resources to survive afterwards.

This is why "forking" an open-source project was considered a nuclear option prior to the emergence of github.

I rarely even get pull requests from people forking my code on github, and when I do, they almost never have bothered to discuss with me prior to implementation. It's a relatively recent phenomena that is largely encouraged by the tools.

</comment></comment></comment></comment><comment><USER50> Maintainer of a project doesn't like a tool some people like to use. News at 11.

Seriously. Just dont' send this particular maintainer pull requests that way.

<comment><USER51> This maintainer is a little more notable than most... And his opinion is a little more relevant :)

<comment><USER50> That's the thing about science or really any discipline where results is more important than anything else.

It's not really. If any other maintainer of a project finds they're cool with pull requests from github, then it's a fine tool for those projects. This guy runs a project which is an outlier in it's size, and which is also a far older project than most of what github hosts.

Now if his criticism has useful facts, that MIGHT be useful, and it does: The github format has fewer bits of info. Could some of those bits of info be important? Maybe. I didn't sense a genuine, measured analysis, but instead a rant from a maintainer about something that's not working for his project. Nor did I see a counterpoint from github why their tool does it the way it does. There may be real design decisions there, ones that might be better answers than what Torvalds has, especially for projects far smaller than Torvalds.

Don't let Torvald's status as the maintainer of the Linux kernel (and creator of git, to do that task) make you forget he's also paid attention to because he's famous as well as a useful contributor. Fame doesn't make you more right, just more adored. His ideas still require critical analysis from the rest of us.

</comment></comment></comment><comment><USER52> I have to agree with Linus on this and it's nice that he's taking time to write out his thoughts in public.

GitHub commit messages can be really ugly. I'm guilty of this and it's not something I'm proud of. I think the small improvement they did a while ago with the display of commit messages is a step in the right direction, I wish they would apply that same style to the web interface when composing commit messages.

edit: A good fix would be a way to turn off pull requests for projects or at least redirect users on how to send pull requests.

</comment><comment><USER53> What, Linus found something he doesn't like?

<comment><USER26> Don't forget SVN: <http://www.youtube.com/watch?v=4XpnKHJAok8>

</comment></comment><comment><USER54> I agree with Linus on a lot of things, but I wonder sometimes if he rubs people up the wrong way occasionally.

<comment><USER55> He makes no bones about it. Git got its name because Linus thinks of himself as a git.

</comment></comment><comment><USER56> Extremely relevant criticism. It appears to be a rather simple problem for Github to resolve.

</comment><comment><USER57> Maybe github can make it easier to send messages in reply to a pull request, or even show an email field there. Having people type out their email into the pull request is not the best way to handle that on the web interface I don't think (although practically speaking if you want to use email it is perfectly reasonable to make that a rule for your project until there is a feature like that for git and github). Ideally git itself could make it convenient to view that as a separate field with the pull request.

I am also pissed when someone ignores a feature I have written and redoes something without good reason.

Torvalds probably doesn't have time to handle a whole bunch of git pull requests, and most of them from github probably have problems or aren't important so this rule probably helps him a lot, practically speaking.

But obviously the people at github should really carefully analyze what he is requesting and if possible this could result in some minor improvements in that part of the github interface or git or both.

I don't know much about the Linux kernel, but I don't think that this type of driver information should be in such a centralized place and controlled by an individual or small group of individuals.

</comment><comment><USER58> It's Linus's repository and he can do things the way he wants. Stop whining.

</comment><comment><USER59> So what exactly is deficient with github's approach to pull requests vs git pull-request?

</comment><comment><USER60> As genius as Linus is, the dude needs to take a couple of shots of harden the f*ck up. I'm sick of his school girl rants and complaints. For such a well- known figure head in the open source/computing industry he sure does complain a lot.

</comment><comment><USER61> How on Earth is this drivel at the top of HN?

<comment><USER62> It's nearly the tech equivalent of a tabloid article. It sells because it has level of entertainment value, not found in "why fictorial won't do github pull requests"

</comment></comment><comment><USER63> I can see two stupid comments by pirtlj (<https://github.com/pirtlj>)

>pirtlj commented on pull request 17 on torvalds/linux a day ago Ouch my feelings are broken... I just wish you would live up to your image, but then again you're just an imperfect human too.

>pirtlj commented on pull request 17 on torvalds/linux a day ago I did not realizes that Linus' shit does not stink. Thanks for clearing that up...

</comment><comment><USER64> The one thing I'll have to give credit to Linus for is that even if people continue to post absurd comments after his original lengthy counterpoint, he will delve into a more polite rhetoric and continue to explain his point, over and over. It's quite the opposite, in fact, of many people who write online where typically the end result is simply escalation or continued fervor.

</comment><comment><USER65> Github should implement a tempting system for commit messages that way every project can enforce there own standars. And those templates should be shareable, like a template repository so new and existing projects can opt to use one of the exciting ones.

problem solved :)

</comment><comment><USER66> i am i the only one who's reading Torvald's comments with David Mitchell's voice? <http://www.youtube.com/watch?v=PqSZEGj-SuI>

</comment><comment><USER67> As long as Linus patiently explained why he doesn't accept guthub pull requests, it seemed ok. But calling someone a moron for it, that kinda hurts the community!

<comment><USER9> He called someone else a moron, and that person deleted their comment. For all I know, that person's behavior was worse

</comment></comment><comment><USER36> Some insightful comments on the github are getting deleted.

</comment><comment><USER68> If somebody invents a car and gives it to Torvalds, he'll call the designers total morons if the blinker isn't at the height that he likes.

<comment><USER69> This seems a bit misplaced. More like if Torvalds invents a motor and then someone puts it in a car, he might complain if the motor doesn't run the way he'd like. Which isn't entirely unreasonable.

<comment><USER68> You're right, it's not unreasonable for him to not like it. He can dislike anything he wants to. But that doesn't mean it's reasonable to expect the car designers to change their car to suit his desires.

Github is not Git. It's a separate product which happens to _support_ Git, but is not Git, strictly speaking. It's basically a social network for building software. Far removed from the revision control software it depends on.

Complaining that the commit log isn't formatted in his preferred manner is similar to an engine designer complaining that the car's ODB2 reports aren't easy enough to read on his hand-held scanner. The engine designer can dislike it all he wants, but if I was the engineering team who designed the whole car, I wouldn't lose sleep over his dislikes.

</comment></comment></comment><comment><USER70> GitHub, seriously, if Torwalds takes the time to point out a flaw in your software, listen to him! Really.

</comment><comment><USER71> These details matter apparently. I hope some of these improvements mentioned will be implemented soon.

</comment><comment><USER72> Can anyone point me to best practices on writing (git) commits?

Or can you sum up yours here?

<comment><USER72> Ok, found this, linked by Mr. Torvalds

[http://tbaggery.com/2008/04/19/a-note-about-git-commit- messa...](http://tbaggery.com/2008/04/19/a-note-about-git-commit- messages.html)

</comment></comment><comment><USER73> This link would be better-titled as "Linus Torvalds pwns Github."

</comment><comment><USER74> Isn't it funny when he signs his comments in the end?

<comment><USER75> He's replying using email, that's why.

</comment></comment><comment><USER76> linus is a misanthropic blowhard. as a role model, regardless of whether he signed up for it, he should be embarrassed at his behavior

</comment><comment><USER77> He's an engineer, he's just being definitive!</comment>


The Real Reason Google Serves All That Free Food - <AUTHOR> http://www.forbes.com/sites/davidburkus/2015/07/02/the-real-reason-google-serves-all-that-free-food/

<comment><USER2> When I worked there in 2013 as a contractor, at first I was puzzled by the huge coffee machine in the mini-kitchen near my desk. It took perhaps 60 to 90 seconds to get a cup of fresh coffee. Later I realized that the value of this delay was getting to talk with people I otherwise would not have.

</comment><comment><USER3> Really agree with this as developers usually sit at their desks and do not get much time to interact with other people. They can exchange ideas with colleagues while grabbing the food.</comment>


The Opening Bell (no one told me I had to make a speech) - <AUTHOR> https://medium.com/@Wuntusk/the-opening-bell-no-one-told-me-i-had-to-make-a-speech-cf2a7e1b04e4 <comment><USER2> My favorite part was the Vonnegut quote.

> I urge you to please notice when you are happy, and exclaim or murmur or > think at some point, 'If this isn't nice, I don't know what is.

<comment><USER3> Agreed. And if you write down in your diary/notebook what have you when you recognize you're happy and having fun. Then write down as much of what you can capture about why. That will give you a tool to use to figure out where to go next to maximize your engagement level with your next task.

</comment></comment><comment><USER4> Sonic Foundry had incredible products (Vegas, Acid) but they don't appear to have enjoyed the success they deserved? They have been acquired many times, once by Sony and then by Magic, and the most recent versions of the software are years old.

Yet these products are among the most stable and user-friendly that I have come across. It would be most interesting to read more about their journey!

<comment><USER5> Acid never struck me as something particularly widely used. I was big into electronic music production at the time and I started with Acid + Sound Forge but eventually moved on to Reason and later Ableton + Reason. People who were doing a lot of multitrack editing seemed pretty loyal to Cubase (or Pro Tools if they were using Macs) and then Ableton came along and became extremely popular.

Sound Forge is of course in a class of its own.

<comment><USER6> And let's be honest. That software was so incredibly pirated I assume more people bought WinZip.

Acid was pretty fun to play with. I will outright admit I did not purchase my copy.

<comment><USER7> One bit of SoFo lore that I was told on my first day: inspecting the metadata on one of the .wavs on win95 would reveal that it was edited using a cracked copy of Sound Forge.

/EVERYONE/ pirated Sound Forge.

<comment><USER8> Not 95, XP:

[http://web.archive.org/web/20041204064837/http://www.pcwelt....](http://web.archive.org/web/20041204064837/http://www.pcwelt.de:80/know- how/sicherheit/104830/index1.html)

[http://web.archive.org/web/20041210045441/http://www.pcwelt....](http://web.archive.org/web/20041210045441/http://www.pcwelt.de:80/know- how/sicherheit/104830/index2.html)

</comment></comment></comment></comment></comment><comment><USER9> Crazy that Soundforge was built with such a small team.

Playing around with Soundforge as a teenager in 1998 and looping samples together was super inspiring for me. Anyone could make professional sounding music from their computer, and using it also piqued my interest in building software.

<comment><USER10> There is surprisingly little difference between what one software developer can accomplish and what a hundred can accomplish.</comment></comment>


Show HN: A/B testing for Unity games - <AUTHOR> http://splitforce.com

<comment><USER2> Awesome: this will be really useful for the Unity game devs I know.

</comment><comment><USER3> Seems interesting. Will take a look.

</comment><comment><USER4> I'll take a look.

</comment><comment><USER5> so useful! BIG like</comment>


Why 'Nudges' Hardly Help - <AUTHOR> http://www.theatlantic.com/business/archive/2015/12/nudges-effectiveness/418749/?single_page=true <comment><USER2> I'm a bit surprised that this article doesn't deal with the increasing amount of science behind neurological food reward mechanisms. The tl;dr is that our junk food (and much mass-produced food in grocery stores) has been tailored for a kind of hyper-palatability that mutes the effectiveness of our normal satiety mechanisms. So in the article's context the "nudge" is up against an evolving attack by industrial food against very low-level neurological mechanisms.

I don't have a good "lay" source for this field, but I'd recommend digging into Stephen Guyenet's blog[1], that is if you're up for wading through an academic's professional musings. He's a neurobiologist and obesity researcher, and as such the blog provides his perspectives on ongoing work (his and others') in this field. Warning: DO NOT go here expecting any specific answers, and be able to deal with a fair bit of hypothesizing (i.e. untested, maybe totally wrong) both on Guyenet's part and via the work he reviews. You'll only really get a sense of how this field is going as you pick up enough context of ongoing work. IMO, the most interesting self-contained posts that go by are the significant negative results, where robust work comes to light that just crushes an existing hypothesis.

[1] [http://wholehealthsource.blogspot.com/](http://wholehealthsource.blogspot.com/)

<comment><USER3> Related book by the former head of the FDA

"Dr. Kessler shows us how our brain chemistry has been hijacked by the foods we most love to eat: those that contain stimulating combinations of fat, sugar, and salt"

[http://www.amazon.com/The-End-Overeating-Insatiable- American...](http://www.amazon.com/The-End-Overeating-Insatiable- American/dp/1605294578)

</comment></comment><comment><USER4> It probably won't come as much of a shock to folks here, but this article has a misleading title.

In the third paragraph, "Nudges hardly help" softens all the way to "nudging sometimes... isn't effective".

I've come across three groups of reactions to "Nudging":

1) Yay! Let's use science for good!

2) Yeah but it's not a silver bullet

3) I think they're brainwashing us

Camp 1 is sensible, and has room for discussion about ethics, rigour, etc. Camp 2 is arguing against a straw man. Camp 3 is a reasonable position to hold if you have government trust issues and don't understand what's happening, so is an education and operational transparency problem more than anything.

Edit: disclaimer, I've worked closely with a nudge unit but am not an employee of one

<comment><USER5> I have issues with nudging, but am unsure of whether I fit in one of your categories. My issues are:

a) When a few people make de-facto decisions for everyone else, those decisions are prone to causing black swans because of a lack of (real) diversification of risk. One example of this would be if 20 countries used the default retirement portfolio scheme (that is often used to support nudges), and in one country, the portfolio was not diversified against a type of risk (i.e. interest rate or mortgage default), that could cause severe malinvestment and economic calamity in one country. It would have been much better for 1 in 20 people to make the mistake than 1 in 20 countries.

b) People's decision making abilities are like any other skill (i.e. language, writing, arithmetic), in that they atrophy over time if they are not used. If the people have no reason to look out for themselves, they may not realize when the nudgers are abdicating their responsibilities. In addition to that, financial decisions give clear feedback and have good incentives for the individual, which allows and requires people to exercise their decision making abilities, that will be useful in other areas of life.

Perhaps I fit in to your 'group 3', but either way, I'd be interested to hear your thoughts (if you would be interested in giving any) on these two objections.

<comment><USER4> Good points all.

Point (a) is a potentially a huge problem, I agree. An entire country suffering from poor pension investments all at once could have disasterous consequences.

My understanding of the typical pension opt-in change is that it opts you in to your company's default pension rather than a state default pension, so the nation as a whole would have diversification even if customers of some pension providers are at risk (unless that nation didn't have diverse pension providers, in which case they already have a problem). Could be wrong, not my area.

Issue (b) is interesting too. I'd say it fell into my third group because it seems to rest on people being lulled into a false sense of security and then taken advantage of. There are a couple of reasons why I don't think it'd be a problem... one applies to "good" nudge units and the other is more general.

Firstly, at a 'good' nudge unit they operate transparently, both at the point of intervention and when publishing findings after the fact. If you look at Richard Thaler's work, he uses 3 'laws' to define 'good' nudges that make it hard for abuse to seem possible:

[http://www.nytimes.com/2015/11/01/upshot/the-power-of- nudges...](http://www.nytimes.com/2015/11/01/upshot/the-power-of-nudges-for- good-and-bad.html)

Secondly, a more general point. Nudge units on the whole use a tiny subset of the psychological arsenal that companies use daily. They only use the stuff there's clear scientific evidence for ploughing on layers of gamification, incentives, information assymetry, etc. Yet companies do not feel bound by Richard Thalers "3 laws of nudging", they rarely follow more than 1. That's fair enough, as it's harder to switch to a different government and governments have more power over us, but it does raise the question... if our decision making skills atrophy over time then that would have already happened with companies, and I'm not sure I've seen evidence to support that view. Again, could be wrong.

</comment></comment></comment><comment><USER6> Author hardly demonstrates how nudges "hardly help". In fact, my guess is that nudges are extremely effective. Just the trivial 10c grocery bag fees (a "nudge", imo) can reduce bag use by 80% (whether or not bag reduction is good/bad is a different discussion).

<comment><USER2> As my other post in this thread gets into, this example of a "nudge" doesn't compare to the junk food case, since junk food is effectively designed to hack our brains' "food reward" mechanisms. Bag use is effectively neurologically "neutral", but junk food (and most other highly processed food) is very much not. "Pringles, can't eat just one!" turns out to be a _lot_ more than a marketing slogan.

<comment><USER7> That slogan is for Lay's potato chips. Pringles' slogan is "you don't just eat them".

Source: I love Pringles. [http://i.imgur.com/oibfGJA.png](http://i.imgur.com/oibfGJA.png)

<comment><USER2> Thanks for the correction!

</comment></comment></comment></comment><comment><USER8> > Thanks to problems like these, the economist (and frequent Atlantic > contributor) Teresa Ghilarducci has called the 401(k)

Is this true? Is your money better off in an IRA, even with an employer match?

<comment><USER9> If you just let your employer put your retirement savings in their default mutual fund, what you're going to get is some product sold to the company by a money manager who is taking 2-3% of your money off the top.

Given how rare it is for a mutual fund to consistently return even 4% for any amount of time (seriously, if you know of one that does let me know and I'll sign up at once - 1-2% is more typical), you end up with something that's worth less than a basic savings account, but with a bunch of rules attached to it that prevent you from using your money when you want. Depending on the circumstances, that could be a pretty poor deal.

<comment><USER10> Forgive me if this is ignorant, but does that basically mean the "employer match" (common at orgs I've worked for) is basically doing nothing as it's a similar percentage?

<comment><USER8> Employers only match what you put in, whereas mutual funds take fees off of the returns. That suggests to me to contribute only enough to get your match, and roll it into an individual account after you leave the company for more control over where it goes.

<comment><USER9> Agreed. Not as set-it-and-forget-it as it's advertised to be, but never turn down free money. Just do the math so you know what you're getting.

</comment></comment></comment></comment></comment><comment><USER11> We're currently in beta with a DNA-based health advice service ([http://withinhealth.com](http://withinhealth.com)) and here are a few observations (this will be written about more in detail at a future date on my personal website)

\- People remember health information that is specific (personalized) to them.

88% of our beta users are able to remember their genetic insights/advice 3 or more days after receiving them.

\- A compelling, personalized reason can help users get over the hump of taking an action.

No one wakes up in the morning and decides they want to get some blood work done for the heck of it. We identified interesting genetic predispositions for beta testers which were enough to motivate 7% of them to get blood work done. 21% of beta testers took an some type of action based on the personalized and advice we presented.

It hardly goes against common sense to believe that personalization would facilitate retention and action but it has been fulfilling to witness firsthand.

<comment><USER12> Tried to sign up, but got:

"403 Forbidden

qXTJJBys/ed4Gx1wX @ Tue, 08 Dec 2015 18:00:18 GMT

BRICK-6"

<comment><USER11> Thanks - should be fixed!</comment></comment></comment>