Or Linux development is significantly more active.
Or, if the act of debugging is removing the bugs from software, then the act of programming is to put the bugs in the software.
Use it as a verb, like embiggening. :)
Depends on the quality of the code being written.
Quality*Quantity
But I do agree with you - not directly related to activity.
OpenBSD's version is as simple as it gets[2].
[1]: https://github.com/coreutils/coreutils/blob/master/src/yes.c [2]: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
[1] https://github.com/freebsd/freebsd-src/blob/main/usr.bin/yes...
Capsicum is really nice if you plan ahead, but pledge/unveil is easy to drop into any existing code base.
> capsicum is after the fact
After the fact in what sense? The program enters capability mode before touching any arguments or doing I/O. You have to set things up before enter capability mode because you can't escape out of it afterwards.
> it does nothing about syscalls
It does quite a lot about syscalls, in that it blocks or limits most of them. As the man page says: "Access to system calls in capability mode is restricted: some system calls requiring global namespace access are unavailable, while others are constrained."
In capability mode, you can use specific syscalls that operate on file descriptors, which limits the program to the specific capabilities it has been granted, e.g. pdkill(2) which is like kill(2) except you can only signal processes for which you have a process descriptor.
Copyfail being introduced by an optimization made to some random crypto module is a good example of this.
Seems to be the case.
How many times do you see a bug investigation and it's determined when the bug was introduced?
Do you ever look at the diff that introduced it to understand what was going on in the project at the time? Often, it's in service to a new feature. Sometimes the original change is questionable when you consider you traded it for a severe bug.