We are also concerned primarily with human activity systems. One individual alone can rarely affect a situation that they are part of, in ways that bring about improvements. This is partly because of the unpredictable way in which human activity systems function, which cannot be anticipated, and partly because bringing about such improvements often requires collaboration or negotiation among individuals – interactions of a particular kind.

I've worked with people at companies where this was their only responsibility. Setting up emails for clients, making sure they pass a battery of tests and look great in all browsers and clients. It's an incredible PITA and it's not a set it and forget it thing. Clients can change month to month; spam filters change, etc...

There’s typically a complex tree of dependencies, where packages all tend to rely on each other in order to function.

Instead of having this confusing maze of lambdas, regexes, and strings, we could, in theory, introduce a single entry point of configuration for Sprockets to use, and in that file declare all assets we wanted to compile. Well, that’s exactly what the manifest.js file is.

Beware, though: What you are about to see is not particularly elegant. In fact, the TTY subsystem — while quite functional from a user's point of view — is a twisty little mess of special cases. To understand how this came to be, we have to go back in time.

I managed to remove it myself this morning...apparently it used to get it's hooks in so deep it was very difficult to remove the daemon as it interconnected with ubuntu-desktop for....reasons.

Dll hell was caused by multiple apps on the same device requiring different versions of dependencies. As dlls were shared that couldn't be resolved. Giving each app it's own versions of its dependencies is a way of avoiding dll hell. I'm not saying this a good thing but it avoids that specific problem.

The worst thing about snap is that it runs contrary to the concept of shared libraries that are easy to upgrade. Each snap package includes the dependencies for the app, which means you may have multiple (vulnerable) versions of a library installed. It's DLL hell all over again from a security perspective.

The upside to snaps is they make installations simpler because they avoid the heartache of dependency hell. This is what occurs when a new application can’t run either because a required resource isn’t available, it’s the wrong version, or its installation overwrites files required by existing applications so they can’t run.

Snap gets rid of dependency mess. Good. Snap offers in one place FOSS and proprietary app’s. Here I am suspicious. It may be an advantage for a commercial app-store and for some users. But this advantage may lead to loss of comfort and flexibility for the many users that rely first on FOSS.

perhaps, imo this would make more sense. but it would slow down Parcel significantly as packages who don't have a browserslist or something similar will all get compiled (and most packages actually do target commonjs, which makes this prob not such a good idea). Which unfortunately is way too many packages. It would be great if tools like babel actually enforced a similar pattern to Parcel and use browserlist file or package.json instead of allowing defining target env in babel. Or at least not encourage it.

I freely admit that this is a mess of post

There is little order of one sort where things are in process of construction; there is a certain disorder in any busy workshop; there is not silence; persons are not engaged in maintaining certain fixed physical postures; their arms are not folded; they are not holding their books thus and so. They are doing a variety of things, and there is the confusion, the bustle, that results from activity. But out of occupation, out of doing things that are to produce results, and out of doing these in a social and coöperative way, there is born a discipline of its own kind and type.

What you get is a mess.