SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
@Harishankar: edited a rly small part of the slack's philo (PV still sells CD sets). Commented my changes.
I can't add something to the 'discussion' part of the article, so here it is: I read somewhere that PV's focus points for Slack is #1:stability, #2:security. Dunno how to put it, and it can be redundant to some of your already written points. But I know that's something I liked about Slack !
Quote:
Originally Posted by kikinovak
I suggest the introduction of the word "soon". It adheres to the KISS principle and works in all timezones, both in UTC and localtime.
Wasn't talking about ETA, in fact, I just wanted to avoid several people writing the same article.
Now I have a question: I have spare time for the moment (looking 4 a job, just arrived in Sydney), so I may be able to integrate some parts of the Slackbook to teh wiki.
But I rly dunno where to start from, and particularly, where to put those articles ! Any thoughts/ideas ?
Really, I think we should have planned the overall structure before anything else. What/how many sections/pages to have, subsections, etc.
I think that's the key. I'm glad that everyone is willing to contribute but let's think it over and structure it first. Otherwise we'll end up with a total mess.
I was thinking about something like (for example):
It's incomplete, just an idea. I'm on lunch at work now so don't have time to think it through:
Code:
1. Slackware installation.
1.1 Methods
1.1.1. DVD/CD.....
1.1.2. Network....
...
...
1.3 Partitioning the drive
...
1.4. Adding a swap partition
1.5. Configuring users
...
...
...
1.7 Configuring networking
1.7.2 Wireless networking
1.7.3 Supported wifi adapters
Broadcom 43.xxx configuration
Atheros xxx configuration
Using ndiswrapper
1.8.9
2. Post-installation tasks
2.1 ....
2.2 Optimising Slackware fonts (Dugan's stuff for example)
2.2...
2.3 KDE configuration and tweaks
2.4 Xfce configuration and tweaks
2.7 Configuring additional windows environments
2.7.1 Installing and configuring i3!!!!!:)
2.10. Terminals
2.10.1 configuring xterm (colours/etc)
2.11. Installing additional terminals
2.11.1 Configuring urxvt
..
..
...
..
..
..
3. Slackware as a server
3.1. Configuring NFS
3.2. Configuring a file server
..
...
...
4. Slackware multilib (Eric's stuff)
5. Games on Slackware
Configuring wine
5.1 Minecraft on Slackware
6. Staying -current
This is just a suggestion but once we've got a well thought over tree like that on one of the pages each person will easily be able to create a new article in the right place.
And somewhere in a post-installation section devoted to getting extra software, using sbopkg and src2pkg.
EDIT
For instance, adding to sycamorex's scheme:
1.6 Switching from huge to generic kernel
2.1 Getting more software (links to Alien Bob's, rworkman's, ponce's,etc, repositories)
2.1.1 Use of sbopkg and src2pkg.
I think that's the key. I'm glad that everyone is willing to contribute but let's think it over and structure it first. Otherwise we'll end up with a total mess.
I was thinking about something like (for example):
It's incomplete, just an idea. I'm on lunch at work now so don't have time to think it through:
Really, I think we should have planned the overall structure before anything else. What/how many sections/pages to have, subsections, etc.
At the same time, if we all just stayed in the playground, we could create pages which could subsequently be moved into place/edited when the structure becomes apparent. For instance, if someone was working on importing the Slackbook, they should be able to use the sections given to get a general idea of how to split up the pages.
It seems to me that the best thing we can do with this early stage motivation is get content in the wiki. Afterwards, even if there is a drop-off of support, much of the work left to do can be accomplished rather easily by a handful of people. Once the pages are live, it will only require those few editors to approve changes to pages, as well as the occasional author to submit a new page. Of course there will be edits/updates needed, but that's why it's a wiki.
It would be a shame to dawdle in the beginning for lack of structure and lose documentation creation/copying efforts. At the same time, I think we should have a place where we can store the pages (playground?) while we wait for TOC, style and admin decisions to be made.
As for internationalization (heu, there's a reason they 18'd that), I think we should consider using the same approach (ie, simply uploading work to a 'sandbox' area, such as frlayground for french). Otherwise, I think it would be safe to say that translation of relevant sections of the Slackbook could be started already, as it seems we are going to be using that as a base. It seems only logical to involve people in the way that motivates them; if we can get someone who offers to translate the installation section into Deutsch, should we not let them? Note, they did not volunteer to copy/create documentation in English. If turned away, these people might simply not get involved.
I still feel it's easier to write down a structure than implementing it in a Wiki. Fleshing out the details and producing content will be the hardest part and having a head start on content is always nice. On the other hand, working with existing content, I feel that a Wiki is not a book, and shouldn't need to have strict adherence to a book-like structure with numbered sections.
The native Wiki concept of root nodes (or main subject matter), groups (with all related topics) and related pages (to interconnect topics that work together) work better in a Wiki. It is looser, and doesn't need ordering (except perhaps by alphabetical order in an Index or when specifically linked from the individual pages)
However, in deference to the views of others, I am not going to create any new pages until we have some consensus about this but I think everybody is in favour of a structure except me.
Of course it is easier but that's not the point. You don't start buying furniture until your house and rooms are ready.
You can still create articles in the playground area and then once the topic tree is ready you'll just paste them in the relevant sections.
I've just looked at Dokuwiki's way of managing structure and it looks fairly easy to me. The administrator with access to the wiki files on the server, simply moves the text files to appropriate sub folders in the data directory as necessitated by the "structure".
Bear in mind that that way you're creating additional work for somebody else. Easy or not, poor administrator if a lot of people start doing it. LOL
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.