The Husband-And-Wife Team Behind the Web's Most Infuriating Outdoor Retailer - <AUTHOR> http://www.outsideonline.com/2051821/123-mountain-infuriating-gear-retailer <comment><USER2> Can't find an item anywhere else, yet one place claims to have dozens in their warehouse? You can almost rest assured that this one place isn't a special unicorn that has items no one else has. What you can reliably bet on is that there's some scamming going on somewhere in the process. I can't tell you how it's going to go, but at some point the company is going to behave dishonestly.

Take these guys as an example: [http://www.abesofmaine.com](http://www.abesofmaine.com). Abe's _used_ to be good. Then Abe got out of the business, and someone else snapped up the name. That someone did not share ol' Abe's ethics. Did you go to the link? Pick any random item on that site, I'll just about guarantee they don't have it. Oh, they'll have something _similar_ that they'll try to sell you using the textbook definition of bait-and-switch. They'll tell you it's the same thing, just a different version, or whatever. Read online reviews, and you'll get the impression that their business plan must consist of one phrase: "bait-and- switch". (I use Abe's as example because I tried to buy the last of the high- end Samsung plasma TVs from them, thinking they were still the old Abe's. They had them in stock, at a not-outrageous price. Oops, no they didn't.)

If you're going to spend $1000 on a jacket, check online reviews of the vendor, and use a credit card that backs you up when you dispute the charge (Amex comes to mind here; your Visa might offer the same, or it might not).

<comment><USER3> While it is smart to take precautions, it still doesn't change the fact that the operation is nothing but fraud, and the people behind should go to jail.

<comment><USER2> I was not arguing that the two are mutually exclusive.

</comment></comment></comment><comment><USER4> Having been through this with a different online retailer, I learned that not shipping goods in a reasonable time frame is an FTC violation. The state attorney general will almost certainly be able to prosecute successfully if facts are as presented and supported by written documents. In my case, the evidence I provided of a retailer not shipping product (and tracking down other scammed customers through online complaints) resulted in a conviction. Now, collecting damages is a different problem and unlikely because the criminals will skip town if they are smart. But at least the judgement will end that particular fraud and make it difficult for then to do business elsewhere.

</comment><comment><USER5> And this is why Amazon or REI should remain the preferred option even if the price is higher or the selection isn't as specialized. It's really strange that people would think online shopping is now a universally safe and hassle- free activity just because some reputable merchants do exist.

</comment><comment><USER6> Brings to mind the old saying, which is extra applicable to e-commerce for hard-to-find items: "If it sounds too good to be true, it probably is."

</comment><comment><USER7> Just use a damn credit card so that you have the option to contest the charge. Visa/Mastercard/Amex don't fuck around with this shit.

<comment><USER8> It mentions in the article that 123Mountain sent a credit-card chargeback to collections against one of their customers.

<comment><USER9> How exactly does that work? I thought the credit card company was the final arbiter of whether the charge was valid or not? If they decide it's not, can a collection agency really enter the fray?

<comment><USER10> Credit card chargebacks don't trump contract law. If you establish a contract with someone to pay X and you don't pay X then they could either sue you or send a collections agency after you...

For most businesses if a customer conducts a chargeback even if they believe they're in the "right" they rarely pursue it due to bad PR and that the cost to pursue it may be more than the amount they're pursuing.

</comment></comment></comment></comment><comment><USER11> A year ago I almost ordered a pair of skis from 123mountain. They claimed to have them in stock when almost all other retailers did not. Fortunately I did some research before submitting the order and figured out they were likely scammers.</comment>


Show HN: Play, pause and discover newsletters with a single click - <AUTHOR> http://lettr.cc

<comment><AUTHOR> I had the trouble of an overflowing inbox caused from newsletters I received during holidays at the beginning of this summer. So I build lettr.cc to pause all my newsletters at the tip of my finger. You now can play, pause and discover newsletters with a single click too.

[http://lettr.cc](http://lettr.cc)

I still have trouble with some newsletters. Does anyone know how to handle e-mail encodings in detail?

I have some bugs with mails that cannot be saved correctly to my database. The HTML-String stops at the equal sign.</comment>


Mozilla's Gary Kovacs to step down as CEO - <AUTHOR> https://blog.mozilla.org/blog/2013/04/10/gearing-up-for-the-next-chapter/ <comment><USER2> Whoever takes charge, I hope he/she keeps Mozilla going in the same direction it has been in the recent past, because the work coming out of that company has been nothing short of amazing in my opinion.

Basically, Mozilla, don't change, you're awesome.

<comment><USER3> Mozilla's "phoenix" legacy is alive and well. I have been very skeptical of Mozilla even very recently as Firefox's many performance problems seemed insurmountable. But here I am after many years of using Chrome typing in this box using Firefox. I also hope they don't change direction. They're on fire and rising once again.

<comment><USER4> Agreed. I've noticed some rather nice performance improvements over the last six months, and, like you, I've switched back to FF from Chrome.

<comment><USER5> I'm guessing the computer you're running FF on has a solid-state drive; amiright ?

added: my reason for asking is that I run FF (release update channel) and I genuinely wonder whether it would be more responsive if it weren't for my slow hard drive. (in particular, I am hypothesizing that every time I visit a new page, its URL gets committed to disk.) was not trying to slam FF; please don't downvote me!

<comment><USER3> It's more than performance, they've also picked up must have features like opening up just closed tabs (cmd+shift+t), and cmd+9 to go to last tab, private windows (used to be all of firefox went private), quick updates.

<comment><USER6> Reopening a closed tab via Ctrl/Cmd+Shift+T has been a longtime feature of Firefox, since at least early 2007.

<comment><USER3> Oh, whoops. Thanks for correcting me!

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I gotta agree with napoleoncomplex - Mozilla has truly hit its stride in recent years and for my money is an example of the corporation of tomorrow - code literate and transparent, yet still kicking arse and taking names

Edit: even corporations of tomorrow will not be immune to politics it seems - rereading the post and blog makes it sound much more like a Eich/Baker coup than a well planned transition. It will be very odd to have him stay on the board - two ex-CEOs on your board makes for a lot of looking up not down for the next one

<comment><USER8> Perhaps I'm overly skeptical, but I have a hard time envisioning them as a "corporation of tomorrow" when, AFAIK/naively assume, they exist (as a corporation that can pay salaries) merely because Google dumps $x00 millions into their lap every year.

To me, this is less "how companies of tomorrow can run", and more like a bunch of techies who hit the jackpot and so can have fun building whatever technology they want.

(Which is awesome, I'm just saying I think Mozilla has a pretty unique situation.)

<comment><USER7> Unique now, commonplace one day.

I really think we are seeing a shift in organisations - one comparable to that experienced after the in enticing of printing press in 1451. Europe went from a literacy rate of 2% to one of 20+ in a hundred years, and suddenly the trading companies and churches and governments were staffed with people who could read and write - and that changed everything. Literate companies out competed the hell of their illiterate counterparts. And the renanissance saw new forms of company, new trading horizons, enabled in part thanks to, well, letters.

Mozilla is an example of this new company - it is staffed by the code-literate and it is out-competing Nokia, Samsung, Microsoft and holding its own against google/chrome/android who are themselves arguably built of the same DNA

Code literacy throughout the company is important but it then demands other things - remote working is probably the biggest thing - it does enable hiring the best in the world, yes, but it makes transparency of decision making so much more natural that it will most likely become a default.

I think we shall see companies be I ing more open in their working practises, in their internal processes and probably in their balance sheets.

For the best part of a generation _at least_ code literate people are going to be in massive demand as companies like Mozilla show that coding is a massive force multiplier for any company in any industry. And that is not merely going to be higher wages - when the force multiplier is big enough it will simply reshape the corporation around itself.

Mozilla does amusingly also show that the politics of human relations will never go away, but there is a elephant in the room now, and it's not going away till long after we retire - and coping with the impact of that elephant will be the defining characteristic of the next twenty years of organisational and intentstional change.

Software is not eating the world like tigers do - it is eating the world like oceans erode cliffs - re shaping the shoreline and the tides.

<comment><USER9> I really like your Utopia but it is missing many things in my opinion. Mozilla is a luxury afforded by Google finance wise. There are much darker futures ahead as well. The entire rise of the Company over the State is rather scary.

Arguably the most successful software company (Apple) is a poster child of using open software to its closed advantage.

Software literacy is also highly divisive. It highly rewards the literates but punishes the rest. Because of that it is very important that people use it for ideas that are not just profit.

We really need more models like Mozilla, GNU, or Craigslist.

<comment><USER7> I think the "Google finances Mozilla out of kindness of their hearts" meme is dealt with here - they have millions and soon to be billions of eyeballs on that google default page. Whatever Google pays is a market rate.

As for the rest, yes illiteracy does count against the illiterate - I think that is a public policy issue. The company vs the state? Historically speaking the one with the army tends to win. Yes regulation is important to ensure companies deliver social value - we have seen that in finance, but that is not a programming issue - back to public policy

As for being open and doing good - yes laudable aims, and I suspect that like now, companies that are more open, more socially beneficial will have the edge of goodwill - but right now the force multiplier of code literacy trumps all.

Edit: I guess I am saying, the force multiplier is so big, that relying on normal market operations to deliver an optimal social good (ie utopia) is a little foolish - we need enlightened governments with perfect regulatory touch to be in tune globally with all the challenges facing the human race.

We're boned.

</comment></comment></comment></comment></comment><comment><USER10> I heard that he resigned because Rust won't support tail call optimizations.

<comment><USER11> Well, how could he face the board after that?

<comment><USER12> He would need to unwind the stack

</comment></comment></comment><comment><USER13> Kovacs didn't really have any public visibility during his tenure. But Mozilla has been doing great, so I assume at a minimum he "just" ran things, and didn't ruin them, which by my calculus is high praise for any imported CEO, let alone one coming into an unusual organization from a very different background. Well done!

</comment><comment><AUTHOR> It's a bummer, not sure why this happened. I liked Gary, and saw him as the right man to shepherd Firefox OS from conception to production.

Searching for a new CEO is a huge distraction, particularly at this crucial time when they're trying to prove a major pivot and work out commercial deals with device makers.

I'm sending positive vibes to my former colleagues!

<comment><USER14> OK, can someone explain this 'pivot'?

I'm typing this into a laptop running Kubuntu (in my kitchen) which is based on a mainframe operating system (I used to talk to a PDP11 via teletype half a lifetime ago).

Won't mobile phones be running Unix soon as well?

<comment><USER15> Aren't they already? What's iOS? Android?

<comment><USER14> Exactly my point. Is this 'pivot' basically the provision of a fat finger friendly interface to existing technology?

PS: I'm not _against_ this, I'd really love to be able to dock a phone and use it for desktop tasks with a 1080p monitor and proper keyboard. Sort of the Rob Pike approach.

<http://rob.pike.usesthis.com/>

</comment></comment></comment></comment><comment><USER16> I'm curious as to why google continues to be a important revenue stream for mozilla, despite having 'chrome' itself. Why can't google stop being lovvy dovey with mozilla?

<comment><USER17> because microsoft would love for that google box in the upper right to turn into a bing box.

<comment><USER16> Ahh, I see! Clever answer. Now I know, why they share revenue.

</comment></comment></comment><comment><USER18> It took til 2010 for them to realize that the future is mobile?! Why would we be looking to Mozilla for leadership on anything?

iPhone came out in 2007, one could argue that mobile was growing fast even before the iPhone. By 2010 Android was a huge thing too. So, what took Mozilla 3 years to figure out about mobile exactly? Even Opera seemed to see mobile as a huge deal long before 2010.

<comment><USER19> Open source needs near-commodity hardware with open specs and kernel source (mostly). Otherwise the hardware vendor uses its secrets to build a proprietary software stack.

We had Minimo, MicroB, etc. before 2010, for all the good it did. Were you paying attention? Did you see any open source smartphone winners back then? I did not.

Android did help flatten and uplift the smartphone space, and make it open. Qualcomm helped too. Kudos to those two!

/be

<comment><USER20> The Facebook "phone" approach is interesting: take over the phone to such a degree that it delivers a FB "experience". No dependencies of the Evil Triangle of the cell world: Handset mfgr, OS provider, Carrier.

Yet Moz apparently is looking to become another OS provider? I'm wondering if they might take the FB approach instead.

FB will succeed now with Android, there appears to be no App Store issues. But my bet they'll also force Apple to cry Uncle! relatively soon. Now THAT would be progress

<comment><USER19> We have a launcher-based approach in the works too. IMHO it's not going to sweep the world, and neither is FB Home.

Strategically, the big problem all such approaches face remains, and it may even get worse as Android matures. Google owns that OS and controls its APIs and rules for extensions.

Anyway, Android 4 doesn't even fit on 256M phones single-core phones, where Firefox OS is entering the market. It is priced out of the launch countries.

So taking a high-end-focused Android-only approach of "[do an FB-Home-like launcher] instead" does not make sense tactically or strategically.

"Also" rather than "instead" can help, we're exploring in the context of Firefox for Android and the Web Runtime based on it -- but it's not exclusively & clearly winning such that we would bet Mozilla on it.

/be

</comment></comment></comment></comment><comment><USER21> never tinker with your lineup when you're leading your division

<comment><USER15> Which division is Mozilla leading, exactly?

</comment></comment><comment><USER22> Did GMoney withdraw affected employee/execs pays/bonuses?

or is he moving to some other company? opera?</comment>


Spinal-Fluid Test Is Found to Predict Alzheimer's - <AUTHOR> http://www.nytimes.com/2010/08/10/health/research/10spinal.html?_r=1 <comment><USER2> An article that begins with "Researchers report that a spinal fluid test can be 100 percent accurate"

does not shine a light too bright on the its author's head.

<comment><USER3> And it continues

      in identifying patients with significant memory loss who
      are on their way to developing Alzheimer's disease.

Yeah, well, I don't think that's very exciting. Seems a bit on the late side; I'd rather know far beforehand, so I can take every possible precaution.

<comment><USER4> _"about a third of people with normal memories [who were tested] had spinal fluid indicating Alzheimer's. Researchers suspect that those people will develop memory problems."_

Give it time - this may well be able to tell you beforehand, but we don't know because the study isn't old enough yet.</comment></comment></comment>


From Please Review My App to Success - <AUTHOR>

Thank you to Hacker News readers. You helped us take an idea 428 days ago (http://news.ycombinator.com/item?id=510656) to market and ink the biggest deal in our space (http://finance.yahoo.com/news/Farmers-Insurance-Deploys-prnews-2031715293.html?x=0&.v=1). You rock. <comment><USER2> <http://news.ycombinator.com/item?id=510656>

[http://finance.yahoo.com/news/Farmers-Insurance-Deploys- prne...](http://finance.yahoo.com/news/Farmers-Insurance-Deploys- prnews-2031715293.html?x=0&.v=1)

</comment><comment><USER3> Congrats!

Which suggestions did you implement? Were those decisions right, in retrospect? Likewise, which did you consider implementing but ignore? Any regrets?

<comment><AUTHOR> \+ Needing a sample document. That was key. We hit the nail on the head in focusing on end-user experience--which is what you saw when signing the first document. But users wouldn't know unless they actually signed something--so this suggestion was on the mark. At the same time asking a user to sign felt like heavy engagement AND was a little hard for a throw-away test of our funnel and feedback here aided our final decision for the successful test. In fact--our current signup is eerily similar to the well-pointed HN comments.

\+ Google Docs integration. Easy to do. Perfect fit. It's tough when looking at all the great SaaS services to partner and integrate with. This and Freshbooks were both great in terms of technical and market fit.

\+ Request for API (we had one, but it wasn't open). Now a big contributor to volume.

\+ Ignorance even in the tech community. This sounds bad to say--but we knew from the outset that the law was changed in 1999 to support online signatures (and in EU/globally in 2000). We assumed a portion of the market would know this--and we were surprised how few did (thanks doubting HN commenters :-). Even in tech--where we regularly agree to our jobs, gigs, Apple purchases and even financial services--all online.

\- Well--it's not a traffic generator as Reddit can be. It's actually USEFUL and actionable comments from peers. It's like our own tech-maker-4chan. :-P

OK--so most of the comments were great and we did implement most of them. I'm trying to find ones we ignored or regretted implementing--ahh--right we did the multi-signing-public documents that were requested. These were for petitions and similar mulit-signer and publicly available documents. This was a great idea and we implemented it and we had zero usage of it.

</comment></comment><comment><USER4> Cool. Please: more success stories on HN!

<comment><USER5> I'll second that. Congrats guys, great to hear this stuff. Inspires all the "dreamers" here including myself ;-)

</comment></comment><comment><USER6> That is excellent news. Congrats.

</comment><comment><USER7> Awesome.</comment>


Free Programming Books - <AUTHOR> http://www.e-booksdirectory.com/programming.php <comment><USER2> Great list of books! How great is this book from 1984 - Creating Adventure Games on Your Computer (<http://www.atariarchives.org/adventure/>)

</comment><comment><USER3> Wait, are these legally uploaded?

<comment><USER4> I saw more than a few recently published O'Reilly books on the list, so I'm guessing not.

EDIT: I noticed that some of the random titles I looked into actually link to the book website. For example: "Real World Haskell" goes to the realworldhaskell.com website. Maybe these are legal after all? A great find indeed if they are.

<comment><USER5> I don't know about RWH PDFs from O'Reilly, but all the content in that book was made available on the author's website.

They did sort of an open editing dealy.

<comment><USER6> I was pretty sure you needed to buy the book before you get that, I tried to follow links for a while to get the RWH pdf before and didn't succeed.

Edit: Seems that they are linking only to the site and not a pdf for RWH so it could well be legal :)

</comment></comment></comment></comment><comment><USER7> I tend to like reading physical books ( _gasp_ ), but some of these are definitely worth scanning through. The E-Books Directory website as a whole has tons of good stuff on other topics, too.

<comment><USER8> It's collections like these that make me sorely tempted to purchase the new Kindle when it's released. Imagine having every one of these books in a portable, readable, display.

</comment></comment><comment><USER9> This list is wicked awesome. I didn't realize RWH or KnR were online!

</comment><comment><USER10> Nice find! Thanks for sharing!</comment>


Turning CO2 to Stone - <AUTHOR> http://sciencebulletin.org/archives/6839.html <comment><USER2> I was curious, so I did the math.

Total worldwide carbon production is 38.2 billion tons per year. Cost to sequester a ton of carbon is between $30 and $150, depending on who you ask and how you do it. Let's assume a middle of the road price of $90/ton. That's $3.438 trillion a year, or about $478 per person. This is roughly equal to the US yearly federal spending, or 3% of the world GDP.

If you somehow pooled together all the world's billionaires and got them to contribute their annual income (roughly $600 billion a year, averaging the past 7 years) to the effort, you could eliminate roughly 20% of carbon produced in the world every year.

\</comment><comment></comment><comment></comment><comment></comment><comment>-

Suddenly, it becomes crystal clear why finding new sequestration methods is incredibly important: if you can get the cost from $160 to $10 per ton, then suddenly all you'd need would be a coalition of half the world's billionaires to stop the main cause of global warming.

Additionally, it's important that people realize that CO2 production is in tons of CO2 per year. Tree offsets are a one-time deal, since when trees die they release CO2, and when new ones are born they absorb that CO2 again. After they've been planted, forests are generally carbon neutral. That's why we can't "just plant trees": we'd have to be continuously planting new trees. The Earth is only 8% arable land, much of which already has stuff on it, or is undesirable for one reason or another. We'd run out of space pretty fast. Trees are good for other reasons: preventing climate change (different from global warming), preserving species diversity, being nice to look at, etc etc.

\</comment><comment></comment><comment></comment><comment></comment><comment>-

Mostly off-topic: when I was looking at estimates of land size, apparently the amount the US has shrunk from 2007 to 2015 (14,000 km2; went from 9,161,120 km2 to 9,147,420 km2) [0] is roughly equivalent to half the area of the Netherlands. Wow.

[0] [http://data.worldbank.org/indicator/AG.LND.TOTL.K2](http://data.worldbank.org/indicator/AG.LND.TOTL.K2)

<comment> semi-extrinsic You also have to remember the costs of capturing CO2, which is best done at the points of emission, and transporting the CO2 to the (usually far away) storage site.

OTOH, the total cost (not just for sequestration) is about $100, maybe a bit more, in most estimates.

For reference, a gallon of gas produces 20 pounds of CO2, so $100/ton equals $1/gallon of gasoline. That's roughly what you'd have to increase gasoline price by to fund CO2 capture, transport and storage. (This neglects that the capture part is neigh-on impossible.)

For electricity, to compensate for the average US CO2 emissions per kWh (~1.2 lbs/kWh), you'd have to increase the price by about 6 cents per kWh.

To do CCS for both gasoline and electricity consumption, the average US family would have to pay (order of magnitude) 1000 x $1 + 12000 x $0.06 = $1720. That would compensate for about half the family's CO2 emissions. The remaining half is dominated by emissions from the food we eat, the stuff we buy and from having fun.

<comment> semi-extrinsic Edit: this should say $1720 per year.

</comment></comment></comment><comment><USER3> The net reaction goes like this: CaSiO3 + CO2 -> CaCO3 + SiO2. Note that the products, silicon dioxide and calcium carbonate, are thermodynamically stable solids.

Crucially, the _activation energy_ for the weathering of silicates to carbonates is low in the presence of water and carbon dioxide. Low enough that it happens spontaneously in nature on exposed rock surfaces. That means that the energy inputs required to reduce atmospheric CO2 via silicate weathering are _much_ lower than a "combustion in reverse" process to turn gaseous CO2 into synthetic coal and bury it.

The other crucial issue is that the _kinetics_ of silicate weathering are tremendously hindered in nature. A freshly fractured basalt surface weathers rapidly for a year or two and then develops a cation-depleted micron scale "rind" that drastically slows the weathering reactions with the rest of the bulk rock.

One way to accelerate the kinetics of silicate weathering is to use more concentrated materials, like the Iceland injection process: nearly pure CO2 plus water will react much faster than natural surface waters exposed to hundreds-of-ppm CO2 in the atmosphere. That works ok if you have a rich stream of CO2 like directly from a power plant's stacks. It won't work for dealing with CO2 already emitted to the atmosphere unless you add a complicated and energetically expensive pre-concentration stage to turn 400 ppm of atmospheric CO2 into a 950,000 ppm CO2 stream you can inject.

The other way to improve the kinetics of silicate weathering is to generate a lot more surface area: crush bulk stone into particles 100 microns or finer. Then there's a lot of fast-reacting extra surface area that can react with CO2 at ambient concentrations. And even the slow weathering to the center of the particle will take maybe a century rather than multiple millennia. (If a century sounds unacceptably slow, I would venture that you have not fully internalized the vast timescales that unaided nature would take to restore the pre-industrial CO2 equilibrium.)

Putting crushed stone particles in near-shore ocean environments may further accelerate weathering by ensuring that natural wave action keeps abrading the rind from particles. Crushed stone rich in magnesium and calcium silicates can also be applied to acid sulfate soils in tropical agriculture. Raising the pH of acid soils increases agricultural productivity by preventing low-pH aluminum toxicity to plants and, unlike sweetening soil with limestone, it sequesters some carbon at the same time. The crushed stone accelerated weathering approach can offset all sorts of CO2 emissions: point or distributed sources, local or distant sources, present or past sources. Finally, it restores the historical pH balance of the oceans as well as getting rid of excess radiative forcing from CO2.

The amounts of stone required to offset historical emissions are vast, but any solution will be vast because the scale of the problem itself is vast. In terms of scalability, simplicity, energetics, and flexibility, I think that accelerated silicate weathering is the best shot at long term restoration of oceanic and atmospheric CO2 concentrations to the pre-industrial baseline.

<comment><USER4> You can see a similar reaction in action when you work with MgO. When preparing starting materials for high P high T experiments on basaltic liquids we typically make mechanical mixtures of simple oxides. MgO is the usual magnesium source, and we always have to calcine the MgO before weighing, as it always takes on CO2 whilst sitting around in the jar. If you put some freshly calcined MgO on some weighing paper on a balance, you can sit there and watch the mass increase as it reacts with CO2 from the air. Alas, too much silica on earth for periclase rocks...

</comment></comment><comment><USER5> It's nice that we're looking to alternative ways to capture and store atmospheric CO2, but at time it also does look like we're working too hard to replicate a system that does that already (and has for a long time): plants.

Or does it mean that the time of planting trees and preserving forests is over now and we have to do it another (most often less efficient) way?

<comment><USER6> The problem with plants is that they do not sequester CO2 permanently; plants grow, die, and decompose, releasing carbon back into the atmosphere. Trees certainly work as a buffer in the sense that carbon in plants is carbon not in the atmosphere, but the amount you could hold is tiny in comparison to the amount that must be sequestered back in order to make a meaningful change in atmospheric and oceanic CO2 composition.

Nonetheless, plants have important benefits, since they alter the local climate by changing the albedo and perspirating. Perspiration of plants in jungles helps to create clouds and regulate humidity, and would help to counteract some of the negative effects of climate change.

<comment><USER7> Isn't soil basically just decomposed organic matter, i.e. a big carbon store? What fraction of a plant's carbon goes into the soil vs. into the air?

<comment><USER8> By burying a plant, you could consciously make that fraction very close to 1. This is a way to fertilize the soil for future plants, and is called hugelkultur.

<comment><USER9> Hugelkulture doesn't involve burying the plants very deeply though - I suspect that it's shallow enough that CO2 that's released during decomposition can easily make it back to the surface.

Most the CO2 from fossil fuels comes from ancient bogs, where plants were prevented from decomposing for long enough that they could eventually turn into materials like coal and petroleum. In essence, they were a result of taking plant matter _out_ of the biosphere, which is sort of the opposite of hugelkultur's goal.

<comment><USER8> Hugelkultur is intended primarily to act as a long-term (5-20 year) fertilization and water absorption mechanism, so that other plants planted on top of the mound grow better.

In that context, you will have a net-positive CO2 absorption (or, a net- negative CO2 release into the atmosphere).

</comment></comment></comment></comment></comment></comment><comment><USER10> We have a great method of storing carbon. It is also technologically simple, very stable, and, would you believe it, completely free! It is called coal. It was already stored in the ground millions of years ago. We just have to not dig it up and burn it.

Also related: oil, peat.

<comment><USER11> No you don't. Those were the results of millions of years. Don't dig it up? Okay, find alternate engery source which can support the way we live today. I am all for reduction (I believe in climate change), but what you said came out very aggressive and counter productive. So noz

<comment><USER10> It's literally very ineffective to keep burning coal, dilute the CO2 to the atmosphere and then fantasize about collecting the 400 ppm ambient later.

It would be easier to replace as much coal as possible with other forms of energy as soon as possible.

<comment><USER11> What makes you think people aren't trying hard enough? It's the fact we haven't come up with an alternative clean source of energy able to sustain the rate of our current consumption. None of the green energy we know of can do that right now (be it too costly, or just not enough power generated).

<comment><USER10> It doesn't have to be a 100% solution at first. The CO2 problem is cumulative. Every ton of coal left unburned is helpful. The earlier those nukes, windmills or solar panels go up, the more coal they displace.

We just had an article on HN where Wyoming banned renewables.

</comment></comment></comment></comment></comment><comment><USER12> Would be very interesting to see nuclear energy sources harnessed to split carbon dioxide into oxygen and carbon or generated into liquid fuels.

I can't wait to see nuclear power plants selling oil and gasoline.

<comment><USER13> I believe the US Navy already have pilot plants for doing this on nuclear- powered aircraft carriers. It's too expensive for land use but much better than shipping across potentially hostile waters.

(Gasoline on US bases in Afghanistan ended up costing something more than $100/USgal, due to being taken overland several thousand miles through Pakistan under armed escort due to occasional Taliban attack.)

</comment></comment><comment><USER14> Not mentioned in these comments is the actual method they cite in capturing the solid CO2. The method involves bubbling CO2 through water and hydrogen sulfide, which is incredibly toxic. Not sure if there's a better way to do it, but their current process is both economically infeasible and dangerous.

<comment><USER15> I don't think 'incredibly toxic' is the best word for a smell most people are familiar with.

Industry uses toxic chemicals all the time. It's not a big deal. This is a chemical that's relatively easy to notice and where prolonged non-acute exposure doesn't have known harms. It's better than most.

</comment></comment><comment><USER16> Just a reminder that the Iceland study result was unexpected, and while it is great that the media is publicizing the results, it would be nice to get additional confirmations before getting really excited.

Having said that, I'm still kind of excited. The basalt flood in Eastern Washington alone is in theory large enough to sequester hundreds of years of US emissions.

</comment><comment><USER17> The best way to reduce emissions of CO2, is to develop sources of energy that are more economical than fossil fuels. If we had the huge surpluses of carbon emissions free energy implied by fusion, we'd be able to slash energy-related carbon emissions to a small fraction of the current level, while also drastically reducing the need to extract hydrocarbons as a chemical feedstocks. Fusion is probably even capable of providing enough energy to sequester excess carbon, beyond emissions.

<comment><USER18> Fusion energy is not free. The cost of building a reactor alone puts the price in the same range as fission. But it's safer, and we have an abundance of fuel for it. So build it to handle base loads, use wind/solar where it makes sense, and use excess production to some meaningful task.

<comment><USER17> _The cost of building a reactor alone puts the price in the same range as fission. But it 's safer, and we have an abundance of fuel for it._

The 2nd sentence will eventually put it in a lower price range than fission.

<comment><USER18> The fuel cost of a fission planet is less than 15% of TCO, so it's not going to be much cheaper, if at all.

</comment></comment></comment></comment><comment><USER19> Scaling up this technique to make it practical is going to be challenging. And it is not enough to simply compute the quantity of carbon not emitted; the full energy-life-cycle of the sequestration needs to be computed as well.

</comment><comment><USER20> There is an entrepreneur I follow on Twitter working on this. Press Release: [http://www.orica.com/News---Media/australian-research- pilot-...](http://www.orica.com/News---Media/australian-research-pilot-plant- turns-co2-into-potential-green-construction-materials#.WIUS6vGGNhE)

</comment><comment><USER21> This made me appreciate how much a few degrees C of climate change matter:

[http://xkcd.com/1732/](http://xkcd.com/1732/)

When the world climate was 4.3 degrees Celsius colder, Boston was covered under a mile-high sheet of ice.

</comment><comment><USER22> I haven't read this, but do people forget basic chemistry? We burn fossil fuels because the process is exothermic -- we extract usable energy from it.

Lithification of CO2 (to make up a word?) is, as far as I know, endothermic. It takes energy to accomplish. On the surface, tending towards counter- productive. Burn fossil fuels to lithify CO2 from burning fossil fuels. Or ramp up nuclear, with all its problems, for the same.

Fusion, sure -- but we are not there, yet.

Unless we look at the sun -- solar and wind. (The largest fusion reactor we are going to have -- up in the sky.)

"Alternative", next-generation, "renewable" energy might allow us to divert part of its potential excess supply to lithification of CO2. At the "tailpipe/smokestack" of conventional production, or even, if we can figure out effective capture, out of the sky.

You want CO2 dealt with, you're going to need to find a way to package it into a stable solid state.

By the way, we already have one worldwide, extant system for lithification of CO2. Based upon solar energy. Photosynthesizing flora.

Trouble is, we are outracing its natural counterbalance while simultaneously reducing and eliminating the flora required for it.

<comment><USER23> This process of trapping CO2 in stone is very, very different from converting CO2 to artificial coal and does not require the same magnitudes of energy (or anywhere near them).

<comment><USER22> Sorry if I wasn't clear. I wasn't referring to trapping CO2. I don't regard it as long term capture, whereas "stonification" \-- actually making the stuff part of a mineral we know has long-term persistence -- is.

</comment></comment></comment><comment><USER24> On a very off-topic note, I wanted to know how human beings can colonize gas giants like Jupiter and Saturn assuming they somehow have access to huge amount of energy. One key problem that would be needed to solve is exactly this: converting gases like CO2 and methane to solids.

<comment><USER25> colonize != terraform

Even if you somehow converted the gasses of Saturn into solids, the mass would result in a level of gravity that would not be survivable. I don't think there's any possibility for colonizing gas giants that doesn't involve something like Bespin or Jetsons floating platforms.

</comment></comment><comment><USER26> The optimal way of storing carbon is as coal.

<comment><USER27> More optimal than diamond?

<comment><USER28> Somewhat, yes. It seems that graphite is a somewhat more relaxed state than carbon's diamond crystal allotrope.

Both burn, and can be vaporized with LOX/acetyline torches:

[http://www.popsci.com/sites/popsci.com/files/styles/medium_1...](http://www.popsci.com/sites/popsci.com/files/styles/medium_1x_/public/import/2013/images/2009/08/diamond3.jpg)

But apparently, over long periods of time, and unless coerced, carbon prefers to be graphite and so, diamonds can decay as such. [0]

[0] [https://en.wikipedia.org/wiki/Material_properties_of_diamond...](https://en.wikipedia.org/wiki/Material_properties_of_diamond#Thermal_stability)

Hence why graphite is generally more plentiful than diamonds.

<comment><USER27> Coal isn't graphite though.

And you're talking about burning, not storage. Coal produces lots of dust and debris. I'm sure diamond would produce some dust at volumes.

[https://www.quora.com/What-is-the-difference-between-coal- an...](https://www.quora.com/What-is-the-difference-between-coal-and-graphite)

Anyway, it's fantasy because I'm fairly confident we're not going to turn CO2 into mountains of diamonds in my lifetime!

</comment></comment></comment></comment><comment><USER29> Question: once this CO2 has been changed into a solid form, will we be able to burn the solids to produce energy?

<comment><USER30> The resulting carbonate minerals can't be burned because they are already completely oxidized, the same way you can't burn water (with oxygen).

Carbonate minerals are a lower energy compound than their reactants, which is good, because it means the reaction will happen spontaneously without an energy input from us (which would probably be too large to make it economical)

</comment></comment><comment><USER31> What about methane, anyone got stuff for that?? It's much more potent of a greenhouse gas than CO2.

<comment><USER32> Just burn it and sell the electricity and freshwater?

Then it becomes 1 CO2.

[http://chemistry.elmhurst.edu/vchembook/511natgascombust.htm...](http://chemistry.elmhurst.edu/vchembook/511natgascombust.html)

<comment><USER33> Plus traces of CO, NOx, carbon particulates, and unburned hydrocarbon.

<comment><USER34> Methane is CH4, if you burn in oxygen then you get CO2 (and some CO potentially as you say) and H2O. Where's the NOx come from?

Can you get particulates burning methane? Long chain hydrocarbons, I can see how that works; but methane seems like it would disperse too easily, unless it's liquid/solid methane you're burning or you're doing it in a very low pressure atmosphere. That's my intuition though, any citations showing significant particulate yield with methane combustion?

<comment><USER33> Any hydrocarbon fuel burning in atmospheric air produces _some_ NOx,and some particulate matter. I should also have mentioned SOx, at least considering that your methane fuel is not going to be chemically pure CH4. Natural gas, in addition to CH4 as the primary component, contains some ethane and propane, plus traces of butane, pentane, hexanes, N2, CO2, and sulfur.

I'm not sure what amounts of pollutants one would consider "significant". Certainly, gas turbines burning methane are comparatively low in pollutants, but even properly functioning automobile engines are extraordinarily low in pollutant emission (just for orientation, I don't consider CO2 "pollution").

[http://www.gasturbine.org/images/thegasturbinesolution.pdf](http://www.gasturbine.org/images/thegasturbinesolution.pdf)

[https://www.enbridgegas.com/assets/docs/Gas%20Analysis%20Vic...](https://www.enbridgegas.com/assets/docs/Gas%20Analysis%20Victoria%20Square%20Stn%20No%2050139%20-%20September%202016.pdf)

<comment><USER34> Thanks for the reply. I'd guess you're always going to get side combustion of existing products in the air, you could probably say "methane combustion produces heavy metals" too in that case as there's a chance that there'll be an atom of a heavy metal floating around the intake air. But it's needs to be noted and practical effects considered.

>gas turbines burning methane are comparatively low in pollutants //

Do they ever burn just methane or do they burn natural gas [that's been somewhat purified]?

I did have a search before posting and found citations claiming natural gas gave significant particulate reduction, as your second citation mentions, ergo the question of whether burning methane made any - it seems primarily to be a factor of burner efficiency, though there's research showing production of fullerenes and nanotubes that probably feeds in here too.

Looking further I found [1] which gives good info, in particular whilst gas:oil is 7:2704 in production of particulates by weight that citation notes that the PM2.5 [small particulates] as opposed to PM10 particulates _may_ be significantly more damaging due to their penetration further in to the respitory system.

[1] [http://www.eia.gov/pub/oil_gas/natural_gas/analysis_publicat...](http://www.eia.gov/pub/oil_gas/natural_gas/analysis_publications/natural_gas_1998_issues_trends/pdf/chapter2.pdf)

</comment></comment></comment></comment></comment></comment><comment> Jean-Philipe I heard there's also a way to turn CO2 into wood.

</comment><comment><USER35> Storing co2 under the sea? Imagine what a leaking well will look like: a giant soda straw injecting c02 directly where it can do the most damage.

Carbon storage may be a stop-gap but, as with "clean coal", is also used as a pr flag to justify continued fossil fuel expansion. With the price of solar dropping, that is where we should focus (and fusion).

<comment><USER3> The point of this article is that the injected CO2 reacts with the rocks to create stable solids, so that it _can 't_ leak even if the physical containment fails after a few years. That is a significant improvement over e.g. schemes to inject CO2 in depleted oil fields, where physical containment failure would indeed undo all the benefits of sequestration.

<comment><USER35> Except for when the pipe breaks, much like every oil-related accident. Pipes +ocean +pressure always creates risks.

<comment><USER36> Except that we control the flow into the pipe and can turn it off in a minute, unlike every oil-related accident.</comment></comment></comment></comment>


Stratus VOS - <AUTHOR> https://en.wikipedia.org/wiki/Stratus_VOS <comment><USER2> Oh man! Stratus was one of my favorite (and first) systems. VOS was I believe the only PL/1 based OS? Had a lot of fun learning PL/1 on them, and the scripting ('command macros') was pretty nice. It was lacking all the _nix tools though. There was eventually a 'C' compiler and _nix OS for Stratus, but IIRC, it never was as stable/mature as VOS.</comment>


Indie game Haunts unable to compile its Go code - <AUTHOR> http://forums.thedailywtf.com/forums/t/27755.aspx <comment><USER3> How is this Go's fault? Just because you can pull code automatically from a remote repository doesn't mean you always should. It seems to me that keeping the entirety of the code necessary to compile a project in a local build directory is a very good idea if you don't want to compile against moving targets.

<comment><USER4> You are correct. Go's remote imports are dangerous for long-term project maintenance, but the feature is still useful for quick, throwaway projects.

Go badly needs two things:

1\. A best practice that dictates that you never import from remote repositories in production, long-term code; the feature is fine for one-offs and experimentation, but the article summarizes only _one_ way this style of work can lead you in to a maintenance world of pain. What happens if the repo you're importing from Github is deleted? What do you do for fresh clones? You're going to end up changing the URL _anyway_. I feel the Go community has kind of glossed over this (and I _like_ Go).

2\. An equivalent of CPAN or PyPI, which you could then import from in concert with a tool to manage those dependencies, a la:

        import (
            "cgan/video/graphics/opengl"
        )

This model works for CPAN, PyPI, and so on for a reason, and that reason is avoiding several of the dependency/merge hells that remote repos can create. CPAN provides Perl a lot, such as distributed testing in a variety of environments. I personally think such a thing is necessary for long-term maintenance of any software project that utilizes third-party libraries. This is one of Google's oversights in Go, because they have an (obviously) different take on third-party code. Here's a good case:

 _Developer A checks out the code clean. Five minutes later, developer B checks out the code clean. In both cases, your "go get" bootstrap script fetches two different commits, because in that five minutes, upstream committed a bug. Developer B cannot build or, worse, can build but has several tests fail for unknown reasons or, even worse, the program no longer functions properly. Developer A has none of those problems. In a world with a CPAN-like, developer B can see that he has 0.9.1 and developer A has 0.9.0, developer B can commit "foo/bar: =0.9.0" to the project's dependency file, then everybody else doesn't suffer the same fate. In the current world, you're either massaging your local fork to keep the new commit out, or any other troublesome, non-scalable approach to this._

Building large software projects against a _repository_ never works. You need tested, versioned, cut releases to build against, not master HEAD. It only takes one bad upstream commit to entirely torpedo your build, and you've now completely removed the ability to qualify a new library version against the rest of your code base. Other people are suggesting "well, maintain your own forks," so you're basically moving merge hell from one place to another. I, personally, have better things to do with my time; I've seen (Java) apps with dozens of dependencies before, and keeping dozens of repositories remotely stable for a team of people will rapidly turn into multiple full-time jobs. Do you want to hire two maintenance monkeys[0] to constantly keep your build green by massaging upstream repositories, or do you want to hire two feature developers? Exactly.

I've started writing a CPAN-like for Go a couple times but I'm always held back by these threads:

[https://groups.google.com/forum/?fromgroups=#!topic/golang-n...](https://groups.google.com/forum/?fromgroups=#!topic/golang- nuts/c-s4_uxamf8)

[https://groups.google.com/forum/?fromgroups=#!topic/golang-n...](https://groups.google.com/forum/?fromgroups=#!topic/golang- nuts/-UG-lF_Ey-o)

The second one highlighting how difficult Go is to package as a language -- my personal opinion is treat Go just like C and distribute binary libraries in libpackage, then the source in libpackage-src. If one message in that thread is true and binaries refuse to compile with different version compilers, I'm troubled about Go long-term.

[0]: I'm not calling all build engineers maintenance monkeys. I'm saying the hypothetical job we just created is a monkey job. I love you, build engineers, you keep me green.

<comment><USER5> You're right that syncing directly with the net is a problem. However, the problem is basically developer education. Go doesn't work like other languages and the consequences aren't well-documented. If you do it right, the process works fine; it's basically how Google works internally.

The basic idea is to commit everything under $GOPATH/src so that you never need to touch the net to reproduce your build. After running "go install" you should check in the third-party code locally, just like any other commit.

Then updating a new third-party library to sync with their trunk is like any other commit: run "go install", test your app, and then commit locally if it works. If it doesn't work, don't commit that version; either wait for them to fix it, sync to the last known good version, or patch it yourself.

If you aren't committing your dependencies then you're doing it wrong.

<comment><USER4> > If you aren't committing your dependencies then you're doing it wrong.

Disagree _strongly_ (and hate absolutes like "doing it wrong"). Their metadata, yes, by all means, commit that. There is absolutely no reason, however, to have the source code for a dependency in my tree, Go or not.

Give me a binary I can link against, or at least the temporary source in a .gitignored location, and let's call it a day. When I want to bump to a new version my commit should be a one-line version bump in a metadata file, not the entirety of the upstream changes as a commit. I've seen a sub-1MLoC project take 10 minutes just to _clone_. Internally! You're telling me you want to add all the LoC and flattened change history of your dependencies in your _repo_? Egads, no thanks! Where do you draw that line? Do you commit glibc?

There's just no reason to store that history unless you are in the business of actively debugging your dependencies and fixing the problems yourself, rather than identifying the issue and rolling back to a previous version after reporting the problem upstream. I guess it's paying your engineers to fix libopenal versus paying your engineers to work on your product; one's a broken shop, the other isn't. Some people will feel it's one, some the other.

<comment><USER5> No really! Go isn't like other languages. You have to think differently. Please try it!

There's no such thing as, say, Maven binary dependencies for Java. If you don't check in the source code for your dependencies, your team member won't get the same version as you have and builds won't be reproducible. You won't be able to go back to a previous version of your app and rebuild it, because the trunk of your dependencies will have changed. By checking in the source code you're avoid a whole lot of hurt.

Checking in source is okay because Go source files are small and the compiler is fast. There isn't a huge third-party ecosystem for Go yet.

<comment><USER4> > There's no such thing as, say, Maven binary dependencies for Java.

I'm saying there should be, but not necessarily the same thing. That's my entire point.

I'm also not a fan of the "you have a dissimilar opinion to mine, so obviously you've never used Go properly" attitude in this thread. One way to read your last is that I've never used Go _at all_ , though I'm giving you the benefit of the doubt and assuming you meant _used Go properly_. Either way, I don't get the condescension of assuming I'm unaware of everything you're explaining to me simply because I have an opinion that is different than yours. Especially since half of your comment is repeating things to me that I said earlier.

<comment><USER5> Maybe it sounds like condescension. I was in the same place at the beginning. No exceptions? No generics? Heresy. How dare you Go people ignore my many years of experience? I wrote a few rants to the mailing list, which were basically ignored.

The reason I assume you haven't used Go much is that your examples of problems with checking stuff in aren't examples of problems happening in Go. It's an analogy with other languages and other environments. Such arguments don't seem to get very far.

Maybe it won't scale and something will have to give. I expect the Go maintainers will find their own solution when it happens, and it won't look like Maven or traditional shared libraries. (If anything, it might be by replacing Git/hg with something that scales better.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> I don't understand the issue, or why it's such a show stopper.

If the original programmer is using git, he should have a complete history of his code. They know the date (or thereabout) when the last version of the code "worked". Revert down to the a commit around that date.

For each dependency, do the same. Pull the dependencies repo down, revert to the last commit that was around the date of the working version, and use a new fork of that repo to get things back to the working state.

One by one, move the dependencies forward, resolving bugs as you go.

<comment><USER7> Maybe they did and it didn't work? You're giving them very little credit.

<comment><USER6> That wouldn't make any sense. Either the code worked at some point, or it didn't.

<comment><USER8> You know, I haven't worked on _that_ much software, and I've run into situations I at first thought impossible often enough that your comment just makes me laugh. :P

Unlikely? Surprising? Insane? Sure. But never call something impossible unless you can not only write down a formal proof for it but also verify your assumptions.

<comment><USER9> Unlikely, I would go with. It's unlikely that it couldn't be done. Based on the level of understanding in that thread, I'm not terribly surprised.

</comment></comment></comment></comment></comment><comment><USER10> Wow, that's awkward.

One of the things I spent a bit of time on when Java was being developed was class management. We had an ongoing discussion about embedding versioning information in class files, creating signatures that could be checked at runtime, and just winging it. Bill Joy was convinced that it was possible to give the class loader the ability to statically analyze a class and determine whether or not it would work with the code that was trying to invoke it. This was when I was first exposed to the idea of creating a digest type 'signature' for a method/class invocation that would encode semantics.

The end result was 'just wing it' of course. This was expedient but didn't advance the state of the art :-)

Go's implementation seems a bit more dangerous. Not the least of which being drive by malware injection attacks on abandoned/poorly administered code repositories. It seems in principle to be no more or less dangerous than something like "apt-get install libcairo-dev ; make" but that would only be true if there was a trusted repository system.

Can someone from Go comment on the ability to create and manage trusted repositories? Should we look for a go 'distro' to build with?

<comment><USER11> When you install a package with `apt-get`, that package can potentially change your system in any way it pleases. Running `go get` will download and compile code, but there is no security risk until you run or use that code without checking it first.

<comment><USER12> You're comparing things that are different. When you install a package with apt-get:

\- it comes from a repository that has been signed by the distributor.

\- the package has been tested and has a good level of integration with the system (ie different distributions may package things differently).

\- depending on the distribution, there may be a commitment to API/ABI stability (ie. Debian backports security fixes most of the time).

That said... running "go get" is very convenient if you control the code repository where you're fetching the code, but it's not a good idea when using 3rd party software that is in active development.

EDIT: formatting

</comment></comment></comment><comment><USER13> Go didn't screw anything over. It sounds like poor version control practices. Although the Go team eschews versioning of dependencies, they do so mainly because they are in control of said dependencies. If you're building software that relies on untrusted source code, do yourself a favor and make a copy of it that is known to work well and use that copy in your build environment.

<comment><USER14> >Go didn't screw anything over.

Erm, yes it did. The civilized world (Java, Ruby, Python, Clojure, Scala, Haskell, OCaml) has version numbers in their dependency management. Albeit out-of-band from the source files (pom.xml, gemfile, requirements.txt, project.clj, sbt, .cabal, OPAM version pinning) but it _does_ work.

Hell with Clojure and Leiningen (the standard choice for dependency mgmt) even the language version is a per project dependency ala:

[org.clojure/clojure "1.5.1"]

So you can still build jars that "just work" even if it's some legacy stuff that you haven't updated to the latest Clojure version yet.

That's not to say Clojure would've helped here - it's a game. And one that's aiming for better graphics - JVM isn't a good idea.

But that doesn't excuse Go's poor package management design that decided being facile and hid complexity of the real problems (changes breaking existing code) was more important than working builds.

The decision to make it facile, weak, and fragile was egregious and very out- of-character with the rest of their design decisions. I think Go can be faulted for failing at their own goals on this particular matter.

<comment><USER15> > Erm, yes it did. The civilized world (Java, Ruby, Python, Clojure, Scala, > Haskell, OCaml) has version numbers in their dependency management.

Go has localised dependencies: you package your code with exactly the versions you need.

> So you can still build jars that "just work" even if it's some legacy stuff > that you haven't updated to the latest Clojure version yet.

And with a Go project, one would have a complete system which 'just works,' complete with all dependencies, regardless of how old those dependencies actually are.

> But that doesn't excuse Go's poor package management design that decided > being facile and hid complexity of the real problems (changes breaking > existing code) was more important than working builds.

Go doesn't do what you think it does (probably not your fault: the article is misleading). It only pulls down updates if you tell it to. It sounds like the developer of the original code was doing the wrong thing, not using GOPATH the way it was designed, not checking his entire source tree—including dependencies—into version control. I could be wrong, of course: it's possible that he really did use it properly but discovered a misfeature I've not yet found.

<comment><USER16> "The developer should have done X!", well, then why doesn't Go just do it by default instead of choosing an approach which has been discarded by pretty much every other modern language/ecosystem?

I think the fact that every Go proponent attacks the developer of the game is one thing which keeps me from using Go. The community seems to be incredibly closed-minded and hostile.

<comment><USER17> This line of reasoning seems to make it hard to suggest that certain things are and aren't idiomatic in different languages without being accused of being closed-minded and hostile. If I read an article claiming that Ruby sucks because of some project where the developer decided to use a Makefile instead of bundler, I would say "the developer should have used bundler!", and you could accuse me of the same hostility you're accusing Go proponents of here. Conventions really do exist for a reason, and really should be followed until you understand them well enough to reject them for a good reason.

<comment><USER16> Amazingly, other communities manage to do that without being so utterly condescending.

<comment><USER17> I'll see your anecdotes with my own; I've had nothing but extremely pleasant interactions with the Go community and think it is much less closed-minded and condescending than most.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> I used go get on the source code and the errors are caused by dependencies on 2 C libraries: opengl and lua. Basically the Go bindings for the C libraries are out of date and/or unmaintained.

Sample output:

        # github.com/runningwild/glop/gos
        /usr/bin/ld: cannot find -lglop
        collect2: error: ld returned 1 exit status
        # github.com/runningwild/opengl/gl
        gl.go:142: cannot use _Ctype_GLint(mapsize) (type C.GLint) as type C.GLsizei in function argument
        gl.go:147: cannot use _Ctype_GLint(mapsize) (type C.GLint) as type C.GLsizei in function argument
        gl.go:152: cannot use _Ctype_GLint(mapsize) (type C.GLint) as type C.GLsizei in function argument
        gl.go:158: cannot use _Ctype_GLenum(internalformat) (type C.GLenum) as type C.GLint in function argument
        gl.go:164: cannot use _Ctype_GLenum(internalformat) (type C.GLenum) as type C.GLint in function argument
        gl.go:170: cannot use _Ctype_GLenum(internalformat) (type C.GLenum) as type C.GLint in function argument

        /usr/bin/ld: Warning: size of symbol `luaX_tokens' changed from 8 in $WORK/github.com/xenith-studios/golua/_obj/lcode.o to 256 in $WORK/github.com/xenith-studios/golua/_obj/llex.o
        /usr/bin/ld: Warning: size of symbol `luaT_typenames' changed from 8 in $WORK/github.com/xenith-studios/golua/_obj/lapi.o to 88 in $WORK/github.com/xenith-studios/golua/_obj/ltm.o
        # github.com/xenith-studios/golua
        /usr/bin/ld: Warning: size of symbol `luaX_tokens' changed from 8 in $WORK/github.com/xenith-studios/golua/_obj/lcode.o to 256 in $WORK/github.com/xenith-studios/golua/_obj/llex.o
        /usr/bin/ld: Warning: size of symbol `luaT_typenames' changed from 8 in $WORK/github.com/xenith-studios/golua/_obj/lapi.o to 88 in $WORK/github.com/xenith-studios/golua/_obj/ltm.o

Seems like a familiar problem that every similar language encounters when using bindings to native code, not just a Go issue.

<comment><USER19> The Lua issue is weird. The bindings are maintained (last update one month ago), and the repo provides its own Lua source files (but the API of minor versions of Lua is stable, so it shouldn't matter).

They should file an issue on GitHub.

<https://github.com/xenith-studios/golua/issues>

</comment></comment><comment><USER20> Or you could fork.

Or you could create a version of your src folder as a github checkout with submodules for each of the things you want to import.

I struggle to see what the issue is. I knew the first time I wrote an import in Go that this was possible, and that as the libraries for Go are relatively young that it is also likely.

My personal preference is just to keep track of changes fairly regularly and not allow much drift. But that's because up until Go1.1 I was following tip, which meant I was already in that habit.

Though it would be nice if ``go get`` could take a revision or branch/tag name.

<comment><USER21> Yeah, this article made my head hurt. It can be summarized as

"Original author didn't localize dependencies, obviously caused problems."

<comment><USER22> I'm a little confused about how this would be an issue in the first place. I mean, surely all the changes are checked into a repository and the working code is on the programmers computer right??? So why doesn't he just share the 'working' code with all of the dependencies if he somehow didn't check in his local copies of the dependencies.

I'm a little suspicious when it is claimed that the original author can't get it to compile. That is just so strange and the simplest explanation was that it was never in a great state anyway.

<comment><USER21> Yeah... it smells a little odd, goes against the general golang development (when you have a dep, it ends up in src and you check in src... so... yeah).

</comment></comment></comment></comment><comment><USER18> I offered to help out on the Haunts game when they had their first round of problems. They had lost the developer who had chosen Go and so were left with no way to continue development. I wrote and offered my help and apparently so did a large number of other people because we were all sent a long questionnaire to fill in with our skills, experience and what we could offer the project. It just seemed like a big barrier to cross simply to offer my volunteer services, so I didn't bother completing it.

In retrospect they were probably being protective of their IPR, but erred on the side of being overprotective and pushing away a few folk that could have helped.

</comment><comment><USER23> This might sound harsh, but...

Maintaining software is hard.

Blaming your own incompetence on a library or an entire language is easy.

I've been guilty of this at times, but when you get down to it, it's your job as a software developer to understand how your software works and how to maintain it well. This doesn't just include the code you write; it includes your tools, third party libraries, and the internals of the language (VM, compiler, etc.). Its not easy, but it's part of the job.

On a more positive note, versioning packages in Go is already possible and is starting to gain momentum. Check out <http://www.gonuts.io/>

<comment><USER7> > it's your job as a software developer to understand how your software works > and how to maintain it well

And it's the job of language (and language ecosystem) developers to make this as straightforward as possible. It's perfectly possible to blame both the author and the language.

</comment></comment><comment><USER15> I've only been writing Go for a short while, but my experience so far is that 'go get' only pulls down updated versions of dependencies if you tell it to, with -u.

The developer should have set up a proper Go tree for his project, prepended it to GOPATH, run 'go get DEPENDENCY1…' (which would have put the complete current source of that dependency into his src directory) and then checked his project tree into his VCS (adhering, of course, to the licenses of his dependencies). Anyone who downloaded his code would have gotten the compatible version of all dependencies from the VCS. Then when he felt it was time to upgrade the dependency, he should have committed his work (and branched in something like git), then run 'go get -u DEPENDENCY1…' to fetch the latest version, which—yes—would break his code's compilation. The next step would be to fix his code to work with the new version, then commit that.

It sounds like the guy was doing something developing his project in his main Go tree, not putting his dependencies into version control, blindly updating dependencies and so forth.

But possibly I missed something.

</comment><comment><USER24> Go pulls down remote repos/libraries locally. If the original developer has any sort of backup of his system from the time the game was working, he will have all of the working code.

If the original developer does not have that but at least hasn't nuked his src directory, he will have all of the working code (but may need to, e.g., git bisect).

<comment><USER23> Yeah exactly. This shit is ridiculous.

</comment></comment><comment><USER25> From now on, remember this anecdote every time you curse at Maven for making dependency management a huge effing hassle unless you publish publicly on version drops to an official repo.

Go's sin here is being permissive. And it's true that _clearly_ the game dev team just... didn't do things right. They were pretty much on a collision course with failure by managing their project's code the way they did. But Go allowed them to get much further along than they otherwise would have.

</comment><comment><USER26> I'm not making any judgements on the project itself, or its dependencies, but I see a lot of people just use code off github (or butbucket, or launchpad) with no regard for the quality of said code. Just because it's on github doesn't mean it's good code, or the maintainer has any idea what they're doing. In general, if I can't trust a project to maintain a stable master branch (or a Go version tag) following best practice guidelines, I'm not going to trust that code in my project without a full review. In that case, I'd fork it (or clone it into another VCS) and work from there.

There are some issues with the way the Go tooling handles dependencies, but I think the minimalist way in which it does is very useful, and easy to build upon. Go uses a distributed dependency system, and you can't give it the same level of trust you give to centralized repositories, like one does with gems, Pypi, NPM, CPAN, and so on.

</comment><comment><USER27> This indie project goofed up, so now they're (probably unintentionally) hurting Go and Kickstarter with more bad publicity. It's going to be information that's hard for the public to properly understand, so it will probably hurt that understanding as well.

</comment><comment><USER28> They claim there is nothing about Go that makes it bad for games, but there certainly is. There are no large, mature game engines for it. If someone was hiring me to write a basic mobile game I could do with a big engine like Cocos2D, and said I couldn't use the engine, I'd probably multiply my time estimate by five.

I've written complex OpenGL ES games from the ground up before, and its a long slog, especially at the end where you you are trying to crank it up to 60 FPS and doing tons of work rewriting it to be high performance.

</comment><comment><USER29> I think everyone here saying "just fork your dependencies" is missing the idea that it's supposed to be an open-source game.

Managing DLL hell may be acceptable to _ship_ a game, but it's not acceptable to _openly develop_ software.

In this case it wasn't even intended to be open-source, which may be why the dev went the route he did, but doing so essentially closed the door on the later option of easily letting the community take over on code development.

There's a reason people codified semantic versioning. Projects like gstreamer take it even further and make the major version part of the library name, even allowing for co-installability of old and new (e.g. gstreamer-0.10 and gstreamer-1.0 can both be installed and used).

<comment><USER27> _> Managing DLL hell may be acceptable to ship a game, but it's not acceptable to openly develop software._

Why not? Having something that compiles and runs is probably a bit of a boon to the development effort.

<comment><USER29> Yes, that's my point.

It's not acceptable to merely "manage" dependency hell as the net result is still unmanageable at OSS scale. You have to essentially eliminate the interplay of "which exact version do I have" with your code, which is why things like semver and soversions (on .ld.so's) try to accomplish.

Being able to have an unknown user download your code and the listed dependencies and have a repeatable build is invaluable for development.

</comment></comment></comment><comment><USER30> I totally agree that packaging and dependency management is Go's weak spot, and I've experienced similar issues. That said, I wouldn't blame this on _golang_ per-se. I have run in to the same issues in Ruby, although versioning is a bit better.

Whenever I see a fast-moving dependency I fork it and use my fork, then integrate upstream changes when appropriate. If you have to do that for _every damn dependency_ I can see that being horrible, though...

<comment><USER21> Why? I can't imagine building a serious product and being dependent on a github repo I don't personally control. It is terror inducing to even consider any real project that would be... even if you are based on a tag or a hash, the author can destroy or rewrite it.

<comment><USER31> Agreed. Also, if your dependency graph starts to get unmanageable, it's usually a sign you've made a mistake somewhere (likely by relying on something else that's poorly designed).

If you keep your system simple and don't rely on too many "kitchen sink" frameworks, then keeping your own source tree of your dependencies isn't that much different from maintaining a local repository of the same code in compiled form (with the added benefit of having the original source available).

</comment></comment></comment><comment><USER32> Hmm, they have issues with dependency handling and 3rd party libraries.

Go doesn't have a gem/pip/cpan/npm/... like ecosystem, instead you import git/mercurial repos directly. This is pretty nice for rapid development and to test things out, but not the right approach for complex long term projects like a game.

The original author of the game missed to include the dependencies into the project and now they are doomed. Put the libs you rely on in your version control, be it as a submodule.

I'm wondering if anybody is working on a package manager for Go libs... That would be great.

<comment><USER33> > I'm wondering if anybody is working on a package manager for Go libs... That > would be great.

@aleksi is: <http://www.gonuts.io/>

</comment></comment><comment><USER34> Seems to me lame excuses from the original developer who made horrible version control decisions and then abandoned ship.

<comment><USER35> It's not even a Go problem, you can be equally stupid by putting "package": "*" in npm's package.json instead of, say, "package": "1.2"

</comment></comment><comment><USER36> IMO this is some sort of clueless scapegoating. Dependency could be an issue in software development but only for large projects. A project with $28k funding and probably 1 or 2 developers, seriously? And no details like lines of code, libraries being used, etc makes it hardly plausible.

<comment><USER37> I agree. I believe is scapegoating too. The guy that wrote the mail had no clue about anything technical, and the other guys that help him explain, didn't really understood what the programmer did and perhaps wasn't even a Go dev. And it seems that the original developer just left and doesn't want anything to do with the game anymore. So...they blame it on the language and 3th party hobby libraries from github because they can't set up the project right. That shit happens on any language even with inhouse built libraries if you put unskilled people to to the job.

</comment></comment><comment><USER38> why would they use go, a language aimed at building scalable web services to build a game is puzzling...I am not sure if people who made that decision actually knows what they are doing. Many open source libs and system-level linux libraries can be installed from git or github repos... that is not news at all. Can't see why people are fighting over such things. O.O

<comment><USER39> Looking at their Kickstarter page, they really could have used anything.

</comment></comment><comment><USER40> This sounds like a problem the community can resolve. Check <http://golang.org/cmd/go/#hdr-Remote_import_path_syntax> \-- anyone can create a Go "repo" by using a <meta> tag in an HTML page.

I don't think it'd be difficult to create a CGAN/GoPI/Gobal/gojars/etc. that provided versioning.

<comment><USER41> That's a good idea. The limitation being that your service can redirect go get to a different repository url, but go will still fetch that repository and check out what it thinks is the best branch for that version of go: one with the name of the current go version, or master. So you'd have to play some tricks to keep a full clone-able repo with master locked at some commit for each version of each library, rather than just one repo per library with tags. I guess there are some ways to do that where the clones share the objects so you aren't wasting space, though so not insurmountable.

<comment><USER40> Space usage doesn't worry me _too_ much. If a "package" is just a set of files, then storing them in some sort of compressed form (.tar.gz) and simply un-tarring them and making the API mimic a git repo with one revision should be fairly straightforward.

</comment></comment></comment><comment><USER36> FYI source code at <https://github.com/mobrulesgames> It seems to me the developers must have been working really hard and the failure is due to that the size of the project is way too large for the two person team. It is unavoidable and the dependency issue is just a symptom.

<comment><USER42> That GitHub page tells me they _did_ clone all of the dependency repos six months when they were trying to recover it.

If the game was finished and working but does not compile anymore, that sounds like a trivial thing for a hardworking developer to fix in a pretty short amount of time.

I've seen much worse when porting games across platforms. This doesn't look even close to "beyond repair".

</comment></comment><comment><USER43> This is ridiculous, there's a correct way to handle this and it's called git submodules. Instead of using go get for non-trivial long-term projects you should just be adding the dependency as a submodule in your git repo and including the files directly. This way you can have your submodule pointing to a specific commit in the upstream repo, you can update it when you want to/need to and all this information is kept track of in version control.

Also, if you want even more control(ie, you want to modify the library you're using in some way), fork it on github and include your fork as a submodule. That way you can patch bugs easily(and send the upstream a pull request) without having to wait for upstream to fix things you know how to fix yourself.

</comment><comment><USER44> This is ridiculous. I have come across numerous projects written in half the languages under the sun that were impossible to build and/or run for various reasons, mainly because the original developer had so much stuff in his environment that it depended on. At least Go has urls to original source repos which is a whole lot better than mysterious binary blobs that noone knows what the hell they do let alone where they came from (but were most likely brittle chunks of Fortran77). And if you modify someone elses code and it gets out of sync...well that's a problem but its not Go's fault.

</comment><comment><USER45> I'm a Go developer using Go for commercial projects in production.

I can tell that the article and its comments is absolutely misleading. Seems that the developer(s) are trying to justify the lack of professionalism and blame language/tools/someone else. In the article I see total misunderstanding of how the Go ecosystem works, strange decisions, obvious failures during development and weird situations like 'original dev cannot compile the code anymore'.

I think an engineer should have a decent understanding of the tools/concepts/... BEFORE starting to use them. Not AFTER some problems occur.

</comment><comment><USER46> The dependency could have easily been avoided by forking the repo which you're using, and using that instead. Obviously the maintainer(s) of the original will be making changes, so wouldn't you want to make sure that if you're distributing the code, you're all on the same version?

> _Why does this matter?_

Maybe I'm not understanding this, but the dependency issue and the issues in this paragraph are not related. Issues like improper syntax? That's not related.

Sounds like bad planning as far as the dependency stuff goes. For everything else, sounds like a distribution issue.

<comment><USER47> Let's say I depend on github/A and github/A depends on github/B. If I fork A, that does not solve the problem. Now I need to fork B and modify import paths in A to resolve my fork. Wouldn't this be a mess in time?

I assume, instedad of forking, it might be possible to import a specific tag, or commit hash from a git repo. If it's possible, it'd solve the backward incompatible change problem but I guess the original author can always delete the github repo.

What is a good way to manage dependencies locally?

<comment><USER46> I hadn't considered the A/B issue, and yeah that can get messy. Importing a specific commit hash to the repo would be great. As far as managing dependencies locally, I couldn't say since I haven't had much experience with Go, but there exists a package manager called "Go Nuts" (see: <http://www.gonuts.io/>). While obviously not widely used, it seems to fix this issue. It's almost like rubygems all over again though.

What I'd like to see is a site similar to this, with a similar tool. Instead of having to upload the package to the site though, you could add a `pkg.json` file (or something similar) with application data. Every time this is committed, the site would automatically check to see if the version has changed, and then index that commit hash as a new version.

This almost sounds fun...

</comment></comment></comment><comment><USER48> It's a good point. I've had it as a worry in the back of my mind for a while now, the 'best' solution for now seems to be linking to your own personal forks of projects you depend on.

<comment><USER49> That's a pretty heavy solution.

<comment><USER50> Sure, but it's also a common solution outside of Go. I write iPhone apps and we have all of our major dependencies forked, because at _some_ point you're going to butt up against the limits of what your lib does. Even just redirecting a git submodule at a later point is a minor brainfuck - <USER2> nowadays we just instinctively fork as soon as we decide to pull it in as a dependency.

What I really want to know is why they chose Go in the first place. Go isn't a game development language and it has little to no support, documentation, or just plain old previous community experience in the gaming context. This feels like the classic software development of putting the technology ahead of the product - using a tool because it's cool, rather than using it because it's the best thing for the job.

It's _all_ about shipping, people. Use whatever you need to you can ship what you want, when you want to, at the quality and reliability you desire.

<comment><USER51> > Sure, but it's also a common solution outside of Go.

In the C and C++ world, yes. Because they lack the software repositories many mainstream languages have.

The problem is that we got used to Maven, Ivy, CPAN, Gems, eggs, NuGet, ...

<comment><USER52> Back when I worked on a large commercial Python project, we did the same thing. All dependencies where on our server and that's the only place we grabbed them from when building a new release.

<comment><USER51> I think the main problem is that we got used to these dependency tools, and many developers coming to Go don't have experience how development was done before they came into existence.

<comment><USER53> Or the fact that many developers look at the previous methods and quite rightly say "That is a hideous method, we have moved on (and IMHO improved) from that, why the hell has a new language reverted to old and busted methods"

As I said in another comment regarding Go. If any company has the ability to create a stable, maintained CPAN / rubygems equivalent for the Go language, it would be Google.

Which just makes the lack of it more jarring (although I see the arguments that Go is designed for Google and may not fit other's ideas of what important features are)

</comment></comment></comment></comment></comment></comment></comment><comment><USER54> I really struggle to understand what is going on here. Wrong usage of a feature isn't tools fault. I saw lots of projects that messed up things with gcc and Make. So can we consider gcc and Make are both broken. Developer should know pros and cons of feature that is about to be used.

Using an unofficial release or development version of a library is always risk. It is not language dependent. Things can always be broken if you don't follow release notes on an actively developed project.

</comment><comment><USER18> It seems that Haunts uses Makefiles to wrap the Go tools so there is some non- standard complexity there. See [https://github.com/losinggeneration/haunts/blob/type_fixes/M...](https://github.com/losinggeneration/haunts/blob/type_fixes/Makefile) which was linked from the 7 month old issue <https://mrg- trac.sourcerepo.com/mrg_Haunts/ticket/34>

</comment><comment><USER55> It's bewildering to see a project that "can't compile" after having $70k+ poured into it. This article sums up this clusterfuck: [http://www.joystiq.com/2012/10/24/haunts-anatomy-of-a- kickst...](http://www.joystiq.com/2012/10/24/haunts-anatomy-of-a-kickstarter- collapse/)

Back on topic, maybe Go should take a page from node's NPM: simple versioned tarballs with isolated dependencies.

</comment><comment><USER56> Wait, so, they were expecting to develop agains an X version, and then after release, when they release the source it will compile easily for all it's users with zero dependencies problems?

I don't see how bashing Go would help these guys out of the hole they are in, same would have happened with any other programming language in a project that uses fast-moving dependencies...

They were making a game, they could have just forked the projects they needed, and build from that, that's the way to do these kind of projects, you stick on a revision, and when there is an update on a dependency, the team should agree to make the upgrade changing all the required source code.

For what they say, the main developer had no idea that the repositories were changing a lot, and he never updated them, so everything was going thru smoothly... I don't see the need to bash Go, neither the main programmer, i just believe he needed more experience to handle the project correctly.

What i don't like is their attitude "nobody can fix this Go garbage code because Go is all wrong"...

</comment><comment><USER23> I love how people jumped all over Go on that thread, without having any idea of what they are talking about.

Gotta love the Internets.

</comment><comment><USER57> It's a poor workman who blames his tools.

</comment><comment><USER58> Wow, how is this Go's fault? Shouldn't it be obvious that one has to be very careful when patching upstream libraries and maintain a forked repository and/or submit patches upstream?

<comment><USER59> Did they have a fork with local changes? The way I read it, they just did

      import "github.com/go-gl/opengl/gl"

and then at some point the go-gl project (which they don't manage) made incompatible changes that broke their build. Presumably there is some version of go-gl they could build against (which happened to be cached on their developer's machine), but they don't know which one because there's no version or tag in that string.

<comment><USER58> But this is what software development is all about anyways... it's like complaining that they have to type a lot in order to get _anything_ working. My whining detector went off.

</comment></comment></comment><comment><USER60> I'm willing to bet that any Go programmer worth their salt not tired of the project can get it running if it were simply build dependency version issues.

I'll take a stab at it this weekend (if I have time).

For the curious, here is their repo: <https://github.com/runningwild/haunts>

</comment><comment><USER37> I bet tomorrow morning half of people here will download and backup their 3th party libraries :). And perhaps even burn them on a CD (just to be safe)

</comment><comment><USER61> Death march project fail, blame the tools.

</comment><comment><USER62> From the Kickstarter trailer: "If we don't get this game out by Halloween, something will claim our souls".

</comment><comment><USER63> Question: Could we give Open Source git repos permalinks?

<comment><USER7> What do you think the hashes are for? :-)

<comment><USER63> Well, I know. But seems people need to be told about it in a different manner. Not every product fails due to the product itself. Sometimes the failure is due to how it is referred to. If we had something like _permalink this repo_ , then people who be moved to used that.

</comment></comment></comment><comment><USER64> This project was haunted from the get-go.

</comment><comment><USER65> Go fuck itself?</comment>


Simple website builder Weebly (YC W07) goes international - <AUTHOR> http://venturebeat.com/2010/02/24/simple-website-builder-weebly-goes-international/

<comment><USER2> congrats on the sick growth guys. The choice of languages surprised me. Chinese specifically - do you expect these users to buy pro accounts? or is that simply about market share?

</comment><comment><USER3> Will you guys be offering customer support in all 4 languages? How much is that going to cost?

<comment><USER4> this is really the big issue; translating sites are easy. Providing ongoing support in 5 languages, means having separate dedicated support teams. I'm interested to see how they handle this.

</comment></comment><comment><USER5> my personal website is hosted on weebly. Jimdo.com has lot of better features though and excellent site designing widgets in browser. I personally tried to build same thing and then understood making these simple things for end user is PITA and demanding on my (limited) skillset

</comment><comment><USER6> I really dig that a company with only 3 employees can achieve all this. Well done guys.

<comment><USER7> Their linkedin page says they have 18 employees.

<comment><USER6> That makes more sense :-)

<comment><AUTHOR> Anybody that wants to can add themselves as an employee of Weebly on LinkedIn, so no, we don't have 18 employees :)

We actually have 7 full-time.</comment></comment></comment></comment>


Homelessness in Downtown LA exposed in dashcam footage - <AUTHOR> http://www.dailymail.co.uk/news/article-5214593/Christmas-Day-2017-Downtown-Los-Angeles.html <comment><USER2> Waze took me through this recently. It's shocking. And abrupt as in turning a corner to drive through hundreds of people in the street. Couldn't see the pavement from all the trash.

A completely different world.

<comment><USER3> Stayed on 5th street at a very nice hotel. Couldn't believe how different 6th street and up look (Fashion district / Downtown). Hundreds of people in "shanti towns", shopping carts full of bottles, rubbish, tents, oil-drum fires.</comment></comment>


San Diego: join us for SD Hacker News meetup #32 (Fri 8/31) - <AUTHOR> http://anyvite.com/sk4hrk8kqc

<comment><USER2> Thanks Trey for organizing the meetup. It will be my first ever Hacker News meetup.

<comment><AUTHOR> Just picking up where the past organizers left off.

See you at the meetup!

</comment></comment><comment><USER3> Thanks for organizing, Trey!

<comment><AUTHOR> Thanks for organizing so much in the past.

</comment></comment><comment><USER4> someone should tell linuxcon about this meetup.

<http://events.linuxfoundation.org/events/linuxcon>

<comment><USER5> I am at CloudOpen (colocated with LinuxCon) and will make every effort to get to the SDHN meetup if I can muster the energy after the con. But, everyone knows at SDHN, I am almost certain to show up at Obrien's by 9:30p.

</comment></comment><comment><USER6> Hi guys, I'm new. Never been to a meeting; thus, this will be my first. What address and time are we supposed to meet at?

<comment><AUTHOR> It says on the Anyvite invitation that is linked. Part 1 is at Pangea Bakery (Kerny Mesa) at 7:30pm and Part 2 is at O'Brien's bar across the street at 9:30pm. See you at the meetup.</comment></comment>