1. 2

    I grabbed one of the cheap / sketchy monoprice 27" 2560x1440 monitors on black friday, and I must say, having all those pixels is an amazing upgrade from 1920x1200. I bet there’s a point of diminishing returns somewhere, but merely being able to put two typical desktop webpages next to each other on one screen is wonderful. I haven’t done much coding at home recently, but even just for wasting time on your favorite link aggregator site, moar pixels really does seem to be better.

    1. 7

      If you have 17 million lines of code in one repo you’ve made at least one horrible mistake. Big tech companies like to shoot themselves in the foot all the time and then brag about how good their surgeons are.

      1. 5

        Big tech companies like to shoot themselves in the foot all the time and then brag about how good their surgeons are.

        This perfectly describes the whole software industry.

        1. 4

          At the risk of sounding pedantic: why? What is wrong about keeping all of your code in a single repository?

          1. 5

            As a current Google employee, I second this question. We get lots of benefits from keeping everything together, and I can’t really imagine not doing this in a large, server oriented organization. Well, I can, but I much prefer this approach.

            For a public citation, “We have a single large depot with almost all of Google’s projects on it. This aids agile development and is much loved by our users, since it allows almost anyone to easily view almost any code, allows projects to share code, and allows engineers to move freely from project to project. Documentation and data is stored on the server as well as code.” http://research.google.com/pubs/pub39983.html

            1. 3

              You can view code in other repos very easily (via github, gitweb, etc), you share code by packaging libraries as libraries and specifying them in the dependency system for your environment (pip, rubygems, apt, w/e), and being able to switch projects is determined by your company’s coding standards, which is orthogonal.

              1. 3

                Yep, there’s certainly multiple valid ways to organize things.

                We avoid libraries and prefer to build everything from head, which one giant repository helps make possible, though I’m sure that tradeoff isn’t right for everyone. There’s some info about our build system at http://google-engtools.blogspot.com/2011/08/build-in-cloud-how-build-system-works.html, and I’d expect Facebook does something similar (especially since the config format of their open sourced Buck build tool is very similar to the format of the example BUILD file).

                1. 1

                  Submodules or the equivalent in another system would also help.

              2. 2

                Short answer: having everything in the same repo encourages coupling, having each service in a different repo makes you be explicit about dependencies.

                1. 5

                  These constraints can be enforced in other ways. For example, Chromium uses modules with explicit dependencies, and lower modules aren’t allowed to depend on higher modules: http://www.chromium.org/developers/how-tos/getting-around-the-chrome-source-code. While using different repos is one way to help maintain separation, it’s not the only way. Having the code together helps keep dependencies in sync and eases refactors that cross module boundaries, while module separation can still be enforced at a higher layer.

                  1. 1

                    I’m not claiming that it’s impossible to have everything in the same repo, just that the drawbacks of doing so are clear and the benefits are dubious in my opinion.

                    1. 2

                      That’s fair. Some of the benefit could also be cultural as opposed to technical, encouraging the mindset of being “Facebook” instead of “<some component>”.

                      DVCSs that require the full history are especially problematic to scale to huge repositories, which is why Facebook’s use of mercurial here is especially interesting. Though I can certainly see where the comment about shooting themselves in the foot and bragging about patching it up is coming from :)

                  2. 2

                    Isn’t tight coupling a bad thing?

                    At a past company there was a single monolithic codebase and multiple daily deployments. When there was a problem during deployment they had to roll back and re-deploy after kicking out the bad patch. This process would waste a lot of people’s time and limited us to two, maybe three daily deployments.

                    To combat this, the company moved toward SOA and newer products were deployed decoupled as services. This allow teams to push as often as they liked with much higher iterations. Running a full test suite on the old code base took an hour, while services' test suites took minutes or less.

                  3. 1

                    At the 17 million line level you probably have several distinct products that are bundled together in one repository.

                    1. 1

                      I worked at a company that built embedded Linux systems; many of the products we supported were years old. All of these systems needed to stay in sync with certain core components, but there were slight modifications to the build for each (for supported features, chipsets, kernel customisations, etc). In this case, a single repo worked well.

                    2. 2

                      Despite the many apparent advantages of multiple repos, and the lack of obvious advantages to having one repo, every large software company tends towards the mega repo. When multiple organizations develop the same solution to a problem that doesn’t exist, that suggests to me that the problem does exist, I just can’t see it.

                    1. 3

                      This looks like a reasonable quick rating of SSL clients. If you’d like to test an SSL server, the canonical tool is Qualys SSL Labs https://www.ssllabs.com/.

                      Since it looks like this is targeted at non-browser clients, it’s worth nothing that this won’t test the most common SSL mistake: not validating server certificates. Many HTTPS libraries won’t validate certificates by default for compatibility / since maintaining lists of CAs is hard, making it trivial to man-in-the-middle such applications.

                      The examples from this 2012 paper “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software” are a great read: https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

                      And by great, I mean terrifying.