Date: Tue, 25 Mar 2014 13:14:06 -0700 (PDT) From: "Chris H" <bsd-lists@bsdforge.com> To: "freebsd-stable stable" <freebsd-stable@freebsd.org> Subject: Re: reason 23 why we've moved to linux Message-ID: <505f34fa64e336dbc9e0ea4154dd219b.authenticated@ultimatedns.net> In-Reply-To: <add6a8e4b80d1b643fb545fbb55e313a.authenticated@ultimatedns.net> References: <m2iorb1ms8.wl%randy@psg.com> <532EDDD0.80700@ohlste.in> <m2eh1spns4.wl%randy@psg.com> <532F6CDE.60105@tundraware.com> <add6a8e4b80d1b643fb545fbb55e313a.authenticated@ultimatedns.net>
next in thread | previous in thread | raw e-mail | index | archive | help
>> On 03/23/2014 05:12 PM, Randy Bush wrote: >>>> Now be honest Randy, and tell us why you started this thread. >>> >>> in the hope that ports will be made usable before so many people give up >>> that critical mass is lost. a real tragedy if the great freebsd core >>> dies because of ports lack of usability. >>> >> >> >> I have run production FreeBSD ever since 2.x. I also work in an environment >> with north of 1000 Linux servers (plus AIX, plus Solaris, plus Windows...) >> >> Guess what? There is no clear winner here. RHEL RPM is a nightmare >> unless you manage it very carefully. Yum make is better but you still >> have to pay attention. There's a reason RH strongly encourages the use >> of Sat Server. >> >> Debian? Well apt-get mostly works until it doesn't and you have to paw your >> way through key problems and the like. SuSE? Ditto. AIX lpps? >> Nice, until you confront a piece of open source they don't support or haven't >> upgraded. Have fun compiling your own version. >> >> Complex systems environments require complex procedures and policies. The idea >> that some technology magically will make this work is absurd. Moreover, >> unlike some random hobbyist desktop (Not That There's Anything Wrong With That), >> enterprise class server environments migrate carefully, thoughtfully, only >> after reasonable testing, and only if really needed. On that basis, I can >> assure you that the FreeBSD ports system isn't particularly "less usable" >> than any commercially supported environment out there and certainly not >> linux broadly. It comes down to what you're willing to do to execute >> clean, stable upgrades. > > The past experience you reference, I would consider an accurate assessment of > that of my own, over a ~25 year period. But that /past/ isn't the issue being > addressed in this post. The /present/ is. While I would never consider Lin* > as a possible alternative. Because it has too many "chiefs", which ultimately > results in never knowing what to expect in the near future, let alone long-term > affects/results. This is probably my primary reason for tracking FreeBSD all > these years. But here in recent months, things have changed. So much so, and > without any perceivable course -- oh yes, I hear all the claims/statements. > That I've felt compelled to consider other alternatives. I track -STABLE. I've > filed quite a few PR's. I've spent quite some time attempting to help the > maintainer(s) to squash some of them. I've provided actual cures, and patches. > Where the cure was simply to add NO_STAGE=(yes|true). I was told that that > wasn't a cure, and that I needed to "upgrade" to the new pkg(8) system. Ahem. > I'm tracking -STABLE, in this case, it meant 8.4-STABLE. If I'm not mistaken, > 8-STABLE is supported till June 30, 2015. If I'm also not mistaken, 8-STABLE > comes with/uses the pkg_ system. Fact is, many are tracking 8-STABLE for just > this reason; without "deep pockets", and wealthy benefactors, this gives > them the opportunity to re-tool for the new pkg system, or see if pkg(8) > ever actually "pans out", and if it does, what it looks like in the end. > That's what "stable" is all about. One other example; I had a couple of > builds that each required graphics/gimp. I was unable to install it on the > first one, because graphics/libopenraw failed to build against devel/libboost. > I filed a pr(1), and noticed there was also another outstanding for 3mos. > The second install was a month later -- same issue, but newer r#. So I took > the time to "wind back" through the revs, until I found a revision where > graphics/libopenraw would build. Then took the time to file another pr(1), > indicating the issue, /and/ providing the solution. > One week later, I received notice that the 2 pr's I'd filed had been closed. > Reason being; they were too similar to the previous one. What?! Forget the > fact I'd just spent a boat load of time I /didn't/ have, to find a solution > to the problem. But totally disregard the solution?! Did they actually /read/ > the pr's? Or were they just looking to make the pr count look better? > But the "kicker" for me was the new "EOL" announcement for pkg-tools: > pkg_install EOL is scheduled for 2014-09-01. Please consider migrating to pkgng > go see Joe blogger, for more info... > For starters, tracking 8.4, means you get pkg-tools, not pkg(8). While pkg(8) > /may/ turn out to be the best thing, since "sliced bread". For reasons > stated earlier, it should not be /forced/ upon those who track 8-STABLE, and > /certainly/ not, until June 30, 2015. After which, the whole point becomes > pretty much moot. The initial message has a pause/sleep timer. Indicating > that placing: > NO_WARNING_PKG_INSTALL_EOL=yes > in make.conf(5) will eliminate further warnings. However, such is not the case. > New installs, or largish upgrades, require being spammed some 1000 times with > this message to go visit Joe blogger. Rubbish! This speaks to the point I had > intended to make, by this reply. IMHO, it shows a terrible short-sighted view > that appears to be affecting FreeBSD in the past few months. There appears to > be too much strain on those that oversee the project. In the ~25yrs I've been > tracking, I have /never/ seen so many oversights. So little thought to the > "big picture", long-term affect(s). I may be off in my perception. But I > can't make sense of it, any other way. > >> >> In truth, in almost 2 decades of use both in my own business and by some of >> my clients, FreeBSD has shown far less aggravation in this regard than the >> Tower Of Babel linux distros have become. Me? I don't much care. The more >> screwed up things are, the more opportunities for additional work I find :) > > I couldn't agree more. I /loved/ Micro$oft for this. They were a /huge/ > money-maker, in this regard. However, I could never wish FreeBSD, with a > strategy like this. > > Thank you for your indigents, Ahem... that was to read indulgence _________________________^^^^^^^^^^ > and sorry if this comes off as a "rant" > (not intended). > > --Chris > >> >> >> >> ---------------------------------------------------------------------------- >> Tim Daneliuk tundra@tundraware.com >> PGP Key: http://www.tundraware.com/PGP/ >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?505f34fa64e336dbc9e0ea4154dd219b.authenticated>