The Gitlab microservices run Gitlab; the Harbor microservice runs Harbor. ntfy and Nextcloud are their own services, and coredns serves DNS to the network. The MySQL backup processes are for small apps I host for myself and for a friend's bar.
1,005 karma · joined March 31, 2020
For most people, myself included, this doesn't matter at all.
For people looking for an extremely "pure" original experience, this is the closest you can get to original hardware - which is getting both more expensive and lower quality with time.
For the competitive speedrunning scene, incorrect emulation speed is a non-starter in some categories, and dropped inputs are a huge problem when they happen.
The other side of the coin is that solo work - e.g. slinging code - is a lot easier to get done at home with fewer distractions.
All that said, if my choice is between the extremes of mandatory RTA and full-time WFH, I pick full-time WFH ten times out of ten.
* Immutability by default, including a warning for unnecessary mutability
* Usable documentation even when the library author wrote none
* Extremely low-friction testing, including fuzzing
To name a few.
Racing to get an HTTP service that starts but doesn't do anything you want it to do correctly isn't really useful; in my experience, that's the only advantage e.g. Python, Go, etc really give you over Rust.
That depends on your goals. I like to catch a buzz once in a while but the majority of the time I'm drinking is because I really love the flavor of my favorite cocktails and the quality would be very poor as mocktails.
Using a Mai Tai as an example, of I could get a couple 0ABV rums, I could sub clarified orange juice for the orange liqueur and probably have something pretty good with no booze in it. I'd be quite happy with that.
For sure - it's a little terse, just to demonstrate the various cases
async fn do_something_async() {
nonblocking_sync_call();
tokio::task::spawn_blocking(blocking_sync_call()).await;
async_std::task::spawn_blocking(blocking_sync_call()).await;
async_call().await;
}
fn do_something_sync() {
nonblocking_sync_call();
blocking_sync_call();
futures::executor::block_on(async_call());
}
If you want to know more about any of that, happy to explain or provide links for further reading
You don't see that much these days, though, as having your highest gear that short is just leaving fuel economy on the table on the highway. If you can pick up speed going uphill without changing down at least one gear, you're wasting fuel to pumping losses on flats/downhill.
* Switching from libc malloc to jemalloc
* Switching from libc malloc to tcmalloc (dating myself a little bit)
* Switching from libc malloc to mimalloc
* Switching from jemalloc to mimalloc
* Switching from jemalloc to libc malloc
* Switching from mimalloc to jemalloc
Heap fragmentation is just a reality of some allocation patterns without a GC runtime.
One certainly can (and, in some cases, should) make their application more allocator-friendly, but - aside from some often-low-hanging fruit - this is a time-intensive process involving a bit of, for lack of a better word, arcane knowledge (I should inline all my fields and allocate on the stack as much as possible, right? Yes, well, except ...)
If you already have a halfway decent benchmark suite or workload generator, which you'll want for other purposes anyway, it's often a lot quicker to just try a few other allocators and select the one that handles your workload best.
let res = iterator.iter().map(|x| x.foo()).collect::<Result<Vec<_>, _>>()?;Extracting more power is, most commonly, a matter of burning more fuel, which requires more oxygen. This increases combustion chamber pressure, which drives the piston down with more force; that force is converted to rotational torque and ultimately drives the wheels harder, pushing the vehicle forward faster.
More oxygen can be added in any number of ways; less restrictive intake/exhaust parts, larger valves, cams that are more optimized for whatever load/engine speed you want to produce peak power (or are more optimized for output than, say, economy or emissions), supercharger, turbocharger.
Adding fuel is more straightforward: A higher capacity pump and/or bigger injectors/carbs.
You can also switch to pistons that will compress the air/fuel charge more. This also increases combustion chamber pressure.
You can also run the engine at a higher speed, which will often warrant different cams, stronger valve springs, etc. May also require bottom end uprated components that can handle that task (connecting rods, pistons, bearings, crankshaft).
On the subject of bottom end components, depending on how much you increase cylinder pressure, you may need to upgrade those.
You can also increase output power by reducing losses - a lighter flywheel is a common example with enthusiasts.
Every single one of these involves a trade-off. A lighter flywheel impacts drivability; removing intake/exhaust restrictions and adding forced induction components will both make more noise; etc.
Anecdotally speaking I've seen them in Pennsylvania and Maryland, but super uncommonly.
This drives me absolutely insane. When we were shopping for a TV for the living room a few years ago I wanted a 120Hz display. Finding one was a pain in the ass because all anybody wanted to list in marketing material was the backlight strobe rate; you had to dig and dig to find the panel rate.
No, I don't care that you can flash the backlight at a thousand Hz, I want an actual panel that's well synchronized with 24FPS content, and I don't want to spend hours of research to figure out which displays have one.
It's even better when all those data structures are just dicts, because it's too cumbersome to make serializable classes, so good luck figuring out what fields are in which.
But I didn't get any audio. That's weird. Until she drove away and the music started playing through my phone's speaker a few seconds later, and I realized that it connected to the wrong head unit.