My #1 complaint by far is that it --- pretty much silently --- depends on systemd to work correctly.
Try having a docker-compose with a service that waits until a dependency is healthy --- in a host that has no systemd (such as Alpine Linux).
The service will never start because Podman relies on systemd (and only systemd) to do the periodic healthchecks which it needs to do in order to handle such dependencies.
And of course, this fact isn't adequately documented anywhere. And Red Hat says they'll never, ever drop this dependency.
---
But I don't know if there are any tools compatible with the Docker ecosystem other than Podman. I'd love to find one.
You can't rip it, or even make backups in the US (you can in most, if not all, of Europe; dunno about the rest of the world). It's illegal, and constitutes piracy.
I like the D approach where arrays are just `struct { size_t length; T* ptr; }` internally --- and strings are just arrays of `immutable(char)`.
It has a big advantage over the Pascal approach in that you can do zero-copy slicing, since the length is separate from the actual data.
And `size_t` makes perfect sense for the length here. If your strings are longer than the address space (which `size_t` technically isn't, but is practically very strongly correlated to it), then you're going to have a problem regardless of the number of bits for the length anyway.
I very commonly see fixed-point libs be slower than floating-point (assuming floating-point hardware is available --- soft-float is slow as hell compared to fixed-point, of course).
Commonly enough that I think it's some fundamental reason (given available/current hardware as opposed to hypothetical).
Two reasons I can think of, though granted, they only apply in certain niches:
1) Floating-point SIMD extensions are far more common than integer ones. This means you can compute N (often N=4 or 8) float operations in one instruction, vs 1 integer operation.
2) For any GPGPU processing: GPUs far prefer floats, to the point where you didn't even use to have integers available (somewhat ironically, the platforms that prefer float much more strongly to int are mobile/embedded ones nowadays --- which is the exact opposite of the CPU situation). To this day, you have a `mul24` intrinsic for integer multiplication in some languages ... which converts two integers to floats, multiplies them as floats, and then converts back to integers. Yes, that was faster than direct multiplication. I'm sure many GPUs do it directly nowadays though.
It's also worth considering that a typical fixed-point multiply (as opposed to integer) is an integer multiply followed by a shift; often to a 2×-bit intermediate, if you want to preserve precision. That's a cost.
Look into things like lithium mining (for batteries; yes, I am aware that other options exist, but lithium is still a very common one). That one is straight up nasty.
The cookie consent dialogs were never required in this form.
That was literally just malicious compliance in order to get people mad at the law instead of the companies (at least at first, there's also a huge amount of cargo-culting nowadays). Congrats, you've been psy-opped.
I'd say it's also a great strategy for throwaway prototypes (which I'd count as a kind of learning anyway: learning about your future product, its requirements, obstacles, etc).
The problem/trap in that case is, a lot of throwaway code ends up not being thrown away in the end, up to and including the prototype becoming the product (even if it was never meant to be).
I actually find that it blows Google Maps out of the water for cycling (which is why/how I discovered it). I haven't really used it for driving much because my own car has a builtin nav, so can't really comment on that.
Try having a docker-compose with a service that waits until a dependency is healthy --- in a host that has no systemd (such as Alpine Linux).
The service will never start because Podman relies on systemd (and only systemd) to do the periodic healthchecks which it needs to do in order to handle such dependencies.
And of course, this fact isn't adequately documented anywhere. And Red Hat says they'll never, ever drop this dependency.
---
But I don't know if there are any tools compatible with the Docker ecosystem other than Podman. I'd love to find one.