Originally Posted by SqdnGuns

Anyone got any Preparation H?

Originally Posted by ReaperX7

Okay dependency resolution. Let's start from here and take it easy.

The reason Slackware doesn't perform automatic resolution is because it involves a lot more resources than Patrick has at hand. Slackware, while being a mainstream distribution is also a minimalist and private distribution. Look at how many people it takes to care for Debian, well over a few dozen to maybe a hundred or so people constantly checking and rechecking packages. This why Debian is slow to release new versions because the Testing branches are slow to spin out stable software.

Slackware also has more of a Linux From Scratch attitude towards dependencies. Originally before programs like apt-get, pacman, and such came along everything was built by hand using makefiles and often during configuration, you'd hit a snag like libgtk2.so.2.4.9 was not found, for example. You would then need to track down what package had that, build it, and then see what else might be missing until it finally built.

Slackware follows this model but only slightly by releasing prebuilt packages usually with all needed dependencies. As a system, Slackware is small but has all it needs for everything, the rest is community maintained like SlackBuilds.org. This offloads Patrick and Slackware by a lot to reduce overburden. No huge database is needed, no extra compatibility checks are required, and 99% of the time everything works out of the box.

The reason we have SlackBuilds is to allow the community to assist the system. By design SlackBuilds lists dependencies for packages, if they are needed. All you have to do is download the build script package and the source tarball, place the tarball in the directory with the extracted build tool, run it, and later manually install the package.

By teaching you the user/admin to resolve dependencies on your own end, you learn how to search for dependencies often for packages that aren't in SlackBuilds. In fact many packages out there are obscure enough to not have SlackBuilds, but that means as a user/admin you have to learn what to look for. By teaching you to build your own packages and resolve things on your end when all else fails, when you transition to builds that have managed systems, like Arch for example, you can know what to look for when a package calls for something that may not be provided, and that you can provide it yourself.

By teaching you, you learn how to work without automation and learn fundamentals of the system and what is needed to make things work.

For instance, if Ubuntu suddenly had a massive FTP failure and suddenly no packages were available, but you needed to install a package that had dependencies, how would you know what to do if you didn't know what to do? You'd be lost. By knowing how to look for dependencies, resolve them, and self-maintain your system, you learn more about how to build a system without being spoonfed.

Originally Posted by damgar

I thought it might be worth mentioning: Floppies are actually REALLY handy when you need them. My current machine, without Windows on bare metal is a real PITA to flash the BIOS. It was a tense moment flashing the BIOS with option C. My "server" still has a floppy drive too and if I were to ever need to flash the bios there, I'm absolutely sure that it can only be done from a floppy. That machine may be old (Celeron chip, 1GB DDR1 RAM) but with Slackware it does everything I need it to do as a webserver, DLNA server, file server, and local -current mirror, as well as running periodic backups.

To quote Mike Muir and Suicidal Tendencies, "Just because you don't understand it don't mean it don't make no sense, and just because you don't like it don't mean it ain't no good." The rest of that quote probably applies too, but I digress.

Originally Posted by SqdnGuns

Anyone got any Preparation H?

Originally Posted by T3slider

Slackware is the only big distro without dependency resolution. By taking it away you leave those who don't want dependency resolution with nothing (with the exception of LFS). If dependency resolution is optional, it essentially mandates that those who don't want to use dependency resolution are locked out of the official or unofficial repositories. slackpkg being officially integrated into Slackware represented a major shift in package maintenance, and represents increased ease of use while making little if any assumptions (for example, when running install-new or upgrade-all you are presented with a list of packages to check/uncheck instead of just doing it). Third-party repositories like SlackBuilds.org, as well as sbopkg for managing those SlackBuilds, are major changes that have greatly increased the efficiency of installing third-party software on Slackware making virtually no compromises. You can insist that Slackware hasn't changed at all but just saying it doesn't make it true.


This will never, ever happen. We stand on the shoulders of giants; there will always be a need to depend on others' code unless you want to insist on reinventing the wheel for each project, which would slow development to a crawl and devastate both open- and closed-source programming. The question of static vs. dynamic linking is a valid one but neither is perfect. You can choose to favour all-static like Windows, making every binary huge and consuming immensely more RAM for each program, or all- or mostly-dynamic, which reduces RAM usage and can ship smaller binaries but requires dependencies to be met. This is NOT an issue of poor coding and suggesting such an idea shows a fundamental lack of understanding.

Perhaps you lack the empathy to understand things from our point of view. Let me try to explain it. We are already using Slackware. Most of the users in this forum did not blindly choose Slackware -- they know something about other distributions as well. We already know the strengths and weaknesses of Slackware but have decided that *for us* Slackware is the best fit. If someone suggests that perhaps more transparency is needed regarding Slackware, I would say that is a valid criticism (though not one that I expect to change much). For example, there is no SlackBuild for Slackware's kernel headers and it is unclear where they come from. Obviously Pat packages them up but there was a discussion quite a while ago now that brought up some legitimate criticism. The documentation issue is also valid -- the Slackbook has been in the process of being rewritten seemingly forever and this is a real problem. Of course, despite all the complaints little has been done to rectify the situation (though the Slackbook is in beta). What *you* are asking for is a complete modification of Slackware's core principles. If you fundamentally disagree with a distribution's core principles, you should not be using that distribution. This is my opinion only, of course. I don't always agree with Slackware's implementation but because its principles mostly fall inline with what I desire, it is the best fit for me. *THIS* is why you get such a negative response when you make criticisms to the core of Slackware itself.

