That's too reductive. Vacuum full isn't just slow, it exclusively locks the table for the duration of the vacuum and is basically a no-go when the database is in use.
And make sure your `random_page_cost` is about 1.1 if running on an SSD or if >~98% of your hot pages fit in memory. Rather than 4 by default which makes the planner afraid of using indexes.
Two things - the word "idles" and the nature of CPython's allocator which generally doesn't return memory to the OS but reuses it internally. So you cannot really "spike" memory usage, only grow it.
> Python: ~60% waste (Mostly sized for startup spikes, then idles empty).
I understand we're talking about CPU in case of Python and memory for Java and Go. While anxious overprovisioning of memory is understandable, doing the same for CPU probably means lack of understanding of the difference between CPU limits and CPU requests.
Since I've been out of DevOps for a few years, is there ever a reason not to give each container the ability to spike up to 100% of 1 core? Scheduling of mass container startup should be a solved problem by now.
I wonder what would happen if someone evolved a circuit on a large number of FPGAs from different batches. Each of the FPGAs would receive the same input in each iteration but the output function would be biased to expose the worst-behaving units (maybe the bias should be raised biased in later iterations when most units behave well).
Sorry not to have made this clear: I am not a frontend developer. I'm a backend/infra developer who's forced to work on a React app abandoned by a frontend developer who incorporated their own wrappers-of-wrappers-of-wrappers.
Meanwhile the client is telling me is virtually impossible to find frontend devs willing to write HTML.
Good riddance indeed. The last 30 years of software teaching basically trained developers to produce complexity for its own sake, while calling it engineering. I'm not sufficiently full of myself to link to my own writing (yet) but I'm full of myself enough to self-paraphrase:
1. Programmer A creates a class because they need to do create an entry point, a callback, an interface... basically anything since everything requires a class. Result: we have an class.
2. Programmer B sees a class and carelessly adds instance variables, turning the whole thing mutable. Result: we have an imperative ball of mud.
3. Another programmer adds implementation inheritance for code reuse (because instance variables made factoring out common code into a function impossible without refactoring to turn instance variables from step 2 into arguments). Result: we have an imperative ball of mud and a nightmare of arbitrary dynamic dispatch.
At some point reference cycles arise and grandchild objects hold references to their grandparents in order to produce... some flat dictionary later sent over the wire.
4. As more work is done over that bit of code, the situation only worsens. Refactoring is costly and tedious, so it doesn’t happen. Misery continues until code is removed, typically because it tends to accumulate inefficiencies around itself, forcing a rewrite.
The parent comment I'm responding to is literally:
> A forest or wetland is a carbon sink only in the growth phase. In a long-term equilibrium, it's carbon-neutral, like biofuels.
To which I'm stating that forests and wetlands are not carbon-neutral but carbon-negative.
Then you miss the parent comment's context and start in an inflammatory way:
> Bwahaha, this is so ridiculous.
And take it somewhere else (move the goalpost) - from whether forests are carbon neutral or not to how effective charcoal creation is at carbon capture, in our human timescale.
Meanwhile the only practical point wrt. charcoal creation from forests was:
> Humans could actually cut down old trees, dry them, and convert them to charcoal later used for soil enrichment.
Which doesn't propose an effective carbon capture solution. At most it's something like emission reduction - the key phrase is old trees. And soil enrichment.
Recommendation: don't argue against points people didn't make.
The root of good faith conversation is that we don't latch on fuzzy meanings of words like "comparison" but try to understand which precise meaning should apply.
The result of subtraction is a difference. In my mind this is the most basic way to compare things. Subtraction of differing units is illegal.
The result of division is a quotient (day to day we say ratio). Division of different units is legal but not always practical.
`kg of fuel per metre` is division, not comparison. You can divide different units by each other. It isn't guaranteed to always make sense but it's very useful.
It's as ridiculous as the comparison of the most recent 12k years of the holocene to the age of plant life on the Earth.
As for using lumber for timber, when eventually disposed it would have to be turned into charcoal rather than burned for energy or let decompose in conditions that don't sequester carbon.
You also missed the point about using charcoal for soil enrichment.
The world is more complicated than a 17th century lab experiment in combustion.
Forests sequester carbon through forest fires producing charcoal. Humans could actually cut down old trees, dry them, and convert them to charcoal later used for soil enrichment.
Wetlands capture carbon by incorporating wood from dead trees in anoxic conditions.
> When plant productivity exceeds decomposition, net soil carbon accumulation occurs. This process eventually leads to the formation of deep peat deposits, which can accumulate for thousands of years.
I'll go further and elsewhere at once: APIs should not present nested objects but normalised data. It enables clients to easily to lay out their display structure independently of API resource schemas and eases out tricks like diffing between subsequent responses, pulling updates or requesting new data by passing IDs and timestamps of already known data, etc. API normalised data obviously shouldn't correspond to DB normalised data. Nested objects are superior only for use with jq.
Sadly, the minorities (in the Anglosphere at least) don't deliver at either "think" or "independently". Their counterculture is as countercultural as joining a church. Just another way to fit in. Be be slightly different and they'll chastise you - a high-profile example of this mechanism has just happened again https://archive.is/qeDfU. Unless that's what it's always been.
Hooligan-like countercultures are also excluded as far as "think" or "independently" goes for an obvious reason.
Thus, the only independent thinkers I've encountered are individuals who don't aim to have all the answers, who can accept disagreements, who attempt to know themselves - but those are individuals, not countercultures.
I'm erring on saying that countercultures were never about independent thinking. They were about fitting in with different people.