I am only referring to the fact that both Fedora (Redhat) and Ubuntu Conical are founded by well known commercial promoters of open source. In the case of Fedora especially sense the RedHat developers have sparked their own little subset of distributions, and not to mention the fact that ninety percent of the fortune five hundred companies that use Linux on their servers prefer Red Hat.

How many of them actually know what they are doing though? I find that most of the time RedHat is attractive to most companies because they can navigate it thanks to all the RedHat GUI bells and whistles. If they didn't have something to click I doubt they would use it.

__________________
It was a new day yesterday, but it's an old day now.

I really like Slackware, but the package management really doesn't do much for me. Slackware as a whole aims for simplicity, and while the design does reflect this, the developers could easily implement a package management system similar to BSD Ports by using Slackbuilds. After all, Slackbuilds are used by developers to create packages and test them before including them in a release. I particularly like Slackbuilds, since you can specify optimizations in the actual script. Also, syncing isn't necessary either because you can just specify version and reexectue the script, which will result in a package of the newer version. I think it'd be the perfect system. I also think Slackware should move the base of the system to a rolling release system, much like FreeBSD, and allow users to sync and update their systems.

I really like Slackware, but the package management really doesn't do much for me. Slackware as a whole aims for simplicity, and while the design does reflect this, the developers could easily implement a package management system similar to BSD Ports by using Slackbuilds. After all, Slackbuilds are used by developers to create packages and test them before including them in a release. I particularly like Slackbuilds, since you can specify optimizations in the actual script. Also, syncing isn't necessary either because you can just specify version and reexectue the script, which will result in a package of the newer version. I think it'd be the perfect system. I also think Slackware should move the base of the system to a rolling release system, much like FreeBSD, and allow users to sync and update their systems.

Why not voice your suggestions to Patrick?

__________________
And the WORD was made flesh, and dwelt among us. (John 1:14)

If you're using Slack since the early beginning you should already now Pats point of view. A rolling release isn't anything he considers stable and 99.9% of the Slack-Users are quiet happy with the package management. And if you want to show some respect then you shouldn't ask the question some people did ask him again and again. By the way, he has got the famous last word, but he works with a team since years! So if you don't like it, don't use it. I'm using it since the nineties because of this system.

You misunderstood what I said. Slackware doesn't have to change it's development ideology or anything. On the SlackBuilds and Slackware websites, it's noted that the developers use SlackBuilds to build packages and test them before inclusion in a stable release. With that in mind, I think there are two things that could be done.

1. A Ports-style directory containing all the Slackbuilds for a stable release and the patches and whatnot. You install the base system and use SlackBuilds to generate packages and install them. It works better for those of us who don't want to download six CDs or an entire DVD.

2. Have the standard installation available, but include the SlackBuilds directory as an optional item during installaion for those who want to use it.

Note, I'm not asking for automatic dependency resolution. SlackBuilds come with dependency information, and the way Slackware and SlackBuilds are developed, you generally don't encounter problems with dependencies. I only need the dependency information so I know what packages to install. I can do everything else manually.

Also, if you have a SlackBuilds directory, then everytime a new release is made available, I guess you'd be able to sync your SlackBuilds directory and upgrade all your packages that way.