SoylentNews is people
SoylentNews
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.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Can anyone remember when the times were not hard, and money not scarce?
(Score: 2) by DannyB on Thursday September 06 2018, @04:13PM (22 children)
Imagine one day if correctfulness were more important than execution speed? If things would fail in a safe way rather than a dangerous way. (someone might even patent a two word phrase for that!)
But it seams speed is moe improtant than accurancy.
FOOF! I say to that!
The lower I set my standards the more accomplishments I have.
(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.
(Score: 2) by martyb on Thursday September 06 2018, @04:30PM
Eye sea watt ewe dead their... =)
Wit is intellect, dancing.
(Score: 2) by darkfeline on Thursday September 06 2018, @07:38PM (3 children)
>if correctfulness were more important than execution speed
That's not the right question to ask. The right question is, "In what cases does the value of N% correctness exceed the cost of reaching N% correctness?", and the answer for most software (or hardware for that matter) is "Never".
Due to inexorable natural laws, as observed in theories like the Pareto principle, fixing the first 80% of bugs takes 20% effort, so fixing the remaining 20% of bugs takes 80% effort, roughly speaking. If creating an 80% correct product costs X and takes Y time, and creating a 100% (actually a lot less due to the exponential curve; 100% is unachievable) correct product costs 4X and takes 4Y time, no way in hell will anyone choose the latter except for extremely small, critical pieces of software, like the brake controller in a car.
Imagine if CPU development took 4 times as much time and cost 4 times as much money. We would be around the 1970s.
Join the SDF Public Access UNIX System today!
(Score: 5, Insightful) by DannyB on Thursday September 06 2018, @08:19PM (2 children)
That extra 4x development cost may be worth it for certain things.
Like avionics, self driving cars, or nuclear reactor control. The cost of wrong might be very much higher than that additional 4x cost during development.
I would even say for microprocessors. Many millions, even Billions and Billions (to quote Sagan) might be manufactured. And today just about everything in the world depends on them working.
I can understand your reasoning if developing a dating site or some nonsense like Facebook. But not for microprocessors.
The lower I set my standards the more accomplishments I have.
(Score: 2) by darkfeline on Friday September 07 2018, @07:24PM (1 child)
>That extra 4x development cost may be worth it for certain things.
That's what I said. Most things don't need it.
>And today just about everything in the world depends on [microprocessors] working.
Yes, today. Not twenty years ago, not ten years ago to most people (SN is not most people), and there are still people today who don't realize the significance of microcomputing devices, and there are still a lot of people who haven't touched a computing device. Take the average company board, are they going to authorize spending an order of magnitude more on computers that are "less buggy" when they see competitors using cheap shit?
Join the SDF Public Access UNIX System today!
(Score: 2) by DannyB on Friday September 07 2018, @07:30PM
You're right that you said most things.
About microprocessors. If there is a development cost of x, which is 20% total cost for 80% correctness, and then 4x which is 80% of cost for remaining 20% correctness, then that 4x element is spread across billions of processors.
The lower I set my standards the more accomplishments I have.
(Score: 2) by bob_super on Thursday September 06 2018, @09:08PM (4 children)
> FOOF! I say to that!
Which is pretty much the right word [wikipedia.org] when talking about dangerous things.
CIF [wikipedia.org] just doesn't roll off the tongue as well.
(Score: 3, Informative) by martyb on Thursday September 06 2018, @11:07PM (2 children)
If you want to read a truly interesting description of FOOF, check out Derek Lowe's "Things I Won't Work With" blog entry [sciencemag.org].
NOTE: you can easily find the article again by searching for what he described would result from reacting FOOF with sulfur hexafluoride: "Satan's kimchi". It is a vast understatement to way Derek has a way with words! If you have even a slight interest and knowledge of chemistry, I can think of few more enjoyable ways to lose a few hours than reading the other entries on his blog!
Wit is intellect, dancing.
(Score: 2) by bob_super on Thursday September 06 2018, @11:12PM (1 child)
Love that blog. Went for the Wiki this time, but I've posted the Lowe version here before.
Interestingly, the quote in the Wiki about ClF3 (the pair of running shoes) is the exact same as on the blog.
(Score: 2) by martyb on Friday September 07 2018, @12:01AM
Thanks for the reply!
A minor nit, if I may? The quote you are referencing actually came from "Ignition! An Informal History of Liquid Rocket Propellants" written by John Drury Clark [wikipedia.org]. That said, (written?), that work is also a most interesting read! Highly recommended, as well!
Wit is intellect, dancing.
(Score: 2) by DannyB on Friday September 07 2018, @03:59PM
I was thinkiong FOOF as the name of a famous Intel snafu.
The lower I set my standards the more accomplishments I have.