| mike.h on Tue, 11 Mar 2003 10:33:09 -0500 |
|
On Tue, 2003-03-11 at 07:27, Michael Bevilacqua wrote: > On Tue, Mar 11, 2003 at 06:57:44AM -0800, Wayne Dawson wrote: <snip> > > I thought perhaps services are always processes that run whenever the > > system is running, but that doesn't appear to be the case. > > If setup correctly that is the case. <snip> Actually, no it isn't. Some "services" will be started by xinetd when a connection attempt is made. su to root and run /sbin/chkconfig --list to see which are configured.For more use info or see man 8 inetd man 5 xinetd.conf Also some "services" can be run at boot, then terminate and do not stay resident.(eg. kudzu) Of course, this begs the question originally asked, "what's a service?" Perhaps the best answer is that it's a symptom of Redhat's strategic decision to be as Windows-like as possible, presumably to make the transition to Linux easier for Windows users. In the NT/2000 world Microsoft calls them "services" not daemons, so Redhat has followed suit. But "daemon" has a different meaning, or used to anyway, it meant a process that ran in the background without user interaction. So, it's clear that kudzu is a daemon, but not clear why it's a "service". This exemplifies why slavish imitation of Microsoft can irritate seasoned Linux/Unix users and just cause additional confusion for the newbe. In general, I approve of Redhat's initiative with v.8. At least so far as the desktop is concerned, my experience is that "bluecurve" is more quickly understood by users used to Windows. There are some things that Microsoft does quite well, and it would be great to see in Linux, but some things just don't make sense and this is one example. -- -mike.h _________________ mike.h@acm.org mike.h@stemik.com __________________________________________ Democracy is the worst form of government; except for all those other forms that have been tried from time to time. -Winston Churchill __________________________________________ GnuPG public key: //http://www.stemik.com/~mike.h/mike.h.asc Attachment:
signature.asc
|
|