How does Slackware compare to Arch

[f33dm3bits]

I have been running Arch for almost a year now, from what I've read here and there Slackware seems similar in a few ways but different in a lot of ways. It would be quite interesting to hear how Slackware compares to Arch from those who have run both but it would also be interesting to hear the view on Slackware from the Slackware only users.

 

[captain-sensible]

Well my time line from Windows was something like :

Windows XP-> Mint/Ubuntu->simplymephis->Antix/ puppy/slitaz->zencafe/zenwalk->slackware

The thing i didn't like about Windows was it did things i didn't ask it to; anybody remember that paperclip busybody on Windows desktop . So it was a stark contrast with slackware being the opposite ; you might have expected wifi works out of the box but it doesn't; no firewall either. So to get a firewall i had to create one and put it at /etc/rc.d there i saw all the other daemons for processes like rc.cups for printer rc.httpd for apache. Once i knew how to get one going I could get all going. Then to /etc/ to do some tweaks config- ah thats where everything is for config.

There is a simplicity to slackware in many ways. In terms of package management on Debian derivatives i had a bad experience with just updates , that after an update some things didn't work properly and a bad experience with incompatibility and dependency hell and apt --fix-broken etc I couldn't help thinking yes you have a 6monthly release but that its sloppy at times.

When i started with packages on slackware i used slackbuilds; that meant i had to read about every single dependency for a package and install in right order. But at least i learn't about packages. For stable every SlackBuild submitted to slackbuilds.org is tested against latest release.

The only failure i ever got was when source changed against that quoted in a build .That lead to understanding a slackbuild and taking over maintaining latex2html for slackbuilds .
Tools like slpkg allow for searching for pre-built packages from current repo tell you the dependencies and install those dependencies. So there is actually dependency resolution if you know which tools are available and how to use them prudently.



I like to get some learning out of using a distro as well as fucntionality but not too much that frazzles my brain. There is nothing i have wanted to do so far that that I couldn't do with slackware. Mind you i am talking about a time snap of Slackware current when it was quite stable.

One of Arch or freeBSD would be my choice if slackware goes down

 

[sp331yi]

@f33dm3bits -- since Arch is 10 years younger (2002 vs 1992) than Slackware, it would be more proper to say "Arch is similar to Slackware," rather than vice-versa, strictly speaking, of course.

Strictly speaking, the Arch link provided is mostly correct. However, slapt-get was not mentioned (controversial among Slacker purists, I know, but one cannot call me such!).
Let me provide some information regarding slapt-get

slapt-get does not provide dependency resolution for packages included within the Slackware distribution. It does, however, provide a framework for dependency resolution[3] in Slackware compatible packages similar in fashion to the hand-tuned method APT utilizes.[4] Several package sources and Slackware based distributions take advantage of this functionality. Hard, soft, and conditional dependencies along with package conflicts and complementary package suggestions can be expressed using the slapt-get framework.

That aside, I will be the first to admit to not being a "Slackware only" user. However, competent usage of the distro is what started me on the GNU/Linux journey. UNIX is what I initially wanted to learn, but politics and economics got in the way at the outset -- there was some Solaris or other legal wrangle going on at the time, prohibiting me from getting my hands on UNIX as an individual. So I went with Linux.

Jaunty Jackalop was my first distro delving into our OS. Looking Slackware over, I decided it was too 'geeky' for me at the time. I quit the 'buntus after Lucid Lynx and moved through so many distros between then and now I cannot remember them all.

I had a Shuttle and bought used hard drives from a local repair shop, putting a distro on each and swapping them out as desired. Also got pretty good at wiping drives using first SysRescCD and then dd command. I loved that Shuttle with an E8400 Core2Duo. Before that I used an ol P4 machine.

Debian became a favorite, especially Sid. Then I discovered Salix -- providing a good bridge for me to continue my journey towards Slackware. Hence, my earlier thread on SalixOS. Salix64 14.2.1 Live is still available. Maybe you'd like to try it and get back on your findings. Just a suggestion.

Enough out of me. Best way to see the similarities and differences is to experience them yourself! Best wishes in that endeavor, f33dm3bits!
_______________________

slapt-get - Wikipedia

en.wikipedia.org

 

[captain-sensible]

yes i forgot to say i did use salixos for a while

 

[f33dm3bits]

Thanks for your sharing, I always find it more helpful hearing it from people who have actual experience with the distro before making decision to try it. It does sound tempting though, but am sticking to Arch. Although I will have a look at SalixOS and install it on a vm and to at least get a sample taste of Slackware.

 

[captain-sensible]

so really its your turn now to tell us about Arch vs Slackware - who maintains it ? is it a committee elected small team etc

 

[f33dm3bits]

so really its your turn now to tell us about Arch vs Slackware - who maintains it ? is it a committee elected small team etc

I actually never took the time to see who does the development, I just looked it up in the wiki. It's basically setup like this:
- Developers: They maintain the core and extra repositories
- Trusted Users: They maintain the community and the AUR.
- Arch Testers: They do the package testing to make sure the packages submitted work as expected.
- Security tracker: They keep track of package security issues.
- Others: Forum and IRC moderator, wiki maintainers and translators.

So just a group of volunteers who all take on different roles to keep the distribution going.

 

[f33dm3bits]

I really like pacman the Arch package manager, it's a bit different that the other package managers but it's simple and it's fast and the Arch Build System(ABS) make it easy to build packages under Arch. I also like the Simplicity principle of Arch and that the whole distribution is about making the distribution better for the people that actually use it, and it being a distribution that cares more about quality over quantity as in the people that use it.

 

[Alexzee]

Slackware has it's own package management system like Arch has it's own.

Once you get to know Slackware's pkg management system you'll be good to go!

 

[captain-sensible]

there are a number of routes to getting packages which have caveats depending on whether you are using stable or current.

slackpkg :

I used this for a complete system upgrade. example of use for getting pkgs

bash-5.0# slackpkg search gimp
[ installed ] - gimp-2.10.14-x86_64-1

bash-5.0# slackpkg search medit
No package name matches the pattern.

slackbuilds,org : lists medit


slpkg

slpkg -F medit



| Repository Package Size
+=========================================================================
sbo medit-1.2.0 0 K

Found summary


bash-5.0# slpkg -F nano

Packages with name matching [ nano ]

+=========================================================================
| Repository Package Size
+=========================================================================
slack nano-4.9.3-x86_64-1.txz 556 K
sbo nano-syntax-highlighting-20180827 0 K


I find slpkg where I can get pre-complied pkgs across several repo and which gives me dep involved and install them the most versatile so far .

There is of course also :

sbopkg for stable and for current:

configuring the current repository with sbopkg

fork of master branch from git://git.slackbuilds.org/slackbuilds.git (read more on wiki). If you want to fork/pull request do it only over master (the other branches are temporary and are always re...

github.com