LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 12-18-2008, 11:06 PM   #316
symatic
Member
 
Registered: May 2007
Distribution: Slackware
Posts: 242

Rep: Reputation: 32

Speaking of mkinitrd it was strange on this install. Usually you can just
Code:
mkinird -m ext3
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.
 
Old 12-19-2008, 02:42 AM   #317
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,111

Rep: Reputation: Disabled
Quote:
Originally Posted by symatic View Post
Speaking of mkinitrd it was strange on this install. Usually you can just
Code:
mkinird -m ext3
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
 
Old 12-22-2008, 05:05 PM   #318
mjjzf
Member
 
Registered: Feb 2004
Location: Valby, Denmark / Citizen of the Web
Distribution: Slackware 14.1
Posts: 879

Rep: Reputation: 38
I understand that the Slackbook is in line for some updating. Any of you a part of that?
 
Old 12-22-2008, 06:34 PM   #319
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,253

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
Quote:
I understand that the Slackbook is in line for some updating.
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.
 
Old 12-22-2008, 06:51 PM   #320
SqdnGuns
Member
 
Registered: Aug 2005
Location: Fountain Valley, CA / Thailand
Distribution: Slackware64ģ 14.0
Posts: 981

Rep: Reputation: 88
Quote:
Originally Posted by Woodsman View Post
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.
 
Old 12-22-2008, 07:43 PM   #321
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,253

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
Quote:
I nominate Woodsman as maintainer and editor
Thanks for the recommendation. I have in the past volunteered to help . . . .
 
Old 12-22-2008, 08:32 PM   #322
MS3FGX
Guru
 
Registered: Jan 2004
Location: NJ, USA
Distribution: Slackware, Debian
Posts: 5,850

Rep: Reputation: 350Reputation: 350Reputation: 350Reputation: 350
Quote:
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?
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.
 
Old 12-23-2008, 06:41 AM   #323
AGer
Member
 
Registered: Oct 2007
Distribution: Slackware current
Posts: 136
Blog Entries: 22

Rep: Reputation: 19
Quote:
Originally Posted by Woodsman View Post
Some of that is covered by various help files, but new users are unaware of all that Slackware contains.
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.
 
Old 12-23-2008, 07:30 AM   #324
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: Slackwareģ
Posts: 10,882
Blog Entries: 1

Rep: Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307
Hi,
Quote:
Originally Posted by Woodsman View Post
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.
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.
 
Old 12-23-2008, 08:07 AM   #325
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,724

Rep: Reputation: 449Reputation: 449Reputation: 449Reputation: 449Reputation: 449
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?
 
Old 12-23-2008, 09:15 AM   #326
eylli
LQ Newbie
 
Registered: Jun 2008
Posts: 9

Rep: Reputation: 2
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.
 
Old 12-23-2008, 02:06 PM   #327
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,253

Rep: Reputation: 481Reputation: 481Reputation: 481Reputation: 481Reputation: 481
Quote:
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.
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.

Quote:
And for technical writing, the writer must usually know as much, or more, than the guy who wrote the code.
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.

Quote:
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.
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.

Quote:
A document meant to be synchronized with the work of coders is quite a task, indeed.
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.
 
Old 12-23-2008, 03:16 PM   #328
Su-Shee
Member
 
Registered: Sep 2007
Location: Berlin
Distribution: Slackware
Posts: 509

Rep: Reputation: 41
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.

Last edited by Su-Shee; 12-23-2008 at 03:17 PM.
 
Old 12-23-2008, 07:04 PM   #329
onebuck
Moderator
 
Registered: Jan 2005
Location: Midwest USA, Central Illinois
Distribution: Slackwareģ
Posts: 10,882
Blog Entries: 1

Rep: Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307Reputation: 1307
Hi,
Quote:
Originally Posted by Woodsman View Post
The writing team could join Pat's developers mailing list. <snip>
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.

Quote:
Originally Posted by Woodsman View Post
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.
<snip>
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.

Quote:
Originally Posted by Woodsman View Post

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


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 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.
 
Old 12-25-2008, 01:29 AM   #330
mjjzf
Member
 
Registered: Feb 2004
Location: Valby, Denmark / Citizen of the Web
Distribution: Slackware 14.1
Posts: 879

Rep: Reputation: 38
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.
 
  


Reply

Tags
cd, live


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware future? coyctecm Slackware 12 02-01-2006 10:03 PM
Future of Slackware kratunko Slackware 30 08-12-2005 12:31 PM
Slackware features? rusty_slacker Slackware 49 12-02-2004 04:45 AM
what are the features of the new slackware 9? ethanchic Slackware 2 09-27-2002 06:15 PM


All times are GMT -5. The time now is 01:36 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration