Dear Slackware, Optimized Distros?
 

Hi, I wonder if Slackware would ever have optimized packaging for each subsystem like what Funtoo did? I know that's so unlikely but I just wonder if there's a possibility. Some not-too-conservative users would probably love to have most features of their processors used at its fullest to lessen lag, gain speed, and perhaps conserve a bit of energy as well for the distro they're using.

Have a look here, this might be helpful: http://www.linuxquestions.org/questi...ct-4175457215/

@TobiSGD I know the possibility of re-building Slackware certainly. But it's better if it's already provided and ready for download. And an official package is also irresistible to take, and probably collect or archive.

Which specific processor features have you identified Slackware as not using?

@dugan Basically new faster instructions? And optimized use of caches?

I meant: which CFLAGS do you want?

@dugan I think it's the value of march that would matter most.

Then obviously, the answer is: no, there is no chance that that will ever happen.

-mtune (which doesn't break backward compatibility) would be a more reasonable request.

Slackware 32-bit still runs on 486 machines (pre-Pentium ones). Slackware 64-bit runs on x86_64 machines and allows to run some 32-bit software using the multilib.

According to “Slackware Overview”:

So Slackware is optimized to run on different machines. If you need the system optimized to run on your machine try Funtoo or Gentoo.

@wk10 You don't really have to say the obvious. That has nothing to do with the question. And it's not about me deciding to use Gentoo, or Funtoo.

Obviously, an optimized code is meant to be an optimized code so it won't work on older systems. But isn't that already expected? I'm actually asking if Slackware could have different optimized distros for every main subsystem as specified in my opening post.

Edit: Sorry I actually misread that. As of the new versions of GCC (checked 4.7) I think there's no longer any difference with that two.

Slackware provides:
(1) Compiled packages
(2) SlackBuilds + source tarballs corresponding to (1), allowing you to optimize any package.

It's very different from Gentoo (let alone Funtoo) on that respect.

And Slackware is maintained by very few people, already pretty busy.

So, IMO doing what you suggest would need to launch a different project, with a dedicated team.

yes, one person maintaing something like 30 (to be optimistic) variants of the same distribution seems to me like a wonderful idea.

in Italy we have a vulgar saying for situations like this (please don't get offended, it's just for explaination's sake): "yes, and maybe while he's at it he could also put a broom in his ass and clean your house".

@Didier Spaier I don't really see the need of having another dedicated team to just rebuild what's already in a dvd after a stable release to have another dvd that's optimized for a specific CPU type, most basically the ones that could be provided to march or mtune.

Please don't confuse optimizing a package for a CPU and changing the target host. It's different.

Did I not very specifically and clearly answer you with no already?

@dugan Why do you question and answer me as if you're the representative?

Because you asked and I know the answer. The fact that you ignored the answer is making me doubt your sincerity.

Oh sorry it seems that I haven't made it obvious in my header subject that I'm somehow wanting to know the opinion of the Slackware team themselves. You know the answer, because you're one of the representatives? Or do you expect it? How different is that to how I estimate that it could be likely that it would be rejected? Even I so I try for I know there's a valid point in it somehow.

Oh, and your meaning is that you did not want to hear from anyone else? Then you shouldn't have posted here at all. You should have contacted them directly.

To be sure that you measure the amount of work that would need, I suggest that you do it yourself for only one CPU type.

The fact that Slackware packages are built individually, and there's no automated process to build them all at once, obviously makes this proposal even more difficult to implement.

I made a choice to ask in a bit more casual manner like in this forum rather than bothering them directly. As for other people's opinion I am open to it. And I mean opinion, not affirmations.

You asked a yes/no question. The answer is no. I'm not going to pretend that it's not the correct answer just because you're not open to "affirmations". That is not my problem.

I wonder. I actually see it to be only a script or two. If they already have something that automates the build of one release, changing the flag for it would just be easy.

But AFAIK, they do not, as Dugan just stated.

konsolebox, do you know that slackware is maintained by just one person?
I think you are missing this very important detail related to what you're asking for (and that is the reason of my previous post).

@ponce I won't mind just having an answer from his team as well.

They don't.

There is one script per package. Packages are updated and rebuilt on an individual basis in the process of developing the -current branch. A release is just a snapshot of -current. In a typical release, many packages will have not been rebuilt or updated since the previous release.

Yet that automation script could be made if it's not yet there if they decided to. It's pretty easy I think. As an example, even with the known utility src2pkg we could just have a list file or a formatted file of packages that could be parsed and call the utility continuously. Stop somewhere if it fails. Log redirections with tee -a. It's fairly easy actually. And it's rare for a build to fail just because a cpu type is changed.

If it's that easy please try it.

If it would have been fairly easy, it would have been done long ago.

But maybe that's fairly easy for you.

Then just do it. Otherwise I would think you're just trolling.

then try it again when software versions change.

After all, Slackware is open source and delivers you a build script for any of the packages, so the first step to have something like that realized would be a proof of concept. Since you already have a plan how it can work why not just try it?
Roll up your sleeves, take the knowledge and work already done from the thread I linked and try to create an automatic build system for Slackware. If it works out well I would think that PV may be interested in your work, but if he is not interested you still have what you want and maybe others will use it for their purposes.

You don't really understand anything about Slackware do you?

Also, this is a public forum, with lots of smart people who are willing to answer the weirdest questions - in theor own free time. I think that your tone if offensive to these good people.

To come back to the topic at hand, my answer is:

Eric

No I'm not trolling. The decision not to distribute optimize copies was probably because for example in 64bit, sse2 instructions were fairly common in most processors and it's one of the fastest instruction sets around. Also, they probably have some reason that it's not good to package multiple distros.

I actually mean fairly easy as easy compared to building packages with unknown dependencies. This time you're just repeating it with just a change in cpu type.

And then?

Pat:

When version changes, well I think the one who would made an update to their system could still update those packages with default binaries. Those would still work, only that they would replace the old with versions that's no longer optimized.

But the point here is at least every release has optimized versions. So one who would decide to install Slackware on his system with a fast processor like corei7 just in case, would get the most of his system, and enjoy Slackware more probably.

Continue of course? And I meant other possible causes that would stop it besides the flag e.g. power failures, disk full, etc. They're common unexpected troubles when compiling software.
I believe he's referring to other unusual setups or systems probably (any arbitrary development environment ). Having optimized binaries for a specific cpu type is far from that.

Okay then, Konsolebox. I'll echo those waiting for you to prove your point in the only way possible: by actually producing, testing and contributing the script to build all of Slackware's packages.

However, let me make the additional point that I'd rather buy a Slackware DVD that works on all x86 and x86_64 systems (which the current release does) than buy a DVD that's been -march-optimized for one architecture.

Yeah I did planned that once only that I didn't have much resources and not knowing how it would be worthy to other people for an upload. Probably if I get a spark for it I would build one at least.

But good point. It seems something worth doing.

Does it? How big a performance increase are you actually expecting for the amount of effort you would need to put into this. Personally I think you should be prepared to be disappointed.

I've been compiling my whole system everytime I get a new setup of Gentoo. And I greatly see the benefit of it.

But anyway it's only for the benefit of a concept proof, and it might be fun as well.

Well I see the benefit of compiling packages with different configure options or using SlackBuild scripts to build new (or perhaps older) versions of default applications. I don't however think you will get a substantial benefit out of playing with march, which seems to be what you are suggesting. If you want Slackware optimised for modern PC hardware, use Slackware64.

I build my own Trinity and KDE4 packages. There are many packages in each set. Each desktop environment takes me all day (or all night) to build. To rebuild both package sets is a two day (night) affair. I have a dual core system with 8 GB of RAM. Not bleeding edge but fast enough. The point being, I can't imagine recompiling an entire operating system simply to squeeze a few additional CPU cycles. How many days would I need to do that?

Extend that thought to Pat and then expect him to push numerous custom DVDs? I'm guessing his electric bill is already high enough.

Answering your original question, yes, creating such disks is possible. Possible but impractical. Practical perhaps for a single person, but not for large scale production and consumption.

I appreciate your Gentoo attitude, but there is the practical element in all of this. Most people don't have the time, energy, or desire for such a project. Such a goal would not scale well at all.

Find a dozen volunteers to crank these custom DVDs, maybe then doable. Yet then the next question is who is going to pay the costs of the servers to host those additional DVDS?

There is the question of return on investment. How many people would actually download the specific DVD needed for their hardware? I'm guessing not many. Moreso, I have several computers here, all with differing levels of hardware. Do I download the specific DVD for each system? I have limited bandwidth with my ISP. I would not be able to afford that kind of cost --- or the time involved to download full DVDs.

A lot of things are possible in this world. That does not mean they are practical.

People participating in this forum are Slackers, not Gentooers. Sometimes we squabble amongst one another, like siblings, sometimes even heatedly. Yet overall we like the house we live in.

@Woodsman: You hit the nail on the head, multiple times. ;)

That's why they call him the Woodsman!

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.