Date: Tue, 25 Mar 2014 11:47:49 -0700 (PDT) From: "Chris H" <bsd-lists@bsdforge.com> To: "Tim Daneliuk" <tundra@tundraware.com> Cc: freebsd-stable stable <freebsd-stable@freebsd.org> Subject: Re: reason 23 why we've moved to linux Message-ID: <add6a8e4b80d1b643fb545fbb55e313a.authenticated@ultimatedns.net> In-Reply-To: <532F6CDE.60105@tundraware.com> References: <m2iorb1ms8.wl%randy@psg.com> <532EDDD0.80700@ohlste.in> <m2eh1spns4.wl%randy@psg.com> <532F6CDE.60105@tundraware.com>
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, 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?add6a8e4b80d1b643fb545fbb55e313a.authenticated>