Ask HN: Most cost-effective method of achieving physical redundancy - <AUTHOR> Hi,
We have a client currently being hosted on a single server in a data centre in the UK. They are asking about getting a level of physical redundancy built into the hosting infrastructure. If a plane lands on the data center, they want to be able to continue operating their website. They are not overly concerned about the service dropping out for a minute or two, but they want to avoid the hours spent offline whilst we restored from backups to another data center and redirected the DNS.
I've done some investigation and found two relatively cheap solutions:
1. Get an additional failover server hosted in another data centre. Operate some level of rsync and mySQL replication to the failover server. Then run a service like http://dynect.com/ to do a rudimentary form of failover via DNS. This is not a 100% solution for everyone (mainly people with badly configured long TTL DNS servers). The rsync/mysql replication is also open to potential problems. This seems like one of the cheapest solutions.
2. Use a provider with a SAN-based virtualisation setup with a backup data centre. I know Hostway offer this, but it is not cheap! In the event of a failover we just fire up our VMWare instance in the failover data center and pick up on the shared SAN.
Both of these are not ideal. 1 is a bit too flakey for my liking, and 2 is a bit too expensive for my client. Is there a neater solution that I am missing?
The application is Java/Struts2/Spring/Hibernate running Tomcat/Apache/MySQL on Linux .
Thanks! <comment><USER2> Interesting question :)

1\. The most cost effective in terms of immediate capital outlay is active- passive - which is pretty much #1 that you described. This is generally also less effort... and is generally easy to test.

2\. The most cost effective long term strategy is active-active as you get ongoing use of both sites. Particularly if the client is happy for reduced performance in a DR scenario... Even if this isn't the case, at least you get a performance boost from the DR site.

This is usually more effort as you need things like replication to work/perform... And you also need to test a whole new range of failure scenarios.

This approach does have some other advantages though. For example, you can do rolling deploys very easily (upgrade DR first, bring down Prod, upgrade Prod).

3\. A common hybrid is to have two active sites on the Tomcat/Apache end and active-passive for the MySQL. Depending on the DB load this can be a best of both worlds scenario.

4\. Some other solutions use a coherent cache solution - e.g. Tangosol, which works with Hibernate/MySQL. As long as the latency between the two sites is low, then this should work. Tangosol is a non-free product, now owned by Oracle afaik, but I don't think it's prohibitively expensive... I've seen this used a lot, and it's probably a very simple and elegant solution, but I personally don't like adding another moving part in. A lot of people I've met swear by it though, particularly Hibernate users.

<comment><AUTHOR> This response is exactly why I posted on HN! Love this site.

In terms of active-active, I guess I need two physically disparate load balancers that heart beat with each other? I'm not really a network engineer, and I dont understand what happens to the packets when 1 data center goes down, in terms of routing around it?

Thanks for your time.

<comment><USER2> > In terms of active-active, I guess I need two physically disparate load > balancers that heart beat with each other?

Yeah - as the brk indicates in his post, you can use something like haproxy to do this. Afaik, you can get Apache to do this too...

One advantage might be that Apache can be configured to do "sticky sessions" - which you'll need if you're not sync'ing sessions between sites (which in this scenario doesn't seem necessary). Never used haproxy, but it might do this too.

In terms of your active-active setup, you can have two "legs" that are load balanced at the front, or you can have load balancing between each tier. If you're (a) not very experienced or (b) you don't have lots of bandwidth between sites, I'd go with the former and just have load balancing at the front end.

</comment></comment></comment><comment><USER3> Get your own ASN ;)

You are on the right path with your approach #1. Setup a failover server someplace and keep it sync'd at an interval that is the right balance between too-often and too-stale.

You could opt to get a small dedicated machine from a larger-scale true multi- homed hosting company. Run haproxy on this "small" machine, which serves primarily to redirect traffic to whichever server is currently deemed to be the "active". Basically this is a low-end DIY Akamai kind of solution. Your cost would be somewhere between #1 and #2. You would eliminate the DNS-lag and the issues you can't control (other servers and clients caching stale DNS data that you can't refresh), and you would get most of the benefits of an availability service like Akamai, without the $15KUSD monthly price tag.

There are other benefits to the haproxy solution as well, you can take either machine offline for maintenance with zero (theoretical ;) ) downtime, and if you ever get a traffic surge you can load balance between the two sites (which isn't a bad idea to do all the time if your syncing is up-to-date enough. Send every 10th connection to the fail over site, just to make sure it's always working as expected).

<comment><AUTHOR> What happens if the 'small' server fails?

<comment><USER3> Depends on how risk-averse you are. You can generally get an SLA that would allow you to have a hot-back up of that server, or you take the risk that it won't wail until you can afford the "better" solution.

Doing "high availability" coupled with "low budget" is ALWAYS going to involve some compromises.

If you keep your DNS TTL's low, the worst-case scenario is if the small server fails, you're doing exactly what you would have done anyways: making manual or automated DNS changes.

<comment><USER4> When I investigated a low cost solution like this before, the issue was big companies like AOL not honoring TTL's less than 24 hours. Is this still the case?

</comment></comment></comment></comment><comment><USER5> 1\. is the cheap way. as someone else said, you can use BGP instead of dns for failover to improve downtime, but then it's no longer cheap.

Personally, this is my preferred solution. keep as much as possible in MySQL cluster and have the rest built on a central dev server and pushed out when there are changes.

