[SOLVED] What can we do to build a larger community?

Originally Posted by fatmac I don't need to defend my choice of distro, because it suits me, we all use Linux, just in different forms, it just amuses me as to why some Slackers do feel the need to put up a defence. This is a Linux forum, if you post about your distro here, others will see it, & have the right to make comments.

I get that your current choice suits you and you have every legitimate right to crow why it does suit you. The defense you see is because this is NOT Linux General. This is SPARTA... I mean Slackware

Crowing the value you find in your Not Slackware choice is legit in general or that distros sub-section, but it isn't OK to come to my house and take a dump on the living room carpet. I'm gonna complain and ask that you leave and never return.

Originally Posted by Zihen Sidenote: everything seems pretty (out)dated on 14.2-stable.

14.2 may have had updates available since you downloaded the ISO that you installed from. (Have you checked?) Yet, even those are not necessarily the latest-n-greatest versions of some applications. They are "stable", though. I seem to recall that 14.2 originally shipped with Firefox 68.x. A recent update took it to 69.x. Still way behind the 78.x/79.x version I heard about recently. If you want to be a beta tester for the latest version of applications, you're better off compiling from sources. If that's too bleeding edge, maybe the "-current" release is for you.

Thank you Gerard Lally for expanding the concept. I still don't get the logic however. Full Recommended Install is optional but it is designed to deliver a minimum target base that integrates everything into a smooth system that can behave in a fairly predictable manner for building on top of that foundation. I don't see how building on top damages that foundation in the least.

I don't think I have ever seen a response post stating the OP won't get support because they didn't do a Full Install. It does get noted that it can be substantially harder though. I've NEVER seen a post that says essentially "Oh you added this app or package so I can't and won't even try to help you". Building on top seems a non-issue to me but then I do Full recommended so maybe your experience differs.

For me it is akin to hardware requirements. It's really wise to start with at least the minimum or better. If one chooses to skate by with less than the minimum that also minimizes one's legit expectations. It doesn't negate them in my view. I just can't see the value in such concern over hard drive space given the difficulties not using that space can generate.

Whether to run 14.2 or current should really take this into consideration:

Originally Posted by deNiro The install media of Slackware 14.2 comes for example with an outdated kernel which means that people with recent hardware might experience problems.

Lenovo Ideapad 310-ABR, purchased 3 years ago for around $200, with AMD A12-9700P RADEON R7 processor is a hyprid cpu/gpu with 4 cpu cores and 6 gpu cores: when it came out I was running 14.2, and I had to compile a newer kernel and enable support for that processor. I give thanks for the slackware documentation on how to compile kernel: that's how it all begins. But Pat's 5.4.67 LTS kernel supports that processor, and I don't need to compile special kernel when running current.

You can upgrade the kernel, kernel-firmware, and kernel-headers on 14.2 and upgrade all the packages in the "patches" directory of the source tree, and have a stable system. But I still think you'll end up wanting to follow the instruction for a 3rd party cool thing you want, and it will want some library that is past 14.2's version of that library, so that you need to upgrade that one by hand. (find recent version, replace version info in the slackbuild script, and run it) But how many times do you need to do that before switching to current becomes a time-saver.

IMHO, from scratch, 14.2 or current can be installed the same way: inside their respective source trees, moving to usb-and-pxe-installers directory and running the shell script with the "--help" flag, so it will print its instructions (many scripts provide instructions that way):

./usbimg2disk.sh --help

and then re run the script following its instructions, and you have bootable usb install media for whichever source tree your were in.

After installing OS, read about the 3rd party apps at slackbuilds.org, where it lists dependencies, and make a list of the 3rd party packages needed in the right order to satisfy the dependency chain, and then batch execute sbopkg on the entire list (again first with the "--help" flag, to learn how it works).

Whether 14.2 or current, I'm doing the same thing. The only time I need to build a package by hand is if a slackbuild doesn't work, or doesn't yet exist for the app I need. Slackpkg+Sbopkg is a winning time saving combination. deNiro is right about getting to spend time using your computers tools to do what you want, rather than spending too much time on figuring out how to get the tool to run on your OS. Make a movie with Blender!

But if you come to slackware, you probably at least want to learn a little about what's under the hood.

