Mercurial: Onward and upward - <AUTHOR> https://blog.bitbucket.org/2015/04/30/mercurial-onward-and-upward/ <comment><USER2> Key paragraph for us mere mortals:

"In my time with Mercurial, I have seen it grow in fascinating ways. These include the concept of changeset evolution coming to life and the announcement of both Facebook and Google choosing Mercurial over Git. The future of Mercurial is that of scalability and because of that, I believe the best days of Mercurial are ahead."

Is it time to give Mercurial another shot? I first migrated from SVN to Mercurial way back when - but after the massive increase in Git's popularity I bit the bullet and switched.

What does Mercurial have over Git _today_?

<comment><USER3> > What does Mercurial have over Git _today_?

There exists no easy tutorial, that takes a beginner up to speed with git. You need to read almost a book length of material and familiarize yourself with some of the git's internals, and to some extent build your own mental model of git by experimentation, before you can use git without regular wtf-moments.

Well, there is also no tutorial that would provide the same level of understanding of the internals of Mercurial, but by some magic it seems that beginners do not _need_ to acquire the same depth of understanding of Mercurial that they need to acquire about git, before they can start to work with Mercurial without wtf's and frustration.

Once you have a solid understanding of how DVCS's work, you can use both Mercurial and git without problems. But if you need to bring a bunch of beginners up to speed, somehow it goes easier with Mercurial.

At least, this is my experience. If someone else has experience in training teams to start using a DVCS, and has compared both git and Mercurial, and has opposite experiences, I'd be interested to hear.

<comment><USER4> I simply don't agree with this. There's nothing wtf about git add, git commit, git push. Those are the commands that normal developers use. Maybe git reflog has issues but 90% of people are never going to come across them.

<comment><USER5> Nothing about that deals with collaboration.

fetch/merge/pull/remotes can be pretty confusing without really wrapping your head around it.

<comment><USER4> What is wtf about git pull?

> git pull origin master

(fix conflicts)

> git commit

That's it.

<comment><USER6> 1) Pull creates a merge commit. Why?

2) What's a fast forward?

3) What's a tracking branch?

