MongoDB – From introduction to high level usage in C# with NoRM. - <AUTHOR> http://fredzvt.wordpress.com/2010/04/24/no-sql-mongodb-from-introduction-to-high-level-usage-in-csharp-with-norm/ <comment><USER2> _I believe MongoDB has a great advantage and will develop more quickly because it is written in C++ and not in Erlang, like CouchDB._

I believe CouchDB has a great advantage and will develop more quickly because it is written in Erlang and not in C++, like MongoDB.

<comment><USER3> He could merely be alluding to the fact that _a lot_ more people know C++ than Erlang and therefore will be able to contribute to MongoDB's development.

<comment><USER4> True. But considering that Erlang was designed especially for high- availability systems and concurrent systems, I would favor a database written in it than in C++.

Of course, it has very little to do with the language and a lot to do with how the code is written, but some things are easier to write in one platform over the other.

<comment><USER5> What I meant was interpreted correctly by dschobel. I agree that Erlang is more appropriate for the case, however, being MongoDB an open-source project, I believe MongoDB will develop faster because more people will be empowered to make corrections and add new features.

</comment></comment></comment></comment><comment><USER6> _•The disuse of SQL as the query API. (Examples of APIs used include JSON, BSON, REST, RPC, etc.)._

JOSN has a standard way to indicate which objects to select, along with ordering, grouping, and aggregation?

<comment><USER5> JSON is just a notation to structure information, not a query language. MongoDB uses JSON documents as specification for queries. Eg: The expression db.People.find({ name: Fred }); could be translated to the SQL: SELECT * FROM People WHERE Name = 'Fred'.

<comment><USER6> My point exactly - the original quote is odd in making a comparison between SQL and JSON.</comment></comment></comment>


Executive management decision for your Startup - When/How? - <AUTHOR>

<comment><AUTHOR> When is the latest that a startup needs to think about the executive management? When does one decide on who the CEO should be? And what is the best way to go about it? Thanks!</comment>


Lisp as a secret weapon - <AUTHOR> http://www.paulgraham.com/avg.html

<comment><USER2> > Viaweb was the first Web-based application

Surely not.

I interned at a very tiny brokerage in the summer of 1995 that had already built an early online trading app by the time I got there.</comment>


Knock 70% off REST network time - <AUTHOR> http://technosophos.com/content/connection-sharing-curl-php-how-re-use-http-connections-knock-70-rest-network-time

<comment><USER2> It would be nice if the title reflected the fact that this article is focussed entirely on _making_ REST connections from _PHP only_ using the _CURL_ library. My first interpretation was that the article was about speeding up your own REST app, not accessing someone else's via PHP's CURL library.</comment>


Lightning makes new isotopes - <AUTHOR> https://www.nature.com/news/lightning-makes-new-isotopes-1.23033?error=cookies_not_supported&code=580c9b9c-9c24-48aa-a823-f3a65db5e340 <comment><USER2> Does this impact carbon dating in anyways? Since it's an unaccounted source of radioactive carbon. Thanks.

<comment><USER3> Very unlikely, because the calibration used for carbon dating is acquired by comparing with artifacts of a known age, i.e. experimentally, and not from first principles.

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

<comment><USER4> How does this help if multiple date ranges correspond to the same C14/C12 ratio?

</comment></comment></comment><comment><USER5> Makes me think of the Electric Universe alt-theory! I wonder...

</comment><comment><USER6> If only they would have simply written " _gamma ray_ " instead of γ-ray, but I suppose there are the bandwidth savings to consider...

<comment><USER7> I see nothing wrong with using the γ-ray nomenclature, but writing gamma ray instead would surely make the text more readable IMO.

I think it's a valid criticism, not sure why the downvote rain happened. Too snarky, maybe?

Unless you really mean that they did this for the purpose of saving a few bytes, then I disagree with you.

<comment><USER6> Hacker News downvotes are to be ignored as pedantry at best. Imagine the level of discomfort inflicted by my comment, and that should correlate well with the amount of discomfort the HN frowny face is truly worth. Maybe it's taste is closest to something like licking a nine volt battery.

They are mostly unproductive, and express an opinion more akin to noise than anything else.

Don't try to predict when downvotes will occur. Only predict that aligning your comment perfectly with the general sentiment of HN's echochamber and the capricious views of some of its moderators, will likely result in a general trend of upvotes.

If you ardently pine for someone else's approval, conform to their every whim.</comment></comment></comment>


Ask HN: Can you own copyright on everything if you publish it first? - <AUTHOR>

This is just meant to be a bit of fun, I was going to attempt it as a joke website and give it all a Creative Commons license but after 1 quick sum it's obvious it's just not possible (doh!).
Anyway, assuming it was possible to iterate every possible combination of characters < 100 characters in length, store them and publish them to a website.  You're looking at in the region of 10^135 terabytes of data so there's no way to store it at the moment, but imagine somehow you can.
Do you then own copyright on all that text?  If Britney Spears released a new single, would it break your published copyright as her lyrics will certainly overlap with your published text? <comment><USER2> No, for a variety of reasons. Copyright attaches to creative expression. Your work is not creative. Britney Spears' new single would not decrease the commercial value (hah) of your work. Any copying of your work would be de minimis in character.

More broadly, the law is generally resistant to attacks that programmers dreamed up in two minutes and thought sounded clever. The canonical essay on this is The Color of Bits.

<comment><USER3> What Patrick said. In the U.S., there has to be at least minimal originality to be able to claim copyright. The White Pages don't count (sayeth the Supreme Court of the U.S.). Neither do exact photographic reproductions of paintings (sayeth another federal court).

Even now, 25 years after Pam Samuelson's [1] seminal article [2], it's still unclear whether computer-generated works can be subject to copyright protection.

[1] <http://people.ischool.berkeley.edu/~pam/>

