Start up guide for Salix 13.37

[tsuren]

Dear Salix users,

We have seen the release of Salix 13.37 and to finish off the release process properly, I am currently preparing the Salix Start up guide 13.37. It is an on-going process, and I have just finished the first draft. Apart from obvious typos and grammatical mistakes, I would like to gather your suggestions and ideas to improve the quality of the doc to the next level!

What I am particularly interested in is to add a section to answer questions that are often asked by new users of Salix and Linux in general, as one of the most important points in writing this start up guide is to remove some stumbling stones away from those users.

You can find the draft here.

Best wishes

tsuren

[tsuren]

By the way, if anyone is interested, the start up guide page is also up and running here.

[mimosa]

How do you get there from the Salix homepage? Clicking on "Documentation" doesn't seem to include a link to the user guide.

EDIT

The first paragraph of section 3.1 on package management, towards the end

you will become you more confident.

the second 'you' should be deleted


... and the links don't seem to work in zathura. They work in Evince.

The mention of OpenOffice on p. 50 should now be LibreOffice.

[ibka]

Found some errors.

Under Salix Editions: KDE is version 4.5.5 not 4.4.3
Under Installation Modes p. 6: OpenOffice.org
Under List of Applications: The web browser is Firefox not Konqueror.
Kaffeine is replaced by Bangarang

[tsuren]

Under Salix Editions: KDE is version 4.5.5 not 4.4.3
Under Installation Modes p. 6: OpenOffice.org
Under List of Applications: The web browser is Firefox not Konqueror.
Kaffeine is replaced by Bangarang

Fixed, many thanks

[tsuren]

Draft version 3 is up. Many thanks to mimosa for preparing a new introductory section on how to use Ratpoison!

The opening post has the link to the draft.

[luddite]

All in all the start up guide is looking good, and as a newbie very releived not to see a "foo" or
a "bar" anywhere ; the guide is actually very readable;

Often as a newbie its the silly little things that everyone else takes for granted that can cause problems ; on page 23 you mention installing from source with a header that reads " Making a Package from a Source File with SLKBUILD" .

I know you come to slkbuild further down, but i would have a header "installing from source", then another header about slknbuild. On the installing from source bit you have
./configure
make
make install

one thing that at first tripped me up was whether to use $ or # ; so I would put

$ ./configure
# make install

I don't think you can ever have too much information , but if its thought this is the case, how about those “extra tips or ref boxes “ like in the dummies books -yes I read them , well look at my user name!

On packages I have found it slightly confusing , but am beginning to see the light; now as i understand it, you can't just go anywhere for a build package, due to slight differences between
slackware & salixos. However since sourcery points to slackbuild.org, as I understand it your also safe if you want to download from there a source file, and the build file.

i have had a lot of trouble with sourcery but found

doing # ./packagename.SlackBuild

very successfull, I have just installed apache-tomcat this way, no problems & its all working .The only issue I had is one package dependeded on another, so I had to build the apache-tomcat, apache-ant and comons-daemon , i didn't find this big issue as a newbie though, because its a simple process - you just unpack the build package, put the source as it is into the unpacked build ,and the procedure is then the same.



On slkbuild forum user “djemos” , has shown a couple of commands depending on whether , you are trying to get an update of a package ,in other words once the package is created that you didn't have you can use

#installpkg packagename.txz

but if you have a package already, and the package just created is a new one you can use :
# upgradepkg --reinstall --install-new newpackage.txz



see: viewtopic.php?f=30&t=2407



ps i'm putting my experience of packages at :

viewtopic.php?f=22&t=2410

i've found the members on the forum very helpful but sometimes feel a bit embarrassed posting – I still think newbies coming to salixos ( and why not I say !) would be less embarrassed if there was a specific newbie post section.

[tsuren]

Hi luddite, thanks for your comments.

And I am happy to hear that you found the guide readable. The purpose of the document is exactly that - to let new users feel a little more comfortable in using Salix (or Linux in general).

As for your comments about installing packages from source, at the time of writing, I wished to put more emphasis on using slkbuild rather than each user compiling his or her own packages one by one with ./configure etc. etc. (besides you actually find a lot of applications being compiled differently from this "standard". For instance, setup.py). And the preferred method is actually to use slkbuilds. That is why the section heading contains "SLKBUILD".

As for $ and #, I find it unnecessary to include in the guide as you actually do not need to know them. If you happened to forget to "su" before installing, you would be warned anyway. And $ and # do not make things easier for a lot of users, I believe. To be honest, I still don't remember what they stand for unless I google for them, (which I never do anyway). I think the rule is simple. If you need to install something on a system, you need to be the root.

doing # ./packagename.SlackBuild

I did not go into detail about compiling a package by using a build file, or by using a slackbuild. Of course, using build file is one way of creating a package, but not the one I endorse to a new user. First, I would say, use slkbuild. If happy with it, then try to see how to write a slkbuild. Once being comfortable writing slkbuilds, you may submit your packages / slkbuild to the official repository. In this way, I think we can enrich the content of the repo we have in Salix. (And not by some workaround like using build files).

#installpkg packagename.txz

"spkg -i packagename.txz" is a better option, I heard, and officially "endorsed".

[Shador]

As for $ and #, I find it unnecessary to include in the guide as you actually do not need to know them. If you happened to forget to "su" before installing, you would be warned anyway. And $ and # do not make things easier for a lot of users, I believe. To be honest, I still don't remember what they stand for unless I google for them, (which I never do anyway). I think the rule is simple. If you need to install something on a system, you need to be the root.

I can't think of any installation routine as called by "make install" which would warn me about not being root. One just gets a pile of for unexperienced users confusing messages, because of access/rights problems.
For buildscripts and slkbuilds (they're not so much different anyway, slkbuilds are basically a simpler representation of buildscripts) in turn there's usually an error message for non root users. Nevertheless in that case the use of fakeroot is highly recommended as bad installation scripts then are unable to mess up the installed system.
Despite having said that, I agree (partially) with tsuren that '$' and '#' are not much use to newbies at all. I suggest doing it like this:

Code: Select all

$ ./configure
$ make
$ su
Password:
# make install

Also I recommend to explicitly mention to look at README, INSTALL whatever files and ./configure --help or ./configure --help=short output. I must admit not having looked at the guide yet, so this might well be in there already.

[mimosa]

The idea of a separate board for newbies was brought up recently. But there's no need to feel embarrassed. 'Newbie' is a relative term, anyway. Anybody who posts with a query ... lacks knowledge which another user may be able to help with. That's what the forum is for. Nobody will mind, especially when the query comes form someone who shows as much initiative as luddite

I think the main reason some distros and forums have a 'newbie board' is because they are so big queries tend to get lost if there aren't more subcategories.

EDIT

Shador, I like your idea about $ and #. I do think they are a useful convention, and that's an economical way of removing any ambiguity. If you just say "install as root" then you have to say "don't untar as root", or whatever. Your way is precise yet unobtrusive for those who don't need to be told.