The ribbon that was introduced around… 2007, I think? Or is there a substantially different one now?

Most of those comments are actually just random people arguing about the merits of the experiment, not continued discussion with the bot.

Also, the bot is supposed to be able to run builds to verify its work, but is currently prevented from doing so by a firewall rule they’re trying to fix, so its feedback is limited to what the comments provide. Humans wouldn’t do great in that scenario either. (Not to say the AI is doing “great” here, just that we’re not actually seeing the best-case scenario yet.)

The user who submitted the report that Stenberg considered the “last straw” seems to have a history of getting bounty payouts; I have no idea how many of those were AI-assisted, but it’s possible that by using an LLM to automate making reports, they’re making some money despite having a low success rate.

Every single time I’ve tried to work on a file using tabs, I’ve had to configure my tabstop to be the same width the original author used in order to make the formatting reasonable. I understand that in theory customizable tabstops is preferable, but I’ve yet to see it work well.

(For what it’s worth, I think that elastic tabstops, had they been the way tabs worked in text files to begin with, would have been far preferable.)

Nope. It links to an explanation of what that poster is:

This is the UNIX Magic Poster, originally created by Gary Overacre in the mid-1980s and published by UniTech Software.

Lots of acronyms no longer stand for anything due to losing their original associations. LLVM, AT&T, SAT (the test, not the programming problem), etc.

You don’t have to imagine it; you can browse the Linux Kernel mailing list!

That’s called a mailing list

/s

TypeScript is a language, and traditionally languages are considered separate from their implementations. When I first saw the headline I hoped maybe it meant a non-JS runtime for compiled TS, and I’m well aware of the difference. Yes, that would be a much larger undertaking than porting the compiler to a new language, but the headline doesn’t indicate how large a project this is, and Microsoft certainly has the resources to write a new backend (even a native-code one) for the TS compiler.

They did consider making environment-manipulation functions atomic; the problem is that there’s simply no way to guarantee that everything that can manipulate your process’s environment is actually beholden to whatever atomic interface Rust provides. I could be misremembering, but I think there was even some discussion with glibc maintainers about whether this could be made safe, and the answer was basically “haha no.”

I…honestly don’t know what you mean, and I’ve had 11 since about when it came out. Do you have an example?

Lots of settings actually seem more convenient now, especially the ones for audio and Bluetooth.

This headline is based on responses to the question “what are your biggest worries about the future of Rust”, not “are you worried about the future of Rust.” So of course most of the respondents answered with a concern about the language.

Marcan pretty clearly isn’t saying that feature requests wore him down. He’s saying that people saying “what you’ve built so far isn’t useful” wore him down.

(Plus, your original analogy about parents and children is completely lost by now.)

Not sure if this was intended as a response to me?

Presumably by people like Marcan working to make it happen, rather than by random people complaining it’s not already done.

The bit you quoted from the post explicitly said “most x86 laptops”, not “all”.

I wrote a longer reply with links, but somehow it didn’t actually post; so this will be shorter and unsourced. Sorry about that.

There already was a discussion, over the course of several years, about whether to add Rust to the kernel. Linus merged rust/kernel into the mainline in 2022, and it was released in Linux 6.1. The patch that Hellwig opposed did not introduce Rust, it just added more Rust.

Hellwig also made it pretty clear that he wasn’t open to discussion. If you read the thread, there were numerous attempts to “talk things over.”

You may be right that Marcan’s posts on Mastodon added nothing productive, though I honestly think there’s some value in sharing behavior like Hellwig’s with the broader programming community. But his posts in the actual mailing list seem pretty sensible, albeit provocatively worded.

Also, in case you didn’t know, similar behavior (to Hellwig’s) led the primary Rust for Linux maintainer, Wedson Almeida Filho, to step down back in August. Marcan is correct that the anti-R4L maintainers are successfully demoralizing the R4L people.

Do you take this sentence seriously, or not?

I will do everything I can do to stop this.

As far as I can tell, “this” here refers to literally any Rust code that isn’t constrained within a specific driver. That does indeed seem like a full-on attempt to stop the R4L project entirely.

He does appear to have a real technical concern regarding maintainability.

“Appear” is doing some heavy lifting there. Opponents of the R4L project always couch their objections in technical concerns. For what it’s worth, I can’t actually find any concerns of merit or substance in that particular thread, although navigating mailing list threads is honestly pretty error-prone, so I may have missed it.

In addition to not actually being correct, I don’t think the information you’ve provided is particularly helpful in answering OP’s question.

The first part is confusing what “middleware” means. Rather than “duplicating” functionality, it connects libraries (I’m guessing this is what you meant). But that has nothing to do with a language being compiled versus “directly executed”, because compilation doesn’t connect different services or libraries; it just transforms a higher-level description of execution into an executable binary. You could argue that an interpreter or managed runtime is a form of “middleware” between interpreted code and the operating system, but middleware typically doesn’t describe anything so critical to a piece of software that the software can’t run without it, so even that isn’t really a correct use of the term.

The second part is just…completely wrong. Lisp, Fortran, and other high-level languages predate terminal shells; C obviously predates the shell because most shells are written in C. “Most original code” is in an actual systems language like C.

(As a side note, Python wasn’t the first scripting language, and it didn’t become popular very quickly. Perl and Tcl preceded it; Lua, php, and R were invented later but grew in popularity much earlier.)