a note about a previous comment on slamd64. I've picked up on other threads that Pat would only support a pure 64 platform (no multi-lib). This is both smart, stable, and good. Additionally, after messing with slamd64 my self, it changes many things that in the words of the slackware.org violate "The goal of the Slackware ports is to imitate the user experience of the Intel distribution as closely as possible. This means that the ports will attempt to include all of the same software, configuration scripts, and so forth."

There is extra software included with slamd64 and I have seen some abstraction to the build scripts that require an extra package (filled with bash scripts) to be able to build the package. sort of like slacktrack but different. Additionally slamd64 is multi-libed.

I would say slamd64 is based on Slackware but it is NOT a port.

ANY WAY The future of slackware looks as bright as it always has. It also taste like vanilla.

Personally I'd love to see Pat put out a 64 bit Slack. I've checked out Slamd64 but it's just not quite Slack.

If Pat were to ask me, I would ask that Gnome be put back into Slackware. I would also like to see Pat develop a 64 edition of Slack. A free computer with every Slackware disk would be nice, too.

I don’t think virtualization is a good addition. I’ve got 5 computers and only one uses virtualization. Then one has to settle the argument, which one, and the licensing thereof.

MySQL comes with Slackware. Every package that I have installed requires, at least, MySQL for a SQL server. Some packages will run with other SQL servers, but it seems that MySQL is the standard. Slackware also includes SQL ite.

I would throw a vote towards a Pat built native Slackware 64 bit addition.

If Pat were not able to continue with Slackware, Slackware would cease, or it would be taken over by those who already work with Pat on the project. Who BTW, thank you! Your hard work is seldom acknowledged (outside of the change logs), but it is very much appreciated.

FWIW, I really don’t see a need to change Slackware, it works pretty good the way it is.

-JJ

Could you be a bit more specific ? What is wrong with it ?

A zazzle store front would be nice.

Other than that, everything is perfect as it is. No reason to fix what isn't broken. It's enough to keep up with the development of the core apps, and make sure they work as well, if not better, than the previous releases.


OK, maybe a nice branded theme for KDE or Xfce

Nothing needs to be changed. Pat provides a stable secure base system for use, if you want anything else, make it happen.

+1 for 64-bit distro. I think 64-bit apps will be here soon.
As for Slamd64 - I can't exactly remember (it was 10.2), but there were some installation or after-install tuning problems I never had with true Slack.

I'm not ready to agree with other proposals of topic-starter. Virtualization software is not for production installations (for now).
Maybe OpenOffice.org instead of KDE. But on the other hand, it can be easily installed... Anyway I'd prefer Slackware's legendary stability to some new stuff

WBW, Oleg

Hi,

As a user then you probably appreciate the OS for what it is. The stablity of Slackware is one of the reasons that I use it. If you look at Slackware history you will find this stability. Some users still use versions with the 2.4 kernel for that vary reason. I've still got some servers that run Slackware with the 2.4 kernel. Stable!

If your worried about the direction of Slackware for immediate needs then the development cycle would probably be a weighing factor. If you are worried about support for Slackware then you should know that release 8.1 is still supported.

As for PV's plan for directions or future support or development of Slackware, you would have too communicate with him. I really feel that the current state of Slackware will work well into the future.

BTW, if you have put that much time and effort into Slackware then you should be comfortable with working on any other GNU/Linux.

I find that other distributions have a pointlessly abstracted configuration and startup system within the /etc directory. It's nice to know that with slackware, for the most part, you just have to worry about adding an rc.startup script in /etc/rc.d then setting it to executable and adding some lines into rc.local[_shutdown]

This thread sounds a little similar to "What features/changes would you like to see in future Slackware?".

I think what would be really cool is to have a feature in the setup program to use tag files like building blocks. For instance, let's say that you want to setup a minimal Apache Server. You select the "Apache Web Server" tag file and all the needed packages are checked. However, you might also want a print server, or a LDAP server, etc. Simply select those tag files as well and the selected packages are equal to the union of the sets included in each respective tag file.

I've been hearing some suggestions for XULrunner lately as well so that custom FF and T-bird builds could be more efficient and complete.

I would advise you not to use Slackware for your business, except if you are an expert in security.
Slackware is a very great distro, but it's also not a "serious" distro.
It's a distro of one man, his toy.
If you don't have a certain feeling, you should not use it.

I don't know why people don't like slamd64. It's mostly just Slackware recompiled to x86_64. I've tried several different versions and they performed exactly as Slackware would only somewhat faster. On my new computer here I used regular Slackware for a few weeks to see how it runs, and then switched to slamd64. The install was faster, and the programs ran faster, that's the only difference I noticed in performance. The only headache you might have is sometimes programs don't want to compile for 64-bit, so you have to force them a bit.

I would love to see something along these lines. This would go a long way towards enabling the "thin" Slackware distro a lot of people have been pining for. Of course settling on what packages belong with which tags could start a whole new mega-thread....


I don't think I've ever seen a bit of advice I've disagreed with more than this. If anything, Slackware is the most serious distro out there. Unlike a lot of the other distros, Slackware isn't enamored of the "latest and greatest" which frequently aren't either. If you're running a business system, stability and reliability are THE two key components you're looking for. Slackware provides those in spades. And PatV's cautiousness about new software has saved Slackware a lot of security headaches suffered by other distros.

Personally, I wouldn't (and don't) use anything else in my business environment.

Where is Slackware going? Onwards and upwards! To Infinity and Beyond!!

First of all, +1 on SlamD64 as well: I moved from Slack to Slam with very little changes in my user experience other than a few programs that aren't 64 bit (Flash being the biggest, but even Macromedia/Adobe finally got the message) and at least one slackbuild that I couldn't get to work right on Slam (for libdvdcss). I realize that the pure 64 vs multilib is something of a religious debate, but I personally prefer the multilib: on Slam its organized enough so that most all compilations "just work", and most programs seem to expect a certain de-facto standard that's been created with 32 bits in /lib and 64 bit in /lib64, along with their /usr equivalents.

Second, call me crazy (enough people do every day under their breath, if not to my face), but I'd love better laptop support, especially with the changes in ACPI that's occurring (acpid is deprecated), out-of-the-box suspend support, etc. Sure, other distros do this well, but I love my Slack!

I've been using Slack for nearly 15 years and had the chance to meet Pat at Linuxworld '98, and while I use SlamD64 now on my AMD Turion laptop,
I still consider it staying within the Slackware family.

BTW, why 64 bit for me personally? Well, 1. Because I just wanted to try it, and 2. some programs (like native-64 bit Urban Terror, running on the QuakeIII engine) run noticeably faster in 64 bit (I suspect it's a bus thing rather than the processor itself).

Mike