Poll: default optimizations for packages in Slack 10.1
 

just curious...what default optimization would u like to see for the packages slack 10.1? as of now slack 10.0 is i486 for all packages(AFAIK)...
i personally would like to see i686 packages from now on, but then i guess slack 10.1 will be unusable on REALLY old machines...

hey moderator how about making this a sticky for a while?

well....
- there are distros which target specially on "older" pc's , ( like "delilinux " ), so there's no need to support those ( i486,i586 ) system's anymore.

but :
-Slackware should be usable all over the world for anyone. as not all people live in the " rich " part of the world.

-an "oldy " ( i486 ) should be able to run it. and if someone really wants an i686 compile, you can compie the whole thing yourself ( don't expect miracles. )

-i myself have revived my old pentium1 ( 200 MHz ), with Slack10 and fluxbox, and it's very usable , so why throw away "old" computers: it's a waste.

so , i say: keep supporting the "oldy's " :)

egag

Definitely the "smallest common denominator" principle.

And as far as I'm concerned (I don't mod in Slackware)
there's no need for this to be stickied ;}


Cheers,
Tink

Optimizations for a single CPU type are overrated in my opinion. And you will lose a lot of compability with older CPU types. So my choice is i486 :)

hmm...looks like i686 + p4/athlon xp seems to have an edge on i486...

...which proves that not all visitors of the Slackware
forum who part-take in a poll are well-informed or
good at reading ;)


Cheers,
Tink

i686 packages won't speed you up. Really. I'm working on a Gentoo box at school and nothing feels faster than it normally would on a P3/650.

I think they ought to give you a choice when you first install Slackware. For example, I have a PIII Tualatin @1.4Ghz with 512 cache, and I hardly think x486 is the right choice for my processor. When I compiled my last kernel I chose PIII for my choice over x486, but have often wondered what the best architect is for my tualatin processor?

I don't think we should plan on Pat V. compiling 2 or 3 entirely different versions just to give someone a choice. Pat will continue to compile for the slowest macine he can without causing problems. Look how long he kept 386 compatibility.

What a great idea :}

Let's try to convince how sensible it would be for
him to compile let's say 5 or 6 builds and offer
as many lots of ISO for download when the actual
speed-gain in real-life is marginal :D

The only things that really matter is the kernel, and
maybe the architecture for things like transcode. On
all other accounts it's just not worth the effort, it will
add as much to your machine as rally-stripes add to
your car - in other words: it's ornamental, and makes
you feel better about yourself. ;)

I have machines of type p166/athlon600/dual-PIII 1GHz
and a PIV notebook here, and one Nehemia box for testing
and I want to downloads 8 ISO's to install a proper version
of Slack on all of them ... *chuckle*


Cheers,
Tink

Leave it at i486. There is no reason to compile to i686 and it cuts off many systems that could otherwise run Slack. If it gave a significant boost it would be one thing, but compiling you kernel optimized for your CPU arch should give you most of the benefits.

EDIT: And i686 would not just break very old machines. I believe it would also make it incompatible with at least some Via C3 processors, which are a far cry from old.

although only two others seem to agree.. I think it's time to bump it up to 586... and as for giving you a choice.. I think you got the wrong two discs... there's a pair of source discs if you REALLY want it optimized for your hardware. it is NOT worth pat's not so abundant time to compile every package three or four times.

586s are still useful and cheap as hell... but.... even though I would bump it up to 586 I don't think it will be done for a while..

Possibly i586, but no lower than that. Preferably stick with 486. If you want to, you can recompile the kernel for a faster macine, but other than that it will barely make a difference anyway, so it's best to keep it low for maximum compatibility.

on a simlar note..does anyone use specific compiler flags for their machines, so that a './configure make' would be optimized for your machine( for programs built from source)?

Not generally - otherwise I couldn't use the same
checkinstall-generated tgz on all my machines. Or
at least it appears silly to have the slowest box do
all the hard work.

