3 ms·

This has gotta be the most bullshit justification for writing bad kernel code that will be reviewed and tested by 200 people before it reaches production. Liter

This has gotta be the most bullshit justification for writing bad kernel code that will be reviewed and tested by 200 people before it reaches production. Literally anything written as low level as this has the potential to crash the system on a dime and needs to be thoroughly tested.

astrange 3y ago
Old code in BSD wasn't thoroughly tested except by virtue of being old; there's no QA department and traditionally UNIX code was tested by thinking about it really hard rather than automated testing. (FreeBSD got a test suite in 10.1, which came out in 2014, not that long ago in UNIX terms.)
- oblio 3y ago
  Not just in BSD... GNU wasn't much better. People would be shocked by how little the core tools we use were tested automatically. Some still aren't.
  - Quekid5 3y ago
    Quite. Thankfully the practice of just randomly shelling out to 'random' programs (like the core tools) has been stemmed somewhat, so perhaps we're mostly safe from RCE via that vector. Downloaded files might still be a vector, tho. Maybe I'm an optimist even though I sound very pessimistic.
Quekid5 3y ago
If your testing infrastructure is so anemic that a sorting algorithm (of all things) is hard to subject to e.g. property-based/fuzzing tests then it'd probably be worth it to expand that before doing anything else. I dunno what FreeBSD's test infrastructure is, but I'm just saying that "it needs testing" is not a good reason not to change to a better sort algorithm in this case.
- kragen 3y ago
  if only the people working on bsd in 01993 had had access to your wisdom, think how much more successful they would have been
  - Quekid5 3y ago
    This is about changing the sorting algoritm. No snark needed. It should be trivial to add a test for the current algorithm (whenever it was introduced) and to replace it afterwards. Heck, even keep running both for bisimulation testing.
    - kragen 3y ago
      probably colin was more interested in booting faster than in improving testing infrastructure if your interests run the other way, that's great, and hopefully you will succeed in improving freebsd's testing infrastructure, but it's hardly a reason for colin not to speed up booting but i don't think i saw anyone claiming that the change should not be made because it wouldn't be adequately tested?
      - Quekid5 3y ago
        I don't think you fully read the post I was replying to. I was just saying that that poster's argument against changing the sorting algorithm was misguided. Quote: > will be reviewed and tested by 200 people before it reaches production I was only saying that this is a bad argument for changing to any simple-ish sorting algorithm. (Because: add tests if you need assurance) Granted, if you're doing super-complicated sorting algos with fallbacks for different sizes, heuristics for detecting semi-sorted input, etc. you might want something more sophisticated than trivial property-based checking.
        kragen 3y ago
        i read that as an argument against having done it that way 30 years ago, not against changing it
deleted 3y ago
[deleted]

astrange 3y ago

Old code in BSD wasn't thoroughly tested except by virtue of being old; there's no QA department and traditionally UNIX code was tested by thinking about it really hard rather than automated testing. (FreeBSD got a test suite in 10.1, which came out in 2014, not that long ago in UNIX terms.)

oblio 3y ago
Not just in BSD... GNU wasn't much better. People would be shocked by how little the core tools we use were tested automatically. Some still aren't.
- Quekid5 3y ago
  Quite. Thankfully the practice of just randomly shelling out to 'random' programs (like the core tools) has been stemmed somewhat, so perhaps we're mostly safe from RCE via that vector. Downloaded files might still be a vector, tho. Maybe I'm an optimist even though I sound very pessimistic.

Quekid5 3y ago

If your testing infrastructure is so anemic that a sorting algorithm (of all things) is hard to subject to e.g. property-based/fuzzing tests then it'd probably be worth it to expand that before doing anything else. I dunno what FreeBSD's test infrastructure is, but I'm just saying that "it needs testing" is not a good reason not to change to a better sort algorithm in this case.

kragen 3y ago
if only the people working on bsd in 01993 had had access to your wisdom, think how much more successful they would have been
- Quekid5 3y ago
  This is about changing the sorting algoritm. No snark needed. It should be trivial to add a test for the current algorithm (whenever it was introduced) and to replace it afterwards. Heck, even keep running both for bisimulation testing.
  - kragen 3y ago
    probably colin was more interested in booting faster than in improving testing infrastructure if your interests run the other way, that's great, and hopefully you will succeed in improving freebsd's testing infrastructure, but it's hardly a reason for colin not to speed up booting but i don't think i saw anyone claiming that the change should not be made because it wouldn't be adequately tested?
    - Quekid5 3y ago
      I don't think you fully read the post I was replying to. I was just saying that that poster's argument against changing the sorting algorithm was misguided. Quote: > will be reviewed and tested by 200 people before it reaches production I was only saying that this is a bad argument for changing to any simple-ish sorting algorithm. (Because: add tests if you need assurance) Granted, if you're doing super-complicated sorting algos with fallbacks for different sizes, heuristics for detecting semi-sorted input, etc. you might want something more sophisticated than trivial property-based checking.
      - kragen 3y ago
        i read that as an argument against having done it that way 30 years ago, not against changing it

deleted 3y ago

[deleted]