Ask HN: Recommend an Online Encyclopedia for Home-Schooling - <AUTHOR>

My kids are a bit to young for unfettered access to Wikipedia. ("Daddy what's 'fisting'[1]?")<p>Does anyone have any experience with any online Encyclopedias? Please and thanks.<p>-----<p>[1]: http://en.wikipedia.org/wiki/Fisting/  <-- NSFW <comment><USER2> Why not allow unfettered access to Wikipedia? What are you afraid will happen? That your kids will grow up with a positive attitude about sex and some knowledge about what it entails? Or are you worried that your kids will want to talk with you about a topic you find difficult or embarrassing to discuss? Or what? Kid's interests are normally age appropriate although they may mimic or mirror parental interests and behavior to gain your approval.

Many kids are sexually active at a fairly early age. The average age of menarche in the US is 13.5 years; the average age of first intercourse is 15 years. Breast development, which usually indicates the beginning of puberty, starts in about 10% of US white females at age seven. Kids are beginning sexual development earlier and earlier. Seems to me that an informed sex positive kid is better equipped to deal with life than one who is kept in the dark.

<comment><AUTHOR> Even _if_ I agreed it's still an issue of timing. Would you agree that somethings are age appropriate and other things are not?

<comment><USER2> I think that kids should be allowed, even encouraged, to explore _anything_ that captures their interest, particularly when the thing being explored exists in the world of ideas. It's really hard to break your arm or get a concussion from reading a book, stumbling on an idea, or surfing the web. I'd even go so far as to extend that permission to their parents (and other older people).

In the more physical realm, I also think exploration should be encouraged, but there some adult supervision makes sense, but only to mitigate the possibility of significant injuries. You want to teach your kids how to explore the physical world safely and cautiously, and do it without restricting their imagination and actions. Most scientists and engineers will tell you about the many things they did as a kid that were dangerous and educational. We owe it to our kids to let them learn about things on their own.

Kids interests change over time; "age appropriate" means, for me, that the materials are things which most kids of a particular age are known to be interested in and that the content is of such a level that the target audience can understand it. For example, it's age appropriate to talk about mathematical concepts such as counting, sequences, and sets to a preschool child, but it's probably not appropriate to do it with a formal set of axioms, theorems, and proofs. Kids are pretty good at self-selecting their own materials.

<comment><AUTHOR> "I think that kids should be allowed, even encouraged, to explore _anything_ that captures their interest..." anything?! Really?

Ok, rhetorically speaking; What about race-hate propaganda? How about a book that praises the joys of religious intolerance? Might we want to see books on these topics held in reserve for an older more discerning audience?

Now a real question: So fisting is ok at what age-range then? Don't miss the direct question. I am asking for an age-range so that you won't say something like, "well.. that er... depends on the child". Pick a range when fisting is, in your opinion, a healthy endeavor for _male children_.

<comment><USER2> Your "real question" is a change of topic. The age a particular sexual practice becomes a healthy endeavor depends upon many factors, including, for example, the attitude parents have about their own and their child's sexuality. But this thread is about knowledge and not about doing.

We are talking about whether access to information about fisting on Wikipedia should be blocked or not. I argue that if the child is interested, male or female, they should be able to learn what the term means. I also think that kids should be able to see for themselves race-hate propaganda, religious intolerance, naked people, and pornography if they are interested. It's our responsibility, as parents, to help them to look critically at the information they find on the web, on TV, and elsewhere. And we need to be open and willing to answer their questions in a clear, non-judgmental fashion.

It is also our responsibility to teach kids about their bodies and their sexuality and what kinds of endeavors are healthy and what are dangerous. I believe that an informed person, regardless of age, is better off than one who has no information or misinformation.

<comment><AUTHOR> So you're not gonna answer my question?

<comment><USER2> No. I am not going to answer the question and escalate a debate over whether certain information should be kept from children into a debate on what is an appropriate age for children (or adults) to engage in particular sexual practices.

<comment><AUTHOR> And information _never_ informs action in your opinion?

<comment><USER2> Not in this case. Would you block access to entries about murder? robbery? guns? knives? Halloween (the work of the devil to some people)? Santa Claus (who might be discovered not to exist)? or any of the myriad of topics where some might feel information informs action.

<comment><AUTHOR> So if information does not inform action -- if you where to be consistent -- then you would be against spending money for sex education in the public schools, correct?

'Cause no matter how much information on sex you gave the kids it wouldn't inform their actions.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER3> Well, most home schoolers start with the landmark 1911 11th edition of the Encyclopædia Britannica because it's very good and now public domain: [http://en.wikipedia.org/wiki/Encyclop%C3%A6dia_Britannica_El...](http://en.wikipedia.org/wiki/Encyclop%C3%A6dia_Britannica_Eleventh_Edition)

If the above doesn't provide adequate versions I know of one that's available on CDs for installing on your computer(s).

This one does however I gather violate the "no access to 'learning how to blow up the world'" or at least yourself requirement. And of course it doesn't cover anything since then.

<comment><AUTHOR> Sent it on to the wife. Thanks! (Though it not having anything since 1911 is a severe limitation.)

</comment></comment><comment><USER4> Unfortunately, the only way right now [1] (at least, that I know of) is to use a blocker like Dan's Guradian [2] or similar, to block sexual term filled sites.

You could also use search engines like DuckDuckGo and Google to search articles, as those engines block sexually related terms.

__________

1: <http://en.wikipedia.org/wiki/Wikipedia:CENSOR> Obvious link. ;)

2: <http://dansguardian.org/> Unsure if it can block Wikipedia

<comment><AUTHOR> I use a white list so blocking is not the issue. I need to find a first class encyclopedia to complement our curriculum.

And thanks for the wiki link. Illuminating...

</comment></comment><comment><USER5> Off the top of my head, I don't know of something like that. I went to my own website to see if I had something like that listed and I don't seem to. I do have some links to educational resources (though I really don't maintain the site these days so there are probably a lot of dead links). I imagine a good homeschool list would be able to give you a lot more links to kid-safe websites than HN can. Though a quick google turns up this list: <http://ivyjoy.com/rayne/kidssearch.html>

(FWIW, I basically did give my homeschooled sons unfettered access to the web with two rules: 1) no porn and 2) no learning how to blow up the world.)

FYI: I copied and pasted the wikipedia URL you posted and it tells me something totally safe for work:

"Wikipedia does not have an article with this exact name. Please search for Fisting/ in Wikipedia to check for alternative titles or spellings. Start the Fisting/ article, using the Article Wizard if you wish, or add a request for it. Search for "Fisting/" in existing articles...."

<comment><AUTHOR> thank you very much. you are correct in the home schooling sites giving recommendations but I wanted something first class and HN is the place I thing of when thinking first class websites.

oh and as to NSFW: leave off the final '/'</comment></comment>


Mary Meeker's Latest Stunning Presentation About The State Of The Web - <AUTHOR> http://www.businessinsider.com/mary-meekers-latest-incredibly-insightful-presentation-about-the-state-of-the-web-2012-5#-1

<comment><USER2> dupe</comment>


Musicians, tune your keyboards: playing in a laptop orchestra - <AUTHOR> http://arstechnica.com/gadgets/news/2011/07/laptop-orchestras-what-are-they-and-where-did-they-come-from.ars

<comment><USER2> Kraftwerk and STS9 have been doin this for years</comment>


Ask HN: Has the GMail graph been published? - <AUTHOR>

When GMail launched, it was invitation-only, and there was a limited amount of invites to give away. My immediate thought was that Google was building a graph of all users, and that the nodes were being kept artificially small in purpose for some reason.
The other immediate thought was the prevention of spam agents using GMail for their purposes.
Sampling users a few at a time, starting with trusted users, also enabled the creation of a profile of a "good user", to further prevent spammers from using GMail--their profile would be very different.
Is there any publicly available graph of GMail or other email systems, quantifying the connectivity of the users (I expect a power law)? And any analysis of GMail "good" and "bad" users? <comment><USER2> I don't know the answer to your question, but I _do_ know that one of your assumptions is incorrect. The reason for making gmail invitation-only was NOT to build a graph and keep nodes artificially small. Rather, the goal was to provide a way of ramping up usage in a controlled manner. By throttling the number of invites given out, Google could control the rate at which new people signed up for the service and make sure that there were always enough servers available to handle the load so the experience for existing users wasn't degraded.

They are currently doing the exact same thing with accounts for Google Wave. In this case, there is an added benefit: unless you know someone else who has a wave account, having one is of absolutely no use because you have no one to communicate with.

<comment><AUTHOR> I didn't think about the scaling-up issues. Makes a lot of sense.</comment></comment>


Show HN: Pushing all your emails to Facebook timeline - <AUTHOR> http://die.socialisten.at/2012/07/behind-the-scenes-timeline-based-emails-for-improving-internal-communication/

<comment><USER2> I can't imagine anything more horrific than publishing my emails to facebook.

</comment><comment><USER3> To be honest, I stopped reading after the first paragraph because the text- shadow hurts my eyes.

<comment><USER4> I stopped after few words. This is unreadable.

<comment><USER5> seems that the text-shadow is disabled now ...

</comment></comment></comment><comment><USER6> I saw this in the PMD fb group; it's a cool hack, it would be even better to hook this up to your code repository / bug tracking / CI, etc. :)

facebook story every time someone breaks a build? fuck yeah.

<comment><USER7> It's definitely a new spin on the whole 'punish the developer that broke the build' addons like retaliation.py:

[http://www.papercut.com/blog/chris/2011/08/19/who-broke- the-...](http://www.papercut.com/blog/chris/2011/08/19/who-broke-the-build/)

</comment></comment><comment><AUTHOR> Disclaimer: I am posting the article on behalf of my camp-colleague jollife[1] who had troubles publishing on HN.

1: <http://news.ycombinator.org/user?id=jollife>

<comment><USER8> "your our"?

<comment><AUTHOR> Oops. Thanks :)

</comment></comment></comment><comment><USER9> I'm glad we inspired you. I love the way you limited your Open Graph actions.

They made an FB group a developer of their app, and didn't approve the actions. Then only people in the group can see the OG actions.