The lack of good third-party packages led to the creation of slackbuilds.org. The desire for more efficient management of SlackBuilds led to the creation of sbopkg. The desire for a fully integrated manager of official package updates led to adoption of slackpkg. The Slackware community is open to suggestions and additions as long as they do not violate certain principles. Again, if you want to fundamentally change the way Slackware works, then why are you using it in the first place?

RedHat is focused heavily on enterprise and support. I don't think Slackware has ever tried or wanted to emulate RedHat. They are two different things entirely and the comparison isn't appropriate.

As for floppy disk support...the floppy package takes up 850K uncompressed and all of the floppy disk support in its entirety likely takes up a few megabytes at most. You gain nothing but may lose something by excluding it. If it costs nothing then why not include it? Just don't use floppy disks if you don't want to use floppy disks.

Originally Posted by Mercury305

There is nothing not to understand about a bunch of empty folders that you don't use.
Redhat doesnt have any folders in /mnt. Why? Because you determine what to mount. In my eyes that is nothing but "clutter". Notice I replied to you because I did not find this comment negative towards my character. Even though your last quote was targeting me.

Originally Posted by Mercury305

I am sure there are ways to add "Automation" without getting in the way of "User Control and Flexibility".

Originally Posted by Mercury305

My biggest problem is the dependency resolution thing. Its just unlogical. You can't just say it messes things up and not use it. At least give an option to use it.

Until Coding improves and there is no need for dependencies I find this a minus. Because eventually you are going to end up looking for a dep of a new program that you can't find.

Originally Posted by jhw

What's wrong with "rmdir /mnt/*" ?

You see, Slackware (besides LFS) in my opinion is the distro, which makes it very easy for the user to change all the criticism you brought on. It doesn't assume anything from the user, just comes with a basic set of software and makes it very easy to add other stuff.

The dependency issue actually isn't an argument for me anymoe. I have been able to add any software with very few extra dependencies, since Slackware already provides the most basic ones. If you don't like a package that ships with Slackware, remove it. If you don't like the way a package is shipped with Slackware, change it. All necessary tools are already there. If you desperately need dependency resolution try slaptget or use a different distro, Slackware is not for you. Just as any distro that has dependency resolution is not for me. But I don't complain about it to them.

Documentation isn't an issue either. Basically, the only documentation you need, is about the Slackware pkgtools. And that documentation is very well. Searchin any other documentation? Refer to the ones provided by upstream. Since Slackware uses mostly vanilla software and doesn't apply patches unless there is no other way around, all standard documentation applies. Acutally, that is one thing what bugs me about Debian. Ever tried to configure a Debian Apache httpd with upstream documentation? Good luck!

Support: It's been stated already. The IRC channel and especially this forum are great sources of support. You want official or even commercial support? Go ahead and buy Red Hat or SuSE. Even Debian doesn't provide official/commercial support for it's distro.


Just my 2 cents ...

Originally Posted by Mercury305

What if Slackbuilds go down? Where are the alternate ftps like in auto dep. management of many other distros?Also compare the repo of Slackware to other distros... Slack is Slacking in that area.

Originally Posted by Mercury305

Doc is an issue if you compare to FreeBSD or Arch.... which is where I can learn stuff.

Originally Posted by Mercury305

OK, I guess some of you prefer to manually do the dependency thing. Maybe after more experience I will get a hang of it too but so far it makes no sense to me to manually download them from slackbuilds. What if Slackbuilds go down? Where are the alternate ftps like in auto dep. management of many other distros? Also compare the repo of Slackware to other distros... Slack is Slacking in that area.

Doc is an issue if you compare to FreeBSD or Arch.... which is where I can learn stuff.

Also I am not the biggest Redhat Fan. I am pretty aware of its many flaws. If I was so happy with it... I would not be in this Slackware forum.

Originally Posted by jhw

I have started to maintain my own repository of Slackbuilds. I just go ahead and download the stuff from slackbuilds.org (not using sbopkg), build them on one machine, put them in a central place and can access them whenever I need them. I even put in a textfile called 'depends' which just states all Slackware external dependencies needed for this package. So, if I wanted to, I could even come up with automatic dependency resolution for my own packages.


I second you on that. The documentation of FreeBSD is outstanding (don't know about Arch). However, there are more people working on those distros than on Slackware. Personally, I did not have any problems with the lack of documentation. Since Slackware itself pretty much only consists of shellscripts and I am perfectly able to read those, they are my documentation. For all the other software, just as stated, I just use upstream documentation.