Crumpled Outfits Drove Me to Create Origami-Style Dresses - <AUTHOR> https://www.projecthatch.co/interview/how-crumpled-outfits-drove-me-to-create-origami-style-dresses-146k-on-kickstarter <comment><USER2> Strangely, the article doesn't link to the actual product site or have very clear pictures of the product. Here's a link to the site:

[https://origamei.com](https://origamei.com)

<comment><AUTHOR> It does link to their site, check the third paragraph! Agree on the image, uploading some clearer ones now

<comment><USER2> Ah, I guess I missed that, might be nice to get a link in the story header / footer if possible. Sometimes tricky to scan body text for a link.

Cool product / story by the way!

<comment><AUTHOR> Appreciate that!

</comment></comment></comment></comment><comment><USER3> For a demo, go to [https://origamei.com](https://origamei.com) and scroll down to "See how it folds."

Very neat idea. I wonder if something like this could work for button-up shirts?

<comment><USER4> I don't think there is much freedom in placing seams in a button-up shirt, so it is difficult to understand how it would work.

<comment><USER5> There's a lot of freedom in placing seams, as long as you're OK with the resulting look.

In fashion, form and function and not necessarily related :)

<comment><AUTHOR> Definitely a opportunity there.

</comment></comment></comment></comment><comment><USER6> This is an interesting design variant, where the wrinkle-resistant dresses are designed specifically to be folded down into very small packages. So the packaging is integral to the approach.

I initially expected something like Issey Miyake, who produced heavily pleated garments that you could stuff in a bag.

<comment><USER7> ^ Miyake was the first thing I thought of when I saw this headline also. The pleated / folded stuff he created in the 90s was pretty neato

</comment></comment><comment><USER8> The dresses don't appear to be particularly special, aside from the built-in pouch. What makes these "origami-style"? Is it merely that they can be folded? Many companies offer similar dresses in a similar wrinkle-resistant material that can hold up to folding during travel.

<comment><AUTHOR> They have seams designed for you to fold along - similar to origami. Yeah, there is also a built in pouch to fold the dress into. Some companies have tried similar but I think think the combo is unique.

</comment></comment><comment><USER9> fun to see that the pictures on the home page are from venice beach.

as neat as the folding and pouching is, i'm more impressed with the 1 dress 100 days campaign she did and all the different ways she accessorized one black dress: [https://origamei.com/blogs/news](https://origamei.com/blogs/news)

this also reminds me of these foldable grocery bags that i still use after many years (was an early customer): [https://flipandtumble.com/](https://flipandtumble.com/)

<comment><AUTHOR> Amazing consistency for the 100 days campaign. It's the sort of thing you say you're going to do and then it falls off after the 4th day.

Those are some good lookin bags

</comment></comment><comment><USER10> When do we get the men version? I don't wanna have to cross-dress.

<comment><AUTHOR> Can't wait for this. Shirts and tees in a bag for after the gym</comment></comment>


The perils of federated protocols (2016) - <AUTHOR> https://lwn.net/SubscriberLink/687294/f0e0d89fe4a77b4d/ <comment><USER2> The benefit of a federated protocol is the same as the downside: No dictator.

Nobody can say that this good feature is now present everywhere, for everyone, at all times, and nobody can remove a good feature or add a bad feature in the same fashion. You can't mandate end-to-end encryption and you can't mandate that everyone who is using end-to-end encryption will use an algorithm which is backdoored.

<comment><USER3> What I'd like to see is some kind of unofficial, periodic publishing provided by the (say) top 3 vendors that implement a given protocol where they would spec a common profile and define the basic integration test suite - sort of like the CSS Acid tests.

Let's take the example of XMPP: the top server implementations could agree that in 2019 all of the servers should support XEP-{A, B, C, D}. In 2020, XEP-E and XEP-F could be added. In 2021, XEP-B can be superseded by XEP-G...

As it is now, it seems that most vendors want to compete and try to take whatever little market is left for XMPP. If instead they decided to collaborate, it would help immensely client application developers, they know that the important thing would be to ensure that they support the current profile.

My guess is that could lead to some kind of concentration of power and force smaller vendors into spending resources in Keep-Up-With-The-Joneses mode, just to get close parity. However, given that the protocol is open and most interesting implementations are open source, this doesn't seem too different from other technologies - how many different FOSS http/mail/amqp/ssh/RDBMS projects are there, and how much of a Pareto distribution do they follow?

<comment><USER4> I think the interoperability issues mostly happen on the client end with XMPP. The popular open source servers support most anything that anyone would want. The problems are with stuff like video and audio chat ... and interoperable end to end encryption for clients that still don't support OMEMO. So you could work on a set of client capabilities for voice/video chat. Such a minimum requirements list would help with all voice/video, not just XMPP.

A relevant grid of XMPP client capabilities:

* [https://en.wikipedia.org/wiki/Comparison_of_instant_messagin...](https://en.wikipedia.org/wiki/Comparison_of_instant_messaging_clients#XMPP-related_features)

<comment><USER5> > issues mostly happen on the client end with XMPP.

from what I have seen in comments over the years is that it's been spotty to make it so you could depend on things working / being delivered to the other (federated) clients - as most do not accept the same feature set as each other.

I had suggested that a chart is made of all the clients along with which features are not yet implemented there, along with the programming language they are written in. This way it should be possible to estimate the amount of hours to add all features to all clients, then estimate the cost - and maybe we could crowdsource the amount of money or volunteer hours to get most clients to reciprocate most feature interoperability.

When I mentioned this here: [https://news.ycombinator.com/item?id=19216077#19223912](https://news.ycombinator.com/item?id=19216077#19223912)

someone pointed out this chart here: [https://compliance.conversations.im/](https://compliance.conversations.im/)

Which I found interesting and was not aware existed.

I'd love to see xmpp, the clients, and matrix and it's clients all get more streamlined and user friendly. (signal too)

<comment><USER4> It is interesting how the greatness of the conversations XMPP client has sort of created a defacto baseline. You have to go half way down the list before you get below 90% compliance.

The thing with an open protocol is that there is always going to be a vast number of clients that don't support much of anything. We really only need one really good free client on each major platform.

</comment></comment></comment></comment></comment><comment><USER6> > Those who want to communicate with other Signal users but not with Google > servers are shut out.

Note that while this _technically_ isn't the case any more, as you can use Signal without Google services now, Signal still creates a background task which periodically checks for updates and you can't change the frequency. This results in the GMS-free version to be a major battery drain [1]. Ultimately, this was a deal breaker for me and I removed Signal after testing it for a while on my smartphone.

[1]: [https://github.com/signalapp/Signal- Android/issues/6732](https://github.com/signalapp/Signal-Android/issues/6732)

<comment><USER7> You know what would be really cool, is if Signal supported encryption over SMS. Then you could communicate without the cooperation of either Google _or_ Signal's own servers! And no battery life impact!

...except it did. And they killed that feature, justifying it with a bunch of _really weird_ arguments [1]. Like that SMS always leaks metadata, when Signal's data protocol also leaked the same metadata - except only to them, instead of a federated network. But don't worry, they promise they don't log it. Honest.

I don't trust Signal at all after that. Use SilenceIM for encrypted messaging [2].

[1] [https://signal.org/blog/goodbye-encrypted- sms/](https://signal.org/blog/goodbye-encrypted-sms/) [2] [https://silence.im/](https://silence.im/)

</comment></comment><comment><USER8> With federated protocols, ideally, many would be running their own servers.

In reality, users tend to concentrate in one or two servers. And then federated is about as good as centralized.

Reminder of what happened with XMPP: It got embraced, extended and extinguished... by Google.

We should be moving towards fully distributed architectures. Only when there are no servers is this problem really gone.

<comment><USER7> This isn't always true. The phone system remains well federated, even within a single country. Email is likewise hanging on, although gmail is very popular. IRC is an interesting case, where "networks" have federated servers that load balance completely transparently.

</comment></comment><comment><USER9> Well, maybe Marlinspike should consider just not moving so fast. There's something to be said for stability. (Cue Debian.)

On the other hand, I do strongly agree that the extensibility of XMPP basically killed off Jabber. I'm back to just IRC except for a (non-federated) work-internal server, and occasionally (say twice a month) firing up a Jabber client to get a message through (though I mostly eMail those people instead).

</comment><comment><USER10> I have always wondered why older social networks like Frienster and Myspace that are in decline not decided to band together and federate their services or parts of it to regain critical mass and stay relevant.</comment>


Google Common Lisp style guide - <AUTHOR> https://google.github.io/styleguide/lispguide.xml <comment><USER2> > _You must not use INTERN or UNINTERN at runtime._

I.e. you must not read Lisp data at run time, if it contains symbols, because that will call _intern_.

> _You should avoid using a list as anything besides a container of elements > of like type._

Good-bye, code-is-data.

I could reduce this guide by a good 30% with "You should avoid using Lisp as anything as Go or Java".

But that could be seen as defining a macro, which you must seldom do.

<comment><USER3> I really don't think that this is bad advice in general. Mess with the code all you want at compile time, but don't touch it at runtime is the good kind of boring. CL is an extremely powerful language, it doesn't mean you should be using it all the time in your day-to-day work.

<comment><USER2> The thing is, you usually shouldn't be calling INTERN even at compile time. A better rule is this:

 _Don 't use code to calculate character strings, which are then converted to symbols via INTERN. The main exceptions to this rule are structs (which generate slot-reader functions by combining the structure name and slot names)._

Macrology which calculates names using code, which are then supposed to be explicitly referenced in code, is pretty stinky.

E.g.:

      (define-blob foo ...)

Here, you're suposed to Just Know that the above is referenced as _blob-foo_ and not _foo_ , because internally it catenates "BLOB-" onto (symbol-name 'foo), and calls intern on that.

<comment><USER4> Above is one of the many reasons I prefer defclass to defstruct. Defclass doesn't do this ridiculous nonsense.

<comment><USER5> Many times when working with code that uses structs in Racket I have found myself fruitlessly grepping for the definition of some mysterious and troublesome function before eventually remembering to check whether there is a struct named foo with a member named bar somewhere. Normally this is not a problem so long as the file can make it far enough through the syntax phase that you can resolve the names. Yet somehow when the code is well and truly broken then somewhere, somehow, a struct will be involved without any way to resolve the member name. I say this having written my own symbol creating and binding macros before I realized the pitfalls and now dread having to go back and fix it. It seems like such a cool idea in principle.

<comment><USER4> It's a cool idea for programming and a terrible idea for software engineering.

</comment></comment></comment></comment></comment></comment><comment><USER6> > Symbol guidelines: You should use lower case

Like flipping through for the soft porn in a friend's "romance" novel, I must confess I searched straight for this guideline.

It astonishes me that Lisp systems still default to all caps. Of course one can quickly disable this, but why send the old gheezer "GET OFF MY LAWN!" message? That's exactly what people do, get off Lisp's lawn. They don't even get to the part where the parentheses (completely unnecessary for representing a tree in 2020) are a hazing exercise / loyalty test.

I love Lisp, but its public relations is the poster child for "How can people who are so smart be so dumb?"

<comment> sahil-kang Can you share more info about the parentheses being a hazing test? I've seen Dylan syntax [1], but is there something else that shows the parentheses to be unnecessary in 2020?

[1] [https://en.wikipedia.org/wiki/Dylan_(programming_language)](https://en.wikipedia.org/wiki/Dylan_\(programming_language\))

<comment><USER7> I've had good experience with Closure's cautious approach to parentheses.

It's not radical, in that it's still basically parentheses but their nesting is greatly reduced by combination of tricks:

Flattening, if reversible. E.g. if something's always a list of pairs, then it's represented as a flat list with pairing inferred.

Having shorthands in syntax, i.e. [a b c] is (vec '(a b c)).

<comment><USER8> In my admittedly limited experience with Clojure a few years ago, IIRC it seemed like it just replaced some parentheses with square brackets, but did not actually reduce the number of total brackets by much.

</comment></comment></comment></comment><comment><USER9> > Macros bring syntactic abstraction, which is a wonderful thing. It helps > make your code clearer, by describing your intent without getting bogged in > implementation details (indeed abstracting those details away). It helps > make your code more concise and more readable, by eliminating both > redundancy and irrelevant details. But it comes at a cost to the reader, > which is learning a new syntactic concept for each macro. And so it should > not be abused.

I really think this just applies to any kind of indirection - classes, functions, even named constants (vs literals).

<comment><USER4> > I really think this just applies to any kind of indirection - classes, > functions, even named constants (vs literals).

Disagree. Macros are fundamentally different in that they can change the syntax of the language. As such, they can inhibit the code's readability in ways the other defining forms cannot. Looking up something by name in CL is as simple as meta-dot. But you cannot meta-dot syntax. (Well, you could on a Lisp Machine, but not so much on current CL implementations.)

<comment><USER10> > you cannot meta-dot syntax

I don't understand this? Besides the macrostep expander, meta-dot works on the macro name: reader macros _are_ harder to debug, but they're generally discouraged.

<comment><USER4> It requires more cognitive load to interpret new syntactic constructs. See brundolf's comment herein.

</comment></comment></comment></comment><comment><USER4> > You should favor iteration over recursion

I take slight issue with this. It's one of the ways Scheme programming style differs from Common Lisp style in general, and it makes sense. But I find the LOOP macro obtuse and ugly and many algorithms are simply clearer with recursion, so if I can write it tail-recursively and I know the implementation supports tail calls (most do), I often do that instead of using LOOP.

The other handy case for recursion is "try foo, and if it doesn't work tweak this argument and try foo one more time." There tail calls don't matter because max iteration count is 2.

LOOP is still critically important but sometimes it impedes rather than assists clarity.

<comment><USER11> Have you tried iterate (wrt the loop sucks problem)

<comment><USER4> Yes but I've never used iterate enough to get comfortable with it. Maybe I should.

</comment></comment></comment><comment><USER12> If curious see also

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

Not Google's, from last year: [https://news.ycombinator.com/item?id=20505807](https://news.ycombinator.com/item?id=20505807)

<comment><USER13> Beat me to it! Link to the article in the 2012 submission is broken, so here's a web archive copy: [http://web.archive.org/web/20130114221734/https://google- sty...](http://web.archive.org/web/20130114221734/https://google- styleguide.googlecode.com/svn/trunk/lispguide.xml)

Seems like the exact same document which harks back to the ITA Software acquisition per comments at the time of that submission

</comment></comment><comment><USER14> I assume (perhaps naively) that Google must have a non trivial amount of CL development if they have a style guide for the language... anyone know what they use CL for?

<comment><USER15> My guess: Google bought ITA Software about 10 years ago, and their search engine was written in Common Lisp.

<comment><USER16> Yes. The authors of this document were all engineers who worked on QPX/QRES.

</comment></comment></comment><comment><USER17> YMMV but i do prefer the following: [https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp- style.pdf](https://www.cs.umd.edu/~nau/cmsc421/norvig-lisp-style.pdf)

</comment><comment><USER18> Is it weird that I enjoy reading this, even though I haven't programmed in Common Lisp for a long while?

</comment><comment><USER19> Who here can talk about how widely used Lisp is at Google, and what it is used for?

</comment><comment><USER20> Went looking for advice on concurrency/parallelism and error handling.

<comment><USER16> FWIW, speaking from memory, if QPX, Google's (previously ITA's) low airfare search engine, is any indication, then the lack of any real mention is not surprising because QPX did not make use of parallelization or concurrency. The way it was written made that move very difficult. From what I recall, there was interest in parallelizing some bits of the computation, but I don't recall it ever really going anywhere. (QRES, ITA's reservation system, which was also written in Common Lisp, may have made use of concurrency or parallelization in some way, but my knowledge of that system is limited.)

N.b., QPX did not quite follow all of these recommended practices during my tenure (e.g., ubiquitous SETFing of object slots).

</comment></comment><comment><USER21> nconc over append, lol. You cannot use append when the first list is long, it's way too slow.

The rest all makes sense.

</comment><comment><USER22> Slightly off-topic but is this official, and if so...why is Google hosting stuff on Github Pages? Seems sort of amateurish. Not to mention it belongs to a rival of theirs.

<comment><USER23> Google moved a lot of their open source projects to GitHub after they shut down Google Code. That was before the MS acquisition.

You can find a lot of smaller projects at [https://github.com/google](https://github.com/google), and obviously there are some big ones like [https://github.com/tensorflow/tensorflow](https://github.com/tensorflow/tensorflow).

Notable exceptions are Android and Fuchsia, which have their own hosted git repos at [https://{android,fuschia}.googlesource.com](https://{android,fuschia}.googlesource.com).

<comment><USER22> Thanks for clarifying. It makes sense to host repos on GitHub - it's so widespread - but what struck me as weird was using the.github.io domain, which I usually associate with amateur bloggers who don't want the hassle of registering a domain.</comment></comment></comment>


Show HN: Identifying the DNS server used to fulfill a HTTP request - <AUTHOR> http://5f5.org/ruminations/dns-debugging-over-http.html

<comment><USER2> Out of curiosity, did you see/find my previous comment ...

<http://news.ycombinator.com/item?id=3738542>

?

<comment><AUTHOR> Nope. See the second footnote at the end of the blog post. I just couldn't get the right mix of search terms to bubble up the relevant sites (like the one in your comment!) If it wasn't a hit on a web-interface to nslookup it was a hit about showing your local DNS settings on Windows or Mac.

I get the feeling that there are many incarnations of this same tool being re- invented every so often. What would you use to search for something like this?</comment></comment>


Chelsea Manning jailed for contempt of court - <AUTHOR> https://thehill.com/policy/national-security/433213-chelsea-manning-jailed-for-contempt-of-court <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=19339039](https://news.ycombinator.com/item?id=19339039).

For a mega-story like this, I feel bad that the karma can't be shared across early submitters. Sorry about that. We're going to do something about this eventually.</comment>


Picking a programming language based on personality - <AUTHOR> http://www.softwaresweden.com/2010/04/28/picking-a-programming-language-based-on-personality/

<comment><USER2> Since python wasn't there, I thought I'd fill it in with this reference to xkcd python wiki page:<http://wiki.xkcd.com/irc/Python> Or in my own words, for those who need to prototype and think fast at the speed of running away from velociraptors (or even deadlines and competitors). Agile like a raptor, libraries and frameworks like a T-rex. Simple yet powerful enough to fly with the pterodactyls.

Lisp would've been nice to see there (<http://news.ycombinator.com/item?id=859669> \- the bipolar lisp programmer)

</comment><comment><USER3> The way to pick a progamming language is to understand that you are joining a community in doing so. So the question is, what are the people in my field, or in my office, using? If you use the same as them, you will have access to experience, code libraries, support, etc. If not, there's nothing wrong with that, so long as you are willing to start from scratch. The language you pick has to be _lot_ better for this trade to be worth it (with the exception of fields in which there isn't already an established technical community).</comment>


Wading Through AccuWeather's Response - <AUTHOR> https://daringfireball.net/2017/08/wading_through_accuweathers_bullshit_response <comment><USER2> Weather.gov is the source for most forecasts out there anyway (your TV weather guy is often just regurgitating what NOAA is saying) so I prefer to just get the info from the source and devoid of all the click bait crap that has infested most commercial weather sites.

<comment><USER3> I completely agree. I used to have a couple of pages (across various weather sites) bookmarked but nowadays I just have the "local" page on forecast.weather.gov bookmarked. No ads, no links to clickbait articles, no unrelated crap I don't care about, and it loads a helluva lot quicker and transfers much less data also.

</comment></comment><comment><USER4> I'm a weather app junkie owing to my previous career in airline operations. I've tried (and bought) at least 95% of the decent weather app on Android. Some oldies, but goodies, like Weather Services Pro & Eye in Sky. Currently running Weather Timeline and am fairly happy. (Must have dewpoint data, or no deal!)

But all that flapping was driven by my ditching AccuWeather (Premium) when they re-did the UX in 2013, trading in simple line-art style icons (with theme choices, also) to freaking _photos of the sky conditions_. Completely obtuse and difficult to interpret at a glance. I have a scathing review posted (same nick handle) which I 'touch' every so often to be sure it isn't listed as a review "for a previous version of the application".

So I've been on the "Screw AccuWeather" train for lo these four-odd years now.

Welcome aboard, mateys. :-P

</comment><comment><USER5> weather.gov/5digitzip will take you straight to what you want and is just about as easy as an app for most folks.

Using well-designed government services feels like a good habit these days.

Try it on your desktop or mobile browser, easy as pie: [http://weather.gov/10018](http://weather.gov/10018)

<comment><USER6> Checking the same zip code with weather.gov and weather.com yielded 122KB / 1.6s (weather.gov) and 1.1MB / 18s (weather.com).

<comment><USER7> So we entered the era where government sites are lightweight and responsive while commercial sites are bloated and slow.

<comment><USER8> In my experience government sites aren't usually slow or bloated, they just look shitty.

<comment><USER7> I wouldn't call "shitty" something with a nice layout and readability. "Not trendy" – yes.

<comment><USER9> I wouldn't call the stereotypical government site a "nice layout". It seems like more often than not my experience with government sites is that I have no idea how to find the data I need.

Try finding a campground in Washington in the early spring. Is it open? Do they take reservations? Are they required? Good luck.

Agreed that trendy and usable are unrelated.

<comment><USER10> I've used [https://www.recreation.gov/](https://www.recreation.gov/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> To me, this raises the question of why should this class of behavior pass the app store review process?

<comment><USER11> Yeah—why should apps even be able to _see_ the list of available Wifi networks? Or at the very least, it should require permissions, or maybe they could only see networks from a pre-specified list?

<comment><USER12> At least on Android, I think it does require permissions. The difference is that users have no idea what it is and therefore don't care. It's unfortunate that the list of on-demand permissions doesn't include doesn't include things like local network info (or internet access in general).

I personally give strong NO to any app that requests GPS location and isn't an actual map app, but Google no longer requests confirmation (or even tells you) when apps add new permissions in the same category, so every so often I have to go through my list of installed apps.

</comment></comment></comment><comment><USER13> This has been interesting to follow. I went through something like ten different weather apps before settling on AccuWeather because the app itself is solid (compared to the other free options). Anyone have opinions of other iOS weather apps?

<comment><USER14> I like Weather Underground. It does have ads, but for $2 you can get rid of them for a year I think.

I remember Yahoo Weather had a good UI, but used 200MB+/month of background data even when not in use...

Edit: This is a bit off-topic, but aviationweather.gov has a METAR API that works for any airport: [https://aviationweather.gov/adds/dataserver](https://aviationweather.gov/adds/dataserver)

This is a great resource if you want a specific metric from a nearby reliable source, e.g. air pressure or wind speed.

<comment><USER13> Nice, thanks. I'm sure I checked out WU previously and perhaps I just didn't like the ads. Looking again it is a good interface and $2 seems fine if the alternative is free + suspect tracking.

Yahoo Weather was actually my go-to originally but at some point they made an update that turned the thing in to like 80% ad/20% content. Plus their ads were always pretty invasive.

</comment></comment></comment><comment><USER15> Canada has had Environment Canada's weather reporting for a while:

February 8, 2010: [https://web.archive.org/web/20100208180217/http://www.weathe...](https://web.archive.org/web/20100208180217/http://www.weatheroffice.gc.ca:80/city/pages/on-143_metric_e.html)

Today: [http://weather.gc.ca/city/pages/on-143_metric_e.html](http://weather.gc.ca/city/pages/on-143_metric_e.html)

As a fun extra, I just found an Apps Gallery that uses open data: [http://open.canada.ca/en/apps?_ga=2.119480777.1582349726.150...](http://open.canada.ca/en/apps?_ga=2.119480777.1582349726.1503424264-1037109847.1501179108)

</comment><comment><USER16> This article is based on the iphone app. Does anyone know the situation with the android version?

<comment><USER17> It wouldn't surprise me if it was doing something similar. Why be a shitty privacy invading company on only one platform?

</comment></comment><comment><USER18> Time for the walled garden to throw a few perps outside the walls.

</comment><comment><USER19> >> following the standards and best practices of the industry.

> No they're not.

Afraid they are, and have the spreadsheets to show it.

<comment><USER11> > have the spreadsheets to show it

Please, do—if this _is_ the standard practice, it should be prevented.

</comment></comment><comment><USER20> reminds me of when apple did that same exact thing [https://www.wired.com/2011/04/apple-iphone- tracking/](https://www.wired.com/2011/04/apple-iphone-tracking/)

<comment><USER21> That's not even close to being 'that exact same thing'.

</comment></comment><comment><USER22> Privacy Badger only reported one tracking cookie (google analytics) on OP's site. ;)

<comment><USER23> Is that unexpected?

<comment><USER22> Just seemed ironic in context. HN doesn't, for example.

</comment></comment></comment><comment><USER24> Does anyone expect their information not to be monetized from any "free" application?

(with the possible exception of an open-source application built and distributed by an open-source advocate, e.g. Firefox, K-9 mail, sipdroid, DDG, etc.)

<comment><USER25> This is explicitly against the App Store terms of service, so yes it's unexpected.

<comment><USER26> If you really start taking the App Store terms of service and apply them to the letter to the Apps in the store quite a few very popular apps would vanish.

<comment><USER17> And I wish hey would, for these kind of reasons. So many popular apps flagrantly violate the rules but get to stay because their popular (Uber, Facebook, etc).

Lots of minor ones are seemingly ignored. They break rules too but Apple doesn't seem to care.

</comment></comment></comment></comment><comment><USER27> Question: _Hypothetically_ , if Apple were collecting similiar data that would allow reasonably accurate geolocation of any iOS-running device (without explicit user consent), would this blogger be similarly upset?

In other words, does his protest extend to all _unconsented_ collection of data that can be used to geolocate, or only to collection by certain parties of which he does not approve?

To clarify the term "unconsented", I mean outgoing connections to the third party's servers that are not intentionally initiated by the user.

For example, periodic automatic outgoing connections would be "unconsented" unless the user has to do something to initiate them and is aware she is initiating constant network traffic that will continue indefinitely. (The traffic might plausibly be used for geolocation.)

<comment><USER28> Yes</comment></comment>


Show HN: Material Hacker News interface with preview image and description - <AUTHOR> https://github.com/GabrielePicco/hacker-news-rich <comment><AUTHOR> Wow

<comment><USER2> Laudable programming. Quite possibly the slowest way of reading the site, however.</comment></comment>


Why Midwest Is Best: The Silicon Prairie - <AUTHOR> http://noahbuscher.com/silicon-prairie <comment><USER2> The only advantage listed of the Midwest over the west/east coast is cost of living which you would expect to go up once the long promised "Silicon Prairie" takes shape. Silicon Prairie News is a cool site to see regional news on tech but I've always found it to overhype itself time and time again. There are certainly quite a few growing tech companies in the area in the same way that there were growing engineering companies in the past. It's hard for me to see there ever being a "boom" in tech that makes it comparable to Silicon Valley. We just don't have the investment capital or the human resources to compete despite our cost of living advantages.

<comment><USER3> > The only advantage listed of the Midwest over the west/east coast is cost of > living which you would expect to go up once the long promised "Silicon > Prairie" takes shape.

OK, but right _now_ that advantage is there, so someone considering a move right _now_ would get that advantage.

</comment></comment><comment><USER4> The Minneapolis suburbs are a terrible barren place. Full of crappy cookie cutter houses, white people, panera bread, chipotle, and strip malls. Devoid of anything resembling culture. My condolences to anyone who has to live there.

<comment><AUTHOR> Haha! I do like downtown Minneapolis, but have not spent much time in the suburbs. I'll heed the warning. ;^)</comment></comment>


Otto, the successor to Vagrant - <AUTHOR> https://www.hashicorp.com/blog/otto.html <comment><USER2> Hello everyone! I just wanted to note that I'm running around at HashiConf and likely won't be around to answer as many questions or comments as I'd like. But thank you for all the activity around this and we're excited to show this to you today.

I want to just give a few key notes, though many other folks around here are right.

* For Otto 0.1, we focused on developer experience. We don't recommend deploying for anything more than demos. Future versions of Otto _are_ going to make this production-ready though, and we already have plans in place to do so.

* As others have discovered, Otto is built on top of our other tools and executes them under the hood. We didn't reinvent the wheel, and this has huge benefits. We're dedicated to making all our tools better, and as we do, Otto naturally improves as well.

* Otto is a lot of magic, we're not trying to hide that. It is a magical tool. But we also give you access to the details (OS, memory, etc.) using "customizations." We'll improve customizations and increase the number of knobs over time.

* Vagrant development will continue, we have some major Vagrant releases planned. Please see this page for more info: [https://ottoproject.io/intro/vagrant-successor.html](https://ottoproject.io/intro/vagrant-successor.html)

* Remember that Otto is 0.1 today and Vagrant is 6 years old. We have a long way to go to reach the maturity and toughness of Vagrant. We're committed to make that happen, but it will take time.

Thanks everyone, sorry for not being able to be more active in here. Have a great day!

<comment><USER3> Why isn't Otto named Vagrant 2.0 or something? Its confusing to be "abandoning" Vagrant for a new system "Otto" when really all that is happening is that Otto is fixing issues that have come up over time with Vagrant. Why not a migration strategy, some backwards compatibility during the translation, and then move into the future?

<comment><USER4> It's pretty depressing to see Hashicorp adding more layers to a system that already has way too much accidental complexity.

Ruby on Rails, for instance, is a beautiful example of an internal DSL, but the Vagrant DSL is awful, you could write a much easier to read/use internal DSL in Java.

Then there is the issue that Packer and Vagrant are two different tools. Why should you need to change anything about your provisioners AT ALL when you are trying to burn an image? Doesn't that just defeat the whole point of devops?

And then there is the issue that when Vagrant can't talk to the mothership, it doesn't work right.

It goes on and on. People are screaming out today that "devops is a big waste of time" and I think 80% of that is that Packer and Vagrant are so awful and putting another layer is going to make it 95% awfulness from Hashicorp.

<comment><USER5> I don't agree with everything you've said, but I _do_ feel like otto is in danger of being another teetering piece on top of the base-os/virtualbox- os/vagrant(+ansible/chef/puppet)/guest-application tower, which are all leaky abstractions and all cause problems in practice and make debugging complicated. "Accidental complexity" is the right phrase.

I can't help but think that what the DevOps world really needs isn't another thin layer of magic trying to shellac over the issues of everything below it, but rather to have a hard think and rebuild everything from the ground up with more appropriate primitives. Sort of like what NixOS is trying to do (haven't used it, so can't attest to how successful it has been).

<comment><USER6> Replace DevOps with "web technologies" in general and your statement rings even more true.

<comment><USER4> I think the difference is that in the case of web technologies there are a huge number of competing products: we've had everything from CGI to ColdFusion to PHP to Ruby on Rails to Node.js and we are always learning from what people got right and wrong in the past.

</comment></comment></comment></comment></comment></comment><comment><USER7> I'm not sure if I find it astonishing or expected that somebody finds all that magic good enough to both build that tool and to be thrilled about somebody did. I, for one, find it absolutely unacceptable. The whole point of virtual containers is to have development environment closely resembling production one (not entirely possible, but better than nothing). Your promise that your tool gives me "best possible environment for Python web-app" isn't enough for me, not even close. In fact, I don't really care what you consider "best possible environment", because I already know that there isn't one and I have experienced multiple times these unpleasant moments when you find out that for your app it actually matters if you use Amazon S3 or GlusterFS on real hardware, how many nodes there are, what are exact settings in php.ini or something else you'd be glad not to care for, but you suddenly do care. I don't need magic software, I don't want magic software, I don't like magic software, I'm afraid of it. I really struggle to imagine somebody who isn't a total newcomer and feels otherwise, but apparently there are such people.

What I ideally want is virtual machine based (like vagrant), immutable configuration (like NixOS) approach, with reasonably simple configuration (like docker+fig) and file-based settings (as opposed to docker, where your image is pretty much separate from Dockerfile) with 1 common repo for your "best possible environment" config examples, where every somewhat important decision is explicitly listed and can be changed by user. So something similar (in some sense) to vim-pathogen: git clone, maybe run some other magic command and your env is up and running in several minutes. If contents of config get changed, so does virtual machine.

I understand that what I'd like to have is a bit utopical in today's reality. But nevertheless, Otto is pretty much opposite of what I consider perfect — I cannot imagine anything farther from desirable than that.

<comment><USER8> Yes - one size doesn't fit all.

Yes - sometimes you need something very specific.

But, please - it sounds like you've just damned us to repeat the same low- level tasks again and again.

80% of websites ARE the same. If you're in the 20% (or 10% or 1%) then good luck to you. But for those of us deploying another typical webapp - I'd really like to draw on community knowledge. I never wanted to learn devops same way as I never want to learn cryptography, oAuth, SQL internals, how nginx works etc. I just want to use tools that solve these problems for me.

<comment><USER9> Amen to that. We copy/paste the same Vagrantfile from project to project, making minor adjustments and improvements (typically after some part of the previous file failed on us in a strange way and we dug around for a fix).

The odd time we have some special requirement (a work queue perhaps?), but most of the time it's _language + store + web server_ and we're off.

</comment></comment></comment><comment><USER10> Key takeaways for me:

\- __Right now__, Otto appears to be Vagrant++. I wouldn't use this for prod, at least not for a while.

\- Otto is written in Go. Source is here: [https://github.com/hashicorp/otto](https://github.com/hashicorp/otto)

\- Otto uses a plugin model for different applications. Plugins aren't supported yet. [https://ottoproject.io/docs/plugins/app.html](https://ottoproject.io/docs/plugins/app.html)

\- Built in plugins don't appear to be consuming a sane plugin interface. How the built-in plugins work is non-obvious.

\- Under the hood, Otto appears to be using Packer, Terraform, and Vagrant.

\- I would consider Otto, Nomad, and Terraform to all be "provisioner tools". They seem to be all directly related to tools such as Ansible provisioning, Chef provisioning, Fog, or other direct management tooling, like the AWS CLI or Powershell CLI for VMWare.

\- Otto, Nomad, and Terraform all promise to solve the same problem in prod in different ways:

\-- Otto is a one-off push to set up infrastructure and deploy to prod.

\-- Nomad is for pushing jobs to help maintain long standing infrastructure in prod.

\-- Terraform is for periodic pushes to prod to create idemopotent infrastructure.

In other words, from least to most robust IMO:

Least Robust </comment><comment>-> Most Robust

Otto --> Terraform --> Nomad

<comment><USER11> I think the Terraform/Nomad/Otto hierarchy is _supposed_ to be like this:

      - Terraform defines that you have X servers with certain specs.
      - Otto defines that those servers are running Docker or whatever.
      - Nomad defines that your application is running in X containers in your infrastructure.

So, it's a layered approach (Infrastructure -> System -> Application), akin to the layers of your network. Each one is isolated enough to not worry about the others. At least, that's how I'm hoping this all shakes out :)

</comment></comment><comment><USER12> "Notice that the Appfile makes no mention of OS, memory, disk space, etc. Otto has built-in knowledge of best practices and picks smart defaults for you."

Sounds like a big bag of "nope."

<comment><USER13> Why? This is what I love about Heroku. I get to build the app I want without worrying about all the other aspects of hosting that make me want to never launch an app ever again.

I love the idea of focusing on the development part and letting something / someone else worry about hosting.

<comment><USER14> Have you ever dealt with a large app deployment on Heroku? Unless you're willing to throw money at the problem it sucks.

<comment><USER13> Yes and if you're a small team with limited resources and you don't have an operations person/team throwing money at the problem works.

There will come a time when you will need to setup a more customized hosting solution but hopefully by then you can hire someone to do operations that knows what they are doing.

I don't think Heroku or Otto are designed for big projects anyways, they're a great way to get up and running and help you grow without having to worry about infrastructure upfront or for a couple years.

<comment><USER15> > I don't think Heroku or Otto are designed for big projects anyways.

If you're right about that in Otto's case, that's a bummer. It's frustrating that there is this seemingly intractable divide between things that are great to start with for a new project (Heroku, etc.) and things that scale well as a project grows huge (Kubernetes, etc.). Every time a devops tool comes out, I read about it in hopes that it has both the easy-start and but-scales-as- needed stories, and inevitably find people saying it's actually one or the other.

<comment><USER16> I think the truth underlying that observation is that scaling is always hard. It's relatively easy to pick some defaults that work to get 99% of projects off the ground when they are small, but once you approach real scale inevitably hard decisions need to be made, and those decisions will depend on seemingly minute details of your service's workload. Therefore, tools like Kubernetes necessarily have a threshold of expertise required to use them effectively. I think all of these things are all trending towards more scalable _and_ easier to use, but fundamentally there will always be a tension between those two goals.

</comment></comment></comment></comment></comment></comment><comment><USER17> I use Vagrant regularly for development work and it is a good tool, however, it does still have a _lot_ of issues. I have also gotten the sense over the years that HashiCorp developers could have been more responsive to users and addressed more of the issues that mattered most to the user base.

And now, with a new, complex, and broad product introduced...I just don't have a lot of confidence that the quality is going to be there or that it will ever fulfill the very large goals that are outlined.

I would prefer they focused on Vagrant and made it a really outstanding, polished tool.

<comment><USER18> Maybe they thought the best path to a really outstanding, polished tool was to approach the problem slightly differently and Otto is their solution? If that's the case (I really have no idea), maybe rather than devoting too much time to fixing vagrant they decided to limit the time spent on that to further what they thought is a better overall solution?

<comment><USER17> Yeah unfortunately I think it's more about tackling entirely new problems in addition to the problems Vagrant already solves.

</comment></comment></comment><comment><USER19> Seeing that it uses Vagrant behind the scenes, and other HashiCorp tools as well (meaning it does things beyond just local development environment configuration... which is what 99% of people use Vagrant for), how is Otto "the successor to Vagrant"?

To me, it seems like it's just a bit of word play to try to get more interest in a product that is less interesting to some people. Vagrant is generic enough and helpful enough that it has become one of the two or three preferred tools for building local environments for developers.

AFAIK (anecdotal evidence here, to be sure), other HashiCorp tools are nowhere near as dominant. So is the tagline just to try to get more people interested in the tool?

It wouldn't sound as interesting to _me_ if it were "Otto, something like Heroku but a Go app that uses a bunch of HashiCorp products to deploy apps locally and in the cloud".

<comment><USER20> I think you've pointed out exactly the reason why this product exists.

<comment><USER19> Yes, but I was making the point that the tagline under which this news story was released ("Otto, the successor to Vagrant") makes it sound as if Vagrant is no longer going to be supported, or as if Otto will focus on local development environments, something like that.

In reality, it seems the "successor to Vagrant" line is more to attract attention, as it's not at all a _replacement_ for Vagrant, just a tool you can glom on top of Vagrant and a bunch of other HashiCorp tools.

</comment></comment></comment><comment><USER21> I'm kind of glad to see this, as I wrote [https://github.com/mpdehaan/strider](https://github.com/mpdehaan/strider) for the reason that Packer and Vagrant used different config files.

This appears to address that.

OTOH, it says it's executing Vagrant and Packer under the covers, so I really need some of the Packer limitations I have (like [https://github.com/mitchellh/packer/issues/409](https://github.com/mitchellh/packer/issues/409) ) addressed more than I want glue on top.

Anyway, if people want to hack on Strider, pull requests are welcome.

I'm not using it actively (yet), but it's a very very tiny amount of code to supply both. All the work gets done by boto.

Back to otto - I am curious what otto means when it says it's going to start to talk to infrastructure and means that it's going ot be more of a workflow engine that can also invoke terraform or what.

The DSL changes appear to maybe be a step in that direction?

Would probably benefit from more than one liners on the homepage, to show what is really involved more quickly.

<comment><USER22> > OTOH, it says it's executing Vagrant and Packer under the covers, so I > really need some of the Packer limitations I have (like > [https://github.com/mitchellh/packer/issues/409](https://github.com/mitchellh/packer/issues/409) > ) addressed more than I want glue on top.

Ahhhh that Packer issue. I have been following that one for what seems like years too.

</comment></comment><comment><USER23> So I feel like the reason I like Vagrant is because it does it's one job well, then gets out of my way. Doesn't sound like this shares that philosophy.

<comment><USER24> This addresses a bigger picture that some folks have been (ab)using vagrant to accomplish and requesting features that belonged in a new project, rather than on top of vagrant.

<comment><USER25> Such as?

<comment><USER26> Such as provisioning and deployment I guess... I've seen those requests over and over.

</comment></comment></comment></comment><comment><USER27> _All Ruby development environments look alike, all PHP development environments look alike, etc._

Did they do any user research? Doesn't feel like it based on the above statement.

<comment><USER28> What do you mean? How is the statement false?

<comment><USER29> Ruby: MRI vs. REE vs jRuby vs Rubinius, for starters.

And this choice is solved through a variety of mechanisms that people rely on for other parts of their infrastructure, and feel strongly about.

For my part, this is also a solution that is way too late: We have Docker/Rocket and a range of similar tools. Why do it yet another way, when if you instead build a Docker image, you can take that Docker image and _deploy_ it without having to translate your dependencies to a different format and re- test everything?

<comment><USER30> Docker is a wrapper around Linux. Vagrant is a wrapper around the entire VM [e.g. Virtual Box or VMware]. Thus Vagrant can be used to manage Windows environments. See the list of Vagrant boxes here:

[http://www.vagrantbox.es/](http://www.vagrantbox.es/)

<comment><USER29> Docker can wrap KVM/Qemu, so you can in fact use Docker as a wrapper around the entire VM...

But I take the point - the idea that anyone deploys stuff to Windows is just so foreign to me that it didn't even occur to me.

</comment></comment></comment></comment></comment><comment><USER31> I think HashiCorp did themselves somewhat of a disservice by presenting Otto as a "successor" to Vagrant. Vagrant is a great technology that solves complex problems. Otto _uses_ Vagrant to solve a different set of problems.

Otto is designed to automate the provisioning of local dev environments and production environments. While some use Vagrant to solve this problem, it's typically an un-standardized, home-grown solution. Otto is an attempt to standardize and automate the process.

FULL DISCLOSURE: I've been working on a project for the last year-ish that solves the exact same problems: Easily provisioning and configuring local dev environments and finding consistent parity between dev and production environments. I'm interested to really dig in and see the differences between Otto and the project I've been working on, Nanobox. Would love some outside feedback so feel free to take a look: [https://nanobox.io](https://nanobox.io)

But I digress. I think Otto is less a "successor" to Vagrant, and more of a natural offshoot that solves a different problem. I don't ever see it replacing Vagrant, especially since it uses Vagrant behind the scenes.

</comment><comment><USER32> Looks really cool, excited to see some more detail on how it actually works!

Why the new custom config file format? I've mostly found that these homegrown formats (logstash? nginx?) suffer from inconsistency and lack of flexibility, and don't have any obvious benefits. Why not use one of the following like other Hashicorp tools?

\- JSON/YAML, possibly with support for templating like Ansible

\- A Ruby DSL

\- A limited, but well-tested and understood format like .ini files

<comment><USER33> > JSON/YAML, possibly with support for templating like Ansible

When you are writing templates for your configuration files, what you've wanted all along was a real programming language.

<comment><USER34> Yes and no, a lot of the ops folks I know peter out at pretty basic scripting and find a templating system easier.

<comment><USER35> Actually I'd love to be able to drop down to Python in my ansible playbooks/configs but ansible modules are very different to yaml/template files for the effort.

<comment><USER8> I have some misgivings about Ansible's fundamental design choices. It's main claim to fame seems to be that it sucks less than Puppet and Chef.

I used to really enjoy using Fabric. I only ever tolerated Ansible. I wonder if building on Fabric might have resulted in a better devops tool than Ansible provides.

<comment><USER36> For smaller setups, I've been very happy with Fabric and the declarative configuration addon Fabtools - [https://github.com/ronnix/fabtools](https://github.com/ronnix/fabtools)

</comment></comment></comment></comment></comment></comment><comment><USER37> Fails on Windows:

    		the following errors and try again:

    		vm:
    		* The host path of the shared folder is missing: C:Projectsotto-playground
    		* The host path of the shared folder is missing: C:Projectsotto-playground.ottompiledppoundation-consulpp-dev

    		Error building dev environment: Error executing Vagrant: exit status 1

    		The error messages from Vagrant are usually very informative.
    		Please read it carefully and fix any issues it mentions. If
    		the message isn't clear, please report this to the Otto project.

<comment><USER37> Easy to reproduce, latest everything: otto, Vagrant, VirtualBox

<comment><USER38> "Hah" says the person who is trying to reproduce this in about a month

</comment></comment></comment><comment><USER36> So the supported environments are available at [https://www.ottoproject.io/docs/apps/index.html](https://www.ottoproject.io/docs/apps/index.html), and they're Go, PHP, Node.JS, Ruby, and Docker.

I hope Python gets added to that list as a first class environment in the future.

<comment><USER8> I thought the omission of Python to be... strange.

<comment><USER39> Probably punted because they couldn't decide between 2 or 3.

<comment><USER8> Do you have an axe to grind? It's not terribly hard to support both.

</comment></comment></comment></comment><comment><USER40> I don't understand why so many people are so scared/not interested/afraid of system administration. It's not that hard. Why does it have to be abstracted? Bringing more and more layers makes everything slower, more complex for sure. The only thing is really hard is configuring and managing an email server.

<comment><USER25> I agree, in spirit. Setting up an app server, a web server, a MySQL database, or a cron job is pretty easy once you get the hang of it. There are a lot of complex sysadmin tasks -- running a BIND server, an email server, a Cassandra cluster, etc. -- but that's not what the majority of developers are doing.

<comment><USER35> I don't understand it, but as an SA there's also a lot of people who are incapable of thinking 5 minutes ahead to the next problem - which is also baffling because its pretty much the same as programming.

You setup a cronjob, did you code the script well, who does is notify, how do we know when it fails, what's the recovery strategy?

</comment></comment></comment><comment><USER25> I love Vagrant. At this point, every repo I contribute to has a Vagrantfile. I've turned dozens of coworkers onto Vagrant. That said, I am not a fan of the full Hashicorp ecosystem. Reading through the Otto site, and comments on HN, my first reaction is that my favorite tool has been selected for planned obsolescence.

<comment><USER41> I had sort of the same reaction. I _just_ learned a bit of Vagrant recently. I needed something to set up a simple three-node environment for a tutorial I'm doing, and the best starting point happened to be a Vagrant project. It worked well enough that I've been thinking of other uses for it, especially as a basis for automated tests on the distributed system I work on (our current infra for that frankly sucks).

Then I read this, and it doesn't look like it's a Vagrant successor in any way that's useful to me. I don't want it to try and figure out service dependencies for me, because I can absolutely guarantee that it's unable to do that for the component I care about. I don't want it fiddling with DNS. I think using the same description but different commands for dev vs. production is a _terrible_ idea. They say Otto does application-level instead of machine- level configuration, but machine-level is what I want. They say multi-VM is too heavyweight but that's also what I want. It's opinionated in all the wrong ways. Everything in [https://ottoproject.io/intro/vagrant- successor.html](https://ottoproject.io/intro/vagrant-successor.html) makes it clear that Otto is _fundamentally_ different from Vagrant, which totally belies their claim (at the end) that it will replace Vagrant in any significant way.

They should just come right out and say that they've created something different _on top of_ Vagrant. Maybe it's cool, but it's not a successor. This brand hijacking just makes them seem fickle or shifty. Now I think I'll just leave Vagrant behind while my investment in it is still small, and learn one of the bazillion other tools that I could use to accomplish the same thing.

</comment></comment><comment><USER42> There's a lot of magic here. I'd love to know what's going on beneath the hood.

<comment><USER33> That magic will surely prove to be problematic. I see lots of potential issues. It automatically installs other Hashicorp tools, presumably outside of your system's package manager, which means that it _is_ a package manager in addition to whatever else it does. Where does it install software? How does it verify integrity? Does it build from source or use pre-built binaries? If they are pre-built binaries, how do I get the corresponding source code and build scripts? Does it bundle all other dependencies? How do I make sure I get security patches for the whole dependency tree? I don't expect that Hashicorp would have satisfactory answers to all these questions.

Furthermore, automatic dependency installation sounds like it will make reproducibility difficult, and I imagine automatic application type detection will fail in spectacular ways. What happens when the magic doesn't work? The Appfile looks like yet another ad-hoc domain specific language that you need to learn that has the usual major deficiencies compared with using an existing general purpose programming language.

</comment></comment><comment><USER43> I love the idea in general and especially using git urls as dependencies and use the Appfile from their repos to bring those services (and their dependencies). That keeps ownership to the people best know about it (the developers of a given service) instead of have that centralized. But all this sounds very ambious.

I'm especially curious how to configure dependencies. You might need to creating tables in a database which is setup as a dependencies, but also need to support restoring from backups or setting up replication. Beside that, some of this configuration should belong to the owner of the service using the db (db names etc), other to the owner of the db (global server settings, limits etc). To add to that, some configuration needs to happen at runtime, so you can't just update the Appfile.

Anyway, this sounds like an awesome "UX" \- let's see how it plays out in reality.

</comment><comment><USER44> Does this use Heroku buildpacks or do they reinvent the wheel?

Edit: Otto appears to do a lot of things. But the part that everybody's complaining about is the "magic" part, the part that sets up a system automatically based on the language of the app. Heroku buildpacks also perform this magic, and have been open sourced and have a large community that helps maintain them. They're useful outside of Heroku -- for instance you can use them with docker via [https://github.com/progrium/buildstep](https://github.com/progrium/buildstep)

It seems crazy to me that Hashicorp would try and reinvent this wheel. It's a problem that's fairly easy to do as a proof of concept, but it's the niggling details and number of combinations that can really explode.

<comment><USER45> I've worked on Cloud Foundry buildpacks team. Several of Cloud Foundry's default are downstream from Heroku (Ruby, Python, NodeJS) and several aren't (Java, Go, PHP).

Heroku's buildpacks _are_ open, but they build them for their own purposes. In particular a large part of my work involved recreating behaviours added to support this or that Heroku change (particularly STACK, god what a mess that was), dealing with binaries being silently substituted, the messy statefulness of their staging architecture.

Oh, and most importantly, we made it all work in a disconnected environment. Which Heroku never intended.

Speaking _individually_ , not as a Pivot, if you didn't have to, I wouldn't recommend starting with Heroku's buildpacks. They solve a lot of problems, but no small part is solving _Heroku 's_ problems.

<comment><USER46> It's interesting you say that, because Cloud Foundry recently built a requirement for the environment that runs in their Warden containers ([https://github.com/cloudfoundry/stacks](https://github.com/cloudfoundry/stacks)) into their buildpacks, which caused applications on CF distributions that used other stacks to break when using their buildpacks.

<comment><USER45> I was partly responsible for that work. We did it for the same reason as Heroku: Ubuntu 10.04 passed out of LTS.

CF buildpacks explicitly state which binaries should be used with which stack in the manifest.yml file. If you had a breakage, feel free to report it on the relevant github repo.

</comment></comment></comment></comment><comment><USER47> Why not choose a name that is not already used by other project?

There is already a pretty popular library for android named Otto [http://square.github.io/otto/](http://square.github.io/otto/)

</comment><comment><USER48> "If your application depends on other services (such as a database), it'll automatically configure and start those services in your development environment for you." \-- Can you guys setup some tutorials that show this? Like you have a set of instructions for a Rails AWS deploy, but it would be nice to see like how to setup postgres etc with the dependencies.

</comment><comment><USER49> For the love of all that is holy, why do their sample code fragments have `smart' quotes in them?

</comment><comment> vezzy-fnord If I understand correctly, this is actually a bridge between several existing Hashicorp tools like Vagrant, Terraform and Consul (as hinted in "What is Otto?") integrated into a one-stop solution.

<comment><USER50> Its an abstraction layer that uses them behind the scenes. If it can avoid being a _leaky_ abstraction, it could move away from the current underlying tools to future tools and built-in functionality in the future.

</comment></comment><comment><USER51> > Vagrant is a mature, healthy project that is continuing to grow every day. > We are committed to supporting Vagrant for the foreseeable future and will > continue to release new versions. Otto is our vision for the next generation > and will be developed alongside Vagrant.

Yeah I agree. That's why there will be a time gap between 5 years, until Otto becomes mainstream. The eco-system of vagrant is so good that I even got it supported in my IDE ( WebStorm ). I don't plan to use Otto, before I can enjoy all the benefits of Vagrant that exist today.

</comment><comment><USER52> Real world has taught me 'magic' only works in some specific cases and mine usually isn't one of those. That is why anything that claims to be smart gets to my nerve. Instead, I prefer tools that are clearly scoped, do their own scope extremely well, and designed to complement each and work well together, AND with good documentations. Yes, Unix command line tools are good examples (except not all have good docs though)

There, I will vote for this option against any other tool that claims ability to do things automagically.

</comment><comment><USER53> Wow, there goes my business idea. Kudos.

<comment><USER54> Why? If someone else is doing it that probably means there is a market for it.

<comment><USER53> Sure, but could I compete with free?

<comment><USER13> If you or someone created something that was basically Heroku in a box that could then be hosted anywhere. I would be interested.

I want to build apps, not worry about hosting and servers.

<comment><USER55> Did you try [http://www.openshift.org](http://www.openshift.org)? The self- hosted version is basically what you described, at least for the JVM languages.

<comment><USER13> I have tried it, but just don't hold up as well as Heroku. I still use and love Heroku, but would be nice to have a similar option I could host _anywhere_ on my terms.

<comment><USER45> Cloud Foundry. It runs on AWS, vSphere and OpenStack. Apache 2 license, IP belongs to an independent foundation, not a single vendor.

</comment></comment></comment></comment></comment></comment></comment><comment><USER56> I almost feel like I am in the majority here but I am insanely excited for this.

It is precisely what I have wanted for a long time and the ability to customize and override defaults where wanted seems to handle most of the complaints that people in this thread are mentioning.

I don't think I can underestimate just how much I don't want to have to stay up to date with all the various best practices for deployments. I have zero interest in that and it is currently a fairly expensive problem to fix for many.

</comment><comment><USER57> Otto looks great, and is probably a substantial improvement over Vagrant.

My biggest concern is that it still relies on VirtualBox for local dev. VirtualBox is unreliable and slow, especially its file mounting driver.

I'd love to see this evolve to use a different virtualization solution, maybe something based on the OS X Hypervisor Framework (ala [https://github.com/mist64/xhyve](https://github.com/mist64/xhyve))

<comment><USER58> Vagrant works with parallels desktop (free plugin, requires parallels pro in v11+) and VMware fusion (with a paid plugin)

</comment></comment><comment><USER59> If Otto's Appfile mimics Heroku's app.json file ([https://devcenter.heroku.com/articles/heroku- button#creating...](https://devcenter.heroku.com/articles/heroku- button#creating-the-app-json-file)), that'd be a huge win to me in having more sustainable Rails open source projects.

</comment><comment><USER60> Seems like a good start to a useful project! I'm a bit turned off by the lack of customisation options for the servers though. I would like a bit more options in terms of what gets installed and what not (I don't need Bazaar, Mercurial _AND_ git installed f.e. and I'd like nginx i.o. Apache).

I'll definitely be keeping an eye on the project!

</comment><comment><USER61> Heads up blank page for docs on custom types: [https://ottoproject.io/docs/apps/custom- plugin](https://ottoproject.io/docs/apps/custom-plugin)

Eagerly waiting to see what goes there eventually - very exciting!

Also, will there be a way to create custom Infra Types?

</comment><comment><USER62> Never used Vagrant that much. How does Vagrant/Otto compare to Docker/Docker Compose/Docker Swarm?

</comment><comment><USER63> Really nice to see it. Me and my co-worker had this feeling of needing something like OTTO when first using vagrant... I remember saying that it should definitely be a product. We ended up writing a python script for our user case that makes life really easy for new developers joining us.

</comment><comment><USER64> Does this mean that development focus will shift from Vagrant to Otto?

Is Otto mean to replace vagrant?

<comment><USER65> Maybe, eventually? But not right now.

[https://ottoproject.io/intro/vagrant- successor.html](https://ottoproject.io/intro/vagrant-successor.html)

</comment></comment><comment><USER66> Maybe Vagrant with Docker as backend will get some love now? That is native Docker (ie on a linux host) not just a separate vm to host Docker. The fact that one can't set static ip-address using the Vagrantfile is annoying.

</comment><comment><USER67> Unfortunate name, there's a popular Java open source library called Otto.

<comment><USER68> There are a lot of things called otto - [https://github.com/search?q=otto&type=Repositories](https://github.com/search?q=otto&type=Repositories)

doesn't mean its a bad name

<comment><USER47> Yeah, but look at the number of stars and forks. Square's Otto is a pretty popular library.

Side note: I don't know why someone is down voting people saying this. I mean yeah they will not change their name I guess but it should be bad for the next big project to choose a name that is not taken by a popular project already.

</comment></comment></comment><comment><USER69> One thing Vagrant does right is to use a DSL. I have no idea why this has been abandoned in favor of the common error of inventing Yet Another XML/JSON/YAML/TOML/INI.

</comment><comment><USER70> there is already go project named otto: [https://github.com/robertkrimen/otto](https://github.com/robertkrimen/otto)

<comment><USER13> Last commit a year ago. Unless you trademark a name or at least has active development I don't see anything wrong with using the name.

<comment><USER70> nothing wrong with one year last commit when project's pretty mature

</comment></comment></comment><comment><USER71> I think I'll stick with Vagrant and Ansible.

I'm not going to trade it for magic to be honest. Unless there is a compelling reason to do so that I'm not seeing/reading.

</comment><comment><USER72> Wonder if this attempt will work properly with windows unlike packer and vagrant. Path issues, unreliable builds, ugh. This isn't the portability promise I expected.

<comment><USER73> Strange. What issues were you having?

We've been using Packer and Vagrant with Windows builds for the better part of a year now and it's been rock solid.

We actually leverage it into our Windows Deployment Server to create automatically updated OS Images to be deployed to production machines.

<comment><USER72> WinRM dropouts when building images in packer, random failures that are unexplained, network not coming up in vagrant, consistency.

I've partially written my own version of it in powershell and Hyper-V now.

</comment></comment></comment><comment><USER74> It seems that my ISP is poisoning my Internet connection once again :(

        Error building dev environment: Get https://checkpoint-api.hashicorp
        .com/v1/check/vagrant?arch=amd64&os=linux&signature=&version=: x509:
        certificate is valid for www.example.com, not checkpoint-api.hashicorp.com
        https://checkpoint-api.hashicorp.com/v1/check/packer
        ?arch=amd64&os=linux&signature=&version=

</comment><comment><USER75> How does this compare to azk [http://www.azk.io/](http://www.azk.io/) ?

</comment><comment><USER76> I'm not seeing anything about Python/Django. Will that be added eventually?

</comment><comment><USER77> "The creators of Otto are also the creators of Vagrant. After working on Vagrant for over six years, we've learned a lot and we believe Otto is a superior tool for development plus so much more." \- another successful project written on Go! Nice!

</comment><comment><USER78> Does this work on Digital Ocean droplets? Vagrant doesn't.

<comment><USER79> How so? The DigitalOcean provider for Vagrant works great: [https://github.com/smdahlen/vagrant- digitalocean](https://github.com/smdahlen/vagrant-digitalocean)

</comment></comment><comment><USER80> Something Else!!!

</comment><comment><USER80> yezsutexryckjg</comment>


What can developers learn from being on call? - <AUTHOR> https://jvns.ca/blog/2017/06/18/operate-your-software/ <comment><USER2> These are all good points.

Being on call thought me to design systems in a more resilient way.

I'm not there yet, but I really like Erlang's let it fail approach and the chaos monkey approach. Stuff will break. The more the system has been designed for it the better.</comment>


Ask HN:  Best Developer Tools? - <AUTHOR>

I'm writing a blog post about the best developer tools available at various points in the app lifecycle – everything from design to build to market and monetize.  I put together a survey, which you can access here:
https://www.surveymonkey.com/s/CVMDYQW
Or you can just upvote and discuss as appropriate in comments.  I'll collate the results and share here. <comment><AUTHOR> Cross-platform app development

<comment><AUTHOR> Appcelerator

</comment></comment><comment><AUTHOR> Lifetime Value (LTV) Analysis

<comment><AUTHOR> Kissmetrics

</comment></comment><comment><AUTHOR> Cross-platform game engine

<comment><AUTHOR> Yo Yo Games

</comment></comment><comment><AUTHOR> Social Game Platform

<comment><AUTHOR> Papaya

</comment></comment><comment><AUTHOR> 3rd Party Tracking

<comment><AUTHOR> HasOffers

</comment></comment><comment><AUTHOR> Mobile Ad Network

<comment><AUTHOR> Sponsorpay

</comment></comment><comment><AUTHOR> Appstore SEO

<comment><AUTHOR> Appstore Rankings

</comment></comment><comment><AUTHOR> App Testing

<comment><AUTHOR> Android Emulator

</comment></comment><comment><AUTHOR> Wireframing

<comment><AUTHOR> Wireframe Sketcher</comment></comment>


How American Giant created the best sweatshirt known to man. - <AUTHOR> http://www.slate.com/articles/technology/technology/2012/12/american_giant_hoodie_this_is_the_greatest_sweatshirt_known_to_man.single.html#pagebreak_anchor_2 <comment><USER2> The real innovation was getting Slate to run the infomercial.

<comment><USER3> seriously, I can't figure out how this isn't a commercial post

<comment><USER4> WHY is this the "best sweatshirt known to man"?

The article doesn't provide any information about American Giant's manufacturing or retail processes except that it's all done in the US.

<comment><USER5> It does if you read the whole thing. Here's one reason listed:

 _Why is this hoodie so amazing? First, it's made of heavyweight cotton. Most other sweatshirts on the market today are made of some kind of blend, usually cotton and polyester._

</comment></comment></comment></comment><comment><USER6> Some speculative numbers at the end of the article:

> * American Giant pays the factory about $25 to $30 each, and then it sells > it to you for $60 and up. Compare this to a model under which you'd buy > standard sweatshirt at the mall—say, this $58 Levi's crewneck. The > department store likely buys that shirt from Levi's for about $30. Levi's, > in turn, pays the factory about $12 to $15 for it, and the factory likely > makes it for $6. So you're paying 10 times what the shirt costs to make, and > Levi's is earning $18 per garment. With American Giant, you're paying five > times what the shirt costs, and American Giant is earning $35. Since there's > no retail middleman, everyone does better under the American Giant model—the > clothing company, the factory workers, and you.*

Seems like a lot of cost-savings are actually from throwing out the middleman.

Also, I doubt this is the best-sweatshirt known to man...There must be better ones out in mass circulation. $80 is not very much for a heavy-duty piece of clothing...In NY, high-end stores sell plain white crews for as much as $200 (though admittedly some of it has to do with superficial branding).

I'd expect an upscale mass-produced hoodie, in terms of durability, comfort, look, and neat features, would be at least $200, if made in America.

<comment><USER7> > I'd expect an upscale mass-produced hoodie, in terms of durability, comfort, > look, and neat features, would be at least $200, if made in America.

May I ask why? where's the cost coming from?

Assuming great quality US grown organic cotton; best quality YKK zips; US minimum wage workers; good quality control; distribution and taxes - I still can't get it to $200 without huge markups. (There's nothing wrong with huge markups. Added value is great if you can get it.)

</comment></comment><comment><USER8> I gotta say American Giant gear is pretty great. I am a big made in America fan and when I first heard about them I bought one of their half zip sweatshirts. Order number 212 or so. Came with a signed thank you card from the CEO. The quality is excellent and the look is classic with a great fit. I actually just received my Black Friday order yesterday, the day that Slate article came out. They were out of one of the colors I ordered and I got a hand written note from one of their customer service people. Great stuff, great customer service, great story. Go get some of their gear.

</comment><comment><USER9> To the naysayers: I'd buy it. Would have bought it then and there but they didn't have my size in stock. I would gladly pay $80 for a garment that looks good and lasts more than a couple years - especially if I don't have to go to the mall to get it! When they get my size in stock and I get my order I hopefully wont be disappointed.

</comment><comment><USER10> This article is an interesting read, and fits well with the recent theme of insourcing articles on HN.

However, the author gushes so much about the quality of these shirts that the article feels like advertising. Does anyone have any experience with the brand? Are their products as good as the author makes them sound?

<comment><USER11> Their web site says free shipping both ways and satisfaction guaranteed, so not that hard to find out.

</comment></comment><comment><USER12> This has all the hallmarks of a "PR" story along the lines of: <http://www.paulgraham.com/submarine.html>

</comment><comment><USER13> High quality clothing is not a revelation, but direct-to-consumer internet clothing operations are a great business. Bonobos (<http://bonobos.com>) started out with this model (but now does sell on other outlets), and Everlane (<http://everlane.com/>) is doing an awesome job bringing extremely high quality basics for a very reasonable price by only selling through their own site, and owning the whole thing soup to nuts.

American Giant might do fine, but high quality online-online direct-to- customer clothing stores is not groundbreaking.

<comment><USER14> Can't browse Everlane without signing in with facebook or making an account.

What a great way to put people off. The "shop now" button just brings to login window again.

<comment><USER15> the 'esc' key is your friend :-)

<comment><USER16> ESC + timing. You have to click "shop now" and before the facebook/login prompt comes up, you need to ESC.

Off-putting to say the least. I don't expect high-quality brands to force a membership check before I even examine their products.

</comment></comment></comment></comment><comment><USER17> An $80 sweatshirt? That's considered a "made in the usa success" ? Are they remotely serious?

Put a 10 year replacement warranty on it and maybe.

Otherwise I am sticking to my $8 sweatshirt.

<comment><USER18> In the article, they mention:

> But there is really no comparison between American Giant's hoodie and the > competition. It looks better and feels substantially more durable—Winthrop > says it will last a lifetime.

But I don't know if that's a legally binding statement of any kind. (Though I imagine that if I bought one, and it fell apart, and I made a big-enough stink on a blog, they'd send me a new one just to shut me up.)

<comment><USER19> I wonder about that also. None the less, if they don't offer an actual life- time warranty, they might look at a retailer like REI who accept returns unconditionally. Yes, they're not the cheapest 'outdoor' supplier, but when you take back your ragged tent or whatnot, they've always, well, so far, come correct.

I'm up for a new hooded sweatshirt. I plan on giving myself one of these for xmas. My 40 dollar versions from Gap, etc, usually last two years, so if this lasts 4, I'm even, if more, I'll be more than happy and would not feel 'cheated' out of the 'lifetime' statement.

</comment></comment></comment><comment><USER20> The title of the Article misses the real innovation. The real gem of the article is telling the story of how manufacturers now go direct to public via the internet, thereby cutting out he middlemen.

I am an advisor to a company that enables this very model, and it works very, very well. Essentially we provide the website, marketing, customer service, and logistics from manufacturer-to-customer.

It appears that is what American Giant has found as well. Good for them.

<comment><USER21> You know, things don't exist in a vacuum.

I don't have time to get into specifics, but there is a REASON why channel sales exist. There is a reason you may sometimes want to outsource this to people who specialize in marketing, customer service, or logistics.

As these companies you advise grow in size, you will see why. I'm not saying you don't provide value - I'm sure you do. I'm just tired of hearing this on HN - that a startup can do it all and all these other companies are fools that aren't in on the secret.

<comment><USER20> Agreed -- channel sales work where you don't have that expertise (ie - government, oil-gas, etc). However, my points addresses direct-to-individuals is where this model works well.

I think you read more into my comment that was really there. We certainly are not a fit for every manufacturer out there. But this much is true - Like it or not, the internet beat a path to the manufacturers' door. Many of them are still not prepared to handle that. It never fit their model. That is where we fit in.

If the customer is already st your door, then why not capture the sale? Why send them off to a re-seller? That is a bad consumer experience.

</comment></comment></comment><comment><USER22> I know it may seem strange to pay top dollar for a hoodie, but here in Boston a high quality, durable, and warm garment that you can take with you anywhere is a real comfort.

My current hoodie is the Katahdin Iron Works Heavyweight: [http://www.llbean.com/llb/shop/51722?page=katahdin-iron- work...](http://www.llbean.com/llb/shop/51722?page=katahdin-iron-works- heavyweight-sweatshirt-hooded)

It retails for a similar price and was worth every penny. The AG hoodie is not designed for such cold temperatures, but I would probably be getting one if I lived in NYC (and may still get one anyway, as a liner or just for warmer temperatures).

<comment><USER23> Definitely. I've got that same Katahdin and liked it so much I bought one for my daughter. It's got those little mesh/velcro pockets inside the pockets to keep your keys and such. A little warm for Dallas where I live, but when it's really cold I've loving it.

</comment></comment><comment><USER24> This is how the website looked in February: [http://web.archive.org/web/20110207234611/http://american- gi...](http://web.archive.org/web/20110207234611/http://american-giant.com/)

</comment><comment><USER25> > It looks better and feels substantially more durable—Winthrop says it will > last a lifetime.

who needs a sweatshirt to last a lifetime? when was the last time you wore a 10yr old piece of clothing outside of your own house?

you buy $79 hoodies/shirts for the brand and current trendy design, not to pass on to your children.

<comment><USER26> I have owned and worn several pieces of clothing for more than ten years. Some styles are just classics. I find it odd that one would deride a company for attempting to produce a quality product.

<comment><USER25> I see most people argue the fact that something can be of quality or that you technically _can_ wear old clothes. My point was, current modern fashion empires (Zara, HM, etc.) are popular because they offer fashionable items often of random/poor quality (notice 'because' not 'despite'). Buy cheap, look good for the season, throw it away. One or two levels higher you got all the Tommy, Polo, Lacoste, etc. where you upgrade for the brand and better quality (I know it's still slave labor, but the quality _is_ better). People buy clothes to look good, and buy the ones that look good in their affordable price range. It's how it works, and somehow I believe people wanting to buy a hoodie 'for lifetime' are a vast minority, especially in the hoodie target group. Yeah, I own a jacket which was cool 4 years ago, is cool now, and maybe will be still cool in the next 3 years if I don't destroy it, but durability is IMHO a weak selling point for an newborn apparel company who positions itself in the price range of the lower-end designer brand clothes.

I hope I clarified my opinion a bit, I'm not against quality, I just doubt it will work in the long run for the reasons above.

</comment></comment></comment><comment><USER27> I'm not sure what makes me more upset, the fact that this hoodie costs $80, or the fact that this very kind of story is eaten up by desperate wannabe 20-somethings that are brainwashed into thinking that they deserve the "very best."

<comment><USER28> I think everyone deserves the very best. Why don't you think so? And how did 20-somethings come up?

Personally, I'd rather pay $80 for a hoodie that lasts 10 years than $8 for 1 hoodie a year. Less waste, less exploitative labor, shorter shipping distances (not riding a cargo ship from a Chinese/Taiwanese/etc factory), and a better looking and feeling garment.

</comment></comment><comment><USER29> The only problem with this company is that all their stuff is out of stock!

</comment><comment><USER18> > When you wear this hoodie, you'll wonder why all other clothes aren't made > this well.

And then I'll realize that it's because I'm not going to pay $80 for every piece of clothing I own.

</comment><comment><USER30> I'm surprised they are only doing men's clothing. There seem to be far less men willing to pay for well made or high end clothing than women even though (from my experience), they tend to wear the same clothes longer.

Then again, even I don't really understand the quality difference of clothes made at discount places. How long will an Old Navy sweatshirt last? Or pants?

<comment><USER31> Women don't care as much about quality because they're more concerned about fashion. There's no point in buying something that will last 15 years if it'll be out of style next year. Thus, the more successful approach right now is that of very up to date fashions combined with mediocre quality and sold at an affordable price. This is what Zara is doing so well and why its founder is one of the richest men in the world. Other examples are H&M and Forever 21.

</comment></comment><comment><USER32> I don't find $80 exactly expensive and I'm sure that's a nice product. Yet, it's amazing how prone to simple manipulation people are. You see, that's just a hoodie.

Example:

"He also used heavy-gauge thread for all the seams, creating connections that won't fray."

First, who doesn't? Second, heavy-gauge threads are not more or less expensive than regular, this isn't thread count.

</comment><comment><USER33> "He's making clothes entirely in the United States, and he's doing so at costs that aren't prohibitive"

$80 for a zip up hoodie is prohibitive. Make it $30 and we're talking. That's still almost double what you'd pay in Walmart or Old Navy, but if it's good, I'll take it. $80? No way.

<comment><USER34> It's not really prohibitive. I currently have 6 hoodies with logos on them that were over $50. Most of them are snowboard companies, 2 are colleges. I've probably owned another half dozen similar ones in the past.

I enjoy wearing them for reasons that have nothing to with function. Does it keep me any warmer than one you get at Walmart? Of course not.

There are certainly people that will pay $80 to make a statement that they wear 'the best possible' clothing.

</comment></comment><comment><USER35> "Since there's no retail middleman, everyone does better under the American Giant model—the clothing company, the factory workers, and you."

Everyone except the retail workers.

<comment><USER36> Good.

They add no value whatsoever.</comment></comment>


Inside America's Plan to Kill Online Privacy Rights Everywhere - <AUTHOR> http://thecable.foreignpolicy.com/posts/2013/11/20/exclusive_inside_americas_plan_to_kill_online_privacy_rights_everywhere <comment><USER2> UN negotiations will predictably go nowhere, since the US maintains a permanent seat on the UNSC with veto power. Any "solution" that relies in whole or in part on the US will fail. The US is not a force for good as it may once have been characterized.

I predict in the future we'll see each individual nation lay their own fiber lines and establish IXPs. At the very least it will protect the privacy of internal communications.</comment>


Facebook Employees Speak Their Mind On Holocaust Denial - <AUTHOR> http://www.techcrunch.com/2009/06/15/facebook-employees-speak-their-mind-on-holocaust-denial/ <comment><USER2> Arrington is wrong, because he's said something along the lines of, "Hey I support free speech but Holocaust denial is so bad that I make an exception." Be consistent, Mike. Free speech isn't just for the stuff you like. If you're against free speech, just say so.

Facebook is wrong if they think this is a First Amendment issue. It's not. They are well within their rights to remove any comments that deny the Holocaust. However, it seems inconsistent for them to call pictures of breastfeeding mothers "offensive" and remove them if they're going to allow Holocaust denial on their site.

<comment><USER3> Came here to make the same point about breastfeeding.

 _There is a common theme - that protection of free speech outweighs any damage caused by the existence of this content._

Really? I fail to see this common theme... Let's not pretend that Facebook is a group of libertarian constitutionalists who's first priority is protecting its users free speech rights. I had a friend who was TOSed for uploading innocent pictures from a spa trip where a tiny fraction of a friend's nipple was visible over her towel.

I'm not arguing the plight of my nippley friend, or that Facebook should allow this or that on their (privately owned) web site. Just that this whole Holocaust-denial debate smells like an opportunistic effort on the part of Facebook to portray themselves as protectors of free speech, when that's nowhere near the truth.

<comment><USER4> I don't think you can compare 'nipples' to 'the holocaust didn't happen'.

Sadly, a large number of people are offended by pictures of naked or semi naked people. I don't think so many are offended by historical ignorance :/ Anyway, it's apples and oranges.

<comment><USER2> As furyg3 and I pointed out, if Facebook is going to take a self-righteous "We support free speech on our site!" stand on Holocaust denial, it is absurd for them to ban nipples.

And believe me, a lot of people are offended by Holocaust denial. It probably wouldn't be illegal in many Western nations otherwise. (Many Western countries, aside from the US, are not so big on free speech.)

<comment><USER4> Are pictures even in the same bucket as speech though? I don't see the similarity here.

<comment><USER2> Yes, that's why it's sometimes called "freedom of expression" instead of "freedom of speech."

<comment><USER4> It's probably more logistics though.

Banning nipples makes a clear and easy line. If they didn't have the line there, where would it be? Nudity? erect penises? Hardcore? Logistically they need a line on how they moderate pictures.

Text/groups on the other hand, is just text. Personally, I don't really find text offensive unless it's directed at me or my family, in a threatening way - eg "We're going to hunt axod down and skin him like a fish". If it's just idiots ranting on about how they hate some group of people, trying to ban or moderate that only draws attention to them.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> A fun argument I just made up: liberal folks should encourage diversity of opinion even when it leads to hate crime, for the same reasons that they encourage racial diversity which demonstrably leads to more crime. Otherwise they'd just be using a double standard to attack their ideological opponents.

I wonder if this line of reasoning can be quickly refuted or it contains something deeply true.

</comment><comment><USER6> An interesting article here about a holocaust deniers conference, a recommended read when looking at this issue: [http://www.esquire.com/features/ESQ0201-FEB_DENIERS_rev_2?sr...](http://www.esquire.com/features/ESQ0201-FEB_DENIERS_rev_2?src=rss)

<comment><USER2> That _was_ interesting. Apparently there are nuances even when it comes to Holocaust deniers.

</comment></comment><comment><USER7> SO much fucking bullshit. The 1st amendment says that CONGRESS shall make no law limiting freedom of speech. Facebook isn't the congress, it's a private company; one which apparently thinks the revenue from a few neanderthal racists outweighs that which might be lost from people who take offense. Facebook can do what they want, just as PG can wipe my account for swearing on HN if he sees fit. They own their site, which now includes playing host to a bunch of Nazis, most of whom would be happy to see Mark Zuckerberg die because of his surname.

I fucking hate September. GTFO my lawn.

</comment><comment><USER2> Now that it's been established that Facebook can do what it wants here, I don't think it's such a great idea for them to host this stuff on their site.

Facebook is a popular networking tool, and allowing this kind of stuff there obviously helps grow the deniers' ranks. Remember that even if it's automatic, Facebook is actively putting resources into hosting and serving these posts. You might say they just host everything and it's not like they're picking and choosing what to host, but if they can employ hundreds of people to find and remove breastfeeding photos and the like, they can regulate this as well.

Upon seeing an anti-Semite somewhere preaching his or her bullshit, there's a difference between leaving him or her alone in recognition of free speech rights and providing the idiot with a megaphone. Facebook is doing the latter.</comment>