[2] [http://people.ischool.berkeley.edu/~pam/papers/47UPittLRev11...](http://people.ischool.berkeley.edu/~pam/papers/47UPittLRev1185.pdf)

<comment><USER4> Raw facts don't count as copyrightable, but a collection/database can count as copyrightable in some cases. This is how map data is copyrightable. Each individual road data ("The road is called main street", "Main St. is 200m long", "The top corner of main street is at X deg North, Y deg West", etc.) is just a little fact, and itself is not copyrightable. However if you collect all those uncopyrightable facts together into one database/collection, then that database/collection might be a copyrightable work.

Tracing street/road positions from aerial imagery may or may not be making a derived work. It may or may not be similar to your 'photograph of a paining'. This sort of thing is important for OpenStreetMap and tracing from aerial imagery. However in that project, we avoid legal gray areas and just don't trace from aerial imagery without permission.

But when it comes to copyrights, IANAL, lots of this is decided by case law in courts, it varies from country to country, and you should get a lawyer if you need better answers.

<comment><USER3> > _However if you collect all those uncopyrightable facts together into one > database/collection, then that database/collection might be a copyrightable > work._

True, _if_ there is at least a modicum of "originality" in the selection and/or arrangement of the uncopyrightable facts. In the U.S. Supreme Court's _Feist_ case,[1] the Court held that an alphabetical arrangement of names, etc., in the white pages of a phone directory did not include the requisite originality.

[1] <http://en.wikipedia.org/wiki/Feist_v._Rural>

</comment></comment></comment></comment><comment><USER5> What colour are your bits? <http://ansuz.sooke.bc.ca/entry/23>

</comment><comment><USER6> Copyrights aren't like patents, if two people come up with the same creation independently neither will infringe on the other's copyright.

</comment><comment><USER7> Please share: <https://creativecommons.org/></comment>


The Paradox of Disclosure - <AUTHOR> http://www.nytimes.com/2016/07/10/opinion/sunday/the-paradox-of-disclosure.html <comment><USER2> > _For example, surgeons are more likely to recommend surgery than non- > surgeons. Radiation-oncologists recommend radiation more than other > physicians. This is known as specialty bias. Perhaps in an attempt to be > transparent, some doctors spontaneously disclose their specialty bias. That > is, surgeons may inform their patients that as surgeons, they are biased > toward recommending surgery._

> _My latest research, published last month in the Proceedings of the National > Academy of Sciences, reveals that patients with localized prostate cancer (a > condition that has multiple effective treatment options) who heard their > surgeon disclose his or her specialty bias were nearly three times more > likely to have surgery than those patients who did not hear their surgeon > reveal such a bias. Rather than discounting the surgeon's recommendation, > patients reported increased trust in physicians who disclosed their > specialty bias._

Every time I think I've figured out the depth of human irrationality, it turns out there's more.

<comment><USER3> It's actually a pretty good selling tactic: tell them why you think they need surgery but add "I might not be the best person to tell you this because as a surgeon, I look at all problems through surgery"; this makes you come off as honest, putting the patient before your benefit, and because patients don't expect such disclosure, they end up trusting you a lot more.

<comment><USER4> I also trust a specialist in x to know when it's not the appropriate solution to the problem.

</comment></comment></comment><comment><USER5> This instantly reminded me of an article I read about medication side effect disclaimers actually increasing the odds of people trying the product. Both are pretty interesting effects.

[http://www.forbes.com/sites/peterubel/2014/08/18/side- effect...](http://www.forbes.com/sites/peterubel/2014/08/18/side-effect- warnings-can-increase-pharmaceutical-sales/)

<comment><USER6> Since I didn't get past the ad I googled for the actual study (or at least one that seems to fit he description for the most part), here it is (PDF):

[https://marketing.wharton.upenn.edu/files/?whdmsaction=publi...](https://marketing.wharton.upenn.edu/files/?whdmsaction=public:main.file&fileID=5092&usg=AFQjCNHxMQCTHb_VyK6dlJfnIt3fBazY6A&sig2=NN8Mx- TfOUCYSg1ViRnwJA)

Abstract:

> We found no evidence that consumers benefit from government-mandated > disclaimers in advertising. Experiments and common experience show that > admonishments to change or avoid behaviors often have effects opposite to > those intended. We found 18 experimental studiesthat provided evidence > relevant to mandatory disclaimers. Mandated messagesincreased confusion in > all, and were ineffective or harmful in the 15 studiesthat examined > perceptions, attitudes, or decisions. We conducted an experiment on the > effects of a government-mandated disclaimer for a Florida court case. Two > advertisements for dentists offering implant dentistry were shown to 317 > subjects. One advertiser had implant dentistry credentials. Subjects exposed > to the disclaimer more often recommended the advertiser who lacked > credentials. Women and less-educated subjects were particularly prone to > this error. In addition, subjects drew false and damaging inferences about > the credentialed dentist.

<comment><USER7> In other words, the disclaimers were confusingly worded, perhaps due to regulatory capture.

Similarly, cigarette warning labels in USA are designed to be hard to read (A PARAGRAPH OF SKINNY ALL CAPS) due to industry lobbying.

</comment></comment></comment><comment><USER8> I wonder if this extends to sharing your reasoning for a decision with others. It seems like it might be a sort of social cognitive offload, where we feel more sure with our decisions when we expose our reasoning to other, even unqualified, people. I think hearing no rebuttal gives us assurance, much like someone positively encouraging you to do something does, even if the encourager has no idea the difficulty of the task,your qualifications, etc.

This seems especially relevant for bias disclosure, because now we feel better giving in to those biases because we've issued warnings.

Anecdotally, I see this used in social situations where someone is not particularly nice, who then unapologetically informs everyone that they are "not nice" or "mean" as if it excuses the behavior.

<comment><USER9> Biases are blaming statements. Saying someone is "not nice" is a blaming statement against a person directly...to avoid the disruption caused by the words which elicited the statement to begin with. Blaming someone else's character to diminish the importance of the statement they made is a well known and oft wielded bias.

Biases work because they allow a steady state of cognitive dissonance to occur. It's only when dissonance is disturbed that it begins to chew up resources - both internally and externally. How much effort should be going into picking a good president here in the US and what is limiting our ability to change things for the better? That's a HARD question to answer and requires a lot of work from a lot of different people to get even reasonably close to breaking the dissonance in society for the better.

Seems a far more efficient solution to let things randomly break at a point for a nice, yet messy, reset on societal cognition.

</comment></comment><comment><USER10> In business, the standard of conflict-of-interest is "Did You Disclose"? So LendingClub's CEO got in trouble for not disclosing the conflict of interest. Achieving financial benefit on the side wasn't the issue - lack of disclosure was.

This actually creates worse governance issues, because you can't trust that execs will do the right thing. You can only trust that they'll tell the board, who may have conflicts of their own.

</comment><comment><USER11> It seems like the paradox very much involves the problem of a person disclose their bias. This results in all sort of paradoxical problems of someone wanting maintain social relations, someone taking a disclosure as part of social signaling in general, etc.

A relatively simple way around this, I could suggest, is having someone else make bias disclosures and indeed requiring someone else to make those disclosures.</comment>


The Million Dollar 'Man-Page' (Tattoo Advertising) - <AUTHOR> http://tapinko.com/billythebillboard/profile/

<comment><USER2> Apparently Safari isn't a supported browser (it renders just fine). How very 1999 :(

</comment><comment><AUTHOR> Posted this with the hope that some start-up is looking for some 'alternative advertising'</comment>


Why Peak Oil Will Never Lead To $500/bbl Crude Oil - <AUTHOR> http://www.chrismartenson.com/forum/why-peak-oil-will-never-lead-500bbl-crude-oil/38937 <comment><USER3> Why is bbl the abbreviation for "barrel"?

Ahh, wikipedia knows: The "b" may have been doubled originally to indicate the plural (1 bl, 2 bbl), or possibly it was doubled to eliminate any confusion with bl as a symbol for the bale. Some sources claim that "bbl" originated as a symbol for "blue barrels" delivered by Standard Oil in its early days; this is probably incorrect because there are citations for the symbol at least as early as the late 1700s, long before Standard Oil was founded.

<comment><USER4> [http://seekingalpha.com/article/18636-where-does- that-2nd-b-...](http://seekingalpha.com/article/18636-where-does-that-2nd-b- in-the-abbreviation-for-crude-barrels-bbl-come-from)

Quote:

In the early 1860's, when oil production began, there was no standard container for oil, so oil and petroleum products were stored and transported in barrels of all different shapes and sizes (beer barrels, fish barrels, molasses barrels, turpentine barrels, etc.). By the early 1870's, the 42-gallon barrel had been adopted as the standard for oil trade. This was 2 gallons per barrel more than the 40-gallon standard used by many other industries at the time. The extra 2 gallons was to allow for evaporation and leaking during tranport (most barrels were made of wood). Standard Oil began manufacturing 42 gallon barrels that were blue to be used for transporting petroleum. The use of a blue barrel, abbreviated "bbl," guaranteed a buyer that this was a 42-gallon barrel.

<comment><USER5> That quote doesn't explain why the abbreviation was used about a hundred years before stabndard oil introduced the blue barrel, as claimed by the wikipedia quote in the comment you ansered to. In fact, your quote just reiterates the claim that wikipedia said was probably false, so to make your argument you should instead show that the citations from the late 1700s are wrong.

EDIT: This will be difficult, as it is quite easy to find citations for "bbl oil" from before 1850 using google books, the first I found was on p. 239 of a book called "Railway engines and cars" from 1832. So the blue barrel legend can be firmly laid to rest in peas.

<comment><USER6> _firmly laid to rest in peas_

Ha! The doubled b in bbl is likely an outmoded typographical convention - <USER2> in _book citation_ p437, and also pp495-500. I like such archaisms but agree it's a bit confusing and inconsistent with other conventions - eg we don't talk of $5 bbn to mean five billions.

</comment></comment></comment></comment><comment><USER7> Executive summary:

The author expects _"government intervention of some kind to occur before prices get much above $200/bbl."_

<comment><USER8> _government intervention_ is of course a euphemism for rationing. Rationing creates shortages which in turn causes steeper rationing, with the result being the economy slows to whatever pace is consistent with the limited supply of energy. For the USA that looks to be a lonnnng way down from here.

<comment><USER9> A combination of subsidies and taxes could align incentives well in advance without resorting to outright rationing.

<comment><USER10> You can tax oil, if we are short of oil. But if we are sort of energy in general, then taxes won't work.

Energy is the input to every single thing humans do. If you tax energy then the price of _everything_ will go up.

You can't build a wind turbine without energy. If wind turbines produce less energy than it takes to make them, you are stuck.

As it turns out wind turbines produce more, but not a lot more. Solar cells produce less.

Even nuclear power just barely produces more than the energy used to build the plant (at least in the first 10-20 years).

<comment><USER9> Tax oil, subsidize renewables and nuclear construction (but not operation). That'll do a lot towards building in the incentives that are currently being lost to free-rider and tragedy-of-the-commons.

<comment><USER10> You didn't understand what I said.

Renewable and nuclear power today, consume more energy in the making of them, then they produce (over 10 to 20 years).

Subsidizing them won't help - there isn't enough energy available.

If you take the long view, more then 20 years, the picture changes, but few renewables last that long. Only nuclear does.

But since no bank wants to loan money with a payout of longer than 20 years, nuclear doesn't get built. That's why they talk about loan guarantees for nuclear power.

There is no free-rider or tragedy-of-the-commons going on here.

<comment><USER11> > _Renewable and nuclear power today, consume more energy in the making of > them, then they produce (over 10 to 20 years)._

I don't think that's true. [1]

> _But since no bank wants to loan money with a payout of longer than 20 > years, nuclear doesn't get built._

That's an oversimplification. There are numerous reasons why nuclear isn't being built, not the least of which are the various NIMBY and other environmental concerns, and the fact that things like Thorium reactors have yet to regain popularity due to the push for weapons-grade-yielding nuclear technology over the last several decades.

[1]: [http://www.eoearth.org/article/Energy_return_on_investment_%...](http://www.eoearth.org/article/Energy_return_on_investment_%28EROI%29_for_wind_energy)

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> It's more basic even than this. Market demand for oil collapses (read: recession) long before it gets anywhere close to $500/bbl.

<comment><USER13> > Market demand for oil collapses (read: recession) long before it gets > anywhere close to $500/bbl.

Above $80 a barrel, alternative fuels (such as liquid fuels from coal) becomes profitable. I sincerely expect that this will expand extremely rapidly in the next 15 years.

<comment><USER12> When demand becomes tight, the price driver is not so much the _cost to produce_ as it is the _rate of production_. Can we produce five or ten million barrels of oil-from-coal a day? Can we replace a two or three percent annual drop in oil production rates through some combination of conserving and replacement _without_ recessionary demand destruction? I'm not so sure.

<comment><USER14> We'd switch to more mundane substitutes long before oil got to $500/bbl.

Just the spike to $130/bbl in 2006 saw people switching away from SUVs to Priuses in droves. If that were sustained for any length of time, everyone would be driving a plug-in hybrid to work. The technology exists today, and the production capacity would ramp up pretty quickly.

If every switched from a 20mpg car to a 50mpg car where the first 100 miles of each trip was free, it'd more than make up for anticipated oil production declines over the next 50 years.

<comment><USER12> That might work if the developed world was driving the increase in fuel consumption, but that hasn't been true for quite some time. North American oil consumption is already going into decline, but global demand pressure is coming from the developing world - China, mainly, followed by India - as well as all the oil-producing countries with nationalized industries and artificially low domestic prices (Venezuela, most of the Middle East).

Those consumers will not be buying plug-in Priuses; and with consumption growing rapidly in the oil exporting countries, once they pass their national production peaks their export rates will decline faster than their own production rates.

<comment><USER14> They have the same price constraints that the developed world does. If oil goes up to $500/bbl, we'll see one of three things happen.

1.) They'll substitute more efficient yet more expensive cars for gas guzzlers, as the TCO of a gas guzzler goes up.

2.) Efficient, cheap, yet _small_ cars will start being developed for emerging markets. (This is already happening a bit - consumers in Beijing tend to drive much smaller cars than consumers in Houston.)

3.) They won't buy cars at all.

There's no innate reason beyond price why consumers in developing companies can't buy plug-in hybrids. And if price is the governing factor, they simply won't buy cars as well. Either way, it puts downward pressure on oil demand and hence serves to limit prices.

</comment></comment></comment></comment></comment></comment><comment><USER15> "The Stone Age did not end for lack of stone, and the Oil Age will end long before the world runs out of oil." Sheikh Yamani, Saudi Oil Minister, 1962-1986

<comment><USER16> That's poetic - but is it true?

<comment><USER15> We've been here before, too, except before it was food shortages and 100s of millions dying that were being predicted in alarmist tones:

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

And the solution, which apparently now sustains one third of the world's population:

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

My prediction, is that like before, science will solve the problem and this will all disappear into the memory. Man's capacity to wipe itself out is far outpaced by it's ingenuity to sustain itself.

Then: Cold War, oil shocks

Now: Terrorism, oil shocks

History always repeats itself.

</comment></comment></comment><comment><USER17> Two things:

a) oil != gasoline <http://www.ranken- energy.com/Products%20from%20Petroleum.htm>

b) Demand destruction doesn't preclude $500/bbl crude, it just means that when oil hits $500 there won't be nearly as many products that are dependent on it.

