Hi,

I've been giving this some thought for a while but really did not think it would be that important. A post today by 'cwizardone'; Really got me to looking at the need again.

I started 'Slackware® Announcements/Additions/Fixes/HotList' wiki today. I've got enough on my platter now but I'll see how it works out.

Let me know what you think or what should be included. Right now it's rough since I used the TOC and some of the content work for headings from 'Slackware-Links'.

I really think a newbie section would be necessary. But how? What's necessary and how simple? Suggestions?

Remember this is rough without notes, announcements or fixes of any kind at this point in time. I really don't think a 'sticky' would justify or provide the service a 'wiki' can for content of this type.

Whoa looks like you got a lot on your plate there.

Good luck

Wow, that's a lot of work there, looks like a full time job :P good job!

Great job, onebuck! Thanks for supporting our community, man.

Great work. Keep it up.

woh woh, scale that page back a notch!

When somebody has a problem or wants a recap, they won't want to look at all those links on the Table of contents.

over 10 links for x86_32 and x86_64 for both current and stable would be needed. For one! most of the information is the same for 32 and 64bit. Only the 'gotchas' would be listed between them.

As for the releases, it's not needed to have the links:
* Slackware® Linux Announcements x86_64
* Slackware® Help Notices x86_64
* Slackware® Linux Simple Fixes x86_64
* Slackware® Linux Major Fixes x86_64
* Slackware® Linux Experimental Fixes x86_64
* Slackware® Packages & Script Notices x86_64
* Slackware® LQ Reference Fixes x86_64
* Slackware® Version Specific Notes x86_64
* Slackware® Hot_Fix x86_64
* Slackware® Request for Testing Hot Fix x86_64

Instead, have meaningful titles there. Because I don't see there being over 10 extra special notes per distro, let alone needing to group them like that.
KDE 4.3.2
xorg.conf no longer needed
Adding multilib support
Intel graphics chipsets! (i8whatever)


Also, until it gets really crazy, you may not need to group all the general distro version non specific tips into generalized categories like drivers/firmware and security.

Even if you grouped them a section like "10 things every slacker should know." would be good. Like having to turn on gpm and hold down shift when copping to or from console vim because of the -X11 and -clipboard options. Or how to extract and RPM file. Or 'objdump' to track dependencies of your pre compiled binaries. or "how to read the change log"


as for new slackers, just really short list of good links to go to for more information.


Again, probably the most success will be from keeping everything as simple and short as possible. I would hope that most slackers that would utilize such a thing would know how to find more information and only need to know where to start. Infact, any information that is really old and dated should probably be removed and or condensed at the very end.

I would also like to see a good method to submit a tip.

Hi,


Great to criticize but how about constructive? I think the break down will have to be of such. Maybe a little different in presentation or layout. The 'TOC' are links to subject(s) within the wiki content no where else at this time.

I stated this is rough and that I'm looking for input. This is Slackware specific, nothing else at this time. Maybe possible in the future but the need seems to be there for Slackware. I haven't looked at hardware/device specifics yet. Just a basic layout.

I think you fail to see the point. 'Announcements' is meant to be for 'Alerts'. Maybe change to that instead? Or a title like 'Announcements/Alerts'. Each of the class subjects are to have content within for the specific topic.

Yes, there's a need to segregate families as the subjects do differ. I believe a library heading for x86_32 and x86_64 would just be one example of difference and how to linear control of the problem for information presentation. I'll note your suggestions and I do appreciate your input.

I don't think scaling back as you suggest would do the wiki or Slackware justice. I know it seems broad but it is a work in progress. If a person is having problems then a TOC will allow the person to get to information within a lot easier than to say 'look at the next page'.

Cleary I have not conveyed the intent clearly. This is not a 'HOWTO', 'Recipe' or 'crib' type of 'wiki'. But a 'wiki' that will contain information on things that are necessary to make emergency/daily changes, document of information, document corrections, style or modifications of Slackware. Your above suggestions would be great for another 'wiki' content. 'lumak' it's not that hard. Why don't you attempt such a wiki as you outlined above? I'm not being smart or sarcastic, just a challenge.

Sorry, guess we were on different pages. Didn't mean it to be harsh or rude. Thought I was being constructive. Good luck with however you decide to maintain it.

Sorry onebuck, but I'm going to agree with lumak on this. I understand where you're going with this (at least I think I do) but that initial page is very overwhelming. It isn't like there are that many announcements that need to be covered by this wiki and I think that by having the set-up as broad as you've currently got it you're inadvertently encouraging it to become a replica of the forum. I think what you've started is potentially valuable, but it looks like you've built a thermonuclear device to take care of that mouse problem.

My suggestion would be to start very simply, say no more than half a dozen subject areas, and let it grow organically as needed. I suspect we aren't looking at that many issues that would need to be dealt with here (maybe 12 a year?) so keeping it simple is going to be key.

Hats off to the enthusiasm and effort of onebuck, I could care less about the number of links. I have eyes, if I have the time I'd be able to read and use the one I want. Nothing wrong with properly categorized link. It is wiki afterall. Slackware really needs more contributors.

I would have to agree that it looks a bit overwhelming at first. One thing that might help is to remove all of the Slackware(C) texts. We know the TOC is about Slackware, so we should not have to include the name in all of the TOC links. Having Slackware in the bolded headers should be sufficient.

Also, if you are going to have such an in depth wiki with that many subdivisions, I highly recommend that you maintain an executive summary. Something similar to an updated CHANGES_AND_HINTS.TXT would be sufficient.

I appreciate your work in the community!

I disagree. I like what onebuck has started. The new wiki has a coherent structure on the opening page that will classify problems and issues in a logical manner as they arise. There's a lot of content there because Slackware is a vast topic. Two thumbs up from me.

OK, I hacked at it a bit, and got carried away. Feel free to revoke all my changes if you want; it is a wiki after all. I thought this was a simpler approach, but I'm happy to have the old one back, it's just that it was a bit overwhelming for my liking. If I had an issue to post, then I wouldn't know which section to put it in. This way, at least as far as I'm concerned, it just goes in "Recent Issues".

Happy Hacking!

In thelist of links at the top, I notice that "How To Ask a Question by XavierP <-'Great LQ post'" is a link to my profile. The rest of it is true though If no one gets to it beforehand, I'll fix it later.

Also, it should now be credited to me and to GrapefruiTGirl as she put in a load of work to update it and keep it relevant.

Hi,
Look I spent a lot of time setting up the wiki and feel you are out of bounds with the way you hacked the 'wiki'. A discussion would have been nice.

I suggest that your jumping in and making the overall changes to the wiki to suit your desires is rather selfish. Not democratic from my point of view.