Date: Tue, 12 Aug 2008 16:22:47 +0200 From: "Adrian Penisoara" <ady@freebsd.ady.ro> To: "Stefan Lambrev" <stefan.lambrev@moneybookers.com> Cc: freebsd-hackers@freebsd.org, freebsd-rc@freebsd.org, wbentley@futurecis.com Subject: Re: Idea for FreeBSD Message-ID: <78cb3d3f0808120722t461bfb56x4782899811cf63f0@mail.gmail.com> In-Reply-To: <48A183D0.6070901@moneybookers.com> References: <78086795e6ab9676870368dcebb57b37.squirrel@secure.futurecis.com> <78cb3d3f0808120503t3e2c7d68n1d4383c98aa41e10@mail.gmail.com> <48A183D0.6070901@moneybookers.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Tue, Aug 12, 2008 at 2:36 PM, Stefan Lambrev <stefan.lambrev@moneybookers.com> wrote: >>> >>> First let me reiterate a few things. I started in FreeBSD and it will >>> always be my first love. Second, keep in mind that Solaris is a >>> commercial >>> product and must be viewed as such. >>> >> >> Good point. Like it happened in the Linux world, we should also have >> some commercially backed versions of [Free]BSD in order to get better >> visibility and business support (which, in the end, counts a lot). >> That's why I've been thinking for some time about starting up the >> EnterpriseBSD project (see http://launchpad.net/enterprisebsd). I >> believe PC-BSD is a good start for the desktop. >> > > There is commercial support for FreeBSD out there. > Actually the problem is that misinformed people are still spreading the lie > that there is not... OK, I will reword that a bit: I believe having also a "business" face for the business market will help a lot in increasing visibility. > > Also the example with Linux is very bad, where you have a "stable" version > only in enterprise RH or SuSe > and the vanilla kernel is only for development and beta testing .. I do not > want to see this happens to FreeBSD 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. >> 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 "<svc>_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. >>> I think a drop-in command like "rcadm" (someone mentioned this as an >>> idea, >>> but cant remember who) would be a good start for managing the states of >>> services. Mike Meyer also brought up many good points that I agree with. >>> Please try not to get caught up in the XML stuff, that is not a >>> requirement or suggestion, it is just an example of how Sun did it, now >>> how FreeBSD has to;) >>> >>> Someone recommended Puppet, but this is an entire framework that would >>> have to be added/implemented and configured to work with FreeBSD as well >>> as learning a new markup language for it. launchd has a lot of good >>> ideas, >>> but I am not sure how mature it is yet; maybe it is a good place to >>> start. >>> >> >> Let's put another name on the table: Upstart (upstart.ubuntu.com). >> It's quite fast. >> > > Some of us use FreeBSD because we think this is the proper way things to be > done, if we want another linux distro we may switch to *buntu .. Oh, we are debating here, not imposing personal preferences :). Good ideas can come up from any direction, it's up to us whether we want to learn from them. >>> If we start with the basics and break it down and program this from a >>> modular standpoint it is not so bad. Begin with the basic (high-level) >>> approach. A shell script (service) that is aware of where rc scripts are >>> located and that can keep track of what the current state of the services >>> (PID's) are. An enable/disable command is nothing more that throwing a >>> start/stop command to these rc files. The rc.conf can assist with knowing >>> what should be enabled/disabled and what flags to throw at it. For >>> EXAMPLE!!!!, (you got that, example only) Solaris uses one master service >>> that is started first, and the whole point of that first service is to >>> monitor the other services and know what state they are in and starts >>> dependent services upon boot. Consider it the service manager almost. >>> >> >> That would very important to for service crash recovery, to keep >> critical services running. >> > > Looks like we are reinventing inetd ? Inetd is only for multiplexing seldomly used network services bound to specific ports -- not too many real-life services fall under this exact specification. >> >> Side note:what about starting up and monitoring services in jails, >> probably we'd need one such master service per jail ? >> > > Like inetd running in jail ? >> >> My 5cents, >> > > Overpriced ;) and good luck with enterprisebsd Well, that was usually conceived as a contribution, not a price. Ideas are free anyway ;). Thanks. Adrian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?78cb3d3f0808120722t461bfb56x4782899811cf63f0>