From owner-freebsd-hackers@FreeBSD.ORG Tue Aug 12 15:10:23 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43BD21065676 for ; Tue, 12 Aug 2008 15:10:23 +0000 (UTC) (envelope-from ady@ady.ro) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by mx1.freebsd.org (Postfix) with ESMTP id 31D488FC1A for ; Tue, 12 Aug 2008 15:10:23 +0000 (UTC) (envelope-from ady@ady.ro) Received: by wf-out-1314.google.com with SMTP id 24so2160870wfg.7 for ; Tue, 12 Aug 2008 08:10:22 -0700 (PDT) Received: by 10.142.213.9 with SMTP id l9mr2763275wfg.2.1218553822695; Tue, 12 Aug 2008 08:10:22 -0700 (PDT) Received: by 10.142.80.3 with HTTP; Tue, 12 Aug 2008 08:10:22 -0700 (PDT) Message-ID: <78cb3d3f0808120810o54f49373n69ac5076c9a9c9b7@mail.gmail.com> Date: Tue, 12 Aug 2008 17:10:22 +0200 From: "Adrian Penisoara" Sender: ady@ady.ro To: "Stefan Lambrev" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 49ffd9cf49c91147 Cc: freebsd-hackers@freebsd.org, wbentley@futurecis.com Subject: FreeBSD in Business (was Re: Idea for FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2008 15:10:23 -0000 Hi, On Tue, Aug 12, 2008 at 4:52 PM, Stefan Lambrev wrote: >> I'm not sure where is that remark headed to. And I don't think >> (re)packaging a business-centric version would harm -- please correct >> me if I'm wrong. >> > > The problem with "enterprise" is that they ship their own kernel which is > heavily modified. Not one, but rather multiple kernels (which includes the generic one). Which otherwise are possible to build with the vanilla distro, but it might take a lot of tweaking time to get there and you got no QA for that either. > If you want enterprise go for OSX :) I think it's the best enterprise BSDish > system ;) Why not help the people already using FreeBSD at their workplace get better arguments to keep and grow the FreeBSD base ? ;) > Also there are more packages for FreeBSD available then for RH, and I can > assure you that > all programs that you actually use (like ssh, apache, perl and etc) you have > to manually compile to fit your needs. I tend to disagree in this particular context -- business usage relies on stability which implies a small set of very well tested packages, not necessarily the latest version. >> >> >>>> >>>> While we're at it, I wish we could leverage the posibility for the >>>> admin to manually start the service at the CLI, no matter whether the >>>> service has been enabled or not -- that is the "_enable" keyword >>>> should have effect only in the bootup/automatic contexts. >>>> >>>> >>> >>> Like keywords - forcestart forcerestart forcestop ?!?! >>> >> >> Yes, I am always reminded of that :). >> Well, to tell you the truth, I do not know of any other OS which >> requires prefixing with "force" the start/stop actions in order to act >> on the service at the command line, and personally I wish it weren't >> the case. >> > > Well I bet you can find this in most linux distros that copy FreeBSD. What > about gentoo? Umm, I have used Gentoo and I do not remember having to use "forcestart" at the command line... > Anyway I think that the beauty of the current rc/ng system in freebsd is > that it's very easy to understand and use it. > Not like those nasty XML config files that makes you blind. > There are small fixes that can be applied to make the system even better, > but rewriting it just for the sport looks like wasting too much power :) > But after all FreeBSD innovate do not imitate ;) > > Anyway it's may be just me, but I do not think that the rc system in freebsd > is the showstopper, that needs funding or more ppl looking at it. Right. And I'm going to stop here -- if you want to continue we can go off-the-list. > And btw burdening the rc subsystem to monitor your daemons is overkill too. > It will never work as good as real monitoring software, > and will only bloat things. There are tons of utilities that can do this. Umm, one should not need huge monitoring software packages to accomplish such (simple?) tasks. The inittab/ttys systems comes to my mind when I say this... ;). Over & out, Adrian.