San is not cheap, and it's pretty easy to screw up the whole san. It's still a single point of failure. (I ran prgmr.com on a san for the first few years, and I switched away from SAN not because of cost, but because of reliability. With a san, it's really easy for the new guy to accidentally trash everything.)

so yeah, I'd do #1. if you can use a active-active VPS, that's best, if you want to save money, run a smaller active-active site with ec2 images standing by (remember to test weekly) - the problem with 'cold' backups is that they are usually broken. active active means they are up all the time.

</comment><comment><USER6> A quick question: When replicating mySQL across data centers, is there an easy or perhaps built-in way to encrypt the replication data streams to prevent prying eyes from potentially intercepting the data? If not, might that be a problem if one is passing replicating credit card numbers, etc.?

<comment><USER7> In the past, I've used stunnel for encrypting server-to-server communications. It's very easy to setup.

</comment></comment><comment><USER8> why not just auto-copy everything to AWS and do checks for uptime of your host. Then if the check fails, auto-forward the url to the AWS location.

This way if it hits the fan, the only problem the users will notice is the 5 mins of downtime between the checks, before the site becomes slower due to the switch to AWS

But then again I don't really know hardware so could be wrong. But from what I understand should be possible</comment>


Our startup quest to generate 1M ideas in one year - <AUTHOR> http://www.dwilly.co/blog/startup-quest-to-generate-1-million-ideas-in-one-year

<comment><USER2> One of my favourite things about HN are the brainstorm threads. So much fun, so many insights! I don't fully understand what _dwilly_ does, but I will give it a try.

<comment><AUTHOR> Really appreciate that @Red. Sorry for any vagueness - slowly building a community doing sort of what you're talking about + involving them in the process of building it. Gonna be fun and glad to have you on board :)</comment></comment>


Let's do AWS whiteboard sessions – I'll review your architecture, live - <AUTHOR> Hey guys if you're interested in AWS & tech in general subscribe to my YouTube channel. I'll be talking about system design/solutions architecture with a huge concentration on AWS. I already have a couple of videos there.
I will be releasing a video every week so if you have a topic you'd like me to dive-deep into let me know. I'd also be interested in having tech discussions with field professionals -- I can whiteboard and architect solutions based on your requirements. Subscribe and reach out!
https://www.youtube.com/VladimirBudilov
Here's one I did recently on the topic of Serverless Photo Recognition: https://www.youtube.com/watch?v=GIdJz7VnP58
P.S. This isn't sponsored by AWS and all of the opinions are my own. P.P.S. Here's my LI: https://www.linkedin.com/in/vbudilov/ <comment><USER2> I'd like to see some general best practices/architecture. Something that would fit a large range of web applications, not just the one I'm making.

For context, below are some details of what I plan to make.

This web application will have: \- user provided content \- login/sign-up \- email notifications (sign-up, user comments, etc) \- limited number of users at the beginning (less than 100 per day). But I want it architected in a way that allows me to scale up when the time comes. \- Standard web application security patterns \- Standard web application performance patterns (load balancers, containers, CDNs, etc) \- Secrets will be stored in Vault (or similar)

My planned full-stack is: \- Vue \- Vuetify \- PWA \- SSR \- Apollo GraphQL + Hasura + PostgreSQL \- Node or Python

<comment><AUTHOR> Does this suffice? [https://www.youtube.com/watch?v=QHJzO5IQCw0](https://www.youtube.com/watch?v=QHJzO5IQCw0)

<comment><USER2> This is great

</comment></comment></comment><comment><USER3> Can I give you some really ridiculous hypothetical requirements to examine?

<comment><AUTHOR> of course

</comment></comment><comment><USER4> Understanding an AWS stack for real time stream processing would be fantastic.</comment>


Reddit raises $300M at $3B valuation - <AUTHOR> https://www.cnbc.com/2019/02/11/reddit-raises-300-million-at-3-billion-valuation.html <comment><AUTHOR> This was rumored last week, but the details such as amount/valuation weren't known yet. Here's the HN discussion from that: [https://news.ycombinator.com/item?id=19087558](https://news.ycombinator.com/item?id=19087558)

</comment><comment><USER2> How is Reddit only valued at 3b but WhatsApp was 19b?

<comment><USER3> Probably a much larger international userbase for WA. Anecdotal, but I've found that most non-English subreddits are pretty dead (or have niche users in foreign countries), whereas when I meet Turkish, Polish, Russian, French, etc. people in the US and abroad, they all ask me to add them on WhatsApp.

<comment><USER4> Not just internationally: a much larger userbase in general. And, I believe more importantly: reddit is essentially a forum. Few people are super invested into forums. They get older, their interests change, they have less time to argue about politics, they move on from forums. Whatsapp is a messenger, people rarely move on from those - it's usually the messengers that abandon their users, not the other way round (aim, icq, skype...), and they do profit from a network effect, reddit doesn't.

<comment><USER5> In 2 years 75% on my social network moved from facebook messenger to WhatsApp.

In 5 Years, snapchat went from the next crazy thing to something I barely hear about.

Remember frontback ? They turned down $40 million 5 years ago.

I could go on and on. Meanwhile, reddit is in the top 10 most visited websites in the world for as long as I can remember.

<comment><USER4> Facebook messenger wasn't actually a messenger in the IM sense, it was a bad site chat, and too locked in. Hence buying Whatsapp = good idea (plus much more data to mine, obviously).

You're right though: things can change. But they usually don't do too quickly once the dust has settled and the giants have emerged. Yeah, yeah, there could be a Google killer tomorrow, but there probably won't. That's very different when markets are still developing and nobody has any clue what's going to happen in 6 months time, but monopolists don't just disappear over night because a new kid rode into town. That's what's different between snapchat, myspace and facebook.

Reddit has nothing even close to that kind of pull. To get to the advertising dollars, it will have to crack down on users and become sfw, and that will turn lots of people away. When there's money to be made, they will also have to deal with copy right, and that will shut down a good part of the meme subreddits, I'm afraid. I'm sure it'll still have a place in a few years, controlling a major discussion platforms is worth money after all, but I don't see it going to the big league by staying what they are now.</comment></comment></comment></comment></comment>


Phone-addicted teens aren't as happy as those who play sports and hang out IRL - <AUTHOR> https://techcrunch.com/2018/01/23/phone-addicted-teens-arent-as-happy-as-those-who-play-sports-and-hang-out-irl-new-study-suggests/ <comment><USER2> It is well documented that exercise is good for well being and happiness. So if teens are shunning exercise in favour of digital media, it's not surprising they are becoming more depressed.</comment>


Show HN: KivyImageViewer – A kivy Python 3 powered Image Viewer - <AUTHOR> https://github.com/ohlogic/kivyImageViewer <comment><AUTHOR> My First attempt at a kivy app programmed for the Desktop Linux. Any suggestions on how to improve? Thanks for reading.</comment>


Google Glass enters an Operating Theatre - <AUTHOR> http://www.thehindu.com/news/google-glass-enters-an-operation-theatre-in-chennai/article5139164.ece

<comment><USER2> I think they mean "Operating Theatre".

</comment><comment><USER3> I just hope the surgeon turns her email alerts off before opening up.</comment>


Lucene and Solr development merged - <AUTHOR> http://asserttrue.blogspot.com/2010/04/lucene-and-solr-development-merged.html

<comment><USER2> Good decision. I use either Lucene or Solr on two or three projects a year. Solr adds a lot of functionality to Lucene so now hopefully a lot of that extra functionality will be easy to use in embedded Lucene applications.</comment>


Unusual Features of the SARS-CoV-2 Genome and Its Probable Synthetic Route - <AUTHOR> https://zenodo.org/record/4028830#.X2AUhGhKhaS <comment><AUTHOR> (I put this comment on all duplicates of this post)

I posted what appears to be the top comment on the previous submission of a similar paper describing the probable laboratory origins of SARS-CoV-2 ([https://news.ycombinator.com/item?id=23875758](https://news.ycombinator.com/item?id=23875758)), so I'll try and do another quick summary here. (Caveat: I have no particular expertise in this area, I just read a lot of scientific research)

The lead author here is an immunologist who, unlike the authors of prior papers alleging laboratory origin, is Chinese and was trained in Chinese institutions. At the time of the outbreak Dr. Li-Meng Yan was working in a public health lab at Hong Kong University and was asked to investigate. She claims that she fled to the US after realizing that there was a cover-up going on and she knew too much already.

The most striking and novel claim made here is that the bat coronavirus RaTG13, which is a 96% genetic match to the novel coronarivus, is a total fabrication. This argument is based upon a few key observations:

1\. RaTG13 was supposedly discovered in 2013 but not publicly reported until after the outbreak already started, in a paper (published by researchers closely affiliated with the WIV) that claimed it as evidence SARS-CoV-2 likely originated from bats.

2\. A number of independent preprint papers raise significant concerns about the veracity of RaTG13, and one published paper indicates that the RaTG13 spike protein is actually ineffective at binding to ACE2 receptors in horseshoe bats (the supposed reservoir).

3\. After excluding RaTG13, the next closest relatives are two bat coronaviruses (ZC45/ZXC21) that were discovered and characterized by Chinese military research labs. A Chinese lab published research near the start of the outbreak which identified these viruses as the closest relatives, and that same lab was apparently closed for "rectification" shortly thereafter.

The paper goes on under the assumption that ZC45 or ZXC21 was the backbone for engineering the SARS-CoV-2 virus, noting how the particular characteristics of the genomic match (100% E protein, 94% Orf8 protein) align with what one would expect after the gain-of-function modifications that produced the unusual RBM and furin cleavage site which were also identified in the Sørensen paper. This paper goes into much more detail on those two points, and provides counterfactuals to describe how unlikely these observations would be in a naturally-evolved virus.

In the second half of the paper the authors describe in detail how a lab with sufficient technical acumen could engineer a virus like SARS-CoV-2 through a sequence of well-defined steps, with references to published research demonstrating these capabilities. Then they postulate the exact components involved in engineering the actual SARS-CoV-2, along with a projected timeline of six months for the whole process.</comment>


Sam Altman's Manifest Destiny (2016) - <AUTHOR> https://www.newyorker.com/magazine/2016/10/10/sam-altmans-manifest-destiny <comment><USER2> _Recently, YC began planning a pilot project to test the feasibility of building its own experimental city. It would lie somewhere in America, or perhaps abroad, and would be optimized for technological solutions: it might, for instance, permit only self-driving cars. "It could be a college town built out of YC, the university of the future," Altman said. "A hundred thousand acres, fifty to a hundred thousand residents. We crowdfund the infrastructure and establish a new and affordable way of living around concepts like 'No one can ever make money off of real estate.' " He emphasized that it was just an idea—but he was already looking at potential sites._

I've been thinking about the feasibility of this as well recently. A good college town has a component of informality, collegiality that binds its residents together.

Munich may be the best example I can think of: a college town dating back to medieval times, scaled up to a city of 4M+ souls. TUM and ABDK seem much more intertwined with the real-world urban design and planning of infrastructure and public spaces, than say MIT and RISD. Not to mention the crafts of cheese, bread, beer making, etc!

<comment><USER3> Utopian attempts to build cities almost always fail.

"the real-world urban design and planning of infrastructure and public spaces" from the 19609's brought us empty downtowns, sprawling suburbs, lack of culture and cars everywhere.

The notion of a 'tech first' place is almost repulsive.

Humans are people, who about 'people first'?

How about the fact that we have been 'iterating' already for thousands of years on this one?

'Munich' is a great city precisely because it is old, and it will never be great 'because tech'.

Utopianism is one of the most consistently apparent acts of crude hubris among technologies and ideologues, and it blows me away because there is so much in recent history to show how exemplarily bad it can all be. Basically the entire Soviet Union and satellite Empire speaks to this.

Visit anywhere in Eastern Europe and see the 'revolutionary people's Utopias' built on 'reason, technology and equality' ... my god man.

All of that said - it's good to experiment and if some college town wants to 'go tech' from Google, then that might be a good idea.

As for Google's 'Toronto Harbourfront' initiative ... no.

<comment><USER4> > almost always fail

 _Almost_ always? What would you cite as a success?

<comment><USER5> Alexandria wasn't utopian afaik, but it was a planned city that seems to have been a success right away.

<comment><USER4> Are you referring to Virginia or Egypt?

<comment><USER5> Egypt. [https://www.theguardian.com/cities/2016/mar/14/story- cities-...](https://www.theguardian.com/cities/2016/mar/14/story-cities- day-1-alexandria-egypt-history-urbanisation-foundations-modern-world)

</comment></comment></comment></comment></comment></comment><comment><USER6> (2016) and quite outdated at this point.

</comment><comment><USER7> This is only two years old and it's very out of date. Amazing how quickly Sam (and YC) evolve.

</comment><comment><USER8> This was posted in 2016: notable, as Sam hasn't blogged about these projects much since then.

<comment><USER9> I think the demeanor, aspirations, love of country of most people changed drastically very late in the evening of November 8th of that year.

<comment><USER10> Totally unrelated, but I just last week did say I loved being an American and love this country yet immediately I got shunned for being a crazy right-wing conservative. I'm like what??! So I can see how thought leaders in this space are keeping quiet waiting for the hypersensitivity to cool off.

<comment><USER11> What did you say "I love being an American" in response to? And did you say just that or was there more to it?

And how exactly did they shun you?</comment></comment></comment></comment>


An overhaul of the battery will jump-start a shift to renewable energy - <AUTHOR> http://www.theatlantic.com/magazine/archive/2014/05/a-better-battery/359811/

<comment><USER2> I'm not particularly convinced by this story. It reminds me of a similarly unconvincing piece by Charles Mann a few months back on the prospect of seafloor methane hydrate mining.

Battery science is hard, capacities are limited by chemistry, and the easy-to- find electrolytes (also the cheapest and most abundant) are fairly well known. Barring breakthroughs in allotropes (such as graphene, everyone's current favorite carbon molecule), novel inorganic molecules, or biotech-derived approaches, I suspect chemistry doesn't have a whole lot extra to give us. Even reasonably abundant minerals such as lithium portent supply crunches when scaled to, say, a century or more worth of battery EV production (though Elon Musk speaks confidently of addressing this via recycling -- though no recycling process is 100% efficient).

The more interesting approaches I've seen for grid-scale battery storage involve possibly less efficient, and certainly less convenient, but cheap and highly abundant materials such as the molten salt or liquid metal (see Donald Sadoway's work) concepts. The chemistry works, the materials abundance is there.

I've played with some back-of-the-envelope calculations suggesting that for electrical energy storage, very large scale thermal storage, say enough for two weeks of supply at the scale of the US, is plausible. The heat-substrate facility would be approximately the size of an existing very large petroleum storage tank farm (these exist in Oklahoma at the terminus of several oil pipelines). See: [http://redd.it/1viied](http://redd.it/1viied)

But the really useful forms of energy storage humans have turned to are long- chain hydrocarbons, whether created recently in nature as olive oil, beeswax, tallow, or other biogenic oils, or in the form of petroleum, and to a lesser extent gas and coal.

The prospect of the US Naval Research Lab's electricity-to-fuel project utilizing seawater as a source of both hydrogen and CO2 to feed a Fischer- Tropsch synthesis process strikes me as among the most promising prospects I've read in a long time. It requires an external energy supply (the Navy proposes existing nuclear reactors aboard aircraft carriers, or renewable energy in the form of ocean thermal energy conversion (OTEC). Proposed at a scale of 100,000 gallons of aviation fuel (essentially kerosene or diesel) daily, fed by 240MW of electrical energy (roughly the scale of a carrier's reactors), at a cost of $3-$6 per gallon of fuel produced, it's more expensive than present fossil fuel energy sources, but, when tied to a renewable energy source, offers the prospect of a constant-cost liquid fuel source effectively forever.

It also seems to me that scaling this to roughly national levels of production is at least plausible. The NRL's proposal is 1/8400th of present US petroleum consumption, but scaling up costs and plant estimates, $8 trillion in capital, 2 TWe in energy, and a total of 10 m x 4.5 km x 4.5 km processing facility volume, would replace the 20 million barrels of oil presently consumed daily in the US. This compares against some $4 trillion in capital expenditures on new conventional petroleum exploration from 2005 - 2012 with a net _reduction_ in oil supply of 2 million barrels/day.[1] And yes, the supplied electrical energy is an _additional_ cost: this won't be cheap. But it's forever.

Round-trip efficiency isn't great: no better than the 60% efficiency of hydrogen electrolysis, with additional energy input requirements for CO2 extraction and a _lot_ of seawater handling (8.8 billion liters/day for the Navy's proposal, 74 trillion at national scale). But once produced, oil doesn't suffer from the relatively rapid storage losses of most alternatives: a few percent per hour or day for many battery, thermal, or kinetic flywheel systems. If used for electrical generation there's another 30% generating loss experienced, for a maximum net efficiency of 42%, but if used to provide liquid fuels to critical uses, this could well prove highly attractive -- there are somethings it's really hard to substitute for.

The process should also be carbon neutral, though it does involve a net transfer from present ocean to present atmospheric carbon reservoirs.

I discuss this more here: [http://redd.it/22k71x](http://redd.it/22k71x)

It's not that I don't expect _some_ improvement in battery technology, but there's a 5x advantage in energy storage densities (MJ/kg) between the _best_ present battery storage technologies (lithium-air) and liquid hydrocarbons. That's closer to 25x for LiON vs. oil[2]. While incremental efficiency improvements (and better energy scavenging through, say pervasive PV surfaces) might be useful for electronics and their Moore's Law dynamics, for devices operating in the physical world and its constraints, batteries will continue to be at a disadvantage in cost, capacity, complexity, and/or abundance.

________________________________

Notes:

1\. Steven Kopits presentation, February, 2014. [http://energypolicy.columbia.edu/events-calendar/global- oil-...](http://energypolicy.columbia.edu/events-calendar/global-oil-market- forecasting-main-approaches-key-drivers) Also discussed and analyzed by Gail Tverberg: [http://ourfiniteworld.com/2011/03/03/steven-kopits-oil- the-e...](http://ourfiniteworld.com/2011/03/03/steven-kopits-oil-the-economy- and-policy/)

2\. [http://en.wikipedia.org/wiki/Energy_density](http://en.wikipedia.org/wiki/Energy_density)

<comment><USER3> Hey! I was always fascinated about energy, but am not too knowledgeable, so I would like to ask you something about oil production: would it be possible/efficient/economical to grow plants (e.g. algae or photosynthesizing bacteria) instead of using CO2 extracted from the sea? I.e. build huge pools in sunny areas, grow algae, harvest them occasionally, and extract CO2 from them or, even better, process them, essentially speeding up the natural oil- producing process.

<comment><USER4> There are dozens of companies that are working on this (I work for one) in a variety of media including bacteria, yeast, algae, switchgrass, etc. It's a very hard problem made more difficult by the drop in the cost of oil from $150 -> $75 since most of these companies were funded.

A partial list of people working on it:

* Amyris

* Solazyme

* KiOR

* Algenol

* Sapphire

* Aurora

* Synthetic Genomics

* Cellana

* PetroSun

Notably, most of the companies on that list have taken hundreds of millions of dollars from domestic and foreign oil companies hoping to create their own supply. Maybe more notably, several of the companies on the list went public, then lost 80-90% of their market cap. Most are pursuing other, higher value products as a first-order business, with promises of biofuels down the road.

<comment><USER2> As I commented previously: plant productivity simply doesn't scale to existing petroleum consumption levels. Even substituting for petroleum in niche uses (say: ocean shipping or aviation) comprising a few percent (I believe combined these are around 5% of total petroleum use, though aggregate global stats are hard to find), in which alternatives are unfeasible, would be a major challenge and require the allocation of tremendous acreages of land to biofuel production.

Remember that the transition from wood to coal occurred largely because the world was running out of wood. Otherwise, wood had a lot to commend itself: it was locally available (coal comes from limited locations), doesn't involve mining dangers, and is easier to burn (some early coal proponents in the US were accused of fraud when the "rocks" they sold wouldn't burn in existing ovens -- anthracite coal is tough to ignite).

Where opportunistic feedstocks exist, I suspect biofuels may supply _some_ energy, but it's going to be a very small fraction of existing fossil consumption in advanced nations.

<comment><USER4> In the short term, you're likely right, in the very long term, I think biofuels will make up the vast majority of liquid fuel (which will be helped as most transport moves to electric).

There have been some interesting developments in biofuels lately with Algenol peaking above >10,000 gallons/acre/year rate and demonstrating a sustained rate north of 8,000 gallons/acre/year. There have been some murmurs of breakthroughs in genetically modifying the photosynthesis pathway as well, which could have a dramatic affect on per-acre productivity.

<comment><USER2> Unless (or until) human populations fall markedly -- to, say, 500m - 2b, the viability of biofuels simply doesn't add up. There's too much conflict with both other human ag demands, and with ecological systems.

Is that algenol productivity associated with open-air production, or is that in an artificial controlled environment with UV lighting and a highly engineered grow space?

Even if those production rates can be sustained, you're looking at 30 million acres for algae cultivation.

Technical details are thin, but I've found their 9kgal/acre-yr release:

[http://www.biofuelsdigest.com/bdigest/2013/03/11/algenol- hit...](http://www.biofuelsdigest.com/bdigest/2013/03/11/algenol- hits-9k-gallonsacre-mark-for-algae-to-ethanol-process/)

<comment><USER5> But 30 million acres is merely a vast amount of infrastructure. It's a big piece of land if you consider it at once (a few hundred miles on a side), but spread across all the places where there are people, it isn't that big an area.

If you manage to build some of the infrastructure in the oceans, the area doesn't even matter (that doesn't mean it would be easy, there is just lots of room).

<comment><USER2> It's a vast amount of land, no matter how you slice it.

A few hundred miles on a side is the size of many larger states in the US, and that assumes a 100% fill factor. Add in requirements for access roads, equipment, human habitations and support, and that's going to increase, though I'm not sure by how much -- 10% to 30% wouldn't surprise me.

Built as a corridor, 30 million acres is 1000 miles x 47 miles -- an assembly of grow tanks stretching 25 miles on either side of an highway running from Chicago to Denver. Though more likely it would be situated in a desert region (so as not to compete with existing agriculture), but where it _would_ compete with alternative direct electrical (or electricity-to-fuel) alternatives.

Even if the area doesn't require freshwater access, it will require _water_ , and for that to be transported (likelihood of occupying thousands of miles of coastline are slim) considerable distances inland, and then back out again (waste streams and salt). All of which are both capital and operationally intensive.

Building sea-based structures would similarly be insanely capital intensive. You'd be better off finding a way to create an inland salt lake (say: in the Dead Sea or Death Valley) and situate your grow-ponds there.

Marine or even simply salt-water environments are very, very harsh and hard on structures (even concrete) and equipment.

<comment><USER5> Sure, it's a tremendous amount of system to decide to construct. But "15% of Texas for liquid fuels for forever" isn't that bad a deal if you can actually get it to work (and there is realistically a lot of low hanging fruit in reducing US fuel consumption, present day numbers would work fine for quite a lot more people).

You can also put some of those acres in other places, you don't have to take them all from Texas.

<comment><USER2> As a practical matter, so long as you're situating this in the US, odds are very good that you're looking at Texas or California, possibly other Gulf states (though there'd be competition for other ag activities there). Perhaps building floating algae structures over Florida after it sinks under rising oceans....

You're constrained by alternative land uses, requirements for sunlight, avoiding freezing (even in Texas and California, desert regions see frosts), and access to seawater.

Elsewhere in the world you could situate grow ponds in warm desert regions: the Sahara, northern and western Australia, the Arabian peninsula (somewhat ironically, requires more comic san(d)s), and similar areas, though these would be among the largest.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> It is generally hard to take James Fallows' opinions seriously. He is a great writer but always seems to be of the wrong side of history. For example back in the late 1980s he led the "The Japanese are Taking Over the World" scare just before Japan went into a multi-decade decline[1]. The fact that he is now worried about China puts my mind at ease.

He is much more credible when he simply quotes Stephen Chu. That much better batteries would change the world is not controversial. Actually making it happen is the tricky bit.

[1] [https://www.theatlantic.com/past/docs/issues/89may/fallows.h...](https://www.theatlantic.com/past/docs/issues/89may/fallows.htm)

<comment><AUTHOR> > _It is generally hard to take James Fallows ' opinions seriously. _

To me it's exactly the opposite. Fallows isn't infallible, but his opinions are always measured and carefully-considered. For probably 30 years now I've been interested in what he's had to say about any variety of issues (except his interest in beer, which strikes me as perhaps an affectation calculated to present an Everyman image).

For example, Fallows moved to Japan in the 1980s, living and working there for several years if memory serves. His view on Japan's economic future was _extremely_ widely held back then; many, many smart people have scratched their heads since then, wondering why things didn't go as predicted. (Who'd have thought it: History not unfolding as predicted; now _there 's_ something new, eh?)

As to Fallows's views on China, he has been a voice of moderation --- again in part because he moved there to live and work for a few years.

<comment><USER7> Mutant Keynesian policy idiocy coupled with demographic decline is why things didn't go as predicted.

<comment><AUTHOR> Hindsight is always so much easier to get right than foresight.

</comment></comment></comment></comment><comment><USER8> Batteries are really hard.

The combination of electrochemical systems, with mechanical requirements make the tradeoffs subtle and the gains sometimes elusive.

Ex: We tested some new SLA(Sealed Lead Acid) batteries that claimed 20% improvement. They provided very close to that number. But they were totally unacceptable for us - the plates were too fragile and were breaking/shorting in transit.

<comment><USER9> It's not possible to physically encapsulate the plates with some plastic grid to make them more resistant? What kind of application are you doing?

<comment><USER8> Riding Lawnmowers.

And no, that would obviate the benefits of their new technology.

</comment></comment></comment><comment><USER10> This article is disappointing - the first two thirds explain why we need better batteries, as if it was not already painstakingly obvious, and then the last bit mentions three technologies without actually saying much about any of them.

</comment><comment><USER11> This is a good driver for tech. It makes sense for everyone to have their own battery at home to be like a google server ups... Distributed is far more reliable than centralized. Heck the power grid wouldn't even have to be 24/7 anymore if it could handle both the peak current and deliver enough average power.

<comment><USER12> Electricity is an area where centralized is much more efficient and reliable, due to the economies of scale when dealing with larger load infrastructures. However, batteries close to the end point could definitely a useful thing, because the grid does work better when there is a constant load. It's easier to plan for both day-to-day activities, and if a plant does need to go down for emergency maintenance.

<comment><USER2> It's not just economies of scale, but laws of large numbers.

Existing grids have benefited from the fact that though any given individual demand rate might vary widely, averaged over a large number of consumers, trends are far more predictable.

On the generating side this hasn't typically been as much of an issue, with highly reliable and dispatchable generating plants. With intermittent renewable/sustainable sources, the fact that local variations in solar or wind capacity can be mitigate by transmitting surpluses, or importing necessary capacity, also helps. In an advanced grid with attached storage, again, large- number averaging should, with effective management, help balance supply and demand.

Trying to do this at the scale of individual households means far more variability which must be dealt with on he immediate premises. This is among the reasons I strongly doubt that visions of a "gridless future" will emerge, at least so long as there's not widespread collapse of _all_ social and technical infrastructure.

<comment><USER11> Large battery banks would allow demand to "debounced" (smoothed) such that load could be much flatter and more predictable. It would be an adjunct at most, definitely not a replacement because it would be temporary storage. Further, any new tech never replaces the previous completely (just look at DC- power grid for elevators in SF. Records, 8-tracks still exist in a post CD world.)

</comment></comment></comment></comment><comment><USER13> If a large proportion of energy comes from storage wouldn't that eliminate or reduce the need for off peak pricing? In such a system could you actually bid on overcapacity? So that the initially generated energy would be sold to the highest bidder who would store or use the energy.

<comment><USER14> People are doing just that to take advantage of off peak pricing:

[http://www.theatlantic.com/technology/archive/2013/11/the-10...](http://www.theatlantic.com/technology/archive/2013/11/the-100-000-battery- that-could-help-hotels-save-bundles-of-money/281194/)</comment></comment>


My four months as a private prison guard (2016) - <AUTHOR> https://www.motherjones.com/politics/2016/06/cca-private-prisons-corrections-corporation-inmates-investigation-bauer/ <comment><AUTHOR> A book just was published with this article as the base. Here's the NY Times review of the book:

[https://www.nytimes.com/2018/10/01/books/review/shane- bauer-...](https://www.nytimes.com/2018/10/01/books/review/shane-bauer- american-prison.html)</comment>


Quantum magic: A skeptical perspective (2011) - <AUTHOR> https://arxiv.org/abs/1107.3800 <comment><USER2> > _We argue that many popular "quantum paradoxes" stem from a confusion > between mathematical formalism and physics [...] most "conceptual puzzles" > of QM are not much different from the well-known paradoxes from probability > theory_

This is really really true. Particularly for any experiment with "delayed choice" in the name, where pop-science explanations follow correlations backwards instead of forwards then confuse correlation for causation and start talking about time travel ( _sigh_ ).

<comment><USER3> i would love to see a translation of quantum paradoxes to probability paradoxes - e.g. quantum tunneling is the same as basically measure 0 events.

<comment><USER4> Or what about wave particle dualities?

How can one particle interfere with itself?

<comment><USER5> Personally I think the concept of "particle" needs to go away completely.

I think really what "particle" means is that "all measurements are quantized". But the probabilities of any given measurement happening flows around as a wave.

For example, "there is a quantity of energy `e` at location `x`" is an observation you could make. The answer to that question has a discrete yes/no answer. The probability of the answer being "yes" flows around like a wave between all the different possible `x` as time progresses.

<comment><USER6> IIRD doesn't the double-slit experiment show it goes through one or the other?

<comment><USER5> No. It goes through both. That's the weird thing that double-slit tells us, especially because it remains true even for "one photon" (i.e. one quantized energy packet arriving somewhere on the detector screen).

<comment><USER4> Wasn't it that particles went through both if you measure at the screen that shows the patterns and they went through one if you measure at the screen with the two slits?

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> The paper is _way_ more nuanced than the abstract suggests. There are huge numbers of papers on the arXiv which try to say, "quantum mechanics is normal and boring, these fools are trying to dress it up as something special because they don't understand probabilities". This paper is more interesting. Here's a quote:

> _In fact, QM is so weird and surprising that even the very esoteric > interpretations, such as the many universes one, can not capture the > subtlety normally associated with quantum paradoxes. For example, theorems > such as the Kochen-Specter theorem [23] (essentially, a generalization of > EPR with three particles) imply that during its quantum evolution no > "classical" variables can fully describe the probabilities of a quantum > system._

<comment><USER8> The following of course is a comment on the quote not on your comment, but no Kochen Specker is not a generalization of EPR to 3 particles. It's easy to come up with a generalization of EPR in 3 particles - just exhibit a 3-party entangled state! (e.g GHZ state). K-S theorem exhibits something a lot more subtle than entanglement known as contextuality. There are examples of systems which have the K-S property but doesn't have any entanglement.

</comment></comment><comment><USER5> A few thoughts:

The Monty Hall comparison is about shifting human knowledge about an underlying system with a definite state. What, then, is the source of the uncertainty in QM in this author's view? It is not our _knowledge_ about the "true state" of things, because of course there _is_ no single true state.

The same could be said about any appeal to "perturbations" from the measurements we make-- in order for a "push" from our measurement instruments be the source of uncertainty, we must explain it in terms of an unknown disturbance making a precise value imprecise (otherwise, the use of "our instruments" as an explanation for "uncertainty" can't be the final tortoise upon which the world stands). Because of the impossibility of a "precise physical value" this explanation doesn't seem satisfactory to me.

It seems the article (like many interpretations) does no better than to say "don't ask" about what lies underneath those probabilities. At best it says "our knowledge is uncertain" but then stops before it says precisely what we are uncertain about.

His points about analogues with classical probability are well taken, but I don't think they suffice to explain or dismiss quantum "weirdness", though it's quite possible I missed the point he was trying to make.

In particular, the article sweeps many-worlds away too quickly, IMO. Many worlds is what we get if we assume that observers are ensembles of particles which can exist in a state of superposition, just like any other ensemble of particles in the universe. "Wavefunction collapse" is what such an observer would expect to see upon becoming entangled with another system, without any additional a priori assumptions. Fundamentally it means that, after measurement, we cannot treat the system and the environment (and the observer therein) as separate-- another way of stating the phenomenon of decoherence.

In other words, I think it is not unparsimonious to assume that "multiple universes" exist, because we already know that ensembles of particles exist in a multitude of states. We simply note that the universe, too, is an ensemble of particles and draw a straightforward conclusion from well-established facts. To me, it seems almost more ontologically bold to _reject_ this.

It is _also_ not unparsimonious to assume that "multiple universes" exist, even after measurement, because delayed-choice eraser demonstrates that wavefunctions can be "un-collapsed"; that is to say re-combined with the other superpositions that Copenhagen supposes "disappear" after measurement. It fact it seems to me a fairly clear refutation of (common presentations of) Copenhagen-- But perhaps the author is on my side about that one.

Either way, this article seems to be a quite thoughtful overview, and I quite agree there's a lot of confusion and woo both within and outside the field.

<comment><USER9> > It is not our knowledge about the "true state" of things, because of course > there is no single true state

That's a biased statement. There is more than one interpretation of QM in which your statement is completely incorrect. The math isn't telling you there is no state, that's a property you've assigned to the math given an interpretation. The paper's analogy to the Monty Hall problem would make perfect sense given another interpretation.</comment></comment>


What's new in Play 2.2 - <AUTHOR> http://www.playframework.com/documentation/2.2.0/Highlights22

<comment><USER2> We're using Play pretty heavily at our startup though not for our customer- facing frontend, that's still in Rails.

What we love about Play:

* Async everything, especially the web service library

* JSON macros

* Scala-based templates

* Integration with Akka

* Support for server-sent events (we use this for cluster monitoring)

What we wish was better:

* JSON deserialization performance isn't as good as raw Jackson yet. (Our PR regarding this is actually in 2.2, should be better now)

* Documentation could be much better, we still have to resort to the API to figure out a lot of stuff

I've been using Play ever since the 2.0-RC days and it's definitely made some huge gains since then. We use Akka very heavily, especially its clustering, and Play works well in conjunction with that though there are still some gotchas lurking about.

Our backend is one big Akka cluster right now. We've had a few hiccups but overall it's been a hugely enjoyable experience.

<comment><USER3> What I never understood is why they embrace rendering templates at the server. Is it simply a matter of "because we can and it's nice for the people that want to use it", or is there a real real reason why pushing raw HTML via AJAX request is better?

I always thought the status quo in the web development world was to use a framework like Backbone.JS to communicate with your backend and use a client- side template engine to render the templates.

<comment><USER4> We push HTML through AJAX to keep all of our templating centralized and consistent.

For a while we used templates for the container page, and then backbone and js templating for certain elements on the page. It can become the 2013 equivalent of spaghetti code if you're not careful.

Now, with HTML via AJAX, you have a clear separation of concerns. For example: the designer doesn't need a dev to make an HTML change, and the dev knows that there will be one place that controls how pages are rendered.

</comment></comment></comment><comment><USER5> For those that have some experience using Play with both Java and Scala, which Play variant do you enjoy working with the most? It sounds like there are some API difference between the Java and Scala versions and I'm curious whether those differences are a factor in deciding whether to go Java or Scala with Play. I'm a long time Java developer, envious of Ruby, interested in Scala for its potential in being a hybrid of the two.

<comment><USER6> With Play 2.0 in Java, there's more verbosity (though nothing like any J2EE framework) in using Java and lack of syntactical sugar features as well as functional programming features (which are widely used in parts like JSON for Play). Also, you don't get the benefits of such things as optional parameters in Java.

Don't get me wrong, the Java version of it is going to be better than any other Java web framework you ever encountered most likely (especially if everything else one tried was based in part on J2EE/JSP since Play has none of those and no XML bs config). However, you do lose some of the Scala niceties when going that route. You still can still call to Scala bits of the API in Java and templates themselves are all Scala (Lift templates), but it's still not quite the same.

If using something like Intellij, you can still mix and match bits of Scala and Java in the same project (but not within the same class file) without too much trouble. Not sure how the official Scala IDE that TypeSafe maintains handles that offhand.

<comment><USER7> Excellent summary. A lot of the API's are definitely built scala-first, then adapted for Java. Usually this isn't too bad, but it can cause some headaches around things like the logger interfaces, etc.

We run a fairly complex java system in the same process as play (similar to an in-process database) for performance reasons, so given the amount of code already in java and not having the time to learn scala, java interop, AND build in the web bindings, we went the Java route.

It's definitely easier to use than something like Spring if you're approaching both for the first time.

<comment><USER8> It's not that it's "Scala adapted to Java", but more like a choice to do async and functional programming even in Java. That makes stuff a bit verbose sometimes because to pass a function you have to pass an anonymous class.

That will become better with Java 8 and lambdas without having to break compatibility with older Java versions (they will still use anonymous classes).

</comment></comment></comment></comment><comment><USER9> Play is an interesting option if 1. you need async request handling (most people don't), 2. are comfortable with Scala, and 3. don't mind maintaining your own branch of the framework (or can pay for commercial support).

Otherwise there are better options, given the hard to configure and slow build process, bloated artifacts, infrequent releases, missing features (in the Java version) and incomplete/outdated documentation.</comment>


Drawings of Scientists by kids - <AUTHOR> http://ed.fnal.gov/projects/scientists/ <comment><USER2> I like how for some of them the "before" was a male and "after" was a female-- especially with the girls. There's always an uproar about how there's a distinct lack of women in science and tech, so it's good that this trip helped them alter their ideas about what and _who_ a scientist could be.

We still live in an age, though, where kids can go for a while through school with only hearing about Madame Curie and a few others (Magaret Meade, Jane Goodall, Sally Ride, Mae Jemison, etc.) as women scientists. Not taking anything away from them, but efforts to change that are always nice (both for boys and girls). I can remember being in quiz bowl at that age and knowing that anytime the moderator asked a question mentioning a female scientist, the ladies above were the likely answers.

<comment><USER3> An interesting observation I read about a week or two ago when this first popped up was that not a single boy changed the sex of their prototypical scientist - every one was male - but some of the girls who drew males first did.

<comment><USER4> Of course not. Boys envision themselves as scientists in the future (at least I did), and so they project some of their traits onto the prototype. It wouldn't make sense if I, at 12, said 'I want to be a scientist.' and then all the scientists I drew were women.

</comment></comment></comment><comment><USER5> Some of the drawings make me wonder if the kids were coached towards a specific message...

<http://ed.fnal.gov/projects/scientists/david.html>

<comment><USER6> It's kind of ironic because what kids are taught is that science is objective. Instead of learning that about science, these kids were fed dogma - which is way to common in 'science' these days.

</comment></comment><comment><USER7> I liked the before drawings better, it appears that the kids image of a scientist was replaced by an image if a regular person, that somehow made the drawings more boring. Just check the contrast(this is the best artwork IMO):

<http://ed.fnal.gov/projects/scientists/nick.html>

It appears to me that the second one was done with a lot less enthusiasm.

edit: The feet are drawn sloppier in the second one, also theres less detail in the face, no background, i think the kid just didn't know how to portrait a scientist anymore, so he did a generic person drawing, and since these are boring, he did a sloppy job at it. My 2c.

<comment><USER8> This isn't about _liking_ the drawings - this makes the important distinction to kids that being a scientist doesn't mean complete exclusion from society. If you read the "pre" pictures from a lot of the kids, their perception of scientists was that of the aloof, disconnected, and obsessive. A visit to the lab changed that - and that can only be a good thing.

No matter what, kids (nay, all humans) desire to fit in. You cannot successfully ask them to go down a career path if you're going to be a surefire misfit/loser the entire way.

The fact that they now perceive scientists as normal people with no-so-normal jobs (to quote from one of the kids) is great, and perceptions like this will serve the scientific community a lot better than that of the obsessive maniac.

</comment></comment><comment><USER9> Interesting that the "before" virtually always are chemists _in the lab_ , wearing a white lab coat and playing with some liquid, usually in a conic beaker. Aside from the "normal person" angle, it's interesting that the prototypical scientist is never a physicist or a field biologist, much less something as exotic as a computer scientist.

<comment><USER10> Computer science largely falls under the old dictum, "if it has the word 'science' in the name it isn't one".

<comment><USER11> Yes and no. While computer science research tend to overlap with other domains of study, there are many avenues of study that fall souly within it, Encryption, algorithms, discovery and application of probabilistic and logical laws. Just because you mostly hear about computer scientists running off and being programmers, dose not mean there is not serious research going on.

<comment><USER12> Be careful not to confuse science with pure mathematics.

<comment> william-newman The math in computer science may not be much like the usual idea of science, but neither is it what people ordinarily mean when they say "pure mathematics." It's much more nearly "applied mathematics," like statistics or signal processing or control theory: more likely to be interested in, e.g., the development of wavelets than in a proof of the Poincare conjecture.

Maybe it would've been more logical if the applied math end of the CS field had ended up with an applied-math-y name comparable to "statistics", e.g. "algorithmics" or "algorithmic analysis," and much of the rest of the CS field had ended up "software engineering" or "computer engineering" or "computational engineering" or "information system engineering" by analogy with "electrical engineering." But naming of technical fields is not necessarily systematically logical, sometimes because of old idiosyncratic reasons to avoid ambiguity with other pursuits: "astronomy" vs. "astrology," anyone?

<comment><USER12> Software engineering may be (currently) part of CS, but theoretical CS is more than just applied statistics. The halting problem, one of the most famous undecidable problems, is pure math and is CS. Lambda calculus is CS and is pure math.

</comment></comment></comment></comment></comment></comment><comment><USER13> Nick and Pat were sitting next to ea. other during the "after" session and collaborating :)

<http://ed.fnal.gov/projects/scientists/pat.html>

<http://ed.fnal.gov/projects/scientists/nick.html>

<comment><USER14> I have a feeling that's a guy they met. Maybe a guide or speaker. Other common features were a man with a striped shirt, and possibly a woman who talked about her extramuros life.

All of these have the same beard: <http://ed.fnal.gov/projects/scientists/pat.html> <http://ed.fnal.gov/projects/scientists/nick.html> <http://ed.fnal.gov/projects/scientists/jesse.html> <http://ed.fnal.gov/projects/scientists/michael.html> <http://ed.fnal.gov/projects/scientists/david.html> <http://ed.fnal.gov/projects/scientists/kevin.html> <http://ed.fnal.gov/projects/scientists/matt.html> <http://ed.fnal.gov/projects/scientists/amanda.html> <http://ed.fnal.gov/projects/scientists/betsy.html>

And these the shirt: <http://ed.fnal.gov/projects/scientists/amanda.html> <http://ed.fnal.gov/projects/scientists/betsy.html> <http://ed.fnal.gov/projects/scientists/jeffrey.html> <http://ed.fnal.gov/projects/scientists/kyle.html> <http://ed.fnal.gov/projects/scientists/james.html>

</comment></comment><comment><USER15> Wait, so now I can't wear functional coats and glasses anymore while making discoveries? I have to care about _fashion_ now? Well damn it.

</comment><comment><USER16> I'd defintely be more motivated to do science as a kid imagining that it was all about blowing things up.

Also, this misses the fact that society just doesn't give too much funding for people doing the type of science that goes on at fermilab. The people that those kids saw were generally those that made it.

There are tons of people that study to be scientists and then end up not making the cut and having to spend the time afterwards working a science job like any other, often without much of the initial passion and curiosity.

Thats not to say that it might be better to (as a society) push people to learn about how the world works, than about something like buisness. At least science gives you some training in thinking.

</comment><comment><USER17> Wow, this is great. I love the quote "Scientists live in their own world and the rest of society puts them there."

</comment><comment><USER18> I call hoax on these drawings.

Look at them and notice how every drawing focuses heavily on the buttons on the shirts and coats. Plus the body sizes are very similar from drawing to drawing. This seems outside the level of probability for a sample of drawings this small. I highly suspect that all of the drawings were drawn by one adult trying to make it look like students drew them.

<comment><USER19> People who haven't learnt to draw (and I'd include all the children in this except possibly Nick and Matt) tend to draw symbols instead of accurate representations. So, what's the symbol for a scientist? A lab coat. What's the symbol for a lab coat? A white coat shape, with buttons down the front.

The children are about ten years old, right? So, despite their lack of skill in seeing, they have the dexterity to draw what they want to draw, and so you'd expect them to draw similar body sizes, in approximately the right proportion (except for the eyes which we tend to perceive as 1/3 of the way from the top, when in fact they are the midpoint.)

</comment></comment><comment><USER20> "The stereotype gives the impression of a geek with glasses or someone who is bald. Actually, they are just people who ask and answer questions."

Nice!

</comment><comment><USER21> This looks very staged. I can't help feeling the children we're given strong guidance in what to write/say in their after pictures.

</comment><comment><USER22> Fantastic to see some of the mystic being taken out.

Next up: engineers! (No, we don't all fix cars or build bridges… ;))

<comment><USER4> stereotypically, engineers design cars- they don't fix them. Someone who fixes cars is called a mechanic.

Of course, modern bouts of sprucing up job title names (my favorite is 'sanitation engineer') means that mechanics can throw stones at me and demand I take that back. I liked the real names better. It's easier to tell people I worked as a bag boy than a 'courtesy clerk'.

<comment><USER22> Unfortunately it depends where you live. In Australia they're the ones who fix cars.

Does the US have a requirement that engineers are engineers (qualified engineers that is) ala claiming one is an attorney?

</comment></comment></comment><comment><USER21> These kids are pretty terrible artists. Seventh grade is old too, these kids are like 12-13?

<comment><USER23> Gee, thanks, Maddox[1]. ;-)

[1] - (WARNING: Not safe for work.) <http://www.thebestpageintheuniverse.net/c.cgi?u=irule>

</comment></comment><comment><USER24> "... Things that may change the world someday. Maybe not today, maybe not tomorrow."

Well said.

</comment><comment><USER25> I love how the after is regularly "normal people with exciting jobs". I hope these kids become scientists :D

<comment><USER26> That actually disappoint me - that the quest for scientific understanding is being demoted to being just a job and not a vocation. To me a scientist will never really be someone who just does science for their job (no true [scottish] scientist would do that!!) - indeed a scientist needn't work as a scientist IMO.

</comment></comment><comment><USER27> I wanted to be a scientist. :-(

<comment><USER28> What's stopping you?

<comment><USER27> I couldn't get a degree.

</comment></comment></comment><comment><USER29> This REALLY makes me wonder which I'd want to be: <http://ed.fnal.gov/projects/scientists/dans.html>

I love the effort, mystery and imagination that went into the first one. Would I want to be a guy that inspires that, or would I want to be the guy that inspires the normal "scientist" in the next drawing?

The first one brings about a sense of awe for these brilliant people that come up with fantastic answers to really difficult questions, while the second one reminds us that even the scientists are humans, and have a social life and enjoy themselves.

Both have their pros and cons.

</comment><comment><USER30> Andy depicts some pretty badass scientists.

<comment><USER10> Link: <http://ed.fnal.gov/projects/scientists/andy.html></comment></comment>


The Art of the Start (by Guy Kawasaki) - <AUTHOR> http://www.lovemytool.com/blog/2007/10/art-of-start.html I never get tired watching this.  Please enjoy. <comment><USER2> I have a dozen business books (only the best) on the shelf, available at all times. This is one of them:

[http://www.amazon.com/Art-Start-Time-Tested-Battle- Hardened-...](http://www.amazon.com/Art-Start-Time-Tested-Battle-Hardened- Starting/dp/1591840562/ref=pd_bbs_sr_1/104-2045170-5755933?ie=UTF8&s=books&qid=1193402956&sr=8-1)

(I especially like one of his 2 word phrases: "Make Meaning")

<comment><USER3> I've read the first half of it but I have mixed feelings about it. Yes, the advice is sound but the tone is dry; it lacks enthusiasm. The Bootstrapper's Bible by Seth Godin (and, generally, everything Seth writes or talks about) is much better.

</comment></comment><comment><AUTHOR> I think Guy's message is not unique. But his passion certainly is.

\--Denny--

</comment><comment><USER4> I enjoy the autoerotic blog title.</comment>


OpenSnitch is a GNU/Linux port of the Little Snitch application firewall - <AUTHOR> https://github.com/evilsocket/opensnitch <comment><USER3> Little Snitch is one of my favorite apps in the world, and it's one of the very first things I install on any new Mac.

For those unfamiliar, it monitors and restricts _outbound_ connections that your applications are trying to make. For example, you might be working away and suddenly get a popup saying:

"Chrome is making an outbound TCP connection to adserver.trackallusers.com, port 9876. Do you want to:

\- Allow or Deny the connection...

\- To all hosts in the domain trackallusers.com, that specific hostname, or that specific IP address, or all hosts everywhere...

\- On this port or any port...

\- Protocol TCP...

\- Once, or for the next 15 minutes / 1 hour / 2 hours / until I reboot / forever"

...and it will postpone making that connection until you answer. You can set defaults for that popup according to your own preferences, for instance to block by domain name instead of hostname so that "server432.example.com" and "server592.example.com" don't have to be managed separately.

When you first run Little Snitch, it's a bit overwhelming. Safari and Chrome want to talk to all kinds of things on TCP/80 and 443, so you pretty quickly say they're allowed to make any 80 or 443 connection they want without further pestering you. Soon you have a good coverage of your apps' normal behaviors, and that's where it really shines. For instance, suppose your text editor commonly talks to "updateserver.example.com" to check for app updates. But this morning, it's suddenly trying to chat with "exfiltrator.badhost.ru". Uhh, maybe you want to block that and see what's going on.

And my earlier Chrome example isn't an exaggeration. It's surprising how many websites want to connect to ad or tracking servers on nonstandard ports. I actually appreciate that a lot because those connections stick out like sore thumbs and I can permanently deny them.

Sorry if this reads like an ad pitch for Little Snitch. I'm not associated with them, but I'm a very, very happy customer. I'm very happy to see something like it becoming available for my friends using Linux is awesome.

<comment><USER4> Using Little Snitch, and seeing the amount of phoning-home Chrome was doing was my "straw that broke the camels back". It tipped me over the edge: drove me back to Linux, Duck Duck Go, NextDNS (I'm not confident enough to "roll my own), turning everything off on my phone (location services, search helpers etc), and not using software that checks for updates or does the least amount of telemetry (I went from VSCode to Emacs)... favoring anything that doesn't track/use cdns/anything by default: whatever is vaguely usable (no matter how annoying) and tracks the least, wins.

I could block it all with Little Snitch - but it's a technical solution to a political problem. I miss a lot of the convenience, and I miss a lot of the slickness/lovely UIs... but Lil' Snitch taught me that that's the price!

<comment><USER5> I found the same thing with little snitch and Firefox. Now I block all the mozilla domains using little snitch and update firefox using Safari.

Related, people also complain about Microsoft phoning home, but Apple does the same thing. (Not that apple is as blatant a jerk as microsoft)

<comment><USER6> Add Google to the list. It is unfortunate that not even one of these companies can differentiate from the others on this practice. They each assume that the user gives them a free pass to make automatic outbound connections, where no consent from the user is required, for whatever purpose they deem "necessary".

</comment></comment></comment></comment><comment><USER7> This is neat, but it seems strange to call it a "port" of a closed source proprietary commercial product. It doesn't actually seem to be related beyond also being a firewall with a UI that kinda imitates Little Snitch.

I think a better term might be "clone"?

<comment><USER8> This is correct. This is not a port. I wouldn't even call it a clone. It's more like "inspired by."

It's just a Hyperbolic Headline.

<comment><USER9> > _It 's just a Hyperbolic Headline._

Maybe, but it's effective. I instantly know what it does instead of trying ascertain what makes Yet Another Linux Firewall different from the rest.

<comment><USER10> Then call it a "recreation" of Little Snitch or something.

Calling it a "port" is completely inaccurate and misleading. I clicked on this thread thinking the Little Snitch developers must be involved somehow.

And If I were the Little Snitch devs, I'd be more than a little annoyed.

</comment></comment></comment></comment><comment><USER11> Software like this seem like snakeoil to me. They often rely on process paths to identify applications, but that can be easily bypassed by using a reputable/plausible program as a lackey [1], or more sophisticated techniques like process hollowing[2]. Afterwards, they can communicate as the (presumably whitelisted) application. Any host-based rules (if any) can be bypassed by routing internet traffic using "popular" domains (eg. CDNs, social media networks), or by social engineering (eg. triggering a request at the same time as a user action, to make the user think it's something he intended to do).

On unsandboxed platforms, you either trust an application completely, or you don't. Tools like little snitch don't turn dangerous programs into safe ones; they only give you a false sense of security.

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

[2] [https://wikileaks.org/ciav7p1/cms/page_3375167.html](https://wikileaks.org/ciav7p1/cms/page_3375167.html)

<comment><USER12> An application can also repeatedly ask for permissions, flooding the user with (little snitch or whatever) popups until they gave up and disable it just to be able to use their computer again.

<comment><USER10> Which would tell the user the app is malevolent.

</comment></comment></comment><comment><USER13> Be careful with using Little Snitch etc.:

'Predictably, online discussions about problems with app translocation and Little Snitch usually recommend stripping quarantine flags, and from what I can see, this has become quite widespread practice. Yet – just as in the blog article – no one seems to be concerned that what they are doing is bypassing macOS's primary security defences.'

[https://eclecticlight.co/2020/01/26/last-week-on-my-mac- when...](https://eclecticlight.co/2020/01/26/last-week-on-my-mac-when-more- security-subverts-security/)

</comment><comment><USER14> I believe the project may be dead -- [https://github.com/evilsocket/opensnitch/issues/259](https://github.com/evilsocket/opensnitch/issues/259) \-- but I see there has been some activity since then.

<comment><USER15> Many of the PRs have been added here, plus some other ideas and improvements: [https://github.com/gustavo-iniguez- goya/opensnitch](https://github.com/gustavo-iniguez-goya/opensnitch)

</comment></comment><comment><USER16> One feature opensnitch has (and I have not seen mentioned here) is that you can run the filter on one device e.g. your openwrt router, and the GUI on your laptop; this is a nice feature that no other "personal" firewall (including the original LittleSnitch) provides - filtering for your iPad and smart tv as well!

</comment><comment><USER17> Fun fact: in macOS Little Snitch if you create a separate profile for your VPN interface (as specified with the goal to allow certain apps/traffic only when the VPN is up), circumventing the VPN it is as easy as:

        curl --interface en0 ifconfig.co

In other words, no firewall rules are applied to actually block traffic on the non-VPN interface. _Apps_ are only blocked from accessing the internet when the VPN interface goes _down_.

</comment><comment><USER18> This project is no longer maintained.

[https://github.com/evilsocket/opensnitch/issues/259](https://github.com/evilsocket/opensnitch/issues/259)

<comment><USER19> > _yes, i 'm not working on it anymore and i'm not responding to issues, > because i lost interest and nobody pays me for this ... if this project is > so essential (?), the "Linux community" can fork it and send a PR._

[https://github.com/evilsocket/opensnitch/issues/259#issuecom...](https://github.com/evilsocket/opensnitch/issues/259#issuecomment-498604956)

</comment></comment><comment><USER20> Reminds me of that Windows marvel called Kerio Personal Firewall which allowed to restrict connections for any application, a feature that Linux should have had since forever and is becoming more and more important today. Most Linux FOSS apps may not call home, but closed hosted or emulated ones (through WINE for example) often do.

<comment><USER16> Linux does do that, and has since the Kernel 2.2 or so; In fact, opensnitch is a user mode process thanks to Linux allowing that, whereas windows needed drivers last I checked (win 2000 days, but the network driver model was still the same for win 7 and even later iirc)

<comment><USER21> Windows Filtering Platform also has a user mode component.

<comment><USER16> That's good to know.

Can it divert, modify and delay packets? Or just have a set of rules for go/no-go?

<comment><USER21> Not sure, as I never used it. The filter engine runs in user space and several behaviors can be implemented as COM instances.

[https://docs.microsoft.com/en- us/windows/win32/fwp/windows-f...](https://docs.microsoft.com/en- us/windows/win32/fwp/windows-filtering-platform-architecture-overview)

</comment></comment></comment></comment></comment><comment><USER22> I always wondered what the windows equivalent was, knowing how well received the app has been for mac users.

<comment><USER23> There's loads of firewall application on Windows: ZoneAlarm, Comodo, Tinywall. Some use their own packets filtering driver, while some are just frontend for Window's built-in firewall.

I used to run these for a while, but it gets annoying real fast with large amount of pop-up. So now I stop using them, and only block known bad IPs using my Pi-hole, allowing everything else.

<comment><USER24> > only block known bad IPs using my Pi-hole

I'd consider this too nit-picky in most contexts, but we're in a thread about connection-blocking software. PiHole is a DNS server. It cannot block IPs or connections.

I'm with you that Little Snitch style filtering gets annoying, but DOH is going to obsolete PiHole / DNS filtering very fast. Can't filter DOH at the gateway without taking on all the other hassles of MITM and can't prevent an app from using whatever DOH server it chooses.

</comment></comment></comment><comment><USER25> i wanted something a bit simpler, so forked and reduced. recently dropped path matching except for display in the visual prompt, simple global firewall, inbound and out. as others noted, path matching is quite janky. never saw a use of libnetfilterqueue before this, so hats off to evilsocket.

[https://github.com/nathants/tinysnitch](https://github.com/nathants/tinysnitch)

</comment><comment><USER26> Great that this exists. I really like the application. Here are some issues:

\- There's a countdown when an unknown outgoing connection is discovered - <USER2> countdown is currently not being stopped when you focus the countdown window. The countdown is only 15 seconds or so - if the countdown is over, it automatically approves the connection.

\- Rules cannot be edited via the python interface. There is one config file per rule though.

\- My computer has been freezing sometimes since I started using it. Not sure but that behavior is related to the tool.

\- Sometimes high cpu usage.

\- It would be great of have some kind of rule-set which can be used as a starting point (optionally).

\- Python interface is slow. Generally not a fan of client applications that are based on Python.

<comment><USER16> All the defaults are configurable (with a config file, not GUI). I have set it to "default deny" and 60 secs.

</comment></comment><comment><USER21> Nice to see it implemented in Go instead of C, one more example of systems software.

</comment><comment><USER27> You could do something like this more efficiently using eBPF I bet. E.g. based on TCPLife [https://github.com/iovisor/bcc/blob/master/tools/tcplife.py](https://github.com/iovisor/bcc/blob/master/tools/tcplife.py)

</comment><comment><USER28> What is the Windows equivalent of this tool?

<comment><USER29> About 15 years ago this kind of "application firewall" used to be really popular on Windows. IIRC, ZoneAlarm and/or Kerio was really popular? And some Antivirus software also included application firewall. Can't vouch for anything particular these days, though, haven't used such thing for a long time.

<comment><USER30> The problem with all such applications on Windows was (and probably still is) that it was too easy to install something that could bypass them at the network layer.

The other issue was that their blocking wasn't fine-grained enough; you couldn't, for example, do what others are describing elsewhere in this thread, allowing an application like firefox to connect to a particular site on a particular port only. You could only allow or block the application itself. You could tell the firewall to explicitly ask you on every request, but of course that wasn't feasible for apps like Internet Explorer. So anything that wanted to get around the firewall could just script Internet Explorer to send its request in the background and you would never see it.

<comment><USER23> > allowing an application like firefox to connect to a particular site on a > particular port only.

Eh, this is such a basic task that even Window's built-in firewall can do it. They just do not make it very obvious in the UI.

<comment><USER30> _> even Window's built-in firewall can do it_

If it can now, that's progress. Windows didn't even have a built-in firewall back when third-party firewalls like ZoneAlarm were popular.

<comment><USER31> Zone Labs released ZoneAlarm in 2000. Microsoft shipped Windows XP with the built-in Internet Connection Firewall (later rebranded to Windows Firewall) in 2001. ZoneAlarm was far more intuitive to use, but there was only one year when Windows did not have a built-in firewall while ZoneAlarm already out.

<comment><USER23> To be fair, Window XP's firewall cannot block Outgoing connection, only Incoming. Vista SP1 and later versions of Windows include a firewall with Outbound blocking.

</comment></comment></comment></comment></comment></comment></comment><comment><USER32> Good show! I use Little Snitch for my computer. It really does rat out the apps that want to tell others about me.

</comment><comment><USER33> Considering that LittleSnitch is a TM, I don't expect this project to last long with the current name...

<comment> _-___________-_ Seems to have lasted quite a while already...

</comment></comment><comment><USER34> I would even pay for a LittleSnitch clone for Linux if it worked nearly as good as LittleSnitch does.

<comment><USER5> it would be nice to have a littlesnitch box for the network

<comment><USER34> There already are enough powerful network-level firewalls available for Linux. The key feature of LittleSnitch mising on Linux is controlling network activities of _particular applications_ on your computer.

<comment><USER35> That's one key feature, but another is the real-time approval UI. I'd love to have that for my other network devices like printers, video game consoles, etc.

If I had that I might even consider off-the-shelf "smart home" stuff but for now I just won't buy any such hardware unless it's 100% local with wires and/or 802.1X support, and even then I don't really trust it.

<comment><USER34> Try Vuurmuur. It's not exactly what you describe but pretty close to that.

</comment></comment></comment></comment></comment><comment><USER12> I've never been a fan of that kind of application.

As a user, it ruins the usability of the operating system. Having alert boxes constantly popping up feels empowering at first, and eventually becomes really annoying and distracting.

As a developer, it breaks your application's expectations and is the root cause of hard to diagnose bug reports. People don't understand what they do and end up breaking software updates (making applications _less_ secure) or other applications features.

<comment><USER36> As a user, you don't have to use it.

As a developer, you kind of have to just accept users taking back their own privacy and work around it.

</comment></comment><comment><USER37> I'm not too familiar with this but would it be possible to spoof the process command to evade any relevant rules?

</comment><comment><USER38> Neat, really liked the idea of lil snitch.

Is the UI a python web app or a Qt desktop app? There's references to both in the readme

<comment><USER39> I think it's a python Qt app.

There is also an open issue for tracking a replacement UI in Go

</comment></comment><comment><USER40> Looking for something similar but on windows, suggestions?

</comment><comment><USER41> Finally</comment>


Google and the Customer Service Myth - <AUTHOR>

I think this deserves its own discussion as it isn't _directly_ related to the Google reorg.
As far as I can tell Google never received any complaints on their _customer service_ until the release of the Nexus One. It seems like tech journalists everywhere immediately pounced on Google's poor customer service for the device, despite the hardware being produced by HTC and the network being provided by T-Mobile.  Since then, people seem to have latched onto the zeitgeist and extended the label to Google Apps, Gmail, and even core monetary products like AdWords/AdSense which I would argue do have sufficient customer support.
I don't fully understand why we, the generally technocratic crowd on HN, are doing this.  Google, like every company, has finite resources, so the more they focus on customer support, the less focused they become on polishing & innovating. They have a pattern of taking an everyday product (like an email client) and making it so commonsense/easy-to-use that it no longer needs customer support. I assume this is why Gmail was in beta for so long.  It was simply a disclaimer slapped on a fully-developed product that there wasn't going to be reps standing by to take your calls.  It's almost as if they're betting that things like a word processor are becoming so quotidian that the product won't need to be supported; a bet I would not take them up on.
I almost expect these sort of criticisms when I'm reading something like _Wired_, but I would think HN would have different priorities when it comes to customer service.  Think about the last time you downloaded a piece of software; did you chose to download the stable version, the beta, or _the nightlies_?  In other words, when given the choice would you choose a technically superior product or one that is better supported? <comment><USER2> Depends on what I going to use it for. Nightlies in a trial virtual machine, beta on my backup machine, stable on my workstation and long term support in my business. Business oriented products like Google merchants and Google checkout do not give you a direct way to talk to someone at google. That is inexcusable in my book.

</comment><comment><USER3> seems you haven't use google at all my friend, google is not just a search engine, but they do have many other products. products like google checkout and merchant generate millions of revenue for Google, but google never care to provide satisfactory customer support, read google checkout forums, you will find hundreds of frustrated buyers and sellers. plus android market place, when you have transaction dispute, that means a nightmare, auto generated reply and countless hours of waiting's to get a answer... no! that's not the way you deal with money.</comment>


Clojure core.async and Go: A Code Comparison - <AUTHOR> http://blog.drewolson.org/blog/2013/07/04/clojure-core-dot-async-and-go-a-code-comparison/ <comment><USER2> This is very cool and intressting. I have to think about something to do with core.async.

This is also a good example why macros are just awesome. Go is a language design to work well with goroutins and channels, but the clojure code looks just as good and readable. You could simply not have such idiomatic use of these concepts without macros.

Or am I wrong, can a flexible language like scala or python be extended to look as good for that usecase? I dont know enougth of the tricks scala people use, I cant juge if it is possible.

<comment><USER3> >but the clojure code looks just as good and readable.

But don't mistake this for having the same runtime characteristics- For what its worth the Computer Language Benchmarks Game shows Go as generally being faster, using much less memory and less code.

[http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=clojure&data=u64q)

<comment><USER2> That is true. I have not looked at the much of the clojure code and non of the go code but both probebly are written in a very unidiomitic style that one does normally not use.

Also with clojure, the actual timeconsuming calculations can be made with java and that should be at least as fast as go (with a bit more memory).

So all in all I value the architectural things much more then pure speed. Go simply has a diffrent target then Clojure.

<comment><USER4> > I have not looked at the much of the clojure code and non of the go code

:-)

> can be made with java

Would that be idiomatic Clojure? :-)

<comment><USER2> > Would that be idiomatic Clojure? :-)

Yes it would. Clojure is design with that idea in mind, make it connect really closly to java so that you can interop with no overhead.

</comment></comment></comment></comment></comment><comment><USER5> Are the first two examples equivalent? In the go version, an anonymous function is being declared and then called with the value of the outer 'i'. In the clojure version, it appears that the value of 'i' is part of the closure for that function.

The go version does what it does to avoid a race condition, because the goroutines are being spun up in the background and it's highly likely that it will take longer to spin up at least one of them than it will to finish the loop, so without it you'd likely get output of all nines.

If the clojure version doesn't have that problem, then I think it's a somewhat telling indication of how it's actually working.

TL/DR: The Go version has to work around the race condition because the runtime is doing things "right", is core.async?

<comment><USER6> The i is scoped differently in clojure than in golang so it doesn't have the same potential pitfall. I think golang people consider their scoping here a mistake (and have tooling to check it?).

<comment><USER7> C# had the exact same pitfall and it was recognised years ago. It's unfortunate that it made it in to Go.

<comment><USER8> Did they introduce a language solution for it in C#?

<comment><USER9> C# 5.0 is changing the behavior of the loop variable to be logically inside the loop [0].

[0] [https://news.ycombinator.com/item?id=3477629](https://news.ycombinator.com/item?id=3477629)

</comment></comment></comment></comment></comment><comment><USER6> Are the clojure threads actually lightweight? Thread/sleep is blocking so you'd need to occupy 10 threads right? If you wanted to sleep without blocking a real thread would you use an executor service to write to a channel after delay and block on that?

<comment><AUTHOR> Author here.

From what I've read/seen, the go blocks are lightweight thread-like processes multiplexed onto a thread pool. You may be correct about using Thread/sleep, ideally I would have used (timeout ...) and then pulled off the channel. However, I didn't want to introduce the concept of channels too early in the post, so I felt Thread/sleep worked as a compromise.

<comment><USER10> Yeah, Thread/sleep isn't quite what you want here:

(time (let [c (chan), n 1000] (dotimes [i n] (go (Thread/sleep 50) (>! c i))) (dotimes [i n] (<!! c))))

"Elapsed time: 8412.25733 msecs"

(defmacro gosleep [millis] `(<! (timeout ~millis)))

(time (let [c (chan), n 1000] (dotimes [i n] (go (gosleep 50) (>! c i))) (dotimes [i n] (<!! c))))

"Elapsed time: 91.278469 msecs"

ETA: for comparison, here's what happens if you actually make 1000 system threads:

(time (let [c (chan) n 1000] (dotimes [i n] (thread (Thread/sleep 50) (>!! c i))) (dotimes [i n] (<!! c))))

"Elapsed time: 4183.669835 msecs"

<comment><AUTHOR> Thanks (and thanks to pron). I've updated the post to include a warning against using Thread/sleep in go blocks for "real" code.

<comment><USER10> I feel silly though that this is the one thing I've commented on, so:

This is an awesome post, thanks for it ^_^

</comment></comment></comment></comment></comment><comment><USER11> Small bug irrelevant to the main point of the article: The very last golang example has a leak. If the timeout does occur, main will exit after a timeout and the spawned go routine will hang on the channel push.

I think the easiest fix is to make the channel buffered. "make(chan string)" => "make(chan string, 1)" Not sure if there is a more idiomatic golang way to accomplish this.

<comment><USER12> Once main exits the program does as well, so all other goroutines will be terminated.

<comment><USER11> True. Leaks don't matter for programs that exit immediately. I was pointing it out because it is often relevant when using the timeout pattern.

</comment></comment></comment><comment><USER13> By the way, you can use (dotimes [i 100]) in place of (doseq [i (range 100)]).

</comment><comment><USER14> Quick question for anyone here familiar with core.async:

Would it be possible (and if so what would be the simplest way) to implement something like Python's generators and `yield` statement in Clojure using core.async? I'm thinking something like:

        (defn range [n]
          (generator
            (loop [i 0]
              (yield i)
              (when (< i n)
                (recur (inc i)))

        (let [generator (range 5)]
          (generator) ;; => 0
          (generator) ;; => 1
          ;; etc
          )

<comment><USER15> I dunno, but I can do it in go :-P

      func generator(values ...interface{}) func() interface{} {
        c := make(chan interface{}, len(values))
        for _, v := range values {
          c <- v
        }
        return func() interface{} { return <-c }
      }

<comment><USER16> "The problem with using a goroutine as a generator is that if you abandon it, it will not get garbage collected."

It's also slow.

[https://groups.google.com/forum/#!topic/golang- nuts/v6m86sTR...](https://groups.google.com/forum/#!topic/golang- nuts/v6m86sTRbqA)

<comment><USER15> My design relies on pre-loading the channel's buffer and doesn't use a goroutine.

</comment></comment></comment></comment><comment><USER17> I have never used Go or Clojure, but this is the first time I have heard of Go as being verbose - or is that just in comparison to Clojure?

<comment><USER15> It's the difference between "programmable programming languages" (which the lisps are, as are haskell and ruby) versus "languages for programming in" (exemplified by go and java).

Go code is very terse compared to the general run of "languages for programming in". And if you know the language, you can _just read it_.

On the other hand, you've got some serious digging to do if you want to understand a clojure macro. Metaprogramming like that is seriously brain twisty.

<comment><USER18> _On the other hand, you 've got some serious digging to do if you want to understand a clojure macro. Metaprogramming like that is seriously brain twisty_

I wish this meme would stop. Your "if you know the language, you can just read it" applies just as much here as it does there.

<comment><USER19> I think you can be pretty proficient in writing regular Clojure and still find macros "twisty". Most Clojurians would agree that "The first rule of Macro Club is Dont Write Macros".

<comment><USER18> Well, I wish that meme would stop too. It makes macros sound all freakazoid, when really they're just another technique. The obvious and natural and historically standard guidance is "Don't write a macro when a function will do."

</comment></comment></comment></comment></comment><comment><USER20> This is pretty awesome. I'm waiting on a clojure book in the mail, but this article makes me want to dive in sooner!

Being a Go fan, this definitely draws me to clojure as a language since the other language I've been messing with was racket (a scheme lisp).

</comment><comment><USER21> Thanks for the write up. Definitely good to see core.async and goroutines side by side...

</comment><comment><USER22> Totally off topic, when i see ")))))))" it makes me want to run the other way.

<comment><USER23> I'll add the classic response of "once you let your editor just handle it for you you forget about it entirely". Because, really, truly, when you code in lisp you're just traversing a very simple syntax tree. If you use emacs/paredit you literally stop typing and start using keyboard commands to "descend down the left branch" or "prune upward 4 times" or "delete this entire branch".

<comment><USER24> Seconding emacs and pardedit.

The power of such a simple approach to editing is very hard to grasp (even more so believe) until you've actually tried it yourself.

</comment></comment></comment><comment><USER25> -> is not a valid operator in go.

</comment><comment><USER26> FYI, there's a typo: "it's on yet available" -> "it's NOT yet available"

</comment><comment><USER27> In Go, am I supposed to seed the rand manually? [http://i.imgur.com/Rw5afx9.png](http://i.imgur.com/Rw5afx9.png)

<comment><USER8> Yes. The default seed is 1. You can set your own using something like this:

        rand.Seed(time.Now().UnixNano())

<comment><USER28> or, better yet, use crypto/rand to seed it.</comment></comment></comment>


QML: A Functional Quantum Programming Language written in Haskell - <AUTHOR> http://sneezy.cs.nott.ac.uk/QML/ <comment><USER2> Perhaps there should be a [2008] in the title? It doesn't look to have been updated since then. Still very interesting, though.

</comment><comment><USER3> Weird coincidence, but I remember someone at Cambridge (Christian Steinruecken, [http://www.siski.de/~chris/](http://www.siski.de/~chris/)) did his undergraduate dissertation on a Quantum ML. Sadly all the links I can find to it are dead now :(</comment>


Ask HN: GRE Subject Test Math - <AUTHOR>

Has anyone on here studied for the Math GRE.  If so, any suggestion of material to study from or what to focus on. Thanks. <comment><USER2> Yes. It's super easy- a 780 is 90th percentile, and an 800 is 94th percentile.

The best thing you really can do are practice tests. Just to warn you though, the Kaplan etc. pre-tests are actually much more difficult than their regular practice tests, and the regular practice tests are more difficult than the regular exam.

This way, you will always do better on the actual exam than on the practice tests, and this will make you believe that studying helped, which is actually doesn't.

The only accurate measure of how well you'll do are the practice tests given to you by the actual GRE people, and you'll get a disk of those a month or so before your exam, in the mail.

<comment><USER3> Are you sure you're talking about the maths subject GRE? Not the regular math section on the standard GRE?

<comment><USER2> I'm not sure at all. You should have said it was the subject GRE in the original post! I was talking about the section on the regular GRE.

I took the biology subject GRE, and tanked it. So I can't be much help here.

</comment></comment></comment><comment><USER4> The main thing that you might not have at your fingertips is basic abstract algebra (groups, rings, fields). I'm assuming you know ODE, PDE, linear algebra and other things from an engineering centric education.

</comment><comment><USER3> Brush up on your calc.</comment>


Microsoft, This Is the One Gift You Should Give to the World - <AUTHOR> http://fullstack.info/microsoft-give-this-one-gift-to-the-world/

<comment><USER2> Good one. I fully agree. Microsoft biggest mistake was not to implement the silence auto-update from IE8 or even earlier (IE6?), as Google did since their very first Chrome version. Imagine what whould happen if there was no auto- update in all Chrome/Firefox browsers! it was a disaster! we (developers) would have to check our code under 50-60 browsers! Now said "thank you Google", forget about it, and think what would happend if Explorer 6 (and above) had this little feature... Wow!!

</comment><comment><USER3> Great post! I wish they would do it though. I really doubt. Unfortunately we're stuck with IE 8 for at least (as you said) the next 2 years.</comment>