mkozlows

Nobody pushed you to use git when you were comfortable with svn? Nobody pushed you to use Docker when you were comfortable running bare metal? Nobody pushed you to write unit tests when you were comfortable not? Nobody pushed you to use CSS for layout when you were happy using tables?

Some of those are before your time, but: The only time you don't get pushed to use new technologies is when a) nothing is changing and the industry is stagnant, or b) you're ahead of the curve and already exploring the new technology on your own.

Otherwise, everyone always gets pushed into using the new thing when it's good.

There are no reputable studies that show EVs having anything like the harms of legacy cars. The worst you can get is that if you're on a carbon-intensive grid, a Hummer EV might be as bad as a compact gas car.

And as for JAXB, it was released in 2003, well into XML's decadent period. The original Java APIs for XML parsing were SAX and DOM, both of which are tag and document oriented.

No. That use case was grafted onto it later. You can look at the original 1998 XML 1.0 spec first edition to see what people were saying at the time: https://www.w3.org/TR/1998/REC-xml-19980210#sec-origin-goals

Here's the bullet point from that verbatim:

  The design goals for XML are:

    XML shall be straightforwardly usable over the Internet.
    XML shall support a wide variety of applications.
    XML shall be compatible with SGML.
    It shall be easy to write programs which process XML documents.
    The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
    XML documents should be human-legible and reasonably clear.
    The XML design should be prepared quickly.
    The design of XML shall be formal and concise.
    XML documents shall be easy to create.
    Terseness in XML markup is of minimal importance.

Or heck, even more concisely from the abstract: "The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. XML has been designed for ease of implementation and for interoperability with both SGML and HTML."

It's always talking about documents. It was a way to serve up marked-up documents that didn't depend on using the specific HTML tag vocabulary. Everything else happened to it later, and was a bad idea.

I mean, welcome to literally every tech startup valuation 2021 vs now. 2021 was so amazing for stock valuations.

The part where it favorably mentioned namespaces also blew my mind. Namespaces were a constant pain point!

XML was designed as a document format, not a data structure serialization format. You're supposed to parse it into a DOM or similar format, not a bunch of strongly-typed objects. You definitely need some extra tooling if you're trying to do the latter, and yes, that's one of XSD's purposes.

This is performance art, right? The very first bullet point it starts with is extolling the merits of XSD. Even back in the day when XML was huge, XSD was widely recognized as a monstrosity and a boondoggle -- the real XMLheads were trying to make RELAX NG happen, but XSD got jammed through because it was needed for all those monstrous WS-* specs.

XML did some good things for its day, but no, we abandoned it for very good reasons.

For not using the default Samsung launcher, which sucks.

Github Copilot was available in 2021, believe it or not. It was just auto-complete plus a chat window, but it seemed like a big deal at the time.

Keep in mind that the US auto industry is also very much a Canadian one. A lot of Big Three stuff happens across the border in Ontario.

But all the policy support that would have let North American automakers build up a competitive position with China is gone, so this is more about just acknowledging reality now.

It's also still not true. My son has a Windows machine that he's responsible for, after a long time running ChromeOS. He's reported all kinds of weird driver things, and having had to watch YouTube tutorials to figure out how to fix issues.

It gave me pause in the sense that it doesn't feel true.

