4 ms·

That sounds like an excuse which I don't accept. I have a formal engineering background and whilst you're fundamentally right, engineering is based upon cumulat

That sounds like an excuse which I don't accept. I have a formal engineering background and whilst you're fundamentally right, engineering is based upon cumulative experience gained. We have a hell of a lot of experience as a society of writing software that works and is of merchantable quality. What the general state of affairs shows is the following traits: 1) There is no thought and research going into the design of a piece of software. Ergo, we do not learn from past mistakes. 2) There are isolated individuals writing vast swathes of software which are trusted unconditionally. Ergo, we do not learn the benefit of multiple eyes on a problem, review and discussion. 3) We assume that software is correct from one person's viewpoint and opinion. Ergo, we do not test software properly nor cover those tests with objectives. 4) We work to deadlines, not quality objectives. Ergo, we trade quality for tolerance from others. In this case someone came along and didn't think about the problem, didn't work with others, assumed they were unconditionally correct and chose tolerance over quality. To use your analogy, they're now selling stainless steel lightning rods (poor conductivity), are the only vendor of them, are a vocal marketing front and houses are catching fire everywhere. Or more specifically, in one example, the entire process was above and from the author to the distributor, no one even noticed that loginctl doesn't work properly.

moron4hire 12y ago
Wait, so let me get this straight. You're an engineer-engineer, not a system administrator or a software developer. And you think there is a fundamental problem of qualification in software development, yet you lack qualification in software development. On your points: #1 is patently false, to the point of being extremely insulting. You've lost all sympathy from me at this point. Go peddle your baseless opinions somewhere the audience doesn't know better. #2 is also laughably false, as that is the entire freaking point of open source and often considered the greatest strength of Linux. You think because your highly qualified opinion wasn't consulted before you had to spend a whole four hours, OMG on a problem that means that no review or discussion was done? #3 is false again, because software is tested. You use the word "properly", so I will sit here and wait for you to bestow upon us your great wisdom on what we could be doing better. #4 is false on both presumptions that software is not built to quality standards instead of deadlines, or that other fields are not dictated by deadlines.
- badgersandjam 12y ago
  10 years in EE (embedded systems, defense industry), then 15 in what we now call devops/architecture. Experience is fine. I have no problems being arrogant about that. I've fallen down a lot more holes than a lot of people and know what I'm talking about. When I say tested properly, I mean tested completely. If you miss an entire functional unit of the software and a client reports it as broken, its pretty obvious what the problem is. Our senior software guys sat down for the other four hours and presented all our findings together and cumulatively said "we're not supporting that shit; we can't trust it". Regarding #4, it's plain to see that RHEl was released with a broken systemd implementation due to deadline...
  - vdaniuk 12y ago
    > When I say tested properly, I mean tested completely. I am still in the learning phase, but even I know that complete testing of any complex software is practically impossible. So, how do you guarantee completedness in "proper" testing? I know you can't without redefining the word "completely". What's your definition? Also see Impossibility of Complete Testing[0] by Cem Kanen, co-founder of http://www.associationforsoftwaretesting.org/ http://www.associationforsoftwaretesting.org/ [0] http://kaner.com/pdfs/impossible.pdf http://kaner.com/pdfs/impossible.pdf
    - badgersandjam 12y ago
      Yes you're right. When your system consists of functions "A, B, C, D", I'd expect to see test suites for "A, B, C, D". In this case there were test suites for "A, B, C". The client found D therefore the test suite was incomplete. Now if a bit of A, B, C or D suites were missing that would be different and entirely expected.
    - nitrogen 12y ago
      You should at least be testing the happy path and most common failure mode of every component of a software system, whether manually or automatically. The most visible components to the user should be tested most. Imagine an ecommerce site where nobody ever tested checkout, or an OS where nobody tested logging in.