</comment><comment><USER18> I got pretty into peak oil circa 2006, when peak was supposedly already occurring or was going to occur by 2008. It will happen eventually, but I'm not going to get into playing this guessing game again.

<comment><USER12> No need to guess. Oil production has been flat around 85 million barrels a day for the past four years.

<comment><USER18> Demand has been lower due to the global recession -- there is no indication that oil production can't go higher than ever before, once demand starts picking back up.

<comment><USER12> And what do you think triggered the global recession, if not an oil price that spiked to an economy-busting $147/bbl in the two years after production peaked at 85 mbpd?

<comment><USER19> Ummmm... I kind of thought it was the combination of a US housing bubble in combination with poor risk management in the financial industry particularly respecting mortgates.

<comment><USER12> [http://research.cibcwm.com/economic_public/download/soct08.p...](http://research.cibcwm.com/economic_public/download/soct08.pdf)

</comment></comment></comment></comment></comment></comment><comment><USER20> I think the Internet will do a lot to lessen the effect of this when it does happen. People who can work from home probably will, when it costs a quarter to half your days wage just to make it to work it will offset any benefit you get by having a team in the same building.

Also online distribution, things like books might become prohibitively expensive in the physical form and drive everyone to ebooks, all creative products really.

<comment><USER21> But the electricity powering the Internet is also somewhat oil-based, depending on exactly what fuels you local plant runs. It may not impact the individual homeowner, but the costs of the data centers and network providers will increase alongside oil prices.

<comment><USER22> Very little electricity is petroleum based anymore. Depending on region it's mostly coal, hydro, or nuke.

<comment><USER21> It depends entirely on pricing. Most "coal" plants switch between coal and natural gas based on current market trends. And even if coal is burned, the fuel to get the coal to the plant is petroleum-based. There are a lot of complexities involved. Of course, working in the natural gas industry, I only have limited knowledge. :)

</comment></comment></comment></comment><comment><USER23> I would like to see some sources for the "more than 100 years of oil left" claim. If it's at all based on 'public reserve levels' declared by oil producing countries, those are basically totally fabricated.

