Why Google Stores Billions of Lines of Code in a Single Repository - <AUTHOR> http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext <comment><USER2> I've worked a bit with "the big monorepo" (though nothing like Google scale) and my impression is that a lot of the benefits fall apart if you don't have people working to maintain the build environment, automated tests, developer environments. When it takes hours or more to run tests and produce a build it can really slow the team down. The ability to force updates on dependencies in a single big commit can be really worthwhile as long as you're willing to spend the time to build the tools and do the maintenance.

<comment><USER3> > a lot of the benefits fall apart if you don't have people working to > maintain the build environment, automated tests, developer environments.

The thing is, a monorepo makes clear what multiple repos can obscure: if you have a software system, then you need all those things anyway. Multiple repos can hide the cost, but they don't eliminate it — in my experience, they multiply it. E.g. if someone makes a breaking change in a monorepo, _he_ breaks the tests and _he_ fixes them before his changes can be merged in; but with multiple repos someone can commit a breaking change and a dependent repo won't know about about it until days, weeks or even months later; the person responsible for fixing it has no idea what really changed or why; and he has a broken build until he _does_ figure it out.

> The ability to force updates on dependencies in a single big commit can be > really worthwhile as long as you're willing to spend the time to build the > tools and do the maintenance.

It's like maintaining your car: you can spend $20 to replace your oil every 3,000-5,000 miles, or you can spend thousands every 10,000 miles. Up to you.

<comment><USER4> On the other hand, some of the code you have to update may be for products that have been mothballed. That might end up being a waste of time if the project is never revived.

Or the code might be safety-critical and updating it is introducing unnecessary changes (and hence, unnecessary danger).

Some tests may include hardware integration. For example, aircraft software may need some number of flight hours after significant changes. That's probably not going to be a part of the CI suite, and the changes will introduce a greater manual testing burden.

<comment><USER5> That's why you delete dead code at head (keeping archive of history) , and you have dev branches and release branches

</comment></comment></comment></comment><comment><USER6> With my current client we decided to go with multiple repositories and came to regret that decision.

The product family we are developing contains website, two mobile apps (iOS, Android), three PC applications (OS X, Windows and one legacy application) and software for embedded devices.

Each product lives in it's own repository, most repositories use one shared component as a submodule and many product share common platform, which is used as a submodoule and products build on top of that. Test automation core sits its own repo. I built and maintain that test automation core and it's a pain.

Each product repository has it's own functional tests that use the test automation core to make the tests actually do something. So when ever I make changes to the test automation core, I need to branch each product and use the feature branch from my core in it. Then run all the tests in each repo and see that I did not break backwards compatibility. If I do break it, then I need to fix it through pull requests to possibly multiple teams.

I'm not the greatest git wizard in the world, so maybe someone else could easily maintain good image of the whole mess in their head, but for me this is a pain. And everyone else who maintains a shared component shares my pain.

Monolithic repo would not magically make all the pain in the world to disappear, but it would be so much more easier to just have one repo. That way I would need to only branch and PR once.

<comment><USER7> Just to be clear, wouldn't the alternative with a monorepo still require that you go back and forth with multiple teams if the commit is not backwards compatible? It seems like the main complaint you have is that it's difficult to wrangle a number of related pull requests, so perhaps switching to something like gitcolony [1] for code reviews would help.

