1. 18
  1. 11

    At risk of writing complete flamebait, I think this is because web developers as an overall demographic have the attention span of a squirrel on crack in a tumble dryer full of walnuts. It’s CADT again (or maybe still), but instead of writing terrible client software I can (mostly) ignore, they’re writing server software that I’ll almost certainly have to interact with and very likely have to fix at some point in my career; and the moment it threatens to teeter under its own accumulated cruftiness, instead of stepping back to fix anything, they run to build something else with the exact same problems, or a whole new set of problems, or some exciting combination of both.

    I can’t help but feel that some of this would be solved if software development were far more expensive. Some large proportion of the developers behind the constantly exploding array of web frameworks are paid by somebody to do what they do, and their employers are clearly not cost-sensitive enough to insist that the things they’re paying for work.

    1. 5

      The 30-minute claim came because the software only officially supports being installed via Docker,

      This is a problem which I don’t know what to do about. I haven’t been bitten by it too bad, but I suspect it will just get worse. Unlike VMs, the pain and overhead is low enough that it’s a viable mechanism for many people to distribute and run other software.

      Unix lied to you

      This whole section is nicely solved in FreeBSD and Solaris via jails and zones respectively, which have existed for a decade or so at production quality. You get your own system! It’s awesome. You can do container-like things with them, but you can also get a whole system, and it’s secure. Since each one gets its own network stack you don’t have to worry about binding to port 80 or anything, assuming you can give each an IP address.

      1. 8

        Docker is a new flavor of an older problem. If there’s two ways to do something, somebody will pick the way that uses a monstrous practically unportable dependency.

      2. 5

        Can’t help but read this and be reminded of simple vs easy and worse is better.

        This is what happens when we choose easy/worse over and over and over again. Endless layers of cruft/ceremony for what should be something fairly simple.

        1. 3

          But we haven’t even tried to solve this, and all the people who are most capable of solving it are too busy scaling Twitter or Amazon up to ten million servers or whatever.

          I was thinking about that before eevee got around to saying it. One of the first things we did to get rails under control at Twitter was fix all the management stuff (just kill it every few hours and make sure it restarts), add metrics and monitoring that’s actionable instead of whining, and… just really basic stuff. But the way we did it would be arduous at less than 100 or so nodes, so it’s completely useless for individual sites.

          I think that’s a big part of the problem: Nobody is working on making the smaller cases work, because they’re being paid to bucket-brigade the leaky mess on a much larger scale, and the solutions are different for smaller cases. A message board that runs completely on one node is the kind of project that’s probably only going to be written by someone in their spare time.

          1. 4

            I’d say the only proper solution is DebObs/FedOps/CentOps: http://enricozini.org/2014/debian/debops/

            This problem was solved many years ago…

            [fkooman@noname ~]$ sudo dnf -y install discourse
            Last metadata expiration check performed 2:16:04 ago on Sat Sep 19 09:04:20 2015.
            No package discourse available.
            Error: Unable to find a match.
            [fkooman@noname ~]$ 

            This tells you everything you need to know about the maturity of discourse :)