You could add a page to the Slackware wiki (either here or at slackwiki.org) and if it's kept up to date, it could be linked to from here. That way, everyone can add what they feel might be issues that are hard to find solutions for.

Sure.
I'll do that if you practice your editing skills.....dude. :)
Google is your friend.

Dear Saint IGNUcius, protect us from all the rogue blobs, firmware, patents and garden dwarfs loose out there =]

So, it would appear you and a few others are saying that before installing a brand new release, everyone one should google a variety of different topics to make that brand new release hasn't had any changes, errors, additions, etc. ?

Hi,

Of course not! Don't be absurd. You should read the documentation relative to the release to see any association of possible errors or prevent potential gotchas from biting you. Especially with Slackware the documentation is very important to review. That way you will expose the information relative to your equipment requirements. You have to remember that most applications are upstream from distributions and Google in this case will afford information that normally will be insulated from the distro user otherwise. That is unless you are on the developer's web site, email alerts or even just down the street then you will have information that should be shared. Start that 'wiki' knowledge base!

You need to remember that 'upstream' fact whenever speaking of new releases of distributions. As Slackware users we have PV and the team to filter through upstream maintainer details whenever applying their applications to '-current'. Luckily you had the ability of stepping back to KDE 3.5 without much difficulty. I'm fortunate that KDE 4 meets my needs.

My Slackware 13 laptop is functional. Complaints that I have are not with Slackware but things like 'ATI', 'wicd' and 'Office'. Not Slackware!

:hattip:

The availability of 3.5.10 for Slackware 13 probably deserved a mention in the slackware.announce mailing list, or on the news section of slackware.com. I've no idea whether it got one as I don't subscribe to that list, but it would seem like the appropriate place for 'announcements' from the project team.

Eric's multilib stuff is a different matter. They were not official in any way and provided "at your own risk", so though it's unfortunate the error caused you some inconvenience it's just one of those things.

The idea of a sticky announcements thread is actually not that bad an idea, and I think people are being a little harsh on you cwizard. However, as XavierP said, they take effort to manage and are not without their issues, so it's probably not a practical suggestion.

Perhaps a "Slackware Community Announcements" sub-forum which would allow an individual thread per announcement, and the ability to add a follow-up post to that thread when errata come up would be a better way of doing community originated announcements than a sticky. A separate sub-forum would solve the issue of announcements sinking down the topic list carried along in the relentless tide of general slackware chit-chat. However, whether people would be disciplined enough to use it correctly is questionable, so I'm not sure whether that'd actually work in practice either.

What problem? There was a problem mid-september (dbus/hal/mysqld rc files were nuked) which was fixed the same day as it was discovered, and it was mentioned here as well as on my blog. People around that time had no trouble finding the information on how to fix the issue since that was an active topic in several places.
Nowadays, that is history and if you download my current set of multilib packages the old problem will not be present.

If there is another, current, problem I'd like to be notified of that.

Keep in mind, these packages are not part of Slackware. Reporting bugs and giving feedkack is walways welcomed on the discussion page of http://alien.slackbook.org/dokuwiki/...kware:multilib or as a comment on my blog post http://alien.slackbook.org/blog/multilib-slackware64/

Eric

The stickied x86_64 RC thread is deprecated for sure though

Hi,

That's why I suggest the use of a 'wiki' that could contain the information. Sections for applications with sub sections for specific ones with corrections. Along with segmented sections for hardware or devices and even a hot list would/could be used. A good means to allow the inclusion by members of problems, solutions or even plain recipe for installs.

Not just a accumulation of posts but a quasi-knowledge base with the ease of use by wiki. I'm speaking from experience. I posted 'Slackware LQ Suggestions Links!' long ago. I was prodded into starting 'Slackware-Links'. I really did not think it would work out as good as it has.

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

:hattip:

-1 sticky with everybody posting. +1 sticky with write access to only slackware forum maintainers (is that even possible with LQ's server?)

+0.5 sub forum. Not a bad idea if people remember to flag posts as irrelevant when the problem is non existent with an update.

+1 google/forum search

+1 to the entertainment value of practicing necromancy. Excellent example of how easy it is to kill something living but how hard it is to kill something that was dead before.

It is possible, we could sticky and close the thread. But I don't have the time or inclination to do this and I think this goes for the rest of the mods.

We'd need a whole forum of locked threads and each one would need to be updated as and when the status changes or it would quickly become irrelevant and wrong. Again, not me!!

I like this idea :)

Entertaining or annoying....? :)