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.
> 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 don't think there is. You should set both and limit doesn't need to match request for CPU.
Your limit should roughly be "what should this application use if it goes full bore" and your request should be "what does this use at steady state".
At least at my company, the cluster barely uses any CPU even during the busiest hours. We are fairly over provisioned there because a lot of devs are keeping limit and request the same.
CPU bursting is safe you just get throttled. Memory bursting is dangerous you get OOMKilled.
That's why Python numbers look so bad here devs set the request high enough to cover that initial model loading spike so they don't crash during a rollout, even if they idle at 10% usage afterwards.
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.
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).
Either it would generate a more robust (and likely more recognizable) solution, or it would fail to converge, really.
You may need to train on a smaller number of FPGAs and gradually increase the set. Genetic algorithms have been finicky to get right, and you might find that more devices would massively increase the iteration count
No need - it's detectable as Trojan:MacOS/Amos by VirusTotal, just Google the description. Spoiler: it's a stealer. Here [0] is a writeup
> AMOS is designed for broad data theft, capable of stealing credentials, browser data, cryptocurrency wallets, Telegram chats, VPN profiles, keychain items, Apple Notes, and files from common folders.
Got anything better? :D Something that may be worth getting macOS for!
Edit: I have some ideas to make this one better, for example, or to make a new one from scratch. I really want to see how mine would fare against security researchers (or anyone interested). Any ideas where to start? I would like to give them a binary to analyze and figure out what it does. :D I have a couple of friends who are bounty hunters and work in opsec, but I wonder if there is a place (e.g. IRC or Matrix channel) for like-minded, curious individuals. :)
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.
Almost any developer familiar with HTML would be willing to write HTML if they were paid similarly to making something flashy in React (to use your example)
Because I don't believe this is a real issue in the marketplace, I will write HTML for your client if they are truly unable to find someone. Writing HTML would be the easiest paid job I could imagine in my field right now.
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.
All of these things you've described are actions taken by someone that has not had a deep think about their code and organization, architecture and patterns. It reeks of inexperience, and/or pressure to get shit done without needing any time/deep thinking on how best to do it.
While the teaching is partially to blame, i say it is more that most people are sloppy and undisciplined thinkers. When they dont have any incentive to produce disciplined code, they wont.
`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.
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.
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.
> Forests sequester carbon through forest fires producing charcoal
Forgive me if I misunderstand, but the carbon in the charcoal resulting from forest fires isn't sequestered any more than the same carbon in the forest when in its un-burned state. The only difference is that, once you have a forest fire, a lot of the carbon is also just released into the atmosphere as CO2 in smoke.
It does sometimes in forests that burn. And generally, forests keep building up soil, it's disturbances and things like erosion (sometimes worsened by fires) that counter this buildup. But mature forests tend to do a lot better at resisting erosion and catastrophic (erosion-causing) fires.
Forests do not infinitely accumulate soil. When we dig into the ground in a mature forest, the layer with organic remnants is not particularly thick. Dead organic decomposes and returns back above the ground.
Show me the megatons/year of charcoal being produced by the worlds forests eh?
We could process them yes, but we can also just make them into timber - or burn them for energy. Or just bury them somewhere under a bunch of clay. Oh, and now we’re back to this thread.
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.
There is zero chance this makes a difference at the scales required. That is my point. Or are you proposing somehow making billions of tons of lumber into charcoal a year, and stopping it from further decay?
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.
Sounds like you might want to actually read the thread? Unless there is a geological process involved (very rare, and obvious when there is), long term forests and wetlands are carbon neutral - or they would be sitting on massive quantities of carbon. The vast majority are clearly not.
reply