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 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.