I'm not sure what you expect. Your constructive criticism is "to remove unnecessary stuff" and "more support". If you have some clearly defined and well thought out criticisms or suggestions I'm sure the Slackware team would be happy to hear about them. If you're going to come in with hand-wavey criticisms and a snarkey attitude you're going to get shot down pretty fast.

Go mount floppy0 for me ... just in case it doesnt work how about mount floppy1 and floppy2 or even zipdisk... nvm im done... a distro that can't even take "constructive criticism" is just ... dead.

Time to move on... This is like joining the subgenius cult.

1 members found this post helpful.

Don't want to post, don't post. This board was here before you arrived, will be here after you're gone.

2 members found this post helpful.

Merc let's take it down a notch and try and discuss this out... this means everyone also that we try and avoid fighting.

Tell us some of the shortfalls you've had with Slackware in full detail. Be specific yet aptly detailed.

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.

Look you don't have to agree with me. Some people do and some don't. The ones that don't switch to other distros and are not here to talk about it. Which is what I should be doing. At least you Reaper have a lot more common sense then the rest of the zealotic behaviour in this forum. This Cattle Like mentality is something that should be shunned especially in a Slackware forum. Ironically it is the opposite. Its like a gang or cult in here. I think that is the 1st Change that needs to happen to slackware. Is to end this hostility to people that criticize slackware or speak their mind. That is by far the biggest downfall of Slackware...

Sure many of you hate me. but the ones that acknowledge the "Common Sense" I talk about embrace it are quite happy to read my posts.

But see you can't fix something that is Broken in its core. Slackware Community is Closed minded for Criticism and Change. Therefore it will be obsolete if not already... Because other distros keep moving and changing and Redhat continues to make billions for a reason other then "its just like Microsoft".

1 members found this post helpful.

waves. don't forget about the last step.. oh wait, I just don't care...

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.

4 members found this post helpful.

I think LQ is the "official" Slackware forum isn't it?

LQ is the primary forum given on the Slackware website, and Patrick does post here. I'd say it's more an unofficial-official forum.

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.

1 members found this post helpful.

If you don't know what's in the best interest of Slackware, then how can you define what's NOT in the best interest of Slackware? Seems a bit foolish if you ask me.

Many distributions do not evolve themselves based on the opinions of their users and their development is also closed to the outside world. Slackware is not alone in this choice. Plus, if there's something you don't like about Slackware, perhaps an outdated library, or an outdated package or documents as you describe, then you can always upgrade the package yourself. Pat gives out the .SlackBuild script (and he uses tar.?z* in the script so whether you use his re-compressed .tar.xz file or the original source tarball, it'll still work) on Slackware's mirrors so you can always upgrade or rebuild the packages yourself.

That can count as "applying your opinion" if you want to think of it that way. You like systemd? Then go download the source tarball(s), install it and remove the packages systemd replaces, it's that simple. You've brought that up a million times and it's what you're implying with "evolves", is it not?

This was mentioned by T3Slider already here:
I happen to agree with his statement. Slackware by default is not created for one user, it is created for many. Some of us don't like Xfce, some of us don't like KDE so we remove it. Some of us don't like GConf so we build Xfce without it, etc. Slackware just happens to be one of the easiest systems to mold into your liking.

1. Newest software is not necessarily stable software. As previously stated you can always upgrade the software yourself, and remove the "unnecessary stuff" yourself as well.

2. The hell is that even supposed to even mean?

3. Everybody that is in the "inner circle" is in there for a reason. Determination isn't enough if you do nothing with it. Those people did something with their determination like adding more architectures for Slackware to support, fixing bugs with the packages that are in Slackware, etc.

Ok, then please make criticism directly related to Slackware and all of the users both current and future. Do not just criticize for what would personally help yourself, because that doesn't necessarily help all the Slackware users (and in my personal opinion it's a bit selfish).

Well, unlike God you have personal flaws. You didn't criticize Slackware for improvement, you criticized it for what you personally did not like. That's not constructive criticism, that's just ignorant criticism aka rambling, crying/whining, etc.

Here's some criticism though -- work on your grammar then come back. Yes yes, I chose the path of being the grammar nazi for this thread, deal with it.

A different distribution has the same philosophy. Why not go use it? Because it's not Slackware? There's many programs which do dependency resolution for you, off the top of my head I can only think of "slapt-get" so just go use that.

You have to make logical (not personally biased) criticism first. Then we can and will hear you out. Please try that, not just for Slackware but for life in general.

2 members found this post helpful.

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.

4 members found this post helpful.

...quite to the point.

3 members found this post helpful.

Slackware was extremely innovative by allowing the community to create SlackBuilds (SBo). Other distributions are starting to follow a similar pattern like ArchLinux is with Archlinux User Repository (AUR). As big a distro as ArchLinux is packagewise through pacman, to start a extended community branch that builds packages using build scripts was straight out of the Slackware philosophy. Other distros are starting this too to trim their distributions or even allow more community involvement to get more packages available.

I think the quote by Robby spoke volumes and was overlooked. I'm going to go play with Slackware from the couch via the xbox and watch some free TV episodes. There's absolutely no point in posting in this thread except to toss biscuits.