</comment><comment><USER10> awesome idea, and makes you wonder how else you could leverage open graph for semi-internal apps/projects... well done!

</comment><comment><USER11> So what's the use case for this? You basically have to make new profiles for this, right, so you don't risk your emails accidentally popping up when FB makes a slight adjustment to their API and default privacy controls?

Also, theoretically, you cc everyone you want to see an email...so FB notifying does what exactly?

</comment><comment><USER12> My eyes!</comment>


NASA releases iPad app with Simultaneous Localization and Mapping tech  - <AUTHOR> http://13thlab.com/ballinvasion/

<comment><USER2> Not actually released by NASA. But still very nifty.</comment>


RIM Must Switch To Android Now, Before It's Too Late - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/g/a/2010/08/20/businessinsider-rim-android-blackberry-2010-8.DTL

<comment><USER2> They way I've seen it for about at least a year now is that the mobile computing world is becoming a commodity, just like the desktop computing world, and in a commodity world there are only major platforms and not big manufacturers.

Consider Windows and the PC hardware brands: generally there's not much difference between Dell, Samsung, HP, Lenovo and the rest. For example, most people are buying laptops these days. Sure, all the brands have little niches: some are considered durable and professional, some focus on the cheap segment and some focus on the pricey end, some make big gamers' laptops and some make small travel laptops. But they're all brands and brands are all about what people think and not much about reality. This means that my mother can choose any laptop she want and even the cheapest one has many, many times more power and features than she needs.

For the mobile world, the transition to a commodity took place when phones became computers. Cellphones are a relatively new invention and new market, and in the beginning it was enough to just reliably manufacture a working phone. Not every company could do even that! The best hardware quite a lot better than the worst hardware.

Then gradually the phone hardware become a commodity. The dysfunctional designs got weeded out. Manufacturing got centralized to companies specializing in specific chips or chipsets. These days a company without lots of experience and history in the mobile world can buy a set of required system-on-chips for gsm/3G/bluetooth/camera functionality and anything beyond, and start making mobile phones. While things did work when each cellphone maker had their own OS it was quite a limitation, and very analogous to the 80's home computer market.

In the 80's, you could buy different Commodore, Atari, Apple, PC, Acorn, Sinclair, and probably a few dozen other niche home computers and none of them worked together. Finally, in the late 80's the PC platform with all their dozens of IBM PC clones won over everyone else, even most of Apple. Soon everyone found themselves having landed on the same commodity hardware and they figured that they'll make more money if they just use the same OS than everyone else, rather than a custom OS that would just cut them off the big market. Hence, Windows bloomed, everyone sold it, and soon it didn't matter which computer you bought because you ended up using Windows on it. Differences between PC makers become differences in brands.

The same is happening in mobile phones, err, I mean mobile computers. Because everyone (relatively speaking) can do the hardware, companies can now afford to, and must, focus on the software.

I hereby foresee that in a few years we're down to Android and iPhone and "the rest". Unless Apple begins to target the low end, Android will become the clearly largest mobile phone platform in the world. iPhone will compete in the high end against Android but the relation between Android and iPhone OS are likely to parallel the way Microsoft and Apple relate to each other in the desktop market.

That is, unless unforeseen disruptions arise and completely throw the market upside down, Android will grow to have 40-50% market share, Apple up to 20-30%, and the rest will be 5-15% Symbian, Windows Phone, and many others combined.

<comment><USER3> I am not convinced that Android will do so great in the long term: well yes, great maybe not.

My guess would be more along the lines of (obviously I am no analyst and this are really just guesses):

Android: 25% Apple: 25% WP7: 20% Meego/Symbian: 15% RIM: 15%

with Apple and Android aiming mostly at the consumer market, and, Windows and RIM at the business market. Meego will be a generic blog that will work in every field but will never excel. And Symbian will control the cheap, 3rd- world country phones.

I do have hopes though that maybe Meego will end up being a surprise. (I wish, I really liked Nokia back in the days).

</comment></comment><comment><USER3> OMG, this is such an unbelievable wrong idea. The only one that it would help is Android, and it would hurt Apple. But RIM would risk losing a lot too in the long-run.

Look at what happened with the PC market. Compaq? Gateway? Even Dell and HP, the biggest two are earning very little from their computer division (well, relatively little). The two winners in the PC market have been Windows and Intel.

So now we have RIM. They move to Android, and lose the exclusivity of their OS. Is their hardware division so strong and their product so flawless that they will be able to compete with Samsung, Motorola or HTC?

