Within the Linux community, the primary X11 implementation has been the XFree86 server, which forked into XOrg over licensing disputes, which forked into XLibre over the development roadmap.

Other implementations include XQuartz (also based on XOrg) and Xlibe (not a traditional server but implements X11 by translating into native Haiku graphics API calls). There's also Xming and android-xserver (written in Java!), among many others.

XOrg may be abandoned. That doesn't mean the entire ecosystem is.

However, the code is a mess, with deliberately cryptic identifiers (e.g., `w_doto` for `cursorOffset`), redundant functions (e.g., `vtputc()` is a strict subset of the behavior of `vtpute()`) and a bunch of other weird choices (e.g., deeply-baked assumptions that one byte == one char == one column, even thought Big5 and ShiftJIS were already a thing when it was written).

I tried adding UTF-8 support to mg a couple years ago and basically gave up.

I'll probably be an atto convert.

Except that isn't true.

There are basically two kinds of undefined behavior.

The first is undefinable behavior, the kind that easily goes disastrously wrong, like writing to random memory locations.

The second is incidentally undefined behavior, something where there just isn't enough implementation consensus for the standard to settle on it, like realloc(p, 0).

There's no standard terminology I'm aware of to distinguish the two. But the distinction exists.

And where programmers read deliberate instances of UB, it's usually the latter, e.g., writing directly to an address memory mapped to device I/O in that particular environment.

Building a basic X11 window manager is almost a one shot prompt.

Modifying a UI toolkit to make it work with MSAA/IA2 is simply not possible.

There's a lot of room for deep work left... for now.

The reasoning the article takes to reach its incorrect conclusion is plainly erroneous. For example, it reasons that "Northern latitudes have later onset of winter sunrise and higher prevalence of SAD, with the latter increasing by 0.2% per 1° increase in latitude," ignoring that northern latitudes also have less sunlight overall.

I am not interested in whatever you've got going on right now. Being dishonest about others' positions is bizarre. Refusing to clarify your own is bizarre. Let me know when you're willing to engage in good faith.

What possible meaning could the phrase "noon happens at noon" have? That's tautological and meaningless.

And if your solution requires a wholly independent, newly built mass coordination mechanism rather than just a minor tweak to the existing one, then I think the burden you bear for arguing your position is extremely high.

Even this article, while stating the opposite conclusion, directly scientifically supports permanent daylight time as beneficial for most people.

It points out sunrise being at 0751 versus 0851 for Toronto. That's the anticipated sunrise time on 1 January 2027. The anticipated sunset time is 1651.

That means that someone working in a cubicle for a standard 0800-1700 schedule will get 9 minutes of possible daylight under winter time, versus 51 minutes under daylight time (sunrise 0851, sunset 1751).

Lack of sunlight leads to terrible circadian rhythms. There is absolutely zero scientific support for the proposition that nine minutes of daylight is healthier for our circadian rhythms than fifty-one minutes of daylight. No person could possibly argue such a thing in good faith.

(Also, I have a terminology quibble with "Standard Time," since Daylight Time is the actual standard, and we observe it eight months of the year.)

This is nonsensical. What are you even trying to say here? MFC isn't available on macOS or GTK.

> Just look at Unicode. It’s an unholy mess.

This seems utterly unrelated to the issue under discussion.

> Qt does what it does, even if the approach is not the same (arguably superior), there’s also Tk. There’s also libui and IUP.

None of those allow a single codebase to compile on Windows, Mac, and Linux, and get native UI elements on each.

secure - adjective

se· cure si-ˈkyu̇r -ˈkyər

securer; securest

1

a: free from danger

b: affording safety (a secure hideaway)

c: TRUSTWORTHY, DEPENDABLE (a secure foundation)

d: free from risk of loss

Passkeys as a sole/required method of authentication increase the risk of permanent loss. In any other configuration they do not mitigate phishing risk.

It is not possible to say there is nothing insecure about them.