Speaking of mkinitrd it was strange on this install. Usually you can just but for some reason this no longer works and looks for /dev/root upon reboot. I got it to work, but I thought that was strange and possibly why it is no longer included in the README in /boot, even though it is in the man page. Just thought that was weird.

This issue has been fixed in the version of mkinitrd that is now in slackware-current (port 12.2).

Eric

I understand that the Slackbook is in line for some updating. Any of you a part of that?

Better yet, why isn't the Slackbook a community project that can be maintained and updated in real-time? Is there a reason why other folks can't contribute?

The book continues to be several releases out-of-date and is scheduled for completion when? Mid 2009? When Slackware 13.0 is released the book will again be out-of-date. The book needs to be maintained by the Slackware community in a real-time fashion, using subversion or other form of submission tool.

Appointing an editor to review submissions is reasonable, but the book should be up-to-date concurrent with any major Slackware release and easily updated by anybody in the community after a package patch changes related book content.

The Slackbook contents is woefully out-of-date. There should be sections related to the many graphical tools. Some of that is covered by various help files, but new users are unaware of all that Slackware contains. The Slackbook should be a stepping stone to everything included in Slackware, not just command line info (how archaic).

Why two separate books? Why not ask/invite Daniël de Kok to use his book as a basis for the Slackbook? Why duplicate? Perhaps merge the two books into an excellent community project.

I nominate Woodsman as maintainer and editor................

He's a great technical writer.

Thanks for the recommendation. I have in the past volunteered to help . . . .

I think the Slackbook is a concept that has outlived it's usefulness, at least in it's current form. In the era of the Wiki, I can see no reason to maintain a closed monolithic document like the Slackbook; I think you are absolutely right that it should be a community effort.

Unless it is maintained by a larger group of writers and at a relatively constant pace, it will never catch up to Slackware's actual development. Things move way too quickly in the open source community to not do incremental updates.

That said, there are a number of Slackware-oriented Wikis on the Internet already (such as SlackWiki) that we as a community could simply support better. While it would be nice to have the name recognition of the Slackbook, there is certainly no reason that the community couldn't dedicate itself to creating a new de-facto documentation source.

I guess this identifies the main problems.

First, if something is not covered in the corresponding help file, be it man, info, html, or pdf, it is a bug and should be treated accordingly.

Second, a new user indeed does not know where to look and what to read. Thus, a better list of what Slackware contains than /var/log/packages should be helpful.

Just an idea:

I think about an ordered net of references to local resources like man or html. It should be ordered so that everything necessary to understand any topic is explained before it. For example, after the bash language is referenced, it is possible to point to the system initialization scripts and that will cover network configuration and the like.

It may be necessary to add some introductory material or, when absolutely necessary, references to external sources with such material, but this still is much easier than a full scale book.

The final goal is to be able to say: read this from the beginning to the end and you will know all things Slackware.

Hi,
Most of the 'Slackbook' is being carried by volunteers. Just like any other endeavor by volunteers, they too have lives. As for the out of date issue, the ever evolving Slackware will require some parallel work with a book but that would be near to impossible to achieve. PV does great work on the distribution but try to provide feedback detail to editor(s) for a tech book would be another layer of burden while developing the new release. I would like to see PV write another book or at least co-author.

I like the 'SlackBasics' and I do recommend it all the time. This reference does need some updating but the basics are there.

I don't think that merging two good books into one project is a good idea. Bringing each to current status would be a better solution. Each has it's own benefit.

Creating good documentation is much harder than coding. It also takes more times to produce and is a larger work than the code itself. And for technical writing, the writer must usually know as much, or more, than the guy who wrote the code.
What is really the hardest thing about effective writing -of any kind, is to keep a clear vision of the who the reader is and their level of proficiency or interest in the subject. Writing an effective document for an expert is very different from writing one for a novice. This means that you either target one or the other, or write two separate documents -of course referring to each other if called for.

The complete book of knowing 'everything' about "X distro", could run into many thousands of pages, depending on what you call 'everything'. There is no end to what can be said about a subject. A document meant to be synchronized with the work of coders is quite a task, indeed. Even documenting the code itself with comments is excruciating -still the same problem of having to ask yourself: Who is the person who's gonna read this, why are they reading this, what do they already know and what do they want to find out?