[http://www.telegraph.co.uk/finance/newsbysector/energy/oilan...](http://www.telegraph.co.uk/finance/newsbysector/energy/oilandgas/7500669/Oil- reserves-exaggerated-by-one-third.html)

In any case, it's the first claim in the article, he should back it up.

</comment><comment><USER24> I wouldn't be so confident about naming a particular ceiling price, but as oil becomes more expensive demand will fall and individuals and industries will move to other sources of energy. In particular within the next 5-10 years it looks as if electric vehicles are going to be a growth area, mainly driven by rising costs on conventional fuel.

<comment><USER10> Electricity is not a "source of energy". If the price of oil goes up the price of electricity goes up too.

There are no other sources of energy that are really practical today. Although some are close.

<comment><USER24> The price of electrons is not necessarily linked to oil production, since electrons can be produced in ways which don't require much or any oil.

There are other eminently practical energy sources available. The main issue is that these have historically not been price competitive with oil. As oil extraction becomes more difficult the economics of energy will change.

<comment><USER10> I don't think you realize how interconnected, and interchangeable all forms of energy are. Not being price competitive with oil means it costs more energy to make then it produces.

If something made more energy than it costs to make it (over 10 to 20 years), then it would be built. Why not build it? It's guaranteed profit.

But, in actuality there isn't anything like that. Every single form of energy is being tapped to the maximum possible. It's the nature of capitalism.

If the price of oil went up, the price of everything goes up. If the price of raw materials goes up, it costs more to build some alternate form of energy, so you get nowhere.

<comment><USER24> The idea that capitalism is either a natural or optimal system doesn't stand up to much serious scrutiny. If you're referring to "cost" in terms of energy cost then yes there is always some amount of energy which needs to be put in to get energy out, with the result being the net energy gain.

For other forms of energy, such as bio-fuels, the net energy gain is presently smaller but this does not invalidate these technologies. As the complexity of extracting oil increases its net energy gain will reach parity with other energy sources, and then begin to lag behind them. The economy - with all its foibles - will eventually back the winners out of pure necessity.

</comment></comment></comment></comment></comment><comment><USER25> > Societal complexity is a function of excess energy availability

That's true in it's most trivial sense, and false in any non-trivial sense. Quick examples - Qatar, Venezuela, Japan.

<comment><USER26> Your Qatar and Japan examples, at least, make his point: the complexity of those cultures reflect the resource conditions in which they developed. Not sure about Venezuela. Japan, in particular, was the only place in the world where hunting and fishing could support large settled populations, if I remember my Jared Diamond correctly.

<comment><USER27> _Japan, in particular, was the only place in the world where hunting and fishing could support large settled populations_

Louisiana was more productive than Japan for wild fish and fowl. (Largely destroyed now by bad planning, pollution, and man-made environmental disasters)

</comment></comment></comment><comment><USER28> "Collapse" a pretty good documentary on the subject

</comment><comment><USER29> No one with any credibility actually believes he can forecast the price of oil.

Oil is very inelastic in the short term, which is why small drops in supply lead to massive price increases. The long-term effect of unavailable or expensive oil will be "demand destruction"-- many of those who currently use oil will either move to alternatives or go out of business-- and political fallout with unpredictable results.

<comment><USER30> People investing in futures do this every day, and some of them are most certainly credible. Southwest Airlines, e.g., seems to be pretty good at saving a buck with aviation gas futures (though that is a step removed from crude oil).

<comment><USER31> _People investing in futures do this every day, and some of them are most certainly credible._

If it were possible to do significantly better than blind luck in speculation about future prices then there'd be nobody around to take the other side of the contract.

<comment><USER32> Speculators usually earn a premium over what they would get via blind luck. If they didn't, there would be no speculators.

The reason why trades occur at all is that not everyone is a pure trader. Hedgers (e.g. Southwest) trade futures to reduce business risk rather than to make money. They tend to make a net loss on trading but earn back a greater amount of money via their core business.

</comment></comment></comment></comment><comment><USER33> We will reach $500/bbl eventually after the US dollar is hyper inflated away.

<comment><USER34> I keep hearing about how hyperinflation is about to hit. Surely in an efficient market, if this was truly likely, its effects would already be being felt? What is the rationale behind its prediction?

<comment><USER22> Goldbugs think any fiat currency will eventually hyperinflate. Note this is an unfalsifiable hypothesis.

</comment></comment></comment><comment><USER35> Dick Cheney returns to political power as an American Hitler laying waste to sovereignty in the Middle East!

Very imaginative. But not very likely.

I think peak cheap oil is likely within the next decade. What a person thinks happens after that says more about the person than it does the future.</comment>


How to ace a hackathon application - <AUTHOR> https://medium.com/@hackthenorth/how-to-ace-a-hackathon-application-88bd76730967#.4ic3ca6by <comment><AUTHOR> Applications are open until mid-July. If you're an undergrad and love to create, we'd love for you to apply.</comment>


The Monkey and the Apple (2016) - <AUTHOR> http://steve-yegge.blogspot.com/2016/11/the-monkey-and-apple.html?m=1 <comment><USER2> Steve Yegge is back! What is this website [http://wyvernsource.com/](http://wyvernsource.com/) he links to?

</comment><comment><USER3> Why the "?m=1" in the URL ?</comment>


The Real (and Imaginary) Benefits of Multitasking - <AUTHOR> http://knowledge.wharton.upenn.edu/article/real-imaginary-benefits-multitasking/ <comment><USER2> As the article mentions, people don't multitask. It's all fast context switching. Up to seven times per second or so. Some are better at it, others are not. One gets one thing done fastest in most detail if one focuses and doesn't switch context, but the brain makes one believe one would be super efficient if one spends time switching context between different things.</comment>


What Happens When a Single Art Project Becomes a Decades-Long Obsession? - <AUTHOR> https://www.nytimes.com/2018/09/18/t-magazine/longterm-art-projects.html <comment><AUTHOR> For examples of labor of love software projects with rather quixotic goals and long development timelines, GNU Hurd and Project Xanadu come to mind. Other examples? (Bonus points if it's a project you were personally involved in)

<comment><USER2> "Cyc is the world's longest-lived artificial intelligence project ... Douglas Lenat began the project in July, 1984" [1]

1\. [https://en.wikipedia.org/wiki/Cyc](https://en.wikipedia.org/wiki/Cyc)</comment></comment>


$100M in bounties paid via HackerOne to ethical hackers - <AUTHOR> https://www.bleepingcomputer.com/news/security/100-million-in-bounties-paid-by-hackerone-to-ethical-hackers/ <comment><USER2> > _$100M in bounties paid by HackerOne to ethical hackers_

Not by HackerOne per se but the companies using the platform.

A better title would be _"$100M in bounties paid to ethical hackers by companies via HackerOne"_.

To be fair, the original message on Twitter reads much better than the title of the article:

> _HackerOne is proud to announce that hackers have earned $100 Million in bug > bounties by hacking for good on our platform._

I was on both sides of this: leading the security team at a company paying bug bounties via HackerOne and also reporting security problems to other companies as a freelancer. To be honest, the experience was always bad in both cases. I wasted several hours triaging bugs reported by "hackers" that often disregarded the conditions of our bug bounty program. People reporting the most trivial things and we would have to pay them anyway just to move on, otherwise they would end up ranting for days.

On the other side, as a bug bounty hunter, the experience is also awful. One of the biggest problems is the fact that you have no way to know if other person has reported the same issue, so you spend hours if not days documenting a vulnerability and creating proof of concepts (PoC) and it is only after your submission that you get a message saying "closed: duplicate issue". Add to that all the back-and-forth trying to justify more complex issues that are slightly more difficult to prove without damaging the system you are testing.

I am glad so many companies and people are still onboard with this service, but I wouldn't blame anyone for closing their account after all the bad experiences I had.

<comment><USER3> > HackerOne is proud to announce that hackers have earned $100 Million in bug > bounties by hacking for good on our platform.

(Tangent) Can anyone recommend a coherent interpretation of that statement?

I know what it means for an individual person to be proud. And I could see an argument for extending that notion to a group of persons _if every_ person in the organization was proud.

But I assume HackerOne has had employees / members come and go over time. And I also assume that some of the past or current members _don 't_ share that feeling of pride for this particular milestone.

So the only interpretation _I_ can think of is that the person writing the PR was being sleazily vague. I.e., trying to get the audience to take a sentiment that's only meaningfully applied to individual humans / animals, and getting them to unwittingly apply it to a brand name instead.

Is there a better explanation that eludes me?

<comment><USER4> Not really sure what you're getting at here. Without getting into the boilerplate cooperate "we're helping the world", it's a perfectly coherent sentence.

</comment></comment></comment><comment><USER5> This is a tangent but it's been fascinating watching the infosec community grow on twitter. It makes me feel super out of the loop with a huge part of my field (i'm more dev/architecture but of course security is important). I kind of dove into it a tiny, tiny bit the last week. I figure with all this time at home for quarantine I might as well start playing in CTFs, etc and hone some skill I'm so used to only using in a reactionary manner.

I'm honestly envious of their community and all of the tools they've created and tutorials and everything for newcomers. They've done a great job getting anyone who is remotely curious the ability to dabble.

When I was coming up as a sysadmin "rtfm."

Anyway, are people making lucrative careers out of bug bounties? What do these "infosec CEO" twitter people do day to day? Their goal is to hit bounties and sell pentesting/exploits I assume?

<comment><USER6> >They've done a great job getting anyone who is remotely curious the ability to dabble.

Any suggestions where to start? I'm several years out of the scene and would love to be reacquainted.

<comment><USER5> I've only done a few hours of research so far and done little hacktivities ([https://tryhackme.com/hacktivities](https://tryhackme.com/hacktivities)).

Then there's hackthebox [https://www.hackthebox.eu/](https://www.hackthebox.eu/) I haven't used this yet.

Mostly I just grab stuff off of twitter/reddit, I don't really know who to recommend right now, I kind of just followed a ton of relatively random open source infosec people organically, but none really scream "has guide for diving in or is a great intro person" off the top of my head.. (maybe @troyhunt), [https://www.reddit.com/r/netsecstudents/](https://www.reddit.com/r/netsecstudents/)

Hopefully someone else can chime in because I'd like to know more as well.

<comment><USER7> I've not seriously started but am considering it. I've only done a few toy problems myself.

On the YouTube side for people who are a bit more casual like me, John Hammond and Live Overflow both seem pretty good for beginners.

John has a bunch popping up on my feed where he runs through a CTF or hacking room and steps through his process, like this SQLite timing attack ([https://www.youtube.com/watch?v=DYLDG_2Vs3E](https://www.youtube.com/watch?v=DYLDG_2Vs3E)) which I found interesting since I knew the concept but hadn't seen it in action before.

Live Overflow also explains things pretty clearly and has covered a variety of topics like using Ghidra, hacking an intentionally hackable MMO, or recreating patched XSS flaws.

I think it's really good to pick a niche first and stick to it, reverse engineering code looks fun but I'm not sure how commercial that skill is compared to busting open web apps.

If you want something to poke and prod at there's also Damn Vulnerable Web Application (DVWA) at [http://www.dvwa.co.uk/](http://www.dvwa.co.uk/)

</comment></comment></comment></comment><comment><USER8> Seems a bit funny, the top scorers didn't have a few massive bounties, but many many little ones. Both of these accounts made most of their hits on Verizon. To get those kind of rates it's probably the same type of flaw present in many places of the system.

It's questionable if these companies are getting massive value for money if most of the bugs are oversights rather than intricate flaws in a bespoke process.

[https://hackerone.com/try_to_hack?filter=type:bounty- awarded](https://hackerone.com/try_to_hack?filter=type:bounty-awarded) [https://hackerone.com/mlitchfield?filter=type:bounty- awarded](https://hackerone.com/mlitchfield?filter=type:bounty-awarded)

</comment><comment><USER9> I feel that bug bounties are still undervalued, and the market is still inefficient because the prices are unilaterally set by companies.

The only other publicly disclosed signals for market price come from third party companies and state actors.

The other signals are not public and hard to quantify, they come from trying to weaponize and monetize exploits yourself. This results in potentially incurring various forms of liability, or reducing that by selling information to a different broker, who will eventually find someone to weaponize or monetize a piece of the exploit. This part is a much more efficient market, but it is not vertically integrated.

The prime bug bounties seem to be trending upwards in value, with the bottom being crowded and with non-serious companies testing the waters.

Does anyone have any ideas to make the value of bug bounties be more dynamic and elastic, trend upwards towards their true value inline with the growth of the sector?

<comment><USER10> I see bug bounty programs as just being another example of InfoSec charlatanism. People do bug bounties because InfoSec people say you should do bug bounties, and not doing what InfoSec people say you should do implies some sort of malfeasance. But the value of them is remarkably questionable. For starters they are absolutely not a replacement for pen testing, having a bug bounty is not a sufficient substitute for any of the pen testing that you should be doing. The value of the bugs you have reported are also typically incredibly low value. Most of the reports you get through bug bounty programs are just the output of open source scanning and static analysis tools. You get no-effort reports for things like frame-able content and "your mobile app has a dependency, which has a dependency, which was compiled with marginally sub- optimal flags". Actually valuable reports do make it through, but I seriously doubt having a bug bounty program is more effective than publishing a security email address on your website. They're mostly just spam generating services that invite people to try pressure you into coughing up some money for largely trivial nonsense.

<comment><USER11> Bounty submissions are _mostly_ scanner spam; maybe _almost entirely_. But every once in awhile you get a serious and important report, and you wouldn't have gotten it without the bounty. Retain 3 different pentesting firms to hit an app and their reports will overlap maybe 70-80%; similarly, bounty people find different stuff as well.

<comment><USER10> > But every once in awhile you get a serious and important report

Yes this is true.

> and you wouldn't have gotten it without the bounty

Of this I am highly skeptical. Most companies that I've worked at who don't have bug bounty programs get the occasional serious report. These reports were submitted to companies before bug bounty programs were even thought up. Bug bounty services just seek to capture value from something that was happening long before they were invented, and I'm highly skeptical of them having a significant impact on generating serious reports that otherwise wouldn't exist.

The other issue is that everybody has a finite security budget, and dealing with the spam is going to (perhaps significantly) eat into that. In those cases, it's taking money that could be spent on something with a decent ROI, and redirecting it to essentially just creating busy work for your security team (or spending their budget on paying somebody else to do that busy work).

I think they really only exist because a lot of security professionals don't really know what they're doing, and a lot of their employers don't really know what they're supposed to be doing.

<comment><USER11> I watched it happen, several times, on projects where I not only had _6 weeks of undivided time_ to run an app assessment before I took over their bounty program, but the client had contracted assessments from other firms prior to me being involved.

It's also a refrain I got from almost everyone I asked about running bounty programs.

A fundamental truth I don't think anybody who does appsec assessments professionally can escape: multiple audits of the same target will turn up different bugs. It happens even if the same people do both assessments! I've never talked to a software security professional who pushed back on this; maybe you'll be the first.

<comment><USER10> > A fundamental truth I don't think anybody who does appsec assessments > professionally can escape: multiple audits of the same target will turn up > different bugs.

I completely agree with this.

> I watched it happen, several times

I don't doubt you have, but this is anecdata. I wouldn't want to draw any conclusions from this, especially because it conflicts with a lot of my own anecdata.

Auditing/security testing is something you could infinitely devote incrementally more budget to, and infinitely receive incremental returns from. While I question it provides as much benefit as you're describing, it can certainly provide a benefit. My issue with it is that, in my experience, it has always had a bad RoI. The resources that you have to devote to dealing with the spam make extracting any value from bounty programs a very expensive exercise. I've personally seen people devoting more than one day a week to managing bounty programs that they were lucky to get one good report per year out of. Imagine how much more value they could have gotten from having a security engineer spending a full day per week threat modeling with the product engineers.

Perhaps the ROI is different if your department is over-funded, or if you have a big brand that people want to write self-promotion blogs about. But any time I hear a security professional parroting the importance of bug bounty programs, the cynic in my wonders whether they're just looking for some low- skill busy work for themselves.

<comment><USER11> I think we'd have to struggle to find a clear debate between the two of us. I just wanted to make the point that people run bounty programs because they do in fact turn up black swan bugs, even after the repeated pentests that most of these firms have already engaged.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> As company you should do bug bounty but in addition, not as replacement of doing your own testing.

The reason: Bug bounty is fundamentally favoring the companies that sign up. They pay next to nothing for getting a lot of eyes on their site and here and there a valuable find will be made.

Rewards should probably be much higher, like 10x I think to attract better researchers.

Also, the latest invention of private programs, where testers aren't even allowed to talk about it or share finds after is a joke as well - it's all just in favor of the companies. The basically buy the researchers silence, e.g. they can dismiss a find and don't pay and just say oops duplicate.

For someone skilled and interested in infosec there are better ways to make money.

<comment><USER13> This is correct in theory but not in practice. Commodity bug bounties have become somewhat of a failed experiment. For most companies, they cost more than they are worth, and that cost doesn't even come from the reward payout.

<comment><USER12> That's a good point, but if I understand correctly Hackerone staff has to triage bugs before a company is even responding or required to look at it? So it's all offloaded, or is that incorrect?

</comment></comment></comment><comment><USER14> The missing figure is how many hours those hackers spent. Most of the companies that were on HackerOne when last I checked are using the platform as a kind of a substitute for contracting with a pen test firm. Things like "will you break my website". With bug bounties, the payout is only for vulnerabilities found, not for analysis effort, and therefore one has to carefully weigh the expectancy. I think that vulnerabilities found is the wrong metric for the industry, because it is really downstream of the true desire. If anything, the metric should be complexity removed. Prove that you made the system simpler.

</comment><comment><USER15> "ethical hacker" is such a trash term.

<comment><USER13> For what it's worth, nobody who actually works in security uses it, and they mostly cringe when others do. That and "cyber" are pretty good smell tests that you're interacting with someone who is very out of touch.

<comment><USER15> yeah, old (by todays standards anyway) infosec hacker here. "cyber" has always a fed/consultant tip off

</comment></comment></comment><comment><USER16> Here's a link to "The 2020 hacker report" by HackerOne

[https://www.hackerone.com/lp/resources/2020-hacker- report](https://www.hackerone.com/lp/resources/2020-hacker-report)

I've looked through it and there's some nice information on how hacker industry emerged and grew into what it is now, talks about money earned by ethical hacking as well.

</comment><comment><USER17> Paid through HackerOne not by HackerOne.

</comment><comment><USER18> What if I introduce security bugs only to be paid bounty on them later

<comment><USER19> I believe that most platforms have restrictions barring you from submitting bug reports if you're affiliated with the company offering them.

<comment><USER7> Easy loophole, work with a friend.

<comment><USER13> And risk losing your 100s of k a year career for a $250 Amazon gift card. Knock yourself out.

</comment></comment></comment></comment><comment><USER20> Worth every penny</comment>


Roads and Bridges: the unseen labor behind our digital infrastructure [pdf] - <AUTHOR> https://fordfoundcontent.blob.core.windows.net/media/2976/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure.pdf <comment><USER2> The first seven pages of "me, me, me" can be skipped. Then comes the important part - that the number of people behind some major open source tools is very small. Everybody on Github knows this - once you get past the top 50 or so open source projects, the number of active developers is very small, often 1. This paper just presents this for a popular audience.

It goes off in too many directions at once, though. This needs to be tightened up to about 5-10 pages.

(At one time, Python's SSL support was maintained by a World of Warcraft guild. They had security problems organizing raids.)

<comment><USER3> It really flies in the face of the common assumption that someone smarter than [present company] is in charge of [difficult domain or problem] that we solve with a library.

</comment></comment><comment><USER4> Development time could be treated as a sunk cost, and given that open sourcing it would improve the quality and maybe also get people working on it for free. You should open source as much as possible. But only if you are confident about your business plan.

The problem I think is that all the one man shops _don 't have_ a business plan.

</comment><comment><USER5> I liked the story format and hope it brings more attention to the need for support of open source projects to folks who would otherwise not know anything about it.</comment>


Why HN is slow lately - <AUTHOR> We've had a huge spike in traffic lately, from roughly 24k daily uniques to 33k.  This is a result of being mentioned on more mainstream sites. I hope this spike will subside, like past ones have.  In the meantime I may temporarily hack a few things to make the site faster, like putting fewer results on threads pages.<p>You can help the spike subside by making HN look extra boring. For the next couple days it would be better to have posts about the innards of Erlang than women who create sites to get hired by Twitter. <comment><AUTHOR> Ok, ok, enough Erlang submissions. You guys are like the crowdsourced version of one of those troublesome overliteral genies. I meant more that it would be better not to submit and upvote the fluffier type of link. Without those we'll be fine.

<comment><USER2> holy shit, i stepped away for like 30 minutes and the entire front page is Erlang. I just submitted the _Innards of Erlang_ article as a response to PG's post/an inside lol for the community (the article is a decent primer though). Almost the entire front page is a bit much guys...

<comment><USER3> As of 22:12 European time, it's the first page _and_ the second page. Olé!

<comment><USER4> :) What's European time? I imagine we (you and me) share Central European Time (CET) but ET?

</comment></comment></comment></comment><comment><USER5> Until I read this, I wondered about the sudden popularity of Erlang

<comment><USER6> Erlang, the next Ruby On Rails ?

<comment><USER7> Damn, and here I was about to throw out all of that code I'd written and to jump on the Erlang bandwagon lest I be left behind.

</comment></comment></comment><comment><USER8> _You can help the spike subside by making HN look extra boring_

I wouldn't mind if, in the service of this cause, the editors killed more fluffy stories.

<comment><USER9> Or just give high-karma users the ability to down-vote submissions that have more than 30 points.

The 30 points limit makes sure that stories don't get killed for the wrong reasons. In fact they don't get killed at all, they just get moved down the page a little faster than they otherwise would.

<comment><USER10> This sounds like a really really good idea.

</comment></comment></comment><comment><USER11> Sorry guys, I'm here to stay. HN's so much more intelligent than Digg, Reddit, etc. Even the tech parts of those sites don't manage to filter out the junk as well. I hope it stays this way, though...

Oh, and I actually found out about the site from Coding Horror (<http://www.codinghorror.com/blog/archives/001236.html>), though I did read the Stack Overflow article as well (via Reddit: [http://www.reddit.com/r/programming/comments/8368a/the_value...](http://www.reddit.com/r/programming/comments/8368a/the_value_of_downvoting_or_how_hacker_news_gets/)).

</comment><comment><USER12> Ever considered just shutting the door to new registrations at peak times to throttle growth? or at least only allowing new members that have been invited from existing members?

I've seen some really whacky comments the last week or so.

<comment><USER13> Or include some fairly simple auto-generated questions.

"At what point does y = 2e^(2x) cross the line x = 2, accurate to 2 decimal points? y = __.__ x = __.__" Extremely simple for a hacker, daunting for the general public. (answer: tinyurl.com/b95cdw rounded up with x = 2.00, of course)

<comment><USER14> You might also get the occasional serious hacker who is just retarded at math (like me!)

<comment><USER15> I would go further, and venture that 'serious hackers who will make good HN citizens' and 'people for whom the above problem is trivial' are two different sets (though the intersection of those sets might be significant).

</comment></comment></comment></comment><comment><USER16> Seems like submitting boring Erlang stories immediately turned into a meme.

First one on HN?

<comment><USER17> First one I remember, anyway.

As much as I like being pompous and saying HN should try not to go into decline, this one I'm happy about. It was all a joke on PG, it had a terrific effect on the stories here in a way that was instantly noticeable here, and it was actually pretty funny.

Now we just make sure this fades quickly enough that a month from now nobody thinks they're "trendy" for mentioning Erlang Week.

</comment></comment><comment><USER18> I'm off to upmod some boring stories.

<comment><USER19> upmod the what web frameworks are missing. snoooze.

</comment></comment><comment><USER20> Still I'm curious, what's the underlying problem?

33k/day doesn't sound like a lot of traffic, honestly. But also I can't imagine lisp being _that_ slow either. Maybe add some caching?

<comment><USER21> If I remember correctly, Arc is an ongoing experiment in language design, not high-performance implementation.

<comment><USER22> And it's running on top of PLT Scheme, which adds another layer of interpretation.

<comment><USER23> And it's running as a single process on a single server without a database storing everything on the file system. That it's doing the traffic it is I find quite impressive.

<comment><AUTHOR> In 2 GB of memory.

<comment><USER24> Extrapolating from the memory-growth graph, how much time would a 16GB ram machine buy you?

<comment><USER25> I'd have thought that most of HN's traffic is on the front page, and it's associated comments. I could well be wrong - But given this I'd have thought 2GB was plenty, and wasn't the bottleneck.

<comment><USER25> Ok maybe not: <http://news.ycombinator.com/item?id=512801>

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> It would be interesting to know what is the likely reason for each traffic spike. Perhaps you could have a page that shows this information in a way similar to the Google finance news items:

<http://www.google.com/finance?q=NASDAQ:GOOG>

<comment><USER21> I'd wager it is due to Stack Overflow's recent article.

</comment></comment><comment><USER2> Done.

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

</comment><comment><USER27> Do you think this is related to the multitude of company launches in YCW09 in preparation for demo day? That's a lot of TechCrunch posts.

</comment><comment><USER28> Man do I love Erlang. I rushed over to HN as soon as I heard a new Erlang community had popped up!

</comment><comment><USER29> > You can help the spike subside by making HN look extra boring

What, submitting a post where I laboriously implemented Surreal Numbers step by step wasn't boring enough?

<comment><USER30> No, it was a great read :-) I like what you're doing with <http://github.com/raganwald/homoiconic>

</comment></comment><comment><USER31> Can we submit posts about women who use the innards of Erlang to create sites to get hired by Twitter?

</comment><comment><USER32> This question might sound ridiculous to majority of people commenting here, but why are you making the site boring instead of trying to improve its performance (putting additional hardware, ditching Arc, whatever)?

<comment><USER33> From what I can tell, correct me if I am wrong, part of the purpose of this site is to operate as a testing grounds for Arc. The focus is on making the language better. So rather then improving performance by providing better hardware, it becomes a matter of improving the site through code. Either by changing the code running the site, or by improving the language itself. But given that this is more of a side project, the resources needed to improve the site are limited. Given the unusual spike in traffic, rather then using limited resources to fix it, or sacrifice the motivation to improve the code/language, the boring article approach is being used.

<comment><USER34> Yes, that. And the site is not trying to be the most popular social news site on the planet. It aims to serve a specific niche that doesn't yet require more processing power.

</comment></comment></comment><comment><USER35> I come to the site daily, but haven't really noticed anything being really all that slow. Could just be timing.

One thing I like doing is following the Hacker News twitter acct: <http://twitter.com/newsycombinator/>

It tweets popular stories and keeps me from visiting the site all that often (unless its a comment link).

Its not a fix, but if anyone out there didn't know about it you should follow. It'll keep you from visiting the site every 5 minutes to see if anything new has been posted.

</comment><comment><USER36> I see people took the Erlang suggestion seriously :P

But I wonder, isn't it a bit silly.. I mean, new people will read this post and find out your evil plans to kic.. err, gracefully lead them out :)

<comment><USER37> if they were going to stick around anyway, then its worth it for the comedy factor alone.

</comment></comment><comment><USER38> I kind of love this, despite having little or no interest in Erlang. It's like that sequence from _The Wiz_ where Richard Pryor keeps declaring different colors to be in style and everyone shows up wearing them. pg should come along every so often - once a month maybe - and just announce that all submissions should be about an obscure language.

</comment><comment><USER39> I'm curious, where does a site like HN have its bottleneck: SQL accesses, server bandwidth, CPU or memory consumption by PLT?

<comment><USER34> There is no database (see the other comments in this thread)

</comment></comment><comment><USER40> More people visiting a site does not make it bad..but more submissions and vote-ups could be the reason for the dilution. Just make that process as hard as possible. How hard can it be to make a user-unfriendly html-hiendish registration page, eh ? :)

</comment><comment><USER41> The webserver is written in Arc, right?

I wonder how hard it would be to inspect the referrer and if an abnormally large influx of users start coming from a specific referrer, start redirecting to programming.reddit.com or stackoverflow or something.

</comment><comment><USER42> Please, don't start Ruby vs. Ergland or Erlang doesn't scale... :)

</comment><comment><USER43> Great. Now you've actually gotten me interested in knowing what Erlang is all about... and I've already got enough side projects to do in my spare time.

</comment><comment><USER44> I can't believe pg implied that Erlang is boring, haha.

</comment><comment><USER45> So, HN is now like the rockstar who puts on a baseball cap and shades and thinks he's out at the WalMart incognito... Ahhh, I get it now. Shhhh ;-)

</comment><comment><USER46> If you're having such a hard time keeping up with the traffic, why not offload the burden of the site to some community members?

Or what about throwing HN up on EC2?

</comment><comment><USER47> I almost thought the site was attacked by a group of guys that just trying to vote up all Erlang related sites. Now I know the reason.

</comment><comment><USER48> I had no idea what Erlang was until a few minutes ago. At this rate I might soon be an expert. naa, feed me more Erlang.

</comment><comment><USER49> I like the current version of HN and it's incredibly fast, so why change it?

Congrats for the 33K unique a day!

</comment><comment><USER50> I feel the urge to twitter/blog that second paragraph, because it's funny. Must...refrain...

</comment><comment><USER51> I have never laughed this hard when checking out the HN front page everyday morning.

</comment><comment><USER52> I was wondering what all those stories about Erlang were doing on the frontpage :-)

</comment><comment><USER53> Are the new viewers gone yet?

</comment><comment><USER54> I just love the energy of the community - Erlang everywhere!

</comment><comment> ryan-allen This is brilliant social engineering, and rather amusing!

</comment><comment><USER55> thats fine but at least let us do this:

<http://news.ycombinator.com/news/!erlang>

<comment><USER55> actually if you click on that link now the result is kinda funny

</comment></comment><comment><USER56> Erlang clogging the pipes...

</comment><comment><USER57> Did you add the word "many" on the saved list, instead of the number of saved stories, for performance tuning?

 _women who create sites to get hired by Twitter_ Well, I thought of flagging this story, but I saw everyone is interested in discussing it!

Anyway, HN is really slow since the last week, and it's being down for 4 to 5 times daily - for me. But when I ping 22.214.171.124 , it works fine.

Maybe killing the spam automatically should help? I am not sure.

</comment><comment><USER58> Hooray!

I vote for a permanent ban on fluffy links.

The Fluffy category ought to include:

\- MBA related stuff

\- Suit related stuff

\- Content free linkbait articles that mention the words "hacker" or "hackers" in the title, like the absolute jewel we had yesterday, where one of the supposed must have skills for a hacker is a high wpm typing speed (I really do think that - in the near future - humans will be able to train monkeys to type)

\- Anything that would appeal to the majority of the "social networking" crowd

\- Anything that offers anything remotely related to the "program software (or any other worthwhile computer activity) with this product, no brain, education, or hard work required!" crack dream

\- Did I mention MBA/Suit related stuff? :)

\- Wannabe MBA fodder

\- Last but not least, I mean (sigh), how can I say this without coming off negatively? well, can't be said, but I will do it. I really do think that the best Heuristic is the Room Temperature Test: anything that would appeal to people whose IQ hovers even close to room temperature ought to be kept off the site period - this includes all of the above, particularly the MBA/Suit Neanderthal stuff.

</comment><comment><USER59> HN is slow lately because PG is a dreamer and too much tied to personal and insignificant taste details (which never combine with a greater user base):

 _HN_ _should_ _have_ _been_ _written_ _in_ _CL_.

;)