jmnicolas 12y ago
It seems to me that OpenBSD stands for everything you want in OS dev, except maybe point 3, Theo seems really at the center of everything.
- badgersandjam 12y ago
  You're 100% correct. In fact my own mail server/web machine uses it. Theo is not right at the centre; there's a large group of people who work together as equals from what I can see. I can't recommend it for our "enterprise use" though because we need some of the more friendly features that FreeBSD offers such as ZFS.
  - protomyth 12y ago
    I run a mixed environment right now with OpenBSD, FreeBSD, Red Hat, and Windows. I use Red Hat and Windows because certain software requires it (basically they are single app servers[1]). The OpenBSD servers are all doing basic utilities and the FreeBSD servers are doing stuff the requires a big file system (ZFS). There are a lot of enterprise tasks that OpenBSD is fine with doing, and I just use FreeBSD for tasks that require the file system or really heavy load. 1) government contractors are so fun when they get their software required to deal with certain parts of government

moron4hire 12y ago

Wait, so let me get this straight. You're an engineer-engineer, not a system administrator or a software developer. And you think there is a fundamental problem of qualification in software development, yet you lack qualification in software development. On your points: #1 is patently false, to the point of being extremely insulting. You've lost all sympathy from me at this point. Go peddle your baseless opinions somewhere the audience doesn't know better. #2 is also laughably false, as that is the entire freaking point of open source and often considered the greatest strength of Linux. You think because your highly qualified opinion wasn't consulted before you had to spend a whole four hours, OMG on a problem that means that no review or discussion was done? #3 is false again, because software is tested. You use the word "properly", so I will sit here and wait for you to bestow upon us your great wisdom on what we could be doing better. #4 is false on both presumptions that software is not built to quality standards instead of deadlines, or that other fields are not dictated by deadlines.

badgersandjam 12y ago
10 years in EE (embedded systems, defense industry), then 15 in what we now call devops/architecture. Experience is fine. I have no problems being arrogant about that. I've fallen down a lot more holes than a lot of people and know what I'm talking about. When I say tested properly, I mean tested completely. If you miss an entire functional unit of the software and a client reports it as broken, its pretty obvious what the problem is. Our senior software guys sat down for the other four hours and presented all our findings together and cumulatively said "we're not supporting that shit; we can't trust it". Regarding #4, it's plain to see that RHEl was released with a broken systemd implementation due to deadline...
- vdaniuk 12y ago
  > When I say tested properly, I mean tested completely. I am still in the learning phase, but even I know that complete testing of any complex software is practically impossible. So, how do you guarantee completedness in "proper" testing? I know you can't without redefining the word "completely". What's your definition? Also see Impossibility of Complete Testing[0] by Cem Kanen, co-founder of http://www.associationforsoftwaretesting.org/ http://www.associationforsoftwaretesting.org/ [0] http://kaner.com/pdfs/impossible.pdf http://kaner.com/pdfs/impossible.pdf
  - badgersandjam 12y ago
    Yes you're right. When your system consists of functions "A, B, C, D", I'd expect to see test suites for "A, B, C, D". In this case there were test suites for "A, B, C". The client found D therefore the test suite was incomplete. Now if a bit of A, B, C or D suites were missing that would be different and entirely expected.
  - nitrogen 12y ago
    You should at least be testing the happy path and most common failure mode of every component of a software system, whether manually or automatically. The most visible components to the user should be tested most. Imagine an ecommerce site where nobody ever tested checkout, or an OS where nobody tested logging in.

jmnicolas 12y ago

It seems to me that OpenBSD stands for everything you want in OS dev, except maybe point 3, Theo seems really at the center of everything.

badgersandjam 12y ago
You're 100% correct. In fact my own mail server/web machine uses it. Theo is not right at the centre; there's a large group of people who work together as equals from what I can see. I can't recommend it for our "enterprise use" though because we need some of the more friendly features that FreeBSD offers such as ZFS.
- protomyth 12y ago
  I run a mixed environment right now with OpenBSD, FreeBSD, Red Hat, and Windows. I use Red Hat and Windows because certain software requires it (basically they are single app servers[1]). The OpenBSD servers are all doing basic utilities and the FreeBSD servers are doing stuff the requires a big file system (ZFS). There are a lot of enterprise tasks that OpenBSD is fine with doing, and I just use FreeBSD for tasks that require the file system or really heavy load. 1) government contractors are so fun when they get their software required to deal with certain parts of government