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. ;)