On 11 Apr 2014, at 8:04, Achilleas Mantzios <achill@xxxxxxxxxxxxxxxxxxxxx> wrote: > Basically it goes beyond what ppl would describe as OS holly wars. > If one chooses to go by FreeBSD, then he better be prepared to handle the burden, both the part that is > imposed by the OS administration itself, as well as the part that is a side effect of the different base system. > > Example of admin part : > Generally, compiling postgresql from source gives more freedom than be stuck on the OS's ports or PKGng > system. (the later being a very handy and welcome addition to FreeBSD). > Now what if e.g. the user wants pgsql software X (e.g. pgadmin3, p5-Pg, etc...) only to find out that most of those > ports need postgresql client as a dependency. He/she must be prepared to work his way through : > - manual installations (gmake config && gmake && gmake install) > - /usr/ports > - PKG binary installations > in decreasing order of freedom but increasing order of easiness, and in many cases work through a combination > of the above. That argument holds for any package system on any OS I know of. Once you start custom compiling things outside the control of the package management system, you’re on your own. Custom compiling may give more freedom, but it’s hardly ever necessary on FreeBSD. For example, the only ports that I ever had to custom compile were ports for software I was developing, which of course no package management system can keep track of. In general, the various options the port Makefile provides for customisation are quite sufficient. It’s a plus to the ports system that you get any options at all. > Example of base system part : > Recently I had to install pl-java on my FreeBSD workstation. There was a problem with libtrh, postgresql should be recompiled > with explicitly setting : -lpthread in /usr/local/src/postgresql-9.3.4/src/backend/Makefile, without this the backend would simply hang > at the very first invocation of a java function. This came after detailed following or email exchange of various hackers groups > in both pgsql and FreeBSD lists, to describe the issue as accurately as possible, to help debug as most as possible, to talk > to the right people, to give them incentive to answer back, etc. It seems to me that the reason you were custom compiling Postgres in the first place was a problem with the port. I’m sure tracking down the problem wasn’t easy, but that is not really relevant to the topic. Ports break sometimes (on any OS) and it would have been sufficient to contact the port maintainer about the issue. For a quick (temporary) fix, you could probably have fixed the port by editing the port Makefile. With that, there’s no reason anymore to “custom compile” postgres and it leaves the dependency tracking of the port in place. Editing Makefiles is indeed not for everyone, but at least you _can_ do that on FreeBSD. Not every package management system will let you do that. And yes, I have edited Makefiles, although the need hasn’t risen recently. > I don't mean to scare the OP, but FreeBSD is not for everyone. And that (again) could be said about any OS. Even Windows or OS X. It depends on what you intend to use it for and what prior experience, preconceptions and expectations you might have. Oh, and please try not to top-post when replying on this list. > On 11/04/2014 00:50, Jan Wieck wrote: >> On 04/10/14 17:25, Christofer C. Bell wrote: >>> I'm not wanting to get after anyone here, but I want it on the record >>> that I am not the source of the above quote discouraging the use of >>> Ubuntu in a server role. That would be Bruce Momjian. While Bruce is >>> entitled to his opinion, it's not one I agree with and I don't want a >>> Google search years from now to tie my name to that viewpoint. >> >> Who (in their right mind) would ever think of anything but BSD in a server role? >> >> <shaking head> >> >> >> Jan Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
