Why I chose to write Nuuton in Go - <AUTHOR> http://nuuton.com/blog/why_i_chose_go.html <comment><USER3> There is no real substance in this blog post. At the end:

 _I chose Go because it is being developed to solve the same problems I have to solve. All by a group of scientists an programmers that are each twice as smart as I have ever been (on my best day)._

So, _what_ are the problems you are trying to solve? And why can Go solve them better than, Java, Erlang, C++, Scala, or any other language?

If you could answer that question, you'd have an interesting blog post. And if the answer is 'concurrency via Goroutines and channels' (it always is), explain why they are better than Erlang or Akka's actors, STM in Clojure or Haskell, or other proposals, and you'd have a stellar blog post.

But really, this at the top of Hacker News?

<comment><USER4> Go effect.

Do you remember when Rails and Node were every day on HN? Now it is time for Go.

<comment><USER5> Maybe; but that's the way towards progress

<comment><USER4> We have a different opinion what progress means, it seems.

</comment></comment></comment></comment><comment><USER6> Odd choice. A little more research could've yielded a migration to something like Clojure with the benefits of Lisp and an industry-backed stack (JVM).

Of course using an offbeat stack is going to hurt - doesn't mean you have to give up Lisp too.

A decision made odder still since being an independent project, one would think maximizing individual productivity would be the only hope of yielding anything novel and useful in a field like search that isn't a fitting of an off-the-shelf to a business problem. (Something I've done before, it was quite neat.)

Go is _not_ a language focused around individual productivity in any capacity or scope. It's the language of pyramid-building Egyptian Pharaohs. (Throw 1,000 lives at it, it'll get 'er done...)

I say this as someone rather envious of any language that has a native compiler that builds static binaries. (Oh, OCaml...)

As we ponder on what orangetide is up to, lets keep in mind he's not explained or revealed anything at all about Nuuton and for all we know - could be having us on for the sake of self-promotion/promoting Go.

The incorrect speculation about the origins and purpose of Go make this even stranger.

Go exists to make people like Rob Pike happy. The Plan9 and Suckless community of programmers. Those types. That it happened to solve the problems of some Google programmers who were making it was almost incidental.

<comment><AUTHOR> _As we ponder on what orangethirty is up to, lets keep in mind he's not explained or revealed anything at all about Nuuton and for all we know - <USER2> be having us on for the sake of self-promotion/promoting Go._

Well, you are right. I am promoting Nuuton. After a almost a year of working on it and not speaking much about it, I decided to start opening up. I don't want for it to fail due to being too secretive. Time will tell if this is the right decision. But I'm having a great time building in Go. If all fails, I will still have the knowledge of doing it.

 _Edit_

I also considered Clojure. Even spoke about it to some people on this board. But it seemed to take me along the same path Lisp did. Still a fine language, though. I have nothing against it. It did not make much sense in my mind.

<comment><USER6> I'd dearly love to know what about Clojure made it inappropriate for you.

My own path was GW-Basic -> C -> Common Lisp -> C# -> Python -> Clojure, with other languages learned along the way.

</comment></comment></comment><comment><USER7> > _Google started developing Go for one simple reason: to simplify the act of > writing search systems._

Not really.

For one, Google didn't develop Go (it wasn't a company decision to get a new language, as Java was for SUN, .NET was for MS and Dart was for Google). Go was merely started by some a team working at Google as a side project and it grew a little from there. They do pay several people to work on it nowadays, but it's not some "bet the company" language. Also, Google hasn't mandated replacing any C++/Java stuff with Go, and nobody is touching their search engine code. If it happens, it happens organically and for lesser stuff.

Second, Go was developed for "systems" software (albeit in the sense of network servers and such), not search specifically.

<comment><USER8> > Go was merely started by some a team working at Google as a side project

History shows that a lot of extremely successful things started out that way.

> and it grew a little from there

That's a bit of an understatement. Go has hundreds of contributors, and is already used by thousands of companies.

> They do pay several people to work on it nowadays, but it's not some "bet > the company" language.

Definitely not. For that matter, neither is Dart.

> Also, Google hasn't mandated replacing any C++/Java stuff with Go, and > nobody is touching their search engine code. If it happens, it happens > organically and for lesser stuff.

You make it sound like Go isn't being used at Google, which is disingenuous. No, it probably hasn't replaced the crawler and pagerank logic--it'd be silly to rewrite all of that--but it is continuously being picked for new projects internally. Some of the few such projects that have become public are Vitess, the database frontend that powers YouTube, and the code that powers dl.google.com.

(That there is no known mandate to replace existing code isn't indicative of much. It's a bad move to rewrite that much code for any reason.)

> Second, Go was developed for "systems" software (albeit in the sense of > network servers and such), not search specifically.

It started out as a "systems language" (which roughly translates to "for writing backend software", but was commonly misunderstood), however that description has been removed since Go has proved useful in other areas. It is now simply a general-purpose programming language.

<comment><USER9> > It started out as a "systems language" (which roughly translates to "for > writing backend software",

Not really. While Go was presented as suitable for writing classically backend software like databases, it was also presented as suitable for writing compilers, programming tools, debuggers, IDEs, and web browsers, none of which are "backend software."

<comment><USER8> Yeah, that's what I meant by "roughly." I was trying to point out that a lot of people assumed "systems" meant "kernel/real-time development", which Go, while not decidedly bad, is not that well-suited for.

</comment></comment></comment></comment><comment><USER8> To the point that it's developing at a rapid pace: Yes and no. There is a lot of development happening on Go, but the APIs that you can access in the stable releases are not changing behavior.

The Go 1 compatibility contract guarantees that no breaking API changes will happen for many years, barring some serious security issue: <http://golang.org/doc/go1compat.html> If it compiles now, it should continue to compile and work as expected in the future.

</comment><comment><USER10> _I wanted it to be pure Python because I love Python. That is until I had to work with threads. After spending some time working with gevent, I decided to simply use another language to deal with that._

If I could have a penny...

<comment><AUTHOR> May you expand on the comment.

<comment><USER10> It's a common complaint about Python, that's all :)

<comment><AUTHOR> Yes, I know. Had to work on a commercial project that used gevent. Boy was that a mess. The project was a server that had to handle 30K+ hits/second. The client's engineering dept could only get it to do 3K. When I saw they were using gevent (along with a custom framework that lacked any documentation), I knew their goal had a long way to go. Last thing I heard, they were having trouble hiring people to work with it. I'm glad I dodged that bullet.

</comment></comment></comment></comment><comment><USER11> Three rewrites and not yet out of (or even in) beta: <http://nuuton.com/>

If you are seriously hoping for this to be a full time business then I would strongly recommend you read "The Lean Startup" or similar. This blind technical pursuit of perfection is a pretty classic approach for us techies and something i'm guilty of myself. It was actually that process that made me realise what my strengths actually were and what I would need to do to start a world class company (work with great people).

If this isn't really a commercial project then just ignore the above and happy hacking, perhaps you should consider open sourcing it?

<comment><AUTHOR> I'm always telling people here about how they should sell first, and code later. This project has been challenging in that regard, but I have been spending a lot of time figuring out the business aspect of search. It is challenging because one of my main goals is to respect privacy. These days, violating the privacy of the users is a sure way to cash in. But I don't want to do that. As a result, I've had to write a couple of versions to see how it would work out. My current plan incorporates a product line right into the stack. That way, if/when the time comes, I can focus on writing the necessary parts. No need to scramble and try to make it fit.

I do follow the lean principle. But one cannot blindly adhere to them. Nuuton is not the sort of project where you just try and get something to work. There had to be a foundation first. But from now on, development will follow the build-measure-learn cycle. I am open sourcing parts of it. Mostly Go libraries that might result from developing it.

</comment></comment><comment><USER12> And the award for best typo ever goes to:

"[Lisp] had been my sweetheart for a log time."

</comment><comment><USER13> Regarding Lisp

 _Things got complicated quickly. I was writing too much code to achieve simple things. Plus I was writing a lot of one-off code. I prefer to write as much reusable code a I can. Mostly because I'm lazy and I like to keep things simple._

I'd be interested to hear more details on this. Writing non-reusable code and lisp seems antithetical to me. Do you mean the lack of libraries and interfaces to other services?

<comment><USER14> Yeah, it sounds very dubious to me that the amount of code in Go ends up being much less than what's required to achieve the same in Lisp. From what I've seen Go looks verbose in comparison with the lack of macros and higher level programming.

<comment><AUTHOR> It has proven to be less verbose for this project. Probably due to my lack of Lisp skills. I have been in love with Lisp for years, and study it actively. But I'm not a PG with it. Sadly, my natural programming skills are not that great.

</comment></comment></comment><comment><USER15> So I guess if I posted about how I chose C++ and Perl to write Enginuity Search Engine I'd get no love on HN because its boring, stable, scales and just works.

<comment><USER16> Maybe not. Or maybe you would, if your reasoning were well-presented and reflected a logical approach and conclusion, and if it were insightful in a way that people found interesting and useful.

<comment><USER15> Well I might have a go at it soon in our engineering section of our company blog. Have some interesting network performance analysis info to share as well.

</comment></comment></comment><comment><USER17> Wouldn't it be funny if the search engine that replaces Google is written in a language developed by Google?

</comment><comment><USER18> The blog post was written in a variant of the English language called "Fragment".

<comment><AUTHOR> You are right, it is not very well written. It was late, I was tired.

</comment></comment><comment><USER19> Do the personal whys really matter? Its a good young lang that has a lot of promise.

</comment><comment><USER20> I don't know who he is and why he's building a search engine, but I'll upvote this post, since I'm fond of Go as well.

