Or is it just going to shadow Slackware or become parasitic?
Oh boy, there's that buzz word again: parasitic.
By definition, parasites take and offer nothing in return. There is no reciprocity, no symbiotic relationship. Politicians and bureaucrats are parasites.
The Salix developers explicitly offer something in return for using the stock Slackware as a foundation: a repository of pre-compiled packages that are compatible with the stock Slackware.
I fail to see how the Salix developers are parasites.
Exactly, Woodsman, I agree with your statement, but why would these people use Slack instead of ubuntu or fedora?
Because many people like and appreciate the underlying design of Slackware. The big distros, Ubuntu, Fedora, OpenSuse, all add much cruft and bloat. The developers with those systems all try to outguess user needs. I have tried to use some of the other systems and I get frustrated all the time. As I have mentioned previously, many times I have wanted to install a Linux based system for other people. I am pragmatic enough to know I would always be their first line of support. After having used Slackware for many years, I am unfamiliar with the other distros. I don't install those systems for other people. Therefore installing a system I like and prefer makes sense. I don't do that because of two conspicuous reasons.
One reason is the lack of graphical tools and boot splash. As I mentioned many times, those tools are not for the die-hards but for the newbies and less technically inclined. I really like the underlying design of Slackware --- I just want a little help for those people. At the Slackware web site is the claim that Slackware is designed for "ease of use." That's nonsense for the less technically inclined person. Slackware is a nightmare for such people. I can't install Slackware for these people because of the lack of graphical tools.
The second reason is the lack of an official central repository with pre-compiled packages. I can't expect other people, even if I am supporting them, to deal with package management as presently performed in the stock Slackware. Most non-technical people would respond "WTF" and demand I reinstall Windows.
Related to a central repository is dependency checking. Die-hards can disable any such feature. I myself am not persuaded one way or another. Yet I'll offer an example where the non-technical people would surrender. A couple of days ago I decided I might want to install and test Miro, a video streaming app. I went to slackbuilds.org. By the time I was finished backtracking, the list of dependent packages I had to build was beyond belief. One package led to another. This is a fine example of dependency hell. Now, the slackbuilds.org maintainers do a great job of listing the dependencies, and I admire whoever maintains and supports the Miro package at slackbuilds.org, but I have no illusions non-technical people will tolerate the effort required to install Miro, let alone try to build the package. Can sbopkg handle the problem? Allegedly yes, but again I have no illusions non-technical people will tolerate a command line app (ncurses or not) to install a package like Miro. In the end, even I did not install and build Miro. I don't have that kind of energy or time.
I never have advocated that the basic design of Slackware change. I only have advocated the addition of packages and feature improvements that would encourage non-technical users to better appreciate Slackware --- and to validate the claim of "ease of use."
They have tons of distros to use; we only have Slack, perfect as it is
Perfect? The length of this thread is evidence many people disagree.
Perfection is subjective not objective. We are discussing a computer operating system. No system is perfect and never will be. There is always room for improvement.
Yes, that's what members of the Mafia and American political society believe too. I prefer a warmer, reciprocating society.
I'm tired of the big bully act and cultish behaviors.
This thread needs to get back on track. So what things do we want to see in the next release of Slackware (13.1)?
1. Graphical administration tools for non-technical users. The Salix developers are on the right track with this area. If the Salix developers and Pat are open to the idea, perhaps those tools can be slipstreamed back into Slackware trunk or /extra.
2. A boot splash for non-technical users.
3. A graphical package manager for non-technical users. A GTK and QT version are needed to compliment both Xfce and KDE.
4. I'm not a GTK fan, but additional GTK apps that provide a more robust Xfce desktop. Xfce is one of the default desktop environments in Slackware.
5. Release the Slackbook into the community for continual, real-time maintenance. The copyright can remain with Pat, but the Slackbook needs a community approach much like the BSD documentation. As the copyright remains with Pat, certainly then there should be an editor or three who reviews submissions and revisions, and to maintain style and structure. The LQ forum community people can all provide reviews of submissions to ensure technical correctness before merging them into the Slackbook. There is no reason whatsoever that the Slackbook is not maintained in real-time. Time to end the "good ol' boys" monopoly toward the Slackbook.
6. Move grub from /extra to trunk and update the installation scripts to support both boot loaders.
7. Don't release 13.1 until after KDE 4.4.x and any kernel superceding 2.6.29.x. Reports indicate that KDE 4.3.4 is much better than 4.2.4, but is not yet as feature laden as 3.5.10. The forcedeth network driver in the 2.6.29.x kernel series is broken.
8. Move the QT graphical partition manager from /extra to trunk and include the tool as a partition option in the installation scripts.
9. Add a graphical background image to the installation scripts to provide the illusion of a graphical installation. The Zenwalk folks have done this. Simple polish and an air of professionalism.
10. Add the empty shell scripts needed to support the bash startup scripts. Nothing needs to be in these scripts other than a note how to use them. Let the users customize these scripts but include the container scripts. These empty container scripts also should be included in /etc/skel.
11. Add an empty /etc/rc.d/rc.firewall script container, with an internal note/link to Eric's firewall builder web page.
12. When auto-configuring the boot loader, the installation scripts should add two boot options: one for run level 3 and one for run level 4. The installation scripts should ask the user which one will be the default. Pkgtool/Setup can provide a simple script to toggle the default setting.
13. Colorized rc.d scripts, with the obvious option of enabling or disabling the color. The installation scripts should ask the user for the default setting. Pkgtool/Setup can provide a simple script to toggle the setting.
14. Merge into pkgtool the ncurses keyboard localization tool found in the installation scripts.
15. Get KPackage and KNetworkManager fixed to function properly with Slackware. This requires working with the upstream KDE developers but these repairs are long overdue.
16. Provide better multimedia support. I appreciate the stupid political debate about adding codecs and libdvdcss. Those packages need not be installed. Yet I think the Salix developers might be on the right track. Provide a simple tool that can download the packages after installation. That way Pat and the Slackware developers remain uninvolved in any decision the end-user makes about those packages. Obviously the location of those packages must be located at a third party location, but the basic tool to download those packages could be included in /extra.
17. Precompile K3B to take advantage of all multimedia support although those packages are not installed in the stock Slackware. That way, when people do install those packages, K3B automatically can take advantage of that environment.
Please note that none of these suggestions detract from the Slackware design nor are die-hards required to use these additional tools.
Hopefully everybody participating in this discussion appreciates the effort, time, and knowledge required to create and maintain a stable computer operating system. Thanks much to Pat the development team.
With that in mind, as always, I am willing to help test these tools and features if they are added.