</comment><comment><USER60> I'm all set with Erlang now.</comment>


Lsd: The next gen ls command - <AUTHOR> https://github.com/Peltoche/lsd <comment><USER3> Every time I see a project using icon font sets (this particular project recommends Nerd Font [1]), I feel something is very wrong. We already have a sort of way (or two) to represent an image in the terminal, but icon fonts are a different beast because it essentially supports a vector representation. Code point collision is already happening (Nerd Font is already coping with this [2]), and in a long run this seems unsustainable. So... is there any way or proposal to encode a vector image in the terminal? (And no, iTerm doesn't seem to support SVG in its inline image support [3].)

[1] [https://github.com/ryanoasis/nerd- fonts](https://github.com/ryanoasis/nerd-fonts)

[2] [https://github.com/ryanoasis/nerd-fonts/wiki/Codepoint- Confl...](https://github.com/ryanoasis/nerd-fonts/wiki/Codepoint-Conflicts)

[3] [https://www.iterm2.com/documentation- images.html](https://www.iterm2.com/documentation-images.html)

<comment><USER4> Unfortunately, the Unix terminal is a gigantic pile of hacks accumulated since the late 1960s. It's a miracle the software stack manages to stay upright at all; adding features and getting the entire ecosystem to support them would be tough. Introducing the concept of an external resource that has to be fetched doesn't seem impossible to me, but there are a lot of issues that would have to be thought through.

Anyway, one nice thing about TrueType/OpenType fonts is that the vector representation is extremely well compressed. SVG or similar would be an efficiency loss. In this light, fonts are actually a fairly decent and practical way to represent vector symbols that will be cached and reused. Maybe a minimal practical solution might be to add an ANSI extension that requests an appropriate font for a particular area of the screen, perhaps with a URL from which a specific webfont can be fetched.

<comment><USER5> >Unfortunately, the Unix terminal is a gigantic pile of hacks accumulated since the late 1960s.

Agreed, and I don't understand why most of the things still done in the Unix terminal have not transitioned to newer, less hacky environments.

I managed to replace the vast majority of the things I was using the terminal for with uses of about 400 lines of Emacs Lisp code that I wrote about 5 years ago.

A large fraction of my uses of the terminal since then have been for the purpose of my getting my Emacs environment and my data files installed on a fresh install of my OS and for recovering from those times when I inadvertently introduced a bug into my Emacs environment that my regression tests did not catch.

The 400 lines of Emacs Lisp code submits a string I typed to bash with the -c flag then asynchronously (i.e., without blocking Emacs's UI) waits for output from the bash process. I also added a way for the user to arrange for a bell to ring when the process finishes. Notably, there is no provision for the user to cause anything to be sent to the process's stdin after the process is started, which allows the 400 lines of code to use a pipe instead of a pty (which is relevant to this comment thread because if OSes didn't need to support the pty abstraction, they could be significantly simpler). In the rare case when I want to send a string to the stdin of some process I use the shell to set things up:

        echo "here is the string" | some process

That whole command line becomes one argument to a call to bash. The 400 lines of code I wrote cannot be used to interact with a REPL. E.g., if you use my 400 lines of code to run "python" by itself as a command line, the python process waits for user input, which will never come because there is no way to write to the python process's stdin.

The closest analog in standard Gnu Emacs to the 400 lines I wrote is "shell mode" (shell.el) which consists of about 3 or 4 thousand lines of Emacs Lisp code. My code re-uses shell mode's code for interpreting (ignoring in my case) the escape sequences for ANSI color and for interpreting the escape sequences for "carriage control", but (like shell mode) does not handle the escape sequences for cursor addressing. IIRC the main reason I was dissatisfied with shell mode was that it contains hacky code to keep the bash process's "opinion" on what the current working directory is in sync with the shell mode buffer's "opinion" on what it is. In contrast, in my code, the buffer's "opinion" is the only one that matters (because every command line is processed by a fresh bash process on that bash process inherits its current working directory from the Emacs process when it is created).

If I ever were to start to need to issue a great many command lines on a variety of remote Unix servers, I would probably take the time to write a replacement for ssh along lines similar to what I just described.

<comment><USER6> I've been wanting to prototype the idea of an HTML-based terminal. Basically take the graphical user interface of the web and connect it to the system administration capabilities of the Unix command line. I'd probably draw inspiration from PowerShell: have programs produce some kind of data structure as output that can be rendered into HTML and displayed using stylesheets.

It would not be a trivial amount of work to build this since, to take good advantage of the UI capabilities, you'd need an entire new CLI OS - <USER2> to replace GNU Core Utilities. I haven't been sure where to start since the choice of programming language or expression language will significantly affect the overall experience.

<comment><USER7> you have it already: [https://hyper.is/](https://hyper.is/)

<comment><USER8> Great so now in addition to having to support everything the terminal does (the whole pile of garbage hacks that were added since the 60s) you have this electron crap running which on its own is probably more complex than 99% of software out there. This basically took the terminal and made it a hundred times worse.

OTOH, if you do what your parent suggests and start from scratch (no terminal support) you have a platform that isn't supported by anything yet, so unless you port or reimplement everything you need you have to keep using both in parallel which sounds just cumbersome.

</comment></comment></comment></comment></comment></comment><comment><USER9> Even though of course nothing beats the power of a set of standardized and ubiquitous tools that you can always count on whenever you find yourself on a new machine, I must admit that I'm favorably inclined toward this trend (or what I perceive as one) of rewriting classic CLI tools with sometimes radical performance improvement promises, but most importantly (for me at least) better UIs: `grep` has always been acceptable for me, but I prefer `ag` these days, and I recently discovered `fd`, which seems like it will replace `find`, as I could never remember its weird syntax, even for the most basic cases.

<comment><USER10> Try rg (ripgrep) over ag:

[https://github.com/BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep)

<comment><USER11> Never managed to switch to ripgrep over ag. Performance difference is not _that_ much of a dealbreaker in practice, and rg is not totally backwards- compatible to ag. I don't exactly remember, what was the problem. I guess it has this annoying practice to ignore everything that's in .gitignore, while for ag I could set up an additional .agignore per-project.

<comment><USER12> For ripgrep, if you want to use PCRE2 regexes (assuming that's what you meant by backwards compatible), then the -P flag will do that.

Otherwise, ripgrep's support for .gitignore should be substantially better than what's in ag. You can use .rgignore just like .agignore. Both ripgrep and ag also support .ignore. These can override whatever is in your .gitignore.

See the guide for more details: [https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md#a...](https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md#automatic- filtering)

> Performance difference is not that much of a dealbreaker in practice

This is true for smallish inputs. But the difference should become larger for bigger inputs. Hell, sometimes ag just refuses to search inputs that are too big. e.g., For a ~9.5GB file:

        $ time rg '\w+\s+Sherlock Holmes' OpenSubtitles2016.raw.en -c
        3003

        real    1.608
        user    1.105
        sys     0.496
        maxmem  9473 MB
        faults  0

        $ time ag '\w+\s+Sherlock Holmes' OpenSubtitles2016.raw.en -c
        ERR: Skipping OpenSubtitles2016.raw.en: pcre_exec() can't handle files larger than 2147483647 bytes.

        real    0.016
        user    0.004
        sys     0.011
        maxmem  6 MB
        faults  0

<comment><USER11> Thank you for your answer.

What I mean, it doesn't seem to be possible to make it forget about .gitignore files completely. For me, it doesn't make any sense for my grep tool to pay any attention to .gitignore files (let alone info/exclude and such), these are 2 completely separate tools. I might occasionally want for some project to put into .rgignore the same line as I put in .gitignore, but that's an explicit choice. Actually, most of the time I have a few global ignores (which is possible to do with ripgrep) and an occasional .agignore file, while pretty much every git directory has .gitignore of some sorts. This is not something I can get around with, since while .agignore (.rgignore) is totally personal, .gitignore affects everyone who works on the project and serves explicitly to indicate that you ought not commit these files.

If I put "\--no-ignore" in my .ripgreprc, it skips both .gitignore and .rgignore files, which isn't obviously what I'm trying to achieve.

One more thing (even thought it it possible to get around it by writing my own bash function that would invoke rg) is that unlike the ag, rg doesn't seem have "\--pager" option, which I always use heavily, by setting half a dozen of parameters for `less` when grepping.

So these are what I consider a deal breakers and reasons why I didn't switch to rg: while it's true that in some cases I would appreciate a better performance, it's extremely rare that I grep something over a 9.5GB file. And conveniently search for a substring in a project is something that I'm in need multiple times a day.

BTW, noticed one more minor quirk right now: export RIPGREP_CONFIG_PATH="~/.ripgreprc" doesn't work (but RIPGREP_CONFIG_PATH="/home/$USER/.ripgreprc" does, so it's probably almost never an issue).

<comment><USER12> You want --no-ignore-vcs. There are several other --no-ignore-* flags. ripgrep is a lot more flexible than ag there. And its implementation of the gitignore matching rules should work a lot better than ag. (Search ag's issue tracker to see just how many bugs there are. I'd be surprised if you weren't hitting any of them!)

As for a pager, that's pretty easy to solve: `rg foo | less -F`. Add `-R` to make colors work.

You don't need to search a 9.5GB file to make ag upset. All it takes is ~2GB. A key advantage of ripgrep over ag is that you don't have to just use it for code searching. It actually works just as well any place you'd use standard grep. ag just doesn't have an implementation that's good enough to be that robust.

<comment><USER11> > \--no-ignore-vcs

Oh, thanks, I've missed it somehow.

> rg foo | less -F

Yeah, that's what I meant by writing my own wrapper, since I wouldn't want to type that in every time I search for something. And since I use bash, $@ in the middle of an alias is not possible, so: rg() { /usr/bin/rg $@ | less -LFXRqn }

It doesn't seem to be working as expected for me without explicitly adding --pretty though (obviously, rg sees it doesn't operate in a terminal and tries to be smart). End even then it's... weird. I don't know if that's `less` issue of `rg` issue, I'm guessing something about it being multi-threaded: it sometimes doesn't display some found items at the top of the terminal, but if I scroll screen down and up again -- it's there! Cannot reproduce with ag. Gonna play with this for some more time later, but it surely doesn't work as solidly with a pager, as ag --pager='whatever' does.

EDIT: actually found a bug report that seems to describe exactly the same problem. [https://github.com/BurntSushi/ripgrep/issues/513](https://github.com/BurntSushi/ripgrep/issues/513)

<comment><USER12> Interesting. I can't reproduce that problem. Piping to less works perfectly fine on both my Linux and macOS machines.

If you're willing, I'd definitely appreciate it if you could update #513 with your environment. In particular, by answering these questions: [https://github.com/BurntSushi/ripgrep/issues/513#issuecommen...](https://github.com/BurntSushi/ripgrep/issues/513#issuecomment-308542044)

If it's convenient and you could try it in a different environment (perhaps a different terminal emulator or a different shell), then that would be great.

Also, this doesn't sound like a multi-threading issue to me, but if you want to rule that out, then `-j1` will force ripgrep into single threaded mode.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> One major showstopper I have with this utility is that it doesn't obey my terminal color scheme and instead hardcodes some colors that probably just look good on author's terminal. [1]

Would love to see this resolved, cause it seems rather nice otherwise.

[https://github.com/Peltoche/lsd/issues/90](https://github.com/Peltoche/lsd/issues/90)

</comment><comment><USER14> This project becomes pretty ridiculous when you realize you can already accomplish the same features with regular ls, if you just bother to read a bit. That means the target audience for this is very junior engineers.

<comment><AUTHOR> Can ls use nerdfont? Does ls color coding display anywhere near the granularity that lsd and colorls feature?

So please drop the dismissive patronizing tone.

<comment><USER15> OP's point is that if you know how to use ls you don't need icons and extra granularity in color scheme to understand the output.

<comment><USER16> The same is true of reading a hex dump of the inode table. Improved UIs can matter.

</comment></comment></comment></comment><comment><USER17> This is pretty and all, and there's nothing wrong with it, but...why? Do people run ls enough that they need something more than a plain ASCII list of filenames? Are peoples' directories so disorganized that this adds enough value to justify it over /bin/ls?

I probably run ls a few dozen times a day, but it's usually just to answer "what did I call that file again?" or "did I remember to copy that over?"

I can't imagine a scenario where I'd require too many extra visual cues. I use color ls, mostly because I find the optional symbols like '/' to be distracting, and differentiating files and directories via color is about all I care about.

There's overhead in becoming too attached to non-standard tools: you have to go out of your way to install them, your muscle memory needs retraining, etc.

Most importantly, tools like this break a bunch of core command line standards, like doing one thing and doing it well, and producing clean output that can be pipeline-filtered with all the other Unix standards.

<comment><USER18> One need only consider that Orthodox File Managers have been in existence for decades to realize that yes indeed people do like to work with more than plain lists of filenames.

Playing the "doing one thing" card when it comes to ls is rather risky, as ls, with its options for doing things like sorting its output, is one of the favourite examples that people point to of tools that do not adhere to this philosophy in practice.

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

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

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

... and so on.

</comment></comment><comment><USER19> Has anyone made an "awesome" list of new CLI tools designed to replace ancient ones?

<comment><USER20> Found some links.

[https://github.com/alebcay/awesome-shell](https://github.com/alebcay/awesome- shell)

Only for rust but not a bad list I think.

[https://lib.rs/command-line-utilities](https://lib.rs/command-line-utilities)

Some blog post introducing cli tools.

[https://darrenburns.net/posts/tools/](https://darrenburns.net/posts/tools/)

<comment><USER21> [https://altbox.dev/](https://altbox.dev/)

</comment></comment></comment><comment><USER22> How does it compare with exa?

[https://the.exa.website](https://the.exa.website)

</comment><comment><USER23> I've noticed a lot of command line utilities are being rewritten in Rust. Is there a reason for this?

<comment><USER24> Possibly because

1\. People predict Rust will be more popular in the future, so they're trying to learn/master the language by practicing it.

2\. People think speed and memory safety are important guarantees for unix programs.

3\. People are testing whether Rust deserves the fame it has

<comment><USER25> > 2\. People think speed and memory safety are important guarantees for unix > programs.

I don't think any of the typical unix tools ever segfaulted on me in the last 15 years I use Linux.

<comment><USER26> Segfaults are the ideal case for memory errors, and those are the most easily caught and fixed, so you're least likely to see them. But, often those memory errors result in silent corruption which can be exploited, and that's harder to detect, especially if it relies on very specific corner cases. `curl` has had a number of these vulnerabilities over the last several years, for example.

Something as simple as `ls` is probably so small and battle tested that it's not an issue, but if you're writing an all-new, not-battle-tested tool, why wouldn't you want stronger guarantees? The new tool is being written for the features, but it's not fun to write vulnerabilities into something that should be simple and "just work."

Languages like Go and Ruby are also mostly memory safe, so those are generally fine picks here too, but every language has trade offs. In this case, the author clearly cares about performance, which Ruby does not care about.

Rust also has a built-in testing harness, which is a lot more convenient IMHO than using whatever C testing framework you might have a predisposition towards.

<comment><USER27> Regarding segfaults, when I was interviewing devs for C++ roles, I'd ask questions about a simple function like this:

      std::string foo(bool flag)
      {
        if (flag)
          return "true";
      }

Questions I'd ask: * Is the function well formed (Yes - functions need not return a value on all paths due to C ancestory, even if the return type has a non trivial actor - not sure if this is still considered well formed, but I think it was as least to C++11) * what happens if 'foo' is called with true? (Returns "true" as one would expect) * what happens if 'foo' is called with false? (Undefined or implementation defined behavior, but generally nothing nice - segfault, acces violation, etc)

* if it crashes, where, when and why does it crash? (Technically since its undefined, nearly any answer here suffices, if it can be backed up. Since practically, most optimizing compilers assume UB can never happen, when you return nothing from a non-void function, the compiler will attempt to invoke the destructor of a non existent object instance (assuming non POD) and boom.)

I asked this because it was a distilled example of a real world rare crash that was extremely difficult bug to track down because the crash location is often know where near the offending function.

I remember getting into a heated argument with a coworker when I claimed it should have been a compilation error. IIRC, he claimed it to be a halting problem and that the compiler couldn't determine that all paths didnt return a value. I called BS, citing at the time (circa 2004) that the new compiler on the block for C# could reliably emit errors when not all return paths returned a value.

I also like it that in C++, it's a very rare example of a very terse example dealing with a number of topics such as undefined/implementation defined behavior, debugging, compilation settings (warning levels, etc) all in a mere 4 lines of codes. With 4 LOC, which is straight forward and simple for the candidate to mentally parse, I can gleam a lot about their understanding of the language (and it's potential pitfalls).

Sorry if this got a little long winded and ranting.

<comment><USER28> > he claimed it to be a halting problem and that the compiler couldn't > determine that all paths didnt return a value.

Theoretically we can't determine whether a function will return a value or not. In practice, heuristics get 99% of the way and the last 1% you can make the programmer put in a possibly redundant return statement.

<comment><USER29> There are two different questions: "do all paths lead to returning a value?" and "will the function return a value?"

Answering the second in the general case is equivalent to solving the halting problem. But answering the first question is much simpler. Static analyzers aren't using a heuristic approach to the second question, they're solving a completely different problem.

<comment><USER30> Don't get me wrong, but if whole classes of errors, can be avoided by not choosing C++, why should I choose to use it?

<comment><USER31> Because you already know C++ and don't want or can't justify learning another language. That's a very valable reason.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> Given the name, I was surprised at how much sense the choices of colours made.

</comment><comment><USER33> How does this compare to exa.

<comment><AUTHOR> I don't think exa uses nerdfont for one.

It's also a lot faster, according to the benchmarks.

<comment><USER20> exa does have a fork which does but exa's development seems to have paused.

[https://github.com/ogham/exa/pull/368](https://github.com/ogham/exa/pull/368)

</comment></comment></comment><comment><USER34> Wish it would disable ANSI stuff (--classic) if it's not a vt100/xterm/etc TERMinal.

</comment><comment><USER35> wow this is amazing... I love the file icons and it's beautiful... ls --tree ran almost instantly on a laravel folder which has a huge number of packages....

</comment><comment><USER36> I use below sometimes. Hope you guys like these.

A modern replacement for ls, written in Rust. [https://the.exa.website/](https://the.exa.website/)

ls with coloring and icons [https://github.com/Electrux/ls_extended](https://github.com/Electrux/ls_extended)

</comment><comment><USER37> Is there a list of features? Or can I assume it implements the same features as colorls?

</comment><comment><USER38> Why would I use this over exa? [https://github.com/ogham/exa](https://github.com/ogham/exa)

</comment><comment><USER39> We really need a way for terminfo/termcap to indicate whether a user has Powerline fonts. Would be great for programs like this.

</comment><comment><USER40> Looking at the example -- do the symbols really help any more than just normal highlighting, and, `x --> y` and `/` at the end?

</comment><comment><USER41> There is an easier way to do this - Use File Manager UI

<comment><USER42> Is that something you can use from the terminal?

<comment><USER43> Of course [https://ranger.github.io/](https://ranger.github.io/)

<comment><USER44> At that point, just use MC... [https://midnight- commander.org/](https://midnight-commander.org/)

</comment></comment></comment></comment><comment><USER45> to install "sudo snap install lsd --classic"

</comment><comment><USER46> It doesn't install a man page for itself, requires weird-ass fonts, has a fraction of the features of the real ls [0], and runs about half as fast ...

However it's written in our lord and savior RUST and has lots of colors so this shit is definitely "next gen."

0: [http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls...](http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html)

<comment><USER47> I'd call this a "shallow dismissal" ([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)): perhaps you could reword your response to be a bit nicer?

<comment><USER48> I think there was a number of reasons given.

<comment><USER47> It wasn't particularly nice, though, and I'm not quite sure all of the comments given qualify as non-shallow.

</comment></comment></comment></comment><comment><USER49> They're gonna need a better list of reasons to try it out than:

1\. It's written in the author's preferred language</comment>


Show HN: Mini-Air Personal Air Conditioner - <AUTHOR> https://www.kickstarter.com/projects/979623853/mini-air-personal-air-conditioner

<comment><USER2> Hmmm. 3" tall, about 1.5" in diameter. Cooling air by around 10 degF. I'm not going to be so uncharitable as to say "impossible," but I will note that it would require the energy density of a bomb even if the entire volume were nothing more than batteries. Not something I'd wear around my neck!

I wonder where the hot air goes...

</comment><comment><USER3> No idea how it works, but I really hope you can make it happen.

There's a HUGE market for this kind of thing in the 3rd world, especially for those who can't afford air conditioners everywhere, or where electricity is spotty (including some of the biggest cities in the planet).</comment>