I like the slackware philosophy of creating slackware packages which can be managed with pkgtools. In unlucky event that a package interferes with my system, it can easily be removed with removepkg. Whether running 14.2 or current, I end up needing to build some packages by hand.

Building slackware packages by hand for yourself is easier than building a slackbuild script that's capable of building the package on various hardware, etc. It's as simple as using the "DESTDIR" flag with "make install" to change it from installing directly onto your system, to installing into a directory. Inside that directory you execute the makepkg (after reading the instructions) and it builds a package you can install and remove. Automating that procedure for the various environments is the art of building a slackbuild script. I like reading them. They are, in general, more sophisticated than the scripts I write for myself. How lucky to have all those scripting examples.

One difference between 14.2 and current, though, is that on current, if an sbopkg doesn't build, I think of all the time and effort of the slackbuild maintainers, and have patience. If I win the lottery, I'm sending them some coin.

Originally Posted by slac-in-the-box Whether to run 14.2 or current should really take this into consideration: Lenovo Ideapad 310-ABR, purchased 3 years ago for around $200, with AMD A12-9700P RADEON R7 processor is a hyprid cpu/gpu with 4 cpu cores and 6 gpu cores: when it came out I was running 14.2, and I had to compile a newer kernel and enable support for that processor. I give thanks for the slackware documentation on how to compile kernel: that's how it all begins. But Pat's 5.4.67 LTS kernel supports that processor, and I don't need to compile special kernel when running current. You can upgrade the kernel, kernel-firmware, and kernel-headers on 14.2 and upgrade all the packages in the "patches" directory of the source tree, and have a stable system. But I still think you'll end up wanting to follow the instruction for a 3rd party cool thing you want, and it will want some library that is past 14.2's version of that library, so that you need to upgrade that one by hand. (find recent version, replace version info in the slackbuild script, and run it) But how many times do you need to do that before switching to current becomes a time-saver. IMHO, from scratch, 14.2 or current can be installed the same way: inside their respective source trees, moving to usb-and-pxe-installers directory and running the shell script with the "--help" flag, so it will print its instructions (many scripts provide instructions that way): ./usbimg2disk.sh --help and then re run the script following its instructions, and you have bootable usb install media for whichever source tree your were in. After installing OS, read about the 3rd party apps at slackbuilds.org, where it lists dependencies, and make a list of the 3rd party packages needed in the right order to satisfy the dependency chain, and then batch execute sbopkg on the entire list (again first with the "--help" flag, to learn how it works). Whether 14.2 or current, I'm doing the same thing. The only time I need to build a package by hand is if a slackbuild doesn't work, or doesn't yet exist for the app I need. Slackpkg+Sbopkg is a winning time saving combination. deNiro is right about getting to spend time using your computers tools to do what you want, rather than spending too much time on figuring out how to get the tool to run on your OS. Make a movie with Blender! But if you come to slackware, you probably at least want to learn a little about what's under the hood. I like the slackware philosophy of creating slackware packages which can be managed with pkgtools. In unlucky event that a package interferes with my system, it can easily be removed with removepkg. Whether running 14.2 or current, I end up needing to build some packages by hand. Building slackware packages by hand for yourself is easier than building a slackbuild script that's capable of building the package on various hardware, etc. It's as simple as using the "DESTDIR" flag with "make install" to change it from installing directly onto your system, to installing into a directory. Inside that directory you execute the makepkg (after reading the instructions) and it builds a package you can install and remove. Automating that procedure for the various environments is the art of building a slackbuild script. I like reading them. They are, in general, more sophisticated than the scripts I write for myself. How lucky to have all those scripting examples. One difference between 14.2 and current, though, is that on current, if an sbopkg doesn't build, I think of all the time and effort of the slackbuild maintainers, and have patience. If I win the lottery, I'm sending them some coin.

Seems to me like a lot of work, for someone who wants to start out using an operating system.

Originally Posted by enorbet Crowing the value you find in your Not Slackware choice is legit in general or that distros sub-section, but it isn't OK to come to my house and take a dump on the living room carpet. I'm gonna complain and ask that you leave and never return.

Nope! If I was to 'crow' about 'my' distro in here, I would have named it.

