Linux s:user-startup

[dfreniche]

@ptek
I love being a newbie. It's the only state of mind where you want to learn things all the time. I'm Amigan just since 2005 but I've used various flavours of MSDOS, Win, Linux, other UNIXes and MacOS. Why use only one system if you can try a bunch?
That said, i use Linux for everyday work and at home. It makes me feel comfortable. AmigaOS shocked me when I first try multitasking in an A500 unexpanded. I can connect it to my Linux box via serial port ! Then the frenzy started and now I own an A1200, an A600 and the 500. And use them everyday.
One of the biggest problems of "experts" is they take people out of their systems. If I start barking at someone for a basic Linux question, why anyone here should treat me with respect?

[ptek]

One of the biggest problems of "experts" is they take people out of their systems. If I start barking at someone for a basic Linux question, why anyone here should treat me with respect?

And why not? Why not a polite "Take a look at this <...> manual section. Hope this helps." ? Is there justification to rudeness? Personally I prefer an ignore attitude to rudeness...

"Basic questions" are of course relative taking in account different persons with different knowledge levels.

Take this example : Suppose one who is not a Linux user although have computer skills and ability to learn *but* (on PC side) prefers Windows since it allows generally do same job taking less time to the user. Suppose he would like to use the DSL distro since it's less than 50MB and run with 64MB RAM. DSL is designed to boot from a CD or USB key so the Internet favorites of the Firefox are not permanently stored. DSL can be installable on HD but in order to store the favourites, it needs some messing with config files, since all by default is saved to ram disk.

Does this person, who just would like to set up DSL for a basic task like surfing safely the Net for his dad (who could have an Windows installation infested by spyware and popups in less than 1 hour of browsing) have not the right to use basic questions about configuration? Considering he has only the sunday free from work and no time to learn the rudiments of linux?

OK, not expecting a full tutorial about it, just some hints to point at a starting direction since he presumly has the ability to think and learn.

PS : Take an example of completly rudeness like the answer of cbagger01 on  (no I'm not who started the 60Hz thread)http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=ST;f=10;t=10374;hl=60hz

And some guys like Grim find that arrogance pretty funny : http://damnsmalllinux.org/cgi-bin/forums/ikonboard.cgi?act=ST;f=10;t=10374;st=10

(well I'm getting off-topic... better to shut up)

[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.

[Fraccy]

murple wrote:

I think the main reason for that is that the First Commandment of unix-like OSes is "RTFM!"

And read log files!

I've never EVER had to post on a forum to sort out a problem. Mostly because someone else had had the same problem and there was a solution, or because a comment or observation pointed the way to a solution.

In nearly every case, the answers are already 'out there', or in the manual or a log file.

[murple]

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

[odin]

Ta for the answers folks.

Urgh. If only C= hadn't died.

[murple]

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

[dfreniche]

@murple
Not sure about the .d question. That's vital to me!
In the Debian tutorial is clear: everything ending in d is a Daemon.

Note all the commands ending in d --- such as kflushd and inetd --- the d stands for daemon[7]. A daemon is a non-interactive process, that is, it's run by the system and users never have to worry about it. Daemons provide services like internet connectivity, printing, or email.

The link to the quote

By the way, a daemon is a"Disks And Extensions MONitor" :-)

So .d maybe is a reminder of history and evolution of UNIX. In those times, it was hard to send a ls -l and watch the teletype printing. Maybe the .d was used to make clear the dirs... but it's used mostly on dirs where daemon config files resides  :lol:
...as it was discussed here

[Fats]

dfreniche wrote:

So .d maybe is a reminder of history and evolution of UNIX. In those times, it was hard to send a ls -l and watch the teletype printing. Maybe the .d was used to make clear the dirs... but it's used mostly on dirs where daemon config files resides  :lol:

Although I think the .d extension has some history it is not what you think. Previously most of the configuration of the deamons was done in single text files in /etc. For example /etc/crontab used by the crond deamon to list a number of processes to run at certain points in time. This is not very modular as you need to remove/add parts to this file to change it.
Then directories that end in .d were introduced to indicate that the full configuration for the deamon is a concatenation of all the files in that directory (e.g. /etc/cron.d for crond).
This makes the task easier for package managers. If you have a package that contains a command that needs to run every night you only need to add a file in this directory and not run an installation script that adds those lines to /etc/crontab. Uninstalling is the same as you now only have to remove the file and not find the lines you added to /etc/crontab and delete them.

greets,
Staf.

[Piru]

@dfreniche

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

Well, the tutorial is wrong there. There can easily be commands that end with d, and are not daemons. For example:

chmod
dd
ed
lsmod
mkmod
pwd
sed
depmod
insmod
parted
rmmod
cdrecord
find
head
hostid
id
ld
mkpasswd
passwd
groupadd
groupmod
useradd
usermod

So it should say "Note some of the commands ending in d ...", or so.

[dfreniche]

@Piru
Ok, lets blame on the Debian guys !  :-)
...and using
# find / -iname "*d"
is cheating !  :-D

I think in the tutorial they are talking about processes and not programs (you know, a process is a running instance of a program blah, blah).
But you're right, it's not expressed exactly as it is.

And the .d question. I know UNIX evolve from single file configuration (examples are /etc/inittab, /etc/passwd, /etc/group, ...) to multiple file configuration in SYSTEM V. So maybe the .d stands for "directory with configs" or "directory with configs plus daemons".

Are there any venerable UNIX Gurus (>20 years experience) that can help us with the .d mystery ? :-P

[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.

[dfreniche]

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."

Ok. As I answered to Piru, let's Blame the Debian help author. :-D
UNIX is inconsistent in many ways. Maybe the .d issue is just another symptom of a 30 years' old OS.

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).

OK. That's described in the FHS. I agree.

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.

That is absolutely half true. Look a the WikiPedia definition of daemon. Both are valid.

http://en.wikipedia.org/wiki/Daemon_(computer_software)

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.

Ooops! That sound me kind of RTFM ! :lol:
Ok, but I've not seen the .d issue covered anywhere Googling around. I know it's not that important, simply wanted to know why the ".d". I'm using Linux (and previously MINIX and a little AIX) since 1994. I don't consider myself a Linux newbie  :lol:  

[vpamicue]

I think the spelling mistake threw you off.
I did not tell him to put it in /root/.kde/AutoStart.
I told him to put it in /home/"username"/.kde/AutoStart. You are right but as a newbie he must be notified of the root path in case he does a search. If you read the note again it says to put the link in /home/"username"/.kde/AutoStart.
I never said I was or that he should log in as root (actually pretty hard on new linux dists as most require sudo and can not boot into root). Just telling him there are more than one folder that can have ,kde/AutoStart. Try chilling out. :-)  :-)

[smerf]

Hi,

According to my Ubuntu Bible Manual,
In the /etc/inittab file, the default run level for your system is identified with a line containing the string initdefault, as in the following example:

id:2:initdefault:

In this case the default run level is 2. An additional entry in the /etc/inittab file identifies a command script that is run to initialize the system itself, as in the following example:

si:sysinit:/etc/init.d/rcs

NOTE: On Ubuntu systems the /etc/init.d/rcs command actually runs the /etc/init.d/rc command with an argument of S, which executes all of the scripts in the directory /etc/rcS.d that begin with the uppercase S.

So I would say that this is just a designation for each run level directory. Lot easier to modify small startup commands in a directory than to have one big glob to mess with.

My job is to make people angry, where did I go wrong on this one?

smerf