I ran it for many years (and still do on a couple smaller machines). It has been exceptionally stable and thankfully devoid of "surprises" (using the word in its worst possible connotation). Things stay exactly as you leave them, it's exceptionally rare for any package to have been "customized" and nothing happens in the system unless you explicitly asked for it / made it happen. This used to be true for the initial setup too, which made it a bit scary to newbies - but since quite a few years that's become a painless experience.
It's simple so it's somewhat easy to take apart and re-purpose. I was able to use it to build an internet enabled kiosk for instance without a lot of extra weight. It's super stable also so it make a good server. Lack of package management means you won't find it in the standard VM distro line up though.
As for other uses... using it to reply to this comment right now.
There is no lack of package management. There is a lack of automatic dependency resolution without third-party additions. This is nowhere near as debilitating as often presented by outside observers who have never tried the distribution.
YMMV, but I've ran into circular dependencies and conflicts in addition to configuration updates rendering systems unbootable multiple times on distros like Debian with their non-transactional resolution heuristics that make your life easier, until they don't. Slackware's spartan package management has not failed me once, it's rock solid no matter how much you thrash your file system hierarchy. In addition, when I want to install SlackBuilds, I have never used a more convenient package manager than sbopkg before. Dependencies can be cleanly recorded and built with queuefiles.
Let whoever wants downvote me, but I'd just like to bring people's attention to what your 2nd paraghraph says.
...to me it often is Ubuntu's apt breaking itself (and even reporting this back with cheerfullness I cannot understand) just in time for a save-home-dir-then-wipe-and-install-latest-ubuntu action sequence :)
Slack has package management. It doesn't do automatic dependency management. That said, Slack's packages are built in such a way to make dependency resolution relatively painless to the point where it's almost a non-issue.
Really? How so? How is dependency resolution managed to the point that it's relatively painless without resorting to automatic dependency management? I'm not saying I don't believe you, I'm just curious. Slackware was the first distribution I ever used oh so many moons ago that I've forgotten how it all worked. Ah sweet nostalgia as someone else mentioned.
Libraries are built as a single package, not split into separate "-dev" packages with headers, so there are fewer packages to manage. Also, these days it's easy to just install the whole of Slackware for a desktop system (when even an SSD is hundreds of gigabytes, a few gigs is no hardship.) So when you do need to build third party applications, your system probably already has what you need. Slackware already comes with a good set of the major libraries, even if they're not GNU (pcre, for example.)
Slackbuilds.org will tell you if one of the packages there has dependencies that aren't in Slackware. Typically installing them is not onerous.
IMO, Slackware is canon. Other distros do great things, but Slackware is the only distro (again to me), that is pure linux in it's look and feel.
Practically, it's barebones and basic yet functional enough to do whatever is needed. It's extremely easy to make Slackware into whatever kind of system you're looking for from desktop to server.
Anything you want from a GNU/Linux-based operating system. Slackware is a great base operating system and its simplicity is its strength. For me it was very easy to get familiar with and feel at home in.
One thing that it has over probably all other distributions is its stability in terms of software selection. It still defaults to Lilo over Grub, it didn't switch to systemd, and installing Slackware 15 or 14.2 when it comes out will be exactly the same experience as installing slackware 14.1, or just about any version preceding it, I'm sure of it. :)
It has one thing to make it genuinely notable: it's the oldest surviving Linux distribution out there.
I run an entire data center of Slackware Linux on Dell servers. My entire EMail and Web hosting platform is Slackware. I have ~30 Slackware Linux boxes. My installs are very stripped down. I.E. I don't install any of the KDE, Gnome or X stuff. I also remove the games and many of the stock applications that ship with Slackware.
I hate Ubuntu, RedHat, etc... Everytime I use them, I feel like I'm fighting the GUI. Ubuntu, for example, I could never figure out how to change the IP address without using the KDE GUI. On Slackware it's as easy as editing /etc/rc.d/rc.inet1.conf
I resist Ubuntu, RedHat, etc... because it forces you to become familiar with that distro's way of doing things. And there in lies the rub. As more and more distributions of Linux come about, I see a fragmented Linux world.
So, in short, I guess you could say I stuck with what I learned and know from years back. I know that at start up, the stuff inside /etc/rc.d/inet1.conf are parsed and fed to ifconfig for static IPs.
Eric Hameleers is a awesome. As a Slackware user his blogs and tips have been helping me for years.
"we are well equipped to keep systemd out of our distro for a while" Win!
This certainly isn't the first live Slackware though. Slax is how I first came to really experiment with Linux internals. It was a cool little tiny distro on a live USB. I was able to take stuff apart and build my own kernel etc without borking my real machine. I made several derivatives and even re-wrote the "live scripts" when the author took a hiatus around 2010. I learned so much from Slax.
Ahh you beat me to it (it being praising Eric Hameleers) :P Slackware is a better operating system thanks to Eric. Native Steam, multilib, leave it to Eric to make these things simple for others to use. I owe the man more beers than I can afford. :)
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.
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.
> 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.
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.
> 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.
systemd only has extensive documentation if you count the source code itself. otherwise, most people are left guessing for things above a "systemctl restart"
> 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/ , 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.
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)
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.
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.
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.
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.
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.
Slackware was my first experience with Linux. So long ago now, I am 31 now but was 12 when I was first shown Linux and I was hooked from there. Like most I have been around the block with many different Linux distros over the years, even a scary few years doing stage 1 Gentoo. I will always be fond of Slack though. Patrick and his work will always have a very special place in my life, I do not doubt I would have gone into technology anyway (seems to be in my DNA) but Patrick and Slackware was such a huge part of what I first remember of truly learning.
Sorry this post is a little off-topic, it is Sunday afternoon and I guess I am feeling sentimental or something ;)
I was "a bit" older when I picked up a copy of Slackware back in '95. I was working doing C development on a number of *nix and other platforms (most of which are gone now), and needed something better for working from home than a 16 bit compiler on MS-DOS.
Slackware felt MUCH more powerful than the SCO x86 OS we had at work, and having a desktop GUI was just gravy, rather than worrying about anything being "ready for the desktop".
Delicious irony 20 years later: the mobile era. Apple, yet again, makes really good devices. However, the most numerous devices are now Linux/Android. Now we have to ask "Is Microsoft ready for mobile", but it's too late, and the answer is "nobody cares".
God, it feels so good to watch Linux kick the crap out of MS, after all those years of putting up with their slow/buggy OS's and development torment-ware.
Well yes but my Android phone (Nexus 4) really feels like Windows 98 though : security is an illusion and it crashes (reboot) for no apparent reason (I believe it doesn't like to be put in Airplane Mode while I sleep).
Let's not talk about my desktop Linux experience which is not stellar either.
Honestly if it weren't for the telemetry updates I'd be a happy Windows user.
I didn't mention Apple since I can't afford what they think people should pay for their devices.
i tried many times to convince myself that i can live
without automatic package dependencies
but failed
i love the legacy of slackware, the brand
but its more of an emotional thing
at the end, i use kubuntu, ubuntu based distros have
access to ppa(s) which really make life a lot easier
for linux on the desktop
hopefully one day slackware will
give up and add automatic management for package dependencies
but until that day, its too hardcore, i dont have
that kind of time
I moved from Slackware to Kubuntu too, but as I recall Slack had something - maybe slackpkg - that did dependency installation. I jumped ship for the breadth of packages available and automatic kernel module compilation (I forget what it's called at the moment; recompiling nvidia video modules was getting to be a pain and I needed to keep the family computer online consistently).
slapt-get (http://software.jaos.org/) does, but it needs repo that has dependency metadata. Official repos don't have it. If a repository doesn't have dependency metadata then slapt-get doesn't resolve deps for that set of packages.
Some other repos (AlienBob's for instance) do have dependency metadata, which assume that you did a full Slackware install, so only dependencies that aren't part of Slackware are listed.
There is also slapt-src (same URL) that automates installing stuff from http://slackbuilds.org/, and it resolves dependencies. It's not fullproof, but is good enough (for me, at least).
There's a new repo on http://slackonly.com/ which offers binary packages built from scripts on slackbuilds, and it looks like it has dependency metadata. I can't vouch for the quality of those packages, I haven't used it yet.
UPDATE:
After skimming through PACKAGES.TXT for a few minutes, I'm not confident that slackonly repo has all dep. metadata correct, but hopefully they'll get better with it soon.
Ah, you're right it was slapt-get that I used; it convinced me that apt-get was really good, part of the reason I moved despite up to then being more familiar with compiling my own (yay for checkinstall) or using yum.
What do you think dependency management would bring to slackware?
I remember, back in 2001 or so, how bad package management was.
yum didn't exist, apt-get was not widely deployed. You were stuck with rpm and dpkg. You should spend a few days forcing yourself to just use those two commands and see how much you hate life.
I used to install systems (up to Mandrake 6.1) via RPM, then give up on package management entirely, in order to compile Enlightenment and GNOME (and much of rawhide!) from source. Eventually, I gave up on installing binaries altogether on these systems, because it was easier to manage upgrades from source.
Now, as a lazy old man, I've switched to gentoo ebuilds, which are glorified scripts that bring just enough dependency management to not get in the way.
I used Slackware for several years as my main desktop machine. I never ran into dependency issues. You have to understand that the Debian et al approach of having dozens of small packages for everything you want to install is not universal.
I have often read "I don't have the time for Slackware." In all honesty, I spent way less time on the OS with Slackware. The quality was much higher, there was never a need to wait months for a bug fix because someone forgot to link something in, and it was really easy to build my own packages.
I eventually left because slackbuilds.org was not being run very well and I couldn't get the packages I needed. But the dependency issue was not a concern at all.
> I eventually left because slackbuilds.org was not being run very well and I couldn't get the packages I needed
I'd be interested to hear more about that if you're willing to share. Let's see if we can do something positive to fix it, even if it's too late to help you personally.
The biggest thing was that SlackBuilds weren't being updated for the new release. There was also some unfriendliness in the mailing list related to getting it fixed (in general, nothing I experienced). I don't remember exactly what it was though. This was quite a while back - probably 13.1 or 13.37.
Thanks. FYI, for the upcoming 14.2 release we have an officially unofficial repo with hundreds of fixes for 14.2 ready to go (and hundreds more needed).
I'll admit I get a little tetchy when people insist on telling me 'xxx is broken on -current' when I already know exactly which 400+ packages are broken, and when everybody should understand that -current is for beta testers.
I'm using slackware (full install) with sbopkg and slackpkg+, and I needed to run a dependency check only once, when a package I already had installed from sbopkg had a new dependency.
All other times (2 years) I haven't run in any issue with dependencies, not even once.
60 comments
[ 4.1 ms ] story [ 136 ms ] threadIn that sense it is practical, not sure if "notable" as there are many other more popular distributions these days.
Its learning potential is very large.
As someone once wrote:
Study RedHat, you will have learned RedHat
Study SuSE, you will have learned SuSE
Study Slackware, you will have learned Unix.
As for other uses... using it to reply to this comment right now.
There is no lack of package management. There is a lack of automatic dependency resolution without third-party additions. This is nowhere near as debilitating as often presented by outside observers who have never tried the distribution.
YMMV, but I've ran into circular dependencies and conflicts in addition to configuration updates rendering systems unbootable multiple times on distros like Debian with their non-transactional resolution heuristics that make your life easier, until they don't. Slackware's spartan package management has not failed me once, it's rock solid no matter how much you thrash your file system hierarchy. In addition, when I want to install SlackBuilds, I have never used a more convenient package manager than sbopkg before. Dependencies can be cleanly recorded and built with queuefiles.
http://idlemoor.github.io/slackrepo/index.html
...to me it often is Ubuntu's apt breaking itself (and even reporting this back with cheerfullness I cannot understand) just in time for a save-home-dir-then-wipe-and-install-latest-ubuntu action sequence :)
Slackbuilds.org will tell you if one of the packages there has dependencies that aren't in Slackware. Typically installing them is not onerous.
Practically, it's barebones and basic yet functional enough to do whatever is needed. It's extremely easy to make Slackware into whatever kind of system you're looking for from desktop to server.
One thing that it has over probably all other distributions is its stability in terms of software selection. It still defaults to Lilo over Grub, it didn't switch to systemd, and installing Slackware 15 or 14.2 when it comes out will be exactly the same experience as installing slackware 14.1, or just about any version preceding it, I'm sure of it. :)
It has one thing to make it genuinely notable: it's the oldest surviving Linux distribution out there.
I hate Ubuntu, RedHat, etc... Everytime I use them, I feel like I'm fighting the GUI. Ubuntu, for example, I could never figure out how to change the IP address without using the KDE GUI. On Slackware it's as easy as editing /etc/rc.d/rc.inet1.conf
I resist Ubuntu, RedHat, etc... because it forces you to become familiar with that distro's way of doing things. And there in lies the rub. As more and more distributions of Linux come about, I see a fragmented Linux world.
So, in short, I guess you could say I stuck with what I learned and know from years back. I know that at start up, the stuff inside /etc/rc.d/inet1.conf are parsed and fed to ifconfig for static IPs.
my 2 cents...
"we are well equipped to keep systemd out of our distro for a while" Win!
This certainly isn't the first live Slackware though. Slax is how I first came to really experiment with Linux internals. It was a cool little tiny distro on a live USB. I was able to take stuff apart and build my own kernel etc without borking my real machine. I made several derivatives and even re-wrote the "live scripts" when the author took a hiatus around 2010. I learned so much from Slax.
http://mirrors.edgeorbis.com/distros/slackware-live/
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.
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.
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.
...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/ , 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.
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)
With sysvinit you'd usually just put it on S99 and be done with it in most cases.
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_A... [2]: https://www.debian.org/doc/manuals/debian-reference/ [3]: https://www.debian.org/doc/manuals/debian-handbook/
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.
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.
Sorry this post is a little off-topic, it is Sunday afternoon and I guess I am feeling sentimental or something ;)
Slackware felt MUCH more powerful than the SCO x86 OS we had at work, and having a desktop GUI was just gravy, rather than worrying about anything being "ready for the desktop".
God, it feels so good to watch Linux kick the crap out of MS, after all those years of putting up with their slow/buggy OS's and development torment-ware.
Let's not talk about my desktop Linux experience which is not stellar either.
Honestly if it weren't for the telemetry updates I'd be a happy Windows user.
I didn't mention Apple since I can't afford what they think people should pay for their devices.
i love the legacy of slackware, the brand but its more of an emotional thing
at the end, i use kubuntu, ubuntu based distros have access to ppa(s) which really make life a lot easier for linux on the desktop
hopefully one day slackware will give up and add automatic management for package dependencies but until that day, its too hardcore, i dont have that kind of time
slapt-get (http://software.jaos.org/) does, but it needs repo that has dependency metadata. Official repos don't have it. If a repository doesn't have dependency metadata then slapt-get doesn't resolve deps for that set of packages.
Some other repos (AlienBob's for instance) do have dependency metadata, which assume that you did a full Slackware install, so only dependencies that aren't part of Slackware are listed.
There is also slapt-src (same URL) that automates installing stuff from http://slackbuilds.org/, and it resolves dependencies. It's not fullproof, but is good enough (for me, at least).
There's a new repo on http://slackonly.com/ which offers binary packages built from scripts on slackbuilds, and it looks like it has dependency metadata. I can't vouch for the quality of those packages, I haven't used it yet.
UPDATE: After skimming through PACKAGES.TXT for a few minutes, I'm not confident that slackonly repo has all dep. metadata correct, but hopefully they'll get better with it soon.
http://dawnrazor.net/sbotools/
https://github.com/dslackw/slpkg
It's called DKMS, a Dell project originally: https://en.m.wikipedia.org/wiki/Dynamic_Kernel_Module_Suppor...
I remember, back in 2001 or so, how bad package management was.
yum didn't exist, apt-get was not widely deployed. You were stuck with rpm and dpkg. You should spend a few days forcing yourself to just use those two commands and see how much you hate life.
I used to install systems (up to Mandrake 6.1) via RPM, then give up on package management entirely, in order to compile Enlightenment and GNOME (and much of rawhide!) from source. Eventually, I gave up on installing binaries altogether on these systems, because it was easier to manage upgrades from source.
Now, as a lazy old man, I've switched to gentoo ebuilds, which are glorified scripts that bring just enough dependency management to not get in the way.
I have often read "I don't have the time for Slackware." In all honesty, I spent way less time on the OS with Slackware. The quality was much higher, there was never a need to wait months for a bug fix because someone forgot to link something in, and it was really easy to build my own packages.
I eventually left because slackbuilds.org was not being run very well and I couldn't get the packages I needed. But the dependency issue was not a concern at all.
I'd be interested to hear more about that if you're willing to share. Let's see if we can do something positive to fix it, even if it's too late to help you personally.
I'll admit I get a little tetchy when people insist on telling me 'xxx is broken on -current' when I already know exactly which 400+ packages are broken, and when everybody should understand that -current is for beta testers.