Anyway, I've been using Radiance to help me deal with the above issues, but it's for all practical purposes non-interactive. At some point there's bound to be a e.g. Monte-Carlo physically-based ray-tracer for these use cases, featuring radiometry with visually negligible error compared to reference (i.e. if you were looking at the real thing with your eyeballs), that is _interactive_-capable (at least in the frames-per-second category and not seconds-per-frame). It's probably already out there, but people have different preferences as to the tools they wish to employ. I like Radiance because it's text mode and gives you a lot of quality for all the text editing and tool composition (which frankly is a bit weird, Greg Ward was sure a maverick!), but mileage varies there.

When you have a carpenter visiting you don't announce they can go into your kids' rooms (for reasons unrelated to the job is) and what not -- the [default] contract is they're there to do a job and their privileges go only as far as the job requires, they normally also ask you first time where your toilet is, although we all agree they can use it. It's a contract, formally and less so, and things work when the contract is abided by. The carpenter also can't say they had the right to the cookie jar on your kitchen counter just because they were working there.

By not implementing such a contract with code, Microsoft has shown negligence. And they have had _decades_, so it's likely a "business decision".

Another problem with looking good is that it's a) subjective (since it has no real or objective reference point, really) and b) it quickly goes stale once something else looks "better". Just look at Doom. It looked good in 1993, everyone would agree on that. It's not realistic, never was realistic and will certainly never be realistic unless you take a particular cocktail of drugs, I guess.

First, I agree commits shouldn't store broken snapshots -- if that's what you mean -- code that doesn't compile or outright is _known_ (as opposed to omissions that weren't caught otherwise and made it into the commit) to be broken, not run, produce runtime/type-checking errors, miss dependencies/assets etc. Not everyone would agree -- in our shop people routinely commit "stuff" for reasons they don't disclose that also remain unexplained to me (not having any explanations my way), and then more stuff on top of that. At some point they tag one of these commits as "v2.0.0" triggering automation that releases a package, often broken. Then they scramble for "v2.0.1" etc. I find all of it tedious and unnecessary -- my best practices would rather be to run automation that does checking and sufficient filtering for "bullshit code" as early as possible -- at the "pre-commit" stage, so only whatever passes through that ends up being committed in the first place. If it yet runs into regressions or other problems in production, I fix (re-triggering all the checking again) and release a strictly patch version -- unless fixing was impossible without breaking compatibility in which case it may be a minor or even a major version bump. I do tag commits, too, obviously. But in principle every commit is "production", the difference is not every commit makes up a _release_ (implying to the general public / intended audience).

Regarding rebasing -- that depends on what you mean exactly -- there's different ways to rebase -- you can squash, auto-squash and/or apply fix-ups, or you can just transplant stuff -- when you say "you should rebase" and "patch on current master", what do you mean? Github-driven projects often don't permit pushing `master` without a PR, so a rebase upfront would have been necessary if the author for some reason is not on a branch [other than `master`].

"Actual merging" -- do you mean merge commits as opposed to fast-forward merging which doesn't produce an additional commit? If the latter, what does "merge from history" mean, again? You just need to produce a working snapshot, expressing it with a commit with N parents, there's no more to it. It's fixing of the merge conflict that requires you to understand the graph, the resulting commit is just the period at the end of a long sentence, so to speak.

Anyway, I really missed the point you were trying to express with your first paragraph, I am sorry. Do elaborate, please.

Bisecting also _benefits_ from non-linear "actual development" graphs -- apart from commits that don't feature broken code committed haphazardly for "reasons" (some people use Git as backup, that I know for a fact) -- since they don't hide the work (one of the reasons I prefer raw graphs over squash-merged "polished" stuff).

One thing I should mention in any case is that I do find slicing work into atomic commits often very tedious and counter to what Git is supposed to sell (distributed friction-free concurrent versioning). Because my brain doesn't always work in terms of concepts aligned with Git's -- I routinely may start with one feature fix, on some branch, then discover N related issues, fix those because they're in front of my face then and there, end up with an unreadable diff I can't cleanly add in chunks, etc. None of that is facilitated by Git in any more capacity than just being a scalpel. I don't always want to cut down a tree with a scalpel, obviously.

