Definitely that was a lot of "get off my lawn", but he might as well have been talking about Red Hat or Ubutu or Debian instead of the freebsd ports, because the Linux userland is *exactly the same source base as* the FreeBSD ports tree. And it has many of the same dependency hell problems.
From the outside looking in ( I haven't written Windows code since toy projects in high school ) it actually looks like Windows might have ended up getting more things right (except for their appalling filesystem semantics) than Linux did, because Linux grew by accretion and Windows was kinda sorta architected.
He conveniently leaves out all of the places where quality is present
because someone is paying attention to it, or even better, because
there are customers paying for it (Red Hat, Oracle, etc).
But see he wasn't talking about the freebsd ports tree, he was talking about the upstream sources that feed into that. And now you're coming along and saying "don't worry, Red Hat will put lipstick on it."
That sounds like "no one is worrying about quality control except for the people who are paid to be responsible for quality control."
The QA toons are paid to find bugs (can we pay them by the bug? I digress.) They are not paid to ensure quality in the sense he was talking about.
It is very good at what it was designed for, which is to pad salaries of ops.
Well yes, there is that. It pains me to see a bunch of paper tigers insisting that you need half a dozen servers to provide email to a group of 100 people, because that's what they were told was "best practice." And then it has regular outages and they all blame each other.
This is not an exaggeration; I speak from direct experience. The environment in question ran Citadel for nearly seven years without a single outage. So you have a system built by hobbyists in our spare time, with quality that greatly exceeds an expensive system built by thousands of highly paid developers and QA people.
So I'm going to come to a different conclusion. Quality happens when someone is thinking about quality. It happens when delivering something that works properly is held as a higher priority than delivering something that has an ever-growing feature set. I believe that this can happen in the cathedral or in the bazaar.
Wearing my pointy-haired toupee for the moment... part of my responsibilities are tending toward team lead these days. So I think: quality happens if you lecture the junior devs until their ears bleed. ( I try to be a bit nicer about this than it sounds. ) That's more cathedral than bazaar though.
Imagine that... me, responsible.
Heh... team lead... lead developer... we're all growing up.
As long as they're legitimate competition, I'm okay.
If their supposed to be on the same team, I need to find a smaller team.
Meh... I haven't had too many dealings with those types, because I don't get hired to work in environments like that. Possibly because I'm viewed as a threat.
It's nice to be important, but it's more important to be nice.
The more monitoring you have, the more trouble you find. If you don’t have monitoring, trouble finds you.
Splunk. Has worked very well for us.
Pricey, but when you don't have time to *design* something, you just throw a full-text search engine at your app logs.
I think we're starting to talk about a more open alternative?
I'll ask today. Remind me if I don't.
theres something like logstash, which I again instantly forgot about since its also done in some bizare language running in the java interperter.
logstash is one of the alternatives we were talking about, yes. I doubt we did a full evaluation yet.