Normally I will leave defaults turned on, a few packages
(like mplayer) will try to detect the cpu anyway, and
for the "time-critical" ones I do use the proper flags (note
on the side: encoding a DVD to DivX5 with a non-optimized
version of transcode took about 40 seconds longer than
with an optimized one - which doesn't do a lot for me
considering that the process took well over 4 hours) ;D

Or, to re-iterate what has been said several times:
CPU/Architecture optimization doesn't gain you THAT
much benefit.


Cheers,
Tink

:tisk:

c'mon tinkster, no need to put people down cause they have a different opinion..

anyway, just for the record, i use athlon-xp specific flags cause i have only one machine running linux and will not be using checkinstall generated packages on any other machine..

Well ... I find that approach (arguing to raise the limit
just because you happen to have a specific CPU)
rather selfish and egotistic ... and a bit of sarcasm doesn't
hurt :)


Cheers,
Tink

opening this one after a long time...but ive just tried two i686 distro's namely mepis and arch, and theyre both much faster that slack..im sticking with arch..mepis was slightly unstable for me..but pacman rules!

Personally, I think i486 is fine. Going higher than that, IMO, is a mistake, as it would be offensive to the Slackware`s philosophy and some of its loyal users, and as [believe it or not] there`s a lot of older systems running around, which offer a high potential of expansion to Linux, and therefore, Slackware.

By the way, about the rich-part-of-the-world comment, and I don`t mean to be rude or start any kind of debate, well, it`s really ... inaccurate.

Anything higher than 586 would be a great mistake. It has been a long time since I've used a 486 (or seen one) but I'm sure they are in use by someone. Pentiums have been around for a long time and surely dominate in the *old* category of computer.

686 would be a huge mistake but 486 works for everyone.

well...then looking at it in that way...switching from i386 to i486 would have offended a whole bunch of loyal slackware users with older machines..im curious..was there a problem with that switch?(slack 9.1 was i386, i think)

Well, for example, I have an old laptop I use for a media computer. It has a pentium processor.

What I am saying is that a switch to 686 would make slack impossible to use on this type of machine, which is old and not one of my work computers, but not garbage.

Just because you aren't using a computer for you daily workstation doesn't mean that you have no use for it anymore.

from an IRC log file: http://ximpul.ath.cx/log.txt

I don't know about you, but i trust this guy.
You propably forgot the mcpu flag....

Recent gcc's require it - *it* doesn't work with 386s, IIRC. So the 386-486 jump was basically out of Pat's hands. As far as 486's I was playing around with one until it died a few months ago. It really doesn't make much sense to exclude 486s just to 'optimize' for 586s. Cost vs. payoff is minimal.

Anyway - while I compile specifically for my machine in most cases, I agree that Slack is a complete general-purpose distro and should work as widely as possible.

And I have Arch on here too and it didn't occur to me it's any faster than Slack. (Not saying it is or isn't but it's definitely nothing that hits you with a 2x4.) Arch also has somewhat quicker startup scripts (which I *did* notice - but they also don't do as much or as carefully as Slack, I don't think) and uses a different kernel patch set, neither of which have anything to do with -march/-mtune and both of which probably make more apparent difference.

im not really talking about the boot scripts...but the desktop and gtk/firefox feels so much
more responsive....i only wish slack was like this..

well...i think your Slackware setup is not optimal.
mayby there are a lot of services running in background that you don't need.

but if you want to make sure, you are free to compile xorg, your wm/de, firefox, gtk etc
on your own machine and see if it makes any difference.

if it does, report back.

egag

Believe me, the setup was optimal. lots of googling, lots of posts at LQ.org to speed it up everyway possible..but windows just seemed faster..all unnecessary startup stuff & processes were disabled.


to do that in slack anyway would be dependency hell IMHO..(i had a fun installing gdesklets) ;)


anyway im going to give slack 10.1 a shot one of these days and see if i like it....i686 or not, theres always a certain charm about slack

I have heard that too, Windows open windows faster, but frankly, could you benchmark a system just by testing its speed at boot and for opening windows ?

Also, if you want to run a V8 system, try some Kernel patches like Kon Kolivas...
For my part, I prefer have a slow stable system than a speedy buggy one (and I like the unpatched 2.6.9 kernel).