<comment><AUTHOR> I'm a nobody. Just some guy having fun pushing his limits. We don't usually need a reason to hack. The act of hacking itself is the reason. (:</comment></comment>


Eliza explores the dangers of on-demand digital therapy - <AUTHOR> https://www.polygon.com/reviews/2019/8/12/20798997/eliza-zachtronics-visual-novel-review-impressions <comment><USER2> I think the name might be a nod to Eliza, the Computer therapist, first written in the 60s.

Here's an online version [0]

[0] [http://psych.fullerton.edu/mbirnbaum/psych101/Eliza.htm](http://psych.fullerton.edu/mbirnbaum/psych101/Eliza.htm)

<comment><USER3> There's exactly zero chance it's not, which makes this review weird to read. "Eliza mostly seems to listen to its patients a bit before asking leading questions to get them to speak more. I don't notice much insight being offered about their problems." Hardly a surprise for a machine named Eliza, since that's the exact same gambit the real Eliza chatbot uses!

(And that's not what a leading question is! A leading question is trying to provoke a specific answer, not to try and get them to speak generally. "How do you feel about that" is the opposite of a leading question)

<comment><USER4> My take is that, in the game, the Eliza software is extremely overhyped in its capabilities. As a player, you're _supposed_ to develop the impression that it isn't what it's cracked up to be, which is part of what makes the game a rather deft criticism of how so-called "Machine Learning" is used by many real-world companies.

<comment><USER3> It's just weird to read a review that doesn't make that connection, is all.

<comment><USER4> Most people that do not work closely with computers aren't aware of how much smoke and mirrors is involved in the "real" implementations of this kind of technology. (And for that matter, a lot of people who _do_ work with computers are in denial about it.)

I don't fault the creators at Zachtronics for taking a subtle approach to writing the game, but it's a bit of an uphill battle to raise public awareness of the limitations and outright fraud surrounding ML-based products.

<comment><USER3> The original ELIZA program is sort of a special case, since it's _famous_ for being a lookup table consisting mostly of "and how does that make you feel?" and yet still being convincing to a subset of patients who felt helped by it. I think the author of the review just hadn't heard of ELIZA.

</comment></comment></comment></comment></comment></comment><comment><USER5> Context:

> Eliza, the first visual novel from Zachtronics, the developer of Exapunks > and Opus Magnum, explores a reality where digital therapy and AI merge to > solve healthcare at scale. It's a departure from the studio's other titles, > which felt more like puzzle games for programmers. Instead, Zachtronics' new > title is a fully voice-acted, conversation-based story game where players > role-play as a character engaged in a story that changes based on their > decisions.

This is a visual novel game where you play as a human proxy for a counseling AI.

<comment><USER6> In addition to the exploration of using "AI" for counseling, Eliza also features an interesting ethical investigation; you play as the lead programmer who _wrote_ the AI, left the company three years prior to the game's events, and is now taking an entry level job reading the AI-proscribed script to patients. The representation of tech-startup culture can be uncomfortably accurate.

If you were thinking of ignoring this simply because it's a visual novel, remember who wrote it. This is an interactive stor from Zachtronics! Eliza is a visual novel from the same people that wrote the clever "datasheet" manual in Shenzhen I/O and the "zines" in Exapunks. Zach, more than most authors, knows how to write about tech's impact on culture/society!

<comment><USER7> Just wanted to correct that Eliza is actually written by Zachtronics writer Matthew Burns, not Zach, but totally agree on the ethical investigation part.

</comment></comment></comment><comment><USER8> There's a nice long (!) format discussion of this in the last two episodes of the General Intellect Unit podcast. Of course, play it first if you don't like spoilers.

[http://generalintellectunit.net/e/045-eliza- part-1/](http://generalintellectunit.net/e/045-eliza-part-1/)

</comment><comment><USER9> Zachtronics! He's one of my favorite game devs, I'll definitely have to pick this one up as well.</comment>


Embed Node.js on any website - <AUTHOR> http://blog.tonicdev.com/2015/09/30/embedded-tonic.html <comment><USER2> So we brought JavaScript to the server from the browser and now we can embed it back in the browser? Excellent!

<comment><USER3> And with every step the performance gets even worse!

</comment></comment><comment><USER4> Am I right in thinking that this is ipython / jupyter but for javascript?</comment>


Use a Decision Journal - <AUTHOR> https://blog.trello.com/decision-journal <comment><USER2> Also known as a Decision Record, as described by Russell Ackoff in many of his books. Another critical component to include in the Decision Record is not just the decision made, but also the other alternatives that were considered. The documentation should also describe why the other alternatives were not chosen.

Since we can only ever learn from our mistakes, a Decision Record helps us be honest with ourselves when we are evaluating things when they don't go as expected.

<comment><USER3> thank you for the hint. There are many works of Russell Ackoff. Could you recommend one of these for this regard?

<comment><USER4> I would love a recommendation too. This is the first time I've heard of decision journals or records

</comment></comment></comment><comment><USER5> In every team i joined at later stages, it was an uphill battle to try establishing this. In the end i was always the only one maintaining it and management saw it as a waste of time. It is absolutely beyond me why decision journals are not standard. But i guess the source of the problem is that thorough evaluation of alternatives does not show immediate results to PMs and is against most devs "just starting to code" reflexes. Also if your choice is made by thinking "facebook also uses react and i already had to use it at my last job" it would be embarrassing to write this in a public document. (this is true for most EU projects, i really hope its different in the US)

<comment><USER6> I cringe when I come across the aftermath of decisions that sorely needed a reality check from a "just starting to code reflex" prototype or POC. Unchecked by the compiler or the need to actually work, complex design documents tend to derail into fantasy worlds.

I want to read about what you ended up having to do after making contact with the real world, not what you thought you were going to do at the whiteboard stage.

<comment><USER7> I don't think he's saying you should write excessively before doing anything, just that enough context should be given to understand the decision at that point in time. At which point someone should start coding, and after real world experience changes the plan, that too could be added to the decision journal.

<comment><USER6> Which is why I love the idea of a decision journal! Currently we only really document the upfront designs. Ongoing logs would add even more value.

</comment></comment></comment></comment><comment><USER8> I have a Google Sheets … sheet? … for this, and it's been handy.

I'm paper trading the stock market while I work on a couple of investment ideas (and still feel like I'm learning, so no real money yet). Every time I "buy"/"sell" a stock (logged in one tab of Google Sheets), I enter the date and the rationale I used when making the decision (logged in another tab of the same Sheet), as well as some context around the current state of the world. It's been useful already (a few months in), but will only get more useful, I believe, as I begin to note patterns in my own behavior.

</comment><comment><USER9> This is such a simple, clever idea. I make what feels like hundreds of decisions a day (exaggeration but it feels like that sometimes) and I frequently finish the day exhausted and unable to remember anything.

I'm going to whip up a web app for this.

<comment><USER10> I've recently ramped up work on something along these lines aimed specifically at personal finances (see my profile if interested... won't spam this thread). It's a spending journal which helps folks gain insight into their own spending habits and make better spending decisions. I've been using it as my own personal tool for years, and have recently (after being laid off) made it available for more folks.

What I found from my (currently) small circle of users, is that ease of use to enter the decisions was key. The SMS input has been key, and I'd recommend you consider it as a way to appeal to folks who would resist installing "yet another app with who knows what kind of data/privacy practices."

<comment><USER9> This is really great! Good luck with your project

</comment></comment></comment><comment><USER11> Tangential: for me, the buzzfeed-esque GIFs make this post unpleasant to read. I couldn't continue after a point.

<comment> user00012-ab I stopped reading because I can't take articles full of gifs seriously; just content farm crap.

</comment></comment><comment><USER12> The author mentions decision fatigue and then cites that well-known judge study [1], implicating decision fatigue as an observed effect. However, the judges study probably isn't the best example of decision fatigue; see program_whiz's explanation [2] from another thread [3] on the judges study:

> Here is the refutation being referred to in the article, the article author > did a poor job explaining it, and the reason to reject isn't "effect is too > large", because the effect is real -- but this study explains it: > [http://journal.sjdm.org/16/16823/jdm16823.html](http://journal.sjdm.org/16/16823/jdm16823.html)

> 1\. Prisoners are ordered by whether they have an attorney (so those going > last in a session are self-represented)

> 2\. Judges order prisoners often by "complexity of the case", so the ones > taking most time are first (and therefore most likely to have a favorable > decision, a short/easy case is probably a no-parole situation)

> 3\. Statistically, the cases that gained parole take longer than those that > don't, so even if they are random/normally distributed, then if one falls at > the end, it will come back to the beginning of next session. A simulation > shows that even with random ordering, you still get the same graph (because > the long/complex cases that could be paroled tend to be moved to next > session when the session is almost out of time).

> So after reading this, the graph means: Ratio of cases with a lawyer that > can be finished in the remaining time in the session.

> Both values are decreasing as the session continues, so it produces a heavy > down sloping graph that resets each session to some approximately random > value (.65).

[1] Extraneous factors in judicial decisions | [https://www.pnas.org/content/108/17/6889](https://www.pnas.org/content/108/17/6889)

[2] Here is the refutation being referred to in the article ... | [https://news.ycombinator.com/item?id=14703990](https://news.ycombinator.com/item?id=14703990)

[3] Impossibly Hungry Judges | [https://news.ycombinator.com/item?id=14701328](https://news.ycombinator.com/item?id=14701328)

</comment><comment><USER13> Decision record journals can help teamwork, especially when the team also logs the decision alternatives.

Decision record templates are here: Template: [https://github.com/joelparkerhenderson/architecture_decision...](https://github.com/joelparkerhenderson/architecture_decision_record)

</comment><comment><USER14> I kind of disagree with having a decision journal. Because I don't believe you have a set date or action that will mark a decision. And believing that it's what make you procrastinate and delay things.

</comment><comment><USER15> ADR is another form of Decision journal but for technical decisions.

</comment><comment><USER16> for engineers, aka a design doc

</comment><comment><USER17> The animated gifs make me need to write a decision journal to handle this article.

</comment><comment><USER18> I read until I saw "As an article for Farnam Street recommends", and then I stopped reading.

<comment><USER19> What's wrong with Farnam Street?

<comment><USER20> I think they were just letting us know how much of the blog post they read. It could have been that at the Farnam Street mention they suddenly realized they had cookies burning in the oven.</comment></comment></comment>


L. Ron Altman: Why Dead Space 2 is a direct attack on Scientology - <AUTHOR> http://arstechnica.com/gaming/news/2011/02/l-ron-altman-why-dead-space-2-is-a-direct-attack-on-scientology.ars

<comment><USER2> Objectivism -> bioshock

Scientology -> dead space

? -> ?</comment>


Tourniquet - <AUTHOR> http://zareason.blogspot.com/2012/07/tourniquet.html

<comment><AUTHOR> For those following the UEFI Secure Boot stuff, good read. Goes into why this is problematic -- specifically the rebranding of Linux on the desktop as insecure.</comment>


Writing FreeBSD Malware [video] - <AUTHOR> https://m.youtube.com/watch?v=bT_k06Xg-BE <comment><USER2> "Exploit authors don't really care about stack cookies, especially with today's techniques like rop, jop, srop"

None of those suggested techniques address stack cookies but okay, I'll keep listening.

"We can overwrite parts of the heap, the problem is the heap is not executable on amd64 and arm64"

And that's where you've lost me. Processor has no concept of the "heap." Whether or not you can make heap pages executable is up to the OS, and all common OS's let you do this. Not only that, but the browser you're using to view this very page is probably using executable allocations right now to JIT the (very little) JavaScript on this site.

<comment><USER3> I interpreted it as meaning "by default".

<comment><USER2> amd64 and arm64 have no default heap configuration, they don't even know what the heap is. Same is true for their 32 bit equivalents. If he said Linux based OS's or Windows have non executable heaps then I'd have kept watching because yeah you could assume he meant "by default". Instead he blamed the processor and not only that but only 64 bit processors. It's a massive misunderstanding on his part.

<comment><USER3> By default on some os.

Doesn't strike me as a misunderstanding at all—my current cpu/os combo also doesn't ship with an executable heap. This strikes me as lazy editing, but not a clear misunderstanding.

</comment></comment></comment></comment><comment><USER4> Nice presentation.

Is the hardenedbsd web site's security feature comparison table up to date?

Edited to remove comment about my confusion that Carolinacon14 -> 2014; not the case. It's 2018.

<comment><USER5> > Is the hardenedbsd web site's security feature comparison table up to date?

It's misleading, if not outright inaccurate.</comment></comment>


SQL vs. Mongo query - <AUTHOR> http://www.vertabelo.com/blog/sql-vs-mongo-query

<comment><USER2> I'm new to mongo still, but isn't it pretty rare to ever need to make a query like the one in the example with mongo?

My understanding is that the (one of the) whole point(s) of using mongo is that you can organize your data in a nested way so as to minimize the joins needed and just make simple queries, then only use the data you need.

</comment><comment><USER3> I find that SQL is the only language I use where reading a query written by someone else is easier than writing it.</comment>


Twitter CEO Jack Dorsey on edit button: 'We'll probably never do it' - <AUTHOR> https://www.theverge.com/2020/1/15/21066815/twitter-edit-button-jack-dorsey-says-no <comment><USER2> It makes sense given what the Twitter architecture is doing. I would be happy with a "Delete and put the contents of this tweet back into draft mode" like Mastodon has: this would speed the ability to perform the same basic effect of editing.</comment>


What if Gas Cost $100/gal? - <AUTHOR> http://www.theoildrum.com/node/4048

<comment><USER2> If gas was $100 a gallon, I'd have an electric car and hopefully only one car. The real changes would come from society at large. I hope employers would get serious about telecommuting, for as many employees as possible. Maybe they'd get more serious about using satellite offices.

I'd use electronic means to communicate more and more and I assume others would as well. It would have to bridge the gap of distance that separates us. I'd probably get to know my neighbors a lot better as well. I'd go local for more than food. I'd have no choice.

<comment><USER3> Would electricity costs be relative enough for an electric car to still make sense? What about goods and products that you buy that's shipped on the massive fleet of trucks?

A sudden surge to $100 a gallon gas destroys civilization.

<comment><USER4> Rail. Ships with sails.

Humans can take a lot more shit than they are given credit for.

<comment><USER5> Warren Buffet invests in trains: <http://www.cnbc.com/id/20519680/> Freight ship with parachute-like sail: <http://www.shippingtimes.co.uk/images/Beluga_SkySails.jpg>

<comment><USER6> Interesting idea, but that sail looks tiny for that size ship. I can't imagine it does much.

<comment><USER7> The sails in the picture are being winched in. Normally, they fly like a kite, about 200 m above the ship, and tow it forwards. The winds are much stronger up there. It also looks like the kite has been partially furled - the picture on Wikipedia looks much bigger:

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

</comment></comment></comment></comment></comment></comment><comment><USER8> Since there were so many scaremongering articles in the news lately, I thought about the same problem recently.

I guess I should be worried, but honestly my first thought is always "finally we'll get rid of those pesky cars". I hate cars so much (swallowing their exhausts every day cycling to work), that I think my joy over car-free cities will outweigh most downsides of the expensive energy.

Personally I don't need a car, I could probably do without a fridge, and I don't really need long distance travel very much. Heating could be a problem.

<comment><USER9> If you'll forgive me, that's a very metropolitan attitude. For huge swathes of the country (including, umm, the bits that provide all the produce to the stores so you can shop whenever you feel like and don't need the means to transport large loads yourself) motor vehicles (including pick-up trucks and other "gas guzzlers") are pretty much essential.

It's all very well to be smug about how high gas prices hurt yuppies in SUVs, but they hurt lots of regular working folks too.

<comment><USER5> How feasible is using horseback for small distances?

<comment><USER10> Horses are quite inefficient; in fact, all animals are. The only reason it's cheaper to ride a bicycle someplace than a motorcycle is because of the lesser weight and speeds; if you created electricity with a human-powered generator like [this](<http://www.los-gatos.ca.us/davidbu/pedgen.html>), you'd actually burn more energy in extra food than you would by getting the same amount of electricity from a gasoline-powered generator.

...which, of course, isn't a direct concern since many people bicycle for their health anyway. But it is a concern when it comes to more equine suggestions.

</comment></comment></comment></comment><comment><USER11> Basically we'd almost all starve to death. Transporting food would become uneconomical. Hell, harvesting food would become uneconomical. The trickle of food which got into urban areas would sell for insanely high prices. The rich would still be able to afford it for a while, but with the whole economy collapsing and widescale starvation the rich wouldn't stay that way for long. Rural folks might be able to survive for a while, until the looters came pouring out of the cities and into the countryside (on foot, presumably) looking for food.

Eventually we'd be able to re-establish some kind of civilization (pseudo- steampunk?) with a severely reduced population, but there'd be all sorts of bad stuff to happen in between now and then.

<comment><USER12> Yea, once I started thinking about the obvious kinds of things you mention, I couldn't take the article's premise seriously any more.

</comment></comment><comment><USER13> $100/gallon gas would do a lot more than slow down commuting. It would make air travel prohibitively expensive (thousands or tens of thousands to fly anywhere - fuel is already the biggest cost at any airline with $100/barrel oil). Shipping would also be seriously impacted; the 20% savings on a radio made in China would be offset by transportation costs. $4 winter strawberries from Chile would be no more. That, and global recession. Personally, sounds to me like some good and some bad.

</comment><comment><USER14> I hope most people will be biking long before we get close to that level:

<http://bikeworker.blogspot.com/>

<comment><USER15> Exactly.

 _Oh, they might buy a smaller car, but they aren't going to start walking 3 miles to the store._

Of course nobody is going to walk 3 miles, that's stupid. However, riding 3 miles on your bike is trivial. You'll be there in 15 minutes. I do this about twice a week, and driving wouldn't be any faster than biking.

I think the reason people don't consider biking is because bikes in america are weird. Everyone wants to get a very cool mountain bike. Then it rides poorly on the street, and it can't carry anything, so they assume bikes are useless. I noticed that when I was in Tokyo, every bike on the street was of the useful variety. They all had chain guards, fenders, and racks, which makes casual riding an enjoyable experience. Maybe if you could go to a bike shop and see bikes like this, people would use them for grocery shopping.

In the US, it appears that most people think bikes are a fun thing to ride to kill time on the weekend. I wish we could change that perception somehow.

</rant>

<comment><USER16> > Of course nobody is going to walk 3 miles, that's stupid.

What is stupid about that? Every day at lunch a group of 4 of us go on a three mile walk. Most days we stroll and it takes an hour.

      If I had my own cart I could certainly do that once a week.

OK, so no more meat every day, but I could still have eggs every day and milk some days. And I still wouldn't need to use any refrigeration. And since I live within 3 miles of several farms and have a bike, I could make a few milk/meat trips a week. I would probably be drinking sheep's milk and eating mutton more, because that is what is close, but that still sounds fine.

</comment></comment></comment><comment><USER17> What if pigs could fly?

EDIT

To clarify, it's ridiculous to just make a conjecture like this and build a case around it. The same thing could be done for anything else, not just gas and the current state of the economy. If the foundation of the article is this wild, then any of its conclusions are just as off-base and pointless.

<comment><USER18> 1\. How do you know that the foundation of this article is wild?

2\. Have you read the article? It's a thought experiment. It's meant to provoke thought and discussion. He's asking people to consider and share what they would do if gas hit a price where business as usual was clearly untenable and there would be no choice but to change consumption patterns.

</comment></comment><comment><USER19> At some point it becomes economical to synthesize fuel using nuclear power plants. I would expect this to be well short of $100/gal.

</comment><comment><USER20> America would look a lot like it did during the Great Depression. People wouldn't travel much, more things would be produced locally because shipping would be expensive, people would live closer together (both in proximity and density), people would eat local produce because out-of-season foods would be expensive to ship, etc. Things like digital content, electronics, etc would seem extremely cheap ($500 for iPod touch or 5 gallons of gas), while other things like wine, strawberries, air travel, etc would be extravagant luxuries. It wouldn't be like the poverty of the great depression, but a lot of things we take for granted now would get very, very expensive.

On the other hand, the high shipping costs would make local labor a lot more economical for manufacturing, maintenance, etc.

<comment><USER7> People traveled _a lot_ during the Great Depression. That's when hobos, okies, migrant workers, and Route 66 entered popular culture. Much of California was settled during the 1930s, as emigrants from the dust-bowl states moved to the Central Valley and LA areas. One of the fastest-growing professions was "gas station attendant", and the Depression years featured the consolidation of the auto industry.

<comment><USER21> Yep, a lot of us would have to adopt the hobo life and cut other people with our hobo knife.

</comment></comment></comment><comment><USER22> Just for posterity, and so I can look this back up in a year's time, but.. I predict an oil price crash by this time next year. If we're not under $50/barrel by summer 2009, I'd be surprised.

I can't cite any great insights here, but I've tended to notice that when everyone jumps on the bandwagon of saying something bad is going to happen, some price is going to rise forever, or the like, the opposite tends to occur within a certain timeframe. It's now happening with property prices (and I remember the bulls just one year ago..) and it'll happen with oil. Same happens with memory prices too.

<comment><USER21> That's hard to say. One can make the argument for a price crash as speculators have flooded into the oil and commodities markets and bid up prices. There is a lot of fear of peak <insert finite natural resource>. Once people got tired of it, prices would drop.

On the other hand, oil is a finite natural resource that has been pumped out of the ground for decades at an increasing rate. Only severely retarded politicians don't believe in peak oil or believe that oil is an infinite resource (they also believe in ghosts, so there). Thanks to China, India, and other countries deciding they want some basic level of civilization, the rate of increase in the rate of increase of demand means oil supplies and proven reserves are going down fast. That means there might not be a price crash and in a few years we will look at $6/gallon for gasoline as the good ole days.

<comment><USER22> Everything is finite. It all depends on /how/ finite things are. Technological advances, increases in efficiency, and the influence of competing technologies (electric, hydrogen, liquid propane gas, and so forth) will all have a role to play.

It is typically very hard to accept that these things can have a big effect, but that doesn't mean they won't (nor, of course, that they must, but the odds are better that they will). The price of oil will be as "immaterial" within 50 years as the prices of horses or gas lamps were immaterial in 1940 compared to 1890.

</comment></comment></comment><comment><USER23> This is the wrong question.

The real question is:

What will be the economic and social implications if the current trend (up) of commodity prices given the timeframe (fast) were to continue.

Just to note: statistically, oil prices peak around this time. Oil prices do tend to be seasonal, so be on the lookout for that.

</comment><comment><USER24> I already started an article "In Defense of $20/gal gas" on

[http://showtimeoncapitalism.blogspot.com/2008/05/in- defense-...](http://showtimeoncapitalism.blogspot.com/2008/05/in-defense- of-20gal-gasoline.html)

I got bored and quit because I thought it was pretty clear to anyone with relative intelligence exactly what would occur.

</comment><comment><USER25> I'm just waiting for the Ron Paul posts now, and the transition will be complete...

<comment><USER26> Cycles of stories happen here, this peak oil post was triggered by the higher voted electric car conversion story. It'll be gone in a day.</comment></comment>


A nose by any other name would sound the same, study finds - <AUTHOR> http://phys.org/news/2016-09-nose.html <comment><AUTHOR> Original article behind a pay-wall: Sound–meaning association biases evidenced across thousands of languages, PNAS, [http://www.pnas.org/cgi/doi/10.1073/pnas.1605782113](http://www.pnas.org/cgi/doi/10.1073/pnas.1605782113)</comment>


Show HN: Zube 1.0 – Powerful project management for GitHub Issues - <AUTHOR> https://zube.io/v1 <comment><AUTHOR> Hi! I'm Jen, cofounder of Zube and we're thrilled to announce Zube 1.0 today. Zube 1.0 is much more powerful than our beta version. We've added Zube Tickets, which lets you create tickets that track groups of related GitHub issues. Think ZenDesk for Github. We've also added an issue manager, which is the fastest way to find and triage your issues on any platform. And there have been many improvements to our scrum/kanban board like a new pull request section and burndown charts.

We'd love to hear what you think of Zube 1.0 and I'm happy to answer any questions you have in the comments here!

<comment><USER2> Hey Jen,

Congrats on 1.0. Our development team uses a micro service architecture that has 1 project spread across multiple repos, and I think the biggest problem with most project management software with extensive Github integration is that they are on a per repo basis. We can never get a holistic view of our entire application without duplicating work into another Project Management platform. Is there anything inside Zube that would alleviate this? How does Zube handle multiple repos for teams?

<comment><AUTHOR> We're working on implementing multiple repos on one board right now and will have that feature out in a couple of weeks.

Are you looking for adding several repos to one board or do you need a board that displays issues from one or more repos as well as non-issue backed tasks?

<comment><USER3> Just one board for all projects _per organization_, please.

I want to keep separate boards for my private projects, but one board for all backend related projects (backend- _, aports-_ ) in another organization.

<comment><AUTHOR> Cool! That's how we're implementing it.

<comment><USER4> Will it be possible to group a number of repos inside one org as well? E.g. repos A and B form one group and repo C is separate?

<comment><AUTHOR> Yep, that's the game plan!

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Oh, this is really cool. So when I create a "card" on zube, it automatically creates an issue on github. And when I drag the card to "done" on your trello- like board, it marks the issue as closed in github. The zube interface definitely adds a lot of clarity with colours and birds-eye view. I'm excited to use this! I think the onboarding could make it easier to quickly understand this much (initially, I falsely assumed a "ticket" corresponded to one github issue).

I just pushed to github with a commit message that closed the issue, (git commit -m "... closes #1", as per [https://help.github.com/articles/closing- issues-via-commit-m...](https://help.github.com/articles/closing-issues-via- commit-messages/)) and sure enough, the "card" is now marked as complete in zube, with a handy hyperlink to the corresponding commit in github. The instant email confirmation ("Ticket #n closed") from Zube could be pretty handy too, as the team grows. Nice work!

<comment><AUTHOR> Thanks for signing up! We definitely have some work to do with the on boarding flow and documentation, especially around Tickets. Glad to hear you were able to figure it out! :)

A Ticket is a place where you can link together multiple GitHub Issues that doesn't sync with GitHub itself. The Ticket tracks the status of those issues and updates it's status as the issues are worked on. This works great for bug reports that need multiple tasks completed in order to be resolved, for example.

</comment></comment><comment><USER6> Oh nice! I like the ability to assign Issues by just dragging to a user and the "Batch Editing" UI is pretty concise! Also, being able to create an Issue without having a GitHub login seems helpful to get non-developers communicating.

I'm a developer that grew frustrated with so many ticket tracking solutions that force users to use the UI (Waffle and ZenHub store metadata that is not in GitHub), a lack of hackable options, and making it difficult for non- members to be involved in what's going on in a project. So, I created [https://github.com/philschatz/gh-board](https://github.com/philschatz/gh- board) .

Some features I haven't seen anywhere else, that gh-board does are:

\- real-time collaborative editing of Issues

\- showing related Issues/PR's

\- shareable URL's (for remote folks)

\- sequence diagrams, gantt charts, etc

\- CI and merge conflict status

\- "deployable" anywhere (using gh-pages or nginx)

Like other solutions, it also supports multiple repositories, Drag-N-Drop, milestone planning. In the _very near_ future it will have a burndown chart, batch editing, Issue creation, and load faster (using IndexedDB).

<comment><USER7> I've used gh-board before and really like the ability to "merge repos" You can view all the PR's across multiple organizations and repositories, which makes it very handy for someone who's a member of multiple projects. Plus it's open- source!

</comment></comment><comment><USER8> We've been using Zube for several months now and are really impressed with how fast the team has turned this into such a powerful platform. We quickly switched from ZenHub to Zube because of how fast and easy it was to prioritize issues and manage dev sprints (using milestones).

<comment><AUTHOR> Thanks for the kind words! Glad to hear Zube is working for you! :D

</comment></comment><comment><USER9> How does Zube do in terms of performance when loading up?

One of my biggest issues with Waffle or Zenhub is that loading them up is often a long wait- Zenhub can be 3-4 seconds(and often is just incorrect in labels/assignments), and Waffle could be upwards of 15 seconds.

Does this do any caching on Zube's side and then real-time update it as it goes, or am I in for a long wait again regardless?

<comment><AUTHOR> Great question. We built Zube is speed in mind even for repos with hundreds of open issues. If you have over 1000 open issues you'll probably notice a lag on any platform and it will take about 2 seconds on Zube. We're obsessed with speed and we'd be happy to work with you to make things fast!

</comment></comment><comment><USER10> Awesome work! I love how simple it is while still adding so much.

I know you've mentioned this elsewhere, but I was a bit confused by the tickets. I get what they are, but who is the intended user?

One feature I'd like to see is custom statuses. I personally am a big fan of "In progress -> Pending deploy -> Verify -> Done" instead of just "Done". It makes it really clear what just went out with every deploy, and allows the person who originally filed the issue to be the final arbiter on whether or not it was actually solved.

Another cool things would be integrations! If you have a ticketing system, it would be great if that tied into the tools that the customer support teams use. I use intercom myself, and it'd be handy if I could create a ticket out of an intercom request and remember to follow up with that user after the fix is deployed.

<comment><AUTHOR> Thanks! We created tickets with non-technical people in mind as way they could report bugs, feature requests and the like without cluttering up issues for developers. Since the tickets track the work on their linked issues, the ticket owner has a clear picture of what the progress is on their ticket.

However, we've also seen dev teams hack tickets as a way to scope groups of issues together, for a feature release for example, similar to epics in Agile workflows.

Would you like to see custom statuses on board, the tickets or both?

We are really excited to add more integrations! Slack, ZenDesk and Intercom are some of the big ones we're looking at.

<comment><USER10> Oh I was thinking of the board, not tickets. But perhaps it's more relevant in tickets? I'm not sure, just an idea.

Years ago I worked at a company that had a jira flow that worked with those stages for tickets and I thought it was great. Haven't been able to replicate that workflow since.

<comment><AUTHOR> Gotchya! We've been thinking about how to add some flexibility to the columns without falling into the 'endless column' trap where teams end up with dozens of micromanaged columns. It sounds like that level of organization would still fit the paradigm.

</comment></comment></comment></comment><comment><USER11> Very nice tool, looks really polished and very functional! A while ago I also built an open-source Kanban board for Github issues using React.js and Material Design:

[https://adewes.github.io/gitboard](https://adewes.github.io/gitboard)

Unlike Zube and other tools (e.g. Huboard) you can use Gitboard without giving anyone else acccess to your Github repositories, i.e. it runs completely client-side within your browser and without an intermediate server between you and Github. Currently it has much less features than Zube though.

It uses the Github API via AJAX and stores your login credentials in the session storage of the browser. Here's the Github repository:

[https://github.com/adewes/gitboard](https://github.com/adewes/gitboard)

</comment><comment><USER12> Any plans for Gitlab support?

<comment><AUTHOR> We are definitely interested in adding GitLab support as well as other integrations though I'm not sure when we'll get there.

<comment><USER13> Good to hear! Let me know if you have any questions, we're happy to help.

</comment></comment></comment><comment><USER14> Really big fan of this approach - link the work up with the thing tracking the work as closely as possible. At Etsy we use Github and JIRA separately and I personally think it'd save time and reduce confusion if we were to move to something like Zube. Nice job Jen!

<comment><AUTHOR> Thanks Jason! That is exactly where the idea for Zube came from! Trying to keep two (or more!) data sources in sync is error prone and just generates extra work for everyone. We made Zube to combat that problem.

</comment></comment><comment><USER15> This looks really cool and is something I would love to check out, but the permissions of the actual app seem pretty high. For us, our code is stored in a private repository with no plan for any public release. Permissions for Zube are asking to not only read the private repository code, but also have write access to them as well. There's also requests to read/write web service hooks, deploy keys and pull requests. Is this a byproduct of Github's design or does the app really need all of these permissions to function properly?

<comment><AUTHOR> We totally understand your concerns and we take security very seriously. In order to manage GitHub issues, GitHub currently requires the repo scope. If there was a more restrictive scope just for GitHub Issues, Zube would use that one instead, but there isn't. Zube requires the same permissions as many other applications, the same permissions as Slack, for example.

On our side, Zube only accesses data related to your GitHub issues and never touches your code at all. All of the calls Zube makes to the GitHub API are whitelisted (on our end) to ensure that Zube only accesses the data it needs. For extra security, we also encrypt your auth token before storing it. It's also important to note that your auth token is specific to Zube and at any time you can revoke your token on GItHub.

<comment><USER15> All that makes sense, thanks for the details.

</comment></comment></comment><comment><USER16> Estimation is a killer feature missing from Github Issues, and it looks like you've got a points estimation feature, which is great.

Any plans to add hour-based estimation?

<comment><AUTHOR> That's a great idea and would be pretty quick to add. Would having either points or hours for a repository work for you?

<comment><USER3> If in hours, then implement it as combobox with predefined list of standard estimates (1h, 2h, 4h, 1d, 2d, 3d, 1w, 2w, 3w, 1m, 2m, 3m, 6m, 1y).

<comment><AUTHOR> Got it! That makes sense, thanks for the breakdown.

</comment></comment></comment></comment><comment><USER17> This looks really awesome, best implementation of this I've seen by far

Personally, I'm really excited about this, but I also imagine a lot of companies might use BitBucket for its free private repos.

The only think I kinda wish for is a way to see an overview across all repos. The GitHub issues dashboard is so awful that I wish someone could take over that job.

<comment><AUTHOR> Thanks for the kind words! We started with GitHub because that's what we know and love but down the road we'd love to add more integrations like BitBucket.

Multiple repo views is a great suggestion. We're working on it now and we will have it out in a few weeks!

</comment></comment><comment><USER18> This is great.

Trying to keep project management synced between Trello and GitHub is busywork. GitHub is a major source of truth for a project, so tools that manage it are really great.

I'll be giving Zube a spin.

<comment><AUTHOR> Awesome! Let me know if you have any questions. I'm happy to help!

</comment></comment><comment><USER19> Hey, any plans for Gitlab support?

<comment><AUTHOR> We'd really like to add other integrations like GitLab. We do have a bit of work to do on our core product first so it may take a little while before we get there.

</comment></comment><comment><USER20> Is this an extension or a standalone web app?

<comment><AUTHOR> Zube's a stand alone web app. Your Zube cards are two-way synced in real-time via the GitHub API.</comment></comment>


The end of CyanogenMod - <AUTHOR> https://lwn.net/Articles/710136/rss <comment><USER2> [https://news.ycombinator.com/item?id=13249307](https://news.ycombinator.com/item?id=13249307)

</comment><comment><USER3> What the hell has actually happened? Neither the link, the Cyanogen website nor the comments here really explain it.

</comment><comment><USER4> Turns out naming things is an even more difficult problem than we thought

</comment><comment><USER5> this is about cyanogen inc., not cyanogenmod.

tl;dr: CyanogenMod isn't going anywhere

<comment><USER6> Your TL;DR is incorrect or misleading. CyanogenMod is dead.

<comment><USER5> No, it's just going to be rebranded and disconnected from the (dead) company cngn inc. - cyanogen himself even confirmed this on twitter

<comment><USER6> "It will come as no surprise that this most recent action from Cyngn is definitely a death blow for CyanogenMod."

[https://www.cyanogenmod.org/blog/a-fork-in-the- road](https://www.cyanogenmod.org/blog/a-fork-in-the-road)

It's a complete fork from CyanogenMod to be called Lineage.

[https://github.com/lineageos](https://github.com/lineageos)

<comment><USER7> Plus Lineage seems like a much better brand name than CyanogenMod for mass adoption.

Though I would've called it Cyborg or something more analogous to Android.

<comment><USER8> I always thought "TrueBlueOS" would have been a good name for the open source version...

<comment><USER9> But then the confusion with TrueOS (prev. PC-BSD).</comment></comment></comment></comment></comment></comment></comment>


Jason Fried: Education As A Customer Acquisition Strategy - <AUTHOR> http://blog.betterlabs.net/jason-fried-education-as-a-customer-acquisition-strategy/ <comment><USER2> The player is super slow. Here's the download link.

<http://blip.tv/file/get/BIF-JasonFriedAtBIF4360.mp4>

<http://blip.tv/file/get/BIF-JasonFriedAtBIF4476.flv>

</comment><comment><AUTHOR> Found via: [http://jasonlbaptiste.com/startups/distribution- distribution...](http://jasonlbaptiste.com/startups/distribution-distribution- distribution/)</comment>


Sway.fm keeps a universal library of top songs you discover online - <AUTHOR> http://sway.fm/?utm_source=ycombinator&utm_medium=newsstory&utm_campaign=selfpromo

<comment><AUTHOR> Following on what Rdio VP of Engineering, Todd Berman recognized recently about streaming music: The streaming music space is too divided. <http://goo.gl/MZJth>

For listeners, that means it's hard to keep track all the music you enjoy on different apps. Sway.fm aims to fix that by automatically collecting the songs you Thumbs Up, Favorite and Like in your universal library (including syncing with Spotify and Rdio playlists). <http://goo.gl/tvl7m>

You can get our Chrome extension which lets you play/pause/control the music streamed from all the sites we support using your hardware media keys: <http://goo.gl/5V7Zd>

We're also looking for a couple key API partners to hook partner with, so we can stop hacking on top of your stuff. :) Let your listeners keep the music they find, and show up in your app with all their favorite tracks!

Want to hit us up? email@example.com || @swayfm (tweet tweet!)</comment>


Hands On Review of the HTC One (M8): Simply the Best - <AUTHOR> http://thegadgetflow.com/blog/hands-review-htc-one-m8/

<comment><USER2> HTC One M8 Beats Apple iPhone 5S In Touch Response Time. Smartphone makers and fans have always declared that better specifications are what makes their devices stand out from others. Many smartphones claim they are the best simply because they have better camera, processor or longest battery life. While all these factors play a key role, there are a few that truly affect the device experience, and display latency is one such overlooked factor. Older devices have latency between 80ms-250ms, meaning it takes almost a quarter of a second to respond to every touch. This is most common on apps which require dragging fingers across the screen. Delayed touch response time increases the possibility of inaccurate touches and the device will feel less responsive. [http://www.dazeinfo.com/2014/04/14/htc-one-m8-apple- iphone5s...](http://www.dazeinfo.com/2014/04/14/htc-one-m8-apple- iphone5s-fastest-touch-response-time-sales-q1-2014/)</comment>


Puppet versus Chef: Why Puppet wins - <AUTHOR> http://bitfieldconsulting.com/puppet-vs-chef

<comment><USER2> Chef still feels like a set of disconnected tools waiting for somebody to integrate them nicely. The codebase is rather volatile (coming back to it after a few months required a lot of extra work) and the documentation right now is definitely poor.

That said, I think Chef has a lot of potential. It's just waiting for a solution that brings it all together. I'm highly looking forward to the upcoming opscode-managed Chef server. I'd like to see something like Heroku, where deployment is simple and easy, but is based on community-provided recipes (instead of Heroku-provided addons) and is closer to a fixed monthly cost (to provide the chef server) instead of a per-server-resource cost (dynos).

As for the article, as other haves stated, it largely talks about how Puppet is more established. The only points that matter to me are #3 and #9. #3 seems to be a direct result of Chef's entry into the market and the value of #9 seems arguable.

So, to summarize:

* Puppet is definitely more established and better documented

* Chef is not there yet, but has (in my opinion) more potential for the future

</comment><comment><USER3> This basically states that Puppet is more established, which is an important point, but not exactly a conclusive "win" for everyone.

Unless I misunderstand #9 ("explicit dependency management"), Chef does indeed have this. It has resources that can both "listen" and "notify," just like in the Puppet example given, and things are executed in dependency order unless execution is specified as "immediate."

I agree with the point about Chef's Rails-oriented deployment. It's a little frustrating having to negate the default Rails settings while doing a PHP deployment.

To me, the major downsides to Chef are quirks/instability as changes are made during active development, and somewhat sketchy documentation in places. Still a great system though.

(Also: check out the reply from Adam Jacob, lead dev of Chef, in the comments. I noticed this after posting here.)

<comment><USER4> What author meant, i think, is that "Chef manages resources in the order they are specified." while Puppet encourages usage of "require" parameter to explicitly define the dependency. He does state that it is possible in chef, also providing link that explains the difference. Here is the link if you missed it [http://stochasticresonance.wordpress.com/2010/01/20/puppet-c...](http://stochasticresonance.wordpress.com/2010/01/20/puppet- chef-dependencies-and-worldviews/)

</comment></comment><comment><USER5> Caveat: I've used Puppet in production (and been very happy with the results), but only looked at Chef.

From a quick survey of the article, it missed the #1 advantage of Puppet, though the comments hit it: Puppet is declarative, which is fundamentally the right answer for this kind of problem space.

The flip side though, is that Chef (being mostly imperative) is easier for many people to get started with. I think this will help it gain share, in spite of the above. I might even pick it up myself, depending on the problems at hand.

<comment><USER6> Shadow puppet <http://github.com/railsmachine/shadow_puppet> is a Ruby DLS for Puppet. it allows you to have the best of both worlds. you still 'declare' your resources but you can imperatively build those declarations.

</comment></comment><comment><USER7> 6 of the 10 reasons are variants of "puppet has more adoption." I got that after the first couple, thanks!

</comment><comment><USER8> Be sure to read the response from the lead dev of Chef here: <http://bitfieldconsulting.com/puppet-vs-chef#comment-19>

</comment><comment><USER9> I honestly didnt know Puppet had such widespread adoption. The tech buzz always seems to favor Chef which is why I have more exposure to it.

Puppet does seem to have much much better docs on their homepage. However Chef is way more reusable. The chef recipe system is very powerful, and the fact that it uses ruby means its much more reusable using standard ruby practices (inheritance, modules, etc).

Sometimes its much better to be a newer technology as you can really solve some of the core issues of the preceding technology.

<comment><USER10> Luke got a good amount of adoption early on. Chef actually only started as a response to Puppet about two years ago when Opscode's original company, HJK Solutions decided they didn't want to have to pay for Puppet support.

The main advantage to opscode I see is that Chef does a better job of marketing and hype generation.

<comment><USER11> As one of the founders of Opscode, and of Chef, it's crazy to say that the reason we started Chef was because we didn't want to buy a support contract.

We have no beef with Puppet - from our experience building fully automated infrastructures at scale, it wasn't the tool we wanted (and it still isn't,) so we built Chef - the tool we wanted. It turns out it's also the tool lots of other people wanted, and we're incredibly proud of it.

There is nothing dirty here, no matter how much the internet wishes it to be so.

</comment></comment></comment><comment><USER4> We manage around 200 servers with puppet.Our system administrators aren't programming savvy. It's much harder to write chef recipes, while puppet's DSL allows them to write pretty concise and clear recipes. And explicit dependencies are very helpful here, we can't imaging our life without those. It is much harder to break thing when there are several people working on one recipe/manifest.</comment>


DNS inventor Paul Mockapetris will speak at dotScale in Paris on May 19th - <AUTHOR> http://dotscale.eu/?pm

<comment><USER3> I went to this conference last year and it was a blast, great speakers - <USER2> from Heroku, Wordpress, Hadoop, ... people who obviously know how to scale :) - great people, and such a great venue !</comment>


Postmortem of a Scaleway related not-too-critical downtime - <AUTHOR> https://www.pc-kombo.com/blog/94/Postmortem%20of%20a%20Scaleway%20related%20not-too-critical%20downtime <comment><USER3> > Despite the small misunderstanding about which server to restart, the > support was helpful and fast.

That's better than expected. We've had multiple occasions of waiting _greater_ than 24 hours for any kind of response from their support team for tickets with priority: High.

Including 2 instances where they migrated VMs to new underlying host - <USER2> changing their IP addresses - without any kind of notification. Was only picked up by our monitoring setup letting us know something was badly broken.

It's the reason we're currently in the process of migrating everything away from Scaleway.

Should have done it sooner, but was hoping they'd get their stuff together. The dropping of ARM64 ended that hope.

<comment><AUTHOR> Sure, I don't know whether this was an accident. But I'm really happy with how fast support reacted and how helpful it was. Was important for me to highlight that, to balance a bit the negative aspect mentioned in the writeup of giving away the C2 instance.

Their small DEV-instances seem to be comparable and to be a good alternative to the ARM64 offers, so I'm not sure how sad to be about that going away. It really was not 100% stable. I'll miss the bare metal aspect of the C2 instances though.

<comment><USER3> Yeah, the bare metal thing was useful. No "noisy neighbour" problem in that regard. :)

</comment></comment></comment><comment><USER4> Am I misunderstanding this? Is powering down an instance putting it up for grabs? Shouldn't that only happen upon deleting the instance from ones account?

> I'm currently betting on AppImage being the best solution for that (starting > point so far: a build script that provides ruby) and plan to invest more > work there.

A simple Docker install is perfect for this case. Would recommend a try!

<comment><AUTHOR> If AppImage does not work out docker is the alternative. Thanks!

And yes, powering down is putting it up for grabs. You also stop paying for it, says the documentation I read afterwards. [https://www.scaleway.com/en/docs/instances-shutdown- modes/](https://www.scaleway.com/en/docs/instances-shutdown-modes/). I think that's a mistake in the current situation. Harmless when there are enough instances going around, really dangerous now that none are left.</comment></comment>


We open-sourced 90 node.js modules at Browserling - <AUTHOR> http://www.catonmat.net/blog/browserling-open-sources-90-node-modules/ <comment><USER2> James and Peteris are two of the most amazing devs I've seen in a long time. They ship and ship and ship and ship.

The first version of StackVM (Browserling's underlying technology) was written in Haskell. They switched to Node close to two years ago if I'm not mistaken. I've gotten an early look at Testling, their cross browser testing web testing tools, and they're easily a year or two ahead of anyone else on the market. I'm looking forward to seeing it launch.

Hook James and Peteris up by purchasing a paid plan: <http://browserling.com/pricing>

Better yet, ping them about buying a corporate plan for your company: <http://browserling.com/contact>

<comment><USER3> They are amazing and Browserling is very handy, but they really need to hire a designer. A lot of their customers are going to be designers, there is no reason to have such a dated look.

<comment><USER4> I also agree. First time I came across their product it wasn't via HN and at first I just assumed they were one of the old-timers who were trying to be quirky with "cool" icons. Otherwise, good job on the product!

<comment><USER5> What do you mean by 'old-timers'?

<comment><USER4> Browser testing sites that have been around since the early days of it becoming important.

</comment></comment></comment></comment></comment><comment><USER6> Most of these are small utilities (e.g. node-mkdirp), but a few are really significant contributions to the Node community. node-bigint, for instance, is a very robust, efficient library for doing infinite-precision arithmetic (a fairly common necessity, since every number in JavaScript is a 64-bit float and there's no way of knowing when you lose precision).

</comment><comment><USER7> I would question my choice of platform if I had to develop 90 modules for it.

</comment><comment><USER8> I like how everyone was drawn for NPM top. Got their likeness on point ha-ha. I wonder how many of these can be grouped in to a general utility package?

</comment><comment><USER9> 90 is an astounding number of useful node modules :)

</comment><comment> thirty-thirty ♥

my stack is full of those modules!

</comment><comment><USER10> Great that these are individual modules instead of just making a single "browserling" package.

</comment><comment><USER11> Dang, Peteris! You and James just keep cranking it out. Looking forward to Testling.

</comment><comment><USER12> What's sad with this is that most of these modules would work in a browser if only they used asynchronous module definition.

That would have been even more awesome.

<comment> thirty-thirty <https://github.com/substack/node-browserify>

</comment></comment><comment><USER13> these guys competed in the Node Knockout! You can see (and vote) for the browserling guys here <http://nodeknockout.com/teams/replicants#votes>

</comment><comment><USER14> Truely amazing

</comment><comment><USER15> I know I'm getting to be a broken record, but two different attempts at an SSH server, neither of which work? Every other thing on this list is a reimplementation of something in Python's standard library or Twisted.

I mean, yes, that's a lot of code to write, and I'm impressed, but this just feels like yet more reinvention of the wheel.

<comment><USER5> I think that's the point. Nodejs is a new technology and people are re- inventing all the Twisted (and other technologies like it) wheels so that you can use them from nodejs.

<comment><USER16> It's a Javascript interpreter/JITer/whatever. What is new about that?

<comment><USER17> It's a javascript environment that _doesn't suck_. Heyoooo!

</comment></comment></comment></comment><comment><USER18> 1\. You win. This contribution make me think there needs to be an open source awards show. Your "best contribution to a web platform in 2011" nomination is in the bag.

2\. PG should be calling you with an invitation to the next YC class, not for this, but for everything you guys have accomplished in the last year.

<comment><USER4> Agree with both points, especially the second. Their product and work _feels_ like a great fit for YC.

BTW, nirvana: at the risk of down-votes here I wanted to draw your attention to this comment I made on an older thread which you might not have noticed: <http://news.ycombinator.com/item?id=2958684>

<comment><USER19> Thanks for pointing that out. I completely missed that wonderful thread.

EDIT: I agree with amirhhz. Nirvana, if you have a blog or newsletter, please let me know. The only info I found from HN & googling you is twitter @NirvanaCore, which I am looking forward it, but I don't want to just know about NirvanaCore from you. I want to read and know about you and your thoughts.

</comment></comment></comment><comment><USER20> Congrats!

Incidentally, anyone have an idea how I can profile my Node app to see where I'm using up memory and CPU resources?

<comment><USER17> There are debugging, profiling and coverage tools though they're maybe not as well-developed as you'd like.

If you have any node questions, you should drop by the #node.js channel on freenode! It's a good place to get help and chat about asynchronous IO with (generally) friendly people.</comment></comment>


Show HN: offlinenotepad – an offline-first notepad that can sync across devices - <AUTHOR> https://github.com/schollz/offlinenotepad <comment><USER2> Played with it a bit just now. Less and more, very nice.

When returning to the page, it will allow you in with the wrong password and without any complaints. This is confusing.

Also, I think it's a bit counter-intuitive that the local copy is encrypted, but the online (published) copy is public. I would expect there's more need to access-restrict an online copy (i.e. to require a password to read it) rather than safeguarding the local one.

More specifically, I was expecting the password to be used for backing up local notes to the server and for restoring them later (say, on another machine). Which would be in addition to being able to publish notes for everyone's view.

But, again, nicely done in terms of keeping it strictly focused on a single simple purpose.

<comment><AUTHOR> Thanks. I'll think about the password. Right now more than one person could claim a username but they will only decrypt what they can with their password. Because of that it's hard to check password validity.

<comment><USER2> Just take a random string, encrypt it with the password and save both plaintext and encrypted version in localStorage, stuff a username in one or another if needed. This will allow you to check if the username/password combo is valid.

</comment></comment></comment><comment><USER3> I got a content warning when I exported, because the format is json.

Is the intention to do something like draw.io, where you can re-upload the file to populate the data into the app?

<comment><AUTHOR> Yes, I like to make sure data is accessible. I'll add importing in the future.</comment></comment>


"I've decided to keep that black tape on my computer camera" - <AUTHOR> http://www.forbes.com/sites/mikemalone/2013/06/14/the-all-seeing-eye/

<comment><USER2> Though it doesn't address concerns of NSA snooping, this[1] article has a lot of relevant information (and will probably be of a lot more interest to Hacker News readers as it addresses issues such as when the camera can be on while the light is off, discusses ethics and dangers of technology, and is more than just a knee-jerk reaction to the possibility of NSA using our webcams to snoop on us now)

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

</comment><comment><USER3> I've often wondered how reliable the red light (indicating that the camera is on) is. What level of backdooring would be required for <nefarious organization> to turn on the camera without turning on the light? Chip level, I assume?

</comment><comment><USER4> any one else been doing this for years too?</comment>


Ask HN: I own the domain ide.as - what should I do with it? - <AUTHOR>

I registered ide.as for a project that didn't work. Should I keep it, sell it, give it? What are your experiencies? <comment><USER2> You could launch a contest in which some startups that would like to use the domain can offer you a small stake in exchange for the domain. You pick up the startup you like the most and lease the domain to them. Looks like a fair change that can return something in a long-term. If the startup doesn't work in, lets say, 1 year, you get your domain back.

</comment><comment><USER3> Good catch. Make it a forum so people can post ideas on what to do with it? Or a bit more useful: you could remake kickstarter, recreate something like DIY project sites (<http://www.instructables.com/id/Magnetic-Rubik-s-Dice-Cube/>), make it a specific-category site for ideas (home improvements, meal recipes, wedding planning, etc), list it for sale and see how much you could get for it, forward it to <http://en.wikipedia.org/wiki/Idea> \- or some things that are a little more unique: make it a project listing site, allowing people to upvote projects, services, and devices they'd most want (similar to kickstarter, but no money involved, allowing you to get a reasonable idea for how viable an idea is in a rather refined market [techies who actually would go and read it]).

<comment><AUTHOR> Many thanks xvolter! I like the "ideas list" idea.

</comment></comment><comment><USER4> <shamelessplug> Post it on friendsdomains.com </shamelessplug>

<comment><USER5> This is like an entire site dedicated to this very question. Very cool.

</comment></comment><comment><USER6> Shop it. What's the worst that could happen?

<comment><AUTHOR> you mean sell it?

<comment><USER3> Yes, he means list it to see what you can get. If you don't get anything reasonable, then don't sell it. However, most services do stiff you out of a huge percentage, I'd avoid selling it, it's a hassle.</comment></comment></comment>


The Apple iPhone XR Review - <AUTHOR> https://www.anandtech.com/show/13912/the-apple-iphone-xr-review-brilliant-battery-life <comment><USER2> XR user here that switched from Android after leaving the iPhone 4. The battery life is amazing. With my minimal use, it's lasting me 3 days with about 20% before I plug it in again. Great app ecosystem too. It's the little things like LastPass just being so much better on iOS. Widgets and notifications have come a long way but I still wish I could have widgets for email instead of having to manually open email. The screen often feels a bit large but gestures make it usable.

<comment><USER3> Please enlighten me.

Which one is worth buying iPhone X or iPhone XS Vs iPhone 8?

\- Writing this with an android phone attached to a powerbank in park.

<comment><USER4> I'm an iPhone 8 user and I prefer the size and form on this one. It has better resolution than Xr and it has 3d touch.

<comment><USER5> I went from an 8 to an Xr. The resolution in terms of dpi is the same on both. In terms of overall pixels it is higher on the Xr, due to bigger display size. Both displays are excellent.

I thought I might miss 3d touch, but with the iOS 12.1.1 update the biggest issue had been fixed: Accessing the context menu for notifications on the home screen. That one now actually feels nicer than on the 8, since the feedback is stronger with haptic touch. Scrolling in notifications with long press on spacebar is slightly worse, since it doesn't allow to mark things via light- release-and-press and doesn't react in some situations. But it's still very bearable. Don't miss the peek&pop functions of 3d touch at all.

The biggest advantage and disadvantage of the Xr: It has a lot bigger screen, is bigger, and feels heavier. It's a tradeoff. I still find it more inconvenient to carry around, and to swipe in from the left side of the screen in order to go back. But the large screen also has it's advantages.

</comment></comment></comment></comment><comment><USER6> I have one, love it, and real high on the list for why is that at the end of a busy day I regularly have 40% battery left in the bank.

Put side-by-side with a XS, i'm hard pressed to find a visual difference between screens, quality-wise.

<comment><USER7> Honest question, because I'm a bit confused: the 40% is good or bad? It seems comparable to my old iPhone SE, is battery life so much worse on the newer generations?

<comment><USER8> Someone getting down to 40% on the XR would have a dead battery on the SE. Your usage is lighter.

<comment><USER9> How are you qualifying that?

Power draw in usage vs battery capacity?

I've never really looked at it like that, but I guess we should take the least generous values from both:

Pure Capacity:

iPhone XR: 2,942 mAh

iPhone SE: 1,624 mAh

Draw:

iPhone XR: "Up to 15 hours", so 196,134 mAh of draw if we take the best case for the iPhone XR.

iPhone SE: 12-13 Hrs on Internet (so, LTE, according to apple) that's roughly 129,92 mAh

; while the capacities are wildly different I don't see the SE being so far behind.

If you can get real power draw numbers you can make your own conclusion. I suspect Apple expects a certain about of idle time (which has been optimised for on the later generations).

<comment><USER10> Yeah, using the battery life test from Anandtech as a guide, an SE gets about 70% of the battery life of an XR: 12.97 hours vs. 9.27 hours.

So I would guess around 28% of its battery when an XR is at 40%.

<comment><USER8> Using those numbers, when an SE hit 0% after 9.27 hours of usage, the XR would be at 28.5% (12.97-9.27)/12.97. That seems reasonable and makes my original claim that an XR would be at 40% was a hit high, but in the same ballpark. There's certainly no doubt that the SE's battery size and power management doesn't compare to the current phones'.

<comment><USER11> Though it's worth pointing out that the SE _did_ beat out its contemporary iPhone 6s, with which it shares most of its innards. Differences are the smaller display, slightly smaller battery, 1st vs 2nd gen TouchID, and a lower res front-facing camera.

[https://www.anandtech.com/show/10285/the-iphone-se- review/3](https://www.anandtech.com/show/10285/the-iphone-se-review/3)

24% longer on wifi web browsing. Worse on the graphics benchmark, but only because the framerate is higher (smaller screen resolution) which keeps the CPU from idling as much.

Makes you wonder what the performance of a modern small iPhone could be like.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> I wanted to love the XR, but it was too big.

I'd prefer a 4.5" phone, but ended up with an iPhone X as a kind of cheaper, smaller, currentish iOS device.

<comment><USER13> I would like to see an SE that's thicker to accommodate a bigger battery.

<comment><USER14> A phone as large as iPhone XR with iPhone SE's thickness would be pretty hefty…

<comment><USER13> No, no. The size of the SE but just a little thicker so the battery lasts longer. That's the only advantage big phones have in my view.

<comment><USER14> That's starting to get pretty thick…maybe it might be better if Apple made a battery case for iPhone SE?

<comment><USER15> The SE is already thinner than the XR by 0.7mm, and 0.1mm thinner than the XS/XS Max.

<comment><USER14> Sure, but since it's smaller it would be far more "chunky".

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Seconding some other users: the battery life on the XR is phenomenal. I upgraded from an iPhone 6, which even with the $29 battery replacement couldn't last till the afternoon with heavy use. Now, with the XR, I've stopped feeling the need to carry a backup battery with me, and I rarely even use my charger at work.

It's quite possibly the only product Apple makes today that Steve Jobs might approve of. Maybe that, and the AirPods.

</comment><comment><USER17> Switched from a Google Pixel (the original one) to the XR. Supper happy about the phone's quality and specially its battery.

At night I noticed that the screen is not OLED or AMOLED or whatevs, the blacks are quite bright, but I don't watch movies or series on it so I can really live with that.

All in all I'm very happy with the phone and it'll last me for years.

</comment><comment><USER18> "The iPhone XR is an interesting product for Apple: It is clear that it aims to be a lower-cost alternative to the higher-end XS flagships."

In what world is $800 an affordable price point?

<comment><USER19> Adjusted to inflation, the iPhone 4S was 722$. XR is 749$(not 800 by the way). 27$ difference, not too bad considering the technology is superior in every way to the 4S.

[https://i.redd.it/jclu70hbjzw11.png](https://i.redd.it/jclu70hbjzw11.png)

<comment><USER20> Twist it the other way around. What used to get you the top of the line, now only gets you the lower-cost model.

<comment><USER21> That's because a higher end model was introduced. A 2019 Toyota is more advanced than a 2009, even though Lexus exists.

</comment></comment></comment></comment><comment><USER22> "...is only outmatched by the more recent Mate 20 with its 33% larger battery."

As a fan of OLED, it's hard to swallow this simple fact that LCD is superior in power consumption

<comment><USER23> The OLED on the XS has more pixels and thus needs more RAM and GPU time to render, using up more energy.

<comment><USER24> It also _needs_ more pixels due to its pentile pixel structure which reduces perceptible resolution.

</comment></comment></comment><comment><USER25> I switched from a 5S I bought at launch to an XR. I'm enjoying the battery life, although the larger screen took a bit of getting used to.

<comment><USER26> Props for sticking to the 5s for this long! I'm still rocking mine as well. Although, I just picked up a $200 Moto G6 (first android device ever) for development, but might just use it as my daily driver since even that budget android phone is an upgrade to the 5s at this point!

Gotta say though, I've been so impressed with how the 5s has held up over the years, that the investment in a higher priced iPhone might just be the way to go.

<comment><USER25> Thanks! I'm hoping that the XR lasts for the next five years (at least!) too. I get some smart remarks from others, but the end goal is to minimize the amount of rare metals consumed in my lifetime. I've been really pleased that the 5S continuously got updates for so long.

</comment></comment></comment><comment><USER27> For those comparing battery life with Android phones, I've noticed that location services is what always drains my battery the fastest (on Nexus/Pixel) branded phones. Turning it off or using Low power location services easily doubled battery life.

</comment><comment><USER28> Updated to the XR from a 6 (replaced battery) and the battery life is amazing.

My biggest complaint is how fragile the phone is. The shell already has scratches and is wildly expensive to repair. I want a premium plastic body like the Lumia phones so badly on this tier of device.

<comment><USER29> I don't know what polymer Lumia uses, but I wonder why Apple doesn't use ultra-high molecular weight polyethylene (UHMWPE) for their budget phone cases.

This material is used among other things on artificial joints such as knees and hips, as well as the bottoms of snowboards. It's very tough and scratch resistant.

</comment></comment><comment><USER30> I disliked when the reviewer starts complaining about the thickness of the device.

It has great battery life, much better than most other phones. That battery needs to be somewhere. You can't have it both ways.

</comment><comment><USER31> Can anyone explain the current iPhone lineup in a few sentences?

<comment><USER8> The new models are XR (LCD phone in the link), XS (OLED phone) and XS Max (larger OLED phone.)

The 8 was last year's LCD phone and the X was last year's OLED phone (the first year it was offered.)

They also sell the 7, which was the phone from two years ago.

<comment><USER32> Is there an effective mnemonic for the model designations? I've heard the lineup several times and it's just not sticking. Because of this, I tend to forcibly _not_ think about the iPhone to save mental CPU cycles.

<comment><USER8> It's messy right now. -S still means an improved version of a previous form factor (X->XS, just like 6-6S a few years ago.) X- seems to mean a curved corner screen and no home buttons (X/XS, XS Max, XR.) Max And Plus both mean a larger version of another phone (XS/XS Max, but it's confusing because the XR also has a bigger screen.)

I agree it's not worth thinking about unless you're really into Apple news.

</comment></comment></comment></comment><comment><USER33> XR is the cheapest smart phone people can buy, you have to consider cost of OS upgrades, free apps that Apple spends $ on (Screentime for parents is worth $5/month by itself). It amazes me how these professional reviewers ignore the fact that most android devices are lucky to get 2 OS upgrades, and have to wait several months after OS is released.

iPhone will easily last twice as long and will get all the feature updates the hardware can support.

<comment><USER34> My Nokia 7.1 has monthly updates guaranteed for two years, is fast with a decent camera and has all the apps I need. Battery life and build quality are fantastic. All for about a quarter of the price of an iPhone XR. Not sure I agree with you there.

<comment><USER35> I'm considering a Nokia 6.1 or 7.1 as my next phone, but I'm concerned that it's allegedly killing background processes so that IMs don't get delivered. Can you comment on that?

<comment><USER36> My sister is non tech savvy and thus loves to complain about things not working on her phone or computer. She has a 6.1 and no complaints on that regard. .

</comment></comment></comment></comment><comment><USER37> I got the XR. I would prefer a smaller phone, but none of the extra features on the XS justified paying 33% more for them. (In fact, I didn't feel that 64 GB was enough, so if you compare the cheapest models with more than that, you're looking at closer to a 50% premium for the XS).

I had a 5S, and I considered the SE, but I had already started to see apps and websites that don't support the smaller screen size very well, and I didn't want to get a phone that I intend to use for 4 or 5 years that was already several years closer to obsolescence.

The XR is a good phone, but it shows evidence of value engineering that you don't usually see on apple products. The larger bezels, the lightning port not being centered on the bottom of the phone, the fact that is thicker and almost heavier than the XS Max.

My biggest disappointment with getting the XR was that general day-to-day tasks that felt sluggish on my 5S since the iOS 11 update . . . are still slow and sluggish. I have watched the phone take over 15 seconds to respond in any way to a tap inside Apple's pre-installed apps. I thought that iOS 11 was just too resource-intensive for my old phone, and I guess its just that Apple has forgotten how to write solid and responsive software -- which used to be one of the key differentiators between Apple and Android phones.

<comment><USER38> > day-to-day tasks that felt sluggish on my 5S since the iOS 11 update . . . > are still slow and sluggish.

If you restored from a backup, try setting up the phone fresh instead. If that doesn't help, just go back to the backup.</comment></comment>


The Great SOPA Conspiracy Theory - <AUTHOR> http://www.forbes.com/sites/insertcoin/2011/12/23/the-great-sopa-conspiracy-theory/

<comment><USER2> This seems ridiculous to me. Does anyone think these corporate dinosaurs really have enough intelligence on this topic to organize a mass conspiracy to gain control of the Internet?

I'm sorry but no.

SOPA is prime evidence of the knee jerk reactions these companies are making in order to protect their age old business models that no longer work.

<comment><USER3> Sounds like regular, run-of-the-mill complete lack of communication between various disparate branches of a any large multinational corporation.

The "internet" side of things were probably run with very little oversight beyond bottom-line targets (which distributing the software off ad-loaded pages no doubt helped).

</comment></comment><comment><AUTHOR> I find it unlikely too. But what's interesting is how this can be perceived as bizarrely hypocritical. For the last 10 years to this day you can go to CNET and Download.com and get software that induce/facilitate/enable piracy, such as Kazaa.

</comment><comment><USER4> This is news to me</comment>


Homo naledi, a new species of human relative from the Cradle of Humankind - <AUTHOR> http://www.timeslive.co.za/scitech/2015/09/10/Homo-naledi-a-new-species-of-human-relative-from-the-Cradle-of-Humankind <comment><USER2> Previous discussion: [https://news.ycombinator.com/item?id=10196922](https://news.ycombinator.com/item?id=10196922)</comment>


Promoting a new site and keeping your hands clean - <AUTHOR> http://diveintothepool.wordpress.com/2009/05/19/promoting-a-free-online-dating-site-and-keeping-clean/

<comment><AUTHOR> On a side note, I was most surprised when I came across the Twitter spam. I knew about Craigslist being relentless in spamming personal ad posts but I found out about the Twitter spam through trying out Scoopler.</comment>


Show HN: I created a util to help you choose what to watch next - <AUTHOR> https://github.com/mitul45/random-episode-picker <comment><USER2> I feel like I'll just keep choosing a new random one until I land on one I like. I feel like the problem still exists -- we find content we don't like, and then decide to keep looking, until we find something we do like.

<comment><AUTHOR> For me personally, the randomness works. Anyhow I was doing the same thing manually before. If I have something in mind than it's different thing.</comment></comment>


Show HN: Chrona, an open source solution to storing and sharing bookmarks - <AUTHOR> https://chrona.io <comment><USER2> The link to github source is incorrect:

Correct Link: [https://github.com/jmfurlott/chrona- api](https://github.com/jmfurlott/chrona-api)

Somehow its redirecting to [https://github.com/jmfurlott/chroma- api](https://github.com/jmfurlott/chroma-api)

(Typo error)

<comment><AUTHOR> Ha thanks for that catch!</comment></comment>