Maybe a job of nothing but coding would be dead but I don't think such a job should have ever been alive.

I can't imagine anyone who has actually used LLM coding assistance think the skill of being able to read, modify, and write code would be dead anytime soon. It went from complete absurdity to surprisingly capable, but still mostly wrong real quick and has kind of sat there for all but the most brain dead simple projects.

I have one of those knob controls for the phone interface and it's good for most things, but if you want to generally peruse the broader map around your route touching is nicer since you can zoo easily rotate, scroll, and zoom. I frequently do that when I'm setting out, request a route, then fiddle with it a bit to understand the route before actually starting the drive, having it zoom out to show me the big route and then I pinch to zoom in on any interesting looking turns so I know what's coming/decide if I want to do it a slightly different way (google loves to just take an exit and get back on to shave maybe one minute off a traffic jam, and I generally ignore those).

Not just tactile feedback, but ability to feel. If they just vibrated the screen a bit, it's an improvement, but doesn't help with navigation.

There was this one car I was in some time ago that did have hard controls, but it was mostly a fairly large sea of nondescript square buttons. Almost as bad as a touch screen.

Having a control surface you can feel with obvious knobs and such with distinct feels for at least the most prominent functions..

I'm not so sure about this, this has been one area where the 'natural language' interfaces sometimes lose a lot. For example, if you are trying to review a map on your display, just nothing beats being able to fling it around, twist it, and zoom it with your fingers. For a lot of adjustments, it's nice having the full range so you can zip it straight to where you want without having to audibly describe where you want. And of course hard controls for adjustments and instant reactions, like 'shut the music up, answer/hang up a call, adjust the temperature real quick'. Voice for things like 'navigate to work', maybe, though on the other hand Google already presents a selection of two or three likely destinations, and work or home will be one of those so tapping is quicker, and if it got smarter then sometimes it might catch other destinations too.

In other areas I've seen people champion ditching UIs because natural language is here, but there's a lot of stuff that's harder to do with language than to hit buttons or knobs or such.

My car has a 15 inch touchscreen that can just be a projection of my phone's interface fixed in a supremely convenient location and nice and huge.

I'm with you on leaning too much on the built-in hardware which will age like milk compared to the expected lifetime of the car, which is why things like Android Auto and Apple CarPlay are so useful to get the interface benefits of the built in, but with the core software and hardware capable of being modular.

At least as of the 2022 model, that was still alive, just concurrent with the touch interface.

They want a touch screen because you need at least some touch screen to do Apple CarPlay or Android Auto or other similar ecosystem applications.

For example, a touchscreen is nearly a requirement for decent GPS UI. There are applications where the multitouch gestures are hard to beat for the UI.

Problem is the industry struggles with the concept of "touch screen for *some* things, but not everything". So you get things like "here's the touchscreen you wanted, *including* replacing those HVAC hard controls with some touch screen stuff".

Of the modern cars I've been in, a 2022 BMW seemed to get it pretty much just right, a healthy amount of physical buttons and a respectable touch screen along with a wheel with haptic feedback for eyes-free cursor style interaction even with Apps. The had this goofy "air gesture" thing that was pretty useless, but it seems like they've given up on that.

For the missing child scenario, they cast a wide net because they want to try to cover about a 2-3 hour radius of likely travel so that someone might see a license plate. But as was pointed out, this can be useful for people actively driving or in a parking lot, not so useful when it's on a nightstand indoors at home where there's zero chance the person is going to see any license plate.

While his comment was a bit off putting, there's a point about overuse of the system.

A child goes missing. That's unfortunate. Perhaps not as unfortunate as you might guess, it's often a custody dispute with lower risks than the alert would make you think, but still worth getting the word out.

But 150 miles away, on a nightstand where it's certain that I won't be recognizing the license plate in the alert, there's not much to expect that I'll be able to do anything helpful. Sometimes the alerts are pointless. One was something like "we are searching for a six year old girl", no vehicle description, not even a description of any person apart from the age and a gender.

On the weather side, if it even thinks of raining, I'm going to get likely a number of emergency alert sounds with flash flood watch. A very normal rain pattern that could flood certain places to be sure, but those places are used to assuming any rain means a flood, so it's not news to them. Whether it's a "gentle rain will cause normal flooding" or "a catastrophic hurricane is going to level the whole area", it's the same alert with same tone of urgency and a single off/on switch to say whether you get them or not.

