Post something that you do not like about slackware
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
installation of softwares ....
I don't like installing from "tar" files.
download -> extract -> ./configure -> make -> make install
I like GUI based installation.
open package manager, select s/w, click to install.
...and miss the opportunity to understand exactly what's on your system, and how it works. On Slackware, installing from source is usually a breeze. I find it much easier than using any of the automated tools I've used. Using those tools, it was easier in the short term, but much more difficult in the long term since so many of the details of what was being done to my system were hidden from me.
Of course it is a Slackware approach--SW is os one of the majority of distros that does a complete install, but the SW community also is big on customizing and optimizing. My only point is that I prefer to optimize by adding things, not by removing them. Maybe that means I should really be using LFS.
"moderator troll"----I like it--please ask Jeremy to add that to the list of available titles. But does one attain this before or after--eg--"guru" or "moderator"?
I like it!
I'll bet you have to even use 'USENET' to get to that status.
I think that's one of the biggest problems. If gtk+ was a self-contained standalone widget library then a lot of these problems would go away.
Then of course, there's stuff like gconf. Ideally, Application developers would leave this to be a compile time '--enable-feature' on ./configure. and code it so that it would fallback to the traditional .programrc files and Xresources when not enabled. Unfortunately, developers can't be arsed to put the effort into coding this and therefore the need for gconf is forced upon everyone just so that one silly little program can get something trivial like its font settings or colours from gconf.
Part of it is down to the application writers, but part of it is also bad library design and separation of function.
There is probably a way people know to do this, but I don't like after doing a full install, I use pkgtool to remove programs/etc, without knowing if the file/program is required.
For just a desktop user, it's hard for me knowing what I can delete and can't. All those proto files for example.
OTT, Slackware is great!
There is nothing i would dislike about Slackware, common, it's stable, it's clean (as far as i know software included with Slack is as most pure vanilla as you can get), it's free (as in beer and as in freedom) it's fun (for the little geek in me), it's cool (as i can proudly say "I use Slackware!" )
The only thing i would like to see is the Slackware Wiki, where users could write how-to docs that would cover lots of things to make other users to understand Slackware better (package creation, installation, removal, dependency solving, configuring, optimizing, customizing, etc... ), and those docs should not only have a list of commands that you can copy paste to get something done, but also explain exactly what they do, how they do and why they do something. That would be truly awesome in my opinion.
P.S.
Maybe such wiki already exists and i just do not know about it?
I think that's one of the biggest problems. If gtk+ was a self-contained standalone widget library then a lot of these problems would go away.
Why do you think that this is a problem? You can think of gtk/glib/pango etc. as parts of a single big package, like the Qt toolkit. They can only exist together. At the very beginning perhaps "Gnome library" and "glib" were almost the same thing, but at least after gtk+2 they were clearly separated. Of course, glib development follows that of Gnome, but the changes are (mostly) in the form of backward compatible incremental updates. I also hate Gnome-dependent software but I'm very happy with the Gtk dependent ones, no problem there at all.
In recent releases they have begun incorporating some Gnome libraries into Glib (or more precisely, the Gtk framework), e.g. the Gio stuff or the printing interface. This is good news, as applications will have fewer or no reasons to depend on Gnome libraries. Qt seems to be more complete in that respect, but hopefully Gtk will catch up.
I agree with you about display related things like pango, cairo and gtk being considered as a single entity and in fact there's probably a good argument for merging them into a single library. They're all related to a single area of function (i.e. graphics/display/gui) it's when routines to provide other types of function are included in what is essentially a gui toolkit that I think is a mistake.
What brought this home to me recently was when I wanted to build an application on OpenBSD that needed the gtk+ library, and to build the library I also had to build CUPS, which required me to build Bonjour and so on. If the gtk+ application doesn't do any printing and only needs the gui widgets then why should I have to add these libraries? Proper separation of library functions based on functional area would have avoided the need for this.
Keeping clear separation of function/purpose between libraries is just good practice for efficient code reuse. At least, that's the way I view it.
But in recent years there seem to have been a few more security problems in Postfix than in Sendmail. No one would have expected this five years ago, when Sendmail was the Swiss Cheese of MTAs.
I won't discuss the rest of the post, as the configuration mechanisms are a matter of taste and I know for a fact that sendmail can dispatch messages faster than Postfix (but both are quite fast anyway).
However, I'd like to read some information backing up the claim on Postfix having more security problems than Sendmail in recent years. Honest question. I've looked back at some security advisories since 2006 for both projects and Postfix has only had two local minor security problems since then (both for 2.x and none for 1.x), while Sendmail has had a remotely exploitable SSL certification vulnerability, for example. Sendmail has certainly improved over the years, but I don't think Postfix is worse in any way regarding security.
One thing i dont like about Slackware is that it doesnt have its own forum and it relies on LQ so we have to put up with moderator trolls.
I have to disagree. Remember, at the heart of it, Slackware is one guy (no offense to Eric, Robbie, etc.). If Pat were to run his own forum, the time he would undoubtedly have to spend dealing with it would only take away from work on the distro itself. Instead, he outsourced the forum to the very capable hands of Jeremy and the LQ crew.
As for something I dislike about Slack, I really despise it's reputation as "a good server distro" or a distro that's "not for linux newbies". The first (and only) distro I ever took seriously was Slack and I can't even enumerate all I've learned about linux. Yes, I've taken my lumps, but it's not impossible for someone new to linux to start with Slack. All it takes is patience, google, the LQ search function and a willingness to learn.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.