Back when Intel introduced the 80286, they didn't quite document everything right away. Errata were needed. Then the 80386 changed things. And then someone convinced them to add just one more feature at the last minute, which didn't get documented properly again.
The History of a Security Hole takes a look at the problems introduced by the I/O Permission Bitmap (IOPB) in the 80286, and how fallout from the implementation caused a security hole in all versions of OpenBSD up to 6.3 and NetBSD up to 4.4.
Conclusion? This programming thing is hard.
(Score: 2) by requerdanos on Thursday September 06 2018, @04:27PM (11 children)
One day it would take if speed remained important. The same operation would take many lifetimes if perfection (which you are somewhat misleadingly calling "correctness") were the only allowed component.
(Score: 4, Touché) by DannyB on Thursday September 06 2018, @04:40PM (10 children)
If speed is moe improtant than accurancy, many programmers can be executed at the same time by using multiple cores. Kubernetes running on a scalable fuster cluck.
The lower I set my standards the more accomplishments I have.
(Score: 2) by requerdanos on Thursday September 06 2018, @04:41PM (9 children)
if /dev/null is fast, I will use it.
(Score: 1, Interesting) by Anonymous Coward on Thursday September 06 2018, @05:00PM (8 children)
Does /dev/null support sharding?
(Score: 2) by DannyB on Thursday September 06 2018, @05:29PM (6 children)
Plan B might be to create
/dev/null
/dev/null1
/dev/null2
/dev/null3
. . .
/dev/null59872
etc
Can that be done without a kernel patch? Or is the non-scalable /dev/null a deeply embedded kernel concept?
The lower I set my standards the more accomplishments I have.
(Score: 2) by Arik on Thursday September 06 2018, @06:09PM (5 children)
Should be doable in a single command, something along the lines of
for i in count(1-99999) ln -s /dev/null$i /dev/null
If laughter is the best medicine, who are the best doctors?
(Score: 2) by DannyB on Thursday September 06 2018, @06:23PM (4 children)
Would a hard link work, or work better than a sym link?
The lower I set my standards the more accomplishments I have.
(Score: 4, Informative) by Bot on Thursday September 06 2018, @09:13PM (2 children)
AFAIK you can use mknod or even better MAKEDEV using the same major minor combination as dev/null (1 and 3). It's still cheating because it's the same device, but I don't see the point to patch the kernel to instantiate more of them.
"Now although the major:minor combination uniquely identifies specific device instances, there's nothing to stop you creating multiple devices nodes (files) that refer to the same device. They don't even have to be created in /dev (but they do have to be on a filesystem that supports creating device nodes, and isn't mounted with the nodev option)".
For getting dev nodes in a chroot you are usually instructed to mount --bind the device files.
Account abandoned.
(Score: 1, Interesting) by Anonymous Coward on Friday September 07 2018, @12:20AM
beat me to suggesting mknod
mknod -m666 /dev/null$i c 1 3
(Score: 2) by DannyB on Friday September 07 2018, @03:57PM
The reason I had asked about a kernel patch was because I didn't know whether /dev/null was part of the kernel in the sense of /proc or /sys. But actually I did know this from reading about 15-18 years ago. It just didn't strike me until you mentioned it. Then I was like: oh, yeah, right! Not something I would have thought of on my own.
Thanks for the great (snicker) approach to scaling if you are doing too much IO to /dev/null. :-)
The lower I set my standards the more accomplishments I have.
(Score: 1) by Arik on Friday September 07 2018, @05:35AM
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Thursday September 06 2018, @06:47PM
Yes, sharding is the secret sauce used to make /dev/null a tasty option.