<comment><USER7> 1) So you can revert the merge very easily. 2) Merging without a commit. 3) A branch on a remote server that you have a copy of locally and you want to keep track of the status of remote against the local copy (who's behind and who is ahead?).

This is my basic understanding in terms of how I use git. I like Mercurial too and don't have a horse in this race.

<comment><USER8> While this somewhat underscores some complexity in git, here's something I wrote trying to explain to others why and how to avoid those merge commits:

[http://michaeldehaan.net/post/116465000577/understanding- whe...](http://michaeldehaan.net/post/116465000577/understanding-when-to-use- git-rebase)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Mercurial was a real eye-opener. Before a friend basically made me try Mercurial, I was using Subversion for managing my private projects, and it was not exactly fun. Especially when I was working on my laptop (netbook, actually, but that is totally OT), away from home, without access to the server.

Mercurial made VCS fun. I recently moved on to Fossil, because I do like the integrated wiki and ticket system for smallish projects, but without Mercurial I never would have gotten there.

I also like Mercurial's hooks. I am not sure if other DCVS support that, but hooks are great. (Fossil doesn't appear to have them)

<comment><USER10> I agree that hooks are awesome, I use numerous hooks with git to do everything from syntax check Perl scripts, to uploading DNS zones.

</comment></comment><comment><USER11> I'm excited to see improved mercurial support at bitbucket in the near future. While bitbucket's support for mercurial goes back many years, mercurial itself has evolved a lot in the meantime, and bitbucket has been focusing more on support for git for several years now. At the very least, I'm glad they have someone on staff who cares about mercurial so new features don't break things for mercurial users.

</comment><comment><USER12> > The future of Mercurial is that of scalability and because of that, I > believe the best days of Mercurial are ahead.

That sounded to me like Mercurial has started to carve their own niche after losing the popularity war to git (maybe just my wishful thinking?), and this may have very good outcomes since currently all scalable mainstream vcs choices are centralized.

Git developers showed they're hardly interested in this area, and Mercurial have had some head start with the contributions from Facebook. I don't think anybody would object it if we had a free dvcs that can respond to very high scalability needs without hacking around its deficiencies. This is the point where Mercurial project should reconsider its priorities and even put some of their current priorities into back seat if that's what it gets to achieve their new goals with no compromises.

My best wishes for Mercurial, go for it!

</comment><comment><USER13> I love all the new things the mercurial developers are willing to experiment with and try out. It seems the (sometimes maligned) plugin system that mercurial uses makes this easy. It's been really interesting to see how our (mercurial developers' and users') ideas about how distributed version control can and should be used have morphed and changed over the years. I remember when mercurial's branching recommendation was to have a clone per branch and when we all hated the idea of modifying our history. Now mercurial supports 4 different branching models and has excellent history editing support with commit --amend, rebase, histedit, and changeset evolution. I'm excited to play with the other new features that are coming.

</comment><comment><USER14> > These include the concept of changeset evolution coming to life and the > announcement of both Facebook and Google choosing Mercurial over Git.

Perhaps this is true for Facebook. But I can say that Google most certainly does not use Hg over Git. The Go source code used to be under Hg, but they've recently migrated to git.

<comment><USER15> I'm guessing it depends from project to project? There are several Google developers contributing to Mercurial.

<comment><USER16> If you look at development at Google, you'll see most people on a perforce derived repo system , then groups like Android, chrome, Etc on git, then basically very few teams using Mercurial.

We do have some hg contributors like augie, but we have way more git contributors, includes git project Lead Junio.

</comment></comment></comment><comment><USER17> I'm very excited about bitbucket improving their hg support. The blog poster, Sean Farley, was previously working on Kallithea before going to work at Bitbucket. I met him during Pycon. From my understanding, he's still allowed to work on Kallithea.

I'm excited about Mercurial's future. There are so many great things coming out. New ways to handle branching, shallow and narrow clones, an experimental interface for running hg over a git store...

<comment><USER18> _> an experimental interface for running hg over a git store_

It would make me very happy to be able to interact with Git repos through an interface that didn't make me want to kill myself with a rusty railroad spike.

<comment><USER17> Well, if you are feeling adventurous,

[https://bitbucket.org/durin42/hgit](https://bitbucket.org/durin42/hgit)

</comment></comment></comment><comment><USER19> I started with and loved Mercurial as a DVCS, and it still has some QoL commands that Git requires some hoop-jumping to get at, but ultimately the deciding factor was the inability to permanently delete branches. Since branched dev work would fairly regularly have generic names or the names of the developer working on it, it would always end up being forked and merged instead of branched and merged, which led to a ridiculous number of headaches in our build system.

We still use mercurial for most of our repositories just because they're dated and not likely to see more than a handful of commits a year, but most of our active development work has already converted to git.

<comment><USER3> > inability to permanently delete branches

If your workflow fits better with git-style branches, you should use Mercurial bookmarks, not Mercurial named branches.

Mercurial even tells you:

        (branches are permanent and global, did you want a bookmark?)

every time you create a named branch.

<comment><USER20> Well, IMHO, nowadays this classifies as bad design. It may have been the better design, but currently git's nomenclature is the standard and not complying to it will only hurt mercurial.

<comment><USER11> Mercurial and git were initially released within a couple of weeks of each other. To change terminology now would break ten years of backward compatibility.

<comment><USER20> I understand that, but my point is still valid. Mercurial is not "guilty" about this, but certainly suffers

</comment></comment></comment></comment></comment><comment><USER21> I wish Bitbucket would invest some time implementing 2FA. It's 2015.

[https://bitbucket.org/site/master/issue/5811/support-two- fac...](https://bitbucket.org/site/master/issue/5811/support-two-factor- authentication-bb-7016)

</comment><comment><USER22> It seems to work OK but monthly releases for version control software scares the heck out of me.

<comment><USER17> Don't be scared. Mercurial is _very_ conservative about what a new release can do. There are lots of rules, and they are treated very seriously:

[http://www.mercurial-scm.org/wiki/CompatibilityRules](http://www.mercurial- scm.org/wiki/CompatibilityRules)

</comment></comment><comment><USER23> Mercurial user for the past 6 or 7 years here. I cling to Mercurial despite people asking me to move some of my side projects (nothing substantial though) to git and github.

I refuse to do that out of principle. I think Mercurial should have taken the place of git as the widely used DVCS. And I try to be THAT change I want to see.

That being said, It would be great if someone can get the hg-git plugin to work seamlessly with newer versions of Mercurial on Windows and Linux, so that I can keep using Mercurial even if a project I am involved in uses git.

<comment><USER24> I was really surprised that Git "won" because I thought that Mercurial's friendlier CLI and being written in Python would give it an advantage. I think I underestimated how good it makes people feel to understand something incredibly complicated. I guess immutable history was a turn off for many people as well.

This fake interview is pretty funny:

"Linus: Git has taken over where Linux left off separating the geeks into know-nothings and know-it-alls. I didn't really expect anyone to use it because it's so hard to use, but that turns out to be its big appeal. No technology can ever be too arcane or complicated for the black t-shirt crowd."

[http://typicalprogrammer.com/linus-torvalds-goes-off-on- linu...](http://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and- git/)

<comment><USER25> That is a clever fake interview quote, but the whole notion that hg's "easier" interface should have made it won misses the point. hg's interface is more familiar (especially since we were mostly all coming from subversion at the time). Git won because it's workflow is so much better than mercurial's. Light-weight branches are better than hg branches (I know they have bookmarks now but I don't recall if they had them back then). The index is a fantastic idea that makes writing clean commits easy (I think the comparable hg option at the time was mercurial queues which are much more cumbersome to work with imo). Rebase is functionality that hg didn't include out of the box. Being able to edit commits in git is something I greatly appreciate for fixing typos and stuff.

tl;dr: the interface of mercurial may be more straightforward, but git won because it allowed people to work better.

<comment><USER26> You're right that Mercurial didn't have bookmarks until years after Git had branches. There were various things you could do to get a similar effect (eg having a branch with multiple heads), but none quite as good, and it took the Mercurial team a long time to come around to the idea.

I have to disagree about the index, though. I use Git every day, and i'm still struck by how pointless the index and the idea of staging is.

Ditto rebase. The routine use of rebase still seems completely wrongheaded to me. Mercurial's convention of preferring merges is better, and the last few years' developments around safe evolution of history really show rebase up as the misconceived hack it is.

Mercurial got 'commit --amend' a long time ago, but even before that, it had 'rollback', which undoes the last commit, leaving the working tree untouched (that is, with the state it had in the commit), so you can make your fixes and commit again.

I'd entertain the argument that Git won because it was better if even a handful of the people who now use Git had learned both Git and Mercurial and made an informed choice between them. That simply does not appear to be the case. Git got ahead because Linus invented it, and won because of GitHub.

<comment><USER27> staging is wonderful. I'm sure hg must have something similar.

I can't tell you how many times I've shot myself in the foot accidentally committing stuff to svn when I just meant a single file.

<comment><USER28> I don't use hg much these days but you can just pass the file(s) you want to commit to 'hg commit'; no need for staging. Even better, hg (or its shell integration at any rate) has tab completion so it's easy to go though the modified files and pick those you wanted to commit. I kinda miss this now I'm working with git mostly.</comment></comment></comment></comment></comment></comment>


Secure Docker out of Docker (DooD) with Nestybox System Containers? (2019) - <AUTHOR> https://blog.nestybox.com/2019/09/13/system-containers.html <comment><AUTHOR> A Nestybox system container is an enhanced Docker container, designed to package not just applications but also low-level system software.</comment>


The gradual decline of RSS readers - <AUTHOR> http://www.readwriteweb.com/archives/rss_reader_market_in_disarray.php

<comment><USER2> Seems like I've been hearing about the death of RSS a lot in the past two years, but as an avid Google Reader user, I can't imagine not having RSS today.

The article states: "I for one still maintain a Google Reader account, however I don't check it on a daily basis. I check Twitter for news and information multiple times a day, I monitor Twitter lists, and I read a number of blogs across a set of topics of most interest to me."

Anyone else do this? How would Twitter be a more useful way to monitor news?

<comment><USER3> "How would Twitter be a more useful way to monitor news?"

Assuming that you follow interesting people who are interested in similar things that you are, it's likely that you could be informed of a news story that matters to you faster than by going through an RSS feed.

<comment><USER4> The fact that URLs are usually obscured, and the accompanying text on Twitter is usually too brief to efficiently indicate the nature of the link, I generally find Twitter not to be a very effective way of keeping track of things I'm interested in.

And the speed at which I'm informed is usually not important to me. I don't have a professional or personal need to be kept informed about time-critical information. Instead, I'm much more interested in insight, opinion and analysis.

</comment></comment></comment><comment><USER5> From my personal experience, twitter is not a good medium for keeping track of news. Unless you follow less than 100 people who tweet moderately, the volume of tweets is overwhelming.

Often it takes more time to scan through tweets rather than articles because, first the URLs have to opened by the browser which is an additional step from RSS reader. Also in the case of RSS you know pretty much the kind of stories that a site is going to post but when you follow someone you will most likely get a wide variety of tweets, lot of which you will not be interested in.

When an important story breaks, twitter becomes an even bigger echo chamber than RSS because some 10s of people will be linking to techcrunch, another bunch will be linking to the nytimes coverage and weeding out these dupes is painful

</comment><comment><USER6> Instead of calling this a decline I would call it a consolidation. Google Reader does everything I need a RSS reader to do. It works on my desktop and it works on my iPhone, need to synchronize between them since it is all on the web. All the readers I tried on the iPhone sucked and I've never seen a need to try one on the desktop.

As for using twitter, Facebook, etc. for following news -- that doesn't work for me. Those kinds of services are good for news that your social circle are interested in, but for following those uniquely valuable sites a RSS reader is still essential.</comment>


First Atari Hotel to Begin Construction in Phoenix in Mid-2020 - <AUTHOR> https://atarihotels.com/news/atari-announces-world-class-video-game-themed-atari-hotels-first-atari-hotel-to-begin-construction-in-phoenix-in-mid-2020/ <comment><USER2> > "Let's face it, how cool will it be to stay inside an Atari?!" said Napoleon > Smith III

I have a feeling he's going to be very disappointed by the answer to this question.

<comment><USER3> If it's anything like working at Atari was, they'll "have layoffs" in the middle of the night and eject you onto the street around 2AM. Good luck getting your luggage. :0)

</comment></comment><comment><USER4> Just an FYI, nothing branded "Atari" in the last 20 years or more has had anything to do with the home computer/console maker. The brand has been passed around and milked for recognition.

<comment><USER5> Disclaimer : I'm a shareholder.

Atari is now owned by French video games company Infogrames which renamed itself as Atari, and it is publicly listed. They bought back all of the liquidated american brands and since 2013 they've done a ton of work to get it out of debt (which is now done).

So, they effectively own pretty much all of the original IP and brand, it's just that the company is a rebirth with a new staff and new ambitions. Mostly, they work through partnerships, with little in-house dev, kind of like what a movie producer would work with a few movies licences.

<comment><USER6> Correct. Which means, as smolder said, the Atari we all remember and love is long gone. The Atari that exists now is nothing but a brand.

</comment></comment></comment><comment><USER7> So, a mediocre hotel with Atari logos on everything and maybe some big Pole Position graphics painted on the walls of the lobby. And a few sets of VR goggles that will immediately become broken and unmaintained?

</comment><comment><USER8> Good, they're on track to complete their Los Angeles infrastructure by 2049: [https://bit.ly/2OwBYNi](https://bit.ly/2OwBYNi)

</comment><comment><USER9> >Hotel development and design is being led by Shelly Murphy's GSD Group and Napoleon Smith III, producer of the wildly successful Teenage Mutant Ninja Turtles film franchise reboot.

Interesting choice.

<comment> jagged-chisel I take issue with "wildly," but I suppose it's hard to argue with a 4x ROI... :-/

</comment></comment><comment><USER10> I bet the final hotel, if it ever gets built, will not have the architectural swooshes.

Those useless details are there for PR when sharing the renders, and are immediately dumped afterwards.

</comment><comment><USER11> Isn't Phoenix mostly just a connecting hub? If I'm going to vacation in a ridiculously hot, dry, arid place, it's gonna be Vegas, likely by way of a layover in Phoenix where I don't even leave the comfort of the airport. Although, it has been a few years, so maybe things have changed, unlike Phoenix's climate.

<comment><USER12> Vegas is getting an Atari hotel as well.

</comment></comment><comment><USER13> Isn't the point of visiting a place to experience it? What's the point of flying/driving somewhere only to put on a VR headset when you arrive?

<comment><USER14> I suspect the hotel would attract conference groups focused on gaming and tech.

<comment><USER15> Trying to impress people from those groups with hotel-supplied VR headsets would trap them into a pretty heinous rendition of the Red Queen's Race.

I'm guessing sci-fi and furry conventions would offer a better product-market fit. By definition, most the people there are there on leisure time, so they'll be generally more interested in playing. And the crowd won't be a bunch of people who are making a career of rendering all the hotel's expensive electronics obsolete.

</comment></comment></comment><comment><USER16> History will look back on mine as the manchild generation. Can't say I'm not doing my part, though

</comment><comment><USER17> Why can't they start in the bay area where we desperately need to build hotels. Any hotels. Phoenix does not strike me as a thriving hotel market.

</comment><comment><USER18> I like this idea of mixing real and virtual

<comment><USER19> so AR? :p

<comment><USER20> An AR _hotel_, specifically. If done well, it could create an entirely new kind of vacation experience, especially in areas that do not naturally get a lot of tourist traffic.</comment></comment></comment>


Ulrich Bretscher's Black Powder Page (2006) - <AUTHOR> http://www.musketeer.ch/blackpowder/homemade_bp.html <comment><USER2> There's an accurate description of black powder production in Cormac McCarthy's _The Blood Meridian_. Done during a trek through the desert, so they used urine instead of water. I wonder if the urea helps. Anyway, when I was a kid, I had an old recipe book. I used gum Arabic as a binder.

<comment><USER3> It's certainly possible the urea helps. I know that Cody from Cody's Lab used urine to get nitrates when he made black powder. He did, however, let the urine sit, to allow bacteria to break it down.

<comment><USER2> The Priest purified potassium nitrate from bat guano.

And now I find that urea is a stabilizer, which increases the ignition temperature, and reduces the risk of accidental ignition.

> I have found that the above objects are accomplished when the black powder > composition contains a stabilizing ingredient consisting of a solid organic > basic compound. While the inclusion of such an ingredient is particularly > desirable in black powders containing ammonium nitrate as a portion of the > oxidizing material, I may include this stabilizer to advantage also in all > types of black powders. Various compounds-may be used, with beneficial > results, preferably from the class of solid aliphatic basic compounds, for > example guanidine, dicyandiamide, urea, and the 5 like. Various aromatic > basic compounds likewise may be employed, such as diphenylamine. Preferably > I make use of urea for bringing about the desired results.

[https://www.google.com/patents/US2030096](https://www.google.com/patents/US2030096)

But that's a 1936 patent, so the Priest was either prescient or Corman was anachronistic.</comment></comment></comment>


Ask HN: Leaving Big Company for Startup - <AUTHOR> First, thanks to anyone who reads this and gives their honest opinion. I know this audience includes some of the most experienced people out there in the startup and large company realm.
I am a Statistician/data scientist for a large energy company. I have my job down to where I have written programs to automate most tasks and my company allows me a lot of freedom and time off to do what I want. I am taking courses during the day at a top 30 university in computer science. I have done a lot at my job, but feel it is in a traditional space. I fear working in this traditional area may not get me where I want to go. My goal is to work as a data scientist for a top tech company, i.e. Google, Facebook.
I have a masters in statistics and my bachelors is in math and economics, however, most of the people I see at top companies in my field hold PhDs. So, while working at this company I have been taking the necessary courses to get into a computer science PhD program, specializing in machine learning.
A friend from grad school approached me and asked if I wanted to work as a data scientist at the startup he works for. I would have the chance to co-lead a data science team and really influence the company. I would get a raise and would have more responsibility, but would have to stop going to school. He works at a fintech company similar to Affirm (affirm.com); smaller than affirm but established (~100 employees).
What route do you think would further my goals, staying at the energy company and working towards a PhD, or taking going to the startup which offers more responsibility and the chance to really impact the company?
Thanks again for any honest opinions. <comment><USER2> Working for Google/FB shouldn't be actual goals. The actual goal probably should be to do something interesting and making it big. So, even if you were to do the PhD, you might still be at crossroads figuring out what to do next. The startup, if whatever you said works, should give you enough to explore and understand your boundaries and in that process if you feel that you lack something that can only be fulfilled by a PhD, you can always do it later. You may not get such an opportunity again soon.

</comment><comment><USER3> you're studying to be a better employee to advance your career? or is just for a title (ceo or phd)? the startup gives you a shortcut to advance your career. you dont mention your age, if you're young, you can usually get away with making a career switch or two. the guy that goes for a startup wants to (probably) make a huge impact on the world in a short time. the guy that stays in big company will have more specialised impact but it probably wont be a headline maker of an impact.

we cant decide for you. but if you think of the two choices as those two extremes (big impact vs specialised impact) then maybe its easier for you to chose. good luck bossman

<comment><AUTHOR> Thanks a lot. The big impact vs specialized impact does frame things well. I almost see the PhD as a necessary condition for my career path; akin to an MD for a doctor. There are no laws governing the work like an MD. However, when I look at the people who are in the positions I want, less than 5% have masters, the rest are all PhDs. I'm in my late 20s by the way.</comment></comment>


Google App Engine SDK for PHP - <AUTHOR> https://developers.google.com/appengine/downloads#Google_App_Engine_SDK_for_PHP

<comment><USER2> Heard about it in the Google IO, I wish there was a NodeJs SDK for app engine to be honest..</comment>


Living pictures formed by thousands of US soldiers - <AUTHOR> http://www.telegraph.co.uk/culture/culturepicturegalleries/5940073/Mole-and-Thomas-living-pictures-formed-by-thousands-of-US-soldiers.html

<comment><USER2> They look awesome but I hate sites that force me to click n times for n images. I wish advertisers had a better method of paying than pageviews.</comment>


Awesome Fontstacks give you ready to use web font collections - <AUTHOR> http://awesome-fontstacks.com/

<comment><AUTHOR> Friends of a friend created this for Rails Rumble. I like it because I like design, typography and web fonts, and this makes it a lot easier to get a matching set of fonts. Including links to download the fonts, and the appropriate CSS, previews with the selected fonts, and (!) previews "what if the font was not downloaded".</comment>


Results of our Ruby development survey - <AUTHOR> http://devver.net/blog/2008/06/the-results-of-our-ruby-development-survey/

<comment><AUTHOR> Are there any questions we didn't ask or other stats Ruby hackers would find interesting?

Perhaps most common used gems or plugins?

<comment><USER2> The test/notest divide is very roughly 50/50, I'd like to know what percentage of testers found tests to actually help catch bugs, and what percentage of notesters wished they had tests because they are confident tests would have caught eventually discovered bugs sooner.

I ask this because the (rails) testing koolaid still tastes funny to me. I wonder if any practice that focuses the attention on code quality, whether TDD, BDD, unit testing, pair programming, cleanroom, etc, would catch the same bugs.

<comment><USER3> I'd venture to guess nearly all developers using unit tests would say they are helpful, otherwise they wouldn't be using them. This isn't meant to be snide. I'm just saying that if you already suspect koolaid then any feedback is basically worthless because the only people responding are the ones who have seen measurable results and idiots who drink koolaid, and there's no way to tell the difference. The feedback from non-testers might be a little more useful, but it's still a little suspect considering it's from people who are confident more testing would improve their software yet still don't do it. Furthermore, unit tests are only as good as the test cases themselves and a survey can't account for quality of tests. I guess my point is that while surveys can be interesting, at the end of the day they're just a popularity contest and not very good for determining what works and what doesn't.

<comment><USER4> Exactly. I'd still love to see real study on whether unit testing is worth it (which our survey doesn't even begin to address, since it's very hard to measure). I think some good studies on that would be invaluable, but it's nearly impossible to control for all the variables, so I'm not holding my breath.

Failing that, most of the "evidence" one way or the other is based on asking people who test or don't test - and probably most testers would say that testing is great while non-testers would say testing wouldn't catch the kinds of bugs that matter. On the flip side, you have some testers saying it's not valuable (because their test quality is bad) and some non-testers saying they are sure tests would help, but only because they imagine tests to be a silver bullet.

In any case, our survey was just supposed to get a rough feel for how many people were doing testing (and what tools they used). What surprised me most was that even small teams (1 and 2 people) often had a test suite. This flew in the face of the anecdotal evidence we had previously gotten from other startups (almost none of ones we have talked to use tests).

<comment><USER2> On example of the question would be, "Do your tests ever find bugs, or do they just sit there always working."

No koolaid, how about the post from this moron [http://kurt.karmalab.org/articles/2008/02/07/rails-app- witho...](http://kurt.karmalab.org/articles/2008/02/07/rails-app-without- tests-guaranteed-fail)

If you look at page 470 of the latest Code Complete, it shows that unit tests have a very low defect detection rate,

Cleanroom software engineering has the best record of quality, but there's no buzz for that now in the ruby community, maybe because it doesnt sell books :-P

</comment></comment></comment></comment></comment><comment><USER5> Does anybody here actually use gedit? And why?

edit : genuinely curious. not trying to put down gedit.

</comment><comment><USER6> I just love my net beans.

I would have thought that this great IDE would have made a stronger showing.

<comment><AUTHOR> Netbeans is nice, but I am actually in the process of leaving it for straight emacs. Netbeans stalls out, is a memory hog, and crashes nearly daily for me right now. I also found that I really only use it as a SVN GUI, and file manager. I the code completion is slow and never useful to me, many of the auto complete features are just annoying. My Ruby tools like autotest, irb, debugger, and rake tasks are just more responsive on the command line (some don't really work at all inside Netbeans).

I really liked it for awhile, but I started realizing that I didn't use or really like most of the advanced features, and all the work it does trying to provide those features are makes it slow.

Do anyone else's Netbeans seem to index things for the first hour the program is opened?</comment></comment>


Vocablurry - <AUTHOR> https://vocablurry.com/

<comment><USER2> Something similar I built a while ago: [http://vocowl.com](http://vocowl.com)

<comment><AUTHOR> Very nice, different approach. You might want to work to improve the UX of it and then it will be great.</comment></comment>


Ask HN: Would you like an IRC server? - <AUTHOR>

The "feature requests" thread is pretty much dead so I'm putting this up here too. I'd really like an IRC server for Hacker News, where we could discuss about pretty much everything related to Hacker News and it would be easier to find a partner or make friends. What do you think? <comment><USER2> irc.freenode.net #hackernews

<comment><USER3> it's irc.freenode.net #startups

<comment><AUTHOR> Oh, my bad. I didn't know. But this isn't official or in any way related to Hacker News, right?

<comment><USER3> #startups is where you'll find most people from Hacker News and YC.</comment></comment></comment></comment>


Learn How to Lower Your Business Financial Risk During Covid-19 (Free eBook) - <AUTHOR> https://covid.monetohq.com/ <comment><AUTHOR> Hi there!

I'm David from Moneto. I would like to share with you a practical step-by-step guide we have written during these difficult times for business owners.

Do you know how COVID-19 affects your business today and in the future?

We understand it's really difficult now. You are exhausted and stressed because you don't know how long your business will last under these conditions when the government shuts down businesses, people are staying at home, orders and projects were canceled, payments are delayed, savings are low and future is unpredictable.

Learn how you can lower your business financial risk and make informed financial decisions. Do it yourself. You don't need to be a financial guru. You don't have to use complicated spreadsheets either. After all, no-one knows your business as you do, and no one can be as highly motivated.

Show your teammates that you have a business in your hands and an action plan based on reality. Your teammates will feel you're strong and they'll love to join you to survive this difficult time.

Get a practical step-by-step process. That! Just! Work!

If you have any queries, or anything not clear, just email me. I am here to help.

Have a lovely day, – David & the Moneto Team</comment>


The man who monetizes data - <AUTHOR> http://mixergy.com/david-shteif/ <comment><USER2> Interesting. I can't watch the video right now, but I hope it gets into the details of what they actually do.

<http://revenuegrp.com/> is just a few pages of hand-wavey marketing speak. And the fact that "Payday Loans" is one of their key verticals doesn't inspire confidence.

<comment><USER3> Lead Gen. You sell the contact information for people who express an active interest in a high-margin good to the seller of such goods.

<comment><USER2> Oh. Well that's a lot less interesting. I'd much rather have a better way to market _my_ services to users.

</comment></comment></comment><comment><USER4> I couldn't get past the point where he's going on about doing lead-gen for payday loans.

I care about creating value far more than I care about making money. In my eyes, $500k earned by creating value is far sweeter than $5m acquired by helping loan sharks.

I'm not sure if this guy had anything interesting to say, but I'm canceling my wife's shopify account based on this interview. I'd recommended them on the basis that they were simple and not horrible... but I don't want a nickel going to this guy.

he can have his payday loans... but he can't have my dollars too.

<comment><USER5> "I'm canceling my wife's shopify account" ?!

I don't know your wife, but I'd certainly ask mine before closing her (hypothetical) business.

<comment><USER5> I'd be grateful if a mod could delete this exchange; it caused some distress to kw_ and certainly didn't add anything to the discussion. I can't seem to find a delete or edit link anymore.</comment></comment></comment>


Microsoft and GitHub team up to take Git virtual file system to macOS, Linux - <AUTHOR> https://arstechnica.com/gadgets/2017/11/microsoft-and-github-team-up-to-take-git-virtual-file-system-to-macos-linux/ <comment><USER2> "Git wasn't designed for such vast numbers of developers—more than 20,000 actively working on the codebase. Also, Git wasn't designed for a codebase that was so large, either in terms of the number of files and version history for each file, or in terms of sheer size, coming in at more than 300GB. When using standard Git, working with the source repository was unacceptably slow. Common operations (such as checking which files have been modified) would take multiple minutes."

These sentences in some parts gloss over the details, and in others it is flat out wrong. Git was designed for tens of thousands of developers (the Linux kernel), it was designed for huge numbers of files (but large numbers of files works fine on Linux due to the dentry cache, it sucks on Windows because they don't have a cache that has the same behaviour as the Linux dentry cache). Admittedly it is slow for files that are large in size, but it was designed for source code; what sane developer would have source files that are hundreds of MB in size?

That said, monorepos with several dozen software projects can be very slow due to O(n) functions such as git blame and the like. It's true that git wasn't designed for large numbers of projects in one repo that are only indirectly shared by library code and the like.

Unfortunately that was not written in the article.

<comment><USER3> > in others it is flat out wrong. Git was designed for tens of thousands of > developers (the Linux kernel),

This is easy to check, and the article is right. The Linux kernel does not have tens of thousands of active developers. Over a little more than the last year:

        titan:~/src/linux geofft$ git log v4.8..v4.14 --format='%aE' | sort -u | wc -l
        4857

If you look at just the most recent release cycle:

        titan:~/src/linux geofft$ git log v4.13..v4.14 --format='%aE' | sort -u | wc -l
        1839

Alternatively, if you look over the last ~year, but at people who have more than five commits (chosen arbitrarily):

        titan:~/src/linux geofft$ git log v4.8..v4.14 --format='%aE' | sort | uniq -c | awk '$1 > 5' | wc -l
        1814

A codebase with 20,000 _actively_ working on the code base is at least an order of magnitude more than the Linux kernel. If they're committing patches every single day, probably more than that. I have, last I checked, four commits in Linux: two for a summer internship in 2009 and two doc fixes. That certainly contributes to the scale of Linux the kernel in the sense of "there are so many people working on it!", but not in the sense of being an "active developer" of the git repo. I was fine sending in my patches to a mailing list and hearing back at some arbitrarily later point, not triggering any CI, not asking anyone else to collaborate on my work, etc. That doesn't work if you have 20,000 engineers on the same codebase writing code every day.

> _Admittedly it is slow for files that are large in size, but it was designed > for source code; what sane developer would have source files that are > hundreds of MB in size?_

Sometimes that's the best way to get things done? The best Debian workflow I've ever worked with (and I've worked with a _lot_ ) involved actually committing binary .debs to SVN alongside their source code, because that meant that the SVN revision number was the single source of truth. There wasn't some external artifact system, nor was there a risk of picking up the wrong packages from an apt repo when rebuilding an older SVN revision.

I'm not defending this as _pretty_. But I will defend this as _sane_. It got the job done reliably and let me work on actually shipping the product and not yak-shaving workflows.

<comment><USER4> I think this is all missing the point. Do they want to store, say, the entirety of the base Windows OS in a single git repo? If that's the case, sure, git isn't a great fit for their use case, and they should either use something else, or find a way (as they're doing?) to change git to fit their needs.

I can't see MS having tens of thousands of developers working on any single component of Windows, so I'm guessing they _do_ want a giant monorepo. If they were to break it up into separate repos per OS component, I doubt they'd have scaling issues (of course, breaking things up introduces coordination and dependency issues).

<comment><USER5> PM for Git at Microsoft here. We explored splitting it up. It's a 300GB repository and it's been a monorepo for the last 20 years. Splitting it up logically would take a lot of time (to put it mildly) and development would stall while we did it. And once we did, we would have 100 3.5GB repositories? 3500 100MB repositories? Neither of these are particularly appealing and getting changes checked in atomically across multiple repositories is insanely challenging. There's no doubt that we would need to build tooling to make this work for us. (We did actually explore this direction, but ultimately decided that it would be too much work for too poor an experience.)

Instead, we decided to - as you put it - change Git to fit our needs.

<comment><USER2> Does Git on MSWindows use a dentry like cache in user land to speed up filename lookups? Does it use a stat() equiv cache? Is there a reason that such caches weren't put into ntoskrnl.exe? Would you be able to give us a brief list (say top 5) of changes that sped up git on windows? And which ones had the most effect on super sized monoreops. Thanks!

<comment><USER3> I have seen poor performance of git on Linux in very large repos, so I'm not super convinced that the dentry cache magically makes things better.

In particular, if my repo is big enough, I often _don 't_ have the entire tree in memory (because I'm doing other useful things with memory and caches got evicted). core.untrackedCache makes things a little better, but it's still not great.

</comment></comment></comment></comment></comment></comment><comment><USER6> Interesting to see them try to fix Git when Facebook considered it (due to similar constraints) and decided to go with Hg instead: [https://code.facebook.com/posts/218678814984400/scaling- merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at- facebook/)

<comment><USER5> Microsoft PM here. It's important to note that Hg also had similar constraints. So Facebook was in a position of having to fix Git or Hg to suit their needs. It turns out that for a variety of factors, Hg was the better choice for them to hack on.

Microsoft took the same look and went the opposite direction, and decided that Git was easier for us to hack on. This was a no brainer for us. We build multiple tools that host peoples Git repositories (TFS and VSTS) and have Git repositories as deployment mechanisms for Azure. We have several contributors to tools in the Git ecosystem on staff, including people contributing to core git, and the maintainer for Git for Windows, libgit2 and LibGit2Sharp. But we have comparatively little institutional knowledge of Hg.

That post you linked is awesome. Facebook has done a lot of really impressive work scaling Hg and a lot of the lessons learned at Facebook and implementations in Hg are very similar to what we've done with Git.

This video from Durham Goode on Facebook's version control team (from Git Merge, amusingly) is also awesome: [https://m.youtube.com/watch?v=gOVD- DrUpwQ](https://m.youtube.com/watch?v=gOVD-DrUpwQ)

<comment><USER7> It's really good to see Microsoft join in the open source community. I switched to Mac over a decade ago largely because of the Microsoft only mentality back then. Really makes me consider switching back.

</comment></comment></comment><comment><USER8> Uhm... the author seems to be confused about the relationship between Github and git.

GitHub doesn't develop git, it's a service built on top of git. Any modifications to git has nothing to do with GitHub. GFVS is a GitHub project, not part of git.

<comment><USER9> > GitHub doesn't develop git

I'd be surprised if none of their employees have contributed to Git. I didn't interpret anything in the article as saying that GitHub develops Git, in its entirety (or even largely).

> GFVS is a GitHub project

GFVS is a Microsoft project and GitHub seems to be contributing. And the GFVS developers have been submitting, successfully, their changes to Git itself upstream to the actual Git project. So it is _becoming_ a part of Git.

<comment><USER10> > I didn't interpret anything in the article as saying that GitHub develops > Git

" _Microsoft [...] wanted to get these modifications accepted upstream and integrated into the standard Git client.

That plan appears to be going well. Yesterday, the company announced that GitHub was adopting its modifications and that the two would be working together to bring suitable clients to macOS and Linux._"

This hints that Git upstream = GitHub. I mean, why mention GitHub at all if they aren't upstream? The rest of the article doesn't explain GitHub's role in this story either.

<comment><USER9> I still don't think your interpretation is warranted, but meh.

Microsoft made some contributions and they're working to get them accepted upstream. They're maintaining a fork basically.

GitHub is adopting their modifications, i.e. GitHub is running Microsoft's fork.

Microsoft's modifications are necessary _for them_ , particularly so they can use Git with the giant Windows repo. Presumably, GitHub also has a need or desire for those same or similar modifications. IIRC, some of GitHub's largest customers need or want a version of Git that can also handle large repos, or repos with large files or large numbers of files.

</comment></comment></comment></comment><comment><USER10> For the avoidance of doubt, GitHub is _not_ upstream of Git.

<comment><USER11> yeah this was really confusing in the article everywhere it mentions up- streaming it refers to "git" only then later mentions how GitHub is accepting it's modifications... so not entirely sure which it is.

TL;DR pretty sure it's not touching git source at all.

Looking though the GVFS readme: [https://github.com/Microsoft/GVFS](https://github.com/Microsoft/GVFS) it appears that it actually wraps git, which would make sense because in that case they would have to explicitly add support to each git host and provide individual platform ports of GVFS (all of which would be unnecessary if it was actually upstreamed into git).

So that's good... git is one of my favourite open source tools and I would really hate for M$ to start polluting it. I don't care if GVFS is a good idea or not I just don't trust the fuckers and they will always deserve that suspicion.

<comment><USER12> No, they needed to do some modifications to the git suite of tools. Generally git expects all objects to be on disk and Microsoft wanted to have sparse checkouts of files in a specific revision.

Not really polluting but rather having some objects be fetched only on demand.

Source: [https://blogs.msdn.microsoft.com/devops/2017/02/03/announcin...](https://blogs.msdn.microsoft.com/devops/2017/02/03/announcing- gvfs-git-virtual-file-system/)

> In addition to the GVFS sources, we've also made some changes to Git to > allow it to work well on a GVFS-backed repo, and those sources are available > at [https://github.com/Microsoft/git](https://github.com/Microsoft/git).

For the record as far as I understand GVFS the article is correctly using git vs Github.

<comment><USER11> Thanks for the clarification, sparse object fetch seems like a small change in concept at least.

</comment></comment></comment></comment><comment><USER13> Did I misunderstood the idea, or is GVFS essentially making git a non- distributed VCS?

<comment><USER14> It's worth asking: how many Github users are actually using git as a fully distributed version control system? The typical Github workflow is to treat the Github repo as a preferred upstream--which sort of centralizes things.

<comment><USER15>
       The typical Github workflow is to treat the Github repo as a preferred upstream

Is it typical? What metrics do you have to support that?

Speaking for myself I have only ever used triangular workflows: fork upstream; set local remotes to own fork; push to own fork; issue pull request; profit

[https://felipec.wordpress.com/2014/05/11/git-triangular- work...](https://felipec.wordpress.com/2014/05/11/git-triangular-workflows/)

<comment><USER16> The main repo is upstream of you regardless of whether it is labeled as such in `git remote -v`. If it goes offline, nobody systematically falls back on your fork. This makes the system effectively centralized, which is parent's point.

<comment><USER17> To elaborate in more (possibly excruciating) detail:

It's very rare for anyone on GitHub to do the sort of tiered collaboration that the Linux kernel uses. If, say, I want to contribute to VSCode, pretty much the only way to get my changes upstream is to submit pull requests directly to github.com/Microsoft/vscode.

Compare to the tiered approach, where I notice someone is an active and "trusted" contributor, so I submit my changes to their fork, they accept them, and then those changes eventually make their way into the canonical repo at some future merge point. That's virtually unheard of on GitHub, but it's the way the Linux kernel works.

Pretty much the only way you could get away with something even remotely similar and not have people look at you funny in the GitHub community is _maybe_ if you stalked someone's fork, noticed they were working on a certain feature, then noticed there was some bug or deficiency in their topic branch, then they wake up in the morning to a request for review from you regarding the fix. Even that, which would be very unusual, would really only work in a limited set of cases where you're collaborating on something they've already undertaken—there's not really a clean way in the social climate surrounding GitHub to submit your own, unrelated work to that person (e.g., because it's something you think they'd be interested in), get them to pull from you, and then get upstream to eventually pull from that person.

<comment><USER15> That's detailed, but not excruciating. Thank you.

</comment></comment></comment></comment></comment></comment><comment><USER18> To me it looked like one of the points of Git was that one could work on anything from the entire repository locally, i.e., for example, without having an internet connection, e.g. when on an airplane. (I think having one huge repository is the problem here.)

<comment><USER19> Well, Git was indeed created to serve Linux kernel development. So decentralized access for the people writing patches all over the world was useful. However, when companies started using source control for their monorepos which developers access through a work network or VPN decentralization takes a backseat to business concerns. Different use cases and all that.

<comment><USER20> I think the problem there, is that you then basically wind up with Git on the backend and an SVN-like layer over the front. Which seems a bit silly. SVN is a very robust project that works really well. Why not add git-like porcelain to SVN if you're gonna force devs to have an network connection so they don't have to download a giant git working directory.

Smart people are working on all this, so I'm sure there are reasons, but in the all the instances where I've had to interact with a monorepo, it was because the tech debt was too high to pay off to break it apart, not because it was better.

And if you're indebted to the point where you have no point in paying it off, you damn well better have leveraged assets against it (i.e. a cash cow of a business, like MS Word or Facebook)

<comment><USER19> That's interesting. I've never been an insider and it was several years ago, but Google spoke in pretty glowing terms of their monorepo when I heard them talk about it. That's neither here nor their though, not my personal preference either to be fair.

As far as Git's killer feature I think decentralization is only one part of it. Being able to deal with the change graph directly is sometimes handy. And knowing the basis of the model, I find Git pretty easy to understand even when history gets fuzzy. Not sure but I think Darcs might be even better for that, just without the mindshare.

</comment></comment></comment></comment><comment><USER21> Sounds a bit similar to Google's Piper ([https://cacm.acm.org/magazines/2016/7/204032-why-google- stor...](https://cacm.acm.org/magazines/2016/7/204032-why-google-stores- billions-of-lines-of-code-in-a-single-repository/fulltext)) that lets you check out a portion of the monorepo, no?

</comment><comment><USER22> "The biggest complexity is that Git has a very conservative approach to compatibility, requiring that repositories remain compatible across versions."

This, above all else. That I never, or anyone else on our team, ever has to worry about wether they are running an "older version" of git is such a win.

<comment><USER23> It's not really a surprise that monorepo advocates struggle here. Compatibility through versioning and stable APIs is challenging and requires discipline.

Making wide-spread changes to all clients of your code when you make changes that break things doesn't require discipline.

</comment></comment><comment><USER24> Hmm, some part of me wouldn't mind, a FUSE setup where: /repository/github.com/<org>/<repo>/ is automatically cloned out from github when accessed the first time :)

It would be pretty cool to use as a $GOPATH. Or just for making drive-by github contributions super easy.

<comment><USER25> It's all fun and games until someone like me tries to run `find` on the parent directory...

<comment><USER26> Children would be lazily loaded and would not appear in directory listing of the parent directory. `find` would search your existing local checkouts only and the file system would still be POSIX.

<comment><USER25> How do you trigger loading the projects if there isn't a pointer to them showing up in the file system?

<comment><USER27> When you open or stat a directory that doesn't exist, try to checkout that path, if that fails, return an ENOENT error?

</comment></comment></comment></comment></comment><comment><USER28> A couple of thoughts as the implementation downloads mainly placeholders:

that mechanism can also be combined with permissions on the server side so contractor X who is fixing a driver need only have access to the driver and some supporting code while still checking into the monorepo.

It also means that every developer's laptop won't have a full copy of the repo (so if said laptop is lost, the risk is more contained)

And it's similar to Part of LFS, bigfiles and other "blob" add-o s to git...could see in future a way to put .doc files and the like into repos.

</comment><comment><USER29> > The open source, free GitHub hosting doesn't need the scaling work Microsoft > has done

They might want to fix that sentence. It reads as saying that Github is open source. Perhaps it should read

> The free GitHub hosting that is typically used by open source projects > doesn't need the scaling work Microsoft has done

</comment><comment><USER30> > _Microsoft and GitHub are also working to bring similar capabilities to > other platforms, with macOS coming first, and later Linux. The obvious way > to do this on both systems is to use FUSE, an infrastructure for building > file systems that run in user mode rather than kernel mode (desirable > because user-mode development is easier and safer than kernel mode). > However, the companies have discovered that FUSE isn 't fast enough for > this—a lesson Dropbox also learned when developing a similar capability, > Project Infinite. Currently, the companies believe that tapping into a macOS > extensibility mechanism called Kauth (or KAuth) will be the best way > forward._

I'd love to read more technical details on this. How can Kauth support a virtual filesystem?

</comment><comment><USER31> It seems that lazy-downloading files isn't all that useful if you need to compile all the source code. Does anyone know which build tools can be used to avoid having to open most of the source files - maybe some centralized build cache?

</comment><comment><USER32> This is kinda funny, it undoes one of the original pillars of why git was made

</comment><comment><USER33> Does anyone else think this is another "Embrace, extend, and extinguish" move from MS? I don't know enough about the changes make that judgement.

</comment><comment><USER34> The title is terrible. Here is an excerpt from the article that explains what's going on: "The company's solution was to develop Git Virtual File System (GVFS). With GVFS, a local replica of a Git repository is virtualized such that it contains metadata and only the source code files that have been explicitly retrieved. By eliminating the need to replicate every file (and, hence, check every file for modifications), both the disk footprint of the repository and the speed of working with it were greatly improved. Microsoft modified Git to handle this virtual file system. The client was altered so that it didn't needlessly try to access files that weren't available locally and a new transfer protocol was added for selectively retrieving individual files from a remote repository."

This style of working is needed in large code bases, where not all files are checked out on developer workstations (for performance or privacy reasons).

<comment><USER35> Man, I get sick of the incessant title criticism on HN. I wish the quality of the title wasn't such a go to topic. Unless the title is grievously misrepresenting, let's just discuss the topic.

<comment><USER36> Yes the latest crowd has created some memes for themselves. I agree we need to extinguish them for the sake of continued quality HN discussion. Including:

\- X software package name reminds/confuses me of Y product with similar name

\- X title is garbage. Here is the title I would write...

\- I don't understand [basic concept available on Wikipedia]. Someone explain it to me (aka lazyweb)

\- I'm not an expert on this, but [completely unqualified and uncited conjecture]

\- I also once did X from TFA and [unrelated personal anecdote with no insight] (aka long form "me too" comment)

I come to HN so that I can read informed discussion from people who work in the field of TFA. To read discussion of basic topics between the uninformed, there is everywhere else on the internet.

<comment><USER37> I mean, unlike a lot of aggregation sites, HN has a specific policy about link titles, which is generally sensible and does the right thing. ([https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html))

Sure, in some cases, implementation of this policy fails, and something is rewritten that shouldn't be, or something should be rewritten that isn't. But, I'd estimate maybe 80% of all discussions about titles, that I've seen, have been valid concerns, and typically resulted in a rewrite.

<comment><USER36> I have long been familiar with HN's policies. OP did not suggest a new title, they instead posted a long quote from TFA and added an oversimplified summary -- which I'm not sure adds to quality discussion. Articles which are only clickbait should be flagged. Correcting the title on a good article is different from complaining.

</comment></comment></comment></comment></comment><comment><USER38> And they are still calling it GVFS -- a name that is already used by a prominent linux technology. [https://github.com/Microsoft/GVFS/issues/7](https://github.com/Microsoft/GVFS/issues/7)

<comment><USER39> Every single hacker news discussion these days seems to have a complaint about reusing a name.

Every name is taken. There is nothing to be done about it. It's okay. I mean, it's sad, and terrible, but it's also fine.

<comment><USER40> They are definitely not all taken

</comment></comment></comment><comment><USER41> Anyone else get superconfused and think about the GNOME Virtual Filesystem?

<comment><USER38> [https://github.com/Microsoft/GVFS/issues/7](https://github.com/Microsoft/GVFS/issues/7)

</comment></comment><comment><USER42> Moving Windows development to git sounds like a completely irrational decision from a technical standpoint that was driven mostly by marketing concerns.

<comment><USER43> Could you please try to comment more substantively? We've already asked you this.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER42> > We've already asked you this.

Am I on some kind of a black/gray list? Either that, or you specifically remember my name, which sounds odd.

</comment></comment></comment><comment><USER44> I wonder if this is a precursor to open-sourcing Windows development...

<comment><USER45> No. Open Source and walled gardens don't mix. MS wants to turn Windows into the later, obviously.

</comment></comment><comment><USER46> Does this mean we have to fdisk/format if we forget the commands to correct a broken git repo?

[https://xkcd.com/1597/](https://xkcd.com/1597/)

I seriously did that first learning Git. And there's plenty of niches and side-cases that I'm still not quite sure of. Going from client-server to distributed has a level of complexity that usually isn't discussed until you implement.

EDIT: And further understanding is, this provides a GIT filesystem based connection so that one can work on a multi-TB repo without downloading everything locally.

This seems to be the result of choosing to have all the software in one OMG- sized repo, rather than 1 project/repo. And evidently they need a "keep on server" for this. Makes me wonder more why they even went with Git or a distributed model at all. This seems more like they 'screwed up and now have tons of bandaids'.

<comment><USER9> Lookup the history of GVFS and why Microsoft chose Git. There are interesting reads about it.

There's also lots of interesting reads about 'monorepos' and their pros and cons. Note tho that Google and Facebook, and lots of other companies, use mono-repos. It's not just Microsoft and, not surprisingly, they've all made (more or less) reasoned, thoughtful decisions taking into account lots of factors that almost no one else in the world would ever think to do.

</comment></comment><comment><USER47> This is only tangentially related, but is there any standard advice to get git on a remote file system (ceph) to run fast with a long history?

</comment><comment><USER48> It's a little surprising to me that these companies use Git at all. What's the appeal of Git really? Is it just the "familiarity factor", and is that really a reason to pour so many resources into it?

<comment><USER49> I think almost all the people they hire nowadays would be familiar with git and not something else. So it would be a lot of time savings in training if you switch to git instead of training every newbie to your own peculiar source control mechanism.

<comment><USER48> Sure, but the CLI is the CLI. I can't imagine there's no way to replicate the Git CLI without rewriting the internals. Surely the basics of branch-and-merge will be the same, right? I doubt anyone would miss the dangerously overloaded `checkout` subcommand, or wrestling with rebase conflicts.

</comment></comment></comment><comment><USER35> I can't help thinking, there is more to this than is discussed in the article. This tech can also be used to give developers selective access to a git repo. It lets Microsoft and other commercial software vendors get on the git bandwagon with out actually sharing all the code with all the developers. Each git repo is a complete copy because git was designed to support Open-Source. In Open-Source there are no hidden parts. But that's a hard pill for corps like Microsoft to swallow. This looks more like a solution to meet developer demands to use git and also satisfy the demands of management to maintain control of their team's code based.

<comment><USER50> As stated in the article, git is also challenging for game development because of the large asset files. Git has limitations and they are part of the reasons a lot of companies and even indie game devs didn't jump into it (Jonathan Blow, John Carmack, being some of the critics). It's more about speed, simplicity, and efficiency rather than "Corp" vs "Open Source" conspiracy.

<comment><USER51> Git's issues with game dev isn't just because of large file size though. Binary files are hard to control in a DVCS because if two people spend 24 hours to modify a binary asset at the same time you can't just merge the changes together like with source code. Someone has to manually go in and replicate both changes together.</comment></comment></comment>


How does biology explain the low numbers of women in computer science - <AUTHOR> http://www.slideshare.net/terriko/how-does-biology-explain-the-low-numbers-of-women-in-cs-hint-it-doesnt?player=js

<comment><USER2> Um... That was remarkably content-free. _Almost everyone_ i've met in CS so far knows that 'men are better than women at math and/or CS' is an mountain- sized stereotype with possibly a sand-grain sized nugget of truth to it.

Yes we men do have our share of die-hard macho morons, but symmetric attitudes are not that hard to find in the feminist ranks either. In fact I think that _in proportion_ to the number of men, we have less of these problematic types in CS than in some other fields.

</comment><comment><USER3> The Eastern European countries seem to be very good at getting women into math, for some reason. I've met a disproportionate number of female math PhDs who were from Eastern Europe, and the first woman to win the Putnam was from Romania, I believe. It's just a question of education and societal expectations, I think.

</comment><comment><USER4> I'm male. My field is Forensic Science. It consists of about 80% women. Doesn't matter which lab I go to, or which forensic education program I visit, the percentage stays the same.

Why?

On a daily basis I'm dealing with very violent crimes. Why does this sort of work appeal to women more than men?

</comment><comment><USER5> I'd be much more interested in a presentation that takes the following tack: we know that some professions are mostly male, some mostly female, and some a mix. Lets pick a bunch of careers from each category. Can we find any common characteristics in those three groups? Can we form a model based on that with predictive power - one that lets us say "based on what we know, we predict that X% of radiologists will be female" and be reasonably accurate?

That would be much more useful than the constant "men are better at math" vs "no they're not!" argument. And if there were interesting findings, someone else could try to determine how much of the difference was social or biological.

</comment><comment><USER5> TL;DR - "It doesn't. Women and men are about equally good at math. Also, CS doesn't require much math ability."

Actually, I don't see how those two ideas form a coherent argument.

<comment><USER6> It becomes more interesting if you add a third: "This logic was presented by a female mathematician."

(Before I get modded down into oblivion, I should state that I agree with both points: Women and men are about equally good at math. Also, CS doesn't require much math ability.

I just think it's interesting to analyze the argument's logic.)

</comment></comment><comment><USER7> There are less women going into computer science because there are less women in computer science. It's an issue of the social norm, not math ability, biology, or anything else. Most people, male or female, will pick colleges, majors, careers, etc. based on what their friends do and think. If none of your friends are going into computer science, you'll feel uncomfortable choosing it and will go into microbiology like your friends.

</comment><comment><USER8> I thought this was going to be about how effective recruitment by Biology programs is responsible for reducing the female enrollment in CS programs.

Instead it just tells us what we already know.

</comment><comment><USER9> There are some comments from the submission two years ago when this was new:

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

</comment><comment><USER10> So even though more men study maths, there are not more men who are good at maths than women (according to the chart)? That seems a bit depressing or at least disillusioning with respect to higher education. Maybe men are on average worse in math and only by studying more they can keep up with women?

</comment><comment><USER11> Programmers - not so much math skill. Computer Scientists - hell yeah</comment>


The Plain Person's Guide to Plain Text Social Science [pdf] - <AUTHOR> https://kieranhealy.org/files/papers/plain-person-text.pdf <comment><USER2> I've made it a side-mission of mine to convince journalists to work in plaintext as much as possible. For all the concern of novices being intimidated by plaintext and code (plaintext basically _is_ code as far as most laypeople is concerned), GUI-heavy software and rich text exact their own cognitive toll, not just in the form of having to keep up with interface upgrades (I've yet to move from Office 2011 to 2016), but in the way the user has to be trained to memorize the quirks of how the software modifies the data.

Excel is the obvious example here, e.g. zero-padded unique ids `00011` becoming `11`, dates turning into numbers like `41566`, and that's before you get into the madness that comes when trying to import/export data (think Mac- style line-endings into QGIS into Mac OSX Office, etc.).

At some point, it's just easier to take some time and be comfortable with the idea that things can be represented in plaintext. That data doesn't magically become data because software is used to open it. I've spent a good amount of time having to convince people that that CSV text file I sent them is not just random gibberish (trying to figure out how people's systems are set up to open certain files upon double-clicking is also not fun).

The inability to understand how software and data (human-readable plaintext or otherwise) can be separated is not limited to the humanities majors. Here's a case in which a civil engineer convinced the Ohio Supreme Court that using Esri ArcGIS inextricably tied the software to the (publicly-funded) GIS data, meaning that any member of the public who wants a copy of geospatial data in a form other than printed map will have to cough up an extra $2,000: [http://spatiallyadjusted.com/use-esri-gis-and-your-data- beco...](http://spatiallyadjusted.com/use-esri-gis-and-your-data-becomes- inextricably-intertwined/)

</comment><comment><USER3> I love text editors, especially Vim.

However, I realize we no longer are tied to paper or use low-power, low- bandwidth computers. Images, still and moving, effectively are as easily handled by the computing platform as words. I believe the reason humans have used text so much more than images so far is that never before in history have we had a platform that efficiently handles multimedia. I need to effectively express myself using images; you can see people naturally doing that for casual purposes with Snapchat, etc.[0]

But even with my eyes opened and my willingness to move forward, I'm limited by available tools. There is no productivity tool that a user can use to efficiently process mixed text and image (and audio).

We need a Vim for multimedia, or at least a Word.

[0] Yes, text is still a great tool, but it's not the best tool for every job.

</comment><comment><USER4> Here's a web version of the document: [http://plain-text.co](http://plain- text.co)

</comment><comment><USER5> This isn't working for me on mobile, gives a failed download of 0kb.

If as irickt says this refers to [http://plain-text.co](http://plain-text.co) then I'd say I wholeheartedly agree with the sentiment. Leverage the tools that are battle tested: plain text and version control.

Of course, it's an uphill battle. If your boss expects to add track-change comments to a Word .docx then your pristine text-based processes are going to get tarnished.

Personally I've been experimenting with github.com + gitbook.com for generation of book-like documents. I tried a hand-rolled toolchain based around pandoc but realised that i could write plugins for gitbook, with far more reliability.

I'll have reached the holy grail when editors submit pull requests instead of track-changes Word docs attached to emails. I expect this to never happen.

</comment><comment><USER6> fascinating. the author nails it here:

"there is little to be gained from plain-text dogmatism in a .docx world."

my f'in life...</comment>


TagSpaces – Open-source personal data manager - <AUTHOR> http://www.tagspaces.org/ <comment><USER2> Very nice, but a stopper for me is that if you have a pdf with the name "foobar.pdf" on your disk and tag it with TagSpaces with the tags Sciences, Thermodynamics you end up with a file "foobar[Sciences Thermodynamics].pdf". The tags are directly encoded into the file names.

<comment><USER3> This is a stopper. I don't want to pollute the filenames with this information. Using a sqlite db or something even simpler would have been more preferable imho

<comment><USER4> Hm, sqlite3 would be slow for large collections of small individual files.

However their approach is awful. Imagine what will happen if you tag video/audio files.

</comment></comment></comment><comment><USER5> File/data management is one of those things that are very fundamental to what computers do and one of the first applications for computers, but where advancements have been quite limited. We are still mostly stuck on simple hierarchical structures with short plain text string as the sole identifier for files. Files themselves are mostly opaque blobs, file managers usually having limited info about their content.

Admittedly file managers these days at least can show thumbnails and in some cases even previews of the file which is great. They also are capable of extracting some metadata of files, but that still feels bit tacked-on in most cases. Versioning is also available in various forms, but that too could certainly be better integrated to the system.

Imho it would be interesting to see a system which would forgo our current conventions of files and directories, and instead would be more strongly be based on the concept of tags, metadata and objects.

But I got sidetracked... I meant it is nice that people are trying to rethink even a little how we manage data, even if this particular project doesn't really hit the mark for me personally.

<comment><USER6> Remember the "Information at your fingertips" speeches of Bill Gates (Comtex '90 and '94) and the Cairo operating system, its ObjectFS filesystem and later WinFS?

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

<comment><USER5> I'm too young for Cairo, but I do remember Longhorn and WinFS, and indeed the marketing and ideas of those have shaped my view of what the systems could/should be today. Didn't BeOS also have some sort of object-database- filesystem-thingy? I remember some chatter about that, but didn't actually catch any first-hand experience at the time.

edit: Longhorn concept video: [https://www.youtube.com/watch?v=b9ifQvQCO7Y](https://www.youtube.com/watch?v=b9ifQvQCO7Y)

<comment><USER6> Nevertheless, consider watching Gates' Comdex keynote videos.

Have you seen the WinFS trailer: [http://www.youtube.com/watch?v=fZ_4p5iUc88](http://www.youtube.com/watch?v=fZ_4p5iUc88)

You can try out BeOS open source successor that comes with a BeFS compatibility called HaikuOS. I suggest you to read the BeFS book written by the main developer who later developed the Spotlight search engine for MacOSX 10.4+ and later iOS. [http://en.wikipedia.org/wiki/HaikuOS](http://en.wikipedia.org/wiki/HaikuOS) , [http://en.wikipedia.org/wiki/BeFS](http://en.wikipedia.org/wiki/BeFS) , [http://www.nobius.org/~dbg/practical-file-system- design.pdf](http://www.nobius.org/~dbg/practical-file-system-design.pdf) , [http://en.wikipedia.org/wiki/Spotlight_(software)](http://en.wikipedia.org/wiki/Spotlight_\(software\))

Both NTFS and the newer ReFS ([http://en.wikipedia.org/wiki/ReFS](http://en.wikipedia.org/wiki/ReFS) ) offer almost equal capabilities to BeFS. And it's a real shame that Microsoft hasn't been able to come up with a decent GUI. Even Vista had a better advanced search dialog integration than the successor's Windows 7 and 8.x

</comment></comment></comment></comment><comment><USER7> Can this be used together with Camlistore ([http://camlistore.org/](http://camlistore.org/)) ?

<comment><USER8> First of all I should say that I've been following camlistore and if it reaches its goals, I think it's going to be amazing.

However, it's nowhere being user friendly yet and the command-line based API changes all the time.

I suppose you could use them together because you can mount your files in camlistore to the file system with cammount but it would not be easy to make them sync tags and metadata.

</comment></comment><comment><USER9> This looks very interesting indeed. There is a definite need for good cross- platform, open-source information management software. It's all too easy to get stuck in one manufacturer's information silo.

</comment><comment><USER10> This seems like a perfect companion (or replacement) for Notational Velocity.

</comment><comment><USER11> This is a program named after a feature. Doesn't really do a good job of conveying what it's for IMO.

Also since it uses the AGPL it's a no-go for me.

<comment><USER12> Just curious, why is that? Why AGPL would prevent you from using this?

<comment><USER11> The ugliness in the WordPress community over themes and plugins. [http://www.red-sweater.com/blog/825/getting-pretty-lonely](http://www.red- sweater.com/blog/825/getting-pretty-lonely)

<comment><USER13> I don't see how themes/plugins have anything to do with an (A)GPL licensed end-user application that doesn't support any sort of plugins (at least not to my knowledge).

Even if you did write plugins for apps and license/sell them, that would stop you from using a useful app just because you couldn't do it for that app?

I'm having a hard time following how AGPL affects you as a user of the app, not someone who's selling addons for it and not as someone who provides the app over a network.

It seems you could modify the source and run your own version without releasing your modifications and without violating the (A)GPL.

<comment><USER11> 1\. This type of app just cries out for plugins.

2\. Yes, because I don't want to spend time learning a system that I can't extend if extending systems is my livelihood.

3\. I don't want to support a community that shuns people who disagree about licensing.

4\. This feels against the spirit of open source to me, to avoid having people use code, and provide feedback.

I don't believe that anyone understands the GPL including its creators. Too many things in it are vague.

<comment><USER14> GPL: Do whatever but the work is to never have restrictions added.

AGPL: Anyone using/visiting the service need to have access to the source code.

They are very simple. The only reason people can be confused by those two is FUD, and lawyers who find such statements too simplistic.

</comment></comment></comment></comment></comment></comment><comment><USER15> i love bootstrap to death, but am I the only one getting Bootstrap fatigue?</comment>


Y Combinator Video Call - <AUTHOR> Does anyone have any advice on what to expect from a Y Combinator video call? Any knowledge at all would be greatly appreciated. Thanks! <comment><USER2> I got an email from YC for a video call with Dalton Caldwell. It was a very crisp 10 min call. Dalton had already gone through our application and was aware of what we are trying to build. He had very specific questions.My advice: Don't try to pitch anything to them and stick to what they are asking.Try to be very clear in your answers

</comment><comment><USER3> For the last session of YC, we had a video call with Paul Buchheit.

How was it? INTENSE! He was very direct and to the point, think rapid fire. Questions centred around our business model and product. How many users we had and revenue. One big question he pushed us on is "How will we be a $10 Billion company?"

Good luck to you all

<comment><USER3> I should probably add, we did not make it past this round.

</comment></comment><comment><USER4> We were invited as well, if anyone had one of these before and can give any insight into what they ask that would be very helpful.

</comment><comment><USER5> My team and I have been invited for a video call. But not sure, what is the purpose.

</comment><comment><USER6> Same here! Please someone share they experience</comment>