Pijul, an alternative VCS, uses this nice patch theory guaranteeing you can "apply" commits in any order, compositing your changes essentially -- a feature is just some baseline that is added N commits (in any order, like the mathematical `+` operator). That way you don't have to rebase anything because parenthood doesn't break merging -- if you fix a bug with a patch in Pijul, you can store it once and count on it being applicable to any snapshot made later, even if the result isn't visible -- unlike with Git where rebasing some old commit will abort and ask you to fix a conflict because Git cannot continue.

See what I did there?

Indeed, Vulkan is the step in the right direction because it largely follows the path I was outlining, but it's still got ways to go because it assumes things and mixes in abstractions of its own, but more importantly because through its mere existence and the way how it is positioned it occupies space where nothing else has room to exist. Point being that Vulkan still requires you to play by someone else's rules of how they thought the API should work, which is detrimental in principle to "exokernels". So this is about exokernels, not about going full retard and programming a 100 billion transistor GPU on your own to draw pixels.

In case I wasn't able to elaborate: Vulkan looks like the part, it's certainly a sign of the people who started with the likes of DirectX have learned about the dead-end model they thought would work and are now finally seeing the "light", and I am arguing that whatever abstracts the GPU should just pretend it's a generic massively parallel computation unit with addressable memory of multiple kinds and places and so on -- without assuming it's for "graphics" (which it is less about today than ever before, what with AI etc).

Point being that branches aren't something to avoid, implying that complicated graphs are not to be avoided either, but embraced and knowing how Git works it's not a problem at all (unless your "bush" is accidentally complex in a bad way) -- except that if noone bothers to learn Git, it _becomes_ a problem, solved at the cost of the value that Git provides -- branching (not just ephemeral branching for your local convenience). Exacerbated by Github since everyone pulls from there -- meaning that production-grade code is not a true graph but a linked list, on average.

The tragedy, if you ask me at least, is rather that they then start imposing the "keep it simple" culture onto everyone else, which frankly turns Git into what SVN and CVS were accomplishing before it, with all the drawbacks of those. This keeps 90% of the team satisfied 90% of the time because there's nothing wrong with strictly linear graphs and the pro's that are asked to produce these, can always squash-merge their intricate local development history before they push to Github (which some Git users also think is part of Git proper).

Something about using Git in the aforementioned way just bugs me strongly. I admit it's a me problem, very likely, but lately I've also had to admit that it's not just that either.

For instance, if I need to fix a bug I use `git blame` to find the commit where I have learned the bug originated. I do a `git checkout -b ... ` to start working on a fix, creating a branch starting at the problematic commit. Already that is head and shoulders above what many people I work with do or know _what_ does (or why would one want to do that).

I do it because it creates a _trail_, certainly more so than just committing on top of `master`, even with a good commit message.

But my practice doesn't produce linear graphs, even as pushed to Github (which we have to use, for better and for worse) and shared with everyone. I then get people coming to me and complaining they can't merge and it becomes obvious they don't understand Git sufficiently to do anything else but `git reset --hard` or worse, `rm -rf * && git pull` and hope for the best.

Not sure where I was going with this, something about why use Git when it's the new SVN with everything SVN had and none of what SVN didn't have...

What am I getting at?

Well, if you take the "no graphics API" to its logical conclusion, then we should strive to remove everything that is "graphics" from it altogether. Reading the article linked and the article the former links in turn ("No Graphics API"), there's still an ungodly mix of graphics rendering _specifics_ and I think these too will start rotting "sooner rather than later".

Having grown up on matrix operations and optimisations that often venture into territory where they _lose_ resemblance to outright _graphics_ pipeline they originally modeled, I am of the firm opinion the logical conclusion I am advocating for, is a sensible one.

To explain with an analogy -- I think we should adopt the "exokernel" approach to GPU hardware. That means just exposes the hardware constructs without trying to fit these into any form of a common denominator (between AMD, NVidia and Intel), and have software specific to each glossing over the abstractions.

Before you say "well, that's exactly what DirectX, Metal and even Vulkan, did!", the key difference is not the encapsulation itself, but its form, the "how" of it.

An exokernel, for instance, does not expose or provide a memory manager (referring to use of MMUs), or give you a `malloc`. It simply exposes the paging mechanism, and you take it from there. If you need a high-level API and/or cannot be bothered to page things in your little command line application -- a fair concern -- you rely on middleware, aka "libOS" in the original, MIT's terminology, a library by any other name -- to provide `malloc` so you don't have to cry over the bare-bones exokernel.