It's hard to take them seriously when 90% of them are nothing and/or I'm useless to them, but they present themselves with the same level of critical urgency demanded no matter what.

Yeah, similar story, it's weird because people just end up searching for Rocky or Alma Linux content on the same thing and using that to try to work with RHEL...

You may know for yourself, but having to reconcile this with having *RedHat* track your usage rather than just yourself is where the aggravation comes in.

When you have to track for yourself, not to bad. When you have to track in the various ways various vendors demand separate of how you yourself would track....

If you mean service containerization like podman or docker, then that's still pretty awkward to juggle around and I end up curating a bunch of OSes. But they don't really provide for 'desktop' usage anyway without a lot of manual effort.

If you mean like flatpak or snap, I've been game but just today I tried to switch from distro packaged application to distro provided flatpak and to flathub provided flatpak and ultimately the native one actually came closest to working, with the flatpaks being even worse at not caring after some optional features that I really needed. I could reasonably with aggravating effort fix the broken requirements of the native package, but the broken flatpaks were just broken.

I think if you sit in the wheelhouse of the distro, keeping up to date should be pretty good and get you the functionality you want faster, but if you have heavy third party involvement or potential exposure to capricious compatibility breakage by some upstream projects, then the risks appear and get really obnoxious really fast.

I agree with my technical assessment that OEL seems credible, but as you say, to deepen a business relationship with Oracle is to invite huge pains and audits and invoices for things you never actually got but they claim you did. OEL nails the technical merits of logistics, but I couldn't trust the business behind it enough to tolerate it.

Alma Linux is probably my favorite of the RedHat-alikes, but would have ignored the hell out of them, Rocky, and Oracle if RHN wasn't so obnoxious about making me prove to them we're using it right in just the way they want it proved to them. My companies usage pattern and willingness to pay is consistent with RedHat usage model, but those logistics are just a no-go.

RedHat has been in a weird place for a while now. Some folks at RHEL took Oracle Linux pretty personally, and basically ever since that launched they've been wanting to burn down the whole clone ecosystem if they could tank Oracle Linux in the process. Which is crazy, since as far as I can tell Oracle Linux is largely ignored except for some real die-hard Oracle shops that probably would have run Solaris if Oracle forced them to, so it's not like RH had a huge shot anyway, and they aren't really that much of the market. Any time you bring up clones with those folks they immediately are audibly frustrated and whining about Oracle, when most people in the room other than them tended to forget Oracle Linux even existed.

As market pressure has worsened against RedHat, it feels like they just keep making it worse. The more and more Ubuntu made inroads for being a bit more straightforward to deal with, the more difficult and complicated RedHat made it to run RHEL or RHEL adjacent.

For a brief moment I thought they got sanity when they announced the retirement of CentOS with a suggestion that they were changing RHEL in ways that would make CentOS unneeded anyway. I thought maybe they noticed that people went to clones because of the simpler repository situations and also Ubuntu being in that same boat and were going to change to be more like Oracle Linux. Nope, they were referring to things like this, you still have to deal with rhn and registration walls around documentation, just ever more convoluted exemptions for maybe possibly not having to pay for some of those entitlements that you still have to manage.

In a fair share of the ecosystem with no regard for backwards compatibility, (especially looking at Python projects), it can be maddening to try to work with fluctuating dependencies and dependent software that isn't equipped to deal. Using a modern non-rolling release has given me enough headaches with software that *largely* works but some piece is broken because, say, they hadn't fully tested with Python 3.13 yet.

The biggest problem rolling release solves is impatience to get to new functions that some users may not be in a hurry to get to anyway. A debian stable user certainly has to be used to usually 'ancient' software, since it's release cycle is roughly in line with Ubuntu LTS, RHEL, or SUSE Enterprise, which is at least a broader target for software to come together on.

Of course, a debian user that is wanting rolling release can live with unstable or testing, though not explicitly intended as a daily driver.

Arch users can enjoy things, but just saying that rolling release is not unambiguously better than the alternative.