I would like to have a live CD an installer in it.

Thus a minimal live CD and a live DVD

I think this is the best way to test your hardware(grafic cards) before you install.

The writing team could join Pat's developers mailing list. The writers are unlikely to participate heavily in development discussions, but would know what major changes are taking place. This is the basic approach in any tech writing project. Developers often are not aware when a change is significant to end-users. As the old expression goes, "they are too close to the project" and tend to presume end-users share the same level of expertise. Good tech writers know and often all they need is to be aware of the upcoming changes. As long as they can "listen" to these discussions, they will know what needs updating in the documentation.

I've been working as a technical writer for more than two decades. I never have known as much as the subject matter experts (SMEs) and never will.

A successful tech writer is skilled at asking questions, researching, and interviewing SMEs. A cornerstone of technical writing is thinking like the end-user, not like the developer. Generally developers are not skilled at technical writing and do not want to be. A skilled tech writer, if brought into a project in the early stages of a project, often is an excellent tester because the writer focuses on how the end-user sees the product, not the developer. When people in the field use the documentation or procedures I wrote to perform their tasks, encounter no mistakes, perform the procedure without comment, and sit down and have a coffee when finished, then I feel complimented despite the lack of any words. When a person stops a task and asks questions about the documentation then I have failed. After more than two decades of this effort, I have experienced both sides of the fence. The latter is always frustrating --- to everybody involved.

In the profession this is called audience analysis. For many computer software projects, the safest presumption is no knowledge. Often a higher level of expertise can be presumed. For example, a hardware troubleshooting guide for technicians can be written with a presumption of understanding basic electronic and electricity skills. The technician does not need to be told how to use a multimeter, but does need to know where to use the tool.

Yet doable if the participants want this. One key component is establishing communications. The volume of information being covered is why I advocate a community approach. Like all modern computer operating systems, Slackware has grown beyond the ability of one person to maintain the entire system. Slackware has grown from one CD to one DVD. Pat still renders the final decisions but now depends upon many people to help with each release. Documentation is no exception.

Yes, a couple of people would be appointed editors. They ensure all text submitted adheres to the document style guide and rules of grammar. With a subversion type system, "patches" to the documentation could be submitted by anyone.

There are several wikis and web sites containing free/libre information. The information could be consolidated into one heck of a "Slackbook." I like what the BSD folks have done. Something similar is possible and doable.

I'd love to see a Slackware documentation similiar to the BSD handbook.

Due to Slackware's strong points and its plain simplicity, a well written Slackware book might be something similar to a distribution-agnostic Linux handbook - like documentation used to be in the old days, when people wrote nice and useful in-depth-howtos instead of just selling "do rpm -foobar and apt-get -barfoo".

One thing on Slackware I'm really grateful for is that project XY's documentation actually still applies and I don't have to distinguish between the package maintainer's opinion on things and the project's documentation and _their_ suggestions how to do stuff.

I would gladly submit a chapter about Unicode and how to do international language support and/or the "beautiful font" thing - or help out Deadra to write one.

Addition: Don't care wether it's printed or in a wiki or groff - good documentation is good documentation and a good thing to have.

Hi,
I think the mailing list would be a component but I'm sure other information would be needed. The changelog, possible side notes or even other log information. That way the drift of the release will be followed.

I agree that you would never know as much as the experts but to be versed doesn't hurt. I would think it would be a double edge, end-user and developer with more leaning towards the end-user.

I agree that audience is a major factor. That's Slackware and other distributions problem. The base is wide and diverse therefore the writer must decide how much information along with how much detail should be included. Each participant would need to provide copy to the editor or the wiki in a moderated format.
This way the information validity, grammar and style would be assured.

I like the 'BSD' documentation. The format could be used as a guideline but customized to suit Slackware.

It seems to me that, as the Slackbook is included in the release and the CD sets, it would not be in Slackware.com's interest to transfer it to a wiki. It should be something that could easily be assembled into a cohesive structure.