Hogwash
|
| Author | Content |
|---|---|
| caitlyn Nov 03, 2010 4:47 PM EDT |
I read this sort of thing by Slackware fans all the time and I really, really, really do not get it. How on earth does not having automated dependency resolution make Slackware more stable? How does it result in fewer problems? Down time? What down time? I primarily use two distros: SalixOS, basically Slackware plus extra packages, tools, and dependency resolution, and Red Hat Enterprise Linux (or it's free clones). Both SalixOS and RHEL are rock solid, stable, and just run and run. Sorry, folks, but this is nonsense. |
| Koriel Nov 03, 2010 5:54 PM EDT |
I disagree caitlyn, been using Slack since 96 in a server capacity, once you get it built to your liking it stays that way. The number of times some dependency manager has screwed up on the countless other distros i have used well i lost count and Linux Mint 9 has a doozy of one that can seriously screw your system if you use the Mint Software manager to remove software instead of Synaptic as it doesnt warn of dependency issues which is a prime example of a possible disaster in the making, it is not nonsense as you put it. That doesnt mean to say i dislike distros with full dependency package management i dont i love them for the desktop i just dont think its wise to rely on them to heavily on them on the server side of things. I also like that fact that Slack still seems to be attracting for want of a better term newbies to its fold. |
| gus3 Nov 03, 2010 6:34 PM EDT |
From the flip side: Last week, I accidentally upgraded the i486 glibc packages onto my desktop, Slackware64-current(*). There is no faster way to bring a *nix system to its knees, than to muck with glibc, and that's what I did. PEBCAK. Fortunately, I had a mini-root install CD which made it possible to install the correct package from an NFS mount. OTOH, improper dependency resolution shows that there's just one more thing to break. In 2001 I managed to put a Gentoo system into a state where it couldn't be upgraded, because libffi broke during its upgrade. No libffi meant no gcc, which meant no upgrades except for scripting language stuff (Perl, Python, etc.). Dependency resolution with Fedora? Yikes. What if I manage to muck w/ a bad glibc package? Sure, I can do a live CD boot, force RPM to install to an alternate root, and then remove the bad glibc. How do I know that the RPM database is in sync with the actual on-disk files? Like I said, one more thing to break. If the system is going to break, I'd like to be the one to break it. It's easier to fix that way, and I'd rather cuss myself out than cuss at the computer. (*)Yes, -current is officially "unstable, unsupported," but in 7 years of using it I've been bitten only once. However, Slackware releases aren't released ready-or-not like Ubuntu, neither do they get so old as to be stale like Debian. If you stick with a Slackware release plus the updates in -patches, the base system will be incredibly stable. But Caitlyn is correct, that is not from lack of package management, it's from Patrick's philosophy underpinning Slackware. |
| jdixon Nov 03, 2010 10:21 PM EDT |
As far as I could tell, the author has no idea that sbopkg exists. I added a comment with a link to it, but it's awaiting moderator approval. Sbopkg makes installing slackbuild.org packages about as simple as pkgtool makes binary packages. |
| hkwint Nov 04, 2010 5:00 AM EDT |
It boils down to knowing what the package manager is doing and why, I guess. One could see the package manager as an 'automated way of what the Slackware-user is doing manually'. Or one could see it as a separate complex beast with life of its own. Making a backup before upgrading still is a good idea I think, even if you know what you're doing and doing it manually. So, to attempt to answer the original question, Quoting:How on earth does not having automated dependency resolution make Slackware more stable I'd say it forces the user of knowing what one is doing, and how to revert if something goes wrong. On systems with lots of packages, I think manually entering configuration options and keeping track of everything is more error prone than letting some package manager handle it. |
| zentrader Nov 04, 2010 1:29 PM EDT |
I recently wanted to add a package to my Slackware system. The dependencies were most of the Gnome system. I decided to go another route. |
| jdixon Nov 04, 2010 7:00 PM EDT |
> The dependencies were most of the Gnome system... Then either install Gnome Slackbuild, or use a distribution the Gnome folks choose to support. |
| hkwint Nov 04, 2010 7:16 PM EDT |
No sets? |
| gus3 Nov 04, 2010 7:34 PM EDT |
@hans: Not in Slackware any more. Patrick doesn't use it regularly, and it was a lot of hassle at every release to try to test Gnome enough to deem it ready. Since there were a couple other Gnome-on-Slackware projects at the time, he decided to drop it and simplify the release process. It also made for smaller releases, for a while at least. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!