For example, it is common in sorting algorithms to do an n² algorithm like bubble sort when the list to sort is small (e.g. <50), whereas when it's larger, we do an n log n algorithm like merge sort.
The issue is that merge sort does recursion, which comes with some extra cost, so that an n² algorithm beats an n log n algorithm, provided n is small.
You can (and probably should) add a threshold to recursive algorithms like mergesort so that they don't end up doing recursive calls on very small arrays.
For arrays smaller than the threshold, insertion is faster than bubble sort. And if you really don't want recursion for large arrays to begin with, you have heapsort or Shell sort.
I don't think there is any practical case where using bubble sort makes sense, except "efficiency doesn't matter for my use case and this is the code I already have".
As in one of volumes of Knuth's The Art of Computing, Heap sort is in place and achieves the Gleason bound so can be regarded as not beaten by quick sort.
>However, there's still communities build around stuff like MMORPGs, FOSS, etc
Both are luxury communities though. I mean, the example MMORPGs as a community, it has nothing to do with the community experience of poorer people "people helping each other to get by" mentioned
Oh, you were quite unclear. Also wrong in saying you need systemd with podman to orchestrate multiple containers without root.
>It is, just to be clear, red hat's recommended way to orchestrate podman containers despite having this nasty dependency analogous to the one docker has on a root service.
It's not "red hat's recommended way to orchestrate podman containers" in general. It's "red hat's recommended way to orchestrate containers on top of systemd", that its whole point.
Nothing nasty about it either, you'd already be running systemd on your redhat system (and many non red-hat ones).
>what else would you like to bundle in the init process? docker compose as well?
You can complain that you don't liken systemd's design or that it does too much (very overplayed complaint, but ok).
But that's an orthogonal point to the initial complaint you've made that it's somehow bad that this requires systemd to run.
That complain is moot, since you'd be running systemd anyway, with or without those containers. And it's double moot, because you can run > 1 containers (with podman) without root too.
(It's also wrong that systemd was added container compose capabilities - podman is what translates things to systemd "speak")
>You can complain that you don't liken systemd's design or that it does too much (very overplayed complaint, but ok).
It's not at all orthogonal. Making the "default" way to run > 1 containers together require the init process is fucking stupid.
Similar to how requiring ROOT to run containers was a stupid design decision made by docker.
This decision to make quadlets the "default podman orchestrator" and to double down on it relegates podman from being "a better docker" to just "docker just with different design mistakes".
>That complain is moot, since you'd be running systemd anyway
false. systemd is not the only pid 1 in existence (much as it likes to pretend it is). when you run a container inside a container there also isn't a systemd.
>And it's double moot, because you can run > 1 containers (with podman) without root too.
except there is NO good orchestration system for doing that. podman compose is a steaming pile of shit. quadlets requires systemd which requires root. docker compose requires a root service. you can run podman compose inside a container but not quadlets.
might as well just use docker at this rate.
>That complain is moot
Your comment comprehensively missed my point 3 times. It's triple moot. It would have been better left unmade.
>Also why does their website have to look so damn ugly?
Because it was made by coders. Old school coders. Backend coders.
>I know that's not what really matters for a git server, but I just can't take such a project seriously. "Who knows what else they didn't really care about?" in the back of my head...
Yes, a nice looking website, that epitome of project maturity and quality /s
(as if there's a shortage of barely working vaporware FOSS projects with great looking websites, because their creators are more into the whole hussle culture / fancy launch page / web design than coding)
I had a CTO that would insist he had to pick every single dependency himself personally. And he mostly decided depending on how much he liked the CSS on the website.
That's how we got to use a payment provider that had absolutely no documentation and was located on the other side of the world, so queries to their support team would take 24h.
We never managed to actually get any money via that provider.
At various points various researchers/entrepreneurs/influencers will say this, based on what "eternal life"/"life extension" solution/research/product they're selling. Then they somehow still die in a normal distribution age, as if programmed. I'd rather they'd lead with the results, not the sales pitch.
>- "identification of conceptual equivalencies among disparate phenomena were foundational to developing previous laws of nature" - what exactly is a "conceptual equivalence"? You mean models?
No, a model is not an "identification of conceptual equivalencies among disparate phenomena". It's a simplified representation of a system.
"identification of conceptual equivalencies among disparate phenomena were foundational to developing previous laws of nature" could be called an analogy, an isomorphism, a unifying framework, etc.
>Unifying disparate observations into models is basic science. Not sure why it is highlighted here as some important insight.
Perhaps because the most important insights are the most basic ones - it's upon those eveything else sits upon.
>At this point, I gave up
If you can't bother beyond the abstract or 1st paragraph, or are perplexed that the abstract has a 10,000ft simplistic introduction into the basics, then it's better that you did :)
>much of Monty Python wasn't recognized at the time as a classic
Monty Python was a huge success in its day - which is why it spawed multiple seasons, movies, comedy albums, books, and of course multiple careers (for all involved, even the mere non-speaking ...cartoonist), and even live shows. And that's just in the 70s and early 80s.
Its funs where younger demographics. Mainstream reviewers of the time were notoriously out of touch. Hardly anybody more square than Ebert (at least he did gave it 3/4).
This mentality is how we ended up with cpu and memory hogging Electron apps...
reply