[1]: [https://www.gitcolony.com/features](https://www.gitcolony.com/features)

<comment><USER8> > Just to be clear, wouldn't the alternative with a monorepo still require > that you go back and forth with multiple teams if the commit is not > backwards compatible?

No. You just send one diff that changes all the team's code and update everything in lockstep, so at any point in your history, everything is compatible.

Instead of you going back and forth with multiple teams, you're bringing them together to comment on a change in one place. You synchronize on version control history instead of needing to wrangle multiple teams across multiple repositories, and you no longer need to deal with fallout for code change compatibility. You just make the change. Everywhere. In one shot.

<comment><USER9> You may have to get multiple teams to review your change before being allowed to commit it. And you have to run all their tests. If there is a problem the whole thing will typically get rolled back, which is a drag because then you have to fix the issue, run tests again and get approvals again.

So, in practice, for large-scale changes that affect many teams, we still try to break up large patches into multiple smaller steps, even working in a monorepo.

A single commit is nice for small patches that only affect a handful of teams, though.

</comment></comment></comment></comment><comment><USER10> During my 16 month tenure in Google, I worked on:

1\. Android, using shell and Make

2\. ChromeOS, using Portage

3\. Chrome browser, using Ninja

4\. google3 (aka "the monorepo") officially using blaze (but often there were nested build systems - I remember one that used blaze to drive scons to build a makefile...)

The diversity of the build systems significantly steepened the learning curve when switching projects. During orientation, they told me "All code lives in the monorepo, and every engineer has access to all code", but this turned out to be not true at all. If anything it was the opposite: more build system diversity at Google than at other places I worked.

<comment><USER11> > I remember one that used blaze to drive scons to build a makefile...

Good lord.. then again I have to use MSBuild. Why can't someone write one that consumes something like JSON and is async?

<comment><USER12> I thought msbuild took json files too nowadays.

</comment></comment></comment><comment><USER13> Please dont do it unless you are google and have built google scale tooling (gforce/big table for code cache)

benefits of monorepo

* change code once, and everyone gets it at once

* all third party dependencies get upgrade at once for the whole company

cons (if you are not google)

* git checkout takes several minutes X number of devs in the company

* git pull takes several minutes X number of dev

* people running get fetch as a cron job, screwing up and getting into weird state

* even after stringent code reviews, bad code gets checked in and break multiple projects not just your team's project.

* your IDE (IntelliJ in my case) stops working because your project has million of files. Require creative tweaks to only include modules you are working on

* GUI based git tools like Tower/Git Source dont work as they cant handle such a large git repo

Google has solved all the issues i mentioned above so they are clearly an exception to this but for rest of the companies that like to ape google, stay away from monorepo

<comment><USER14> > git checkout takes several minutes X number of devs in the company > git > pull takes several minutes X number of dev > people running get fetch as a > cron job, screwing up and getting into weird state

I feel like you are addressing teams of several hundreds of developers. Unless they commit large binary files each day this is hardly an issue for smaller several tens people teams.

> even after stringent code reviews, bad code gets checked in and break > multiple projects not just your team's project.

Revert such code immediately once detected by the CI. Which is harder to do if the changes and their adjustments are spread across dozen of repositories. Also, please compare the easiness of setting up CI for a hundred of repositories compared to a single one with tens thousand of files.

> your IDE (IntelliJ in my case) stops working because your project has > million of files. Require creative tweaks to only include modules you are > working on.

Monorepo does not mean you have to load everything in a single workspace. It means everything gets committed at once. If your tools cannot handle so many files or cannot be configured to work on subsets, blame your tools.

Yes, monorepo present some challenges but handling hundred of repositories is no better. Having done both, I prefer the former.

And yes not everyone is Google, with thousand of developpers and billion lines of code.

<comment><USER15> > Also, please compare the easiness of setting up CI for a hundred of > repositories compared to a single one with tens thousand of files.

It's not so black and white though. There's plenty of difficulty in keeping a mono-CI system running and being helpful.

* The CI service becomes a single point of failure for all developer productivity

* Running a full build on every commit while accounting for semantic merge issues (so serially) is non trivial.

Jane Street did a pretty good write up of how hard this can be: [https://blogs.janestreet.com/making-never-break-the-build- sc...](https://blogs.janestreet.com/making-never-break-the-build-scale/)

</comment></comment></comment><comment><USER16> > Since all code is versioned in the same repository, there is only ever one > version of the truth, and no concern about independent versioning of > dependencies.

This sounds like horror to me: it's essentially a forced update to the latest version of all in-house dependencies.

Interesting article though. It feels like there's a broader lesson here about not getting obsessed with what for some reason have become best practices, and really taking the time to think independently about the pros and cons of various approaches.

<comment><USER17> It's been a long, long time since I worked at Google, but IIRC the build system was like Maven: you could depend on the latest version of something, or a specific version, and only the dependencies you needed would get pulled from the global repo when you checked out code. If your code depended on a specific version of some piece of code, then you'd be immune to future updates to that piece of code unless you updated your dependency config. (Hopefully I'm remembering all of this correctly..)

<comment><USER18> Nope, that's not quite how it worked. Except for a few critical libraries that were pinned to specific versions, every build built against HEAD. However, a presubmit hook would run tests on the transitive closure of code depending on the changed code, and if anything broke, it was your responsibility as the committer to fix it or roll it back.

This is really what kept things stable. If you maintained a a common library and wanted to update it, you had to either keep things backwards compatible, write an automated refactor across the codebase (which wasn't too hard because of awesome tooling), or you would get dozens of angry emails when everything broke. If you relied on a library, you had to be sure to write solid e2e tests or your code might silently break and it would mostly be your fault.

I definitely miss the big G, so many resources were dedicated to engineer productivity and tooling. It's what makes the monorepo work.

<comment><USER17> Thanks! I appreciate the correction. I miss a lot of the resources, too. I also miss the spirit of dedicating serious attention to code quality. Things like Testing Fix-it and Documentation Fix-it days were awesome.

<comment> squeaky-clean > Things like Testing Fix-it and Documentation Fix-it days were awesome.

Can you elaborate on this? Are they just days where the team goes "Ok, no need to stress about new features today, let's just catch on on test coverage / documentation" ? If so, that sounds pretty wonderful.

<comment><USER17> It was company-wide. Every month or two, there would be a "documentation fix- it day" or something similar. The theme would vary: sometimes it was docs, sometimes unit tests, sometimes localization, etc. If memory serves correctly, the idea was that unless you had a high priority/production bug, you'd spend your day working on the theme of the fix-it.

</comment></comment></comment></comment></comment></comment><comment><USER3> Anyone have a cache?

Without reading it, I've used monorepos and multiple repos, and far prefer the former. What people don't get is that any system consisting of software in multiple repos is really a monorepo with a really poor unit & integration test story. The overhead of managing changes to inter-repo dependencies within the same system is utterly insane — I'd say that it's somewhere between 2^ n & n^2, where n is the number of repositories (the exact number depends on the actual number of dependency relationships _between_ repos).

In fact, after these several years, I'm beginning to think that 'prefer' is not the word: monorepos appear, more and more, to be Correct.

<comment><USER19> Unless the software has nothing to do with each other.

A client software in Java, another client in C#, another one in Obj-C and a server software in C++ will be hard to test together, will share no code, and often be developed in independent development cycles, often by independent teams.

Putting such things in monorepos would be stupid.

<comment><USER20> Totally disagree. Any serious development project that has an application that needs to work across iOS, Android, Mac and Windows should be sharing as much of its business logic, in C or C++ which is usable on all those platforms. The UIs of course will be platform-specific, hopefully as thin as possible, but the majority of your code should be totally re-usable.

</comment></comment></comment><comment><USER21> Couple of notes:

\- This is a technique, and it's a toolset, but most importantly it's a _commitment_. Google could have split this up many times. In fact, this would have been the "easy" thing to do. It did not. That's because this strategic investment, as long as you keep working it, keeps becoming more and more valuable the more you use it. Taking the easy way out helps today -- kills you in the long run.

\- This type of work just isn't as important as regular development, it's _more_ important than regular development, because it's the work that holds everything else together.

\- In order for tests to run in any kind of reasonable amount of time, there has to be an architecture. Your pipeline is the backbone you develop in order for everybody else to work

\- You can't buy this in a box. Whatever you set up is a reflection of how you evolve your thinking about how the work gets delivered. That's not a static target, and agreement and understanding is _far_ more important than implementation. I'm not saying don't use tools, but don't do the stupid thing where you pay a lot for tools and consultants and get exactly Jack Squat. It doesn't work like that.

<comment><USER22> The paper does not compare or evaluate this "commitment". It is a data point that monorepo scales to 86TB provided you heavily invest in infrastructure to support it. This is significant as many would have considered that "impossible" as in "it is impossible to make git scale to 86TB".

We don't know if the monorepo approach is worth it. Google believes it is (Facebook as well). Many others don't. The manyrepo approach also has advantages.

<comment><USER21> FTA, "...Over the years, as the investment required to continue scaling the centralized repository grew, Google leadership occasionally considered whether it would make sense to move from the monolithic model. Despite the effort required, Google repeatedly chose to stick with the central repository due to its advantages..."

The article goes into detail about both benefits and drawbacks.

 _The manyrepo approach also has advantages._

Care to elaborate on any of these? (aside from the obvious "works fast on my machine")

</comment></comment></comment><comment><USER23> It works well when most of your code is written in-house. If you have a lot of external dependencies -- not so good.

The problem is what version of the third-party dependency is various projects in the BIG repo should depend on.

Article mentions that: "To prevent dependency conflicts, as outlined earlier, it is important that only one version of an open source project be available at any given time. Teams that use open source software are expected to occasionally spend time upgrading their codebase to work with newer versions of open source libraries when library upgrades are performed."

So if you have a lot of external dependencies -- you need a dedicated team to synchronize them with all your internal projects.

<comment><USER24> The article doesn't say that google need _dedicated_ teams to synchronize with external open source projects. The teams that _use_ each external dependency are responsible for maintaining that as par the course.

<comment><USER25> When submitting a third party package to the repo you become the third party package maintainer. And it's your responsibility to make sure you don't break the world when updating it. If people using it want a newer version (only one version can live in the repo, by policy) it is generally their responsibility to manage that transition. It's been a long time since I managed a third party package, but that's my rough recollection.

The other thing is that third party packages are checked in as source. Everything is built from source at Google.

<comment><USER26> This is still how it's done today.

</comment></comment></comment></comment><comment><USER27> I have a question for Googlers: I keep hearing about refactoring all across the repo. How does that work with dynamic call sites (reflection, REST), etc.?

I mean, there's no way to prove something is actually used in those cases except for actually running the thing.

Do you just rely (and hope) on tests across all projects?

<comment><USER28> There is a good talk from a Facebook engineer about this for JavaScript: [https://www.youtube.com/watch?v=d0pOgY8__JM](https://www.youtube.com/watch?v=d0pOgY8__JM)

It usually goes like this:

\- You make your API backward compatible.

\- You use grep to try and find all the ways people are using it.

\- You write and run a codemod to convert 70-90% of the call sites mechanically.

\- You manually fix the remaining ones. This is usually a good opportunity to throw a hackathon-style event where a bunch of people sit in a room for few hours and drive it down.

\- You remove support for the previous version.

<comment><USER29> > You use grep to try and find all the ways people are using it.

The mere thought of this makes me think of the dark ages and a time in my career that I'd rather forget. All hail statically typed languages. Or languages that can easily be tooled against.

<comment><USER30> If Facebook uses Flow internally, tooling could be written against that. Hell, just removing the old function and seeing the compile errors would expose all the call sites if their whole code base is Flow typed.

</comment></comment></comment></comment><comment><USER31> As someone outside of google, I'm having a hard time seeing how this would actually work. Not as in, it can't be done, as in, is there actually empirical evidence that the supposed benefits (how do you know silos are lower than otherwise?) are happening as claimed because of the monolithic code? Do silos really come down, do big changes to underlying dependencies really get rolled out, or do people hunker down into their own projects, try to cut out as many dependencies as possible?

Perhaps the extra tools, automation, testing, etc helps to a large extent, I can see that being reasonable, but I don't see how they solve all the problems I have in mind.

Perhaps more so, if you've invested in all these automated tools, I am, perhaps (certainly?) ignorantly, not entirely certain what those tools inherently have to do with the choice of a monolithic code base? Couldn't many of them work on a distributed code base if they're automated? I mean, we're talking about "distributed" in the sense that its all still in the one org here...I realise that in practice, this distinction between monolithic and distributed is possibly getting a bit academic...

<comment><USER32> I think your last paragraph sort of makes the point.

A lot of these things depend upon the ability to quickly and easily see how a given piece of code is being used universally. Whether that means a single repo or simply a single unified index of all code and the ability to atomically commit to every repo is immaterial, but the latter sounds a lot like the former.

</comment></comment><comment><USER33> I've found an interesting detail, does anybody know more about this?

"The team is also pursuing an experimental effort with Mercurial, an open source DVCS similar to Git. The goal is to add scalability features to the Mercurial client so it can efficiently support a codebase the size of Google's. This would provide Google's developers with an alternative of using popular DVCS-style workflows in conjunction with the central repository. This effort is in collaboration with the open source Mercurial community, including contributors from other companies that value the monolithic source model."

<comment><USER34> Haven't facebook forked Mercurial to use it for their own mega mono repository?

<comment><USER35> As per this blog post. [https://code.facebook.com/posts/218678814984400/scaling- merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at- facebook/)

</comment></comment></comment><comment><USER36> Google gave a talk at the @scale conference in 2015 about this very topic. You can watch it here (30 minutes): [https://www.youtube.com/watch?v=W71BTkUbdqE](https://www.youtube.com/watch?v=W71BTkUbdqE)

<comment><USER37> Thanks for linking the talk. It was much more descriptive than the article.

</comment></comment><comment><USER38> Interesting:

        The Google code-browsing tool CodeSearch supports
        simple edits using CitC workspaces.
        While browsing the repository, devel-
        opers can click on a button to enter
        edit mode and make a simple change
        (such as fixing a typo or improving
        a comment). Then, without leaving
        the code browser, they can send their
        changes out to the appropriate review-
        ers with auto-commit enabled.

Do they still maintain CodeSearch for themselves? Was it so much burden to maintain reduced version of it for the public?

<comment><USER39> They open sourced a tool for code search: [https://github.com/google/codesearch](https://github.com/google/codesearch)

I don't know if it's the same, as I just heard of it from a YAPC talk a few days ago and haven't tried it, but it's called "Code Search" so it seems likely.

<comment><USER38> It looks like local index and search tool like ack and ag. While above I'm talking about the whole service.

<comment><USER40> "It looks like local index and search tool like ack and ag. While above I'm talking about the whole service. "

The tool that was open sourced by russ uses the same technology/scheme that the original codesearch was built on.

Given Russ wrote code search (the service) as an intern in a few months, one would think you should be able to take the pieces and put the rest together. :)

As for cost to maintain it for the rest of the world --

Look, if you have, say a team of 3-4 people, and your mandate is mainly one to support internal developers, and there is plenty to do there, you just aren't going to end up keeping external folks happy. This is likely true of almost anything in the software world. Even if it works, people want to see it evolve and continue to get better, no matter what "it" is.

If the next question is "why is internal so different from external that this matters", i could start by pointing out that, for example, internally it doesn't need to crawl svn, etc repositories to be useful. There are tons and tons and tons of things you don't need internally but need externally. What it takes for a feature to be "good enough" to be useful is also very different when you are talking about the world vs 20000 people.

So it's not really even a question of "cost to maintain" in some sense.

</comment></comment></comment></comment><comment><USER41> Does this mean that one Googler could checkout the complete system, and sell it or put it online? How many people have access to the complete repository? How big is one checkout?

<comment><USER10> Checkouts are apparently instantaneous. Behind the scenes, there is a FUSE filesystem that faults in files by querying Google's cloud servers. So it does not require a significant amount of space (but does require fast access to Google's servers, which can be problematic).

Almost all engineers have access to the "complete system," which is really Google's server-side software. Other repos like Android have historically been more locked-down, but there's been some recent effort to open them up within Google.

Presumably if you tried to copy all of the files, you'd first be rate-limited, then get an access denied, and lastly a visit from corporate security. I wouldn't want to try.

<comment><USER42> Is it a good idea to try to run the du command in the root directory?

<comment><USER41> Probably even better to try sudo -i! ;-)

</comment></comment></comment></comment><comment><USER43> Since acm can't handle the traffic:

[https://web.archive.org/web/20160625124824/http://cacm.acm.o...](https://web.archive.org/web/20160625124824/http://cacm.acm.org/magazines/2016/7/204032-why- google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext)

</comment><comment><USER44> There are advantages and disadvantages to consider. Clearly monolithic repositories allow you to leverage commonality but it's not free.

For example, single-repository environments may require you to check out _everything_ in order to do _anything_. And frankly, you shouldn't have to copy The World most of the time. Disk space may be cheap but it is never unlimited. It's a weird feeling to run out of disk space and have to start deleting enough of your own files to make room for stuff that you know you don't care about but you "need" anyway. You are also wasting time: Subversion, for instance, could be _really slow_ updating massive trees like this.

There is also a tendency to become too comfortable with commonality, and even over-engineer to the point where nothing can really be used _unless_ it looks like everything else. This may cause Not-Invented-Here, when it feels like almost as much work to integrate an external library as it would be to hack what you need into existing code.

Ultimately, what matters most is that you have _some_ way to keep track of which versions of X, Y and Z were used to build, and _any_ stable method for doing that is _fine_ (e.g. a read-only shared directory structure broken down by version that captures platform and compiler variations).

<comment><USER45> Companies that do this don't require you to check out the world, that would be craziness. Perforce allows for partial mappings and is used by pretty much all the big companies. Even Microsoft's internal source depot is just a fork of perforce.

Dependencies are usually handled by a binary import/export system where you pull modules from a shared "build the world" system from a known checkpoint.

<comment><USER46> Both git and hg supports shallow (low history) and sparse (selective files) checkouts as well, facebook has a blog post somewhere about how they built it into hg.

<comment><USER47> It's still not the same as perforce's mappings. Even with shallow repos, git will force you to download the entire world each time you pull or fetch.

<comment><USER48> That's not really the entire world though, because the history before the shallow clone will not be pulled or fetched. You'll get all the new stuff though.

<comment><USER45> I don't think the scale of these places are fully appreciated. Your local enlistment could be a few hundred gigabytes and that is only the head revision of stuff you work with daily. Keeping more than just the current revision around is a lot of data for even a beefy workstation.

</comment></comment></comment></comment></comment></comment><comment><USER49> See also: [https://www.youtube.com/watch?v=W71BTkUbdqE](https://www.youtube.com/watch?v=W71BTkUbdqE)

</comment><comment><USER50> History as a guide, we will look back on this for the tire fire it is. monorepo and projects like Chrome and Android to me look like a company that is trying its best to hold itself together but bursting out at the seams the same way Microsoft did in the '90s with Windows NT and other projects. Googlers frequently use appeal to authority to paper over the fact that they are basically the new Microsoft.

<comment><USER51> OK, interesting point of view.

Can you justify it with examples?

<comment><USER50> That was just my reaction to the article. I saw Google and ACM so thought it would be something good, but in the end I fell victim to the authority click bait. The article is written in a scholarly style, but it is neither academic nor profound. It is the engineering equivalent of an intra-office memo describing how a massive company is going to organize their sales regions and Take Over The World. Imagine for a moment if IBM, Microsoft, or the Department of Defense wrote this exact piece today... would ACM have published it? Would it have made the front page of HN? I simply felt disappointed and expressed that reaction.

For examples of Google non-superiority (remember, this is a hacker/entrepreneurial forum, we should seek solidarity in outdoing behemoth entities with agility), I simply encourage you to think for yourself and not put any credence into lore, methodology, or tech simply because it comes out of Google. I see a 1:1 comparison between Android and the non-WinNT kernel Windows releases. Google put a festering pile of code out and allowed handset makers and carriers to basically never patch any type of vulnerability. The permissions model and app over reach are just barely now contained in Android 6... seven years after release. Chrome bundles tons of third party libraries... it's another moving train wreck with enough bodies to somehow deal with the naive vendoring, scope creep, and general upkeep but it's still a nightmare to correctly build and package for an OS. By comparison I have immense respect for the Servo developers who are making an interesting reach with far less resources than Google.

</comment></comment></comment><comment><USER52> One thing to consider is that monorepo tooling is (outside of Google) still pretty immature.

At Square, we have one main Java "monorepo", one Go "monorepo", and a bunch of Ruby repos. The Java repo is the largest, by a huge factor (10x the Go repo, for example).

The Java repo is already noticeably slow when doing normal git operations. And I'm told we've seen nothing of the pain the folks at Twitter have had with git: their monorepo is huge.

We periodically check to see how the state of Mercurial and Git is progressing for monorepo-style development. Seems like Facebook has been doing interesting stuff with Mercurial.

But I still miss the fantastic tooling Google has internally. It really is so much better than anything else I've seen outside.

<comment><USER53> How big is your mono repo ?

We have ~90k lines of java code. I don't think it will be a problem unless it grows ten times. We spend time grooming it. Removing old code, etc. I believe it is the case for most companies. Unless you are google, facebook, square, etc.

<comment><USER52> Our Go monorepo has 1,325,332 lines of non-comment code, according to `cloc`, although about half of that is generated protobuf code. I'm still waiting for `cloc` to finish on the Java repo…

<comment><USER54> It's likely that Mercurial would scale for you today, using Facebook's stack. Drop me an email if you'd like to chat sometime.

</comment></comment></comment></comment><comment><USER55> Seems to be down... (I can't imagine the ACM is _that_ easy to take down..?)

<comment><USER56> Remove the /fulltext and it loads instantly.

<comment><USER2> Thanks! How on Earth did you figure that out?

<comment><USER56> I have to fix a lot of broken URLS from the submissions sent in to hackaday.com. I guess I don't even think about fiddling with them until they show up anymore, haha:) What a weird skill.

</comment></comment></comment></comment><comment><USER57> For me, it seems that the power of this model is not that "we have a single head", rather than, "we can enforce everyone use the newest library version (expect for sometimes create a whole new interfaces)".

Let's suppose we have a tool that can

* automatically check out the HEAD of each dependent repo

* run a complete integration tests across all the repo before any push/check-in.

This will work fine even with a multi-repo model, won't it?

Also, As mentioned earlier by others, The reason google can do it is because google can * maintain a powerful cloud-based FUSE file system to support the fast checkout

* run automated build tests before any submits to ensure the correctness of any build

So they don't need to maintain multiple dependency version(for the most time)

</comment><comment><USER22> How does Google deal with external dependencies? E.g. the Linux kernel. Do they have a copy of Linux in the monorepo for custom patches? Is there a submodule-like reference to another repository? Is there a tarball in the monorepo, a set of patches, and a script to generate the Custom-Google-Linux? What happens when a new (external) kernel version is integrated?

</comment><comment><USER58> It's amazing to read this kind of articles, because they are the best argument to all those very opinionated (or simply arrogant) people who claim that "one repository is s __* " or similar, such as "this technology is better than this one", "unit-tests yes/no", the list of religious wars could go on forever ...

Thanks a lot for sharing!

</comment><comment><USER59> This works because they have teams dedicated to reproducing the work everyone else gets from their ecosystem's community.

For us non-googlers, would you trade away the benefits pip,gem,npm for single source of truth?

<comment><USER60> I can't see why I can't have both...

If my central package repo had genuinely reproducible builds, such that I could download the source, run the build process and know that I had the same output that the repo held, then I think that I would love to have a setup where:

\- I could "add a dependency" by having an automated process that downloads the source, commits it as its own module (or equivalent) in my source repo, tags it with the versioned identifier of the package, and then builds it to make sure it matches what the package repo holds.

\- I could make local modifications to the package if I needed to, and my source control would track my deviation from the tagged base version

\- I could upgrade my package by re-running the first step, potentially merging it with my local changes.

 _Hmm, I think I just described the ultimate end state for Go package management..._

</comment></comment><comment><USER61> The monorepo solves source-to-source compatibility issues, but it doesn't solve the source-to-binary compatibility issues. For that you need a solid ABI, possibly versioned, unless every code checkin redeploys every running process everywhere.

Say version N of the code is compiled and running all over the place, and you make a change to create N+1. Well, if you don't understand the ABI implications of building and running your N+1 client against version N servers (or any other combination of programs, libraries, clients, and servers), then you'll be in a mess.

And if you do understand those ABI boundaries well and can version across them, I'm not sure you need a monorepo much at all.

<comment><USER62> protobuf and grpc (both open-sourced) solved that: just don't reuse a protobuf field number and you are fine.

</comment></comment><comment><USER63> I find it really hard to find anything when it's split into a bunch of smaller repositories. If you're going to do that, you should at least have one master repository that adds the tiny ones as git submodules.

</comment><comment><USER64> This is a very interesting article. I believe there is value to using libraries about there is something to be said for monrepos. Interesting that Google and Facebook are working together to extend Mercurial for large repo's.

The article gave me the following idea's to extend GitLab: Copy-on-write fuse filesystem [https://gitlab.com/gitlab-org/gitlab- ce/issues/19292](https://gitlab.com/gitlab-org/gitlab-ce/issues/19292) Autocommit using auto-assigned approvers [https://gitlab.com/gitlab- org/gitlab-ce/issues/19293](https://gitlab.com/gitlab-org/gitlab- ce/issues/19293) CI suggesting edits [https://gitlab.com/gitlab-org/gitlab- ce/issues/19294](https://gitlab.com/gitlab-org/gitlab-ce/issues/19294) Coordinated atomic merges across multiple projects [https://gitlab.com/gitlab- org/gitlab-ce/issues/19266](https://gitlab.com/gitlab-org/gitlab- ce/issues/19266)

</comment><comment><USER65> At previous job I had Google to thank for the team's god awful decision to choose perforce over git thanks to some silly whitepaper or article. They acted like git was some fringe version control system that no one would use professionally... just for fun toy projects.

<comment><USER66> Perforce is a perfectly reasonable choice given certain technical and organizational constraints. It is a bad choice for others. Git is a good choice for many projects. It is a terrible choice for others, and was a much worse choice in the past.

</comment></comment><comment><USER67> My experience working in large corporations and smaller companies with both approaches tends to make me lean towards the multi repo approach.

Some details:

* Amadeus: huge corporation that provides IT services for the airline industry, handling the reservation process and the distribution of bookings. Their software is probably among the biggest C++ code bases out there. We were around 3000 developers, divided into divisions and groups. Historically they were running on mainframes, and they were forced to have everything under the same "repository". With the migration to Linux they realized that that approach was not working anymore with the scale of the company, and every team/product has now its own repository.

All libraries are versioned according to the common MAJOR.RELEASE.PATCH naming and upgrades of patch level software are done transparently. However Major or release upgrades have to be specifically targeted. What is more important for them is how software communicates, which is through some versioned messages API. There is also a team that handles all the libraries compatibility, and package them into a common "middleware pack". When I left around 2012 we had at least 100 common libraries, all versioned and ready to use.

 _Murex

financial software used in front/back office for banks. We had one huge perforce repo, I can't even begin to tell you what pain was it. You could work for a day on a project, and having to wait weeks to have a slot to merge it in master. Once you had a slot to merge your fix in master, chances are that code has changed meanwhile somewhere else and your fix can't be merged anymore. That was leading to a lot of fixes done on a premerge branch, manually on the perforce diff tool.

Also given the number of developers and the size of the repository, there was always someone merging, so you had to request your slot far in advance. Maybe the problem was that the software itself was not modular at all, but this tends to be the case when you don't force separation of modules, and the easiest way is to have separate repositories.

_ Small proprietary trading company We didn't have a huge code base, but there were some legacy parts that we didn't touch often. We separated everything in different repos, and packaged all our libraries in separate rpms. It worked very well and it eased the rebuild of higher level projects. If before to release some project would take ~1h, with separation of libraries it would only take 5 minutes. It was working well because we didn't change often base libraries that everyone was depending on.

</comment><comment><USER68> I'd be curious to see how this works with third party libraries/etc...

For instance did everyone at Google migrate to Java 8 at the same time? That seems like a huge amount of work in a mono repo.

</comment><comment><USER69> Cached version: [http://webcache.googleusercontent.com/search?q=cache:XDtepkB...](http://webcache.googleusercontent.com/search?q=cache:XDtepkBDv3MJ:cacm.acm.org/magazines/2016/7/204032-why- google-stores-billions-of-lines-of-code-in-a-single- repository/fulltext+&cd=1&hl=en&ct=clnk&gl=uk)

</comment><comment><USER70> A lot of the benefit that comes from this code storage method doesn't really seem like the best solution.

The presenter in the video linked in this thread that this is very advantageous due to cross dependencies. I don't think that this is the correct way to handle a cross dependency.

I'd much rather handle it by abstracting your subset of the problem into another repository. Have some features that two applications need to share? That means you're creating a library in my mind. This is much better suited for something like git as you can very simply use sub-modules to your advantage.

Hell, you can even model this monolithic system within that abstracted system. Create one giant repository called "libraries" or "modules" that just includes all of the other sub-modules you need to refer to. You now have access to absolutely everything you need within the google internal code base. You can now also take advantage of having a master test system to put overarching quality control on everything.

This can be done automatically. Pull the git repo, update all the sub-modules, run you test platform.

I'd say that's a better way to handle it. Creating simple front end APIs for all of the functionality you need to be shared.

</comment><comment><USER71> A great talk about this: [https://www.youtube.com/watch?v=W71BTkUbdqE](https://www.youtube.com/watch?v=W71BTkUbdqE)

</comment><comment><USER72> Why does google have billions of lines of code?

This is more of a rhetorical question. As a tech minimalist, the preferrable answer by a long shot would be that, internally, Google is keenly aware of the severe bloat and technical debt of their codebase and have clear plans going forward to drastically reduce the scale, by more than 1000x at least, without sacrificing any of the features/bug-fixes/performance of any of the code.

<comment><USER73> Realistically, I don't think you can have a minimalist, clean and focused code base with thousands of engineers pounding away at the keyboard. You ought to make some trade offs with that many employees.

<comment><USER72> That sounds like reverse justification, i.e.,

Google's operations probably require X lines of clean code added everyday by 10% of the engineers (so ~5000 instead of ~50,000 engineers), but because of the sheer number of engineers Google has, that are supposed to do something continuously to show performance, Google has ended up with ~10 or ~100 X lines of daily bloat accumulation.

Sounds like a textbook example of too-many-hands-spoiling-the-broth.

</comment></comment></comment><comment><USER74> I suppose they don't do git pull :p, what's their source control management system?

<comment><USER75> I believe it's called Piper.

<comment><USER76> Pied ... Piper?

<comment><USER77> Piper is Piper expanded recursively.

[https://99designs.com/t-shirt-design/contests/t-shirt- design...](https://99designs.com/t-shirt-design/contests/t-shirt-design- wanted-google-86935)

<comment><USER78> Oh, God, that is awesome.

</comment></comment></comment></comment></comment><comment><USER79> > The Google codebase includes approximately one billion files

> approximately two billion lines of code in nine million unique source files

So what are the other ~991 million files? I don't doubt that there's a lot of binary files, but what else? Also what does "unique" source files mean?

<comment><USER80> It's the next sentence in the article. > The total number of files also includes source files copied into release branches, files that are deleted at the latest revision, configuration files, documentation, and supporting data files; see the table here for a summary of Google's repository statistics from January 2015.

<comment><USER79> > see the table here for a summary of Google's repository statistics from > January 2015.

Is it just me or is there not actually a table there?

</comment></comment></comment><comment><USER81> I wonder if they also distribute binaries internally. Otherwise, setting up a developer machine could take really long. Like installing Gentoo Linux :)

<comment><USER82> With CitC meaning all the source is instantly, "locally" available and up to date, and something like bazel.io meaning you always have a reliable and fast way to rebuild something out of cached/distributed build outputs[1], you don't _need_ to distribute a binary in the general case.

Whoever needs a tool can cd to the source of the tool, build it right then and there, and run it.

[1] [http://google-engtools.blogspot.com/2011/10/build-in- cloud-d...](http://google-engtools.blogspot.com/2011/10/build-in-cloud- distributing-build.html)

</comment></comment><comment><USER83> The idea of working directory in cloud is dangerous, because it reveals that I haven't yet started anything haha.</comment>


Most marijuana medicinal benefits are inconclusive, wide-ranging study finds - <AUTHOR> https://www.theguardian.com/society/2017/jan/12/marijuana-study-benefits-chemotherapy-pain-multiple-sclerosis <comment><USER2> Don't let the stoners hear you say that. I've never met a crowd of people more insistent that their vice was virtue.</comment>


Ask HN: Use Facebook to land interviews? - <AUTHOR>

I'm currently seeking an Internet professional job (Marketing or Web Design).  I've sent numerous resumes out & never received an interview invite, until I found names of hiring managers(on company site) and then found/sent them message on Facebook re: jobs.  This worked and landed me an interview that went great with her(age 29), but 2nd interviewer her boss (age 47) hearing I did this ended interview.  So, would you use Facebook this way or it's going to far? <comment><USER2> I had someone send me a friend request via FB during a recent hiring round. My thought was, "Who is this person and why would they think I want to be their friend on FB?"

To me, FB is personal - it's not LinkedIn which is 'work'. FB is for friends and family. Hit me up on LinkedIn and, although I'll still likely ignore you, there's at least the chance that I won't whereas I'll never respond to something on FB like that.

I'm 38 so perhaps my usage is different from you younguns.

</comment><comment><USER3> Stick to linked in rather than FaceBook. Some people prefer their facebook to be friends and family and find it intrusive if you poke your head into their life.

You will get better results and won't run into this problem on linked in since that is what it was designed to do and everyone is in a biz mindset there. Also you can try Plaxo if you need contact info.</comment>


Mac's share falls to five-year low - <AUTHOR> http://www.computerworld.com/article/3155088/apple-mac/macs-share-falls-to-five-year-low.html <comment><USER2> I keeping hearing the narrative from this crowd that the MBP is on its way out of being in vogue for developers, but I don't buy it at all.

First of all, this is market share up to the release of the new MBP. It's not surprising that their market share has been slipping given that up to this point they haven't released a significant update to the MBP since 2013.

But getting to the point, the Mac ecosystem is now ingrained into open source development. Believe me I used to use a PC not too long ago and nothing would work because OS software is designed to run on top of a NIX environment. I recently had to go through this exercise with a colleague who was in denial. But over time, it ends up the same: software built to run on Linux servers runs best under an environment that is designed more like Linux. He now owns a MBP.

So Windows is out (for non .NET devs). That leaves us with what, Linux itself as the OS? Anyone who suggests doing this either hasn't done it before or has way too much time on their hands. I use macOS because I don't have time to hunt for drivers, trying to understand an obscure error discussed in a long forum thread or having all my software no longer work just because I updated a package. I've already tried that twice once with Gentoo and then with Ubuntu years later hoping it would be different. I know plenty of others who have as well. Ultimately we have jobs and we need to debug our own software.

Which brings us back to the Mac. I fully expect this release to be their Windows 8 moment, a beta event from which they will recover from given time for hardware to catch up. Not every release can be a stellar event. Give it time.

<comment><USER3> > the Mac ecosystem is now ingrained into open source development.

Interesting...

> Anyone who suggests doing this either hasn't done it before or has way too > much time on their hands.

Oh...

Quick question, when was the last time you did it?

Currently I have three full time Linux boxes:

* Custom PC build I did myself

* System76 Galago UltraPro

* Dell XPS 13 Developer Edition

Oddly enough, the one that gave me the most issues was the Dell supported XPS 13 DE but I didn't have to do a thing, just waited for driver updates from Dell which I could install via:

> sudo apt-get update

> sudo apt-get upgrade

But at the end of it I have a Linux laptop with premium build quality, 8 hour battery life (with 4K screen), and an external battery pack that easily extends my battery to a full day of work before needing an outlet.

My company gave me a Mac, but literally _every_ other computer I personally own, right down to the Dell T710 server I have is running Linux (Ubuntu 14.04.3 specifically) without issue.

I don't expect Linux to take over the Desktop market. But for Developers I see the current MBP as just another reason to seriously consider just getting a Linux laptop from an OEM like Dell or a niche player like System76.

Let's face it, this MBP just highlights the fact that its target market is not developers or power users. Which is fine, and it probably can be a successful product with or without us...

<comment><USER4> The second you compile one package to get any of those boxes to work, for me, the pro-linux box argument is negated. Particularly for work machines, I don't have time to compile and install just to get my box up and running. Mac worked for me for this reason, I presume the reasons are the same for many. You like the freedom and power your boxes allot you, I like the simple operation of the mac. My problem is Macs are quickly becoming more work with all of there services and issues. When I start having to search for drivers online I might consider switching to Linux, but this won't be a cure all, because I deal too much in graphics.

<comment><USER5> > The second you compile one package to get any of those boxes to work, for > me, the pro-linux box argument is negated.

This seems a strange things to say considering everyone I know who uses a Mac for dev uses homebrew, which compiles as part of the install.

<comment><USER6> Homebrew tries to download a binary for pretty much every package, and only rarely compiles from source.

<comment><USER7> True. It used to be like that at the beginning, but now it's rare.

</comment></comment></comment></comment></comment></comment><comment><USER8> PSA: This "news" comes courtesy of a company called Net Applications, which I've never heard of before. Looks like they're a web analytics firm. So take this with a huge grain of salt, because they can't actually see real user share, all they can see is the share of people who browse to their clients' sites.

<comment><USER9> So what would be the best way to estimate OS market share? Stopping short from including household OS usage in worldwide census?

<comment><USER8> I'm not sure, but you could start by asking someone who's in a position to observe a much larger portion of internet usage. For example, I bet CloudFlare could collect some interesting statistics.

<comment><USER10> While CloudFlare would be a much better source, I think it's not so bad to compare a large number of sites, with their previous selves.

</comment></comment></comment></comment><comment><USER11> Also see the relative growth of /r/buildapc vs. /r/apple: [http://redditmetrics.com/r/buildapc#compare=apple](http://redditmetrics.com/r/buildapc#compare=apple) (click on Total Subscribers). March 2013 was the crossover point.

I'm trying to compare Apple on it's own turf here (tapping into the enthusiasm of retail / consumer folks). That's a lot of mindshare lost, IMHO, by defining themselves as the "Bose of computer hardware".

Important mindshare at that: young people. Once these young folks struggle with BSODs, fiddling with BIOS settings, NVidia drivers, screwdrivers and thermal paste, and get a rig up and running, it becomes an addiction. I find it ironic that it is the very opposite of what Apple offers, a trouble-free "It just works" experience, that is the appealing factor of /r/buildapc.

The one thing they should have learned from Steve is: everything has a context; it's OK to change your opinion.

<comment><USER12> I'm not sure I believe your assertion that building a PC makes people love it for life— I built a PC in high school, then switched over to a Macbook for college and haven't looked back.

Now that fiddling with computers is my job, it's less appealing as a hobby.

<comment><USER13> Agree. I used to build PCs as well. I even had a review site that received 2MM uniques a month and manufacturers would send me motherboards and top end video cards, for free, to review. I loved making PCs but would I trade my Macbook Pro and go back to a PC/Windows setup, no.

I don't imagine anyone would want to go thru that. Getting a case, fiddling with screws, power supplies, Video Card, and CPUs. Even worse, it is highly error prone. Do something wrong and POOF that 800 dollar CPU you bought is toast.

<comment><USER14> Arguably, you a trading the chance to lose 800 with a guaranteed loss of around that much, just by paying the Apple premium.

<comment><USER13> 800 is the tip of the iceberg. There is a lot that "just works" in an Apple ecosystem.

<comment><USER10> I was briefly an Macbook Pro user for four months (recently went back in late Dec.) could you talk a bit more about features that "just work" in Apple?

</comment></comment></comment></comment></comment></comment><comment><USER15> Whether this was a reflection of overall PC slowdown, I don't know but Apple execs need to make some course corrections sooner rather than later.

The apparent neglect of developers with respect to some of the changes (and non-changes) in the laptop and desktop lines seems to be giving many developers pause and concern.

<comment><USER16> One thing that Windows (somewhat famously) gets is "developers! developers! developers!"

Apple has a passionate, loyal developer community. Developers who create iOS apps use OS X machines to do it. They spend almost twice as much on an OS X machine (vs. a Windows machine) to get over the barrier to entry.

Apple has never made anywhere close to the same investment in their developers that their developers have made in Apple. Their mindset can be summarized as (I think):

1\. iOS and OS X are "easy to develop on" (so Apple thinks) so WWDC is sufficient as far as developer relations. Lately even WWDC is an empty shell.

2\. Huge software failures don't seem to touch Apple's revenue stream (e.g. Maps, iCloud, security exploits), which over time makes Apple more and more deaf to the realities of software outside their company.

3\. Apple execs are "courageous" and visionary. The company has a very top- down culture.

<comment><USER17> I think Microsoft forgot about developers for a while. The Windows 8 timeframe wasn't a great time to be a Microsoft developer. They have been recovering mindshare lately, but it's the same back and forth. It's less clear that developer mindshare even matters as much these days when the web is the real desktop platform for most software.

<comment><USER18> Depends on the developers you talk to.

As someone whose Windows dev experience goes back to Windows 3.0, I was thrilled with WinRT, having Visual C++ finally catching up with C++ Builder and .NET finally going properly native as it should have been since .NET 1.0.

<comment><USER19> Yeah, but they also started a number of projects only to kill them later (eg Silverlight). This was very annoying for developers who had invested a lot of time.

Hopefully things will be more stable now.

</comment></comment></comment></comment></comment><comment><USER20> Why does StatCounter disagree? They find OS X user share currently at an all- time high of 11%: [http://gs.statcounter.com/#desktop-os-ww- monthly-200807-2016...](http://gs.statcounter.com/#desktop-os-ww- monthly-200807-201612)

<comment><USER20> StatCounter's answer to that question: [http://gs.statcounter.com/faq#net- apps](http://gs.statcounter.com/faq#net-apps)

<comment><USER21> This stuck out for me, but I might be wrong:

Net Apps base their stats on unique visitors per site per day. ("We 'count' unique visitors to our network sites, and only count one unique visit to each network site per day.") We [StatCounter] base our stats on page views

So if an os x user read more pages than a linux user on a specific site, that same user will have more "weight" in the statcounter analysis.

Basically.. different methods that actually measures different things.

</comment></comment></comment><comment><USER22> I can understand the fall, since I myself am torn or the subject. I am a huge fan of Apple laptops for two reasons: 1. I can do all my development on the same Unix environment I run Adobe and various DAWs on. 2. Apple's trackpads. Having said that, I've been considering a move back to my previous two-laptop setup; one Linux machine for development and general use, and one Windows machine (shudder) for Adobe and DAWs. I can get a PC with the same specs or better than a Mac, with memory capacities up to 32GB of RAM (twice what Apple offers), for around $1,000.00 less. I could also solve the problem of the vanishing hardware (e.g. ports, Esc key, etc.) by going this route.

However, I still like macOS a million times more than I like Windows. I'm not ready to switch yet, but I'm thinking about it. If Apple continues to neglect their Mac line, and fail to offer specs comparable to their competitors, my thoughts may turn into action. I imagine others are feeling the same way.

</comment><comment><USER23> They are expensive and underpowered. I used to get the top of the line macbook but it's not worth it anymore. It's starts to look like the John Sculley era. If it wasn't for the pro audio support I would jump on the linux boat.

<comment><USER24> Apple prices like a luxury item: no sales etc..

But the thing is - tech is not like fashion. You can't just call it 'Gucci' and hold the plebes at bay with high prices.

It's utility - so when there is less utility, people will drop apple and go elsewhere.

If they want to keep luxury brand status they actually have to provide something of value.

<comment><USER25> This is an odd sentiment to hear on HN.

We are usually technical people, surely we can see past "spec" as the only differentiator of two laptops.

Apple are priced like a high-end business quality laptop. (except upgrades are a higher mark-up) if you compare laptops based on the quality of their build Apple laptops are quite competitive.[0]

That's before you factor in little things that don't seem to make it to business line laptops even like protection against USBKiller[1] and getting BIOS firmware updates 8 years after buying a laptop.[2]

It's disingenuous to compare an Apple Macbook with an Acer Aspire on things like specification without taking into account all the little things.

If you haven't noticed, spec selling has thoroughly destroyed the bottom end of the laptop market, it's super difficult today to get a decent quality laptop because manufacturers are just throwing out devices with high spec and corner cuts everywhere else.

I say this, as a person attempting to buy a Dell Precision 5520. I'm not an apple fanboy, but I appreciate quality. It's not a fashion label.

[0] [http://i.imgur.com/Gjnr0sw.png](http://i.imgur.com/Gjnr0sw.png)

[1] [http://www.express.co.uk/life-style/science- technology/71174...](http://www.express.co.uk/life-style/science- technology/711745/USB-killer-2-0-Macbook-Pro-Apple-Macbook-Air)

[2] [https://support.apple.com/en-us/HT201518](https://support.apple.com/en- us/HT201518)

<comment><USER23> You may compare apples to oranges because the CPU and other components may be slightly different(usually they are older and cheaper on the mac). It's a known fact that Apple has the highest(by far) margins on laptops.

Apple used to be priced and marketed as a high-end business quality laptop but now I feel it's marked more as a lifestyle product.

<comment><USER25> the CPU is on display for the precision 5510 in the screenshot.

That's the same CPU used in the high end 15" macbook pro. I'm failing to see how what you said holds true when the original price of the Dell is $1,000 higher than the Macbook. (with a smaller m.2 SSD, even.)

</comment></comment></comment></comment></comment><comment><USER26> IBM for one is converting their laptops to mostly Macs, claiming to calls to support is way down compared with users of PCs (e.g., look at total cost of ownership -- TCO). IBM has software which helps to deploy Macs in the Enterprise.

The integration of Macs/ Mac OS with the iPhone / iPad eco-system is helpful as well. I use iMessage a lot on my Mac.

For those that need it, tech support is readily available in Apple stores.

<comment><USER27> IBM is selling enterprise Apple support, them claiming that the TCO is lower is like a car salesman telling you the TCO of their specific brand of vehicle is lower. Take it with a huge grain of salt. IBM has a vested interest in pushing Mac enterprise adoption.

</comment></comment><comment><USER24> I think it's as simple as better PC's and Macs that have not really improved and are just really expensive.

<comment><USER28> Certainly with laptops; PC laptops 4 years ago were really a cut below the macbook pro. PC laptops have improved so much in 4 years. And apple just gimped the latest mbp with a really bad keyboard and another $500 on the sticker.

</comment></comment><comment><USER29> Personally I'm hopeful. I think Apple does their best work when they're on their back foot. When they get to be the market leader (however you want to define that term) they get lazy. I wouldn't like to see a repeat of their situation in 1997, but it certainly did spur some big changes.

<comment><USER30> While I would agree with you a company is the sum of its people and right now the personnel at Apple has changed just way too much.

I'm not as hopeful - Apple will continue to be a behemoth, but I'm afraid the magic is gone. It may not go down the path of HP, but it will be closer to Dell in the future than to Apple at its Zenith.

</comment></comment><comment><USER31> Does this really matter?

I've also felt that recent mac desktop/laptop releases have been poor. But is it really important to satisfy the masses in this market? It seems like we're in a world where most people could be quite happy with doing most things on a phone or tablet.

That's not to say it isn't likely an important strategic market (after all it's the only platform you can develop iOS apps on). But having a large share of this market might not be important.

<comment><USER32> > _It seems like we 're in a world where most people could be quite happy with > doing most things on a phone or tablet._

We're not those people, though, and we do care.

> _That 's not to say it isn't likely an important strategic market (after all > it's the only platform you can develop iOS apps on). But having a large > share of this market might not be important._

As long as people also have jobs, it will be.

<comment><USER17> The reason people make apps for iOS/macOS despite the small market share is because those users spend a disproportionate amount of money. As long as Apple keeps them there it doesn't matter.

But, if the people who are spending money are using Apple products because they enjoy the integration across the entire product line and they become disillusioned, the whole house of cards could come tumbling down. Alternatively, if people evangelizing Apple fall in this camp and stop recommending them, that could also have adverse affects. I don't know if this will happen, but it's a risk for them for sure.

In the end a killer iPhone can probably solve everything, but Mac users leaving is definitely a drag.

</comment></comment></comment><comment><USER33> Oh please...this is like saying google shares fell. It's not like there is a new competitor that entered the marketplace or that mass mac users are jumping ship like a mass exodos for windows or Linux. It's because they haven't launched an iPod or iPhone. But I guess people gotta write to get those clicks these days..

</comment><comment><USER34> This overall slowdown could be the reason why Apple made a gimmick for newcomers, i.e. the touch bar. They needed to try to boost sales.

<comment><USER32> They don't think like that. "Let's make a gimmick for newcomers".

They just legitimately thought it was great and will it enough to impress people and shut them up about the late revamp of the MBP line.

And it could be good, with certain provisions, but not will all the other BS coming with it.

The main issue is it seems nobody at the top could see this -- and I mean see this when they said ok initially, because surely they did know the issues before launching the machine, when it got to wider testing (before that it was only small teams that had seen the whole new laptop plus strip, as it their usual modus operandi).

<comment><USER35> If the touchbar is so amazing, why didn't Apple have the courage to just replace the entire keyboard with one big OLED display?

You can easily see how the touchbar comes across as being gimmicky. Lenovo already ditched their touch bar on the X1 Carbon (2nd generation) because it was a terrible idea. Buttons are useful, particularly for people who touch type.

<comment><USER32> > _If the touchbar is so amazing, why didn 't Apple have the courage to just > replace the entire keyboard with one big OLED display?_

Obviously this is no argument.

It basically is: If cake is so amazing why don't we eat cake or day?

Cake is indeed amazing to have in moderation, but it's also not the best thing to solely eat. We could thrive on just greens and meet maybe, but we'd do worse with just cake.

Standard alphanumeric keys are used far more often, and people rely on them far more than they do on function keys (common people, the 95% of users, don't use debuggers or vim). Without a great haptic feedback story that actually gives the sense of clicking it would be disaster.

Plus, it would be way costlier, and just give diminishing returns (since most of the time we just want the alphanumeric keys to be just that, whereas function keys already had a double life as controller keys for sound, etc).

Third, even if it was ergonomically perfect and likable, it will obviously be even more power hungry and expensive at this point.

<comment><USER35> To make it cheaper, maybe they could just do half the keyboard. Say split it between 5-6, t-y, g-h, and b-n and just make the left half with an OLED screen. The best part is they could then sell you a new MBP in two years which has a full OLED keyboard when the prices have come down.

Back to reality, the problem is that more than 5% of common people use those function key buttons on a daily basis, and they need that haptic feedback. I want my computer's volume, playback and brightness controls to be easily accessible. I also want to be able to use my escape key. I don't want to have to switch to some other application in order to turn the volume down or pause my music when I'm interrupted by someone, and it's nice to be able to control the screen brightness without having to switch applications in order to do so.</comment></comment></comment></comment></comment>


Do atheist men want to have children?  Or do they merely accede to so because their wives really want children? - <AUTHOR>

Men who are religious might want children because it is a religious duty to do so.  But there is no such duty for atheist men.<p>One might argue that evolution resulted in men and women being different in this way so that there is a separation of concerns, with men more concerned with bringing food for their families while their wives take care of their children. <comment><USER2> Animals reproduce and I doubt many of them are religious. Actually, I didn't realize anyone merely had kids because they thought it was their religious duty. If so, I feel sorry for their kids.

Not sure what this has to do with hacking, though.

</comment><comment><USER3> My dad is atheist, and I don't think he was browbeaten into having all three of us...

</comment><comment><USER4> doatheistmenwantchildrenordotheymerelyaccedebecausetheirwivesreallywantchildren.com may still be available.

if it is, you should jump on that.

</comment><comment><USER5> You know, it only takes a few people posting completely off-topic things to ruin the board for everybody.

Just sayin'</comment>


Amazon AWS vs GitHub – "Suspected Unauthorized Activity" - <AUTHOR> http://pivotedreality.wordpress.com/2014/04/11/amazon-aws-vs-github-suspected-unauthorized-activity/

<comment><USER2> "When we moved our Github repository from private to public (as the co-founder was leaving and I had to share it with some other prospective co-founders), the AWS keys were all in the open for everyone under the sky to play with. Doing some online search, I figured out we were not the only ones. It's apparently quite a common mistake developers do."

Yes, Yes and Yes. I have made a similar mistake once on Github for a personal project, I realized my mistake and immediately updated the file and did a new commit. Guess what ? Even after committing a new version of the file, you can always check the "History" of the file which will show you the version with the credentials. My only option was to delete that config file completely.

Having said this, it can be scary if you leave your credentials on sites like Github. I work a lot with Python Flask framework and oen of the commonly used extension is Flask-Mail to send emails. Guess what ? A lot of developers are leaving their email credentials in the open and being a flask dev, I know that most of the time, it is MAIL_PASSWORD variable usually in a config file. Knowing this, I can just do a code search on github with keyword MAIL_PASSWORD. You figure out the rest.

<comment> vertex-four Even after deleting the file, you can still find it in git's history, it's just very slightly less easily accessible through github's web interface. The whole point of git is that nothing ever actually gets deleted.

You need to do a reset of any credentials that end up in public, ever.

</comment></comment><comment><USER3> Another reason to always always always setup AWS billing alerts: [https://aws.amazon.com/about-aws/whats- new/2012/05/10/announ...](https://aws.amazon.com/about-aws/whats- new/2012/05/10/announcing-aws-billing-alerts/)

This can POST to a URL, SMS you, email you etc. Set a $ threshold you are comfortable with and enable this right away.

<comment><AUTHOR> Absolutely, spot on. This is the best way to avoid this situation. Thanks, I will put this in the blog somewhere.

</comment></comment><comment><USER4> The best practice with AWS API keys is to ONLY EVER use IAM (Identity and Access Management). There is nowadays zero reason to even generate account- level API keys. With IAM, you can create separate keys with separate abilities, down to the API call, even locked down to certain IP addresses. Even on my personal account I have separate IAM "users", e.g. one for each S3 bucket that I use for backups, locked down to the minimum access needed for the backup software to work.

</comment><comment><USER5> I've heard the billing alerts elsewhere.

Seems like AWS did a great job of making things right in the end.</comment>


Ask HN: Should we file a trademark? - <AUTHOR> We're CodePen.  We've been operating for 3+ years.  A google search for our name yields 518k legit results.  We've always operated under the assumption that we're the de-facto owner of our name.  But, recently, someone used our icon which was included in a free icon set as the icon for their magazine.
We're looking into paying to trademark our company, but it seems kinda pricy and also seems to have little value.  In fact, [LegalZoom] [1] says "you are not required to register a trademark to achieve some level of protection".
Can anyone here explain to me what we'll really get from going through this $900 process?
[1]: https://www.legalzoom.com/knowledge/trademark/faq/benefits-registered-trademarks <comment><USER2> LegalZoom also talks about unregistered trademarks ([https://en.wikipedia.org/wiki/Unregistered_trademark](https://en.wikipedia.org/wiki/Unregistered_trademark)) and the comparison with registered trademarks at [http://info.legalzoom.com/registered-vs-unregistered- tradema...](http://info.legalzoom.com/registered-vs-unregistered- trademark-21089.html) and [http://info.legalzoom.com/report-use-unregistered- trademark-...](http://info.legalzoom.com/report-use-unregistered- trademark-22578.html) .

You first send a cease and desist letter.

> If the infringing party does not comply with your cease and desist letter, > you may protect your unregistered mark by filing a lawsuit for trademark > infringement in your state court. Your lawsuit will need to notify the court > how long you've been using the mark and how the other party is infringing on > your rights. Because an unregistered trademark is only granted protection > within a limited geographic area, any infringing use outside of this > geographic area will not be enforceable. A third party who files for federal > registration of your unregistered mark, even after you've been using it, may > be granted the right to use that mark in all geographic areas other than the > limited area where your common law rights exist.

</comment><comment><USER3> Yeah, getting your logo used in unexpected places is one of the major downsides of having your logo included in icon packs.

Before I changed it, one codebase I had inherited used the Pagelines (had never heard of this product before seeing it in the FontAwesome logos section) logo [1] as an icon on a webpage.

[1] [http://fontawesome.io/icon/pagelines/](http://fontawesome.io/icon/pagelines/)</comment>


Judging the Stupidity of GitHub Projects by Stars and Forks - <AUTHOR> http://ericgreer.info/github/funny/stupidity/2016/02/28/judging-the-stupidity-of-github-projects.html <comment><USER2> As opposed to judging the stupidity of blog posts by how facile their analyses are?

"I think this metric is much more accurate than you might first assume", and yet when looking at one of the "stupidest" projects, Jekyll Now, step number one in the README is literally "fork this project". And in this case, it makes _perfect_ sense, since the goal is to get a yourusername.github.io blog up. That wouldn't be possible if they _didn 't_ fork.

At a much more basic level, this article conflates stupidity with a) making custom alterations that are never propagated back to the original project, b) misguided enthusiasm for working on a project and c) inexperience with git and GitHub instead of stupidity, per se.

I suspect a, b, and c account for a huge fraction of the forks. I, myself, have forked projects I respected and wanted to contribute to, but never got around to. But since there's no penalty for unused forks, users have no incentive to clean up their project list.</comment>


Russian-Style Kleptocracy Is Infiltrating America - <AUTHOR> https://www.defenseone.com/ideas/2019/02/russian-style-kleptocracy-infiltrating-america/154749/?oref=d-dontmiss <comment><USER2> Despite the title, the article doesn't mention any American kleptocracy. Just the American financial system supporting foreign kleptocracy.

<comment><USER3> True and it's true the title is a clickbait overreach without direct evidence in hand, however it's still true that America's decline has been a mostly gradual one and the rich have captured politics and media to lower their own taxes and make regulations favorable to them. As it gets worse, privatization, including public-private partnerships as just the beginning, comes in and takes the valuable and vital parts of communities and society, and sell them off to semi-corporations to charge people for what their taxes already paid for. With time and worsening conditions, vampiric, cannibalistic strip-mining of parts of civilization needed to function ordinarily are sold off, destroyed or replaced with more expensive, substandard substitutes. Today, you're hard pressed to find a water fountain or apart from a library, find anywhere convenient for a public meeting that doesn't require commercial activity. Parks are fewer and farther (except maybe the mandatory public spaces in NYC, that are often in/on top of sterile buildings).

I don't want to sound like a sky-is-falling doomsdayist, but when/if it gets nearer to such a perceived fall of empire, there will likely be overt theft of public and government resources committed almost exclusively by the ruling class, as happend in the Soviet collapse.

Beware the era when the politicians in countries like Brazil or the US, who listen almost exclusively to their rich supporters, stop listening to average citizens and many people stop voting. The French Revolution was also itself a failure of empire due to extreme inequality, and the Yellow Vests are a modern, more mellow resurgence "relief valve" release of dissatisfaction that is by no means an isolated occurrence: Occupy, Brexit, Trump, etc. And as the world becomes "flatter," there will be more and more similar situations happening across countries, and far-right autocrats, rising nationalism, rising xenophobia and populist revolutions are currently some of the most widespread phenomena. Nationalism is especially concerning because it's a leading indicator of another global war.</comment></comment>


Kicking the Tires on Ruby 2.1 Preview - <AUTHOR> http://spin.atomicobject.com/2013/09/26/ruby-2-1-preview/

<comment><USER2> Refinements, why, matz, why?

In a large complex program with many dependencies, they are going to make debugging an nightmare, figuring out where the method you were calling is actually defined. And lead to weird hard to diagnose bugs where you call a method with a differnet definition than you expected.

And the use cases that justify refinements is entirely large complex programs with many dependencies, right? They're supposed to actually _reduce_ bugs and debugging challenges from monkeypatching... but nobody seems to actually think they do except matz.

Is _anyone_ who works on well-known large complex programs with many dependencies -- actually on record as supporting refinements, subsequent to the analyses that showed what a mess they'd become?

Why, matz, why?

<comment><USER3> My understanding is that refinements are more of a limitation of existing monkeypatching functionality though. Like before, if you needed to monkeypatch something, you had to re-define the method system-wide. This seems like it allows you to have the monkeypatch only apply in the modules that you need it to, and to define it with a special refine keyword that's easy to search for.

Then again, many of the major gems that I've worked with so far define methods in various dynamic ways, making it challenging to figure out what code it's actually running. Hello ActiveRecord?

<comment><USER4> I'll refer to Nutter on this one. Refinements appear to be a method caching nightmare.

[http://blog.headius.com/2012/11/refining- ruby.html](http://blog.headius.com/2012/11/refining-ruby.html)

<comment><USER5> Those concerns voiced with 2.0's refinements before release were why they were marked as experimental, and were the driving force behind the changes made to refinements between 2.0 and 2.1.

On the 2.1, non-experimental version, he has said: "What we're going to have as refinements in 2.1 is a paired down version that I think still provides the bulk of the functionality people wanted out of the feature without most of the pain that I was concerned about originally."

[http://rubyrogues.com/124-rr-jruby-with-charlie- nutter/](http://rubyrogues.com/124-rr-jruby-with-charlie-nutter/)

</comment></comment></comment></comment><comment><USER6> I'm interested in seeing how refinements actually affect things. Matz is so set on it but so many smarter people than me think it's a mistake.

<comment><USER7> +1 I wonder if anyone has a branch of what the "refined" activesupport would look like.

<comment><USER8> I still wonder why a lot of activesupport's monkey patches are not merged into ruby's stdlib proper. Sure some of it is quite rails specific but things like String#constantize is just so damn handy it should be in ruby stdlib.</comment></comment></comment>


Ask HN: Is invite only product allowed in Show HN? - <AUTHOR> I'm wondering because the rules says that sign up pages can't be tried out so they're not Show HN. Invite only can be tried out but only to a limited amount of people. In addition to that, we have a demo product in our site but being able to use it for your own is the invite only part. <comment><USER2> Interesting idea to provide a discussion platform that prevents trolling and toxic discussion. What makes you different than other platforms like Disqus? They claim to be working on this:

[https://blog.disqus.com/first-steps-to-curbing- toxicity](https://blog.disqus.com/first-steps-to-curbing-toxicity)

Looking forward to your response and hope the best for your product.

<comment><AUTHOR> Woah I'm surprised you can predict what I was hiding from this Ask HN post. That's the power of Google I guess haha.

Anyways, I'd prefer to answer that when I do a Show HN post so we wouldn't go out of context from the topic.

<comment><USER3> > "That's the power of Google I guess haha."

Helps when you put it in your profile.

<comment><AUTHOR> Ohh wow. I totally forgot about that. :P

</comment></comment></comment></comment><comment><USER4> Per [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html), no:

> If your work isn't ready for people to try out yet, please don't do a Show > HN. Once it's ready, come back and do it then.

</comment><comment><USER5> I did a Show HN when my product was in private beta, so I don't see why you couldn't. People post landing pages all the time, attempting to validate an idea.

</comment><comment><USER6> What are you "showing HN" if we can't actually try it?

I think it would be ok if you had that but provided a special link to HN that bypassed the invite system.</comment>


Ask HN: Please review our iPad App - Bento Master - <AUTHOR>

This app was my wife's idea and she did most of the design and all of the graphics and made the website as well. I just coded it ;). We recently released it and it got pretty high in the lifestyle category in Japan and made it into the "New and Noteworthy" section of the lifestyle categories in the US and Germany. We are thinking of various things to add to it (beyond more recipes) and would love your feedback on it. Please see our website for it here: www.bentomaster.com <comment><AUTHOR> clickable link: <http://www.bentomaster.com></comment>


A Reloadable Visa Debit For Your Bitcoins - <AUTHOR> http://coincashcard.com You can now purchase anything using bitcoins! <comment><USER2> From just looking at their website, it seems that they're going to run afoul of banking/money services regulations in nearly every country, if it is not shut down by VISA first.

1\. I don't know much about countries other than the US, but in the US you have to be at least 16 with an adult as the joint owner of the card to get a debit card.

2\. (Correct me if I'm wrong) I haven't seen a case where you can get a debit card without an ID. No withdrawal limits, no ID verification, and moving it through bitcoin seems like a very easy way to launder money.

<comment><USER3> VISA gift cards?

<comment><USER4> Those have all sorts of limits, basically anything above a few hundred euro a year and you are running afoul of EU AML laws, look at paypal for example to see what the limits are before you have to verify paypal accounts, its roughly the same for reloadable cards.

</comment></comment></comment><comment><USER5> I actually wrote to them to say:

"It is a really neat idea, but....

1\. 15% is usurious. I know you have approximately a 2.2-2.8% cost built in through Visa, and I don't mind paying a percent or so extra, but 15%?

2\. You provide no contact information of any meaning or any sense of who you are or where you are. You are handling money and ought to be willing to provide complete details of your company. This would allow your customers to do a basic due diligence."

</comment><comment><USER4> The site just screams "SCAAAAAAAAAAAAAAAAAM"

EDIT: contact just goes to email form to firstname.lastname@example.com

<comment><AUTHOR> The site was launched prematurely and has since been fixed!

</comment></comment><comment><USER6> I really want this to be true, but man, does this website look shady: typos everywhere, questionable copy, and the default Yeoman favicon, FAQ doesn't mention who's issuing...

<comment><AUTHOR> Sorry about the premature launch the website has since been fixed

</comment></comment><comment><USER7> Just an FYI to readers of this thread. Yes, the nature of bitcoin seems to tilt toward dismissing startup ideas like this as a scam, but I personally contacted the founder of the site, and I can say with confidence that this is a legitimate, although very early-stage service. I have funded my account, and verified through CoinCashCard's payment processor that the money is indeed on the card.

Proof: [http://i.imgur.com/2D3wn8L.png](http://i.imgur.com/2D3wn8L.png)

</comment><comment><USER8> While such a thing definitely appeals to me due to it's simplicity, my too- good-to-be-true detector immediately kicked in when I read that 1) it was a Visa card, 2) there were no age restrictions and 3) no address request. Those points were the most salient, but there was just an underlying current of suspiciousness. Normally, something that sounds this cool has a website full of caveats.

</comment><comment><USER9> Pretty sure this guy[0] is just gathering emails. I've been working on a credit card/Bitcoin project for 8 months now, and it is _insanely_ hard to get merchant accounts to work with you as a Bitcoin company.

[0] Domain registered by [http://www.gagebachik.com/](http://www.gagebachik.com/)

</comment><comment><USER10> 15%? This is insane. How is this not in breach of almost every financial regulation since the big bang?

</comment><comment><USER11> So many typos on their website...

<comment><AUTHOR> all of which should be fixed :]

</comment></comment><comment><USER12> No HTTPS. Go and die.

<comment><AUTHOR> There is now https sorry

<comment><USER7> I can actually still access the site without https.

<comment><USER7> Problem looks to be solved. Thanks for fixing.</comment></comment></comment></comment>


Nanoparticles loaded with bee venom kill HIV - <AUTHOR> http://news.wustl.edu/news/Pages/25061.aspx <comment><USER2> This submissions is a press release from a university press office. There is a well established science news cycle

<http://www.phdcomics.com/comics.php?f=1174>

in which a university press office will hype a preliminary research finding, and then credulous news organizations will amplify the hype. The incentive to do this is gaining external funding for research projects and looking good to prospective students or faculty candidates.

The preliminary finding mentioned in the press release submitted here will take a lot more clinical research before we can be sure that this is safe and effective for human use.

<http://norvig.com/experiment-design.html>

That's been the usual experience here on Hacker News--gee-whiz press releases about breakthroughs submitted a few years ago end up not having any actual clinical safety or effectiveness as the preliminary findings are followed up by clinical trials. It's great to continue research on means of killing viruses or errant cells in human tissues, but it will be a long while, if ever, before this is a first-line defense against AIDS or any other health risk.

</comment><comment><USER3> The article sort of breezes right by the sentence saying it can also work against tumor cells.

Also, at the end- "This work was supported by the Bill & Melinda Gates Foundation Grand Challenges Explorations"

</comment><comment><USER4> The basic mechanics of this just read awesomely. Viruses generally "attack" cells by having protein sheathes with molecular "hooks" that latch onto cell wall receptors to disrupt the membrane and deliver the viral payload into the inner workings of the cell.

This technique uses a similar mechanism (molecular latching structures) that are scaled and aligned to fit into the viruses outer sheathes themselves, then disrupt the virus structure between host cells (DNA/RNA doesn't last long without protection). It's like fighting viruses with virus-like binding mechanisms, except the attack vector isn't self replicating.

</comment><comment><USER5> Full article is available here: [http://www.intmedpress.com/journals/avt/abstract.cfm?id=2346...](http://www.intmedpress.com/journals/avt/abstract.cfm?id=2346&pid=31)

Abstract is free, full text is £17.50.

</comment><comment><USER6> So this is not intended as a cure, and can not function that way.

Rather it's for use as a protective to prevent someone getting infected.

And it might have value as a treatment (but I'm guessing it will be too toxic inside blood).

<comment><USER7> _Hood also sees potential for using nanoparticles with melittin as therapy for existing HIV infections, especially those that are drug-resistant. The nanoparticles could be injected intravenously and, in theory, would be able to clear HIV from the blood stream._

<comment><USER8> But the reservoir for HIV infection, the thing that makes clearing HIV particles from the blood insufficient to cure it, is the CD4 T-cell. So just clearing the blood of HIV will not be curative.

<comment><USER9> I don't have much biology experience, but if you can keep the blood stream clear of HIV, wouldn't that prevent new T-cells from getting infected, allowing the count of healthy T-cells to start growing as the body makes new ones?

<comment><USER8> Yes. That's the basis for HAART, the current mainstay of HIV treatment. It's a good treatment, but not a cure.

</comment></comment></comment></comment></comment><comment><USER10> This is pretty cool. I can't find Dr. Hood's paper on scholar.google.com yet so its hard to know exactly what is going on, but the mechanism sounds plausible.

</comment><comment><USER11> Is this legit? I have no idea what to make of it.

<comment><USER12> There are tons of things that would kill HIV - strong acid, fire, lasers, but it doesn't mean it's good for the rest of the body.

<comment><USER13> True, but bee venom wouldn't be harmful to anyone now would it? :P

</comment></comment></comment><comment><USER14> I am curious, would nano particles filled with salt or any other substance also do the same thing? I mean if you can get close enough to the virus, you could kill it anyway you like.

</comment><comment><USER15> Nanoparticle safety still unknown: [http://news.discovery.com/tech/biotechnology/nanotechnology-...](http://news.discovery.com/tech/biotechnology/nanotechnology- safety-120829.htm)

I know that is a generic article, but is it safe or not? Is it worth the chance to put it in lube as mentioned?

</comment><comment><USER16> Condoms are already an effective preventative for sexual transmission of HIV. Will a person who's not using condoms be any more likely to use a "vaginal gel" ?

<comment><USER17> Yes, women who may not have control over condom use.

</comment></comment><comment><USER18> the HIV-AIDS hypothesis is a hoax instigated by a cancer fraud. See Duesberg.com for details.

<comment><USER19> Buncha articles on Duesberg's bullcrap science.

[http://www.sciencemag.org/site/feature/data/cohen/cohen.xhtm...](http://www.sciencemag.org/site/feature/data/cohen/cohen.xhtml)

</comment></comment><comment><USER20> Yeah and so does chlorine bleach.

</comment><comment><USER21> These two things do not sound great together:

 _Nanoparticles carrying a toxin found in bee venom_

 _developing a vaginal gel_

I'm just sayin'...

</comment><comment><USER20> HIV will just mutate so the particle can't bind to it anymore and stops working.

The real solution is better immune system design.

<comment><USER22> Doubt it. As I understand it, the outer envelope is a fairly important functional part of HIV - it needs to be very similar to normal human cells or the immune system will destroy the virus.</comment></comment>


Defying Experts, Rogue Code Lurks in World's Computers  - <AUTHOR> http://www.nytimes.com/2009/08/27/technology/27compute.html <comment><USER2> _It's using the best current practices and state of the art to communicate and to protect itself_

While I was impressed with the overall design of Conficker, I was genuinely surprised to see that it seemingly used HTTP 1.0 and not HTTP 1.1 for updating itself.

To me that would seem to severely limit the amount of usable hosts it can use to retrieve updates.</comment>


Quotes - <AUTHOR> http://www.paulgraham.com/quo.html <comment><USER2> So what I want to know is who the heck is Tara Ploughman?

Google finds lots of hits, but they're all quotes (and mostly referring to pg's page of quotes). I think maybe pg made up this clever character.

<comment><AUTHOR> Has anyone ever seen Tara Ploughman and Nick B in the same room?</comment></comment>


Digg vs Stackoverflow server capacity - <AUTHOR> http://twitter.com/spolsky/status/27244766467 <comment><AUTHOR> Flame war cometh? The feedback to Joel was based on PHP being so inefficient but I think that could not explain half of it. I think technically it is a combination of the fact that PHP is slow and asp.net mvc with sql is much faster/more efficient (when done right) than people can imagine. Those factors might explain 20% of it but I think the most important factor is the fact that Jeff Atwood and team are wickedly good programmers who have grown the site not under the auspices of grow as fast as we can but rather they have been methodical about their choices. Jeff wrote recently about going 'that way fast and if something gets in your way, turn' and while that is probably true in a macro sense - they are just in a different league. I truly believe that a great hacker can produce 10x the average lackey and there is probably an imbalance over at Digg in this factor.</comment>


Show HN: Arvados, a free software storage and compute platform for big data - <AUTHOR> https://github.com/curoverse/arvados <comment><AUTHOR> Hello all, Arvados developer here to answer your questions.

<comment><USER2> How does Arvados differ from other big data tools?

It looks to be focused mainly on bio-informatics, do you see other use cases where it's features provide more leverage than general purpose tools?

<comment><AUTHOR> There's several features that make Arvados unique.

* The content addressed storage system references hashes all data so you can unambiguously reference an immutable data set, similar to git but capable of handling huge invidual files (hundreds of gigabytes) and scaling to petabytes.

* Every compute job is recorded in a database with hashes identifying the inputs, Docker image, and outputs, so re-running past jobs is easy.

* Designed to federate multiple instances, to support both "hybrid cloud" setups within an organization, and allowing different organizations to share data.

These are all features that are particularly important to the bioinformatics community, but solve problems that are common to lots of informatics big data problems.

<comment><USER2> So would it be correct to say there's an emphasis on immutability and idempotency and a capability for heterogenatity across cloud computing platforms?

<comment><AUTHOR> Yes, that's right. I would also add data provenance, eg where did a data set come from and how it was computed. This flows directly from the features I mentioned of content addressed storage and recording compute job history.</comment></comment></comment></comment></comment>