The way I see it Samsung has still a few aces from its very strong screen division, and others (don't they also produce flash?). HTC also could win: they started from almost 0, a cut-throad market can only do them good.

But the others? They all have access to the same processors, screens, batteries, and OS. Even now (and we have just started) a new phone enjoys a few months in the sunlight before being subclassed by a new model. In the long term they will only be able to compete by adding more recent hardware (but everyone can do that) and price.

Is this really were RIM wants to be in the future?

<comment><USER4> >Look at what happened with the PC market. Compaq? Gateway? Even Dell and HP, the biggest two are earning very little from their computer division (well, relatively little). The two winners in the PC market have been Windows and Intel.

Your analogy suffers from a strong survivorship bias.

If you were paying attention to the computer market in the 80s, there were countless companies with their own take on computers. The overwhelming number of them disappeared, while a very few (like Dell) managed to hang their fortunes on the winning side (PC-ish, Windows) and saw the dollars pour in.

The more I think about your analogy, the more I realize that the example you gave is an exact counterpoint to your given conclusion.

And really, you claim that Dell and HP make relatively little from their computer divisions? They are both global companies, having profited to the tune of many billions, on the backs of that effort.

RIM _cannot_ continue on their current arc. They will be _dead_ in a matter of years. It is absolutely, positively guaranteed.

In any case, one thing about Android is that in no way do vendors lose exclusivity...that's a part of the platform. I know tech people hate HTC Sense, but you know a lot of end-users actually love it. The same for Moto Blur and the other differentiations. We are not a good study in the utility of such differentiators. RIM would have the full ability to completely customize Android to be a very unique, very powerful experience.

<comment><USER3> Sure. But your view is a bit pessimistic. I would like to think that the management at RIM think they've got something unique that will give them an edge. Maybe it's more risky but if you believe in your company that's a risk you should take.

And RIM is not exactly a nobody: they've got a large chunk of the market. Your point is basically: "Forget your past glory, give up your profit margins, and join the Android crowd". Why not instead: "Improve your OS to be on par with the competition (no need to be better), and use your good hardware and your proprietary applications to make the difference".

I don't see how using Android is a long term viable strategy for a company that currently has 17% of the market. It looks more like throwing the towel.

</comment></comment></comment><comment><USER5> He's forgetting that a lot of times, it isn't the end user purchasing the Blackberry. RIM owns corporate sales, and that isn't slackening. Their overall market share in smart phones is declining, but that's just an effect of so many consumers beginning to buy them. At the end of the day it's all about profit, not market share, and a smaller percentage of a much larger pie is often a good thing.

The iPhone (and most Android units, which are keyboardless) don't even attempt to cater to RIM's core market: hardcore emailers. RIM will continue to own that for the foreseeable future. They're even getting some consumer traction since text messaging is so ubiquitous.

Corporate IT departments, that already have BES running, are going to keep buying Blackberries. And the Blackberries are going to keep them running BES. There are certainly alternatives (Android/Active Sync) but the cost involved in switching is significant and the benefits are merely nonexistent.

So all RIM would do in switching to Android is end their vendor lock-in. Vendors don't often give that up.

While the Blackberry OS is rough around the edges, so is Android. And the Berry still does email better than anyone.

<comment><USER4> There seems to be a lot of debate based on emotion with remarkably little fact.

Many corporations are moving to a bring-your-own smartphone policy. My organization did exactly that recently, and no new Blackberry has been purchased in some time: We have the BES server and the plans, but users don't want to carry some deadweight blackberry _and_ the Android or iPhone smartphone that they also carry. With Exchange Web Services, the whole BES thing seems like such an anachronism anyways.

<comment><USER5> Decrying an argument for lacking facts and then replying with an anecdote is hypocritical.

<comment><USER6> He is right many companies are switching to a bring-your-own-smartphone policies. We haven't issued a Blackberry in quite some time and stuff like IMAP and OWA make it easy to make just about any cleverphone functional.

The issue is dominance. Once a new player enters the segment, it's a question of time until it fragments. Blackberry enjoyed a dominant position for a long time but being the #1 corporate-issue phone is not important in a world where more and more people bring their own phones into their jobs.

</comment></comment></comment></comment><comment><USER7> Obviously the entire article is fluff, but there's one thing that sticks out as just wrong:

"No one who buys BlackBerry products actually cares about the BlackBerry OS."

Has this guy ever talked to a Blackberry owner? They seem to be some of the most loyal cell phone owners around. Everyone talks about switching to an iPhone or whatever, but (from the article):

"RIM is still selling plenty of BlackBerry devices -- thanks to international expansion and big sales at carriers."

<comment><USER8> I believe this article had the basis that the reality of the market is changing. So while Blackberry may have some passionate users now, the gap in quality of their software compared to android/ios is going to keep widening.

Basically they either need to get their software up to speed or move to android.

</comment></comment><comment><USER9> This would actually be a terrible idea. Imagine all the rewriting of every little business app people have written for their blackberries, and the instant obsolescence of BES servers. No, RIM just needs to innovate in a way that doesn't seem half-assed.

<comment><USER10> Presumably if RIM switched to Android, they would port all their apps (like the much-beloved mail client) to Android and possibly even have a J2ME VM to run old third-party Blackberry apps.

</comment></comment><comment><USER11> This bears and eerie resemblance to all those "Apple needs to switch to Windows NT" articles from a decade back.

<comment><USER12> Well, Apple's core OS was severely lacking, and they did need to make a major switch to really start turning things around. Unfortunately, the analogous thing to what Apple did would have been to acquire Palm and use its underlying architecture for a new product that was still called RIM OS (and hope that the CEO of Palm was some genius visionary that could run your company instead of you, I guess?)

<comment><USER6> The difference is that NeXT acquired Apple (for a negative amount of money, that is) and provided them with an OS they could control. Apple adopting an OS Microsoft controlled was a Really Stupid Idea, much like Blackberry adopting an OS Google controls is now. The only meaningful difference is that Google is not a direct competitor while Microsoft was (in association with every PC maker)

</comment></comment></comment><comment><USER13> I disagree. I think Microsoft and RIM should team up. Microsoft is supplying Windows 7 to vendors that just don't give a crap about what software is on their phone as long as it's got all the checkbox features (i.e. they offer both Android and Windows 7 devices but won't focus on one over the other). So stop supplying Windows 7 to these vendors and make RIM the exclusive vendor for Windows 7 devices. Microsoft has a pretty great mobile OS in Windows 7 (this coming from an iPhone lover) and RIM has great hardware and a fan base. These two companies need each other.

<comment><USER14> I wasn't aware Windows Phone 7 was released. I don't know about you, but I can't really tell what a product is like until I've at least read independent reviews, or preferably used it directly.

<comment><USER13> That's usually true unless the product is from Microsoft. Unlike Apple, Microsoft is pretty up-front about what their product will be like before it's actually released. Also, it's not like Microsoft will be starting from scratch. They've got a good kernel and solid foundation to build from. They've got great developer tools. Yes, the user experience is a HUGE blank that needs to be filled in. But do I think Windows Phone 7 will suck like Windows Mobile? I'm a betting man and I say it won't suck, it will actually be decent and won't feel like Android's "I'm running KDE" crappy feel/user experience.

</comment></comment></comment><comment><USER15> RIM owns QNX which has been working in embedded communication devices for years.

Why would they need Android?

<comment><USER10> To run Android apps.

<comment><USER16> Why would they want a task manager app?

</comment></comment></comment><comment><USER17> I agree. BB OS is buggy and does not have even close to the level of developer attention as iOS or Android. RIM should just make the jump now before it fades into irrelevance. IMHO, the most useful features of BB OS could be reworked as an Android skin, like HTC's Sense or Motorola's Motoblur.

<comment><USER18> the apps are horrible, but the core BB operating system is very fast and usable.

<comment><USER19> In my (admittedly brief) experience with Blackberry development, this is anything but the case. Libraries are flaky, inconsistent and poorly documented, and aspects of the RIM JVM implementation are deeply flawed. For example, one of my coworkers recently discovered that static initialization blocks can be called multiple times if a class or interface has inheritors, blatantly violating the spec.

...Did you mean the UI or something?

</comment></comment></comment><comment><USER20> I am very seriously considering switching from a Droid back to a blackberry.

<comment><USER3> Would you care to explain more?

(Incidentally here in the UK Blackberries are doing very well, and not just in the corporate environment. A lot of students and teenager have them too.)

<comment><USER21> That's the same in the states, but adoption has really fallen off after the Bold and Curve2 - there hasn't been anything exciting and new in the works in the past year or so, and the Torch is considered a failure so far stateside (it's only been a few weeks). Most of my friends still have Blackberries but as their handsets die they're being replaced with a lot of Androids and iPhones..

<comment><USER3> But how much of that is hype and how much is a fundamental problem with Blackberries? To me the torch seems a pretty nice product. Sure: still a generation behind. But it's not like opponents are too far ahead: they (and MS and Meego) can still catch up. Look what Android did in one year!

I think if the Blackberry keep being solid mobiles that are a little bit behind the curve but not much (say 6 to 12 months), they'll be just perfect for corporations. There's a bright future ahead.

</comment></comment></comment></comment><comment><USER3> Incidentally, I think it's too early to call the shots. One year ago Android was another nobody, and now look where they are!

Palm had a money problem, but if they didn't maybe they could have got good returns.

And on the horizon we have Meego and Windows Phone 7.

A year from now the situation may be very very different. Plus when your product is mostly good but some aspects are crap, wouldn't the best policy be to improve the latter instead of throwing everything and become a me-too manufacturer?

</comment><comment><USER22> RIM is buying QNX. Probably smarter to build a new kick-ass platform based on QNX than switch to a platform that just got hit with a major lawsuit.

</comment><comment><USER23> Their change to a webkit based browser is interesting. Will RIM devices will be able to access a broad enough spectrum of mobile-oriented web-apps to overcome the perception of a too-late too-little application marketplace strategy? Will their implementation of webkit be too different from the others? It will be interesting to see what happens.

</comment><comment><USER24> Here's my possibly slightly less ridiculous proclamation as to what RIM should do:

RIM should set up shop in a warmer climate, maybe the California Bay Area, so that they can attract more software design talent hesitant to live in cold, windy Toronto.

<comment><USER25> RIM has an R&D location in Redwood City since 2008.

</comment></comment><comment><USER26> The coming dominance of mobile/tablet oriented web apps running in the cloud with persistent offline operation is what is going to keep RIM (and others) from needing a better OS. Android and iPhone only have a temporary advantage in the mobile space.

</comment><comment><USER27> Doesn't this kill any hope for BlackBerry to have software revenue? Can't see that being a good thing given how fast the app market is growing. They should have bought Palm back then could.

</comment><comment><USER28> Hah! Was this really written after Oracle sued Google? So RIM should give up patent protection to switch to Dalvik?

</comment><comment><USER29> Maybe RIM could work on porting apps to android behind the scenes and then when everyone wants android on there bberries, bam. That os is free and open source, right?

thought #2 open source to != profit. Ever heard of apple, microsoft, cisco, etc.

Companies need to protect there intellectual property.</comment>


Tech giants to be targeted by laws to help police access encrypted data - <AUTHOR> http://www.abc.net.au/news/2018-06-06/tech-and-telco-terror-laws-to-be-presented-in-weeks/9839500 <comment><USER2> When strong commercial encryption becomes illegal, two things will happen: 1. Criminals and terrorists will construct their own strong encryption (anyone can buy books explaining how to do this from Amazon, and any competent programmer can do it) and 2. China, Russia and organized crime will penetrate the weakened commercial encryption.

<comment><USER3> "When strong commercial encryption becomes illegal"... criminals and terrorists will continue doing illegal things. They will not say "oh shit, encryption is illegal I better stop and be good now".</comment></comment>


Portainer, a UI for Docker - <AUTHOR> https://media-glass.es/portainer-the-ui-for-docker-d067f6335f23#.2gafj9tpt <comment><USER2> The lineage:

DockerUI - Created by Michael Crosby, later handed off to me when he got busy at Docker. The goal was to provide parity with the Docker command line, no extra features.

UI for Docker - Rename of the same project due to trademark concerns

Portainer - Fork of the original codebase with an expanded feature scope. I started losing interest in keeping up with Docker features when they added native Swarm, combined with a job change it was a good time to hand off the torch to someone else. It looks like they're trying to make a company out of it, I'm interested to see if they can make it happen.

<comment><USER3> Thanks Kevan, the work of Docker UI was legendary, however, as you pointed out, development slowed. We initially built portainer for our own internal use (as the UI for CloudInovasi.id), but liked it so much, we decided to focus on it. We are now wanting to add substantially more capability so that it becomes truly production ready. There will be a select few paid add-on's in the future for things like AD authentication, multi-tenancy etc, but the core will always be opensource and free.

</comment></comment><comment><USER4> I'm not really sure on how this can move beyond a "good to have" UI on my dev machine. In production I'd always want a more wide-scoped dashboard like the one in K8s or Marathon.

<comment><USER5> This. I evaluated Portainer recently and found myself missing a few critical features available from Marathon.

<comment><USER3> Such as? Let us know what we are missing, and we can look at adding it.. remember tho, we are not trying to be a replacement for Swarm, we believe swarm service orchestration to be a winner, so are supporting that (as opposed to rancher, kuber etc who have their own cluster solution).

</comment></comment></comment><comment><USER6> how is this different then shipyard -> [https://shipyard- project.com/](https://shipyard-project.com/)

i would love to be able to add docker-compose file and it would create everything for me ( something like rancher ). shipyard does not support this and with rancher i abounded it after running into problems.

<comment><AUTHOR> Both Portainer and Shipyard currently occupy the same space. While there is no Docker Compose support at the moment, however, you can add customisable templates, see [https://portainer.readthedocs.io/en/stable/templates.html](https://portainer.readthedocs.io/en/stable/templates.html) for more info.

Also, they do eventually plan for Portainer to compete with Rancher [https://twitter.com/portainerio/status/814542425410576386](https://twitter.com/portainerio/status/814542425410576386)

</comment></comment><comment><USER7> Why should I use this instead of Kubernetes?

<comment><USER8> Is there a similarly simple and rich UI for Kube?

<comment><USER9> Kubernetes Dashboard - [http://blog.kubernetes.io/2016/07/dashboard-web- interface-fo...](http://blog.kubernetes.io/2016/07/dashboard-web-interface- for-kubernetes.html)

</comment></comment></comment><comment><USER10> would love to see a curses (cli) based UI for managing images/containers (not aware of any).

<comment><USER11> I am fairly certain I've used one, do not recall the name.

Edit: [https://github.com/TomasTomecek/sen](https://github.com/TomasTomecek/sen)

</comment></comment><comment><USER12> Can anyone point me to the best argument for hiding complexity instead of eliminating it?

<comment><USER13> Sometimes you want it (lots of config options) and sometimes you don't. In the real world, you need the detail available for strange edge cases but generally are happy with mostly-defaults.

</comment></comment><comment><USER14> @ncresswell, more create and update capabilities would be great (e.g. the ability to create a network, connect a container, etc.)

</comment><comment><USER15> Betteridge's law, something for headline writers to be aware of?

<comment><USER16> It's pretty well-known!

[https://hn.algolia.com/?query=betteridge&sort=byDate&prefix&...](https://hn.algolia.com/?query=betteridge&sort=byDate&prefix&page=0&dateRange=all&type=comment)</comment></comment>


Go modules have a v2+ problem - <AUTHOR> https://donatstudios.com/Go-v2-Modules <comment><USER3> I see a lot of comments in here about the v2+ rule's reason for existing being to allow importing multiple major versions of a module. That's not it at all. As the blog post (which was easily Googled by me and explains things quite well IMO) states: "If an old package and a new package have the same import path, the new package must be backwards compatible with the old package."

They're trying not to break compatibility until a downstream developer explicitly opts in to that breakage. The simplest way to do that is to give the module a new name. And the simplest way to do that is append the major version to the name.

Here is the post: [https://blog.golang.org/v2-go- modules](https://blog.golang.org/v2-go-modules)

For more background on this principle, I recommend Rich Hickey's Clojure/conj keynote "Spec-ulation" from 2016: [http://blog.ezyang.com/2016/12/thoughts- about-spec-ulation-r...](http://blog.ezyang.com/2016/12/thoughts-about-spec- ulation-rich-hickey/)

<comment><USER4> That's weird, how then do other languages manage to solve importing packages/modules cleanly without requiring that the name of the package _include_ the version number, while still allowing developers to specify exactly _which_ version of the module they want to use?

Surely _someone_ else has solved this problem before, like Rust's Cargo, or Java's Maven, or JS's NPM, or Python's PIP, Ruby's Gems, or...

Unlike in _every single one_ of those other languages, this Golang decision means that you can't pin to a specific minor version, or a specific patch version (in the sense of MAJOR.MINOR.PATCH).

It's very in-character for the Golang team though: they value simplicity-for- themselves no matter what the complexity-for-you cost is.

<comment><USER5> It's short sighted to think that the Go package managment is "simple", there was a lot of thoughts and considerations that was put into it and improvements over other languages ( even recent one like Rust ).

Good read: [https://research.swtch.com/vgo- principles](https://research.swtch.com/vgo-principles) which answers some of your questions.

<comment><USER6> "A lot of thought and consideration" was put into the ten previous approaches they've attempted to solve this problem.

I'm starting to think that the reason they've tried so hard to avoid solving interesting problems in the language is that every time they've tried they've made something worse than every other alternative that existed in the problem space.

</comment></comment></comment></comment><comment><USER7> Re: "They need at the very least a section of the documentation that lays it out clearly and in layman's terms."

As a Go outsider who's trying to get his feet dipped in the lake, trying to use modules has felt... uneasy? I tried to look up the official resources on the matter and found the official blog posts to be lacking concrete and concise examples on the usage; documentation feels like it's written for people who work on the project and already digested the unit tests as examples.

As for the case of v2, similarly messy and undocumented. I also appreciate author's call for action on warning messages in tooling.

Wasn't the unified tooling supposed to be a selling point for Go? It just doesn't _feel_ good to use.

<comment><USER8> Poor documentation seems to be a Google culture thing. I suspect that's why godoc is literally just source code comments wrapped in HTML.

<comment><USER9> I have found this to be almost universal when it comes to reading / writing documentation, not just Google.

I have come to the understanding that to write good documentation, you should write it as soon as you have learned it, or at least, try and explain in a similar way in the way you learned (which is not easy at all). I feel the issue stems from abstraction. Once you become somewhat an expert in a topic or develop a deeper understanding of said topic, you automatically abstract away the information that lead you to that understanding in the first place.

Otherwise you end up reading or writing documentation with a bunch of assumptions for knowledge and understanding, which are not only not stated but may not be available to the person trying to get to grips with the technology. A bit of a digression from the post, but I don't feel this is just a Google thing.

<comment><USER10> There is a name for it: The experts blind spot

<comment><USER11> Erlang's creator Joe Armstrong once said it like this (quoting from memory) "There's a moment when you go from not getting it to getting it, and you have about 24 hours when you remember both before and after, and that's when you have to write things down. After that you won't remember how it was not getting it"

</comment></comment></comment></comment></comment><comment><USER12> Hiyo,

I'm one of the co-authors of [https://blog.golang.org/v2-go- modules](https://blog.golang.org/v2-go-modules).

One of the takeaways from this article was, "there needs to be more documentation", and I think I can speak to that:

First, thanks for the feedback. We also want there to be a loooot more documentation, of all kinds.

To that end, several folks on the Go team and many community members have been working on Go module documentation. We have published several blog posts, rewritten "How to write Go code" [https://golang.org/doc/code.html](https://golang.org/doc/code.html), have been writing loads of reference material (follow in [https://github.com/golang/go/issues/33637](https://github.com/golang/go/issues/33637)), have several tutorials on the way, are thinking and talking about a "cheatsheet", are building more tooling, and more.

If you have ideas for how to improve modules, module documentation, or just want to chat about modules, please feel free to post ideas at github.com/golang/go/issues or come chat at gophers.slack.com#modules.

<comment> grey-area As an everyday user of Go perplexed by this making it into the mainline, I'd like to second the request to make this feature optional. More documentation would be nice, but I'd prefer the default to change.

The assumptions in that v2 go modules article around the meaning of major semantic versions do not jibe with the way the majority of software in use today uses version numbers - they are most often used to denote new features, which may or may not have breaking changes large or small, and small breaking changes are tolerated all the time, often in minor versions. This assertion in particular seems wrong to me for most software in use today:

 _By definition, a new major version of a package is not backwards compatible with the previous version._

<comment><USER12> Semver is very clear on what a minor vs a major change means.

> the majority of software in use today uses version numbers - they are most > often used to denote new features, which may or may not have breaking > changes large or small, and small breaking changes are tolerated all the > time, often in minor versions

We're getting into opinion here. Let's be clear: semver very strictly, objectively disagrees with this approach. In general, this approach of "what's a few breaking changes in a minor release amongst friends" leads to terrible user experiences.

Go modules takes the cost of churn, which in some languages gets externalized to all users, and places it on the module author instead. That is far more scalable and results in much happier users, even though module authors sometimes have to be more careful or do more work.

<comment> grey-area Thanks for working on the docs and engaging here, I know it can sometimes be a thankless task.

I don't think it's a matter of opinion that the vast majority of software in common use does not use strict semantic versioning, most likely including the web browser and operating system you are using to read this comment, popular packages like kubernetes, and the Go project itself in the mooted 2.0 with no breaking changes. It is highly desirable to avoid significant breakage, even to the point of ignoring strict semver and avoiding it across major version changes! So I'm not arguing for encouraging packages to break, but rather the reverse, I prefer the status quo pre go mod where packages are assumed not to break importers, though sometimes small breakage happens and/or is acceptable.

Most packages use a weaker version of semver than the one you describe, which is still useful, so I'm not clear why the go tools have to impose the very strong version which is not commonly used. The difficulties introduced seem to outweigh any benefit to me.

<comment><USER13> Because the version of web browser and the kernel more or less doesn't matter because they care way more about backwards compatibility than the "vast majority of software".

The kernel doesn't break user space. Web browsers' api generally remains backwards compatible (how long did it take to remove flash - and you can still install it if you want!)

<comment> grey-area Prior to this change, all go software operated on this assumption (do not break users of the pkg), which doesn't comply with strict semver.

It worked fine.

</comment></comment></comment></comment></comment></comment><comment><USER14> > Some projects like GORM sidestep the issue entirely by tagging their 2.0 > releases as far flung 1.x releases. That something of a solution, but smells > terrible.

Amusingly, the Google protobuf team did a similar thing for the Go protobuf bindings. The new, backwards-incompatible `protobuf` module started with version 1.20, while the old module is at 1.4.

If you've followed this, you know I've omitted one detail - they actually changed the name of the module as well, from `github.com/golang/protobuf` to `google.golang.org/protobuf`. Because, of course, Golang modules names are actually URLs, not identifiers like in every other package manager out there.

<comment><USER15> > Because, of course, Golang modules names are actually URLs, not identifiers > like in every other package manager out there.

They don't have to be URLs, though. What's the difference between `google.golang.org/protobuf` and `org.golang.google.protobuf`?

<comment><USER16> > What's the difference between `google.golang.org/protobuf` and > `org.golang.google.protobuf`?

There isn't one, because that's also a (mangled) URL, namely "[http://protobuf.google.golang.org/"](http://protobuf.google.golang.org/"), and should be rejected for the same reasons. A _identifier_ would be "protobuf"; note the lack of any reference to the DNS domain.

<comment> grey-area Do that and soon you're going to have to introduce namespaces, and you're back to something that looks like urls.

People use these longer import identifiers because they avoid polluting the global namespace, which be reserved for very important packages (in the case of go the std lib).

<comment><USER17> _> Do that and soon you're going to have to introduce namespaces_

Everyone says this but there is strong evidence from npm and other package ecosystems that you can go surprisingly far with a single flat global namespace.

I think there is a paranoia among software developers about _potential_ name collisions. But in reality, name collisions are rare and easily avoided. There are 308,915,776 unique six-letter identifiers. Go to eight and you have 208,827,064,576 names to choose from.

<comment> grey-area Namespaces are used for clarity (this is pkg log from org/user x), not because we run out of letters.

<comment><USER17> The problem with that is that you're essentially using a hierarchy to attach some piece of metadata to each package. The question then is what piece of metadata is both so valuable to be worth enshrining in the name and yet so unchanging that if its value changes, you're OK with every user of that package having to migrate to the new identifier.

I have yet to see any particular bit of metadata that fits into that set. Using "owner" like you do in your example here is a common choice, but also very frequently changes. If you look around, you'll find lots of examples where a package moved to a new owner and caused all sorts of problems because now all the old name references no longer work.

You could try to pick some essentially descriptive property of the package itselfs—maybe, say, "Net" if it has to with networking—like CPAN does, but it's not clear that doing so adds any real value beyond satisfying our human desire to put things in neat littly cubbyholes.

<comment> grey-area I do have some sympathy with your views on this. Package identifiers don't have to live in a hierarchy or include origin/owner. That they do in so many systems indicates people find this information useful. I do disagree that owner changes frequently - for the vast majority of packages that's not the case.

Personally I find knowing the owner sometimes useful, and quite like the use of urls in go imports as it also lets me look up the source. I've never found it a huge problem (and I have moved packages from one place to another a few times).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> In the go ecosystem, packages are imported per file. Go is designed for large systems to evolve over time. You need to be able to refer to v1 and v2 at the same time.

Thus the "/v2" requirement.

Yes, it is different. Stop complaining, do it, and it just works. Here is the tutorial.

1\. Modify go.mod package path to include the "/v2" element. 2\. Commit. 3\. Tag as "v2.0.0" 4\. Push tag.

I'm not seeing what is too confusing about releasing.

To consume, on packages that you want it, import the new package. Done.

Being able to import multiple versions without conflict has been extremely helpful when I've needed new features in one version, but didn't want to update (at the same time time) all the other places.

I really don't get why people don't like it, other then it is different then what they expect elsewhere.

<comment><USER19> It's actually pretty much the only consistent and guaranteed backwards compatible way to deal with such changes.

<comment><USER20> There's no guarantee of backwards compatibility without limiting of forward functionality. The trade-off can't be escaped.

If you can make do without any persistent state, or global or externally visible resources (network connections, configuration files, etc.), then you're OK. But that's a limitation.

<comment><USER21> Modules that rely on global state for anything other than memory pooling or what have you should be avoided. It's a lot more testable and clean to return a high level data structure that contains any of that state you would have held before globally in the module and have that be the "context" or just the parent data structure to any others that are spawned.

Global state makes thing impossible like parallel unit tests that all use another module, or changing things like "MaxConcurrency" in a way that is synchronized across goroutines that might already be calling into the third party module.

My 2c.

<comment><USER20> Of course. I'm not advocating global state. It's just that most real systems have things like file systems, config files, databases, listening network sockets, etc. These are inherently non-local.

</comment></comment></comment></comment></comment><comment> grey-area I'm still really not clear on why the Go team thought this was a good idea.

It makes no sense to me to try to impose this rule on the ecosystem - <USER2> costs (confusion, multiple urls, multiple ways of doing it) vastly outweigh the benefits (multiple versions in use at once), and if a particular project wishes to use this rule, they could do so, without imposing it on the thousands of packages which might want to use higher numbers to indicate large feature releases or are already using higher numbers.

In theory a larger number in semantic versioning indicates breaking changes, in practice small breaking changes are made all the time, it's a matter of degree and the context of a given project, and people also use version numbers for marketing or indicating lots of new features - a good case in point being Go 2.0 which may well be backwards compatible to Go 1.0. That makes this assumption in their blog false:

> By definition, a new major version of a package is not backwards compatible > with the previous version.[0]

That's not the only, or even the main, reason projects use higher version numbers.

I imagine lots of people will keep their version forever in the 1.x range to work around this rule. I too believe Go should drop this requirement before it is too late.

0\. [https://blog.golang.org/v2-go-modules](https://blog.golang.org/v2-go- modules)

<comment><USER22> There is a difference between a software (executable) and a library. Semver is overrated but at least common and well understood with clear semantics. And no, Go 2 probably will be Go v1.23.

</comment></comment><comment><USER23> I knew about this rule and I still got bitten by it last week when I was trying to upgrade a package. It's one of the many things I hate about go modules.

As I understand it the reason for this design decision was to allow a project to use multiple versions of the same dependency at once. To me this seems like a pretty rare edge case. They burdened the 99% of users with weird V2 syntax so that 1% of users could handle this edge case (which could have been handled by other means).

<comment><USER15> It's not really an edge case, it's sort of to the core of how modules work, and allows a whole slew of issues to be elided. See [https://research.swtch.com/vgo-import](https://research.swtch.com/vgo-import) for more background and examples.

> They burdened the 99% of users with weird V2 syntax so that 1% of users > could handle this edge case (which could have been handled by other means).

Really the only burden lands on package authors who are making breaking changes. And really, the path provided is so much easier than actually making breaking changes for your users. Everyone wins.

<comment> grey-area > Really the only burden lands on package authors who are making breaking > changes. And really, the path provided is so much easier than actually > making breaking changes for your users. Everyone wins.

The burden falls on every module developer who wants to use a version number above 1.x. That is _not_ congruent with developers who make breaking changes as you seem to assume.

There's an assumption here about v2 meaning breaking changes that not even Go 2 itself may adhere to (as it may well be more of a 'new features' version number than a 'breaking changes' version number increment).

<comment><USER24> > The burden falls on every module developer who wants to use a version number > above 1.x.

And this is fine as it gives module developers an opportunity to make breaking changes which they wanted for quite some time. It makes much clearer for module user as opposed to Java where one does not know which module will blow up code was it 2.11 or may be 2.13.2 etc.

> There's an assumption here about v2 meaning breaking changes that not even > Go 2 itself may adhere to

If anything Go is trying to be even more conservative that they are avoiding breaking changes in 2.0 as opposed to being rash making breaking changes in 1.x. I see no problem with that.

<comment> grey-area It directly contradicts the assertion that major versions must mean breaking changes, the justification for forcing import urls to change.

</comment></comment></comment></comment></comment><comment><USER25> A consequence of the complexity is that some devs stay below v2 forever because it's easier. Backwards incompatible changes pile up in v0.x's. It's then really difficult for consumers to install two versions of the same package, which can happen with diamond dependencies.

<comment><USER26> Do you have an example of such package? I've used Go modules for years and never encountered that.

<comment><USER27> someone cited kubernetes above

</comment></comment></comment><comment><USER28> Go has a bigger tooling problem. Build systems are hard, and Go has decided it doesn't want to be hard so it's ignored anything other than the "happy path". I wish other Go dependency tools still existed.

</comment><comment><USER29> I'm a huge fan of Go, and not a fan of dependencies at all, so I tend to vendor everything.

Go mod just looks like a total mess from the outside. To be honest I (like most gophers I've talked to) never really understood why dep wasn't adopted as the official solution for this.

I'm resisting converting my projects to modules until there's a clear and definite advantage to it. So far, none.

<comment><USER30> I tried dep for a project of mine and could never even get it to the point of doing anything useful. Conversely go mod took about three minutes to migrate to and was super straightforward.

I am very happy that they did not adopt dep, it was in no way ready (and I don't think it was going to significantly improve given more time).

<comment><USER29> True, there were problems with it, it wasn't perfect by any means.

I guess the main complaint at the time was that it appeared to be "not invented here" syndrome. The community was converging on dep, and then the Go team decided to do something different, for reasons that weren't completely clear. It kinda rammed home the reality that Go is not a community project, it's a Google product controlled by a small team. That definitely has benefits and good points, but it doesn't match everyone's expectations.

</comment></comment></comment><comment><USER31> What I don't understand is why they chose to put the major version as part of the path part of the uri (/), as opposed to some other separator, e.g. fragment (#). Especially since it's optional. You can always convert "example.com/foo#v2" into the "/v2" if needed, but if you see "foo/v8" is that a repo "foo" version major v8, a subfolder of "foo" named "v8" or a repo "v8" in the project "foo"?

<comment><USER32> It's traditional at least with web browsers to not send the fragment to the server. Query param would work, but implies your routes don't change much between major versions.

<comment><USER31> > It's traditional at least with web browsers to not send the fragment to the > server.

Ah, TIL, thanks!

I meant more "why must the import syntax use specifically this scheme to denote versions". I guess backwards compat?

<comment><USER33> Import paths are used to figure out where to fetch the source code from. To simplify a bit, if you see `example.com/foo/bar`, it works because there's an appropriate meta tag at [https://example.com/foo/bar?go- get=1](https://example.com/foo/bar?go-get=1) . The import paths are pretty directly used as URLs.

</comment></comment></comment></comment><comment><USER34> "I have seen many very large projects including Google owned projects get it wrong."

As an ex-Googler I can tell you that this above statement can be more broadly applied across _many_ developer facing Google products (most notably for me, Android frameworks and libraries). Google's apps don't use the guidance and recommendations we gave to external Android devs.

I wonder if there is something cultural about Google not even being able to coordinate changes and improvements within the org itself.

</comment><comment><USER35> I don't understand whats so hard at making it easy, if one just use source repo tags (which in go module land you should be using).

1) your go.mod should include the version 2) the module itself always assumes its the version of it's go.mod file 3) to release a version you just tag it based on the version in the go.mod file (with later semantic versions being considered the best and what go will use by default) so module authors have to do.

so module authors dont have to do anything special besides include the version in the go.mod file (and keep it up to date) + tag release appropriately in a way that keeps to go's compatibility promise.

4) when you import a module, you specify what version you want (with a default assumption of v1) so your go.mod would either include the module or modules/v2... 5) your imports in actual .go files would not have to include the /v2 as they would know based on the go.mod file.

you as the end user of the module will follow v0/v1 tag for as long as it exists, but will have to modify your go.mod to use v2 if you want to switch.

does my conception not make sense?

<comment><USER36> The point of having separate imports for separate versions is to allow for use of (for example) both v1 and v2 of a module within the same codebase, if required. Your idea would force a single version, which means that would no longer be possible.

<comment><USER35> ok, reasonable, though it would seem that one could do both. i.e. for those that dont want to include multiple versions, be easy, for those that need them, then you have extra complexity.

</comment></comment></comment><comment><USER37> 2-3 years ago I was working on a large project in Go with many dependencies. We moved in the span of 12 months from go get, to glide, to dep, and when vgo was announced I realized I was on a pointless treadmill, despite community assurances that the current package manager is "blessed" and will be maintained. I then decided that Go is actually quite unstable and is not yet ready for enterprise projects, and recommend against it despite the fact that I really like and agree with the design philosophy of the language.

<comment><USER18> It would have been best to have skipped glide and dep. Sorry.

The Go the language is stable, and Go modules is stable and is the future. Everything, including new features, is based on Go modules. That isn't changing.

</comment></comment><comment><USER38> Author of the post here. Really neat to see something I posted _last night_ on HN the very next morning.

With a night to sleep on it, I think requiring `/v0` and `/v1` would have been the better option, that way you'd hit the issue _right away_ rather than years into your project. Teach things early. I've updated the post with a note of this idea.

I think that's likely not something they could add at this point however.

I don't even mean to be critical of the v2-ing itself, I just think it's entirely non-obvious.

</comment><comment><USER39> This is why I never use anything but "1" as the first number in my go modules. The second number is the major (breaking changes) version field, and the third number is the minor field (non breaking changes).

These are just the kinds of things you put up with when writing go code and need to work around bad designs of the language and ecosystem.

</comment><comment><USER40> I think people are too quick to declare v1. All of my modules are (deliberately!) v0 because v1 means "I commit to never breaking this API." Most Go modules should be v0.year.minor, eg v0.20.5 for the fifth release this year. You should only be using v1 if you have a lot of users, a set of core maintainers, etc. etc.

<comment><USER41> How does that make anything better for the user?

They know they cannot rely on a stable API, which means they have to carefully read the diff for every single upgrade, so saving no work over explicitly picking a major version.

<comment><USER40> The advantage is truth in advertising.

</comment></comment></comment><comment><USER42> Never realised this was a problem. How so?

Tag your version v2.0.1, import it as .../v2 in project - done. You don't even have to read docs or blog posts to understand it, just look at the source code of a new project, notice the ../vN part, see the corresponding tag in repo and do the math.

</comment><comment><USER43> I don't see any big problem. There is a blog post on the Golang website explaining everything. (My only complaint is there is no cheatsheet on golang.org for this) Also it's actually quite nice that it's possible to keep all maintained - and possibly incompatible - versions on the same branch without the overhead of a 3rdparty acting as package curator/distributor.

</comment><comment><USER44> I wonder if they should've just required v1 or v0 when using Go modules†, so that v2 and above didn't seem like a red-headed step child / surprising / non- obvious by comparison.

The basic idea of having separate import paths for non-compatible versions of a project seems, in fact, really good; an elegant solution to a tricky problem. It certainly seems much nicer than secretly using multiple versions of a package behind your back (especially when you consider that if this happens and a package uses mutable internal state, you could actually get broken behavior).

I guess for me the takeaway is in aggregate, people will be maximally lazy. You need to make the correct thing be the easiest thing.

(†Also release a patch to older versions of Go to just ignore v1/v0, and error for above, so you can have source compatible w/ both module and non-module Go.)

</comment><comment><USER45> The whole premise that the "communication of this rule has been weak" is rather weak. It has been hammered in throughout the development process of modules, and is part of the official documentation.

If the author has missed the numerous blog posts throughout the development, and hasn't read the official documentation, well, I'm not sure we can fault someone else for that.

Luckily, it appears that the community has picked up the memo somewhere, as there are quite a few v2+ modules around.

</comment><comment><USER46> It has gotten much better but in our project we got bitten by this. I gave a talk about it at GoSF last year if looking for some Go v2 modules schadenfreude :) [https://www.youtube.com/watch?v=8xAaZDSDWOc](https://www.youtube.com/watch?v=8xAaZDSDWOc)

</comment><comment><USER47> > Even as a seasoned developer, I found this write-up somewhat impenetrable

As is the usual case with these write-ups

</comment><comment><USER48> This is where "technical writer" profession shines, I know companies who have technical writing teams do excellent job there, but if we leave it for busy coders, that's what we got in the end.

</comment><comment><USER49> It's absurd that golang didn't take established solutions such as Java's packaging system, and had to re-invent the wheel in a completely suboptimal way.

</comment><comment><USER50> Modules had been in discussion for like years. Modules HowTo has been around from day one and it tells about this very clearly. Modules adoption rolled over a couple of releases which gave all the pointers they could..

Any minimally maintained project uses modules already. It is a must for any Go programmer to be skilled at managing modules because otherwise things just break. And yet it seems some people have lived under rocks.

People don't have time to RTFM, but apparently lots of time to complain and write about things they should have known with minimal due diligence around the tech they use. _shrug_

</comment><comment><USER51> The dep fans try to strike back again?? I hoped we are done with this...

</comment><comment><USER52> > I brought the issue up at my local Go meetup, and no one had ever heard > about the rule. They were very skeptical of me.

This resonates with my experience writing Golang (plus Bazel) this year. Anything that isn't working, you must have just messed up and did something wrong. It can't be that something is actually broken here.

Even in this comment thread, "stop complaining and just do it."

<comment><USER53> This kind of dismissive behaviour have been in the Go community since the beginning, unfortunately. It's the product of Rob Pike's behaviour and his rejection of "complexity". But you can't just dismissing complexity by deeming it irrelevant, it's there.

Ian Lance Taylor is probably the only person in the Go team that has a more pragmatic approach to things. The rest is a bunch of deaf people led by the blinds and a few vocal gatekeepers outside Google that will publicly humiliate you if you stray away from the current orthodoxy.

</comment></comment><comment><USER54> The Go Team has actually communicated this matter extensively through your blog ([https://blog.golang.org/v2-go-modules](https://blog.golang.org/v2-go- modules)).

<comment><USER55> This is mentioned in the article.

The problem is that the official solution, as mentioned in the article, seems really bad... you just have to copy the whole project into the `v2` folder, then do the same for a future `v3` and so on... it kind of goes against normal practices of using version control tools for this kind of thing, where each version would be in a different branch, not folder.

Not to mention having duplicate files like this can make finding files in your editor a bit confusing as well.

Though I like how Go solved dependency management and dared to go on a different path than almost every other package manager, this particular solution seems to go a bit too far?!

<comment><USER56> Or you could just have separate branches for major versions. That works too, and everyone seems to forget it.

<comment><USER57> I do only this. Copying the codebase into a subdirectory seems like a kluge. It baffles me that they recommend that solution; seems like too much backward compatibility.

</comment></comment></comment></comment><comment><USER58> What a mess. Starting with the GOPATH. This is far worse than the lack of generics which has had much airtime. For all the historical credits Pike and Thompson have, I don't know what they're doing here, it's making them look like buffoons; maybe they're not involved with this. I've mostly abandoned Go because of this ongoing red flag mess. Is there an end goal? The "we're watching the community" sounds like a weak excuse.

<comment><USER59> Ken has been retired for years.</comment></comment>


Elias M. Stein, Mathematician of Fluctuations, Is Dead at 87 - <AUTHOR> https://www.nytimes.com/2019/01/14/obituaries/elias-m-stein-dead.html <comment><USER2> "Two of his students, Dr. Tao and Dr. Fefferman, later won the Fields Medal, often considered the Nobel Prize of mathematics."</comment>


Mining Bitcoin with pencil and paper: 0.67 hashes per day (2014) - <AUTHOR> http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html <comment><USER2> You just need to be lucky and in 2 days you get 1 BTC…</comment>


Converting bad fat to good fat: a new means of tackling obesity - <AUTHOR> https://www.theguardian.com/society/2018/jun/10/converting-bad-fat-to-good-fat-a-new-means-of-tackling-obesity <comment><USER2> TL;DR: "The experiment did not show that the implanted mice lost more weight than a control group"</comment>


Ask HN: Any good alternatives to WOT? - jan-jakub After recent revelations about the ways WOT treats their users data (https://news.ycombinator.com/item?id=12870953), do you know of a Firefox add-on that would serve the same purpose and is worthy of users' trust? <comment></comment>


Why I created Favorize - <AUTHOR> https://medium.com/favorize/why-i-created-favorize-cc7604262d5f#.m01t0rn0m <comment><USER2> This is really neat. Great job. Only criticism, the headlines should be above the "meat" (favorized content). The headlines give the context. If I read the favorized part first I am often wondering what the heck the text is talking about.</comment>


30 US Companies Said To Be Violating EU Data Transfer Deal - <AUTHOR> http://techcrunch.com/2014/08/14/safe-harbour-cdd-ftc-complaint/

<comment><USER3> > Our investigation found that many of the companies are involved with a web > of powerful multiple data broker partners who, unknown to the EU public, > pool their data on individuals so they can be profiled and targeted online.

I would like to see the consumers' faces the day they understand that companies like Google have been tracking their every step on the Web via background requests to Google's properties such as Google Analytics - <USER2> ages.

</comment><comment><USER4> What are the implications of actually breaking this agreement? Does the FTC actually have the authority to fine these companies? If so, how much can they be fined?

<comment><USER5> Well, for one thing, it would mean these US organisations could fall foul of European law directly themselves, putting them at risk of sanctions if they have any people or assets within European jurisdiction.

For another thing, it would mean European companies _using_ these services could get in trouble for failing to honour their own data protection obligations to their own customers. Those companies are definitely within European jurisdictions, and they are therefore subject to European data protection regulators, and in some cases those regulators have significant teeth. So potentially this could see European businesses switching away from non-compliant US businesses to protect their own legal position.

Finally, this is not good news for the US government. Safe Harbor is already under scrutiny because the European authorities can't just turn a blind eye to US government snooping in the post-Snowden world, which means in reality no US business can truly claim to meet the Safe Harbor requirements, which means every European company that works with those US businesses has an element of risk now. Given that privacy vs. free speech is one of the widest cultural gaps between the US and Europe, and that if activist lawsuits start flying and European companies start to pull out then the US has much more to lose, this is really not a subject where the US government wants to rock the boat right now.

Bottom line: If these big US companies really are flagrantly violating the Safe Harbor deal, you can probably expect some significant pressure to be put on them by the US government to clean up their acts in the near future, and if they don't comply, you can probably expect that it won't stop there either.

</comment></comment><comment><AUTHOR> I'm curious to see which companies were examined - if any were investigated and were found to be meeting regulations, or could be held up as exemplary.

The paper details 30 companies investigated and found lacking, but no mention of how extensive the survey was. Was every single company they looked at in violation? Did they check out 100 companies and find 30 that didn't comply?</comment>


Everything Old Is New Again, and a Compiler Bug - <AUTHOR> https://randomascii.wordpress.com/2016/09/16/everything-old-is-new-again-and-a-compiler-bug/ <comment><USER2> The author of the article is obviously very experienced and extremely talented. Personally, I find it a tragedy that he is wasting his time on Windows, on a platform, which in his own words, _in the crazy world of Windows there are a lot of programs that think that injecting their DLLs into all processes is a good idea. Whether malware or anti-malware or something else these injected DLLs end up causing a good portion of all of Chrome's crashes. And in this case one of these injected DLLs decided that changing the FPU exception flags in somebody else's process was a good idea._

 _The fld instruction is part of the x87 FPU and it loads a floating-point value onto the x87's peculiar eight-register stack, so it seems initially plausible that it could have caused a FLT_STACK check._

 _Who designs a stack with just eight entries? Intel. It must have seemed like a good idea at the time._

Not to mention something those of us who grew up on Motorola MOS 6502, MC68000, SPARC, UltraSPARC and MIPS families always knew: intel might be really fast now, but under the hood, the architecture was and still is really, really shoddy. It's covered up by raw speed, but woe to one if they have to work with things "under the hood".

I chuckled, half in amusement and half in grotesque disgust, when I read the bit about the stack with only eight entries, because the first thing I thought of when I read that was of UltraSPARC and register windows, effectively giving one 256 stacks by means of i0-i7 and o0-o7 registers (which in reality are part of the r0-r31 physical registers). I'm kind of comparing apples to oranges, but the difference in design approaches is striking. What a contrast! intel designers were always bad, even from the very first 4004, through 8008 to 8086. Their two shots at making things right, the i960 and Itanium RISC processors were both epic failures. They are so bad at designing _clean, elegant architectures_ , that a competitor, Advanced Micro Devices, had to implement 64-bit extensions on _their_ processors, and then intel had to license that from them.

How much longer is intel going to be _the_ mainstream, I wonder? Is there any will for change of the status quo?</comment>


YouTube Instant Creator Accepts Job At YouTube - <AUTHOR> http://techcrunch.com/2010/09/24/youtube-instant-instant/ <comment><USER2> Super of the Youtube guys to follow through on this and great for him to see he actually got the job.

I'm pretty curious if we'll be able to spot his 'fingerprint' in the features that youtube will roll out over the next period.

</comment><comment><USER3> just playing devil's advocate here, but why is slapping together an API with some javascript worthy of a job offer? what's so exciting about YT instant? from hurley's twitter message, it sounds like he asked this kid to drop out of stanford to join youtube, which sounds a little crazy. maybe I just have no imagination.

(congrats to the kid in any case)

<comment><USER4> I agree and thank you for speaking what was on my mind as well. Anyone with moderate javascript skills could have a site like this up and running within 2 hours. I'm not even a fan of google instant though, oh well, to each his own.

<comment><USER5> People often say "I could do that" when seeing a Jackson Pollock painting. The key is they didn't, Pollock did. Hindsight is 20/20 and skills in executing are a dime a dozen. I'd be willing to be the vast majority of HN users could have coded up Youtube Instant. The differentiator is Feross actually did it.

</comment></comment></comment><comment><USER6> Normally, does getting a job at YouTube require the same hoops to jump through as getting a job at Google, or are their HR departments and processes separate still?

<comment><USER7> Though it's been a while now, back in 2007 I was offered a job at YouTube without going through the interview process because I co-developed the now- defunct Chime.TV ( [http://techcrunch.com/2007/06/12/chimetv-a-prettier-way- to-w...](http://techcrunch.com/2007/06/12/chimetv-a-prettier-way-to-watch- youtube/) ) and won the Mashup Competition that year. I even confirmed to make sure I wouldn't have to go through the crazy Google hiring practices and was assured that "If you say yes, you don't have to interview - you have a job starting tomorrow on my team at YouTube." It seemed like a very cool proposition too - my code would be visible to hundreds of millions of people immediately. I would've accepted it had my life circumstances been different.

</comment></comment><comment><USER8> "Interestingly enough, the ambitious Aboukhadijeh was a software engineer intern at Facebook when he created Youtube Instant."

Hm, I was under the impression Facebook didn't allow side projects. I suppose this doesn't apply to interns?

<comment><USER2> Programmers will do 'side projects' in their heads when you tie their hands, it's like painters having to paint and writers having to write.

Not allowing side projects is opposing a force of nature.

Silly move by facebook.

<comment><USER9> I've worked at Facebook all summer as an intern. Never have I been aware of any company policy that forbids side projects.

<comment><USER2> For interns that would be pretty weird anyway, after all, it's not like they are under the kind of employment contract where you could reasonably make the case for that.

In fact, your best interns probably do have side projects.

</comment></comment></comment></comment><comment><USER10> I am sorta envious of the guy.

</comment><comment><USER11> >Interestingly enough, the ambitious Aboukhadijeh was a software engineer intern at Facebook when he created Youtube Instant.

Ouch. Does that mean Facebook own the rights?

Because IT staff are not much more than slaves in our world: anything you create while employed is property of the employer, even if the work is done in your own time.

</comment><comment><USER12> Ah jezzz, next is a movie deal!

</comment><comment><USER13> What is YouTube Instant?

<comment><USER14> <http://ytinstant.com/>

<comment><USER13> Yeah, couldn't find the about page.

Is it just an AJAX-based Youtube search autocomplete that pulls up the results and then makes am autoplaying playlist?

<comment><USER14> yeah, and google instant is just a google search that pulls up results as you type them.

<comment><USER13> Are you trying to get a rise out of me, sir?

<comment><USER14> just pointing out the fact that you can make a lot of things sound trivial if you try :)

</comment></comment></comment></comment></comment></comment><comment><USER15> Poor guy. And I mean it.

Google is a big mess of hierarchy, (yes, they're much better than the average -- that's not saying much). Their "eternal" startup mantra is just that. Looks like the world has lost yet another good hacker to the halls of the Googleplex.

I hope he loves it. Unfortunately, I don't think he will.

Kudos to all the work put in for YouTube Instant. Good luck to your future at YouTube!

<comment><USER9> Hey, author of YouTube Instant here. I just want to say one thing: I'll never stop hacking. Expect to see lots more from me in the future!

<comment><USER16> I want to publicly thank you for being cool and answering a question I had about ytinstant by email. Your instinct for hacking is an inspiration.</comment></comment></comment>


Cyborg Beetles with Remote Control - <AUTHOR> http://www.technologyreview.com/biomedicine/22111

<comment><AUTHOR> Ethically and scientifically, this seems stunning: a radio receiver is attached to a live beetle, with probes inserted capable of flight instruction. And these are inserted in a pupal phase, so as to not be visible in the adult.</comment>


Ask HN: Recommended Open Source Projects for a CS Junior? - <AUTHOR> I'm looking to start contributing to some Open Source projects but there are so many that it's daunting to choose one. My interests are compilers and HPC and my preferred languages are C/C++, OCaml, and Fortran. But I'm open to hearing about any projects. Thanks, guys! <comment><USER2> This may be an unpopular opinion, but I've never understood why so many people recommend contributing to open-source projects if you are a CS student or beginner. It's a fantastic way to feel inadequate in your ability to write code. If you pick a large open-source project your skills may not be up to scratch to help out in any meaningful way. Even with smaller tasks, a lot of larger projects have enough structure in place to ensure that trusted developers are working on key parts of the project, so it's likely that getting involved will take a lot of effort.

There's definitely an argument for contributing to open source projects, but I'd recommend finding small utilities over big-name projects. These have their own dangers with contributors often abandoning projects, or ignoring issues/pr's, but it's a much easier way to get involved and get some open- source contribution cred on your CV/resume.

As others have said, the best approach would be to create your own project, and should things go well there maybe look into seeing if there are any now- defunct projects you like the look of that would consider handing the reins over to you to maintain.

One last option would be Google's Summer of Code. It's too late to join in for this year, but it may be worth it next year if you're serious about contributing to a big-name project. The acceptance rate isn't great (I applied three times and didn't get in once, but this was years ago), but given your niche interests you might be a perfect candidate for a handful of projects.

</comment><comment><USER3> I recommend the awesome for beginners list. [https://github.com/MunGell/awesome-for- beginners](https://github.com/MunGell/awesome-for-beginners)

It's a bunch of beginner welcoming open source projects with a supportive team to help you initiate in the open source world.

<comment><USER4> Fantastic resource.

</comment></comment><comment><USER5> Probably not the answer you were looking for, but one of the best ways is to simply just _make_ something of your own. At the very least it's good practice, and you just might make something people find useful if you've found an 'unscratched itch'.

Even failing that, your codebase can be an educational tool for others. rosettacode.org is a pretty solid example of this--any addition to the wiki is going to save someone's bacon at some point.

But to be more specific for a moment: I see you have a functional-ish language listed (Ocaml) and you've also mentioned compilers--If you're looking for low level stuff with a hint of FP, diving into Rust might be interest you. I'd suggest looking at Redox OS--it's a monster, but plenty of the big scary parts are modularized away. Might be interesting.

<comment><USER6> I wish I had worked on other people's codebases earlier. Its a bit daunting when starting out but the art of understanding a codebase is invaluable and you'll learn how others use a language in interesting different ways

<comment><USER7> How would you describe practicing 'art' of learning a codebase? Surely there's a more efficient way than to just stare it down for weeks on end.

</comment></comment></comment><comment><USER8> In my experience, the trick is finding the sweet spot between something you use every day and your abilities. I don't contribute to Ubuntu, because I have very little understanding of what's going on there. I do contribute to my lab's software Nengo and other libraries I use, because I understand the code layout and where I can contribute. Consequently, maybe it's a good idea to make a decision matrix based on these criteria?

<comment><USER9> Yeah, this I think is the most important. You can't just pick up some OSS project and start working away, it's usually a lot easier if you've been a consumer of the project before. I've contributed a lot to several big JS projects (Webpack, Grunt, npm) because they were missing things which I needed and it turned out to be easy enough to just add them.

</comment></comment><comment><USER10> Most people will say that the motivation to work on a problem should come from you being really excited about the problem domain. Play around with someone else's code, trying to do something interesting to you that's just barely on the edge of what the provided code can do. Then, when you realize you just need that one feature to do something awesome, you can write it yourself. Don't contribute to open source because you feel like you should, contribute to open source because you want the project to have the features you're contributing.

</comment><comment><USER11> Pick something that you use in a language that you're familiar with. Look for github/jira issues tagged something like: 'good-first-issue', or just interesting issues in general.

Honestly you will learn a lot just setting up a project and getting the tests to pass if you haven't done that before.

</comment><comment><USER12> I've heard that [https://up-for-grabs.net/#/](https://up-for-grabs.net/#/) is a good place to look to find projects that have issues that are beginner friendly.</comment>


Astronomers Spot First-Known Interstellar "Comet" - <AUTHOR> http://www.skyandtelescope.com/astronomy-news/astronomers-spot-first-known-interstellar-comet/ <comment><USER2> This is really exciting news. Not only did we find an interstellar comet but we found it using the Pan-STARRS telescope. With the LSST coming online soon which is the next generation of survey telescopes we can expect to find many more interstellar comets that previously expected.

[https://panstarrs.stsci.edu/](https://panstarrs.stsci.edu/) [https://www.lsst.org](https://www.lsst.org)</comment>


Silurian hypothesis - <AUTHOR> https://en.wikipedia.org/wiki/Silurian_hypothesis <comment><USER2> Part of this is the realization that backward (or forward) tens of millions of years or more is a place as awesomely distant as a star hundreds of light years away. Billions of years may as well be another galaxy. Time as well as space is vast, and we really can't see details very far. There could have been two or three "flowerings" of high intelligence on Earth so far and we would have little direct evidence.

<comment><USER3> Definitely! I often wonder about the evidence (who knows if the dinosaurs had computers and mechanical flight for a short time(geologically speaking)?) How could we?

[Edited to make it clear I was talking about airplanes]

<comment><USER4> > Definitely! I often wonder about the evidence (who knows if the dinosaurs > had computers and mechanical flight for a short time(geologically > speaking)?) How could we?

We've found fossilized dinosaur bones in silted up riverbeds, but no dinosaur- era subway tunnels that silted up with what would now be mudrock. If dinosaurs had computers and mechanical flight, they'd almost undoubtedly have had subways, sewers, and bunkers that we could find at least trace evidence of.

<comment><USER3> I don't know if subways would have fossilized if they were only around for 1000 years, 60-120 million years ago.

<comment><USER4> > I don't know if subways would have fossilized if they were only around for > 1000 years, 60-120 million years ago.

I think you misunderstand. The extent and location of the systems would matter more than the duration of their use. What we'd be looking for is the geological result of artificial tunnels filling up with sediment that then undergoes normal geological processes to solidify into rock.</comment></comment></comment></comment></comment>


Language-oriented software engineering: a book review of Clean Architecture - <AUTHOR> http://parametri.city/blog/2018-12-23-language-oriented-software-engineering/index.html <comment><USER2> > There are some good ideas on architecture, but they are presented with too > much fluff and imprecision

Would you like to highlight some of those?

<comment><AUTHOR> It boils down to DSLs with interpreters, using underlying primitive actions in a command pattern. The interpreter allows for optimizations. Using the idea repeatedly allows for the formation of boundaries, key ideas is to treat a framework as a bundle of commands and write an interpreter for that. Not many good resources in my opinion; I'm not fully sold on the free monad or tagless final stuff, mainly because I find it hard to read despite a good amount of study.</comment></comment>


NASA Tests LDSD 'Flying Saucer' - <AUTHOR> http://www.ustream.tv/channel/5808990 <comment><USER2> From [http://www.nasa.gov/mission_pages/tdm/ldsd/](http://www.nasa.gov/mission_pages/tdm/ldsd/)

# Low-Density Supersonic Decelerator (LDSD)

As NASA plans ambitious new robotic missions to Mars, laying the groundwork for even more complex human science expeditions to come, the spacecraft needed to land safely on the red planet's surface necessarily becomes increasingly massive, hauling larger payloads to accommodate extended stays on the Martian surface. Current technology for decelerating from the high speed of atmospheric entry to the final stages of landing on Mars dates back to NASA's Viking Program, which put two landers on Mars in 1976. The basic Viking parachute design has been used ever since -- and was successfully used again in 2012 to deliver the Curiosity rover to Mars.

NASA seeks to use atmospheric drag as a solution, saving rocket engines and fuel for final maneuvers and landing procedures. The heavier planetary landers of tomorrow, however, will require much larger drag devices than any now in use to slow them down -- and those next-generation drag devices will need to be deployed at higher supersonic speeds to safely land vehicle, crew and cargo. NASA's Low-Density Supersonic Decelerator (LDSD) Technology Demonstration Mission, led by NASA's Jet Propulsion Laboratory in Pasadena, Calif., will conduct full-scale, stratospheric tests of these breakthrough technologies high above Earth to prove their value for future missions to Mars.

</comment><comment><USER3> Description: [http://www.nasa.gov/mission_pages/tdm/ldsd/](http://www.nasa.gov/mission_pages/tdm/ldsd/)

Seems to be trying to figure out how to save fuel by relying on atmospheric drag to rapidly decelerate on descent to, say, Mars with extremely heavy payloads.

News conference: [http://www.ustream.tv/recorded/48346813](http://www.ustream.tv/recorded/48346813)

"Current technology for decelerating from the high speed of atmospheric entry to the final stages of landing on Mars dates back to NASA's Viking Program, which put two landers on Mars in 1976. The basic Viking parachute design has been used ever since -- and was successfully used again in 2012 to deliver the Curiosity rover to Mars."

Viking program: [https://en.wikipedia.org/wiki/Viking_program](https://en.wikipedia.org/wiki/Viking_program)

</comment><comment><USER4> Intro video specifically about this test:

LDSD: The Great Shakeout Test For Mars

[https://www.youtube.com/watch?v=3YwSXAba6Ik](https://www.youtube.com/watch?v=3YwSXAba6Ik)

<comment><USER5> Is this Mark Adler - one of the author of zlib? According to this it looks like it's him: [http://en.wikipedia.org/wiki/Mark_Adler#Mars_Exploration_Rov...](http://en.wikipedia.org/wiki/Mark_Adler#Mars_Exploration_Rover_mission)

<comment><USER6> Yes, that would be him, he's amazing. He not only works on making Mars habitable, he's also partly responsible for the most popular image format on the web today.

Full respect.

</comment></comment></comment><comment><USER7> The video feed is raw, no commentary and little editing, just FYI. If you want to figure out what's going on, you need to read up on background info and also listen for 10-20 minutes :P

As of 4:32 EST, it looks like a live video feed should start coming from the vehicle soon (within minutes), but timelines are changing every few minutes. I think the parachute deployment is still on schedule for 4:51 EST.

[Edit: There are now commentators, so it's a bit easier to figure out what's going on and follow the progress.]

</comment><comment><USER8> Here is a timeline of the test: [http://www.nasa.gov/jpl/ldsd/pia18451/](http://www.nasa.gov/jpl/ldsd/pia18451/)

</comment><comment><USER9> Looks like the parachute failed to deploy cleanly.

<comment><USER10> You can watch the air density as it falls, it was so still at the highest altitude.

<comment><USER6> Tell ya what, In KSP I'd have waited another 30 seconds or so to deploy that 'chute... But I don't work for NASA, and that's probably why not :-)

</comment></comment></comment><comment><USER11> Does anyone know why the live footage looks like it was taken using a security camera from the 80s?

<comment><USER6> Didn't you know that all "space" footage is actually from a government sponsored set where they invented chroma-key compositing? Kubrik was in on all of it. Take my word for it...

</comment></comment><comment><USER12> I have a distinct feeling that someone really tried to make the acronym spell "LSD".

Speaking of which, does anyone here know how acronyms are created at NASA? Is it by committee or does someone just make a name that kind of sticks?

</comment><comment><USER13> Damn, headline isn't NASA Tests LSD In Flying Saucer.

Maybe next time.</comment>


Atom: Editor window startup is slow - <AUTHOR> https://github.com/atom/atom/issues/2654 <comment><USER2> Amazing that so many comments compare Atom performance to Sublime and TextMate, but do not mention the fact that Sublime and TextMate are native while Atom is based on Electron. They profile module loads etc, but fail to recognize that Atom first has to start layout engine and JS engine, then initialize all that code and only after that it can start executing application code. As a personal rant, and performance issues aside, HTML5+CSS+JS is a terrible programming paradigm, unfortunately the only one that stuck for web apps. But to use the same paradigm on desktop????

<comment> Spartan-S63 I think it's important to keep drawing the distinction, but you're right, the thread didn't really point out the difference and that's what's missing in the conversation.

I think it's important to remind everyone of the world we used to live in where apps were native to the platform they ran on and were performant and power efficient. I think that's even more important than ever to remember now.

That said, somehow Microsoft has pulled off a miracle with VS Code as it's reasonably efficient and performant given the tech stack it's implemented on top of. I think a lot of this has to do with Microsoft being a company that established itself in OS and native application development for Windows. They have an ethic of performance whereas GitHub may not have had that at the time that Atom came on the scene.

</comment></comment><comment><USER3> This issue is from 2014 with last activity in November of last year. It was just marked as stale 15 days ago by a repo bot.

Am I missing something as to why this was posted?

<comment><USER4> Maybe because it's been closed recently?

</comment></comment><comment><USER5> That's interesting. Atom (last I checked) shows you profiling of how each package contributes to start-up time, and it's always been slow regardless. It seems like it's been consistently slow for 5.5 years now, which is unfortunate.

Start-up time was the number one reason I was not sold on the Luna language editor -- they were building it on top of Atom! (they are rebuilding it though, or maybe that is already done)

<comment><USER3> The profiler is nice but Atom was still too slow for my tastes. Then I found Sublime and plugins to replicate my Atom customization. I cannot go back to that.

For apps like Slack, I'm perfectly content with Electron.

</comment></comment><comment><USER6> I tried atom in the past and felt the definite slowness by comparison to other text editors, I would definitely need to check it out today to see if anything has changed. I currently use vscode and it feels really snappy for the practically the same functionality.

I also find it interesting that Microsoft is looming over both of these projects, I wonder what that will mean for the future.

</comment><comment><USER7> Issue recently closed by Stale-bot, not updated since Nov 2018.

IME Atom is not nearly as slow as it used to be, unless you're on a remote FS or have many, many files in the project directory - like it scans them all when starting - so I just keep my project directory small.

<comment><USER3> Should you have to do that though?</comment></comment>