The multilib files included in the default Slackware64 installation.

Or even in /extra so that updates are picked up by slackpkg.

samac

Please share your facts and evidence why the Salix developers are not trustworthy. They have gone out of their way to create a standalone distro that is fully backwards compatible with the stock Slackware, thereby creating a useful repository. One of the common complaints about Slackware is the lack of precompiled packages compared to the Debian, Red Hat, etc. repositories. I welcome the Salix developers into the Slackware community.

I think having slapt-get and glsapt in /extra would be a nice gesture. I would like to see Slackware provide graphical package managers for non-technical users. I also would include slackpack to provide a QT graphical package manager (gslapt is GTK). Pat included slackpkg in /extra for a long time, so why not other related tools?

0 members found this post helpful.

That is why we have the excellent site, slackbuilds.org. Also, gnashley's Src2pkg utility fills that need.

1 members found this post helpful.

I didnt say the Salix developers are not trustworthy. I just said rworkman is.
SalixOS isn't a repository for Slackware, like rworkman's or GSB or Alien Bob's, but another Linux distribution.
I see nothing wrong with using their packages, or anyone elses if you wish to. But as always you are responsible for the consequences of your actions.
Plus, like i already said most packages in order to have a more complete XFCE experience are provided by rworkman for both architectures.

Complaints for precompiled packages: You mean like complaints for "the lack of a package manager"?
When in fact Slackware is the distribution with the most package managers?

Building packages in Slackware doesnt require from the user to be familiar with complex distribution specific package manager documentation.
Package management in Slackware is simple and build scripts are in plain bash which is the default shell on almost all Linux distributions.
Does that count when we are talking about saving time?

You see, if you are trying to find negatives on anything, you are bound to succeed.

I took Salix for a spin last night, It was "OK", Gslapt locked up on me a few times so not overly impressed.

I just took Salix64-13.0.2a for a spin and it has much in it that is good, so I would like to suggest something that may well see me tied to a stake atop a large pile of wood and ignited.

[HERESY] Many off-shoots of Slackware have bits in them that are good, eg the Salix installer allows you to set up your language, and a user, it's xfce desktop is very well done, and it has one application per type (though you can download others). As these other Operating Systems either borrow heavily from, or just copy, Slackware, shouldn't the Slackware developers "nick" the best bits of these derivatives? [/HERESY]

OH! OH! I see an angry mob approching, time to run.

samac

I would also like to cast my vote for multilib being in /extra on the CD.

Sorry, but this is wrong. One of the main goals of Salix is to provide extra packages to Slackware users.

I would love to receive a report that I could reproduce for that. I'm sure the gslapt developer would like that too.

I agree if it stays in /extra. I (at least for now) would prefer my Slackware64 to continue "pure" 64-bits.

I wrote "precompiled packages." Neither slackbuilds.org or src2pkg provide precompiled packages. There are non-technical people, and some technical people, who are drawn to the Slackware design but do not want to build packages. Slackbuilds.org and src2pkg do not fill those needs.

SalixOS is both. The Salix developers want a custom system for people who like the Slackware design but not the overall effort to install and maintain Slackware. They want all of their packages to be backwards compatible with the stock Slackware in order to provide another repository. Both are primary goals of the developers. For the record I am not a Salix developer or user, but I welcome the Salix team to the Slackware community.

Snobbery.

No. I mean precompiled packages. Non-technical people, and some technical people, do not want to spend time building packages. They want only to download and install packages. They don't care as much about the means of getting those packages.

You've done a pretty good job of that all by yourself.

There is no reason why some of the better ideas and contributions of the derivative developers cannot be slipped back upstream in the stock Slackware. Yet that decision rests with those developers, and Pat and the Slackware development team. For example, Slackware does not provide a fully equipped Xfce desktop that is equivalent to KDE. I'm not an Xfce user, but I think Slackware would benefit by merging various GTK app packages back into trunk. Even if only two dozen GTK packages were added, that would improve Xfce significantly. I also like the idea of the graphical admin tools provided in Salix. Such simple tools make Slackware more enjoyable for non-technical users --- the die-hard Slackers can ignore those tools. I have long advocated the inclusion of graphical package managers in Slackware for non-technical users, but I myself am unlikely to use them. I am happy with the scripts I use to maintain my local mirror and updating patches. Yet I have no illusions non-technical people will embrace those means of updating. Another example is the lack of a splash screen for booting with a simple progress bar. Most non-technical people don't care to watch boot messages.

Many of these derivative systems arise simply because the respective developers believe Slackware is incomplete in certain ways. I have used Slackware for several years and Slackware is my primary desktop. Yet I'd like to see some of the work provided in the derivatives merged upstream in Slackware. I think if Pat and the development team were open to that kind of process that many of the derivative developers could join the Slackware development team rather than trying to beat their own drums.

Ah. I missed the pre-compiled packages reference. However, two of our esteemed Slackware developers ,alienBOB and rworkman, provide packages at their sites. As they are contributors to Slackware I trust their work.
As a general rule I only use software that I generate myself from SBo, Src2pkg, or stuff from Eric and Robby's sites.
Each to his own.

This is almost a religious subject I also only use software I build myself from source. But there are users out there that do not know or or do not want to compile software.
Should we send them to *buntu instead?

I maintain several packages for Lego software. All SlackBuilds are available on SBo, but I also put pre-built packages on my site.
If people do not "trust" me, they can compile their own.

Just my contribution...

Egad....no don't send them to *buntu.
However, I think it is a good idea to warn new users that do not know or who are unwilling to compile software that there can be security issues associated with "untrusted" pre-compiled software.
* Note: I'm not saying that the software mentioned by Woodsman is untrusted.
And I will go check out your packages, niels.horn.

P.S. Agreed. Package selection, choice can indeed be raised to an evangelical fervor.