If you upgrade then, for example, you can't run all of your PHP 5 code in PHP 8, most of it you can but you will have to change the parts that are broken, which are the areas that are repaired in PHP 8.

Same goes for other languages like C# or Python

The standard libraries were the lacking part in PHP. The language itself was never a serious problem.

i haven't heard any issues about coffeescript.

with that in mind, i'd love to hear your stories. how did you get bitten?

I still hate PHP the most, and I very much mean PHP 5 when I say that, and have no idea what happened beyond that, and honestly the scars are so deep I don't care to find out.

I think the situation is better now, but that was worthy criticism for a long time; like anything though, those that bought into it wholeheartedly couldn’t take the criticisms.

I wonder if there’s a word for that, seems to be a common issue.

CGIs in the 90s were written in perl 5, and perl hasn't evolved much since then. but perl was never a bad language. it had/has a quirky syntax. if you were coming from a lot of commandline work using sed, awk, tr, and many other tools to manipulate text in shell scripts, then perl made a lot of sense.

and while raku may have been a great improvement, perls reputation was tied to its syntax. the readability and writeability of the code. and that's the one thing that raku did not change significantly.

so unlike other examples i don't see how peoples views of perl could improve

> My hope is that this reputation will go away eventually, as less issues are found in the code.

this has not yet happened like this other comment shows: https://news.ycombinator.com/item?id=44632639

Switching to io_uring is not just moving from one API to another. It necessitates a serious rethinking of your concurrency model. I guess for big, established codebases this is a very substantial undertaking, security consideration notwithstanding.

not about their servers

I wouldn't be surprised if they do have servers with it enabled when very useful.

and Android Linux kennels lack behind in their version

If a kernel panic is considered a security issue, anyone using Nvidia's drivers should fear for their lives.

Is io_uring a complex and therefore bug-prone API surface? perhaps.

The `curl` project has a similar number of CVEs listed if you search for it, but we generally don't characterise curl as insecure.

If you're not using io_uring then it could make sense to disable it as a hardening measure, but I don't think the existence of now-fixed CVEs is a reason not to use it.

Nowadays its mostly a combination of eBPF, SELinux and auditd plus namespaces in case of containers. Usually in the combination that some distro ships, so nothing really fancy.

1. know what io_uring is

2. are interested in performance enough to look at improvements based on new linux kernel system calls and talk about it in public

3. care about security in multitenant environments or the syscalls used by third party libraries

I think io_uring right now probably makes a lot of sense for HPC and highly technical, performance-sensitive financial stuff, but they can be kind of insular. I don't think most linux hobbyists really need the performance benefits enough t care about it, and most businesses are using a major cloud vendor/don't have the scale or expertise to be thinking about this kind of stuff. Which leaves major cloud providers and really big businesses like Meta with their own internal clouds as the ones that stand to benefit enough to care about performance while really caring about security

That someone with kernel IO dev experience may be able to relatively easily add such a fetaure in the future (though I would doubt that, given that it hasn't yet been implemented apparently) doesn't make it a small problem.

- io_uring initially was conceived without considering security or auditing tools

- io_uring later was changed to allow ioctl calls, even though security people do not like ioctl because what its arguments mean depends on the device being called (possibly even on the version of the driver), not on the type of device, and often is poorly documented, making it hard for a security filter to decide what to do with a command.

That also made them fear that similar security-breaking changes might be made in the future.

io_uring is only a more ambitious manifestation of a pattern that has been commonplace for a long time. High performance network, storage and other hardware use circular buffers internally in their drivers to process commands and return results. io_uring is attempting to realize the same pattern, but for the entire operating system interface.

That's a really big idea. It has me asking whether this isn't how all "IPC" should be done, where one generalizes all of the running processes, including the "kernel." Ultimately it has significant implications for CPU architecture, supplanting traditional patterns.

When I wrote "given the nature of io_uring," I had something specific in mind wrt formal verification. io_uring fundamentally consumes a stream of bytes. At the front end of that is a great deal of validation code to ensure the steam contents are sane. At the backend, the commands are mapped to existing kernel functionality. It's the front end I think could be well served by formal verification.