4 ms·

How does Slackware compare to ArchLinux? They both seem to be very barebones and force you to learn more about Linux, but ArchLinux seems much more popular from

by rifung 11y ago

How does Slackware compare to ArchLinux? They both seem to be very barebones and force you to learn more about Linux, but ArchLinux seems much more popular from what I gather.

EC1 11y ago
Slackware only took me 8 installs vs 15 for Arch.
- anonbanker 11y ago
  Gentoo only took me 2 installs vs. 8 for Slack
komaromy 11y ago
The Arch docs are superior (best that I've encountered in the Linux world) but Slackware is worth it to me to stay away from systemd.
- coherentpony 11y ago
  Out of curiosity, why don't you like systemd?
  - komaromy 11y ago
    It felt too restrictive to me. Things were changing without me asking for them and that was preventing me from learning. One of the most egregious problems was forcing the change from text logs to journalctl binary logs.
    - JoshTriplett 11y ago
      > Things were changing without me asking for them and that was preventing me from learning. systemd has extensive documentation, both in manpages and in higher-level documents explaining how all the pieces fit together. I've generally found it far more straightforward to learn about than the components it replaces. > One of the most egregious problems was forcing the change from text logs to journalctl binary logs. You can keep a syslog implementation like rsyslog installed, and you'll continue to have text logs too. And journalctl outputs plain text.
      - dijit 11y ago
        You can also make rsyslog work on windows, doesn't mean it's supported or encouraged.. people seem to have this analogue of "you can configure away the bad bits" but in the end the bad bits are orthogonal to it's design and 'bypassing' them or hacking around them should not be encouraged- it should be able to be done by default.
        JoshTriplett 11y ago
        > people seem to have this analogue of "you can configure away the bad bits" Where in my comment did I imply that the journal was "bad"? The journal is awesome. But if you have some workflow designed around syslog, such as a log analyzer or statistics package that you don't want to tweak, text logging still works just fine.
        thiagowfx 11y ago
        "bad" is just a metaphor in this context
      - anonbanker 11y ago
        systemd only has extensive documentation if you count the source code itself. otherwise, most people are left guessing for things above a "systemctl restart"
        JoshTriplett 11y ago
        > systemd only has extensive documentation if you count the source code itself ...and the manpages for every tool, every config file, built-in units, and every type of unit, plus the extensive documents linked from https://wiki.freedesktop.org/www/Software/systemd/ https://wiki.freedesktop.org/www/Software/systemd/ , including a 21-part series of articles targeted at system administrators, a dozen more pages targeted at users and administrators about specific topics, several dozen documents for developers, a dozen videos... There are many criticisms you could reasonably throw at systemd, but "not well documented" certainly doesn't seem like one of them.
  - toast0 11y ago
    I recently put together a systemd system, here's a list of grievances compared to the previous setup: On boot, systems waits for two minutes or so for dhcp on an Ethernet interface with no cable, and it's not cancelable if I happen to be at the console On shutdown, it turns off swap before shutting down daemons; not an issue for my system because I don't expect swapping, but in what world does this make sense? Closing the lid sleeps the computer without configuration; some people might find this to be a good thing, but in my experience in the last 15 years, Linux only slept on lid closure if i was running software to handle that (acpid and/or something from a desktop environment), if i have apache running on an old laptop with no GUI, i expect it to stay on. (yes, there's a config, but its still annoying)
  - deckard1 11y ago
    it's like the face-hugger, from Alien(s). Once it gets into your distro, it impregnates it with a horror monster. An init should not be micromanaging every aspect of my system. I'm on arch now, but my next Linux will not have systemd or journald.
  - Elhana 11y ago
    Let's say we have a service, that needs network to be up and running. network.target won't work on boot, you start googling and find network-online.target that should do the trick, but it doesn't. Then you spend half an hour trying to figure out how to make it wait for dhcp config to finish for /etc/network/interfaces. In the end, either find that you need to enable some obscure service that waits for it and makes network-online.target actually work and enable it or you copy-paste it from somewhere on the internet and it is a shell script anyway. I'm not sure how you can you depend on network-online.target and be sure this network waiting services are properly enabled. With sysvinit you'd usually just put it on S99 and be done with it in most cases.
- rvern 11y ago
  I disagree. For every Fedora release, the Documentation Project prepares a new version of the System Administrator's Guide[1] and of five other high-quality manuals. These manuals are usually up-to-date, accurate and comprehensive, and since they are maintained in the DocBook format (which is very superior to wikimarkup for technical documents), they can be converted into HTML (for the version on docs.fedoraproject.org), PDF (for printing or viewing in a PDF reader) and EPUB (so I can put the guides on a e-reader and read them comfortably). The documentation is even translated in multiple languages. Debian has documentation of similar quality, with the Debian Reference[2] and the Debian Administrator's Handbook[3], which is more up-to-date. Also in DocBook, and all I said about the Fedora documentation applies as well. This will not be a popular opinion, but I don't think Arch Linux's documentation compares to Debian's and Fedora's. [1]: https://docs.fedoraproject.org/en-US/Fedora/23/html/System_Administrators_Guide/index.html https://docs.fedoraproject.org/en-US/Fedora/23/html/System_A... [2]: https://www.debian.org/doc/manuals/debian-reference/ https://www.debian.org/doc/manuals/debian-reference/ [3]: https://www.debian.org/doc/manuals/debian-handbook/ https://www.debian.org/doc/manuals/debian-handbook/
