l1ambda's comments

"Ontario now recommending against Moderna vaccine for men 18-24 years old...This comes after public health officials determined there is a 1 in 5,000 risk of myocarditis — a form of heart inflammation — following a second dose of the Moderna vaccine."

There is a concept in economics called spontaneous order. Once the cost of congestion becomes apparent through the price mechanism, then society can reconfigure itself to adapt to it. You just have to have the price mechanism in place to signal it. People will figure it out and adapt once you have implemented congestion pricing. Practically every medium size or larger city in America has terrible traffic congestion problems.

Importantly, you have to resist the temptation to set a price ceiling (like Houston did at $8), as it will not work effectively because it will not allow the price mechanism to work and will cause a shortage of road capacity and you end up with no material change and basically a bad tax. (E.g., the true cost of congestion spurs demand for apartments and transit options near the city center, which in turn reduces traffic congestion.) Also important that it is purely congestion pricing and not resulting in crony government. Changes in laws and zoning and public transit will occur subsequently.

I am excited for NYC to pilot this and hope it becomes a success for that city.

There is a concept in economics called spontaneous order. Once the cost of congestion becomes apparent through the price mechanism, then society can reconfigure itself to adapt to it. But you have to have the price mechanism first. People will say, what about this, what about that. It doesn't matter. People will figure it out and adapt, but you need to implement congestion pricing right now, because practically every medium size or larger city in America has terrible traffic congestion problems. Importantly, you cannot set a price ceiling (like Houston did at $8), as it will not work effectively because it will not allow the price mechanism to work and will cause a shortage of road capacity and you end up with no material change.

Changes in laws and zoning and public transit will occur. Given a little bit of time, the emergence of various kinds of social order from a combination of self-interested individuals will occur.

Education is free (MIT has free courses, and there are lots of opportunities nowadays for self-study); it's a degree that's expensive.

Furthermore, if one uses modules (as one should), one can arbitrarily and somewhat trivially run those modules either in-process (compiled in) or out-of-process (via REST, gRPC, Cap’n Proto, or another RPC system), e.g., in a separate service/microservice/whatever you want to call it. This gives you a best of both worlds approach where code can be arbitrarily run in a monolith or a separate service as-needed. This changes the thought dynamics from a rigid "monolith vs. microservice" decision to a more fluid process where things can be rather easily changed on a whim. When modularity is the goal, then services become something of a secondary concern.

Microservices are used as something of a sledgehammer to force modularity and performance in languages that lack proper modularity and/or are innately slow or otherwise inefficient, while suffering orchestration costs and the performance penalties of copying data across multiple processes and networks as well as making it harder to derive a single-source of truth in some cases.

Probably a good approach for a typical webappp looking to improve performance would be to first port core logic to a modern, fast, compiled language with modules, then evaluate the performance from there, and then determine if any modules should be split out into separate processes or services.

Like NoSQL, microservices can be (but not always are) a case of the cure being worse than the disease; however, they can also be useful in certain situations or architectures. Like anything in engineering, there are tradeoffs and it depends on your situation.

The blog post https://www.techempower.com/blog/ puts it better than I:

> I argue that if you raise the framework's performance ceiling, application developers get the headroom—which is a type of luxury—to develop their application more freely (rapidly, brute-force, carefully, carelessly, or somewhere in between). In large part, they can defer the mental burden of worrying about performance, and in some cases can defer that concern forever. Developers on slower platforms often have so thoroughly internalized the limitations of their platform that they don't even recognize the resulting pathologies: Slow platforms yield premature architectural complexity as the weapons of “high-scale” such as message queues, caches, job queues, worker clusters, and beyond are introduced at load levels that simply should not warrant the complexity.

The Software Freedom Conservancy argues that not only is zfs.ko a derived work of Linux, but really any dynamically loaded Linux kernel module is a derived work (of Linux). To me that feels like a bit of a stretch, and one could make the opposite argument.

By virtue of the fact that zfs.ko is an optional module, rather than an integral part of Linux, it's not a derived work. ZFS.ko MUST be a separate entity from Linux in the first place; SINCE zfs.ko is a module, it MUST be logically discrete, while interacting with Linux through the standard, normal kernel interfaces. Further, it's likely that only if ZFS were distributed as a changeset against the Linux source code (rather than buildable as a distinct module) would it possibly be a derived work of Linux.

The statically vs. dynamically compiled (linking) distinction doesn't hold water as it is an arbitrary technical one that only has to do with how things are layed out on the filesytem and/or loaded into memory, since modules, plugins, add-ons, and similar things almost often can be either statically compiled in or dynamically loaded, of which there are many examples of in many existing software.

The basis of the incompatibility claim seems to be from 3 arguments:

1) Statements from the FSF website, but those have no legal bearing against the actual text of the licenses

2) Claims that the CDDL was engineered to be incompatible with the GPL, again, it's an interesting hypothesis but has little bearing against the actual text of the licenses

3) Derivative Work argument from the GPL. This seems to be the only one that could hold water; however, I doubt that a court would find ZFS to be derivative work of the Linux kernel.

Furthermore, even if you argue that the "derviative work" clause makes them incompatible, there’s no way actually to prosecute such a violation. Copyright law is something called a tort in law, which means you have to show that someone violated the rules AND also caused quantifiable harm. What would our theory of harm be? (https://blog.hansenpartnership.com/are-gplv2-and-cddl-incomp...)

In other words, you end up with traffic congestion and tolls, the worst of both worlds.

I read a similar thing about Houston where it's capped at $8 and has little effect on reducing congestion. The first course of action should be to remove the price cap. (And expand the number of paid lanes, which would decrease the cost paid by drivers by spreading it out over more lanes.)

You can't have your cake and expect it to eat it too by imposing usage pricing with price caps.

Economics 101: price ceilings cause shortages.