5 ms·

Bryan Cantrill expresses this[1] in a manner I certainly agree with. Software that is designed/ intended to be reliable should not go through large periods of i

by gbrown_ 10y ago

Bryan Cantrill expresses this[1] in a manner I certainly agree with. Software that is designed/ intended to be reliable should not go through large periods of instability only to be written off as "prepubescence". [1]http://www.youtube.com/watch?v=79fvDDPaIoY&t=18m28s http://www.youtube.com/watch?v=79fvDDPaIoY&t=18m28s

cpeterso 10y ago
Bryan Cantrill is such a great storyteller. "My therapist says I need to talk about the firmware revision numbers, just to let it out so it doesn't corrode me." He then shares a story about a firmware bug where the polarity would be reversed of the disk read/write head. :)
- rdtsc 10y ago
  Completely agree. I often just search for videos by him and just listen to him present a topic or talk about anything. I learned about things normally I wouldn't go and read about otherwise -- history of Sun, ZFS, dtrace, containerization (Joyent, zones legacy, KVM, comparison with Docker). In that respect he is like David Beazley (of Python fame). I could just listen to David talk all day and not get tired of it.
rdtsc 10y ago
Ooh, like that analogy. Pure gold: (Paraphrasing): --- ZFS never went through a period where people lost data using it. ... amazing how people are willing to write that off like 'Oh well, it kind of lost my data but Omg! A million eyeballs'. This is like a 12 year old who is stealing cars -- this is a serious issue. Not like "Well...he's only 12" it is more like "He stole a car at gunpoint, having just robbed a liquor store". Can't say let's just wait till he's 18. Would you want to know what he's like when he's 18? ---
- makomk 10y ago
  Technically, ZFS never went through a period where people lost data using it. It just kernel paniced when they tried to access their data and besides it was probably their fault for using hardware that was slightly flaky. (Early ZFS adopters had a really interesting time of it, judging from the complaints people had back then.)
  - rdtsc 10y ago
    I am guessing in general losing data (overwriting, dropping it on the floor) is usually worse than crashing the system.
X86BSD 10y ago
See also: https://youtu.be/l6XQUciI-Sc?t=55m22s https://youtu.be/l6XQUciI-Sc?t=55m22s https://youtu.be/Ya6h2zKlpaQ?t=38m40s https://youtu.be/Ya6h2zKlpaQ?t=38m40s
- vidoc 10y ago
  About the first video talking about epoll design flaws, doesn't EPOLLONESHOT kind of solve this? Unless I am missing something..
  - X86BSD 10y ago
    Perhaps it does. But the point was that the Linux world never seems to get things right. They implement horrendous solutions that are not engineered or even well thought out and wind up reimplementing said solution over and over and over again to solve the problem instead of learning anything from others who have solved these problems already. They refuse to look outside their echo chamber and double down on NIH and just implement piss poor solutions to problems. And it's so frustrating for the rest of us to watch.
    - vidoc 10y ago
      > Perhaps it does. But the point was that the Linux world never seems to get things right. Well in this particular case, seems like this feature was added in linux 2.6.2 (2004). epoll itself was added in linux 2.5.44 (2002), so yep, you're correct that they didn't make this right immediately. Now I think it is rather easy to play this game of pinpointing flaws this way and it could be done the other way around, probably in an equally as unconstructive matter (e.g: how long did freebsd wait for robust mutexes?). That said, amazing speaker, thanks for the links.
      - X86BSD 10y ago
        Waiting to implement a feature while you actually engineer it well and robustly is not the same as throwing poop at a wall and seeing what sticks then scraping the poop off and forming it into another shape and throwing at the wall again.

by gbrown_ 10y ago

cpeterso 10y ago

Bryan Cantrill is such a great storyteller. "My therapist says I need to talk about the firmware revision numbers, just to let it out so it doesn't corrode me." He then shares a story about a firmware bug where the polarity would be reversed of the disk read/write head. :)

rdtsc 10y ago
Completely agree. I often just search for videos by him and just listen to him present a topic or talk about anything. I learned about things normally I wouldn't go and read about otherwise -- history of Sun, ZFS, dtrace, containerization (Joyent, zones legacy, KVM, comparison with Docker). In that respect he is like David Beazley (of Python fame). I could just listen to David talk all day and not get tired of it.

rdtsc 10y ago

Ooh, like that analogy. Pure gold: (Paraphrasing): --- ZFS never went through a period where people lost data using it. ... amazing how people are willing to write that off like 'Oh well, it kind of lost my data but Omg! A million eyeballs'. This is like a 12 year old who is stealing cars -- this is a serious issue. Not like "Well...he's only 12" it is more like "He stole a car at gunpoint, having just robbed a liquor store". Can't say let's just wait till he's 18. Would you want to know what he's like when he's 18? ---

makomk 10y ago
Technically, ZFS never went through a period where people lost data using it. It just kernel paniced when they tried to access their data and besides it was probably their fault for using hardware that was slightly flaky. (Early ZFS adopters had a really interesting time of it, judging from the complaints people had back then.)
- rdtsc 10y ago
  I am guessing in general losing data (overwriting, dropping it on the floor) is usually worse than crashing the system.

X86BSD 10y ago

See also: https://youtu.be/l6XQUciI-Sc?t=55m22s https://youtu.be/l6XQUciI-Sc?t=55m22s https://youtu.be/Ya6h2zKlpaQ?t=38m40s https://youtu.be/Ya6h2zKlpaQ?t=38m40s

vidoc 10y ago
About the first video talking about epoll design flaws, doesn't EPOLLONESHOT kind of solve this? Unless I am missing something..
- X86BSD 10y ago
  Perhaps it does. But the point was that the Linux world never seems to get things right. They implement horrendous solutions that are not engineered or even well thought out and wind up reimplementing said solution over and over and over again to solve the problem instead of learning anything from others who have solved these problems already. They refuse to look outside their echo chamber and double down on NIH and just implement piss poor solutions to problems. And it's so frustrating for the rest of us to watch.
  - vidoc 10y ago
    > Perhaps it does. But the point was that the Linux world never seems to get things right. Well in this particular case, seems like this feature was added in linux 2.6.2 (2004). epoll itself was added in linux 2.5.44 (2002), so yep, you're correct that they didn't make this right immediately. Now I think it is rather easy to play this game of pinpointing flaws this way and it could be done the other way around, probably in an equally as unconstructive matter (e.g: how long did freebsd wait for robust mutexes?). That said, amazing speaker, thanks for the links.
    - X86BSD 10y ago
      Waiting to implement a feature while you actually engineer it well and robustly is not the same as throwing poop at a wall and seeing what sticks then scraping the poop off and forming it into another shape and throwing at the wall again.