I answered a legitimate post by a user of why it is difficult to increase Slackware popularity with the general masses that use Linux, & I gave my reasons for moving on.


P.S. If you had your own Slackware Forum website, I wouldn't join because I am no longer using the distro, but here, I read all new posts on this 'general' Linux Forum to offer any help that I can, because that is the way of Linux usage, we help each other when we can.

enorbet,

It is interesting to note that our official Slackware forum (endorsed by Mr. Volkerding) is targeted by disgruntled former Slackware users. As with the most recent disgruntled Slackware user it is clear to me that you cannot reason with them. After a brief interaction with him/her I have decided to live and let live.
Back on topic.
I am happy that you want to get involved with our community, Zihen. I think that you will enjoy Slackware.

It is interesting to note that our official Slackware forum (endorsed by Mr. Volkerding) is targeted by disgruntled former Slackware users.

Perhaps ask why are they disgruntled.

Improving Slackware's popularity is moot until the release cycle returns to some kind of regular cadence. Traditionally releases are available "when ready," but a basic two to three year release cycle is palatable. Any cycle longer than that likely results in the natives beating drums.

One observation is lack of support for newer hardware. For many people that can be resolved with a newer kernel, but a minority of people need newer build tools too. Despite Slackware being a somewhat "hands-on" distro, compiling a new kernel is challenging and off-putting for many users.

Some disgruntlement could be avoided if a newer kernel package was offered in the /extra or /testing branch. There is precedent for that, back in the 2.4 to 2.6 transition period. One challenge with that approach is the installer needs to support newer kernels with newer hardware. This is not an uncommon challenge. Debian users face a similar Catch-22 when needing newer kernels from the backports repo.

Commonly a full install is recommended, but this approach is different from just about every other distro. The package categories/series/disk sets have remained unchanged since the original floppy disk days. To many new users this approach seems quaint and antiquated.

A minor complaint is package duplication. Likely that could be resolved by moving packages to the /extra branch.

The lack of a large binary package repo is a common discouragement as is package dependency checks when installing packages. Through the years the majority vote is not to support dependency checking, but that might need to change to increase popularity.

A common point of contention is the lack of a base or minimal install option. Defining "minimal" presents many arguments, but something of that nature would quash complaints.

Similarly is the option to create various types of installations, such as a desktop, file server, print server, web server, etc.

While updating the original ISO with packages in /patches is straightforward for many people, often new users expect a respective point release ISO image to reduce the number of /patches packages to install.

Slackware remains my preferred OS at home. I am content to let Pat do his thing. He provides a tremendous amount of sweat equity for his return on this investment. Thus, I am not complaining. I am not arguing or proposing. I'm only noting common arguments why some users might become disgruntled and how popularity might increase.

When it comes to updating a kernel, surely the most important thing is how it's configured, not what version it is. There is no reason why changing the kernel version should ever cause a problem if that is the only thing that changes.

On LFS, I build my kernel lean and mean. I have configured out everything I don't actually need. But on Slackware, I always use Patrick's config file because he knows what he's doing and I assume he tunes the kernel to the system. If you build a new kernel that way, it's easy and any newbie can do it. You copy over the config file from /boot as .config, make menuconfig, exit immediately without messing about and "make".

Originally Posted by upnort Slackware remains my preferred OS at home. I am content to let Pat do his thing. He provides a tremendous amount of sweat equity for his return on this investment. Thus, I am not complaining. I am not arguing or proposing. I'm only noting common arguments why some users might become disgruntled and how popularity might increase.

same.
You make fair observations about Slackware. Our BDFL reads comments here on LQ. I will continue to financially support Slackware and use this great operating system. I will continue to support new users here on LQ.

Hello upnort,
I think you gave a good assessment of the things that some folks don't like about Slackware. I do hope you realize it is largely those very same things that others like about Slackware. I see no value in pandering to the masses to become just another also ran by trying to do the impossible and please everyone. Slackware stands for something and I prefer that immensely.

Perhaps ask why are they disgruntled.

In most cases, it's safe to assume their new hardware requires many new things from the OS, so from their PoV it's the OS that should get the blame.
Suggest that it's hardware fault and they say something like: who are you to question the recommendation of hardware vendor?
So, I guess if their vendor only supports android, windows and mac >> they must find someone to blame other than the guy who bought the thing in the first place.

