For all practical matters it is xterm that has become the standard.
Like with web browsers, it is irrelevant what the standard states. The only thing that matters is that it displays correctly with the most popular / authoritative browser.
Web pages are increasingly bulky. A 3 MB page will take 1 second to load at 25 Mbps, so latency is often not the primary bottleneck.
Part of the problem may be that companies who own network infrastructure, and get paid for data usage, are also the ones that are the largest content providers.
This also comes with an electricity cost. We regulate efficiency for refrigerators, it might be time to add some sane limits to the largest content providers, which will also improve connectivity for those stuck with 2 Mbps.
Even if it's a thing, the idea that a teacher should take on the role of psychologists and figure out a child's optimal learning style should be preposterous to anyone with common sense.
It might work in combination with a software suite, with e-readers getting cheaper and more capable, and easily lasting through a school day, it's an option.
I suspect it has the same problem as ncurses: Not easy to learn, get proficient with, or rapidly produce something decent with.
I've been working on a project for a while that allows running any console program within it, and use text, keyboard, or mouse triggers to add a VT100 TUI, but it's uncomfortable to learn, very hard to get proficient with, and while it's possible to rapidly produce something decent, you're going to hit a hard wall producing something excellent.
There's likely a market for office workers since there's a significant reduction of stress on the eyes.
You'd save about 0.5 kwh a day in electricity, more if the AC is running. So I could see them becoming popular once the price comes down. People who run 2 monitors might be interested as well.
There's also the ability to notice strange/curious/discordant things, and either connect the dots through trying semi-random things, as well as sudden insights which seem to be partially subconscious.
One of my (many) theories is that I have the ability to use long-term memory in a quasi-similar manner to short-term memory for problem solving. My IQ is in the 120-130 range, I suffer from hypervigilance, so it's generally on the lower end due to lack of sleep.
I'd say there's a strong creative aspect. If I could redo life I might try my hand at music.
As you can see, quadsort 1.1.4.1 used 2 instead of 4 writes in the bi-directional parity merges. This was in June 2021, and would have compiled as branchless with clang, but as branched with gcc.
When I added a compile time check to use ternary operations for clang I was not adapting your work. I was well aware that clang compiled ternary operations as branchless, but I wasn't aware that rust did as well. I added the compile time check to use ternary operations for a fair performance comparison against glidesort.
As for ipnsort's small sort, it is very similar to quadsort's small sort, which uses stable sorting networks, instead of unstable sorting networks. From my perspective it's not exactly novel. I didn't go for unstable sorting networks in crumsort to increase code reuse, and to not reduce adaptivity.
"pick a few fixed sizes and handle the rest by rounding down then a few steps of insertion sorting."
I'm late to the party, but this sounds a lot like quadsort's small array handling:
Sort 4, 8, or 16 elements using unrolled parity merges, and handle the rest with insertion sorting.
An unrolled parity merge can be viewed as a stable sorting network. I never added unstable sorting networks to crumsort due to wanting to keep the code size low, and perhaps the mistaken idea that it would reduce adaptivity, as crumsort is likely to scramble partially sorted input.
It is said that getting ripped off is the highest form of flattery.
The FOSDEM talk indeed addressed my worries.
I actually don't see the ping-pong merge as a personal accomplishment, it's not that novel a concept, at best I popularized it. The actual performance gain from it is minimal, maybe 1%, though that is perhaps the most interesting thing, that data moves are practically free. And I would like to take full credit for that observation!! :-)
I've been most impressed with ChatGPT's ability to analyze source code.
It may be able to tell you what a compiled binary does, find flaws in source code, etc. Of course it would be quite idiotic in many respects.
It also appears ChatGPT is trainable, but it is a bit like a gullible child, and has no real sense of perspective.
I also see utility as a search engine, or alternative to Wikipedia, where you could debate with ChatGPT if you disagree with something to have it make improvements.
As I wrote previously, thank you for fully addressing all my concerns in your recent FOSDEM presentation.
While it would have been outside the scope of the presentation, and time being short, quadsort does present an interesting alternative to handling the merge length problem powsort tries to solve.
I've honestly been unable to detect any notable instruction-level parallelism on my own hardware. I suspect there may not be any? It'll be interesting to get to the bottom of this.
As for quadsort, it does contain a guarded bidirectional merge. I published it after you started working on glidesort however. It was always on my todo list, but I do get tired of programming from time to time.
As for unguarded parity merges, it was indeed one of my brighter moments when I came up with that.
Anyways, once again, thanks for addressing my concerns in the FOSDEM presentation, and if it wasn't clear, I think you did some really excellent work on glidesort.
I've just watched your FOSDEM presentation and to put it simply, thank you for addressing all the issues I had.
I felt pretty uneasy about what I perceived as a situation where you could end up taking full credit for innovations I was first to develop and publish. I do realize this could be all in my head. Anyways, I'm at ease now and I hope my assertions didn't create any ill will between us.
As for your arguments, they're pretty sound and I find no reason to doubt you. It was never my intention to appear dismissive towards your work, writing glidesort was no easy matter and the merge routines are a significant improvement upon Timsort/Powersort.
Like with web browsers, it is irrelevant what the standard states. The only thing that matters is that it displays correctly with the most popular / authoritative browser.