vezzy-fnord 11y ago
Arch isn't at all bare bones, that's more of an outdated humblebrag than anything else. Actually, neither is Slackware. I find sbopkg and SlackBuilds.org to be better than yaourt and AUR. sbopkg's UI is just top notch (ncurses-based). Slackware uses sysvinit with flat rc scripts as opposed to the traditional System V setup of numbered symlink farms. Much cleaner. Arch uses systemd. Slackware's pkgtools are much more minimalistic than pacman. They're shell functions that manage local tarballs. In addition, you have slackpkg for fetching remote updates. Slackware actually double-functions as both a rolling and stable release distribution. You can either set slackpkg to track -current, which is often bleeding edge yet surprisingly robust, or stick to official versions like 14.1. Slackware's installer and setup utilities are all ncurses-driven rather than pure CLI as in Arch. I actually find them much more capable. The only pure CLI part of installing Slackware is disk partitioning, the rest is a highly detailed TUI menu installer (similar to FreeBSD if you've tried that). Slackware has a very strict devotion to not patching upstream packages at all, with exceptions only in the most critical circumstances. This means that you're pretty much always using vanilla Linux userland as it is, and so if there's bugs, you report to upstream rather than to the distribution tracker. If you're a developer, this is great. Slackware's package management can alternate between binary and source-based. As such, I'd recommend Slack. It's venerable and rock solid.
massysett 11y ago
https://wiki.archlinux.org/index.php/Arch_compared_to_other_distributions https://wiki.archlinux.org/index.php/Arch_compared_to_other_...
delcaran 11y ago
I've been using Arch for two years before going back to Slackware. It was a good run, Arch is fun and easy to use and everything works very, very well. On the same laptop is even faster than Slackware (I did not run any test, it was just my perception after a fresh install... maybe because Arch has way less packages...). BUT Arch brokes often. Even when I look the news on the official website or search the forums for issues with recent updates, even when I check that everything is ok accordin to the (awesome, really awesome) docs, Arch brokes something. I grew reluctant to run "pacman -Syu". Now with Slackware I am 100% sure that my system will always work after every update, and if it doesn't work is because a simple new dependency that I can install in a couple of minutes if I want, or I simply keep the already installed package without any issues whatsoever.

by rifung 11y ago

How does Slackware compare to ArchLinux? They both seem to be very barebones and force you to learn more about Linux, but ArchLinux seems much more popular from what I gather.

EC1 11y ago

Slackware only took me 8 installs vs 15 for Arch.

anonbanker 11y ago
Gentoo only took me 2 installs vs. 8 for Slack

komaromy 11y ago

The Arch docs are superior (best that I've encountered in the Linux world) but Slackware is worth it to me to stay away from systemd.

coherentpony 11y ago
Out of curiosity, why don't you like systemd?
- komaromy 11y ago
  It felt too restrictive to me. Things were changing without me asking for them and that was preventing me from learning. One of the most egregious problems was forcing the change from text logs to journalctl binary logs.
  - JoshTriplett 11y ago
    > Things were changing without me asking for them and that was preventing me from learning. systemd has extensive documentation, both in manpages and in higher-level documents explaining how all the pieces fit together. I've generally found it far more straightforward to learn about than the components it replaces. > One of the most egregious problems was forcing the change from text logs to journalctl binary logs. You can keep a syslog implementation like rsyslog installed, and you'll continue to have text logs too. And journalctl outputs plain text.
    - dijit 11y ago
      You can also make rsyslog work on windows, doesn't mean it's supported or encouraged.. people seem to have this analogue of "you can configure away the bad bits" but in the end the bad bits are orthogonal to it's design and 'bypassing' them or hacking around them should not be encouraged- it should be able to be done by default.
      - JoshTriplett 11y ago
        > people seem to have this analogue of "you can configure away the bad bits" Where in my comment did I imply that the journal was "bad"? The journal is awesome. But if you have some workflow designed around syslog, such as a log analyzer or statistics package that you don't want to tweak, text logging still works just fine.
        thiagowfx 11y ago
        "bad" is just a metaphor in this context
    - anonbanker 11y ago
      systemd only has extensive documentation if you count the source code itself. otherwise, most people are left guessing for things above a "systemctl restart"
      - JoshTriplett 11y ago
        > systemd only has extensive documentation if you count the source code itself ...and the manpages for every tool, every config file, built-in units, and every type of unit, plus the extensive documents linked from https://wiki.freedesktop.org/www/Software/systemd/ https://wiki.freedesktop.org/www/Software/systemd/ , including a 21-part series of articles targeted at system administrators, a dozen more pages targeted at users and administrators about specific topics, several dozen documents for developers, a dozen videos... There are many criticisms you could reasonably throw at systemd, but "not well documented" certainly doesn't seem like one of them.
- toast0 11y ago
  I recently put together a systemd system, here's a list of grievances compared to the previous setup: On boot, systems waits for two minutes or so for dhcp on an Ethernet interface with no cable, and it's not cancelable if I happen to be at the console On shutdown, it turns off swap before shutting down daemons; not an issue for my system because I don't expect swapping, but in what world does this make sense? Closing the lid sleeps the computer without configuration; some people might find this to be a good thing, but in my experience in the last 15 years, Linux only slept on lid closure if i was running software to handle that (acpid and/or something from a desktop environment), if i have apache running on an old laptop with no GUI, i expect it to stay on. (yes, there's a config, but its still annoying)
- deckard1 11y ago
  it's like the face-hugger, from Alien(s). Once it gets into your distro, it impregnates it with a horror monster. An init should not be micromanaging every aspect of my system. I'm on arch now, but my next Linux will not have systemd or journald.
- Elhana 11y ago
  Let's say we have a service, that needs network to be up and running. network.target won't work on boot, you start googling and find network-online.target that should do the trick, but it doesn't. Then you spend half an hour trying to figure out how to make it wait for dhcp config to finish for /etc/network/interfaces. In the end, either find that you need to enable some obscure service that waits for it and makes network-online.target actually work and enable it or you copy-paste it from somewhere on the internet and it is a shell script anyway. I'm not sure how you can you depend on network-online.target and be sure this network waiting services are properly enabled. With sysvinit you'd usually just put it on S99 and be done with it in most cases.
rvern 11y ago
I disagree. For every Fedora release, the Documentation Project prepares a new version of the System Administrator's Guide[1] and of five other high-quality manuals. These manuals are usually up-to-date, accurate and comprehensive, and since they are maintained in the DocBook format (which is very superior to wikimarkup for technical documents), they can be converted into HTML (for the version on docs.fedoraproject.org), PDF (for printing or viewing in a PDF reader) and EPUB (so I can put the guides on a e-reader and read them comfortably). The documentation is even translated in multiple languages. Debian has documentation of similar quality, with the Debian Reference[2] and the Debian Administrator's Handbook[3], which is more up-to-date. Also in DocBook, and all I said about the Fedora documentation applies as well. This will not be a popular opinion, but I don't think Arch Linux's documentation compares to Debian's and Fedora's. [1]: https://docs.fedoraproject.org/en-US/Fedora/23/html/System_Administrators_Guide/index.html https://docs.fedoraproject.org/en-US/Fedora/23/html/System_A... [2]: https://www.debian.org/doc/manuals/debian-reference/ https://www.debian.org/doc/manuals/debian-reference/ [3]: https://www.debian.org/doc/manuals/debian-handbook/ https://www.debian.org/doc/manuals/debian-handbook/

vezzy-fnord 11y ago

Arch isn't at all bare bones, that's more of an outdated humblebrag than anything else. Actually, neither is Slackware. I find sbopkg and SlackBuilds.org to be better than yaourt and AUR. sbopkg's UI is just top notch (ncurses-based). Slackware uses sysvinit with flat rc scripts as opposed to the traditional System V setup of numbered symlink farms. Much cleaner. Arch uses systemd. Slackware's pkgtools are much more minimalistic than pacman. They're shell functions that manage local tarballs. In addition, you have slackpkg for fetching remote updates. Slackware actually double-functions as both a rolling and stable release distribution. You can either set slackpkg to track -current, which is often bleeding edge yet surprisingly robust, or stick to official versions like 14.1. Slackware's installer and setup utilities are all ncurses-driven rather than pure CLI as in Arch. I actually find them much more capable. The only pure CLI part of installing Slackware is disk partitioning, the rest is a highly detailed TUI menu installer (similar to FreeBSD if you've tried that). Slackware has a very strict devotion to not patching upstream packages at all, with exceptions only in the most critical circumstances. This means that you're pretty much always using vanilla Linux userland as it is, and so if there's bugs, you report to upstream rather than to the distribution tracker. If you're a developer, this is great. Slackware's package management can alternate between binary and source-based. As such, I'd recommend Slack. It's venerable and rock solid.

massysett 11y ago

https://wiki.archlinux.org/index.php/Arch_compared_to_other_distributions https://wiki.archlinux.org/index.php/Arch_compared_to_other_...

delcaran 11y ago

I've been using Arch for two years before going back to Slackware. It was a good run, Arch is fun and easy to use and everything works very, very well. On the same laptop is even faster than Slackware (I did not run any test, it was just my perception after a fresh install... maybe because Arch has way less packages...). BUT Arch brokes often. Even when I look the news on the official website or search the forums for issues with recent updates, even when I check that everything is ok accordin to the (awesome, really awesome) docs, Arch brokes something. I grew reluctant to run "pacman -Syu". Now with Slackware I am 100% sure that my system will always work after every update, and if it doesn't work is because a simple new dependency that I can install in a couple of minutes if I want, or I simply keep the already installed package without any issues whatsoever.