That's why they call him the Woodsman!

1 members found this post helpful.

konsolebox,

You do not intend to listen the people which do not grasp your brilliant idea.

You do not intend to put into effect your brilliant idea yourself.

So I am asking you now how much are you willing to pay to someone who will do that for you?

(I am pretty sure that if you offer to pay enough someone will customize Slackware Linux to work on your “konsole box”.)

Well the idea is good.Maybe a minimal Gentoo-Like Slackware installation ?

Not only Slackware is optimized for the P6-ISA, Windows NT 5.1/5.2/6.0/6.1 x86 is 686-optimized too. All current x86-CPUs are designed to execute Windows as fast as possible, that's a fact. So there is no point in using obscure Compiler flags on CPUs designed for Windows. When in Rome, just do as the Romans do.

4 members found this post helpful.

I'm pretty sure you can't even recompile all Slackware packages using the current supported architectures let alone trying to do it over and over again. A system like Gentoo absolutely requires constant verification that sources still compile. Slackware doesn't have the man-power to do this for the two architectures it does support let alone the rest. For example, bc hasn't been upgraded (and thus it hasn't been recompiled) since Slackware 12.0, in 2007 (13.0, the initial release, in the case of Slackware64). There is absolutely no guarantee that the SlackBuild used then will still work today -- upgrades to gcc, glibc, etc. may not compile bc. Of course, that is just one example of many. Slackware by design does not compile each release in full.

Thus, doing what you ask is *not* easy and would take a ton of time -- not just to put in the infrastructure to automate compiling of various optimizations, but to actually make sure that sources will always compile on any given release (not to mention the time actually required to compile for each architecture, which is enormous). It would require a lot more resources than Slackware has. So, while your desire may have some merit (though it is unclear how much), Slackware is definitely the wrong distro in which to implement it. Gentoo already exists, and they do a good job of machine-specific optimization and maintaining constant compilability -- but Slackware is not up to that particular task.

4 members found this post helpful.

That link has been pretty much overused to keep people from opening their ears to the obvious benefits. That's pretty much outdated already. One could believe that they don't get much out of optimizing their binaries but that's no longer really true today, at least with new processors.

@Woodsman For the server cost I don't think it would be really applicable if it's distributed by torrent? And I'm a Slacker as well and no one can deny that, but conservative parties. Also, that's not really a Gentoo attitude as some use the distro more for its other features. Generally I just look over the benefits.

@T3slider Even Gentoo does not provide optimize binaries. Only binaries specific to target host. Perhaps you're referring to Funtoo. Still it's not Slackware. And I choose to have Gentoo with a more dynamic system, and Slackware to more static or long-term systems.

I was speaking more about the ability to compile optimized binaries yourself rather than providing binaries -- even that step isn't possible with current Slackware. And that is, in my opinion, a mandatory step if you want to provide multiple sets of binaries for each architecture. The other possibility is to setup many initial customized builds up front, doing a single sweeping check for source compilation, and then just keeping each optimized release up to date -- but this is impractical since you would have to do it again for new CPUs.

So, again, what you are asking isn't feasible and likely will never be feasible. You may be able to take Eric's current (in-progress) work on a new ARM port in order to get a starting point where everything should compile, but even that may not work since it was started quite a while ago and restarted recently, so I'm not sure if every package will compile even now (and even if it does, there is again no guarantee that every package will still be able to be compiled in the future).

You can continue saying that it is easy and should be possible or you can look at the facts and decide that, despite Pat V not personally stopping by and saying "No", it will never happen.

Torrents don't help me. My local mom-and-pop ISP, the only choice in this rural area where I can get reasonable bandwidth, has super low bandwidth caps. I can exceed the caps but my monthly cost skyrockets. I could be a torrent leach but I'd rather not. I would not be able to seed and that limits me to downloading DVDs. As I have five different computers here, I'd need a separate DVD for each. My only salvation would be that the existing DVDs would still be produced, meaning I could continue using "generic" DVDs for all of my systems.

I maintain a local repo of the Slackware releases I use. I burn my own DVDs, but that is with precompiled packages. As I mentioned, I can't envision the time and cost required for me to run my computers for days on end, debugging compilation failures, finding patches, etc., just to squeeze a few CPU cycles. I don't have the time for anything like that. Even if I did, I lack complete interest in such a project. I'd rather pick the lint from my belly button while reading a book. I suspect Pat would rather play with the spouse and daughter than create multiple special DVDs.

What you seek is admirable, but is so unlikely to happen because of many restraints and lack of a return on investment. Both I and T3slider mentioned compilation issues and times. I mentioned how much time is required to build just two package sets. I need all day or night to build either and that is if nothing goes wrong. Often that is not the case because I do a lot of patch testing for the Trinity project and that means build runs fail just as often as not.

From another perspective: I've read stories how long a Gentoo build takes. No offense intended, but no thanks.

Do you have benchmarks that give you numbers indicating the range of performance increase that would result? Or is this a subjective feeling?

@T3slider Adding another script to be placed in extra/ could make it happen. And I don't see how it is necessary for the end-user to be able to compile the whole system. That feature/capability could be added later. I'm only after the distributed binary in every release. Is it because if you decide to compile new or recompile current package, the output should also be an optimized version, or perhaps have much consistency out of the binary-source pairs? I'm not sure why the source has to be updated and I don't think there's a need for it. All we need is a building tool that would make build customizations possible. Looking at SlackBuild for example, one tool could export the value of MARCH and make it recognizable by SlackBuild e.g. http://slackware.mirrors.pair.com/sl...ash.SlackBuild. See how MARCH is interpreted.

Edit: Sorry I didn't notice that MARCH is actually set with MARCH=$( uname -m ). But I think that could be overridden.

With a wrapper uname function if it could be exported, or a wrapper script placed on another directory placed, and with a modified PATH.

At least how I compared the noticeable performance difference of my Gentoo and Slack setups back then I could tell. I can't do benchmarks. And desktop experience with respect to system response can't really be benchmarked I think.

Sorry but that tells you nothing since Gentoo and Slack are not identical in all other aspects. You can't have that many different variables and still claim you know for a fact that any performance difference is purely down to march.

Additionally, without careful and precise benchmarking you may well be fooling yourself because you expect a certain outcome. Since you have now admitted you have not even tried to do benchmarking you are further confirming that you do not know that there is any improvement at all.

1 members found this post helpful.

Really? What would this magical script look like? What would it do? If you actually understood my previous posts you would realize that no magical wrapper script will be able to recompile everything with additional optimizations -- specifically because not everything can be recompiled without having to constantly rewrite SlackBuilds.
What aren't you getting? Not even Pat can compile the whole system right now without a massive overhaul (and repeated and ongoing testing and SlackBuild rewriting to ensure a constant ability to recompile every package). The problem with your idea isn't that it is too difficult for end-users, but that without a much, much larger team of people working to make it happen (which would require active community decisions that currently fall to Pat -- who doesn't scale, by the way) this isn't possible at all. The current development process of Slackware (as far as I know, anyway) would make your idea untenable in the long-term.
The source doesn't have to be updated but it has to be recompiled to support each optimization. The current sources and their SlackBuilds are not guaranteed to compile, so just recompiling an old package for each architecture may in fact require updating the source to support newer gcc. I remember one case specifically, where WindowMaker could not be compiled with whatever Slackware version it shipped with -- the binary package still worked, but it could not be recompiled without rewriting the SlackBuild (and patching the source). I believe newer WindowMaker activity changed this, but there are certainly packages in Slackware that will not compile today without having to change things. Right now the Slackware team only recompiles packages if something breaks or if they are updating the version. If said package will not compile, then they have to rewrite the SlackBuild (and possibly find patches) to get it to compile. It is done on an as-needed basis right now, but to produce multiple releases of Slackware requires recompiling all (or most) packages to support each CPU optimization, and thus would require constantly verifying that *all* 1000+ packages will still compile after every package update. There are distros that do compile every package for each release, but Slackware isn't one of them (and is therefore an unsuitable candidate for your project, in my opinion).
Work on this is already underway -- see Alien Bob's ARM port, mentioned previously. However, again, there is no guarantee that sources will still compile on later releases, so adding new architectures is not trivial and still requires a lot of work.

1 members found this post helpful.

@T3slider Please see my update (edit) on that post.

And you're not adding a major architecture. The targets would still be x86_64 and ix86.

@Woodsman I hope you did consider that if a SlackBuild is stable and builds the way it is for a specific release, changing the CPU type flag (march/mtune) for it is unlikely to give troubling difference when rebuilding. Unless the binary could really be only built manually. I find that unlikely, but again we could make use of a customized SlackBuild.

@ruario Once I had attempted to use packages of Slackware for Gentoo and it worked. Yes they could be identical, at least signifcantly.