I don't think there is one programming language that is best suited for all types of programs. I think that Rust is probably the best language currently in use for specifically implementing Unix coreutils, but I don't think that this implies that (say) Zig or Odin or Go or Haskell would necessarily be terrible choices (although I really would pick Rust rather than any of those).
But my point was that there's no reason to think that the specific package of design decisions that Rust made as a language is the best possible one; and there's no reason why people shouldn't continue to create new programming languages including ones intended to be good at writing basic PC OS utils, and it's certainly possible that one such language might turn out to do enough things better than Rust does that a rewrite is justified.
I have no opinion whatsoever on the rewrite. It might be the best thing since sliced bread for all I know. I have trouble with integrators recklessly shipping untested dependencies however.
The sliced bread might not be the best quality, but it is rather consistent and much less crummy when making yourself a toast or just butter+jam. No dangers of a kid cutting itself while making its own sandwich either.
Middle class people who think of cooking for themselves as a hobby maybe lose the ability to understand labor-saving technical advances. People who cook as a duty think of cutting bread as more work, which it quite obviously is.
If cooking is a hobby for you, you're seeking labor. Maybe that makes the obvious unintelligible. If you're poor and have a bunch of hungry kids waiting, you don't want the cutting board covering up half your counter space while you're carefully trying not to screw up eight slices of bread before something on the stove burns.
It was combined with the toaster and sandwiches made easily, and taken away for a bit in WWII, and then came back. It was one of those advancements that "stuck".
Knew what absolute disaster of a video this was going to be before clicking. Highly recommend watching Colin's videos, this one included, for the sheer level of "this is clearly a bad idea, let's do it" that he gives off and the things learned along the way.
Aside from there being no crises, rewriting a set of utilities with nearly no bug reports for years and for which no new features is needed accomplishes what exactly? Aside from new bugs, that is.
There surely would be a more beneficial undertaking somewhere else.
If then you’d argue that they may do as they please with their time, fair, but then let’s not pretend this rewrite has any objective value aside from scratching personal itches and learning how cat and co are implemented.
This effort has produced new bug reports and test cases for upstream, clarifying their desired behavior. That's one positive side effect that helps everyone.
I recommend that you look into the bug trackers of the original tools. There were a lot of bug reports that came from reimplementing these tools. It's also not a replacement - at all. You and distro managers can choose not to use them.
In my experience the crisis comes more from an influx of people who wants to change everything without having read or caring for specifications and portability. There is however a lack of people like to clean the dirty stuff behind them.
Brilliant. This is another piece of evidence on the pile of why we got Wayland: it's because people who understood X11 mostly retired and everyone else couldn't be bothered to learn X11 because it's "yucky C code" or something. And it bothers me that we lose remote rendering with Wayland (unless one fights with waypipe) that was just built-in to X11. Yes, it was slow, but actually if you're running a VM on your local system and using SSH to connect to it, then it works great. Sigh. I'm an old person yelling at clouds.
Not particularly if you are on a low latency network. Modern UI toolkits make applications way less responsive that classical X11 applications running across gigabit ethernet.
And even on a fast network the wayland alternative of 'use RDP' is almost unusable.
For whatever reason X11 shoving pixbufs over the network seems to have orders of magnitude better performance than actual RDP over a high speed network.
How would government realistically preserve a (in hindsight) fragile cultural phenomenon? OTOH a ~difficult mandatory PC/internet operator's license might have done it.
Now that reminds of the weird Internetführerschein ("internet driver's license") courses for nontechnical folk in Germany. Though these were entirely optional and so not cool.
That wouldn't have prevented tech bros from hijacking the cultural momentum or commoditizing attention. Even a maximum fidelity web archive would drown in the noise just the same.
Many recruiters continue to reach out to me on LinkedIn mostly, including FAANG companies. All of the positions are either a 3-2 hybrid or completely on-site. In such cases, these companies want to phone screen and have the first round technical interview via Zoom or something. I've been telling the recruiter that, unless the company allows fully-remote work, I will not allow for a remote interview; however I am happy to interview so long as the entire process is on-site. That includes everything that would normally be done remote, such as the initial phone screen. I'm tired of companies (think of some well-known ones) having it both ways: remote interviews are OK for them but not remote work. If enough smart, technical people told these companies "no, I won't allow you to conduct a remote interview for a non-remote position" then things may change.
1. I had a recruiter from Amazon reach out to me about “exciting opportunities” as an SDE on LinkedIn. The issue was that my profile showed that I was already working at AWS.
2. A recruiter from Google reached out to me about an Engineering Manager position. Not only did I not have any management experience on my profile, my current position then was in the consulting department (full time) at AWS - it wasn’t even officially software development
3. A recruiter from Meta reached out to me about a senior software engineer position in AI. Again, my profile clearly showed a bunch of no name CRUD developer jobs and then working in consulting
Recruiter outreach is no indication of careful targeted outreach
Recruiters, in my case, have either been contractors or employees of the companies for which they're hiring. In the latter case, they're better prepared than those of the former.
I would only assume the other side of this entire conversation, from the recruiters view is that it is also a numbers game. Recruiters are effectively sales jobs just a different contract to close on. Get enough leads and eventually they close.
I'd expect that don't care if the resumes are perfect. There's very little lost for being wrong.
I’m fairly OK financially at this point so my strategy is to make the money I can, while I can, and then when I become unemployable or replaced by LLMs, just retire.
