In the meantime, I'll advocate for evolving Markdown, specifically GFM.
I do use a custom keyboard layout, but that doesn't have to interoperate with anything/anyone.
Edit: I have a similar unpopular opinion: we should use functional languages and immutable datastructures. At least we some data of movement in that direction with the patterns being adopted by other languages and codebases.
This is demonstrating the difference that still exists between free software and open source. People who use GPL/AGPL want it to be shared and spread vs others using source as means to an end other than more/better software. There is still a problem with AI/LLMs though that basically de-GPL such licensed source.
> (Relativity isn't a problem here, though it is a tempting distraction. All of humanity's current computing systems share a close enough frame of reference to make relativistic differences in the perception of time immaterial).
GPS clocks take special and general relativity into account. I'm no expert, just something I thought I'd read.
I'd never heard of the FLP result before and it seems mostly a theoretical concern with distributed systems which do have time bounds etc so it doesn't apply (unlike CAP which always does).
Edit: I like the details that are presented, but not the way it's done. If organized as reference material could be more useful for this volume of info. As long as we're digging in the weeds, I'd like to hear about how there is no absolute/universal "same time" for spatially separated events.
I think there’s a small misunderstanding, though: while systems like GPS do account for relativistic effects at the clock level (and even with extremely precise atomic clocks and practical synchronization via NTP), this doesn’t mean we have a universal or perfectly shared notion of “the same time” across distributed nodes — especially once you consider network delays, clock drift, and faulty or unreachable nodes
In physics there is no absolute global time for spatially separated events, and in distributed systems this shows up as unavoidable uncertainty in synchronization.
Also, the FLP result isn’t about relativity or physical clocks at all — it’s a theoretical result about the impossibility of guaranteed consensus in fully asynchronous systems with failures.
So even with very accurate clocks and practical time bounds, distributed algorithms still have to explicitly deal with uncertainty and partial synchrony rather than assuming perfect global time.
Having both modes could be good. Default allows pre-noodling and enabled gives satisfaction of being correct one-shot (or falls back to retry with noodle).
The problem with Apple's execution of Liquid Glass is that the intended audience isn't the iOS user, it's the onlooker watching the iOS user (FOMO). That was an effective strategy when iPhone popularity was growing rapidly. Now that we're in a plateau of market saturation (post-peak Apple), anything directed at the onlooker which detracts for the actual user will hurt their bottom line.
How would this work? The only place I've ever heard of liquid glass is from iPhone users complaining about it incessantly and tutorials on how to turn it off or diminish it. What would I fear missing out on?
Interesting read. I had the Abit BP6 and it was a killer in performance/price. The problem I had with it wasn't the capacitors but rather that the PCB itself was a bit thin to support 2x CPUs/fans.
Another cool thing was that the BP6 supported Ultra DMA/66 (aka ATA/66) and it did so by adding a second controller so you had twice as many buses. Looking a pic of it now, it really was a Franken-machine with AGP, PCI, ISA busses too.
In the meantime, I'll advocate for evolving Markdown, specifically GFM.
I do use a custom keyboard layout, but that doesn't have to interoperate with anything/anyone.
Edit: I have a similar unpopular opinion: we should use functional languages and immutable datastructures. At least we some data of movement in that direction with the patterns being adopted by other languages and codebases.
reply