It has a lot to do with physical location, too. Some countries are known to advertise and recommend intentionally flawed hardware.
For example, many of us from mainland Europe would not even consider UK based hardware vendor for anything other than the list of things that are intentionally flawed.
From experience, I'm 100% certain that German based vendors have shipped better hardware for a long time, and I'm almost certain it has something to do with their consumer laws.

I like Slackware because it is untainted by the interests of mega-corporations who have no idea who I am, that I exist, and that my workflow might be different than what they anticipate. Pat doesn't make assumptions about my or any other Slacker's tastes in anything; all he provides is a "raw" distro, able to be made into anything the end user desires, provided, of course, that (s)he is willing to put the sweat equity into it. This is the attitude that all Slackware users must approach the distro with; not the attitude that (s)he will be spoon-fed the information, but that they are willing to put in the time to thoroughly research their topic, and after all that, if they cannot find a satisfactory solution, state that plainly in their post, and then ask for help, hat in hand (figuratively speaking, of course!).

I don't like the concept that I need a mega-corporation to administer my system for me; I am perfectly capable of administering my own system without any assistance, and am also perfectly capable of thoroughly researching a topic if indeed I need help with that. I can usually find a solution close enough with maybe a couple of searches, refining as necessary to narrow down the number of possibilities. The reason I rarely ask for help is because of this self-help attitude, and it is usually the case that I find the answers on my own shortly after I ask. Perhaps it is the action of posting that kick-starts my brain and gets it working again on an answer.

I like the concept that I can just push the power button on my computer, and be fully confident that I can be looking at a fully articulated desktop in less than 30 seconds (yes, I have NVMe drives on an AM3 platform; the flexibility of Linux makes that possible). Notwithstanding the presence of pulseaudio, which I and many others consider an non-issue because it has many more benefits than drawbacks (just my opinion!).

"Set and forget" is the name of this game; I don't have to remember why I did what I did (although in most cases I do anyway). When I set something a certain way, it stays that way unless and until I change it for whatever reason. That's the beauty of Slackware; for an old-school nerd such as myself, who is quite passionate about his keyboard and doesn't mind typing in long command lines to accomplish what I need done (yes, I realize I am in the tiny minority in this, but I don't care; I get what I need done in a satisfactory manner, and that's all that matters), at the end of the day, I get what I what when I want.

I hope this helps.

Happy Slacking!

Originally Posted by Gerard Lally We keep hearing this mantra that only a full installation is supported by the true Slackware users in this forum; that's why it surprises me when they deign to support a Full+ installation, with all the a-y series installed, combined with dozens of extras on top.

Where are all these posts?

I've seen a lot of posts about people running partial installs that still get help. It will always be "recommended" to run a full install (as that is what Pat recommends and is the simplest for dealing with dependencies), but there have been many posts where members have helped others with partial installs. However, for those who don't have the ability to at least do basic troubleshooting for a partial install, they probably shouldn't be running it and people will tell them so.

If you go to a car forum and tell them you want to run the vehicle without a catalytic converter and muffler, but you have no idea how to do it (or what benefits you get from it other than "more power", which isn't always the case), there's a good chance that forum members will tell that user that they should just run normal exhaust. But if someone comes in saying they're into racing or off-roading and they had removed their stuff and ran into a specific problem that they've tried to overcome, people are more likely to try and help that person if the reasoning the person wants to run without exhaust is legit.

Too many people want to run a partial install due to the ill-conceived notion that it will make their computer faster. Those people will not benefit from running a partial install and likely won't understand how to fix issues with a partial install if they don't understand why a partial install won't make their computer faster.

Originally Posted by deNiro Seems to me like a lot of work, for someone who wants to start out using an operating system.

Not just any operating system. It's slackware, where folks come to learn linux. They have to figure out how to type "setup" anyways: what's two more: slackpkg + sbopkg? Just two commands make managing that OS a breeze, so they can get to doing whatever they own their device for.

Some users like solving puzzles. I always tell my mom to quit playing sudoku and figure out how her computer works... building packages is akin to solving little puzzles, and for some, it's not "more work" but more fun puzzles.