China prepares to grow vegetables on Mars - <AUTHOR> https://www.google.com/hostednews/afp/article/ALeqM5hod_Ie0wMvZ5X0-YlGuCU9G63PNw?docId=CNG.46a88dd86d10a67a9033edc98156d446.471 <comment><USER3> How well could this work?

On the plus side (for plants), the Martian atmosphere is about 95% CO2. Even though the total pressure of the atmosphere is much less than our own, the partial pressure of CO2 is still about 20 times higher (erring a bit on the generous side).

On the other hand, Mars is about 1.5 times as far from the sun, so the intensity of sunlight is less than half, and temperatures are correspondingly colder. Then again, if we're going to support human colonists, we probably need a nuclear power source anyway. So let's assume we rig up bright lighting to grow our plants.

There's some uncertainty about the soil, but at least some studies suggest that it could support life. There's probably frozen water there, so we'll use the spare heat from our nuclear reactor to melt some.

Humans need approximately 30g of Oxygen per hour, which is roughly 1 mole. A fast-photosynthesising plant can produce 30 umol/m2/s. Running the numbers, you'd need 9 square metres of leaf area photosynthesising at that rate per person - assuming it could carry on 24 hours a day. To supply food, you'd need rather more, because not all of the carbon fixed goes into edible parts.

This is actually a lot more feasible than I initially thought. You'd probably want to send robots ahead to construct the base and plant the plants, though. And you still have the problem of life support for the journey, which would be several months.

<comment><USER4> If you have a nuclear reactor or extensive solar panels, you may just as well use it to split CO2 into O2 and CO (monoxide gas can also burned as fuel). Plant photosynthesis is rather inefficient if your goal is a breathable atmosphere. If the goal is biomass for food, then just call up Monsanto for a few space-dense crops.

It would probably easier to oversize the powerplant (to generate oxygen, growlights, melt water, treat air and waste) than to try to bring along a whole biological ecosystem. On the first few trips at least...

The advantage with the powerplant approach is that you can live anywhere with rock and ice in the soil (most airless planetoids) or CO2 and water in the atmosphere (Venus, Mars or the gas giants).

<comment><USER5> If you burn CO as fuel you are producing CO2 back.

<comment><USER4> It may be useful as fuel for a mars vehicle or for rockets (electric vehicles will take you not very far and it's hard to strap the nuclear reactor to it). CO is easier to store than hydrogen. Of course, if you have a steady supply of ice you can make methane/methanol which is better for that purpose. But to extract ice you will need heavy mining machinery, earth-moving etc...

CO + O2 fuel would make more sense on Venus, where water would be more scarce (water is present in thin clouds of sulphuric acid in about 25% concentration). The surface, however, is another business.

More on Venus (a surprisingly appealing place to go): <http://www.space.com/5653-cloud-cities-venus.html>

And a story by Geoffrey Landis <http://www.asimovs.com/2010_09/exc_story1.shtml>

</comment></comment></comment></comment><comment><USER6> It's odd that any mention of Elon Musk colonizing Mars results in rapturous worship.

Other efforts, China in particular, seem to attract scorn. Especially in light of the fact that Elon Musk's original plan was to send a greenhouse with plants to Mars.

Perhaps I over-estimate the HN crowd.

<comment><USER7> >Perhaps I over-estimate the HN crowd.

Perhaps this has something to do with China's absolutely atrocious record regarding:

1) The environment

2) The rest of the world

3) Human rights

\--

Is it really that difficult to understand that some of us have the foresight to realize that China's method of interfacing with its environment is not something that we want to see tarnishing a yet-untarnished planet?

<comment><USER8> Think of the verdant fields that could be reduced to red dust!

Truly, an environmental catastrophe. They could render the planet uninhabitable. :(

<comment><USER9> Funny, but I think the actual concerns are more along the lines of _"What happens if it works?"_

If they accidentally unleash an Earth origin extremophile, it would have the potential to taint any any life that may already exist on Mars. This hypothetical life on Mars probably isn't of any real _use_ to us, obviously it isn't megafauna or something, but it would be of _unspeakable_ scientific importance. The chance to study live from an independent instance of abiogenesis.. I just can't find the words to describe how important that would be.

<comment><USER10> We know all that. That's why we're being cautious about exploring it now; but we should be able to get a definitive answer on the presence or absence of Martian life within a decade or two. If there is life there, we'd be better off studying it i _in situ_ than trying to transport it back and forth.

Present or not, we need to have some kind of strategy for how to survive there on a long term basic, either for a small-scale scientific mission or on a larger scale to terraform.

Besides, there are several other places in the solar system that have the potential to host life, such as Europa. I don't want we should spend so long sitting on our hands that another generation or more has to die without seeing the human race explore further. It irritates me that it's already 40 years since the last moon landing: <http://xkcd.com/893/>

<comment><USER9> Oh certainly, I feel the same way. We are definetly going to put humans on Mars eventually, and better sooner rather than later, but I think that it is something that needs to be done with an incredible amount of caution. There are definitely concerns about contamination that need to be considered carefully when planning such missions.

</comment></comment></comment></comment></comment></comment><comment><USER11> > _"If we establish a party branch in space, it would also be the 'highest' of > its kind in the world," Xinhua quoted Yang as saying._

Really, I love Chinese humor. It's underrated.

<comment><USER12> It works like this: Grade school kids running around have puns pop into their heads, so by the time they get to high school, they're over the obvious ones. However this only works for their native language.

This is why translated puns can sound very stupid. It's also why you're likely to sound stupid when you try to pun in Chinese.

</comment></comment><comment><USER13> As Bruce Sterling says: "I'll believe that people will colonise Mars when they start colonising the Gobi desert."

<comment><USER14> The incentives for colonising the Gobi desert are vastly smaller than for a (small) colony on Mars or the moon, even just in perceived prestige.

<comment><USER15> But the costs are also vastly larger, and the payoffs likely smaller.

And prestige? 1/3 of the Earth's land surface is covered by desert. If you could suddenly transform that from a life-hostile to a life-flourishing environment, you'd win as many Nobel Peace Prizes as they can possibly stamp out.

<comment><USER16> Transforming the desert into a life flourishing environment is really easy, you just have to add enough water. I believe that's how they do agriculture is large parts of Africa. It's of course quite expensive to do so if you can't get the water from, say, an aquifer. Sometimes you can even flood the whole area, if you want to

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

<comment><USER15> That's an interesting link, but it doesn't really discuss the ecological effects of such a project regarding human habitablity in surrounding areas. I'm more hopeful for something like the Green Wall of China[1], but aggressive enough to actually reclaim desert rather than merely halt its advance. It's also a plus if it works on a timescale of less than a century. :)

Though we should also note that turning desert into (ideally) arable land could have disastrous unforeseen effects; consider how much of the Amazon is fertilized by the Sahara.[2]

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

[2] <http://earthobservatory.nasa.gov/IOTD/view.php?id=7279>

</comment></comment></comment></comment></comment><comment><USER17> If China manages to do this, then we will have people on Mars in under 2 years.

Competition from china is the only thing I can see spurring the USA into action.

<comment><USER18> Far from. It takes nearly 2 years just to get to Mars.

Also, China tends to be a _fast copier_ , not a leader. They seem to leave the bulk of development costs to someone else. So I think it's unlikely that they will front the resources it'll take to make a Mars mission possible.

<comment><USER19> > China tends to be a fast copier, not a leader

Wasn't there a famous Chinese guy who said something like "never underestimate your adversary".

In the past that might have been true, but things change. Just one example A lot of people have been educated in the US, and are going back to china to start companies.

<comment><USER20> Does he count as Chinese if he died before the Qin dynasty began?

</comment></comment></comment></comment><comment><USER21> I hate to knee-jerk this one, but my first reaction to this is that it's probably propaganda. In the States a few years ago, there was an effort to create a self-contained ecosystem and it failed no matter how hard the engineers behind it tried. That China can suddenly say "Yo guys, we got it to work" out of the blue is suspicious at best.

Not to say they haven't got something half-functional. I'm just very skeptical that it's as great as they say it is.

</comment><comment><USER22> Since soil samples on mars seem to be strongly oxidizing, even containing perchlorate, the vegetables are likely to catch fire upon touching martian soil.

<comment><USER23> And growing vegetables on the moon is far too expensive to be practical - <USER2> rocks cost thousands of dollars per gram!

EDIT: OK, for the benefit of whoever didn't have a sense of humor, I was suggesting that the astronauts might be planning on bringing some soil with them.

<comment><USER24> ever heard of supply and demand?

<comment><USER23> Yep. It gets kind of interesting though when you think about the challenges.

You could have a really good plan to convert martian soil for plant use, but then again, that might fail. This obviously means you can't _depend_ on your garden. Also, what you would have would be a laboratory, not a garden. You would spend a lot more time analysing the food than eating it.

On the other hand, you could carry out a sample return mission, bring some mars dust back, run tests, and land with a solid plan. Only thing is, sample return from mars would make moon rocks look cheap.

Finally, bringing the soil with you would be the most reliable method. It's moon rocks in reverse though! That soil would be, kilo for kilo, the most expensive soil in the history of mankind.

<comment><USER23> Thinking about this more, I guess hydroponics might be the way to go ;)

<comment><USER25> Another way that growing marijuana is benefiting mankind! ;-)

</comment></comment></comment></comment></comment></comment><comment><USER26> Fill in the blank:

      1. Develop system capable of growing plants on Mars.
      2. ____________________
      3. Grow plants on Mars.

<comment><USER27> Presumably they are also working on that.

Also, you forgot step 4.

<comment><USER28> Profit?

</comment></comment></comment><comment><USER29> China should focus on developing non-contaminated produce in China, so their elite doesn't have to import it.

</comment><comment><USER30> I'm all for this, the current policy of "don't contaminate Mars with organic materials" brings us nowhere, let's put some life on there and see what happens!

<comment><USER31> I'd be a big fan of sending loads of bacteria with the potential to survive, and some water and stuff, to Mars. Just to see what happens. Hey, the Martian environment would be a "gross evolutionary pressure", right? :)

<comment><USER32> Fantastic. We can check back in a few million years to see how it's working.

<comment><USER31> We've got to start sometime ;)

</comment></comment></comment></comment><comment><USER33> Could curiosity give us a good enough picture of the soil composition on mars that we could recreate it on earth and practice growing plants?

