What features/changes would you like to see in future Slackware?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Having a trustworthy repository with packages would be nice, but who do we trust enough to maintain it?
SBo is maintained by volunteers who do a wonderful job and we trust them.
sbopkg gives us a tool to install the packages more easily, but still it might be too complicated for the non-technical user.
Quote:
And I will go check out your packages, niels.horn.
Hope you'll have fun with them I certainly do!
Click here to see the post LQ members have rated as the most helpful post in this thread.
However, two of our esteemed Slackware developers, alienBOB and rworkman, provide packages at their sites.
Yes, they do.
Quote:
As a general rule I only use software that I generate myself
Likewise, but I empathize much with those folks who like Slackware but do not want to build packages. The debate is not about silly ideas like defining "the Slackware way," which smacks of religion and politics, but about striving to make Slackware more accessible and usable by a wider audience, which includes non-technical users. Many people change the engine oil in their car but have no clue how or desire to rebuild an engine. Software systems are somewhat similar. Users should expect some maintenance, but should not have to build packages.
Quote:
Should we send them to *buntu instead?
I agree with that point. I prefer to have people use Slackware. I'm not a fan of the general attitude that to use Slackware a person has to build packages. Apparently the people who support derivative versions of Slackware think the same. I think a lot of people like Slackware but the lack of prebuilt packages in a central repository discourages many. Granted, package managers can be configured to search multiple repositories, but the lack of a graphical partition manager in the stock Slackware also discourages people. I would like to install Slackware for several people I know who have grown weary of the many Windows problems, but they are all non-technical people who will never use the command line except for emergencies. I tell them to consider Mint or PCLinuxOS. I would prefer to have them install the same system I use for familiarity when helping.
Quote:
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.
I agree. Package managers should be configured to discourage that behavior, of course. If a person insists upon the basic Windows mentality of downloading anything from anywhere, then I would shrug and move on without helping. About 6 years ago I helped a person with a new XP system. I warned many times to exercise prudence with downloads. The person's system got infected three times. The third time scared him good and thereafter he never again downloaded anything from anywhere. I would now like to install Slackware for him, but he is a typical point-and-click person. I have no illusions that he'd adapt to Slackware without some graphical admin tools, including a graphical package manager.
Quote:
but who do we trust enough to maintain it?
Trust is always earned not given. With respect to malicious behaviors or sloppy packaging, which is where the trust issue resides, I have yet to hear of anything bad about slackbuilds.org, slacky.eu, Robbie (Workman), or Eric's (Alien Bob) packages. The Salix repository is new, but I haven't read anything to indicate the developers' intents are untrustworthy. Just the opposite. Trust with packages is rather straightforward: the first time any Slacker experiences terrible packaging or malicious intent, the word will spread quickly on the web within 24 hours and that packager will no longer be trusted. That general effect and attitude is why I prefer to see the slackbuild script included in packages. That simple effort shows an intent by the packager not to hide and to be open.
Well, we all here believe in the open software ideology, so if anyone - or any group - finds that there should be a repository of pre-built packages, then he/she/they should start one.
If enough people like / use / trust it, it may become a success, but don't wait for someone else to do it.
There is a graphical package manager for Slackware (I think it's called SlackPack). I have only used it once but I'm an old guy that spoiled his eyesight from typing at green-phosphor 3270 terminals so I tend to do about everything from the command line
I agree with that point. I prefer to have people use Slackware. I'm not a fan of the general attitude that to use Slackware a person has to build packages. Apparently the people who support derivative versions of Slackware think the same. I think a lot of people like Slackware but the lack of prebuilt packages in a central repository discourages many. Granted, package managers can be configured to search multiple repositories, but the lack of a graphical partition manager in the stock Slackware also discourages people. I would like to install Slackware for several people I know who have grown weary of the many Windows problems, but they are all non-technical people who will never use the command line except for emergencies. I tell them to consider Mint or PCLinuxOS. I would prefer to have them install the same system I use for familiarity when helping.
Here is where we get into an interesting problem. Yes. I would like everyone I know to run Slackware. I maintain a Slackware LAN at home for my family, they all have a Slackware box to use. But, I'm certainly not going to set-up, maintain Slackware boxes for others to use.
The fact is Slackware is a bit too difficult for some users. One needs to use a shell prompt or a text editor to set-up Slackware and this may be what keeps some users away from Slackware. However, the users that do perservere, read the slackbook, will feel a sense of pride knowing that they did it themselves.
Slackware is not for everyone.
I feel sometimes as Slackers we become almost apologetic because people think our distro is hard to use. Slackware is perfect the way it is. I for one am very thankful that PV maintains his distinct vision of Slackware.
Slackware works for me!
I'm certainly not going to set-up, maintain Slackware boxes for others to use. The fact is Slackware is a bit too difficult for some users.
I would clarify that installing and configuring Slackware tends to be difficult for many people. I would not expect most of the people (I have in mind) to install Slackware. That would be out of the question for almost all of them.
I don't want to become a single-person tech support shop either. I envision creating a pre-built disk image based upon my own experience. Then all I have to do is install that image along with some minor tweaks. I likely would install that image to a new hard drive. For those who are unsure, I would not have to touch their Windows installation --- just install the second drive and configure the boot loader. Because most people avoid administrative tasks, much of what we are discussing probably would be ignored by most of these people. Updating security patches could be automated, but all of them can adapt to a basic desktop and find apps. Most are not interested in updating the entire operating system every release either, just in updating apps, which is where a graphical package manager is handy.
So.... (throwing some firewood in the flames, as people say here in Brazil ) does this all and up with a discussion if Slackware should be made "simpler" or not? I wouldn't dare to define "simple" by the way...
I know what I do when I install a package or upgrade a system and have no need for a graphical interface.
I also understand that there are people out there that may want to download & install complete packages. Maybe it comes down to "Slackware is not for everyone", as hitest stated. As Gentoo or Arch are not for everyone, Ubuntu neither.
Each has its advantages / attractiveness for a certain group of users.
I don't think Slackware should do something a certain way just because others do it that way, but I do think there is a demand for pre-built packages for Slackware.
But to have a repository with the quality we are used to (SBo / rlworkman / alienBOB) is a difficult task. For it to have all the packages that can be built from SBo, quite some space / bandwidth is needed. This involves money for hosting, etc...
Another option would be to build the existing repositories that we have and trust. For example I have on one occasion had a slackbuild accepted at slackbuilds.org, but I only submitted it because I wanted to A) see how it was done and B) I wanted a game of xscrabble. Could we not, as a whole, build that repository? If we all submitted one slackbuild and maintained it we could expand the range of programs available dramatically. A second stage would involve getting slackbuilds and sbopkg accepted as the "officially accepted" 3rd party repository, this would mean that automatically new users would have access to a large range of "trusted" software that was relatively easy to install.
Sorry, but this is wrong. One of the main goals of Salix is to provide extra packages to Slackware users.
Then i suggest you change the "Salix is a linux distribution based on Slackware" to "Salix is a package repository for Slackware". Sorry but those are two interely different things.
Quote:
Originally Posted by Woodsman
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.
Yes, indeed that sounds nice.
But despite the fact that their packages work on Slackware they arent built using the standard Slackware tools. But anyway, thats not so important when we are talking about packages.
And they do include the scripts.
Didnt Zenwalk (from which the Salix developers come from) claim to do the same thing a while ago? Is that still the case? Those kind of things can change any day without notice to the "repository" users.
Re: trustworthy: Personally, one the main reasons I (only I) dont trust the Salix developers is cause IMO it has been proven (to me) that they dont even know how Slackware works.
And i dont think they bothered to check either. At least not extensively as a distribution maintainer would. I expect that from people in such positions. But maybe thats just me.
Heres an example: http://www.salixos.org/wiki/index.ph...esn't_work
Slackware's hal is patched so that Ctrl+Alt+BS works. Most, even common, Slackware users know that.
Again thats entirely my personal opinion.
Im done on this subject.
@samac: There are thousands of SlackBuilds on SBo (I asked the number some time ago) and the list is always growing.
It does not resolve the problem of a repository of pre-built packages for the not-so-technical user though.
And SBo is quite clear on the homepage:
Quote:
We do not now nor will we ever provide precompiled packages
Maybe putting sbopkg in /extra would be a nice start... If it gets more exposure it might grow into an even more user-friendly tool for the non-technical users.
It does not resolve the problem of a repository of pre-built packages for the not-so-technical user though.
Yes it does. The non-technical user doesn't care how a program is installed, all they care about is if I click on "A Generic Game" then the said game is installed and works without a fuss.
This is not ever going to be possible on Slackware as there is no way of resolving dependencies apart from manually, sbopkg does make this a bit easier with lists and queues but it does not completely solve the problem for the non-techies.
Pre-compiled packages do not solve this problem either as they may depend upon other packages that are not part of the base install. So slackbuilds and sbopkg are just as effective.
I know there are thousands of packages available on slackbuilds, but how many are recreational? It seems to me that many are libraries, development, scientific or multimedia related. There are more niche programs than general interest programs. For example compare the number of games available for Slackware by comparison to any other distribution.
So, in conclusion, my suggestions (from various threads) for improving the next release of Slackware are:
1) add sbopkg to /extra
2) make slackbuilds.org the official 3rd party site and have a campaign to extend it
3) add Alien Bob's 32-bit extensions to extra (64-bit version only)
4) Harvest the best bits from the numerous Slackware derivatives if they will improve the speed, stability or usability of Slackware
5) Trim Slackware to a core, basic, full (somewhat like Salix OS) installation and on a one program per use basis eg one editor, one music player etc. moving the other programs to /extra or slackbuilds.org
These modifications would, in my opinion, improve Slackware (the best version of linux) without changing what Slackware is.
Yes it does. The non-technical user doesn't care how a program is installed, all they care about is if I click on "A Generic Game" then the said game is installed and works without a fuss.
This is not ever going to be possible on Slackware as there is no way of resolving dependencies apart from manually, sbopkg does make this a bit easier with lists and queues but it does not completely solve the problem for the non-techies.
Pre-compiled packages do not solve this problem either as they may depend upon other packages that are not part of the base install. So slackbuilds and sbopkg are just as effective.
I know there are thousands of packages available on slackbuilds, but how many are recreational? It seems to me that many are libraries, development, scientific or multimedia related. There are more niche programs than general interest programs. For example compare the number of games available for Slackware by comparison to any other distribution.
So, in conclusion, my suggestions (from various threads) for improving the next release of Slackware are:
1) add sbopkg to /extra
2) make slackbuilds.org the official 3rd party site and have a campaign to extend it
3) add Alien Bob's 32-bit extensions to extra (64-bit version only)
4) Harvest the best bits from the numerous Slackware derivatives if they will improve the speed, stability or usability of Slackware
5) Trim Slackware to a core, basic, full (somewhat like Salix OS) installation and on a one program per use basis eg one editor, one music player etc. moving the other programs to /extra or slackbuilds.org
These modifications would, in my opinion, improve Slackware (the best version of linux) without changing what Slackware is.
samac
Most non-technical people can use something with minimal instructions so the usage of a repository would be the way to go. The manager choice should be left to the user or the maintainer to avail; KISS.
I think the problem with the current repositories is that most submissions are by people that are technical and the available packages are what these people find important. Involvement by a intermediate user base would be important to achieve the wider package base. I pity the poor team that must filter the submissions that would be afforded by such.
I agree with all your submissions except #5. My reasoning is that the Slackware basic full install is meant to service a wide user base. Plus the user has the choice via a menu to choose what to install. I think the menu driven install could be improved with a exception rule base but that too would be a drift from the Slack way.
I would hate to see Slackware become a bend my way distribution. Me thinks it won't happen!
The culling of information, techniques or whatever from derivatives is already occurring.
Pre-compiled packages do not solve this problem either as they may depend upon other packages that are not part of the base install. So slackbuilds and sbopkg are just as effective.
I think it is almost as effective. Don't get me wrong, I think sbopkg is a really nice program and I have no right to complain about it, as I do not give anything back in the form of constructive ideas etc. - simply for the lack of time.
It deserves to get into /extra and maybe later into mainstream Slackware (like what happened to slackpkg).
Quote:
Originally Posted by samac
I know there are thousands of packages available on slackbuilds, but how many are recreational? It seems to me that many are libraries, development, scientific or multimedia related. There are more niche programs than general interest programs. For example compare the number of games available for Slackware by comparison to any other distribution.
I submitted a few "recreational" packages (for building Lego) and these are exactly the ones user ask me about pre-built packages...
About games.... I'm not really into gaming, but if there are so many games around that are not available for Slackware (really, I have no idea at all...) maybe it would be possible to create a "request" system for Slackbuilds. Just a wild idea...
Quote:
Originally Posted by samac
So, in conclusion, my suggestions (from various threads) for improving the next release of Slackware are:
1) add sbopkg to /extra
2) make slackbuilds.org the official 3rd party site and have a campaign to extend it
3) add Alien Bob's 32-bit extensions to extra (64-bit version only)
4) Harvest the best bits from the numerous Slackware derivatives if they will improve the speed, stability or usability of Slackware
5) Trim Slackware to a core, basic, full (somewhat like Salix OS) installation and on a one program per use basis eg one editor, one music player etc. moving the other programs to /extra or slackbuilds.org
1) agree
2) not sure what "official" would mean (a link from slackware.com?), but for me it's official enough
3) in /extra is fine with me, not in the main tree though (explained this in another post)
4) I have my doubts here... Who decides what is "the best". For me this can only be Pat.
5) Dunno... Doesn't bother me having all these programs...
Aren't there enough easy distros out there? Do we really need to add Slackware to that pile? There's a distro to suit more or less any need or taste, let's keep it that way, OK? If you want to tinker with Slackware, do it to your own - not everybody elses.
Aren't there enough easy distros out there? Do we really need to add Slackware to that pile? There's a distro to suit more or less any need or taste, let's keep it that way, OK? If you want to tinker with Slackware, do it to your own - not everybody elses.
Agreed. I will stop using Slackware the day it becomes "something for everyone." Slackware is designed for people who like to roll up their sleeves and get a better understanding of how their OS works. If we add a graphical installer and or GUIs this will increase system overhead and in my opinion it will change the fundamental nature of Slackware.
Thankfully PV has the final say as to what happens with our favourite distro!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.