Date: Sun, 23 Mar 2014 15:23:05 -0400 From: Jim Ohlstein <jim@ohlste.in> To: Daniel Corbe <corbe@corbe.net> Cc: Randy Bush <randy@psg.com>, Mark Linimon <linimon@lonesome.com>, freebsd-stable stable <freebsd-stable@freebsd.org> Subject: Re: reason 23 why we've moved to linux Message-ID: <532F3499.4040407@ohlste.in> In-Reply-To: <ygflhw0zrjd.fsf@corbe.net> References: <m2iorb1ms8.wl%randy@psg.com> <532EDDD0.80700@ohlste.in> <20140323153843.GA16935@lonesome.com> <532F1C48.7080003@ohlste.in> <ygflhw0zrjd.fsf@corbe.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, On 3/23/14, 2:41 PM, Daniel Corbe wrote: > Jim Ohlstein <jim@ohlste.in> writes: > >> Hello Mark, >> >> On 3/23/14, 11:38 AM, Mark Linimon wrote: >>> On Sun, Mar 23, 2014 at 09:12:48AM -0400, Jim Ohlstein wrote: >>>> last I checked there were over 1500 active ports related PR's alone. >>> >>> Current count is 1851. See http://portsmon.freebsd.org/portsoverall.py . >>> >>> The whole list is at: >>> >>> http://portsmon.freebsd.org/portsprsbyexplanation.py?explanation=existing&sortby=prnumber&reverse . >>> >>> I did a little rough data reduction for curiosity about changes related >>> to "new infra": >>> >>> % grep -i clang foo | wc -l >>> 32 >>> % grep -i stage foo | wc -l >>> 37 >>> % grep -i staging foo | wc -l >>> 31 >>> % grep -i options foo | wc -l >>> 31 >>> % grep -i cflags foo | wc -l >>> 5 >>> % grep USE_ foo | wc -l >>> 22 >>> % grep WITH_ foo | wc -l >>> 19 >>> >>> as opposed to: >>> >>> % grep -i update foo | wc -l >>> 280 >>> >>> NB: I didn't check for overlaps. >>> >>> I was expected to see more "new infra" changes than 200. >>> >>> I will note that about a third of the PRs are from the last 3 months. >>> I no longer have an insight into how fast PRs are turned over but it >>> is quite brisk. >>> >>> mcl >>> >> >> Thanks for your response. I don't think that tells the whole story. >> >> How many PR's contain "broken" or "broken on 10" or "break" or "build" >> or similar? Another few I'm sure. Updates are important too. Many of >> us look forward to new features not to mention important security >> fixes. The only ones which may not be "urgent" or "important" are the >> new port proposals of which I counted 181. (I have a few in there and >> I am waiting patiently. I spent quite a few hours working on a port of >> MonetDB which sits there untaken. Maybe it sucks but I'd like >> feedback/help if needed. I have others for which I directly approached >> a committer whom I like and respect since he maintains similar ports, >> and was told he's too busy.) >> >> I'm not trying to make this more a bitch-fest than it is, but I'll >> point out the obvious that if a third of PR's are from the last three >> months, that means two thirds are older than three months! I don't >> find that to be "quite brisk". If the ratio were reversed it I might >> be inclined to agree. >> >> My point however, perhaps was missed. While I did squawk that the new >> pkg system is in a state of flux and therefore not appropriate for >> sole use on 10, I was separately mentioning the glacial pace at which >> ports related PR's get looked at, taken, and committed. There is no >> obvious triage system. It's simply if someone is "interested" they >> take the PR. If no one is interested, it sits. Imagine if a hospital >> emergency department functioned that way. A gunshot wound might sit in >> the waiting room because seeing a case of strep throat would be less >> work, or a laceration needing sutures might be more fun. And one case >> of strep throat might sit six hours while another waited only 30 >> minutes because it was up to the doctors and nurses to decide who they >> wanted to see and when, not based on any system of necessity, urgency >> or how long a problem has been waiting. >> >> In the current system, if there is a maintainer, s/he may not answer a >> PR for months, even if that person is a FreeBSD committer. If ports >> don't build, that *is* a big issue because pretty much everyone uses >> them. With two thirds of ports related PR's over three months old, >> updating your system is a crapshoot at best. > > How many of these PRs contain remotely exploitable security > vulnerabilities? Of which, how many of these ports do you use on a > regular basis? I don't know. There's no obvious way to tell. > > You like to talk about "triage" like the very existence of a bug in the > ports tree is a show stopper. To use your example, context actually > means a great deal in an emergency room. You would treat that gunshot > wound victim before you would treat the 1500 other patients in your > waiting room with self-inflicted bruises sprains and muscle pulls. Wow, something got the hair on your neck up. This is my point exactly. In an ER they would take the most serious first (and sometimes gunshots are through and through and not all that critical), and then the non-serious *in order*, or at least reasonably so, not by a willy nilly "I'll take this" system. That way the pretty girl with strep throat who's been waiting only 30 minutes doesn't get seen ahead of the smelly homeless old guy with leg ulcers who's been waiting six hours. Ports PR's are mostly non-urgent. Triage out the urgent and get them done. The rest should be handled in order, not by an "I'll take this" system. > > There's a finite amount of people available to respond to PRs. They do > a pretty good job of maintaining the ports that are most often used. I don't disagree that it's "pretty good". Again, context. I raised a series of concerns, and this was but one of them. Try building KDE-4 and tell me how that goes. I have a laptop that had a functional KDE-4. Sadly I tried a binary upgrade. Left X unusable. Then I tried compiling from source. Multiple ports failed. Finally backed up the laptop, reinstalled 10.0-RELEASE and used the included packages. That works but I'm left with outdated software. Not a huge issue, but certainly could be seen as a barrier to adoption. > > It's been almost a decade since I've had a FreeBSD box fall victim to a > remote exploit. By contrast, I constantly struggle to keep the > vendor-supplied linux boxes on my network from being broken into. Like I said earlier, FreeBSD is the worst system, except for everything else out there. I use GNU/linux only when I have to do so, and never by choice. > > And if you're really so worried about corner cases, perhaps a more > pro-active approach to security is required. After all, it really isn't > that much more work to maintain a software package from source than it > is to constantly scan and run binary upgrades. That's exactly what I do on network servers. I have my own repository and build with poudriere (poudriere *is* the shining star of the new packaging system, and I will shout that from the rooftops). When I see a security release that's based on a verified vulnerability, I don't wait for the maintainer. I edit the Makefile, run "make makesum" and upgrade. Nice chatting. Peace out. -- Jim Ohlstein "Never argue with a fool, onlookers may not be able to tell the difference." - Mark Twain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?532F3499.4040407>