<comment><USER34> I've only skimmed through the first bit, but this probably answers the question. [http://www.geology.wisc.edu/~astrobio/docs/Seiferlin_et_al_2...](http://www.geology.wisc.edu/~astrobio/docs/Seiferlin_et_al_2008_Planet_Space_Sci.pdf)

</comment></comment><comment><USER35> Well, I'm glad someone is thinking about what to do when they get there.

</comment><comment><USER36> It's a worthwhile goal but the preparing is a poor choice of words because it sounds like it's happening next week. You prepare yourself for work in the morning. You prepare for going to the supermarket. You prepare to take a dump by making sure toilet paper is present. You prepare for a trip. You research growing plants on Mars for many years and eventually stage operations on the Moon. Finally, when the day comes, you prepare for the first mission to Mars.

</comment><comment><USER37> But this cannot be of much use, even if they can make an atmosphere somehow, they would need an active core for magnetic field to protect from solar particles/radiation.

<comment><USER23> Their experiment was using a closed biosphere, so they're bringing the atmosphere with them.

Really, I think the original article was terrible; it omitted important details to make the whole thing sound more silly. Closed biological systems are an interesting field of research.

I'm not sure about radiation levels on a mars mission, but if we can solve the problem for humans, it should be solvable for plants/algae.

</comment></comment><comment><USER12> There's a lot of thinking in the comments here which is good for what it is, but which lags far behind engineers and scientists who have thought about it for years.

Get your hands on this book and read.

<http://amzn.com/0684835509>

<comment><USER38> There is a new version people should get instead. Not much has changed but we might as well direct people to the latest stuff:

<http://www.amzn.com/145160811X>

<comment><USER12> Sorry, wasn't paying attention.

</comment></comment></comment><comment><USER39> These are very good news indeed. I started to wonder what good Elon Musk's colonists and tourists will do on Mars upon arrival. And it appears that they shall be able to buy some grocery! Isn't that wonderful?

</comment><comment><USER40> would've been interesting to know what kind of vegetables.

<comment><USER23> Ah, found it: this is a much better link for the story: <http://english.peopledaily.com.cn/90786/8044143.html>

"During the experiment, four kinds of edible vegetables, namely lettuce, leaf lettuce, gynura bicolor and sonchus oleraceus, were planted in a 36-square- meter area to absorb the carbon dioxide exhaled by the two astronauts and provide them with oxygen and 30-50 grams of fresh vegetables per meal per person."

Google tells me you need 1 ton of soil to cover 30m^2 to a depth of 25cm. So now I'm interested to know if/how they're optimising for mass efficiency.

<comment><USER28> I think they'll use Martian soil. That's what Elon was planning, and other commenters below speak to its practicality.

</comment></comment></comment><comment><USER41> One of my first thoughts was: what will the effects of the reduced gravity be on the plants? Will they still be able to grow successfully?

<comment><USER32> I've seen plants in photos of the space station and shuttles.

</comment></comment><comment><USER42> I can totally understand. Growing vegetables on earth just doesn't generate big enough GDP for the 8%-a-year-every-year target.

</comment><comment><USER43> I stopped reading at "develop their own sources of ... water"

</comment><comment><USER44> China has been doing great lately, but this sounds like a case of Icarus to me.

<comment><USER45> You've got it wrong.

Mars is further from the sun.

<comment><USER12> _> You've got it wrong. Mars is further from the sun._

Actually, this has been studied. There's enough sun with the right timing and thermal balance (provided the right kind of greenhouse) to grow food.

<comment> qu4z-2 I don't thing the GP was worried about the amount of sunlight needed to grow food, but rather pointing out that Icarus's downfall was flying too _close_ to the sun.</comment></comment></comment></comment>


Chinese law will force game makers to reveal loot box drop rates - <AUTHOR> http://www.pcgamer.com/chinese-law-will-force-game-makers-to-reveal-loot-box-drop-rates/ <comment><USER2> Having a law for everything... this doesn't work out well in the end.

<comment><USER3> It sounds like they're assuming more for casino-like games. I don't know how gambling is regulated in China, but that change would bring it closer to other countries where gambling machines need to achieve the registered win/lose rate.

Of course that doesn't change the fact that it will move the steam market prices...</comment></comment>


A Mathematician Hacked Into Google, Thinking It Was A Job Interview - <AUTHOR> http://www.businessinsider.com/a-mathematician-hacked-into-google-because-he-thought-it-was-part-of-a-job-interview-2012-10?0=defense <comment><USER2> What a poor title, sadly the article itself is even worse. The Wired article is much better: <http://news.ycombinator.com/item?id=4692453></comment>


Show HN: Remote Work Statistics - <AUTHOR> https://remotehub.io/remote-work-statistics <comment><AUTHOR> I made this. Must say that there's probably not too much useful info yet as I don't have a huge amount of data. But maybe it's still fun and it gets better every day.

I've been thinking about opening up community editing if HN people would like to add info about the company they are working at remotely. I currently have:

* 188 remote companies who work in

* 1310 cities across

* 94 countries

There are following categories:

* TOP 10 most cities

* TOP 10 most countries

* TOP 10 hottest climate (idk why I made this)

* TOP 10 benefits

* Cities with most teams</comment>


Ask HN: Any books related to machine learning or AI - <AUTHOR> similar to "Data Science from Scratch" or "Programming Collective Intelligence" where no external libraries are used to implement the algorithms? <comment><USER2> Here are two good ones freely available - they are not new and hip, and more focused on the basic ideas rather than writing code, but the basic ideas don't really change that much over time

