Difference between revisions of "Talk:Beginners' guide"

From ArchWiki
Jump to: navigation, search
(Suggestions: CD speed)
(Add group scanner to group list)
Line 33: Line 33:
 
===Add group scanner to group list===
 
===Add group scanner to group list===
 
*I think it would be good to add this group in the useradd part of the guide, as it is one that would be commonly needed. [[User:Kyo|Kyo]] 11:07, 27 October 2009 (EDT)
 
*I think it would be good to add this group in the useradd part of the guide, as it is one that would be commonly needed. [[User:Kyo|Kyo]] 11:07, 27 October 2009 (EDT)
** IIRC, I don't think that group "scanner" would exist at this point in the installation.
+
** IIRC, I don't think that group "scanner" would exist at this point in the installation. [unsigned]
 +
** The unsigned comment is correct -- the group “scanner” is created and deleted by the install script for the “sane” package.  More to the point, a user cannot be added to a group that does not exist yet. [[User:Rransom|Rransom]] 02:38, 1 July 2010 (EDT)
  
 
===inittab===
 
===inittab===

Revision as of 06:38, 1 July 2010

  1. The Beginners Guide now redirects to Beginners' Guide.
  2. A version bump in mediawiki has rectified the former apostrophe bug which rendered the page useless.
  3. Please make all editing suggestions here.
  4. Please keep discussions civil and productive.

Thanks. Misfit138 15:23, 22 October 2009 (EDT)

Suggestions

Actual experience