The only difference I see when enable CFLAGS during compile is a resulting binary with a slightly less drive space than unoptimised one. So I think as it has less size, it would load quicker in memory (in theory). But the difference is minimal.

about benchmarks....synthetic benchmarks dont really matter right?..theyre not real world results (like a lot of articles saying raid-0 is crap in the real world, but brilliant in benchmarks)..what matters in the end is the experience or atleast the feeling of speed & responsiveness for the user..and windows is better when it comes to that..(but windows is annoying too cause it does sneaky stuff to speed up boot time like loading services after logging in...i hate those flickers & mouse jerks during a windows boot up)

ive tried CK, CKO , mm & ac patches...but none of them made any noticeable difference...i greatly suspect DLG/swaret/slapt-get/random-dependency hell(during gdesklets) of ruining my system...i guess i should take pat's advice about things like swaret/slapt-get...but its quite annoying when you download a program...extract...run configure..then find out that you need some other program..google again..install that..then come back to the original program which you wanted to install..only to find out that it fails slightly later during configure..amd google again...

and a good number of websites dont really list dependencies..thats what makes it all so frustrating..

Yeah, I think we might have found the problem. Considering DLG rewrites a large chunk of the system and swaret and slapt-get can bork any number of things, I'm not sure it's fair to call that a Slackware system. (Not that DLG doesn't have its charms for some people or that swaret/slapt-get *have* to bork your system - just saying that this isn't 'official Slack'.)

My general practice is to install a somewhat minimal Slack base and compile my apps on top of that, with ice as a wm. With Arch, I did exactly the same thing, except I used their pacman thingamajig as long as there was no dumb crap like bash 3.0 being broken and bluefish having pointless Gnome-deps, where I did the ABS thing to fix bash and make a Gnome-less bluefish and so on. So, like I say, with that yardstick, just as with Gentoo, I don't notice a big difference with any of them, though all are faster than your commercial rpm sysv distros.

And people must be running Windows on new hardware or something. Windows XP creeped on the midline/bargain hardware it was released on even with all the junk turned off. Though, on a very top-line system of the time or a current 3GHz processor with 512MB of RAM, I reckon it is pretty snappy.

Still no excuse for Linux to bloat, though. Windows should *not* be the yardstick for performance and resource requirements. The excuse that XP came out years ago isn't a good one, but there is *some* truth to that.

(BTW I agree about the benchmarks vs. real-world user experience thing.)

the problem is people will use windows as a yardstick for performance whether we like it or not...cause thats usually the environment theyre coming from and they need to feel that speed in linux is something better/comparable to windows...cause speed is always a compelling reason to switch..(apart from ease of use, security, blah blah)

anyway...why is it that early adopters havent posted a review of slack 10.1 on LQ.org yet? still waiting for that before i download..

Well, this is true, but I meant it the other way around. Linux used to be *much* faster and run on *much* older hardware with ease and, while there are still ways to achieve this, the standard Linux with all the bells and whistles seems to have first used XP's size and *slowness* and now, especially, the projected insane requirements for Neverhorn, as an excuse to make Linux sloppy. So I meant the other way - not that Linux has to strive to match Windows in speed because that should be a gimme - Linux has to strive to *not* match Windows in size, bloat, and sluggishness on regular hardware.

Quote:

anyway...why is it that early adopters havent posted a review of slack 10.1 on LQ.org yet? still waiting for that before i download..

I've been caught up in another project, myself, so haven't used 10.1 thoroughly enough to review it. I've been mostly in 'my own' distro and somewhat in my old Slack 10 install. I also don't normally write reviews but I'm currently in 10.1 and after some more playing, maybe I can say something about it. So far so good - I'd say there's no need to upgrade except that it's the only well-maintained version at this point - but no reason *not* to upgrade in that everything seems fine. But that'd be premature until I've used it more.

Basically, I wouldn't hope for a magical transformation or fear a flaming disaster from upgrading. This is very much a point release.

I just did a review, and suggest others do the same. Remeber this is mostly just a stepping stone on the way to 11.0 and essentially its just version bumps and bug/security fixes. Nothing major.