Linux s:user-startup

[murple]

.d does not mean daemon... you'll notice plenty of non-daemon .d directories such as php.d or yum.repos.d or profile.d... I dont know what it stands for (if anything at all) but it essentially means a subdirectory where certain similar configs (or subconfigs) are found. For example under /etc/rc.d you find directories for each runlevel configuration (rc).

You will not learn to use Linux by just messing around. At least, you will learn very slowly (as in years) and will get many things only partially right. Linux is, like any other unix, a very complex and powerful operating system. You need to read some manuals.

I *strongly* recommend (as in, if you dont, chances are you will give up in frustration) that you read some of the free online books at: http://tldp.org/guides.html

At the very least look at "Introduction to Linux"... but several of these will make your life MUCH easier.

There are several great print books too, a good start is the book "Running Linux" published by O'Reilly (see www.ora.com)

As for the original question, /etc contains most system-wide configuration and startup scripts. There can be other user-specific configs in your home directory.

[murple]

The directoru should also be in your root directory /root/.kde/AutoStart

If you are doing most of your daily Linux user activity as root... do yourself a favor and STOP DOING THAT!!! That is perhaps the single stupidest thing you can do on any unix type system and is extremely extremely very super extremely much very dangerous and bad and not smart and dumb.

[murple]

I specially find the linux forums crowded of little arrogant people (most of them, there are exceptions of course) since some of them find themselfs like part of an elite (yes linux is not for all but that doesn't means linux masters cannot be helpfull and polite).

I think the main reason for that is that the First Commandment of unix-like OSes is "RTFM!" Most common problems are due to people who ignore the manuals and just try to figure things out themselves. That doesn't work with Linux. When people show up asking repetetive questions which are clearly explained in various manuals, its sort of like if somebody keeps going to the hospital saying "I keep sticking a fork in my toaster and it keeps electricuting me, how do I keep the toaster from electrocuting me when I stick a fork in it?"

I've found that Linux forums are often very helpful and un-arrogant if you first read the manuals and then phrase your questions in ways that show you took the 5 minutes to read the instructions... assuming you even have a question still after reading the instructions. Chances are, the instructions alone are enough to answer your question.

[murple]

Why not a polite "Take a look at this <...> manual section. Hope this helps." ?

The assumption is that you should read the manual as the very first step in trying to set something up under a unix system. The sort of questions that tend to get rude responses on unix forums are ones which clearly show the person didn't read the manual before asking the question. You see their responses as rude, whereas they see it as rude that you ask questions before reading the manual. Whether or not it is right, in unix circles asking questions before reading the instructions is considered impolite and annoying. The fact is though that many questions are very clearly answered in the documentation for any piece of software you'll get in Linux. The documentation is in predictable places (manpages, source code readme files, etc).

There is also an assumption that you will learn the basics of the OS first. This generally means taking a Unix class in college or through work, or else self-educating yourself by reading some books like the ones I mentioned earlier. As with not reading software instructions, not taking the time to learn basics of the OS is seen as lazy and impolite... "We all had to read the manuals, you're no different." Again, this may not be right, but it is the usual attitude.

Informed and well phrased questions usually do get very polite and helpful responses from Unix people. There is a steep learning curve, but once you learn the stuff, it is incredibly powerful.

[murple]

Cutting and pasting logfile error messages to Google has solved 80% of my Linux problems. Good suggestion!

[murple]

Get started with the free online books at http://www.tldp.org and you'll get the hang of this real quick.

[murple]

I've been using Linux (and Solaris, BSD, HP-UX, Irix, etc) for nearly 20 years.

In the Debian tutorial is clear: everything ending in d is a Daemon.

Well, many *programs* that end in d are daemons... for example, crond or dhcpd. Not all daemons end in d though, for example sendmail. And certainly many things end in d which are not daemons, for example sed or ld. Things that end in .d are NEVER daemons, but are configuration directories for the most part... For example, /etc/profile.d has nothing to do with daemons. In fact I would probably go as far as to say that most directories ending in .d are not daemon related.

In my /etc, these are not daemon related: bash_completion.d, dev.d, gre.d, ld.so.conf.d, libpaper.d, logrotate.d, lsb-release.d, makedev.d, modprobe.d, pam.d, profile.d, readahead.d, reader.conf.d, rwtab.d, sane.d, setuptool.d, and yum.repos.d

And these ARE daemon related: cron.d, init.d, rc*.d, netplug.d and xinet.d

I suspect .d is for "default."


Daemons, under the Linux File System Standard, will generally be located in /sbin or /usr/sbin, and while many daemon program names end in d, many do not. While daemon CONFIGS will be in /etc, no daemon or other program should be in /etc (not counting executable scripts).

daemon is a"Disks And Extensions MONitor"

Uhh, no. That is absolutely not true. A daemon is a background system process that does stuff, and comes from the Greek word for servant.

Just a quick glance at that Debian help file tells me you ought to go read the TLDP stuff instead. Not that the Debian file is wrong, but its not very clear and has some things that will be confusing to newbies.

You can tell much more about what kind of file a program is by where it is. The filesystem has a pretty clear structure that is defined in a standards doc. Search the net for Linux filesystem standard.