I mean, yes, I've had to look things up to see how to do things in Linux. I've also had to do that on MacOS. (Just the other day, I couldn't remember what the Task Manager-equivalent on MacOS was, and nothing I typed into the launcher was coming up with an appropriate app, so I had to ask the robot what it was named.)

But dozens of hours? Maybe back in the Red Hat 4.2 days, but not now. Some of that is obviously just that I have a lot of knowledge about things, but even so.

What's funny is, the author is only having these questions because they chose a wacky Arch-based ultra-techie distro that I'd never even heard of.

If they'd just installed normal Ubuntu or Fedora, they wouldn't even know what a bootloader was, and they'd just use whatever desktop environment (probably GNOME, maybe KDE) came with it.

I suspect they sincerely picked CachyOS because they read people advocating for it, and were convinced by the advocacy. People advocate all kinds of distros, and all of them except the one I advocate are bad choices.

If you want a bit more automation on your spreadsheet, check out Tiller. They provide the integrations with your banks to automatically download your transactions into a spreadsheet (support Sheets or Excel), as well as some handy templates that you can use for budgeting/dashboarding/whatever. But fundamentally, just pulling data into a spreadsheet so that you can use it however you want.

Yeah, fair! Same sentiment about Microsoft now as then, but fewer real blockers on the Linux side.

I'm sorry, but no. I ran Slackware 96, Red Hat 4.2, Mandrake 5.0, a bunch of Ubuntus from 12.04 onward, and Fedora now. It is absolutely, qualitatively different now than it was at the turn of the century.

In the Red Hat 4.2 days, it was something that I was able to use because I was a giant nerd, but I'd never ever ever have recommended it to a normal person. By Ubuntu 12.04, 15 years later, it was good enough that I'd recommend it to someone who didn't do any gaming and didn't need to use any of the desktop apps that were still then semi-common. In 2026, it's fine for just about anyone unless you are playing particular (albeit very popular) games.

I mean, yes. That's how people work: They don't care about the OS for itself, the OS is a means to run the software they want to run, and it'll be ready when it runs that software.

(I'm typing this on my Linux desktop right now... but also have a separate Windows PC for running the games I want to run that don't work on Linux yet. When they work, I'll be thrilled to put Linux on that machine or its successor.)

I haven't, because I buy hardware that's designed to work with Linux. But if you buy hardware that doesn't have Linux drivers, it just won't work. That might mean Wifi not working, it might mean a fingerprint reader not working, etc.

Works well if the laptop has hardware designed to support Linux. Framework stuff is great, for instance.

Windows 8 era had the same vibe.

I was going back and looking at timelines, and was shocked to realize that Claude Code and Cursor's default-to-agentic-mode changes both came out in late February. Essentially the entire history of "mainstream" agentic coding is ten months old.

(This helps me understand better the people who are confused/annoyed/dismissive about it, because I remember how dismissive people were about Node, about Docker, about Postgres, about Linux when those things were new too. So many arguments where people would passionately talk about all those things were irredeemably stupid and only suitable for toy/hobby projects.)

I don't think they generally one-shot the tasks; but they do them well enough that you can review the diff and make requests for changes and have it succeed in a good outcome more quickly than if you were spoon-feeding it little tasks and checking them as you go (as you used to have to do).

Your monitor is probably set to the wrong settings for film content. Almost all monitors are set to a cool white point out of the box. If you're not producing film or color calibrated photography on your monitor, there is no standard white temperature for PC displays.

If your secrets are in your repo, you've probably already leaked them.

I'm not remotely cutting edge (just switched from Cursor to Codex CLI, have no fancy tooling infrastructure, am not even vaguely considering git worktrees as a means of working), but Opus 4.5 and 5.2 Codex are both so clearly more competent than previous models that I've started just telling them to do high-level things rather than trying to break things down and give them subtasks.

If people are really set in their ways, maybe they won't try anything beyond what old models can do, and won't notice a difference, but who's had time to get set in their ways with this stuff?

... and people kept using Uber.

There is! That is precisely how TVs work! Specs like BT.2020 and BT.2100 define the color primaries, white point, and how colors and brightness levels should be represented. Other specs define other elements of the signal. SMPTE ST 2080 defines what the mastering environment should be, which is where you get the recommendations for bias lighting.

This is all out there -- but consumers DO NOT want it, because in a back-to-back comparison, they believe they want (as you'll see in other messages in this thread) displays that are over-bright, over-blue, over-saturated, and over-contrasty. And so that's what they get.

But if you want a perfect reference TV, that's what Filmmaker Mode is for, if you've got a TV maker that's even trying.

"Warm" or "Warm 2" or "Warm 50" is the correct white point on most TVs. Yes, it would make sense if some "Neutral" setting was where they put the standards-compliant setting, but in practice nobody ever wants it to be warmer than D6500, and lots of people want it some degree of cooler, so they anchor the proper setting to the warm side of their adjustment.

When you say that "HDR is static" you probably mean that "Dynamic tone-mapping" was turned off. This is also correct behavior. Dynamic tone-mapping isn't about using content settings to do per-scene tone-mapping (that's HDR10+ or Dolby Vision, though Samsung doesn't support the latter), it's about just yoloing the image to be brighter and more vivid than it should be rather than sticking to the accurate rendering.

What you're discovering here is that the reason TV makers put these "garbage features" in is that a lot of people like a TV picture that's too vivid, too blue, too bright. If you set it to the true standard settings, people's first impression is that it looks bad, as yours was. (But if you live with it for a while, it'll quickly start to look good, and then when you look at a blown-out picture, it'll look gross.)