SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
We're now onto page 9 of this pointless thread, over two weeks later, which could easily be renamed as "why can't slack be more like gentoo or funtoo?".
At the University, we used to call this phenomenon "The Zorro Syndrome". Once in a while, an author (or a critic/researcher/politician/whatever) rides along on his white horse and wants everybody else to see the light.
No one in Sackland needed a proof for that. This possibility has always been included in SlackBuilds' design.
You sure you know what you're referring to? What kind of optimization do you exactly mean? And an example SlackBuild that does that perhaps? And you do mean the whole set of release which others disagreed upon to be possible and not just one package?
Last edited by konsolebox; 05-05-2013 at 09:00 AM.
So tell me if this would be a good description of your progress so far. You took the easy step of doing a global search and replace and noticed that this operation failed on many SlackBuilds. You then tried to build the packages. The build results were exactly what we told you to expect: that many packages failed to build. You then declared, based on these highly negative results, that you've "proven" that an "optimized Slackware" is "possible" "for the whole distribution and not just one package". You have also refused, despite repeated prompting, to do benchmarks to test the assumption underlying your project: that these "optimizations" will have any real-world, human-noticeable benefits at all.
Would you say that that is an accurate summary of what you've posted so far?
(Of course, if the claim has indeed changed to "possible" from "easy enough for Pat to maintain", then it's no longer wrong. There are/were Slackware forks that rebuilt every package).
And yes from what I discovered I think I can't accept how Slackware just allows an old package to be included when it could have possible compatibility issues, and relying more on discovering bugs through long-term use rather than checking through compile-time if it's compatible with the new dependency packages. Yes the team monitors which could still be compatible with new updates, but I still see that is risky and so not Slackware-like as how I thought Slackware is. Yes I admit. I was mistaken about Slackware's approach to stability.
Slackware has included new versions of packages in -current that later got reverted to older ones because the brand-spanking-new packages were functionally worse than the old ones. On paper, these new packages were compiled with the newest dependencies and should have worked great, but they didn't. And again, problems with these new freshly compiled packages are discovered through long-term use -- because there isn't another way to find them. Just because something compiles doesn't mean it works or is stable. The only way to maintain stability is through being conservative with package versions and a lot of testing. Period.
I will make a note again about WindowMaker -- when that couldn't be compiled for multiple years, you would have just dropped the package because it makes you 'uncomfortable' despite it working and remaining stable. There was no way to get that to compile without a lot of serious patching effort.