That was my feeling as well. Why even bother if you are going to just give 90% of the X packages the same slack-desc? A lot of the packages are not obvious as to their function, and as it is, you need to have Google sitting next to you to accurately prune out things you don't need. Personally I think there are way too many packages in /x to expect everyone to just install them all blindly. Besides, isn't that the whole point of a modular XOrg in the first place; the ability to swap out drivers and functions without replacing the whole thing?

I understand that the sheer number of X packages in Slackware 12 is something that couldn't be avoided due to the new modular layout, but that is no excuse to skimp on the documentation. To say that documenting them isn't important since you should just install them all without asking questions is precisely the mentality I was trying to avoid when switching over to OSS.

As for an extra CD of popular applications, I have thought about that in the past as well. It would be nice if users could submit slackbuilds and have them reviewed for inclusion in a "community" CD that is maintained by the users but is part of the official distribution. But then, that is essentially what we are doing now with sites like slackbuilds.org and linuxpackages.net, so I suppose there is really no reason to re-invent the wheel there (though a more watchful eye over the package content/quality would be nice).

No, not really. If I do an upgrade-all then I want to scan through the list and choose what to upgrade (I'd also like to flag for removal, a bit like gslapt I guess - except I think these features should be in the default provided package tool). So yes that's the info I mean (I'd do "slackpkg info $package" or "slapt-get --show $package" normally though).

No. The packages being chosen for upgrade are those made newly available on the slackware mirror. I can now go through and choose the "upgrade" packages. But if the packages are numbered properly and someone who can script can do the maths then it should be relatively straight forward to have a flag for installing minor OR major upgrades automatically. If a package skips a version number (1.x.x to 2.x.x) I'd like to see what's changed and check if I want to upgrade. If a package has skipped a sub-minor version (1.x.1 to 1.x.2) then I'll just accept the upgrade without checking.

The other point is that self-installed stuff can be a higher version number but slackpkg offers to upgrade it to a lower version.

But yet easier still would be a base install with a single pdf viewer. Then the other 7 could be in an optional "full" install. No there'll never be consensus about which packages to include!

Oh yeah and does slackpkg or something write a tagfile for me based on /var/log/packages/ ? That would be cool.

This is simply not an issue. Generally speaking, the only time you'll see major version number bumps is in Slackware -current, and following -current is NOT something that should be automated.

This is a feature, not a bug. The point of using slackpkg is to keep your installed package set in sync with what's available in the official Slackware tree. If what you have is not the *same* as what's in the official tree, then slackpkg offers to "fix" it. For those packages you don't want "fixed," see /etc/slackpkg/blacklist

That's exactly right. There will never be a consensus on what pdf viewer should be the "chosen one," just like there will never be a consensus on which packages should be added, removed, mangled, and/or otherwise modified in Slackware.

Slackware is an operating system. It ships a reasonable set of additional tools and applications to be useful in a wide variety of environments and purposes, but there's simply no practical way to make it acceptable for all purposes "out of the box." The sooner "we" accept that and learn to live with it, the better "we" will be.

1 members found this post helpful.

Robby makes a good point. My response to the suggestions to either add or remove packages from the default installation is to state that the users can already do that. You can choose what to install during the installation process. There's even guidance on a minimal installation available from the Slack Wiki.

As for adding packages, a combination of SlackBuilds from SlackBuilds.org and using src2pkg works best for me. I like building my own packages from source. I like that I can check out the sources, ./configure scripts, "Read Me" files, dependancies, and SlackBuild scripts instead of just accepting something that other people have put together.

Additionally, I find that I can get much more recent software versions by building from source compared to what's available via the official repositories of other distributions.

OTOH, I like that official Slackware updates are available for the packages included in the distribution. That greatly simplifies routine system maintenance. I simply check the changelog and do and download and install the updates manually.

My total time with installing programs and system maintenance is probably two to three hours a month. In comparison, nearly every time I turn on my laptop with OpenSUSE 10.2 on it, there's another update to download and install.

Having said all of that, I'd like to see Emacs 22 as an official package instead of version 21.4a which was released in Feb, 2005. Emacs 22 really is an improved product and it was released in June 2007.

Regards,

For those wanting more information on the packages in X, try downloading the slackx scripts from:
http://sourceforge.net/projects/slackx/

The tarball is just a set of scripts for building modular X, but it includes a pretty good set of slack-desc files which give a good description for most of the parograms and drivers. The libs are'nt so well described, but most users will want to install all the libs anyway.
If you have an old installation of Slackware wghich used non-modular X, you can figure out a lot of what is going on with X by looking at the database files in /var/log/packages. Basically, the old 'base X' packahe included all the libraries and applications, the 'devel' contained all the proto packages and the fonts were spliut into 75-dpi, 100-dpi and ttf packages.
Actually the last few days I've been working on a minimal list of X packages -got it down from +-110MB to around 35MB -still with most headers, docs and man-pages. Fonts take more space than anything else...

I looked for info about the proto files (in the slack-desc files on SVN, browsing via sf.net) ...

Not as informative as I was hoping!

Slackware is my favourite distro. What features would I like to see in future releases of Slackware? Interesting question. I leave that up to Patrick V; he has an uncanny ability to pick tried and true, rock-solid applications for Slackware. I'm never disappointed with the features that are included with Slackware, it is all good:-)

pbhj, the proto packages are not hard to figure out -they are just the development headers for the library of the same name. Unfortunately the library packages also do not have good descriptions either. But they also are pretty simple -you really don't need to know what a library does unless you are writing apps which use the libraries. You can do a very small installation and leave out most of the libraries, but if you are running a very versatile desktop and using drm, dri etc, then you probably are going to need all the libs sooner or later. I do have it narrowed down to where I know which libraries are the most used, but each user will have different needs. If you want to not install some of them, just start out by installing only libx11 and try starting your desktop. You'll no doubt get errors. Just start adding the libraries until you get no more errors. Do the same for all the applications you normally use. You should be able to avoid having some of them installed.
Still, remember that the old x11-base package included nearly all the libs currently avaialable as separate packages.
If you are not compiling programs which use x libraries, you can leave out all the proto packages, the utils and the imake, makedepend lndir stuff.
The server itself basically doesn't need any of the libraries(except drm, I think).

Hi,

I think that most are available as packages now. If PV would have an 'Official Package Site' then that would be a means to allow expansion and not limit the distribution by adding another cd/dvd to Slackware.

Therefore the 'Oops' noted!

There is much about Slackware I like. Yet as Robbie mentioned, there is a significant challenge with creating an operating system to meet all or most of the demands of most people. Slackware installs the basics and leaves the end-user deciding what to do next. That works for some people and not for others. Works for me most of the time. Nonetheless, but there are some things I would like to see changed.

I would like to see better support, at least in the Extras branch, to create a more robust Xfce environment. I addressed this issue in another thread and have a page at my web site to serve as a portal for people interested in the idea. End-users can find additional tools using SlackBuilds.org and LinuxPackages.net, or even src2pkg, but fundamentally much remains missing in the stock Slackware Xfce when compared to what KDE provides. And there are Slackers who like the Slackware design but are not inclined or eager to build packages. I am trying to learn to write stable build scripts, but with my schedule the pace is slow. The Extras branch seems like a good place to store GTK2 programs to improve the Xfce environment, especially if Pat accepted submissions from reliable people to create stable packages.

The setup scripts could be updated to provide a less accident-prone method to configure fstab file system mappings. Currently end-users must manually type selections rather than choose from a pick list. The setup scripts also could scan a hard drive for an existing fstab and ask the end-user to populate fstab accordingly. I would like to see a "Back" button at the end of that sequence of steps in case a user saw a mistake in the mappings.

Both during setup and any time thereafter, there could be an easier way for non-hacker users to configure the boot process to start in init 4. Many new users are confused when Slackware starts and they are greeted with a cryptic command line message of "You have mail."

The setup scripts could ask the end-user for a box/host name. This option is available only in the network configuration tool.

A nice addition to the setup scripts, in the section to install from a known file directory, would be to provide end-users the option of mounting an ISO image. As is, the scripts work fine if an ISO is manually premounted, or the ISO image is extracted to a full directory tree, but a script option to mount the ISO image would be nice.

End-users could be offered the choice of installing the fortune cookie program, even with a full installation. Many new users find those login messages confusing, and sometimes scary because new users are unfamiliar with this program.

I would like to see a skeleton bash startup script package installed. Slackware provides no such package. The scripts do not need to be populated, just contain some basic comments how to use the scripts.

Long overdue in the opinion of many Slackers, GRUB could be a boot loader option.

Parallel port devices are still used and there could be support during installation to enable those options, without manual post-installation editing of rc.modules. Perhaps rather than enabling within rc.modules, a separate rc.d script would be more intuitive.

Many people use Slackware because they continue to use older hardware. The APM module should be the default selection for such people, not ACPI, and APM should be started with a script.

Samba is a standard Slackware package. The Samba Web Administration Tool (SWAT) could be enabled by default from within the installation package.

Slackware could use a nominal firewall rc.d script.

Getting X configured is a mixed bag of success. Some people have no problems, some have a lot. Slackware could use some better video recognition tools to help configure X. The Live CD folks seem to have this problem resolved much better than Slackware.

With virtualization now popular, I would like to see qemu and the kqemu module offered in the Extra branch. Possibly Virtual Box too. Yes, Eric provides some scripts, but only veteran Slackers know the various third party locations to find these packages.

I would like to see a few additional packages offered in the Extra branch, such as squid, lshw, and rsnapshot. Although I am not an OpenOffice fan, that package probably could be provided in the Extra branch too. Scripts and packages are available at the various third party sites, of course.

Somebody mentioned compiling Firefox from source and an appropriate SlackBuild script. I like that idea because there is some bloat in Firefox I'd enjoy trying to remove. But I believe there are some copyright issues with that approach.

Improved documentation is an area that interests me. The Free BSD Handbook is indeed a standard to compare other software documentation. I have worked in the technical writing field for two decades, but I'm snookered to find flexible time in my schedule to work on such a project.

I empathize with new users who try Slackware but are not hackers at heart or by nature. Playing the wish list game is a harmless activity and might actually prove useful should Pat decide to adopt some of the ideas mentioned in this thread.

This is the funniest thing I read all day! I'll be laughing about it for a while I imagine...

Don't throw away the fortune. I just remembered the sudo lesson:

Might be frightening, but still... required.

Great post anyway.

Let's check what fortune -o tells me today.

Fortune is great. I'm glad it's included by default, even tho it does scare away some users ... but not always, it depends on the quote

I like fortune... even if, after all these years (too many to even count) I still have to look twice when I see "Sorry, try again", or "core dumped".

Sheesh

But ... again, after all these years, I think there are still a few I haven't seen. They are entertaining, even if they get in the way on rare occasions.

They're easy enough to exclude post-install if anyone wishes to do so...

Slackware is great as it is. There are many packages that provide duplicate functionality and as has been pointed out, if you don't want them, either don't install them or remove them after initial installation--Slackware provides you with that flexibility.

Regarding the descriptions, from a noobs point of view the 'safe bet' is to install it all. 4gb for a fully functional operating system is NOT unreasonable given the available storage and memory (even on older hardware) today. And with the exception of setting up servers for only specific tasks, this does not seem unreasonable for other installs either. While it could be argued that using the process x20 for each box needed to be set up would make a huge waste of time this is where (like so many other tasks) the work should be put in up front to customize a tag script after the first one is set up and tested, then the others can be installed in the most efficient manner.

The centralized documentation repository/bible/wiki could be very helpful It should be obvious by the active community just within this forum here on LQ that there is much interest in this, but again, interest does not equal work required. I am as guilty as the next. Aside from ALWAYS buying the official distro once it comes out I don't provide much else to 'further the cause' but I am certainly glad for those that do. With that in mind, I am not going to complain, and I urge Pat and team to keep up the good work.