The following is my experience for following this guide through, until the very end where I have LXDE set up. I used the 2009.08 core iso to install.

  1. The section 2.9.1 states that we will be prompted for configuring initramfs. This is not true anymore. System Configuration will simply present us with the menu listing all the config files for us to select and edit. The first being /etc/rc.conf. Maybe merge the info in this section into 2.9.4 (/etc/mkinitcpio.conf)?
  2. In 2.9.3 (fstab), my initial fstab does not use UUIDs for my disks, it uses /dev/sda1, /dev/sdb1, etc. directly. Perhaps mention (for beginner's sake) that we could do '/sbin/blkid >> /etc/fstab' to get the UUIDs into the file for easy edits?
  3. In 3.5 (install sudo), doing 'pacman -S sudo vim' at that stage will result in the 'vim: /usr/bin/rview exists in filesystem' error and pacman exits without installation. Maybe mention that we can simply 'rm /usr/bin/{view,rview}' before pacman? (Reference: http://www.archlinux.org/news/445/)
  4. 4.3.3.2 (perform the X test), we can in fact just type 'exit' in xterm to shut down X and return to our prompt.
  5. 5.3.4 (LXDE), we must also install garmin, which will ask to remove FAM. Else when we enter LXDE, an error message will pop up asking us to make sure one of the two is running.
  6. : I did not read any wireless sections, as I don't need it (and I have dhcp upstream). Also, I have not progressed into the Appendix.

Apart from the above, this guide is perfect! Everything works as written. (Except the 2009.08-netinstall has a faulty version of pacman and will segfault during package downloads. That's why I used the core iso, but this will be a non-issue when the next iso is out.) Claestw 21:22, 24 October 2009 (EDT)

The current version of the guide does not properly sequentially address the initial sequence of first updating the local mirror db and than obtaining python when using the core iso. Direct link to part in question. Thibi 06:28, 7 February 2010 (EST)

CD Burnd Speed

i hope this is the right place, but i have experience with ESR and burning at low speed doesnt do anyone any good... high quality (and high price) CDRs and DVDRs have *one* certified speed and one will get the best results when burning with the certified speed. The cheap CDR's speed for best results is (as a general rule of thumb) about half the max speed stated on the label. It makes sense to me, because if you burn with the lowest possible speed the laser heats up the material much more, if you burn with too high speed you might get a sloppy write out of it. My personal experience is (at least for DVDs): certain recorders produce crappy DVDs. Some recorders prefer DVDRs form a certian label. as for my ESR experience: a really crappy optical drive reads discs written with the certified speed the best.

About 2.9.3 - /etc/fstab

  • I think the possibility of using tmpfs for /tmp should at least be mentioned and possibly even encouraged.
  • Only the noatime option is mentioned, what about its big brother nodiratime and its safer cousin relatime ? Maybe a note about that in the Arch installer-generated /etc/fstab would be good too. See http://kerneltrap.org/node/14148 for details.

Changaco 08:13, 25 October 2009 (EDT)

Add group scanner to group list

  • I think it would be good to add this group in the useradd part of the guide, as it is one that would be commonly needed. Kyo 11:07, 27 October 2009 (EDT)
    • IIRC, I don't think that group "scanner" would exist at this point in the installation. [unsigned]
    • The unsigned comment is correct -- the group “scanner” is created and deleted by the install script for the “sane” package. More to the point, a user cannot be added to a group that does not exist yet. Rransom 02:38, 1 July 2010 (EDT)

inittab

I would add the inittab method not only as a note on the kde guide, but also gnome and the others as it's generally preferred. Kyo 11:22, 30 October 2009 (EDT)

I disagree. Adding a login manager to rc.conf is simpler and more in line with the the other configuration steps that you are going through during your first time install.
I agree with ^. manolo 10:49, 13 November 2009 (EST)

/boot on primary partition

There were a couple of forum threads were people couldn't boot because /boot wasn't on a primary partition. I suggest to recommend putting /boot on a primary partition, with a disclaimer that it is not necessary if you know what you are doing. Explaining when it would not be necessary would be tool complicated at this point.

Clarifying 2.9.10 (pacman mirrorlist)

Specifying the pacman mirror list is slightly confusing. There are two files that show up in the list to edit (pacman.conf and mirrorlist). All the other files are given explicitly with more detail than setting up the mirror list.

Changing the mirrorlist at install time does not make sense. That is best done after the install. Setting up the mirrorslist, is explained in Mirrors with a section/link in Post Installation Tips#Mirrors. -- M l 11:07, 25 November 2009 (EST)

UNIX-like overdo

UNIX-like has 8 mentions in the whole article--this is a little too much. Also, UNIX isn't a technical term, so it does not need the <tt> tags. Time 04:07, 6 December 2009 (EST)

As for the code tags around UNIX, it results in a very close representation of the original small caps UNIX font..which is a good thing.

 Dennis Ritchie says that the `UNIX' spelling originally happened in
  CACM's 1974 paper "The UNIX Time-Sharing System" because "we had a new
  typesetter and troff had just been invented and we were intoxicated by
  being able to produce small caps." Later, dmr tried to get the spelling
  changed to `Unix' in a couple of Bell Labs papers, on the grounds that
  the word is not acronymic. He failed, and eventually (his words) "wimped
  out" on the issue.

From http://dictionary.die.net/unix Misfit138 13:46, 22 January 2010 (EST)

Paying homage through typeface seems more like an afterthought for justifying "I saw it elsewhere" than anything close to smart or fitting for the document. If editors actually shared that concern, they would surely do better than choosing a different glyph and pretend that's showing appreciation for the peeps at Bell Labs.
That aside, the focus was meant to point towards the sheer amount of mentions. Dres 03:09, 23 January 2010 (EST)

Not only that, but the word "the" seems to appear thousands of times as well. We should probably bikeshed more about this crisis here. Misfit138 21:06, 23 January 2010 (EST)

I'll leave it to someone else to explain articles like 'the'.
No point in being direct. Time and time again has proven that the most effective way of influencing this wiki is closet manipulation. ;) Dres 22:47, 23 January 2010 (EST)

Most effective and potentially most destructive, as you proved once. ;) Misfit138 12:32, 24 January 2010 (EST)

I agree with Time. This isn't about Unix, and IMHO, it is redundant to state "Linux distribution, and UNIX-like". In fact, it is difficult to know what is meant by "Unix-like". Is it meant to be opposed to BSD? Or Windows-like? Very confusing. Perhaps the problem is that there was no definition given for the term. But if there was, then why use the term? The KISS principle was overlooked there.
Further, I don't think that anyone's sincere question should be cast aside in a belittling manner. Rather, if it was important enough to be written here, it is important enough to respond to in a friendly manner or ignore as one wishes; especially since it was not stated in an insulting or denigrating manner. (Sorry; I evidently forgot to sign.) - KitchM 23:27, 25 January 2010 (EST)

I agree! Misfit138 14:11, 24 January 2010 (EST)

In reply to KitchM: It's not even about the subject matter, nor whether it's about Unix or not. I'm just pointing out a phrase that's being overused. Anything that gets overused becomes tedious to read, see 'provides', 'via', 'as a side note', and countless of others that just don't seem to tire from being repeated every two seconds. Dres 18:55, 24 January 2010 (EST)

A simple, lightweight Beginner's Guide

One of the things my professor kept (h/y)ammering about when it came to software documentation was the difference between "data and information". The important thing in this context he always said was unambiguity: use a single example to show the 'way of doing things'. This makes a lot of sense, since the intention isn't to provide choice, but to provide information on how things work so people can make their own choices.

Extrapolating this to our BG, i think it would be a good idea to start using single examples of how stuff works on Arch. For instance, we can take Xfce or Lxde and show how it is group-installed, this will help people who just want a working Arch up and running. Other DE's and WM's should be linked-to only, give a small explanation of the different options and where installation instructions can be found. It is really not necessary to provide almost-identical-but-slightly-different installation intructions for 5-6 graphical desktops in the BG, it is confusing the people who really need beginner's instructions. Another argument for this is the Occam's Razor principle: don't duplicate efforts, KDE & Gnome etc. already have their own wiki pages with detailed installation instructions. Keep the BG simple and focused and people will understand better 'where to find what'.

Areas where i would propose to take the above approach:

  1. Graphical desktop (DE/WM etc.)
  2. Proprietary video (use xf86-video as preferred example, link to FGLRX/NVIDIA pages for vendor lock-in alternatives)
  3. Filesystems (use EXT as example, link to page with info on other filesystems)

Other sections that could definitely be moved out of the official BG to a separate wiki page:

  1. Analog modem/ISDN (for the 0.1% installing Arch on analog modem, a link to the appropriate page will suffice)
  2. Third party (openntpd/powerpill/? - they're handy tools, but definitely not essential for installation)
  3. Manual xorg.conf (X is moving away from this, it's not the preferred way anymore. Provide link for people who need it)
  4. Font configuration (the system will work fine without custom fonts, not BG material; if you want fancy fonts, read the designated wiki page)

Your opinions on this? I will be more than happy to help abstracting the above sections and work towards a simple, lightweight Beginner's Guide. litemotiv 04:45, 7 December 2009 (EST)

I feel the need to mention that using "a single example to show the way of doing things" does not apply in this context. It's not just any kind of information; it is instructional. This reasoning is apt for narration, not manuals. Having said that, I agree with all of your suggestions, specially the ones on repeating content from GNOME, KDE, etc. One striking peculiarity about these sections in the Beginners' Guide is how they are potentially conflicting ones, assuming that installing KDE in parallel to GNOME is a rare course of action. Partially coinciding with your observation: other sections are escalating, these are forking. Time 07:45, 7 December 2009 (EST)
I agree with Time. I would like to keep the instructional nature of the guide intact at the cost of repetition. I also agree with these points:
  1. Analog modem/ISDN (for the 0.1% installing Arch on analog modem, a link to the appropriate page will suffice) agree
  2. Third party (openntpd/powerpill/? - they're handy tools, but definitely not essential for installation) agree -- provide links
  3. Manual xorg.conf (X is moving away from this, it's not the preferred way anymore. Provide link for people who need it) agree -- mention this exact fact and provide link(s)
  4. Font configuration (the system will work fine without custom fonts, not BG material; if you want fancy fonts, read the designated wiki page) ? which section are you referring to?
Misfit138 12:34, 7 December 2009 (EST)
I think the instructional approach is fine, my 'single example' suggestion was meant as a possible way of providing a fully working Arch desktop for beginners without giving redundant installation instructions for alternatives (e.g. desktop environments). In this way one could just follow all the commands from top to bottom and end up with a working example-installation, every command would be a unique step in the process. With this approach no decisions need to be made, but can be if one desires so (show the commands to install example-DE and give links to the other DE-pages). There is a risk of politics here obviously, since we'd need to choose an example package for each section.
The alternative of primarily explaining procedures when choices need to be made (like the aforementioned desktop environment) might also work, we should think about this and maybe create a test-page like Thisoldman proposes. It would be interesting to see if choice-intensive sections like DE/video work without any direct instructions at all.
@4 above: Part IV - Step 1; i would say that the existing link to Font Configuration is fine, we could just remove the installation text/commands above it (provide only commands for essential tasks) - Litemotiv 16:49, 9 December 2009 (EST)
Small correction to my previous message: a history lesson is both narrative and instructional. A more accurate discription would've been procedural, instead of calling it merely instructional. Time 16:23, 7 December 2009 (EST)
I agree with litemotiv. To be clear, however, we should always provide choice. But we need never tell anyone how to make their choice.
As I have mentioned before, all wikis need to implement XOXO so that we can have a more useful, collapsing outline layout. This keeps things simple, yet allows a depth of information that saves a lot of unnecessary page loading and reloading when only links are used. It is also far superior to any other method because the user can collapse all but the currently important areas to keep the install process simple and clear as she or he goes along.
In any case, the elimination of duplicate text is a huge benefit. In fact we could take it a little further and explain in general terms what these various sections are for, such as the DE choice, and then give the links to, first of all, a wiki page of comparison, and second, an individual wiki page for the installation of each one, but only from the comparison page. There is no need for any how-to in any of those areas of the BG; rather it is enough to point out that this is the point in the install process to add one if so desired. We don't even need a sample install; that goes in the appropriate wiki page for that item.
Also, I have found that a streamlined and simple install keeps the user from getting bogged down in unfamiliar minutia that has no bearing. If something can be installed at a later time, after the system is up and running, then it should be left out of the install, or placed in the addendum. Including something here clearly implies one should address it now. That is often just not true.
It is easy to get involved in details simply because someone else started down that path. I have been guilty of falling into that trap, and the simplification idea would go a long way in protecting all of us and keeping us on track. It appears prudent to re-evaluate the route from start to finish before starting the journey down it yet once again. - KitchM 20:59, 7 December 2009 (EST)
This is another good point, many sections of the BG are written verbose with unnecessary background information. For instance, the section about Pacman can be compressed back to this:
Now we will update the system using Pacman. Pacman is the package manager of Arch Linux, we will use it to download software packages and install them onto our system.
This saves us about 20 lines about how Pacman is written in C and how it uses gzip instead of bzip etc. We should take a careful look at each section and try to eliminate any smalltalk or superfluous information.
- Litemotiv 04:50, 10 December 2009 (EST)
Yes. Good point. There seems to be a lot of that thru-out the wiki, but sometimes a person may be a little concerned about editing someone's verbiage. If we can all agree on removing such things, we can feel a little more at ease about going thru and fixing articles. Also, there is still the question that remains up in the air and unaddressed; "Who is the target of the articles". If it is strickly for the intermediate or advanced user, then the tone of the articles may actually allow such extra, "techie" stuff. - KitchM 13:52, 10 December 2009 (EST)
~ I agree. The article lacks clarity. Information is presented in the Beginners' Guide that belongs elsewhere or should be eliminated entirely. Do we need 5 introductory sections before the reader is told to download the software?
Will anyone dare to take a first stab at this drastic edit and post the draft somewhere?
Sidenote—I appreciate that people are trying to keep the tone formal, but this has led to multi-syllabic obfuscation. We need to remember our reader may have limited English language skills.
--Thisoldman 07:35, 8 December 2009 (EST)

Additional menu.lst example for separate partition for /boot

I added this text:

Example for /boot on the separate partition:

title Arch Linux (Main) root (hd0,0) kernel /vmlinuz26 root=/dev/sda3 ro vga=773

initrd /kernel26.img

because i reinstalled Arch 5 times before i carefully read the whole section. While i know that this was my fault, i think beginners deserve another good example, if they wish to have a /boot on a separate partition. --Sindikat 11:49, 7 February 2010 (EST)

Install X confusion

4 Part III 4.2 Step 2, at the end of the first part of 4.2.2B it says "If you do not want to install the proprietary drivers or do not have an NVIDIA or ATI graphics card, you should skip down to Step 3: Configure X.", and links directly to Step 3, however this skips over the section to install the input driver packages. i figured it out pretty quickly, but this should probably be changed to avoid confusing others. Dharmabm 10:33, 28 February 2010 (EST)

Huh? Right above that it says "Use pacman to install the appropriate video driver for your video card/onboard video. e.g.:..." (?) Misfit138 19:25, 28 February 2010 (EST)

The Don't Panic Section

This section needs to be expanded so as to explain why we shouldn't panic and how not to. It appears to need a more encouraging tone and a clear reasoning, otherwise the whole point of the title and the words used won't make any sense to a lot of readers. - KitchM 14:23, 30 November 2009 (EST)

Layout

Level 5 titles (such as 2.4.1.2.1 Does the Wireless Chipset require Firmware?) appear in tiny characters, which makes them unnoticeable when the display font size is "medium". Is there a way to improve this? --zeb 03:34, 24 February 2010 (EST)

snd

So, which is it; snd-pcsp or snd_pcsp? - KitchM 12:25, 16 March 2010 (EDT)

Either. Template:Codeline; first sentence of DESCRIPTION section. -- pointone 12:33, 16 March 2010 (EDT)
Then, for the sake of clarity, let's choose one. - KitchM 13:14, 16 March 2010 (EDT)

Installation

Why is there an article on installing Arch, and then a section of this article devoted to installing Arch also? I think it would be best if there were a preface article describing the Arch philosophy (which already exists), installation article (which already exists), and post-installation (which is covered in this article). I don't like when a wiki contains different articles teaching the same thing.

Sometimes things might not seem too clear for newbies. I know how that is, and sympathize. In this case, the philosophy had been to not design the product or the web site for any less than intermediate users. With that said, however, there has been something of a small trend toward providing separate information for new users of Linux. Hence, the seemingly duplicate articles. But note that this one is for beginners and the other is for more Linux-knowledgable users, whatever that means.
The bottom line is that there remains a lot of improvement needed with the portal organization to direct users to the right category of articles, and to explain the diffence in clearer terms. Hopefully that will help with this sort of confusion. - KitchM 00:12, 4 April 2010 (EDT)
I feel like one complete installation article would be accessible to both newbies and advanced Linux users. There is already a quick install guide which seems appropriate for the impatient user. I, for example, feel like I am a competent Linux user. I used Gentoo for a while and installing and maintaining that was some work. So much that I switched to Arch. But anyway, that doesn't mean I immediately understand all the nuances of installing Arch. A complete article doesn't leave anything out. A newbie should be able to follow the directions if they read it. A more advanced user like me can sort of skim over and get the parts he needs. I just feel that with the multiple articles, one has something that the other doesn't so I read them both and that is often the case. And the beginner's guide contains some things that most people would want to know, not even necessarily beginners, like how to set up alsa and X. Also, there is a difference between Arch newbie and Linux/computer newbie. If you are NOT an Arch newbie, you most likely don't even need the installation guide to install Arch. It is quite straightforward especially once you've done it once or twice. So if you mean Arch newbie when you say newbie, that would pretty much apply to everyone wanting to read an installation article. --Skrapasor 21:57, 4 April 2010 (EDT)
An excellent comment, Skrapasor. I agree. Firstly, and as I have tried to address elsewhere, there is a huge disagreement between Arch users as to the target of Arch, whether others outside that group should be given any help, and, as you point out, what is meant by “newbie”.
In my way of looking at it, the relative experience of any Linux user should be the criteria. If Arch tries to make such common terminology into something more parochial, there is nothing but confusion that will be obtained, and I am against that. Such a position would require one to be, not just a subscriber to a wiki or a particular OS distro, but a tested member of a private club.
I have had to assume that newbie meant anyone not familiar with Linux in general, and that Arch would not cater to them at all. In fact, the clear indication was that Arch had no time for them and their basically ignorant ways. Which leaves us to wonder if the idea of a Beginners' Guide is really in the spirit of the Arch Way. I prefer to think that it is a small cadre of narrow-minded people who promote such a position, and I have pushed to be more inclusive and friendly to all people, of every competency level, by making a more detailed wiki.
Toward that goal, and getting to the other part of your comments, I strongly support the inclusion of a collapsible outline format for the wiki pages. (One could use something like XOXO, but it appears to be difficult to find a wiki that has it.) The very best way is to use a simple outline for the instructions. At any point, the newbie, or other interested party, could simply expand that item to include the desired level of detail. I have never seen a better way of handling this problem, and no one has suggested anything that works as well. Hyper-linking is a good second option, but it simply is slower and requires too much mental whiplash, making it very tiring to use.
My idea seems to be the only one that solves the problem of missing important related information just because it was on another page somewhere else. Besides, I've never understood the value of a knowledge base of any kind, if the information is difficult to locate. Making it worse, as you alluded to, is that the newbie might not even know they're missing anything.
Anyway, that's my two cents. I realize that providing the suggested solution is not all there is, but I'm afraid that I'm not the one who knows how to implement it. Bummer. Still, I do believe it is the most valid solution. - KitchM 17:00, 26 April 2010 (EDT)

Floating

Does anyone know what a "floating window manager" is? Is there a link to info that explains it? Thanks. - KitchM 19:56, 6 June 2010 (EDT)

A floating window manager allows for the dragging, dropping, and layering of windows within a workspace as opposed to a tiling window manager which presents all windows within a workspace in a pre-determined, mosaic fashion. Misfit138 18:14, 16 June 2010 (EDT)

KDEmod

What the heck is going on? Pierre says that its broken, but unless he works at the Chakra Project, I believe we should listen to those folks instead. Evidently he hasn't even read his own link (an archived old news item), which I quote here:

"Now there are some people worrying: What is the situation now? Will I have to switch to the new platform within the next days?
The answer is: No, you don't have to! All this stuff is still in pre-alpha stage and we don't really want anyone to use this stuff yet on a productive system, as it will most likely break pretty soon. We will be supporting Arch still for the foreseeable future."

Please note that last sentence.

So its broken? Anyone have proof of that? In fact, even their main page only mentions Arch.

By the way, I use their products if I have to use KDE and everything works fine in that regard. - KitchM 00:25, 15 June 2010 (EDT)

See User:Pierre and Pierre's forum profile. Rransom 00:47, 15 June 2010 (EDT)
What were we supposed to see there? - KitchM 15:37, 16 June 2010 (EDT)
I'm guessing that he's implying that because he's the KDE maintainer than he "oughta know what he's talking about". I think argument from authority is stupid so suffice to say, I disagree.
Putting that aside, KDE mod 3 is unmaintained.  ;) self 16:08, 16 June 2010 (EDT)

Xorg 1.8 Changes

I performed a few cursory changes to reflect the updated xorg situation. Hal is no longer required by the x server, obviously. I believe hal is still required by thunar and pcmanfm, etc. Please feel free to update any sections corresponding to a DE you are familiar with, as I am not sure about GNOME, KDE, etc.