The point I am making is that as the exokernel software (and libraries that would complement it) just exposes the GPU hardware, there is more flexibility to how to use it without "cramming round shapes into square holes" -- a bane of graphics programming _and_ especially optimisation there, that has plagued the entire field since 3dfx' days. Library authors can wrangle API design without touching the hardware or working _around_ it, while hardware vendors can tune subsequent chips to generic computing -- it's the way it's going anyway, except that they won't have to coordinate closely with software writers -- the dependency will go strictly one way -- from library to "GPU exokernel" authors to hardware manufacturers, and never the other way around (ideally). Every link in the chain has more flexibility then.

Practically, we're talking about a generic massively parallel processing unit with tons of addressable memory of different latency (system RAM, on-board RAM, on-chip RAM / L0-level stuff) exposed with a zero-cost abstraction layer known as an "exokernel". DirectX / Vulkan etc compatibility implemented strictly in software over the "exokernel". Those who want their retained mode or whatever else that doesn't require them to deal with cache thrashing issues, can use that, while those who like to holistically optimise and/or Unity / Unreal Engine developers proper, can use the exokernel by writing libraries for it, or outright affect the exokernel itself as new hardware is put on the market.

Sorry for the wall of text. This is from someone who started with implementing solid-painted triangle and polygon rasterisation, then Phong and Gourad shading using an Intel 386...

P.S. This isn't AI slop (although you're obviously free to feel it reads like one), I just like to use the em-dash.

P.S. When we invent the time machine, we should go back to load up on actual GUS _and_ spread the word for people to never install it horisontally :-)

> Social people will be fine

Thing is, "social" is not only a scale, it's not even a line for scale. It's this multidimensional space of different social preferences and different preferences as to _how_ to socialise, not to mention with whom and for what reason. In short, it's much more complicated than as to permit a "binary" division into the "social" and "other" people, but even if you did, I would wager the division puts it at 50% for either group, meaning you're basically describing a cataclysmic event where 50% of the population suddenly has no access to a fundamental trait of humanity that in known and unknown ways has assured our feeling of happiness and warded off a plethora of conditions of misery and worse that psychology has no names for (and won't ever have names for because that's like classifying different gradations of drinkable water, I imagine).

But yeah, humanity has always had to evolve, it's just that these changes come too fast for our adaptability to adapt to, I believe.

Anyway, good memories, even in the tragedy. I can relate to people who resurrect GUS.

Since others mention similar failings of their card, I remember I too had it installed horisontally in a (Chinese/Taiwanese) mini-tower, it definitely wasn't a desktop chassis, much less an IBM PC. I guess gravity strained it to a breaking point.

Our devices have now increased the distance _between_ us -- it's not about _you_ being able to "do X" -- talking to others is not _you_ doing it, it's you _and the other person_ doing it _together_. You can't be doing anything together consentually when the other person is in the habit of talking with their AI, or doomscrolling for that matter.

> True however those who control the HTML spec are unlikely to let it go.

Like I said in another comment, I believe XHTML was axed because it stepped on _someone_'s toes. I suspect it had to do with W3C being understaffed and criticised for being too slow at the time -- by most of the industry, and most of it deservingly -- and WHATWG (with Google co-authoring their standards) stepping in as the authority on all things Web, and somewhere between the two XHTML was used as the proverbial fall guy. Speculation, of course -- but a lot of good, useful work was thrown out the window with XHTML. Not the first time it happens, of course, but this was the Web we're talking about, not Adobe's product portfolio.

I've heard the "streaming" argument before, by the way -- it keeps being mentioned (probably because it was one of the official reasons for the transition to HTML 5), but I think it's a "ruse" -- nothing about XHTML in practice prohibits an agent from progressively rendering an XHTML document, and if something really did, in W3C's writing for instance, then all they needed to do is relax that requirement because again -- there's plenty of hierarchical data formats with strict rules that by their very nature don't preclude parsing (or semantic analysis / rendering) done in streaming fashion.

There's a bit of irony with the fact that HTML 4 which _did_ have browser "correct" errors (albeit in non-standardised manner) _was_ what motivated XML in the first place -- it's just that in light of the wildly different correction behaviour between Netscape Navigator, Internet Explorer, etc, they decided on a pragmatic solution -- abort and tell author, like a C/C++ compiler. The latter can also correct syntax errors, strictly speaking -- but you'd be hard pressed to find a programmer that would seriously consider letting the compiler do that. Why HTML should be different?

Say you forgot a `