[https://web.stanford.edu/~hastie/ElemStatLearn/](https://web.stanford.edu/~hastie/ElemStatLearn/)

[http://www.inference.org.uk/itprnn/book.html](http://www.inference.org.uk/itprnn/book.html)

</comment><comment><USER3> [http://aima.cs.berkeley.edu/](http://aima.cs.berkeley.edu/) and [http://users.isr.ist.utl.pt/~wurmd/Livros/school/Bishop%20-%...](http://users.isr.ist.utl.pt/~wurmd/Livros/school/Bishop%20-%20Pattern%20Recognition%20And%20Machine%20Learning%20-%20Springer%20%202006.pdf)

</comment><comment><USER4> You might like the books from Jeff Heaton:

[https://www.heatonresearch.com/book/](https://www.heatonresearch.com/book/)

All chapters come with example code written in C#, Java and R.

</comment><comment><USER5> I know those two that explain deep learning from scratch:

[http://www.deeplearningbook.org/](http://www.deeplearningbook.org/)

[http://neuralnetworksanddeeplearning.com/](http://neuralnetworksanddeeplearning.com/)</comment>


Post Mortem: A single whitespace character - <AUTHOR> http://eatabit.com/blog/articles/post-mortem-a-single-whitespace-char.html <comment><USER3> Likely "Cowboy" is a transparent proxy added by your mobile service provider. I had a similar thing happening a year ago when the mobile provider used by most of our barcode scanners decided to add a transparent proxy into the loop (without telling anybody).

The solution for this problem: Use SSL.

I mean: There are already many good reasons to use SSL, but whenever you need to send any kind of mission critical data over the mobile network, you practically _must_ use SSL if you want any kind of guarantees that the data you send to the server is what actually reaches the server (and reverse).

Here's my war story from last year: [http://pilif.github.io/2013/09/when-in- doubt-ssl/](http://pilif.github.io/2013/09/when-in-doubt-ssl/)

<comment><AUTHOR> We would really like to use HTTPS but it's not supported by the Arduino chipset as I understand it. Though I'm not the hardware guy here at eatabit...

<comment><USER4> Why not ROT13? Or a simple substitution cypher?

Not trying to be silly. But if the only goal is to prevent man-in-the-middle attacks such as someone mangling the data, why not "corrupt" the data such that the phone company in the middle can't read it?

You control both ends. You can make your own "security".

You're not explicitly worried about security. You're not worried about Evil Person reading your messages. You just want your carrier to stop f'ing with your data.

If the data is slightly corrupted so the carrier's crappy software can't recognize it as http headers then the carrier's software (hopefully) won't fck with it.

<comment><USER5> They could try a different port - some systems won't bother.

They might also use TLS with null cipher. That should be not-so-intensive, even on a tiny processor. And it could be enough to defeat some packet- modifiers (they may notice it's TLS and not analyze), while maintaining HTTPS compatibility.

</comment></comment></comment></comment><comment><AUTHOR> Heroku came back and said:

Looking through the system, I see that you were sent two emails (in August and September) as several of your apps were migrated to the new routing stack ([https://devcenter.heroku.com/articles/heroku-improved- router](https://devcenter.heroku.com/articles/heroku-improved-router)). As mentioned in the documentation, the new router follows stricter adherence to the RFC specification, including sensitivity to spaces.

...and sure enough, there is a line that says:

The request line expects single spaces to separate between the verb, the path, and the HTTP version.

So the lesson is: RTFM

-G

<comment><USER6> The team at Heroku (where I currently PM) is constantly trying to improve our communication and documentation. We're definitely sorry that this caused problems, and we'll work even harder to make sure that our communication calls out any potential issues. Again - thanks for reaching out to us, and let us know if we can help.

<comment><AUTHOR> Heroku did their best here. They reached out to us (twice) advising of changes and linking to a document that describe EXACTLY the bug that we discovered (later). Honestly, I don't feel bad about his bug because even if I would have read the alert to the letter, we would not have audited the entire codebase because we don't have that luxury of time. Yes, it took our whole operation down...but we found it, fixed it and now we're back up. ...it's all in the game. -@eatabit

<comment><USER7> That's all true but once you start accepting illegal input on a protocol for a long enough time you can't just suddenly go and break things without an automated alert to the customer when that particular thing starts acting up.

After all it would not be that hard to scan for which customers are going to be bitten by that particular change when it actually happens rather than using some fire-and-forget email.

</comment></comment></comment></comment><comment><USER8> This very example -- requests were technically illegal all the time without devs realizing, but something in the stack changed to start rejecting them -- demonstrates the fallacy of the "be liberal in what you accept, strict in what you issue" principal. If all the web servers involved had been strict in rejecting the illegal request from the start, they would have noticed the bug in development before deploying to firmware in the field.

<comment><USER9> I don't agree that "be liberal in what you accept, strict in what you issue" is a fallacy. The client actually failed to adhere to the "be strict in what you issue" principal, just as the Cowboy was not liberal in accepting. All software will sooner or later exhibit bugs or be stricter or more lenient about a standard.

I think the fallacy is to assume that once stuff works in production, only your changes can trigger a bug. There's way too much software involved in a standard webserver stack to assume anything about it. Any patch, any update to software or devices not under your control has the potential to break your stack. The thing the OP did was the right thing: Monitor, monitor, monitor.

<comment><USER8> The problem is that "be liberal in what you accept" is, by definition, saying to go beyond the standards, accepting things that are technically illegal according to the standards.

So different software will necessarily do it differently. For all software to be doing it the same, there would realistically need to be some specified standard on how to do it, and then we're no longer talking about 'be liberal in what you accept', but just 'accept exactly what the standards say.'

Of course, in this case the client software was not being 'strict in what you issue' \-- I am not challenging that part, of course you should _always_ issue exactly correct according to standard requests or other protocol communications. But there will inevitably be bugs, bugs happen.

"Be liberal in what you accept" makes it harder to find those bugs, and leaves them waiting to surprise you when the (non-standard) level of "liberalness" on the receiving end changes, which it inevitably will because it was not according to standard in the first place.

I think the HTML/JS/CSS web provides another good example of the dangers of 'be liberal in what you accept', very similarly -- you may think your web page is 'correct' because one or more browsers render it correctly while being 'liberal', and not realize it's in fact buggy and will not render correctly on on or more other past, present, or future browsers. This example has been commented upon by others, and I think has led to a move away from 'be liberal in what you accept' in web user agents. [http://books.google.com/books?id=5WXp4j4eV4UC&pg=PA136&lpg=P...](http://books.google.com/books?id=5WXp4j4eV4UC&pg=PA136&lpg=PA136&dq=be+liberal+in+what+you+accept+web+browsers&source=bl&ots=48B_3l1pWX&sig=LGm7MvGg- Gc4BqVFTBp- xYwiPBI&hl=en&sa=X&ei=zIFOVIKIMYLbsATvhILIDQ&ved=0CD8Q6AEwBQ#v=onepage&q=be%20liberal%20in%20what%20you%20accept%20web%20browsers&f=false)

<comment><USER10> How about this as a middle-ground:

Be strict in what you issue (duh!), be liberal in what you accept - but both emit strong warnings when the input isn't strict, and have a strict mode.

<comment><USER5> That doesn't work. Strict mode ends up getting turned off by default, or turned off at the earliest problem. After all, what's the point in being so strict? I've seen security bugs arise from this, nicely commented in source with a "// spec says x but no need to be so pedantic".

If everyone can be strict in what's sent, then the problem is solved. But since that won't happen, even on accident, the only solution is to be harsh on receiving input and hope things fail early in the dev cycle.

Also, text-based protocols are especially prone to this poor handling, A: because spec writers (like HTTP's) go moronically overboard, being all creative (line folding? comments in HTTP headers? FFS!) and B: because text is so easy, everyone just figures anything goes and pays less attention.

</comment></comment></comment></comment></comment><comment><USER11> The Server: cowboy tag is from an Erlang web server:

[https://github.com/ninenines/cowboy/blob/master/src/cowboy_p...](https://github.com/ninenines/cowboy/blob/master/src/cowboy_protocol.erl#L177)

I'm guessing around here would be interesting to add a test case to handle.

As far as whose server this is? I'd guess Heroku or AWS, though it's plenty possible T-Mobile could have devised some proxy to inspect traffic, but seems unlikely they would do so with Cowboy?

<comment><USER12> It's simple enough to single out Heroku:

      $ cat <<EOF | nc example.herokuapp.com 80
      GET /test  HTTP/1.1

      EOF
      ----
      HTTP/1.1 505 HTTP Version Not Supported

<comment><USER13> Your example fails with or without the whitespace. These work though:

Request

      printf 'GET / HTTP/1.1\r\nHost: example.herokuapp.com\r\n\r\n' |  nc example.herokuapp.com 80

Response

      HTTP/1.1 200 OK
      Connection: keep-alive
      Server: SimpleHTTP/0.6 Python/2.7.6

Request

      printf 'GET /  HTTP/1.1\r\nHost: example.herokuapp.com\r\n\r\n' |  nc example.herokuapp.com 80

Response

      HTTP/1.1 505 HTTP Version Not Supported
      Connection: close
      Server: Cowboy

<comment><USER12> Ah right, forgot about the newline specification. I guess, for reference, the smallest string I can come up with to get Cowboy to spit that error message is '\x20\x20\n'. Parsers are fun.

</comment></comment></comment></comment><comment><USER14>
          strcpy( ( char * ) commsOrderBuffer, "GET /v1/printer/");

          strcat( ( char * ) commsOrderBuffer, ( char * ) settings.getIMEI());
          strcat( ( char * ) commsOrderBuffer, "/orders.txt  HTTP/1.1\r\n");
          strcat( ( char * ) commsOrderBuffer, "HOST: ");
          strcat( ( char * ) commsOrderBuffer, SERVER_NAME);
          strcat( ( char * ) commsOrderBuffer, "\r\n");
          strcat( ( char * ) commsOrderBuffer, "Authorization: Basic ");

What the.... O(n) string concatenations, unnecessary pointer casts, no bounds checking... I think extra whitespace in an HTTP request is not their only problem.

<comment><USER15> Those would be "safe" (assuming that settings.getIMEI() is completely under your control, everything else is string literals) but yeah snprintf seems way better here (though it's been well over 20 years since I wrote any significant C code.

<comment><USER14> Possibly safe but definitely inefficient, since it has to find the end of the string to know where the destination pointer starts. The right way is to keep a pointer to the end.

(Or since they are already using std::string in other places, maybe just do that everywhere, I'm sure it makes better choices than they did here.)

The pointer cast thing is glaring. Why not simply declare the buffer as a char array and be done with it, instead of casting at every use? IMO over-use of pointer casts is a clear sign someone is lost in the language, your goal should be to reduce them.

<comment><USER15> Yeah agree, to me casts like that are a smell that someone is trying to squash compiler complaints rather than understanding them. It also has every appearance of "copy/paste" code writing.

</comment></comment></comment></comment><comment><USER16> I saw it right away - "that HTTP/1.1 looks a bit farther away than it should be..." \- and confirmed it by selecting the spaces. I thought it would be a bit more subtle than that... I remember working with a server that violated the HTTP spec by not accepting allowed extra spaces in headers.

According to the new HTTP/1.1 RFC 7230, it should be a single space - <USER2> previous RFC didn't specify this clearly in the wording, although it is implied by the grammar (SP and not 1 * SP).

[https://tools.ietf.org/html/rfc7230#section-3.1.1](https://tools.ietf.org/html/rfc7230#section-3.1.1)

"A request-line begins with a method token, followed by a _single_ space (SP), the request-target, another _single_ space (SP), the protocol version, and ends with CRLF."

I'm surprised there doesn't seem to be any widely-used and easily available HTTP conformance checker - unlike the well-known HTML validators.

This is also why monospace fonts are ideal for seeing small but significant differences like this.

<comment><USER17> That's an interesting idea. It would be useful to have a Web server where the output is just a conformance check of the request. That might be a fun project for a rainy day :)

<comment><USER18> Sounds like something that could be added to [http://httpbin.org](http://httpbin.org)

<comment><USER16> That runs on Python/Flask, which is already a layer of abstraction above where HTTP conformance testing would be; what you need is something that listens on a TCP socket and parses the requests itself.

<comment><USER18> Actually, thinking about it, didn't Zed Shaw make a Ragel-based strict- conformance HTTP parser?

> Simply being more explicit about what is valid HTTP means that most of the > security attacks that worked on Apache were rejected outright when tried on > Mongrel.

Which I guess is a qualified "sounds like it, maybe?"

</comment></comment></comment></comment></comment><comment><USER19> This proves a very important pet peeve of mine: Your modern application has a highly dynamic operating point. There is no way you can deploy a system and expect it to be static for eternity. Back in the day with low interconnectivity you could. But today it is impossible.

When you build stacks on top of system for which you have no direct control, you must be able to adapt your system. This means you can't statically deploy code without an upgrade path in one way or the other.

<comment><AUTHOR> True but that doesn't bother me. Nothing is static on the web these days and everyone plays under the same rule set. Keeps things interesting...

<comment><USER19> It shouldn't bother you. It is just how moderns systems _are_.

</comment></comment></comment><comment><USER20> Cowboy is quite a well respected we server of the Erlang flavor. I'd guess heroku rejiggered something in their stack, perhaps adding cowboy as a reverse proxy or load balancer in front of their junk.

Cowboy apparently shot yor no-good dirty sidewinding web requests in the face.

<comment><USER21> It is well known that you can't (should not) rely on _bugs_ (or _internal APIs_ )

</comment></comment><comment><USER22> It's technically correct, according to the HTTP spec there must be a single "SP" character between the elements in the Request-Line:

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

Source: [http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1](http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1)

</comment><comment><USER23> Another broken network device which takes it upon itself to mess with TCP connections passing through.

I ran into this a few years ago with Coyote Point load balancers. It turns out that if you send HTTP headers to a Coyote Point load balancer, and the last header field is "User-agent", and that field ends with "m" but does not otherwise contain "m", the connection does not go through the load balancer.

Complaining to Coyote Point produced typical clueless responses such as "Upgrade your software". (The problem wasn't at my end, but at sites with Coyote Point devices. Fortunately, I knew someone who had a Coyote Point unit, and we were able to force the situation there.) I had our system ("Sitetruth.com site rating system", note the "m") put an unnecessary "Accept" header field at the end of the header to work around the problem.

Coyote Point's filtering software is regular-expression based, and I suspect that somewhere, there is a rule with a "\m" instead of "\n".

A current issue: there are some sites where, if you make three HTTP requests for the same URL from the same IP address in a short period, further requests are ignored for about 15 seconds. You can make this happen with three "wget" requests. Try "wget [http://bitcointalk.org"](http://bitcointalk.org") three times in quick succession. Amusingly, this limiter only applies for HTTP sessions, not HTTPS.

</comment><comment><USER24> That series of strcat's caught my eye as bad practice. Fine in this case since the destination string is short but horrible in general. Every single one of those calls needs to iterate over the entire existing string to find the string size. The code could be much cleaner with a small macro hiding the incrementation and the casts.

<comment><USER25> A sufficiently smart compiler could optimize a string of strcat calls to remove the redundant length finding. I have no idea if real compilers actually would....

<comment><USER26> Java does, for the "+" operator.

<comment><USER25> Oh yes, nice example! So there's precedent for C compilers doing something similar.

</comment></comment></comment></comment><comment><USER27> What's the deal with all the scrollbars on this page?

<comment><USER28> Yeah, why is every image, heading, and paragraph on that page surrounded by scrollbars where most don't work and are not necessary?

<comment><AUTHOR> What browser are you using? I'm not seeing that here on my devices...? We are using pretty vanilla Bootstrap.

<comment><USER29> [http://i.imgur.com/v0b1LKC.png](http://i.imgur.com/v0b1LKC.png)

This is what I see in Chrome on OSX.

</comment></comment></comment></comment><comment><USER30> It scares me to think all of these requests run over unencrypted HTTP.

<comment><USER31> Why? it's just pizza

<comment><USER32> Pizza has been used as a tool of harassment in the past. People order lots of pizza from different places for the victim, who then has to deal with a bunch of angry pizza drivers and being black-listed from those pizza places.

Pizza drivers are often the victims of crime. Not only for the small amounts of cash that they carry, but sometimes just for the pizzas.

edit: I should say that my comment here was a kneejerk reaction to "it's just pizza", and has nothing to do with how eatabit.com deals with this kind of harassment. i agree with other commenters that blog posts like these are a great way to promote the company.

<comment><USER33> How are you going to exploit the fact that these pizza orders aren't encrypted to achieve either of those things?

<comment><USER34> that's the wrong question to ask.

We're not (all) in the "think-of-things-to-do-with-stolen-information" business like so many others are; but many of us _are_ we're in the "encrypt- all-the-things-so-that-information-isn't-stolen" business.

</comment></comment></comment></comment></comment><comment><USER35> Kudos for sorting this out quickly. Problems like this one can be really difficult to debug.

I remember one case where the coefficient table for a polyphase FIR filter we implemented in an FPGA caused huge instability problems in a design. The coefficient table, if I remember correctly, was 32 wide (32 multipliers) and 128 phases long. That's 4096 numbers. The design had about 40 of these tables that would be loaded from firmware into FPGA registers in real time as needed. We built a tool in Excel to be able to compute these tables of FIR coefficients.

We got word from a customer that things were not behaving correctly under certain circumstances. We were able to reproduce the problem in the lab but could not find anything wrong with the FPGA, microcontroller or Excel code after about three weeks of work by three engineers. This quickly became a nightmare as it threatened several lucrative contracts and failed to service our existing customer base adequately.

I had to put our other two hardware engineers back to work on their existing projects so I took on the debugging process. This was the most intense debugging I've had to do in thirty years of software and hardware development. Lots at stake. The very reputation and financial well being of my business was at stake. Enter 18 hour days, 7 days a week.

FOUR MONTHS LATER, at 2:00 AM on a fine Sunday morning without having slept for three days looking at code the bug jumped out at me. We've all had that moment but his one was well "one of those". The problem? We used "ROUND()" in instead of "ROUNDUP()" in calculation that had nothing to do with the FIR filter coefficients but rather affected the programming of counters related to them. This caused timing errors in a state machine that drove the FIR filters. If this were software this would be exactly like having the wrong count in a loop counter. Yup.

I re-calculated after making the change and everything worked as advertised. That was the best Monday I've had in years. And I took a long vacation after that.

Over four months to find a bug.

That's why sometimes it is impossible and even unreasonable to create budgets for software development. One little bug can set you back weeks, if not months.

</comment><comment><USER36> Way to abuse :first-letter.

</comment><comment><USER37> Assuming the problem originates from something relating to eatabit's infrastructure, the important takeway (for me) would be: Depend as little on 3rd parties as possible.

I know this is not a popular opinion among the HN crowd, mainly due to the entire web's love of linking to some other site's js/css to offload cost from their own site. But this makes no sense; you're not really reducing costs, you're just delaying them.

People talk about how 3rd parties speed up development or (potentially) reduce costs. But if the success of your business depends on providing a service all the time that has to be reliable, the reliability of your product is directly proportional to the reliability of the 3rd party. And each 3rd party adds additional points of failure. If you don't control whatever service or product the 3rd party is giving you, you will be unable to even attempt to isolate and fix it yourself.

Typically the answer to this problem is 'buy a better service contract'. But if the 3rd party doesn't provide 24/7 365 support along with multiple contact methods and harsh penalties for failing to supply you with timely service, you're wasting your money. You don't want to be the guy who has to tell the CIO "Sorry, I can't get a hold of our service provider or they aren't giving me timely updates, so I do not know when our product will be up again."

<comment><USER38> > Depend as little on 3rd parties as possible.

This attitude has many a startup reinventing and supporting commodity infrastructure instead of focusing on developing unique products and value for their customers.

</comment></comment><comment><USER39> When learning OCaml, I decided to write a little web client that would bruit force the password on my own home router. I wrote a client, and my router wasn't responding, so I tried having my client fetch pages from Yahoo, and it worked fine.

I fired up wireshark and saw that everything looked fine... except that all of my line terminators were shift-in-formfeed instead of carriage-return-newline. It turns out that OCaml uses decimal character escapes instead of octal. (This was back when I was under the impression that portable code avoided use of \n in string literals because someone who misunderstood text mode file handles had told me that Microsoft compilers expanded \n to \015\012.)

Apparently someone at Yahoo had experienced enough terribly terribly written web clients that they wrote their HTTP server to accept any two non-space whitespace characters as a line ending.

</comment><comment><USER40> "our cellular printing api has printed over 9300 food orders for our client restaurants, stadiums and golf courses"

Am I the only one who read this as a system using 3D printing to print food? Disappointed to discover it's not that kind of cellular.

</comment><comment><USER41> Tangentially, why didn't curl escape the trailing space to %20?

</comment><comment><USER42> I experienced a similar problem with a POP3 utility that I had written years ago. I had been appending an extra space to the end of each text line (before the CRLF ).

There were a few people using this utility with no problems until one day a particular POP3 server no longer tolerated my utility's malformed requests.

</comment><comment><USER43> I have some advice. Hire a real C programmer. This code is _awful_ and probably full of vulns.

</comment><comment><USER44> I've had the same issues when developing with Flask in Python. I forgot to URL encode some query parameters and it worked fine with the local HTTP server.

But when I put nginx in front as a proxy, it denied all requests.

<comment><USER45> The thttpd webserver doesn't handle requests with too many slashes either, which I only found out recently

This is treated as an invalid request:

          http://example.com//robots.txt

<comment><USER18> Unless I'm reading RFC 3986 incorrectly, that's valid because you can't have an empty segment in the path part of a URI.

<comment><USER46> I think you're reading it incorrectly.

You can have an empty segment in the path. The BNF for a segment is:

        segment       = *pchar

Which according to RFC2234 section 3.6 means zero or more repetitions.

<comment><USER47> But then the server may still decide that an empty segment is so meaningless that it will refuse it.

In fact, it would not be a smart move to just treat double slashes the same as single ones, because of relative URLs: a ".." segment only removes one slash, so the hierarchy levels would get messed up. thttpd is doing the smart thing here.

As one of my teachers at university would say: the empty segment is also a segment.

<comment><USER48> The server can of course interpret the path as it wants, but it should allow an application running under the server to give 'foo//bar' a meaning if that application wants to, IMO.

<comment><USER47> True. I was writing about the case when the URL simply mapped to a file system location. Applications should be able to apply their own interpretation.

</comment></comment></comment></comment></comment></comment></comment><comment><USER49> Slightly off-topic, but this is why dev posts like this are important. I didn't know eatabit.com was a thing, it it sounds like a great service.

<comment><USER50> Dev #2 here thanks for the compliment. Where are you? Maybe we should expand to your area. :)

<comment><USER49> Buffalo, NY. We're quite proud of our local restaurant industry. So, yes, you should!

</comment></comment></comment><comment><USER51> If this were my team, I would be unsettled by the fact that we never caught it in testing. Did no one write tests to exercise this part of the app - the one where we're handcrafting HTTP requests?

Objectively, you need to write more tests. At the minimum, _this_ bug should have a regression test so that it can never accidentally happen again (say when a dev merges an old branch in for whatever reason).

<comment><USER52> What test would you have written to catch this? One that checks the exact contents of headers passed along? It's possibly they even _had_ tests around this, but were expecting the same output that they were inputting (copy+pasta). Perhaps they had a more "integration"-ee test that actually hit the web with that bad header. At the point they wrote it, that test would have been passing. It wasn't until the parsing server changed (to Coyote, it seems) that the test would have started to fail.

<comment><USER51> Yes, I would have written a test to confirm that input_a generates output_b. The first half of that function is nothing but a string builder and easily testable. If they were copy-and-pasting the actual output to get the expected output, then yes: they screwed that part up.

I'm far from a TDD purist, but it's clearly true that they're not sufficiently validating their code. If they had been, this would not have happened. I'm not saying this as an attack on their skills as programmers, but as caution to others reading the story: you have to - _have to_ \- test your stuff.

It's one thing to lean on third-party libraries and expect them to mostly Do The Right Thing, especially if they're popular and come from a culture of valuing test coverage. If you're writing a Rails app, for instance, you might be forgiven for not writing your own independent validations of the Ruby methods you call. But writing string-building code to implement RFC-defined network protocols? You should have some confidence that your program is generating the output that the other party will be expected. _Especially_ with something as commonly proxied as unencrypted HTTP; you just have to assume that your data will be traversing and analyzed by systems 100% outside of your control.

<comment><USER52> At first I was thinking that suggesting that you exactly check the output of a request might be a bit much, especially since it could be entirely variable and cause your tests to break at any point during refactoring. If that was done by a third party framework, as you point out, you might not get a whole lot of value from testing its output. However, if you're constructing your own HTTP requests, as seem to be, then yeah, you probably need to explicitly check that it is being built up correctly. Or, since this appears to be a single build up, and not common/shared functionality, it could probably be abstracted into a common function/utility that does it for you. That should be easily unit-testable. Fair enough.

</comment></comment></comment></comment><comment><USER53> Are there any languages out there that handle scale and many connections like Erlang does, but with an easier to swallow syntax?

<comment><USER54> Erlang. The syntax really isn't that bad, once you get over the initial shock. In all honesty, grasping that the variables are immutable and how you need to change your thinking is much more difficult than the syntax itself.

</comment></comment><comment><USER55> q

</comment><comment><USER56> i'm just glad my city made it to HN.

<comment><AUTHOR> Charleston represent!</comment></comment>


Nullsoft: The death of the last maverick tech company (2004) - <AUTHOR> http://www.slate.com/articles/technology/webhead/2004/11/nullsoft_19972004.html <comment><USER3> Despite the "change the world.. break the rules, etc." rhetoric, Silicon Valley couldn't be more different today.

I find it hard to imagine a Google employee releasing an ad blocker[0], or Popcorn Time raising a Series A round, or startups shipping crypto that breaks the law, or a startup selling offensive security software (there's a reason that business has been pushed overseas)

Today, startups that push the boundaries on bad laws and regulations are more likely to be roundly criticized than praised.

DMCA notices are automatically complied with without question via automated systems. The tech companies have _become_ the media companies. Founders in file sharing or media make a point in investment pitches that they'll be conformist. YouTube's ContentID system means thousands of legal satire and parody videos are removed every day.

Not to mention _whatever_ is/was happening between SV and the intelligence agencies.

It's pretty hard today to find projects or communities that have similar levels of energy and disregard for rules. When you do find them it's no coincidence that they're usually on the periphery of what SV touches.

[0] Brian Kennish quit Google and released Disconnect, a privacy plugin for browsers.

<comment><USER4> I often read stuff like that. "Now you couldn't do it like they did it before".

"You wouldn't be able to get away with the same jokes today."

Or

"You wouldn't be able to publish the same story today."

I agree that time changes, but this is discarding the merits of those who did it then.

Believe it or not, at that time it was not easy either. The people that did it had huge balls.

Geeks were considered less that nothing by society. The working world didn't trust them, believe in them or value them. They were basically rejected, as something annoying you had to have somewhere in your closet. My father actually told me in 2003 that he was disappointed I choose to work in such a boring field.

Technology didn't exist. You couldn't google your way out of anything like today (now if you google, SO answer everything!). Networks and computer where slow and expensive (we now got unmetered VPS for 3€/month, come on!). Less libraries, less frameworks, no crazy powerful API (can you believe making uber before google map ?) and no proof whatsoever that what you wanted to do was achievable.

The market was unproven (the 2000 bubble killed so much). We had no experience in it. Not tools to recruit, sell, build...

It's was not easier to do anything. The constraints were just different.

The constraints of tomorrow will be also different.

Let's not use the change as an excuse.

Doing something that matters is ALWAYS HARD.

<comment><USER5> "Geeks were considered less that nothing by society. The working world didn't trust them, believe in them or value them. They were basically rejected, as something annoying you had to have somewhere in your closet. My father actually told me in 2003 that he was disappointed I choose to work in such a boring field."

Exaggerating a bit? By a bit I mean a lot? I know that some geeks had hard childhood and were bullied, but way more others were not. Plenty of fathers were disappointed over children choosing various professions.

The way you people talk about it makes it sound as if all people who ever went into tech were bullied outcasts and that is simply not true.

<comment><USER4> I'm not exaggerating by one bit.

At best you had an "ok" situation. Nothing like the "rock star" attitude you get today.

Not only geeks where the less popular in school, but the media mocked them. And this snowballed into the workplace where the only people threated like the IT department was the accounting one.

The pay was not nearly in the same area. Nobody would consider buying a dual screen for their IT dev a minimum requirement.

I can recall people dreading to call the sysadmin to deal with anything. Talking to them was considered a chore.

The best way to defend this is that before the ipod existed, noone would ever say "I'm such a geek". Today somebody playing too much on iphone would say that. We call girls with cute glasses "geeks".

<comment><USER5> "At best you had an "ok" situation. Nothing like the "rock star" attitude you get today."

Not being rock star is not an oppression. The ok treatment is what majority of people have. I mean, not being treated as something super special is not "considered less that nothing by society". It is being considered normal.

"And this snowballed into the workplace where the only people threated like the IT department was the accounting one."

There is nothing wrong with the accounting department. In pretty much all workplaces I have been at, they have been treated with respect. In any case, if that workplace treated accountants badly too, the workplace was shitty for more then one group.

"I can recall people dreading to call the sysadmin to deal with anything. Talking to them was considered a chore."

I have seen such behavior towards admin, but then again I did not liked talking with that particular admin either. I dont doubt that there were groups of great admins that were not treated fairly despite acting all polite and all that. Bad workplaces happen.

However, admin I considered chore to talk with was condescending too often and it was hard to get what I needed from him. He was good in tech, but talking with him was a chore.

"The best way to defend this is that before the ipod existed, noone would ever say "I'm such a geek"."

Yeah, I find everybody is a geek culture annoying too.

"We call girls with cute glasses "geeks"."

Guys with pretty much zero technical skills used to be called geeks just for liking a tv show or play videogame.

<comment><USER6> Regarding the IT department thing:

From my first job to my current one, I always made sure I was in good stead with the IT department (whatever its size) - it was where I could get cast-off hardware for my computer junk pile!

</comment></comment></comment></comment></comment></comment><comment><USER7> For what it's worth, Justin Frankel continues to produce great software. He founded Cockos Incorporated, which produces REAPER; I think it's pretty widely accepted in the audio recording community that REAPER is the best value in the multitrack recording DAW market, and among the best overall tools for the purpose.

He's obviously wealthy enough to never need to work again. It's clear Frankel just loves music, and wants to make meaningful contributions in the field. So, I think that's pretty cool. (I've also been a very happy REAPER user/customer for many years.)

<comment><USER8> He was a regular in #c on IRC back in the 90s. Pleasant, fun guy. I kind of miss those days.

<comment><USER9> He used to come on #winprog - I think Winamp was his first windows app, he was always asking about GUI elements how he was planning on making it skinnable. Everyone was trading mp3's and I couldn't figure out why you would want to spend 15 minutes downloading a song...

</comment></comment></comment><comment><USER10> I don't know if this is how Winamp was meant to be used (I suspect it wasn't) but its default behaviour from its launch - with all of your music in a big giant list which you could muddle around, and a randomize play-order button - almost invited me to explore music in a way that I haven't seen since. It seems like ever since then the UIs try their best to force you to dig down into a specific album. If a track's id3 tags are incorrect then they're effectively lost in that UI because you don't know where to look for them.

Yeah you can randomize play in iTunes or Zune, but you have to make arbitrary playlists explicitly. You can drag tracks around in VLC but the UI isn't helpful.

I would say I knew 90% of the songs in my music collection then and probably know 10% now despite it being about the same size, purely because of a few 'helpful' UI constraints.

People sort of suggest that music changed when MP3s and Napster bloomed, but the 'end of an era' in my mind, the time when my experience of music definitely changed, is when I was obligated to stop using Winamp and start using iTunes etc in the mid 2000s.

<comment><USER11> What a glorious time it was with that master playlist and the excellent keyboard shortcuts. I used to put it on shuffle and play a game where I'd press Next and then Pause immediately and try to impress friends by knowing what song it was within the first half-second.

You could also just conjure up any song with the "J" keyboard shortcut that would search the entire path as well as the ID3 tags. It was so good that one weekend night in high-school, my friend and I decided to put an old desktop in the back of my Jeep on foam and power it with an inverter. We ran aux wires to the stereo and I literally just had a full-on keyboard that I could pull up while driving and get any song in my library with a few slaps of one hand without looking down even once (I knew one-handed typing skills would be useful someday). (I even tried voice command with Dragon Naturally Speaking but it only worked when the engine was off.) To this day, I haven't had such an agile interface to my music. I just use a phone now but it has a fraction of my old library and searching for things while driving is dangerous, illegal, slow, and miserable.

<comment><USER10> Ha wow, now that's dedication.

At least now your car can have bluetooth and Siri integration...which lets you play music from Spotify...when you have reception...or tracks from your $500 16gb iPhone which can store a few albums...ugh.

You could probably re-make that project pretty handy these days, with Raspberry Pi's and hard-drives being cheap and so on

<comment><USER12> If you reencode to lower bitrates you can likely store just as much on the iPhone as you did in the winamp days; when I was using winamp, I bought the largest drive I could afford for video encoding; it was 6GB.

<comment><USER10> Good point. 128kbps was more than enough for me in those days. 160 was hedonistic.

<comment><USER12> Half my original MP3 collection was 96kbps 128kbps was "high quality".

</comment></comment></comment></comment></comment></comment><comment><USER13> NSIS (created also by Nullsoft) was particularly awesome, made it a breeze to build a Windows installer. There was also a photo gallery script Justin created which I thought was ahead of its time back then.

<comment><USER14> It's still alive — latest release December 11, 2016!

Two years ago I worked on an Electron-based app for Windows. I tested* it right on my dev machine in Electron for Linux _and_ the whole build process, including the NSIS-based installed also ran on Linux via makensis utility, so I didn't even have to touch Windows until the final QA phase. This was very nice.

<comment><USER15> NSIS is more than alive for Electron apps -- it's about to become the default windows installer in electron-builder! Squirrel.windows will be deprecated soon.

</comment></comment></comment><comment><USER16>
      What kind of snot-nosed brat takes millions from AOL and
      then publishes software perfect for ripping off Time
      Warner's entire catalog? Frankel, a grunge-dressing slacker
      from Sedona, Ariz., was a teenage college dropout in 1997
      when he wrote Winamp, the first program that made playing
      MP3s on a PC point-and-click simple.

How times have changed. There's now so many snot-nosed grungy slackers who could buy the author's house in cash, just to make a point :-)

<comment><USER17> While it's certainly true that there are many more 20-somethings/30-somethings with lots of money in tech these days, I think the attitude he had is pretty rare.

Most people wouldn't dare to release software that might get them fired because they just wanted to make it, and thought it should exist. Of course, it's well within the rights of a company to fire an employee for doing so, but pretty sure most tech workers these days just stay in line, relegate open source work to when they're told they can do it (nights and weekends), and gnash teeth but ultimately submit when a company shoves something they don't like down their throat.

Then again, he did have "fuck you" money after the acquisition so...

</comment></comment><comment><USER18> There's a really excellent long piece in Ars from 2012 about Nullsoft/Winamp that has the advantage of nearly a decade more perspective: [https://arstechnica.com/business/2012/06/winamp-how- greatest...](https://arstechnica.com/business/2012/06/winamp-how-greatest- mp3-player-undid-itself/)

The following year, AOL officially killed the Winamp product.

<comment><USER19> WinAmp is back. [http://www.winamp.com/](http://www.winamp.com/)

<comment><USER20> It's been 'back' since... around 2013?

<comment><USER21> It's "back" as much as a zombie is "back". Yeah it works on the latest OS, but several features are broken.

Shoutcast still working is a little miracle. Though I am quite pleased with the Podcast Downloading feature w/ RSS. ( for example you can pull stuff from soundcloud )

</comment></comment></comment></comment><comment><USER22> Small guide on How to use WASTE -> [http://www.cs.montana.edu/~huff/waste/howto/Waste.html](http://www.cs.montana.edu/~huff/waste/howto/Waste.html)

<comment><USER23> I was just thinking about WASTE recently in the last 2 weeks since Trump took office.

WASTE was written in Java and was sort of tricky to setup / understand. At one point about 10 years ago, I had a small 8 person "dark net" running with WASTE, shit was so 1337 for its time.

Bit torrent was just making waves around this time and made downloading WAY faster, but was more risky then sharing directly over WASTE.

<comment><USER22> WASTE was written on entire C++, you can find sources here [http://slackerbitch.free.fr/waste/download.html](http://slackerbitch.free.fr/waste/download.html) or somewhere here [https://sourceforge.net/projects/waste/](https://sourceforge.net/projects/waste/)

<comment><USER23> Hmmm, maybe I found an "open source" client that was written in Java then. I remember having to mess with JAR files.

</comment></comment></comment></comment><comment><USER24> I still use winamp as my mp3 player, one of the first things I install when I reinstall my Windows. It's everything that I need without the BS.

<comment><USER25> I'm also a fan of Foobar2000: not as pretty, but surpremely small and functional :)

<comment><USER26> There's no accounting for taste. I found Winamp gaudy, and actually preferred Foobar. The black theme was quite nice once the font colour was changed to off-white.

I cannot recommend Foobar enough, the tools for fixing up dodgy mp3s are very useful. It isn't so hot with mp4 tags though.

<comment><USER27> _It isn 't so hot with mp4 tags though._

What do you mean exactly? mp4 tags in all variations, including various iTunes oddities, are fully supported.

<comment><USER26> Way back in 2009/2010, I remember there being some issues. But that's coincidentally when I switched to a Mac, and started doing all my tagging in iTunes instead. Come to think of it, it's likely they've fixed it by now. I have used foobar since, but mainly for playback.

</comment></comment></comment></comment></comment><comment><USER28> For me I stopped using Winamp when I went full OSX and iPod. There was no reason to use anything else. Now, I hate iTunes but it is not easy to change. Right now I only use it for managing the library as a source of truth. The files are on a network share and played in Kodi on the compute stick plugged into the TV thought an external DAC to a tube amp. ;)

</comment><comment><USER29> Man I would kill for an ultra-simple, ultra-lightweight, robust music player for macOS that was just like Winamp 2.81, the last good version. No, not foobar.

<comment><USER30> "Ultra-lightweight" can mean two very different (and nearly opposite) things: some people want a player that has _no external dependencies_ (and thus must do everything itself, like VLC); while others want a player with _minimal binary size_ (which thus will then rely on the OS's AV frameworks as much as possible for media support.)

Personally, I prefer the second definition, but it's the harder of the two to satisfy. I don't really understand why the approach Perian undertook was abandoned when Perian itself was. It'd be very nice to just have macOS "natively" support every media format+codec under the sun, and then just play media files in Quicktime or iTunes or any other player GUI you prefer.

<comment><USER31> VLC is great, but UI sux tbh. Also, SMplayer is great, but UI sux even more for audio.

The level of 'it just works' for those 2 products is just not comparable to anything else. Plus they are cross platform, works on pretty much anything in existence.

That is the reason I tollerate UI and use them every day. Also, while it lacks audio management, SMPlayer is the best video player, period.

<comment><USER32> VLC's UI sucks so terribly, it's like they went WAY out of their way to make it sucks on purpose, and stubbornly refuse to acknowledge that there are any problems or ever consider fixing them.

One example of many [1]:

Type CMD-E (on Mac, or whatever the equivalent is on Windows) to get the video effects window.

Select "Geometry". Now check "Magnification/Zoom".

Notice how you get a picture-in-picture in the upper left corner, with a white rectangle showing the zoomed area, that you can move around by clicking. But if you press and hold, it also drags the entire windows (on a Mac -- I haven't tried on Windows -- VLC's UI and behavior on Mac and Windows diverges widely so I won't try to predict what happens).

Now look underneath the picture-in-picture and notices some ugly upper case pixelated text that says "VLC ZOOM HIDE". See how it's jaggy and rendered at the resolution of the movie you're playing itself, not at screen in a full resolution overlay with readable text?

Now look at the triangle with a jaggy curved hypotenuse below the jaggy words. That is the zoom "slider" (which also drags the window when you drag the mouse, so it's more like a clicker than a slider). See how it gets narrower and narrower in a succession of jaggy stair-step chunks, until it's merely one jaggy pixel wide? Well guess what: the TARGET AREA also gets narrow to match the width of the slider, so it's almost impossible to click on the bottom of the slider, to select the larger zoom sizes! Since the zoom slider is not very tall and its pixels fat and jaggy, you don't have fine grained access to very many zoom sizes at all, either. The zoom pixel steps are much bigger than screen pixels, depending on the video resolution!

What possible purpose could that serve? Why would any user guess that the lower narrow part of the slider represents a wider zoom showing a bigger rectangle over the picture-in-picture, while the top wider part of the slider represents a tighter zoom showing a smaller rectangle over the picture-in- picture? And what slider have you ever used that gets narrower from top to bottom, with a jaggy curve, and an impossibly narrow hard to click target area at the bottom?

This single facet of VLC's terrible UI deserves to be front and center in the User Interface Hall of Shame [2] -- it's even worse than Apple's infamous schizophrenically skeuomorphic QuickTime 4.0 player [3], from 1999! The latest version of VLC in 2017 is still much worse than the shameful QuickTime player was 18 years ago!

Who could have possibly gone so far out of their way to design and implement such a terrible user interface on purpose, then smugly brushed off and ignored 16 years of bug reports and cries for help on the VLC message boards, without harboring a malicious contempt for their users?

That's not even the worst of it. Now check "Transform" and pick one of the transforms like "Rotate by 90 degrees". Guess what? The magnification interface itself is rotated 90 degrees, because it's drawn on the video before it's rotated, so now it appears at the top right of the screen, rotated 90 degrees itself.

And guess what else? The mouse clicks are not even transformed properly, so clicking on the magnification interfaces does NOTHING, rendering it completely useless! Depending on the aspect ratio of the video, you can't even click in the upper left corner where it USED to be and SHOULD still be to operate it, because it is clipped off the right edge of the window.

Are those ugly cosmetic and impossible usability problems not bad enough for you? Then make a playlist with one item. Select "Repeat" mode. Play the movie. Now go to the finder and remove, rename or move the movie you're playing, or just unplug the USB stick containing the video. Not an uncommon occurrence, right? Now VLC will hang up, consuming 100% of the CPU time, often times seizing up the entire Mac, turning on the fan, locking out all user input, and forcing you to reboot! This happens to me all the time.

These bugs have been around for years. The more you fiddle around with it, testing out the edge cases and trying to combine various poorly designed and implemented features, the more bugs you find.

File a bug report, they say. People report these problems again and again. The developers just ignore them and brush them off. I've tried reporting these and other bugs, describing them in meticulous detail, which is frustrating because once I start writing step-by-step instructions to reproduce one problem, I keep finding more and more problems, each worse than the last, and then they just brush me off and ignore my bug reports too.

VLC's user interface is maliciously terrible in so many ways, the developers are careless and arrogant towards their users, and there's no hope of the developers ever changing their ways, acknowledging the problems, and improving it. Instead of improving usability for everyone, they're more interested in adding yet another obscure anime decoder feature so they can watch their AMV cartoon porn [4] [5].

[1] [http://imgur.com/gallery/g0acV](http://imgur.com/gallery/g0acV)

[2] [http://hallofshame.gp.co.at/index.php](http://hallofshame.gp.co.at/index.php)

[3] [http://hallofshame.gp.co.at/qtime.htm](http://hallofshame.gp.co.at/qtime.htm)

[4] [https://www.videolan.org/vlc/releases/2.1.5.html](https://www.videolan.org/vlc/releases/2.1.5.html)

FOR ANIME FANS

New 6.1 downmixer to 5.1 and Stereo from MKV/Flac 6.1. Correct YUV->RGB color matrix in the OpenGL shaders. Improved MKV support for seeking, and resiliancy. Editions support in MKV. Better subtitles and metadata support from MKV. Various ASS subtitles improvements.

[5] [https://myanimelist.net/forum/?topicid=208770](https://myanimelist.net/forum/?topicid=208770)

Now, if you are an AMV (Anime Music Video) creator and want to edit the video directly, the MKV is your best friend since it's a lossless video-content container due to the fact that you will find yourself adding effects to the video frames/audio. In this case you will want to lose as little as possible in your video, so MKV compression best suits.

TOPIC ANSWER: The reason why MKV is popular for anime is because of it's noted lossless compression. Anime show creators most likely notice this fact and use it to contain their video frames and audio tracks for maximum quality. - <USER2> has nothing to do with HD.

<comment><USER30> > Instead of improving usability for everyone, they're more interested in > adding yet another obscure anime decoder feature so they can watch their AMV > cartoon porn

Mind you, FOSS is contributed to by people scratching their own itch. It's not so much that VLC has a lot of otaku developers; it's that a lot of people who watch (or subtitle) "AMV cartoon porn" see a problem with, or missing feature in, VLC, and think "I'm a programmer; I can fix that", and dash off one-off patches.

<comment><USER31> Its very hard to contribute patch to foss tool in general. There is no substitution for agile development team.

<comment><USER32> Oh I certainly wanted to contribute to the VLC project and integrate it into my own projects, but after having my concerns that I wrote up in great detail flippantly dismissed with such contempt, and seeing how the exact same thing happened to other users reporting legitimate longstanding bugs who were brushed off and ignored over so many years, I had no interest in contributing after that. It's fortunate that not every open source project suffers from such arrogant developers as VLC.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> The Nullsoft brand was sold to Radionomy in 2014. nullsoft.com now redirects to winamp.com, which astonishingly still exists.

<comment><USER33> I remember reading a few posts on the Winamp forums around a year ago that they were revitalizing development on Winamp, not sure if that went anywhere though.

<comment><USER34> I have a feeling it isn't.

I used to have winamp on my android phone and when I got a new phone a few months ago I discovered that they had removed winamp from the store. Which is unfortunate because winamp was surprisingly great on android too.

<comment><USER35> Their site[0] says that they're revitalizing it, and the last dev tweet I could find was from October 2016 [1]. So I'd bet it's going along at a reasonable pace.

[0][http://www.winamp.com/index.html](http://www.winamp.com/index.html)

[1][https://twitter.com/Ed_Rich/status/788650603383754752](https://twitter.com/Ed_Rich/status/788650603383754752)

<comment><USER36> It looks like he actually replied to somebody else very recently to say they're waiting on the legal department:

[https://twitter.com/ed_rich/status/817065613411713025](https://twitter.com/ed_rich/status/817065613411713025)

</comment></comment></comment></comment></comment><comment><USER37> I recently encountered an episode of the Internet History Podcast that featured a long interview with Frankel. It touches on many of the points in the Slate article (working relationship at AOL, end of Nullsoft, etc.), and was recorded in 2015. Might be a nice companion to the article for those looking for a little more insight: [http://www.internethistorypodcast.com/2015/07/justin- frankel...](http://www.internethistorypodcast.com/2015/07/justin-frankel- creator-of-winamp/)

</comment><comment><USER38> Easter egg at [http://www.winamp.com](http://www.winamp.com)

Click the llama's ass.

</comment><comment><USER39> Winamp was a great, music player back in my day that combined features with great, skinnable appearance and visualizations that could leave you in a trance. Plus it had a funnier opening than the competition at the time:

[https://www.youtube.com/watch?v=HaF- nRS_CWM](https://www.youtube.com/watch?v=HaF-nRS_CWM)

</comment><comment><USER40> Well NSIS (Nullsoft Scriptable Install System) is one thing that came out of Nullsoft which continues to be very widely used even today. Makes it child's play to write simple installers which are in mere KBs.

</comment><comment><USER41> > Conventional wisdom says Frankel is more likely to join the millionaire has- > beens who dot the hills in my San Francisco neighborhood or become a trophy > hire at a tech startup, like contemporaries Fanning, Marc Andreessen, and > Linus Torvalds.

Heh.

</comment><comment><USER42> Waste was released before my time...

Can anyone comment on what the scene was like when it was new?

</comment><comment><USER43> This is from 2004. What's new?

<comment><USER44> A whole generation of a potentially interested audience who was not yet aware of Nullsoft in 2004.

<comment><USER45> A generation who can't imagine the novelty of performing a first search on Napster or Direct Connect. Magic!

<comment><USER46> Audiogalaxy. Was always impressed how easy it was to find 320kbit versions or even some extremely rare songs...

<comment><USER47> Audiogalaxy was insanely effective at finding related music, due to, basically, human curation. I will always be grateful of having discovered lamb and goldfrapp through it.

<comment><USER48> Up-voted for dragging Lamb into an HN thread. ;)

Somehow appropriate for a decade old article about 90's vintage desktop MP3 software.

Now go and try to locate rips of episodes of AMP from MTV and complete your electronica collection.</comment></comment></comment></comment></comment></comment>


AT&T To Launch Yelp Competitor - <AUTHOR> http://www.forbes.com/2010/01/26/att-yelp-advertising-technology-business-intelligence-buzz.html?boxes=Homepagechannels

<comment><USER2> I'm sure given AT&T's laudable history of building huge-scale, world-class websites and their sterling reputation for dealing with customers in a human fashion this site will do excellently.

<comment><USER3> I agree with the fact that this is doomed to fail. AT&T does own Yellow Pages and they do have a head start in that regard. Wasn't there a story about Yelp being lousy for business owners on HN active list the last few days?

</comment></comment><comment><USER4> "AT&T came up with the idea for buzz.com about a year and a half ago, says David Krantz, president and chief executive of AT&T Interactive"

He says that so casually, like it was an original idea. And, he's not bothered by the fact that it took them a year and half to launch.

<comment><USER5> "And, he's not bothered by the fact that it took them a year and half to launch."

Well, considering how long it took Twitter to scale and stop falling over, I'd say taking a little while longer to launch is a good thing.

<comment><USER6> I don't understand this logic at all. Twitter has learned so much by launching as early as they did, and now it's a huge success. It's better to "scale and stop falling over" while you're improving your product and growing exponentially than spend a year and a half having meetings.

</comment></comment></comment><comment><USER7> buzz.com is a _really_ good domain name for something like this, but I can't think of a single instance where a Fortune 500 company tried to build a strong community and succeeded.

</comment><comment><USER8> The joke being, they screw over their customers instead of the businesses being reviewed...

</comment><comment><USER9> "The site, which is in an invitation-only "alpha" testing phase, is geared toward helping people ferret out the best local businesses using recommendations from friends and family."

Immediately brings to mind: <http://www.thumbtack.com/>

</comment><comment><USER10> <http://web.archive.org/web/20000520002726/http://buzz.com/>

</comment><comment><USER11> This has massive fail written all over it if they don't allow users to speak their mind.

If they would really give this a fair shot with their resources they could really make something of it. I'd love to give this a shot if they did this as a skunkworks project rather than their generally top down approach.

</comment><comment><USER2> Also, while I'm bitching...

<http://www.buzz.com/>

The logo looks like somebody took the bing font and merged it with the technorati icon, with a near-fatal dose of compression artifacts.

Sorry, AT&T is not my favourite company :-)

</comment><comment><USER12> How can I get an invitation?

</comment><comment><USER13> It seems to me AT&T is trying to be more like www.gigpark.com than Yelp. Gigapark was recently sold to Canpages.. the guys operate in Vancouver, BC.

</comment><comment><USER14> The only way this will be successful is if they manage to buzz.com for a lot, once they've given up.

</comment><comment><USER15> ... but will they let you review AT&T?</comment>


Donate your intellectual property in case of death - <AUTHOR> http://evan-roth.com/public_domain_donor.php

<comment><USER2> I don't really want to sign that. I'd need a way to make exceptions.

Let's say that I'm working on a startup that hasn't become a company yet with someone when I die. I'm not sure exactly how the IP legalities work, but I assume that he would be able to keep working on it, possibly under the condition that he give some of gains to my heirs.

But if my half of the IP enters into the public domain, my cofounder would lose his cofounder and at least have questions of whether much of the work we had done to that point had to be released.

Plus, I really don't want anyone to have incentive to kill me because they want that great book I wrote or that great piece of proprietary software that I developed and own to enter the public domain.

<comment><USER3> The "way to make exceptions" is to incorporate your startup and sign an IP agreement with it.

<comment><USER2> Yeah, but what if we haven't gotten there yet? What if it was a side-project that we now know will turn into a startup but hasn't gotten to the stage of incorporation?

I may not say, "Oh, yeah, 20 years ago I signed something putting all my IP in the public domain if I die. We should incorporate now just in case something happens to me." I may not remember, especially if I'm hacking 12 hrs/day on the startup.

</comment></comment></comment><comment><USER4> May I suggest you to change "IP" in the title to "Intellectual Property"? It is a nice initiative, but the title is a bit cryptic and may get ignored

<comment><USER5> I thought the article was going to be akin to "My Death Page", but that you have an permanent IP pointing towards web space for "hedge stone".

</comment></comment><comment><USER6> This is great idea but I'm not sure that this implementation is really going to work.

</comment><comment><USER7> Isn't this a bit meaningless unless we have some sort of repository?

</comment><comment><USER8> Donate your IP in case you're murdered.</comment>


Analysis of Raft Consensus [pdf] - <AUTHOR> http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-857.pdf

<comment><USER2> (Disclaimer: involved with the work linked.)

A short version of this tech report is due to appear in the January special issue on repeatable research of the Operating Systems review journal. A pre- print is available at [http://www.cl.cam.ac.uk/~ms705/pub/papers/2015-osr- raft.pdf](http://www.cl.cam.ac.uk/~ms705/pub/papers/2015-osr-raft.pdf) (10 pages).

<comment><AUTHOR> thanks for sharing!

</comment></comment><comment><USER3> I love this animation/website for anyone looking to get a great 10 min visual quick start into Raft and distributed consensus in general [http://thesecretlivesofdata.com/raft/](http://thesecretlivesofdata.com/raft/)</comment>


Nine years of Go - <AUTHOR> https://blog.golang.org/9years <comment><USER2> I've written a _lot_ of Go, I started four years ago when my workplace at the time wanted to ditch writing web services in Ruby. We were very deep into containers, so the obvious choice to the team lead was to do what the Docker folks were doing.

My take is that Go is a great language when you're working with incompetent people. It's so limiting in the abstractions you can build with it, that it is very difficult to write code that is not immediately obvious in its purpose. Go is easy to teach, easy to review, and it's so syntactically deficient and the tooling is good enough that it's hard to bikeshed. This ultimately improves the experience of writing code at work, and its static type system makes it easier to reason about large code bases for the folks who are used to using Ruby and Python at scale.

But Go is also awful in so many ways, its such an obvious step backwards in its design and the community is so dogmatic about Go and the Go authors.

On large code bases you almost invariably end up working around the deficiencies with the empty interface, code gen tools that add non standard syntax, and lots, and lots of copying code and code patterns over and over again. Any common pattern you see emerge, that you'd like to create a generic structure for, is probably impossible to encode without type variables. Go also notoriously pushes many errors that would have been caught at compile team to runtime because of its weak type system. With Sum types, it's difficult to make improper states illegal, and default values lead to subtle bugs because they essentially behave as predictable garbage.

Go honestly keeps me from having faith in software engineering as a craft. It's the acceptable of the status quo, or worse, moving backwards in order to fit the needs of the lowest common denominator.

<comment><USER3> "My take is that Go is a great language when you're working with incompetent people. It's so limiting in the abstractions you can build with it, that it is very difficult to write code that is not immediately obvious in its purpose."

Do you think this is intentional? Similar to how java is incredibly restrictive, and thus great for corporate programming environments?

<comment><USER4> "The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

\-- Rob Pike

<comment><USER5> this philosophy really shines when my golang compile time is super fast - especially compared to say c++ which is just an abomination

<comment><USER4> Yet Turbo Pascal for MS-DOS, with more features than Go has currently, did already have faster compile times on those clunky 8086 CPUs, let alone on modern 21st century hardware.

Fast compilation times in Go are only a surprise for a generation that never used native programming languages with native support for modules.

As for C++ compilation times, yes they are an abomination when doing _make world_ from scratch, including third party dependencies, with heavy template code.

However modules are around the corner and they were just voted into C++20.

<comment><USER6> >Fast compilation times in Go are only a surprise for a generation that never used native programming languages with native support for modules.

This.

</comment></comment></comment></comment></comment></comment><comment><USER7> In the last 3 months, we have built the new version of our API in Golang, the old one was in rails. The api serves a mobile app and a web app.

Despite taking longer to build, it's a treat to work on Golang. The explicit error handling and static typing have made our code much more reliable, with a lot less unit/integration tests required. Concurrency is dead easy to understand and build over. We are OK with using dep, definitely miss a debugger or an REPL. Having generics would make it much easier to write code. But overall it was worth it. Our response times are much lower now with a lot less server nodes required.

<comment><USER8> > definitely miss a debugger or an REPL

Bizarre that a programming language designed by non first time language designers, backed by a multi-billion dollar company and used extensively throughout that company(by "new" engineers), doesn't have a world class debug story.

<comment><USER9> The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

            — Brian W. Kernighan, in the paper Unix for Beginners (1979)

<comment><USER10> And the most effective car crash prevention system (for now) is the human brain, yet I still want a seatbelt, airbags and good brakes on a car.

Having a debugger available does not drop your IQ by 20 points.

<comment><USER11> > Having a debugger available does not drop your IQ by 20 points.

Not necessarily, but it _can_ have that effect. Sometimes I spend a long time in the debugger, following the chain from effects to causes to the causes' causes and so on, getting a little dopamine hit every time I uncover a new level – it's exciting, like watching a detective show – and ultimately discovering the root cause… only to have it be something dumb or obvious, something I might have found in less time by just patiently rereading the code.

<comment><USER10> You can just not use the debugger...

</comment></comment></comment></comment></comment></comment><comment><USER12> I love Go, used it a lot for over 3 years. I love the simplicity, directness, the inline structs, but I still cannot get out of the package management mess. I can even tolerate `if err != nil, return err` and do not care enoguh of generics, but I hope Go modules and Go 2 would fix, over the time, it has really become a love-hate relationship for me. My daily driver at work is Java and some Python, I really miss the tooling (of course, not runtime classnotfound errors) and maturity. Not ignoring the success of projects with Go, such a big one as Kubernetes, I think it is a whole different aspect, but Go started to tear me out through the years, and it is hard to defend it.

<comment><USER13> There is no better way to do errors imo, unless you're going the erlang way of "let it fail". Errors can be passed to the caller the same way exceptions are, and it becomes an endless pursuit of where the error is actually being handled (if at all). I agree that some syntax sugar helps, see Rust, but it doesn't completely fixes the problem.

<comment><USER14> It's baffling though that the compiler doesn't at least warn when you forget to check the err. So many edge cases with that (especially due to `:=` vs `=` if reassigning a prior err).

<comment><USER15> Try gometalinter. [https://stackoverflow.com/questions/43898074/is-there-a- way-...](https://stackoverflow.com/questions/43898074/is-there-a-way-to-find- not-handled-errors-in-go-code)

<comment><USER16> Specifically (if wanted standalone) [https://github.com/kisielk/errcheck](https://github.com/kisielk/errcheck)

<comment><USER15> Personally, I like my linter output in the style of a furious fruit salad, so I go for the kitchen sink.

</comment></comment></comment></comment></comment></comment><comment><USER17> I prefer to use .NET Core / C#. It is very fast, async, cross-platform, open source and unlike GO, it is a high level programming language. One disadvantage is that compilation time is not as fast as with GO, but it was improved over the last years.

<comment><USER18> > unlike GO, it is a high level programming language

what is high and low level depends very much on the context, but I don't see GO to be lower level than C#...

<comment><USER4> Lack of support for generics, enumerations, dynamic, FFI marshalling, expression trees, LINQ, exceptions, match expressions, ....

<comment><USER18> some of these are not present in other high level languages like PHP, javascript and you don't call them lower level...

<comment><USER19> PHP and JavaScript are not statically typed. What would be the use of generics in there? Obviously for the same reason you don't need the dynamic keyword. As for LINQ at least in JavaScript you have it, either integrated in the language with map, filter, reduce or using some library like lodash or Ramda. You don't have expression trees but you don't really need them given the highly dynamic nature of the language, although not at the same level as ruby if I remember correctly. JavaScript has exceptions, so here I'm really not sure what you are speaking about. For FFI marshalling (that for sure I would not call high level feature) there is webassembly. Match expressions are present in JavaScript and obviously you can't have exhaustive pattern matching like in typescript because of the lack of types. Even in that way it's pretty comparable to c# switch case. So to me it seems that at least JavaScript has all the features listed in the gp, why you are convinced of the contrary?

</comment></comment></comment></comment></comment><comment><USER20> I'm in the process of evaluating Go-raylib for a fantasy console project in lieu of Love2D. The basic rationale is:

* I only need inner loop high performance - it's a fantasy console, and intentionally limited. It will have some C code, but I don't want to write a lot of it.

* I want the project to be easy to build with few external dependencies(raylib is tops at getting this right)

* I want static types and zero-indexing for the "OS layer" part, at least, since I have to build some original data structures for IDE functionality(e.g. there will be a text editor).

It was the last part that made me switch away from Lua, and then it was the first two that made me consider Go.

<comment><USER21> I think the problem is the ffi overhead to C from Go is really high, like, way higher than any comparable language, because of the segmented stack thing. I mean the nice thing about Love2d is that LuaJIT has the best ffi overhead when calling C.

[https://github.com/dyu/ffi-overhead](https://github.com/dyu/ffi-overhead)

<comment><USER4> It always felt strange to me the CGO approach, instead of what many compiled languages offer, e.g.:

        function exit(code: integer); external;  cdecl;

No need to have two phase compilation or run external tools.

</comment></comment></comment><comment><USER22> just wondering, what are some well known Go projects? I know docker is one.

<comment> ainar-g * Kubernetes: [https://kubernetes.io](https://kubernetes.io)

* Hugo, a static site generator: [https://gohugo.io](https://gohugo.io)

* Gogs, a git service: [https://gogs.io](https://gogs.io)

* Syncthing: [https://github.com/syncthing/syncthing](https://github.com/syncthing/syncthing)

* CockroachDB, a scalable SQL database: [https://www.cockroachlabs.com/](https://www.cockroachlabs.com/)

<comment><USER23> Gogs has been succeeded by Gitea[0], as I understand things.

[0]: [https://gitea.io/](https://gitea.io/)

<comment><USER24> My last post on Gogs and Gitea: [https://news.ycombinator.com/item?id=17006872](https://news.ycombinator.com/item?id=17006872)

<comment><USER23> There are a lot of conflicting opinions, even on that thread.

It would be nice if someone wrote an article that did a deep dive on the current state of both of them.

Looking at Git activity, I can clearly see that Gitea is _more_ actively under development by every metric.

However, since they are now divergent code bases, what does Gogs offer that would make someone inclined to use it over Gitea?

</comment></comment></comment></comment></comment><comment><USER13> What happened to the weird tire logo?</comment>


SCOTUS – Constitutional Protection Against Excessive Fines Applies to States - <AUTHOR> https://www.washingtonpost.com/politics/courts_law/supreme-court-says-constitutional-protection-against-excessive-fines-applies-to-state-actions/2019/02/20/204ce0d4-3522-11e9-af5b-b51b7ff322e9_story.html <comment><USER2> Comments moved to [https://news.ycombinator.com/item?id=19209957](https://news.ycombinator.com/item?id=19209957), which seems to be the article generating more responses.

If you care about the karma, I'm sorry. Usually we take the earlier submission as the primary one. Someday we'll implement karma sharing on popular stories, to solve cases like this.

<comment><AUTHOR> No need to apologize re karma, I'm happy with what I got.

My submission was on the front page within 10 minutes. It's interesting how things played out here.

Perhaps it was the title, or maybe just timing.

Anyway, thanks.</comment></comment>


ZFS officially coming to Ubuntu 16.04 - <AUTHOR> https://twitter.com/Stephenitis/status/697560639657680896 <comment><USER2> I thought the license was incompatible? Also, what does this mean for BTRFS?

<comment><USER3> The license does not allow for ZFS to be included in the kernel. It runs in user space.

<comment><USER4> I don't know much about Linux kernel architecture, but could it be a separate binary loaded at runtime by the kernel, so that it's not actually part of the kernel?

<comment><USER2> That's how [http://zfsonlinux.org/](http://zfsonlinux.org/) approaches it. Maybe Ubuntu will just package it in the standard distro. That'd be a bit underwhelming if that's what it is. From what little I know about ZFS, its designers basically thought that traditional layering of how storage is approached in UNIX didn't make sense, so they re-did much of it from scratch. As a result, ZFS doesn't really natively fit as a pluggable filesystem.

</comment></comment></comment></comment><comment><USER5> Details please ...

<comment><USER5> Assuming I can reply to my own post? Anyway, I dug up comments from a Gentoo Developer and ZFS On Linux contributor, Richard Yaoon Phoronix: "Michael's prediction that 15.10 will use a DKMS package is likely correct ... there is no legal issue preventing the sources from being combined because neither the CDDL nor the GPL place restrictions on aggregations of source code, which is what putting ZFS into the same tree as Linux would be. Binary modules built from such a tree could be distributed with the kernel's GPL modules under what the GPL considers to be an aggregate"

[http://www.phoronix.com/forums/forum/software/general- linux-...](http://www.phoronix.com/forums/forum/software/general-linux-open- source/827623-ubuntu-is-planning-to-make-the-zfs-file-system-a-standard- offering)

Edit: Some other details on Softpedia including a comment from a Canonical developer. [http://news.softpedia.com/news/zfs-file-system-for- ubuntu-16...](http://news.softpedia.com/news/zfs-file-system-for- ubuntu-16-04-lts-is-90-ready-498166.shtml)</comment></comment>