[HN Gopher] RFC 9225: Software Defects Considered Harmful
___________________________________________________________________
RFC 9225: Software Defects Considered Harmful
Author : wakamoleguy
Score : 217 points
Date : 2022-04-01 17:23 UTC (5 hours ago)
(HTM) web link (www.rfc-editor.org)
(TXT) w3m dump (www.rfc-editor.org)
| topspin wrote:
| Someone, somewhere is going to unironically cite this RFC as a
| compliance requirement. In fact, I might do that just to see what
| happens.
| rablackburn wrote:
| I think there's a few of us who have already memorised the
| number so we're ready on Monday...
| bombcar wrote:
| I think the same argument that is used against "GOTO considered
| harmful" applies here - deep down, at the machine level, every
| single decision that is made by the code is simply just a bug.
|
| Pretending that "higher level code" avoids the bug because you
| don't see it is just tricking yourself. At the base level, code
| is just 0, 1, and bug.
| spc476 wrote:
| From my quotes file: "Every program has at least one bug and
| can be shortened by at least one instruction---from which, by
| induction, one can deduce that every program can be reduced to
| one instruction which doesn't work." Proof:
| http://en.wikipedia.org/wiki/IEFBR14
| oneepic wrote:
| RFC 9226: Software Considered Harmful
| [deleted]
| virgulino wrote:
| RFC 9226: Bioctal, Hexadecimal 2.0
|
| https://news.ycombinator.com/item?id=30883799
| AdmiralAsshat wrote:
| I look forward to the final draft after corporate lobbying has
| made their suggested alterations:
|
| "Software Defects Considered Harmful Unless Fixing Them Requires
| Pulling Resources Away From Delivering New Features"
| sumtechguy wrote:
| Can you get that on the backlog and we can run it through
| intake?
| bombcar wrote:
| See we solved this by filing the missing feature as a _highest
| priority_ bug. Everyone 's happy and it's Agile. Or Algae. I
| forget which.
| commandlinefan wrote:
| > a highest priority bug
|
| The 70th this week, in fact...
| flenserboy wrote:
| Apple's been using this rule with the Finder for decades.
| hermitdev wrote:
| > "Software Defects Considered Harmful Unless Fixing Them
| Requires Pulling Resources Away From Delivering New Features"
|
| "Software Defects Considered Harmful Unless Fixing Them Enables
| Charging Customers For An Update"
|
| Fixed that for you.
| pornel wrote:
| Excellent. Now instead of saying "this doesn't work" I can say
| "this software is in violation of RFC 9225".
| ganzuul wrote:
| TBH it had me going. "Well, I guess we finally need to define
| this in an RFC." "Maybe this will helps against TLA spies
| hiding backdoors in critical infrastructure." "Surely automatic
| theorem proofing could help with this." And "Oh..."
|
| I have had a terribly humorless day. The dryness made me
| chuckle in some deep hidden place.
| amelius wrote:
| Tautological headlines considered harmful.
| falcor84 wrote:
| I personally find these to be a lot more positive than those
| following Betteridge's law.
| mdeeks wrote:
| Blockchain can help with this. We can record all defects on the
| blockchain and have tamper proof evidence of those who
| consistently fail to adhere to this RFC. It will encourage
| developers to write bug proof code everywhere. Employers can
| further encourage developers to stop writing bugs by docking the
| gas fees from their paycheck. This works doubly so on devs who
| are blockchain "non-believers" because they desperately will not
| want to contribute to the heat death of our planet. (Those people
| clearly don't get the bigger picture. The colossal waste of
| energy will obviously be offset by the fact that code throughout
| the world will no longer have bugs and people will be more
| efficient.)
|
| This seems like it could be the one of the best thing to ever
| happen to the software industry in decades and has no possible
| chance of unintended consequences.
| adhesive_wombat wrote:
| Harmful or not, they pay a lot of salaries.
| actinium226 wrote:
| "Headlines abusing 'Considered Harmful' Considered Harmful"
| codetrotter wrote:
| > Best Current Practises
|
| > 1. Authors MUST NOT implement bugs.
|
| This, of course, is achieved by writing the software in Rust.
|
| Writing software in Rust avoids, not only memory corruption type
| bugs, but indeed it is impossible to implement any sort of
| defect, as long as you write your software in Rust.
|
| /ducks
| vlowther wrote:
| Instructions unclear, now suffering from waterfowl infestation.
| I think some of them are geese.
| wongarsu wrote:
| Alternatively write your software in Go. Go is not only memory
| safe, it's also easy. So easy that it's basically impossible to
| write bugs in any Go program.
| rurban wrote:
| This of course is achieved by writing software in a safe
| language. would be nice if Rust someday would join this group.
| their bug tracker speaks otherwise, and their docs and specs
| ditto.
| gnufx wrote:
| OK, hands up all those who were about to post something
| similar.
| giomasce wrote:
| The combination of this and RFC 8962 is going to create a lot of
| trouble...
| mostertoaster wrote:
| "As it is assumed that there is an even distribution of bugs
| through all software, it is safe to consider any piece of
| software to be bug free once a certain number of bugs have been
| found"
|
| Lol genius. Anyone else ever do that thing where you write some
| good code and it works the first time you test it, but somehow
| that makes you feel less confident. Other times you write some
| crap code and it has several immediately found bugs but weirdly
| you emotionally feel more confident in that code because you
| "fixed" the bugs.
| akavi wrote:
| No, the exact opposite for me: Code that works on first run is
| almost always actually bug free; if I find one bug in a piece
| of code, then I almost always fine more eventually.
| Arnavion wrote:
| There have been a few times when I wrote complicated Rust code
| involving mutable borrows moving around lots of scopes,
| expecting the compiler will yell at me and I'll have to rewrite
| it a lot, but it compiled fine the first try. It makes me
| suspicious every time that I've done something wrong.
|
| Of course there was the one time when it was an actual compiler
| bug, heh. https://github.com/rust-lang/rust/issues/51117
| DaiPlusPlus wrote:
| > Anyone else ever do that thing where you write some good code
| and it works the first time you test it, but somehow that makes
| you feel less confident. Other times you write some crap code
| and it has several immediately found bugs but weirdly you
| emotionally feel more confident in that code because you
| "fixed" the bugs.
|
| Ever since I started adopting TDD, FP-style and using "Railway
| oriented programming", and always running static-analyzers as
| part of the build process far more often-than-not my code not
| only works correctly on first-run, but stopped getting bug
| reports. It felt weird at first but now it's weird to see my
| code not work on the first run.
| lordnacho wrote:
| > Anyone else ever do that thing where you write some good code
| and it works the first time you test it, but somehow that makes
| you feel less confident
|
| I did this yesterday. I was writing a variation on a function
| to draw some stuff in the terminal. When I ran it, it worked
| fine, no crash or anything like that.
|
| Turns out I wasn't running the new version of the function.
| anamax wrote:
| I start by inserting asserts that fail. I keep at it until
| the expected failures occur. As I fix things, I move those
| failures.
| kergonath wrote:
| This happens to me _all the time_. "Dammit, I thought I fixed
| that damn stupid bug an hour ago" before realising I
| effectively hit "run" instead of "build and run".
| scottlamb wrote:
| I do that all the time. And I just [1] did the reverse: I
| tried to track why a bugfix wasn't working, only to realize
| my user was running a version that predated the fix. D'oh.
|
| [1] https://github.com/scottlamb/moonfire-
| nvr/issues/209#issueco...
| yjftsjthsd-h wrote:
| Hah, yes; the number of times I've accidentally run ansible
| with --check (dry run) and then wondered why the server
| wasn't restarting...
| jlokier wrote:
| The best refactor is the one you accidentally commit using
| the smooth, virtuoso commit command only for masters of the
| art, "git reset --hard". Fingers have a mind of their own
| sometimes.
|
| (Next was something to snapshot the VM, followed by "apt-get
| install ext4magic". It worked!)
| gnat wrote:
| When I was a larval programmer, I collected the different
| types of bugs I found as I debugged my code. This category
| was my favourite.
|
| I once progressively commented out more and more of a file,
| trying to find the bit with a bug, until the whole thing was
| commented out and no source was being compiled yet the
| original buggy behavior was still there and only THEN did I
| figure out I was editing a different file than I was
| compiling.
|
| Echoes of this original sin have shown up repeatedly
| throughout my life, to be point where it's one of the first
| things I check when my corrective measure has no effect on
| problematic behavior.
| Akronymus wrote:
| This is why, when compiling, I have "everything" pulled up,
| sorted by change timestamp and check if the file I care
| about actually has changed.
| the_af wrote:
| I've been hit enough times with this bug, now it's one of
| the first things I test. Just printing something in order
| to check I'm editing the right file, even before trying to
| fix the actual bug!
| salawat wrote:
| Not really a bug though. That's operator error. This week
| I've seen multiple people stumbling over that, and it's
| gotten to the point I question whether people understand
| filesystems anymore.
|
| Half the reason for them is to provide an abstraction
| that maps a spacelike addressable quality to data to be
| operated on. It's an extension on the more general
| concept of namespaces. What's the difference between data
| HERE and data THERE. different path.
|
| Even with stuff like git or other VCS's where you fudge
| the spacelike mapping with an extra layer of time-like
| addressing...
|
| This is the content HERE from 3 revision's ago vs. the
| content HERE now vs the content over THERE either now
| that or 3 revisions ago...
|
| I have to train people to break them of the habit/hubris
| of thinking they are "smarter" or more "accurate" at
| computation than the computer is. If you take the meaning
| of compute to be "creatively navigating to a solution in
| a problem space, humans win hand down.
|
| If you define it as reliably doing the same thing over
| and over again, give up. The silicon has you beat. Always
| check your assumptions against what the machine is
| actually doing. Checklist if necessary. That puts you on
| a footing where you can actually outdo the computer in
| both realms.
|
| Or don't and be reminded once again of why being human is
| the most pitiable form of cognitive logic, where it takes
| hard work just to ensure a consistent response to similar
| classes of stimulus over time, and where remembering and
| recalling things is totally non-trivial. In the quest for
| staying alive in a dynamic world doing it's best to kill
| us, our brain does great. In a world in which it'd be
| nice not to be reminded by my equipment of my own idiocy
| on a regular basis, not do much.
| kodah wrote:
| A programmers view of code isn't exactly one to one with
| a filesystem though, so I don't think it's that
| programmers have trouble understanding filesystems.
| Instead, I think it's that many languages push us into
| particular paradigms of code organization. That
| filesystem now quickly reflects the programmers mental
| model of the application within the confines of the
| language. Often in those paradigms I find that there's
| layers to a single feature; for instance, it may be
| implemented via a hook that calls a controller that calls
| a service. Those layers exist to group code and to allow
| for future development, but they can also get confusing
| about what you're touching in large codebases.
| lordnacho wrote:
| What are the other categories?
| hdjjhhvvhga wrote:
| Well, although this RFC is probably a 4/1 joke, there is some
| truth in the first part: assumed we are talking about state-of-
| the-art open source project where many people can actually
| inspect the code and are interested to do so, with the amount
| of bugs _per LoC_ already found you decrease the chances of
| finding more bugs in the future provided that you don 't add
| new ones. This can be seen in projects considered "mature"
| where no new features are being implemented.
|
| Of course the second part is ridiculous: unless we are talking
| about a system formally proven to be bug free, which has
| enormous limitations, there always will be bugs.
| valw wrote:
| April fool's joke : we'll pretend that bugs in software are
| distributed as a homogeneous Poisson process, AND that Poisson
| distributions are bounded, while we're at it.
|
| Poisson d'avril!
| smrtinsert wrote:
| Finally, I've known about this for years.
| oaiey wrote:
| April 1st. Love it.
| ChrisMarshallNY wrote:
| Ah ... April The First ...
| xbar wrote:
| Got me.
| lkrubner wrote:
| Regarding this:
|
| " As an example of the detrimental effects of bugs in physically
| hard to reach systems: the [NASA] Deep Impact spacecraft
| [DEEPIMPACT] was rendered inoperable due to a fault in the fault-
| protection software, which in turn triggered endless computer
| reboots. Mission control was unable to recover the system from
| this error condition because no engineers were available on-site.
| The commute was deemed infeasible due to a lack of reasonably
| priced commercial transport options in that region of the solar
| system."
|
| I think this means that software bugs will be acceptable once
| there is low cost commercial transportation to every part of the
| solar system? Has a cost/benefit analysis been done to determine
| which option is cheaper, eliminating all software bugs versus
| introducing low cost commercial transportation to every part of
| the solar system? Is it possible that actively promoting the
| creation of bugs, while funding remediation efforts for those
| bugs, including all efforts but especially including low cost
| commercial transportation to every part of the solar system,
| would have side effects that would actually pay for the
| remediation efforts?
| logicallee wrote:
| Plainly, this document is the response to my complaint that my
| ability to make money from my art (poetry, music, etc) through
| Patreon supporters was improperly removed, similar to the closure
| of my Stripe account.
|
| The document is written as though it's just a joke like, haha, of
| course all software is going to have bugs, it's just a bug bro.
|
| This is false. Software generally doesn't have these kinds of
| bugs by the time it ships and gets to be the top service in its
| category.
|
| I am unhappy to read such a glib dismissal of serious, repeated
| issues that impact my ability to put food in my mouth. 0 out of
| 10.
| ganzuul wrote:
| Sorry to hear that you have had this experience, but a lot of
| us can use the levity right now.
| [deleted]
| hermitdev wrote:
| > Plainly, this document is the response to my complaint that
| my ability to make money from my art (poetry, music, etc)
| through Patreon supporters was improperly removed, similar to
| the closure of my Stripe account.
|
| I'm not sure how you arrive at this conclusion seeing as how
| none of the authors work for Patreon or Stripe.
|
| We're laughing at this because it's obvious satire and tongue-
| in-cheek, and we're laughing at ourselves. No one here that's a
| programmer strives to produce buggy code, quite the opposite.
| Frankly, your attack on programmers at large is quite offensive
| and unnecessary. We're fallible human beings, the same as you
| (unless you're a bot, but I'm assuming you're a person).
|
| I've personally been woken up overnight 3 times this week to
| address defects in code I support. Do you think I want that,
| enjoy it, or celebrate it? Of course not. My full time job is
| to make the software I work on better: more reliable, faster
| and use less computing resources to do the work.
|
| > I am unhappy to read such a glib dismissal of serious,
| repeated issues that impact my ability to put food in my mouth.
| 0 out of 10.
|
| No one here is dismissing _your_ issues.
| bee_rider wrote:
| Can the publication of a document which is very obvious be
| considered a sort of light joke? Is this an April Fools? This
| seems like the ideal sort of April Fools to be put in an RFC:
|
| * Harmless
|
| * Technically correct
|
| * Hypothetically I guess it might be useful to have a specific
| rule related to something obvious if you are arguing with a real
| super-pedant.
| maxbond wrote:
| Yes, there are April Fools RFCs every year, and they're usually
| pretty great.
|
| https://en.wikipedia.org/wiki/April_Fools%27_Day_Request_for...
|
| There are some other great ones like "TCP/IP over Carrier
| Pidgeon" and "Scenic IPv6 Routing"
| can16358p wrote:
| AFAIK there was an actual implementation of the IP over avian
| carriers that carried actual packets, with quite a few
| dropped ones.
| wongarsu wrote:
| Here's the writeup on that implementation: https://web.arch
| ive.org/web/20220401021424/https://www.blug....
|
| If you extend the protocol to support SD-cards instead of
| rolls of paper as the data medium, and appropriate frame
| and packet sizes, you can get phenomenal bandwidth even if
| latency and packet drop are still not great.
| Akronymus wrote:
| https://what-if.xkcd.com/31/ I got just the xkcd for
| that.
| formerly_proven wrote:
| Where I come from scenic IPv6 routing is the default, not an
| extra option.
| zerocrates wrote:
| It's definitely an April Fool's.
| ganzuul wrote:
| But is it though?
| smegsicle wrote:
| they post one every year, iirc
|
| one classic: A Standard for the Transmission of IP Datagrams on
| Avian Carriers
|
| https://datatracker.ietf.org/doc/html/rfc1149
| brian_herman wrote:
| I read that as avian flu carriers.
| imglorp wrote:
| Another good one that is totally harmless and entirely
| functional is 1149: IP over avian carriers.
|
| https://datatracker.ietf.org/doc/html/rfc1149
| a_shovel wrote:
| Software defects are _not_ harmful. Backwards long jumps are just
| a bounds-checking error, and without them, it would take over
| _five minutes_ to beat Super Mario 64. The A-Button Challenge
| wouldn 't be possible at all if it weren't for bugs. Bugs are an
| important part of the software ecosystem and should be included
| whenever necessary.
___________________________________________________________________
(page generated 2022-04-01 23:00 UTC)