LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-04-2013, 01:09 PM   #106
chemfire
Member
 
Registered: Sep 2012
Posts: 414

Rep: Reputation: Disabled

Quote:
Originally Posted by konsolebox View Post
what I'm saying are those that aren't about it, like possible changes within the headers of the library or other dependencies.
You sure not even change in data/structures within headers? Those that may affect function calls, and data to be used.
Usually changes like that are pretty well publicized with core libraries like glibc; Pat pays attention to information like that coming from up stream. Its possible that data structure changes might cause issues with smaller less used libraries. Most projects are pretty good about changing major versions when something like that happens though.

Stuff is usually linked with somelib-2; the library maintainers will usually install the library whatever version it is to /usr/lib/somelib-2.2.3 and then symlink that to somelib-2; for as long as its compatible. Then they move to somelib-3 and no long symlink somelib-2 with it. That way ldd can quickly show you where the problems are. So most of the time this not issue.
 
Old 05-04-2013, 01:22 PM   #107
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,248

Original Poster
Blog Entries: 8

Rep: Reputation: 235Reputation: 235Reputation: 235
Quote:
Originally Posted by chemfire View Post
Usually changes like that are pretty well publicized with core libraries like glibc; Pat pays attention to information like that coming from up stream. Its possible that data structure changes might cause issues with smaller less used libraries. Most projects are pretty good about changing major versions when something like that happens though.

Stuff is usually linked with somelib-2; the library maintainers will usually install the library whatever version it is to /usr/lib/somelib-2.2.3 and then symlink that to somelib-2; for as long as its compatible. Then they move to somelib-3 and no long symlink somelib-2 with it. That way ldd can quickly show you where the problems are. So most of the time this not issue.
And what about the less known dependencies. Is every depending package also monitored for every update of a dependency? That's quite a large task if you could imagine the links.

Btw as for ldd, that's only the link not the changes within. And some packages point to more general versions.

Last edited by konsolebox; 05-04-2013 at 01:26 PM.
 
Old 05-04-2013, 01:34 PM   #108
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 7,068

Rep: Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145
Quote:
Originally Posted by konsolebox View Post
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.
I quote your original question (not to say the title of the topic): seeing the funtoo download page that imply to have, beside the existing i486, x86_64 (maintaned by Pat) and armv5 (maintained by mozes) ports, other 12 distributions, namely corei7, core2_64, atom_64, amd64-k10, amd64-k8, core2_32, atom_32, amd64-k8_32, athlon-xp, i686, armv6j_hardfp and armv7a_hardfp.
you have rebuilt many packages on just one of these archs with some optimizations (and I won't even ask if you have done this with a new core2 toolchain, and the order of the rebuilds), but are you actually running what you've rebuilt? is everything going fine? rebuilds are useless if not tested (*everything* should be tested, how can you call it *stable* instead?).
you can rebuild also what's missing, test it, and when you're *sure* everything works fine, maintain your own core2 port following slackware-current, so you can have an idea of what does it mean maintaining a distribution, as you're asking Pat to maintain 12 more beside the two he's already kindly providing us: it's not just building some packages once, you seem to not understand this.
I don't ask you to do this for the 12 more archs you asked Pat to provide, one should be enough to teach you the pain that this means.
but only if you will be able to do this for the 14 archs (I include the existing 2) you asked for then you will have proven your point, not a second before.

Last edited by ponce; 05-04-2013 at 04:26 PM. Reason: spelling
 
Old 05-04-2013, 01:53 PM   #109
chemfire
Member
 
Registered: Sep 2012
Posts: 414

Rep: Reputation: Disabled
Code:
        
        movl    $3, 28(%esp)
        movl    $4, 24(%esp)
        movl    28(%esp), %eax
        cmpl    24(%esp), %eax
        jle     .L2
        movl    $0, (%esp)
        call    exit
.L2:
        movl    $1, (%esp)
        call    exit
Konsolebox,

You seem really concerned with stability and the risk associated with not building everything from source and possibly unknown data structure changes between binaries. As I and others have pointed out the risk of these being unknown and undetected are small.

The concern people have with changes to CFLAGS and other compile options is not will the package compile. Its can you be sure the resulting program will be correct. Consider then totally simplistic example above. Do you need a noop before cmpl? (No cpu really would) but there are odd cases where the ordering of instructions, insertion or not of noop, selection of branching methods etc, can cause a register value to be used before its stabilized. This is why you don't want to go crazy with letting the compiler optimize. You might introduce really subtle bugs. The compiler is going to be able to produce output for valid input no matter what the optimization flags are; and the assembler is going to be able to produce object code. You won't see problems until runtime and even then it might depend on other odd corner cases.
 
Old 05-04-2013, 02:07 PM   #110
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761
@konsolebox: As I am sure you are aware Slackware is the oldest surviving distro and has over its 20+ years built up an enviable reputation as one of the most stable. If your concerns about the risks of not constantly rebuilding everything held real merit, not only would Slackware not have managed to garner this reputation, it probably would have died a long time ago.
 
Old 05-04-2013, 02:14 PM   #111
T3slider
Senior Member
 
Registered: Jul 2007
Distribution: Slackware64-14.1
Posts: 2,367

Rep: Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843Reputation: 843
Quote:
Originally Posted by konsolebox View Post
You serious? How are those packages even comparable to gcc, glibc, mesa libraries, x libraries, core utilities, etc.
Code:
# Files not converted in which packages are probably not compiled or is meant to be not optimized.

./a/aaa_base/aaa_base.SlackBuild
./a/aaa_elflibs/aaa_elflibs.SlackBuild
./a/aaa_terminfo/aaa_terminfo.SlackBuild
./a/acl/acl.SlackBuild
./a/attr/attr.SlackBuild
./a/bin/bin.SlackBuild
./a/btrfs-progs/btrfs-progs.SlackBuild
./a/bzip2/bzip2.SlackBuild
./a/cups/cups.SlackBuild
./a/cxxlibs/cxxlibs.SlackBuild
./a/devs/devs.SlackBuild
./a/elvis/elvis.SlackBuild
./a/etc/etc.SlackBuild
./a/genpower/genpower.SlackBuild
./a/getty-ps/getty-ps.SlackBuild
./a/hdparm/hdparm.SlackBuild
./a/infozip/infozip.SlackBuild
./a/isapnptools/isapnptools.SlackBuild
./a/kbd/kbd.SlackBuild
./a/kernel-firmware/kernel-firmware.SlackBuild
./a/lha/lha.SlackBuild
./a/lilo/lilo.SlackBuild
./a/mcelog/mcelog.SlackBuild
./a/mkinitrd/mkinitrd.SlackBuild
./a/mt-st/mt-st.SlackBuild
./a/mtx/mtx.SlackBuild
./a/ncompress/ncompress.SlackBuild
./a/pcmciautils/pcmciautils.SlackBuild
./a/pkgtools/pkgtools.SlackBuild
./a/quota/quota.SlackBuild
./a/rpm2tgz/rpm2tgz.SlackBuild
./a/smartmontools/smartmontools.SlackBuild
./a/splitvt/splitvt.SlackBuild
./a/sysfsutils/sysfsutils.SlackBuild
./a/sysklogd/sysklogd.SlackBuild
./a/syslinux/syslinux.SlackBuild
./a/sysvinit-functions/sysvinit-functions.SlackBuild
./a/sysvinit-scripts/sysvinit-scripts.SlackBuild
./a/sysvinit/sysvinit.SlackBuild
./a/tree/tree.SlackBuild
./a/udev/udev.SlackBuild
./a/unarj/unarj.SlackBuild
./a/utempter/utempter.SlackBuild
./a/zoo/zoo.SlackBuild
./ap/amp/amp.SlackBuild
./ap/ash/ash.SlackBuild
./ap/dmapi/dmapi.SlackBuild
./ap/dvd+rw-tools/dvd+rw-tools.SlackBuild
./ap/ghostscript-fonts-std/ghostscript-fonts-std.SlackBuild
./ap/ispell/ispell.SlackBuild
./ap/joe/joe.SlackBuild
./ap/ksh93/ksh93.SlackBuild
./ap/lm_sensors/lm_sensors.SlackBuild
./ap/lsof/lsof.SlackBuild
./ap/man-pages/man-pages.SlackBuild
./ap/rexima/rexima.SlackBuild
./ap/sc/sc.SlackBuild
./ap/seejpeg/seejpeg.SlackBuild
./ap/vorbis-tools/vorbis-tools.SlackBuild
./ap/workbone/workbone.SlackBuild
./ap/xfsdump/xfsdump.SlackBuild
./d/ccache/ccache.SlackBuild
./d/cscope/cscope.SlackBuild
./d/distcc/distcc.SlackBuild
./d/gdb/gdb.SlackBuild
./d/mercurial/mercurial.SlackBuild
./l/gmm/gmm.SlackBuild
./l/gnome-icon-theme/gnome-icon-theme.SlackBuild
./l/hicolor-icon-theme/hicolor-icon-theme.SlackBuild
./l/icon-naming-utils/icon-naming-utils.SlackBuild
./l/libaio/libaio.SlackBuild
./l/libao/libao.SlackBuild
./l/libpng/libpng.SlackBuild
./l/libtermcap/libtermcap.SlackBuild
./l/poppler-data/poppler-data.SlackBuild
./l/pycups/pycups.SlackBuild
./l/pycurl/pycurl.SlackBuild
./l/sound-theme-freedesktop/sound-theme-freedesktop.SlackBuild
./l/tango-icon-theme/tango-icon-theme.SlackBuild
./l/urwid/urwid.SlackBuild
./n/biff+comsat/biff+comsat.SlackBuild
./n/bootp/bootp.SlackBuild
./n/bsd-finger/bsd-finger.SlackBuild
./n/ca-certificates/ca-certificates.SlackBuild
./n/elm/elm.SlackBuild
./n/ethtool/ethtool.SlackBuild
./n/getmail/getmail.SlackBuild
./n/icmpinfo/icmpinfo.SlackBuild
./n/inetd/inetd.SlackBuild
./n/iputils/iputils.SlackBuild
./n/ipw2100-fw/ipw2100-fw.SlackBuild
./n/ipw2200-fw/ipw2200-fw.SlackBuild
./n/netdate/netdate.SlackBuild
./n/netkit-bootparamd/netkit-bootparamd.SlackBuild
./n/netkit-ftp/netkit-ftp.SlackBuild
./n/netkit-ntalk/netkit-ntalk.SlackBuild
./n/netkit-routed/netkit-routed.SlackBuild
./n/netkit-rsh/netkit-rsh.SlackBuild
./n/netkit-rusers/netkit-rusers.SlackBuild
./n/netkit-rwall/netkit-rwall.SlackBuild
./n/netkit-rwho/netkit-rwho.SlackBuild
./n/netpipes/netpipes.SlackBuild
./n/network-scripts/network-scripts.SlackBuild
./n/netwrite/netwrite.SlackBuild
./n/newspost/newspost.SlackBuild
./n/popa3d/popa3d.SlackBuild
./n/portmap/portmap.SlackBuild
./n/ppp/ppp.SlackBuild
./n/procmail/procmail.SlackBuild
./n/pssh/pssh.SlackBuild
./n/tcpdump/tcpdump.SlackBuild
./n/tcp_wrappers/tcp_wrappers.SlackBuild
./n/telnet/telnet.SlackBuild
./n/tftp-hpa/tftp-hpa.SlackBuild
./n/tin/tin.SlackBuild
./n/traceroute/traceroute.SlackBuild
./n/trn/trn.SlackBuild
./n/vlan/vlan.SlackBuild
./n/vsftpd/vsftpd.SlackBuild
./n/whois/whois.SlackBuild
./n/wireless-tools/wireless_tools.SlackBuild
./n/zd1211-firmware/zd1211-firmware.SlackBuild
./t/xfig/xfig.SlackBuild
./x/dejavu-fonts-ttf/dejavu-fonts-ttf.SlackBuild
./x/liberation-fonts-ttf/liberation-fonts-ttf.SlackBuild
./x/sazanami-fonts-ttf/sazanami-fonts-ttf.SlackBuild
./x/sinhala_lklug-font-ttf/sinhala_lklug-font-ttf.SlackBuild
./x/tibmachuni-font-ttf/tibmachuni-font-ttf.SlackBuild
./x/ttf-indic-fonts/ttf-indic-fonts.SlackBuild
./x/wqy-zenhei-font-ttf/wqy-zenhei-font-ttf.SlackBuild
./x/x11-skel/x11-skel.SlackBuild
./x/xdg-utils/xdg-utils.SlackBuild
./xap/gkrellm/gkrellm.SlackBuild
./xap/seamonkey/seamonkey.SlackBuild
./xap/xgames/xgames.SlackBuild
./xap/xine-lib/xine-lib.SlackBuild
./xap/xine-ui/xine-ui.SlackBuild
./xap/xv/xv.SlackBuild
./y/bsd-games/bsd-games.SlackBuild
Don't forget about those. sysvinit, udev, bzip2, xine-lib, seamonkey, and more are being ignored because they require manual SlackBuild modification. Certainly bzip2 is a candidate for optimization.
Quote:
Originally Posted by konsolebox View Post
Perhaps you mean they -should- be done regardless if they are being optimized or not just to verify that -those- packages are truly compatible not only by the output binary but also of the used configurations and proper functions that possible could have been changed.
Again -- Slackware has been one of the most stable and reliable distros since 1993 and it does not recompile everything. If the only requirement for stability rested in compiling for every release, then the vast majority of other distros would surely be ten times as stable.
Quote:
Originally Posted by konsolebox View Post
It's actually because you believe changing a CFLAG for a subarchitecture would cause an error if the package is able to build as a normal x86_64, but as proven it's not.
I have never said this, nor do I believe it. But you can continue to put words in my mouth if it makes you feel better.
Quote:
Originally Posted by konsolebox View Post
And that you also believe that those errors found are -always- (as it seems it's what you believe) not signs of the old binary not being truly compatible (but only see it with macro-analysis through runtime; as long as you see it's working it's working and don't really bother with the difference, or probably just wait until you actually saw that one of its functionality is no longer working the way it should be) with the new versions of its dependencies.
I have never said this either. If there is a major ABI or API change, then obviously failing to compile against something *may* (or may not) indicate that the program will not play well with its dependency without a version bump.
Quote:
Originally Posted by konsolebox View Post
It really sounds that you only assume superiority as the way you speak but don't really have much idea how mass packages could be possibly worked out to compile. And even if you really don't care, I guess you still couldn't estimate how possibly it could really cause troubles if they are to be built with new flags.
I haven't assumed any superiority. I am giving opinions on information that I know about Slackware. You recompiled a bunch of packages, but discovered errors in some and have a WHOLE BUNCH leftover that weren't attempted because mass conversion just isn't possible without rewriting the SlackBuilds (which is why I still suggest waiting for Alien Bob's work and targeting a potential future Slackware release rather than doing this now).
Quote:
Originally Posted by konsolebox View Post
At least please try to prove your conjectures in a more technical manner. Can you give an explanation how at least 1 out of 10 packages could not cause errors, unexpected functionality, or exceptions in some of its functions if one of the packages it depends upon has already changed and that the old sources no longer compiles with it, and I mean not just because of new compilers, linkers, etc.
The sources can be rewritten entirely but maintain the same compatible ABI. Because of the source modifications, the dependent application may fail to build (for example, because of a Makefile that is no longer compatible with gcc -- the sources may not need any modifications, but the Makefile may need to explicitly pass linker information. Or, the include file may change -- where you could previously include only specific header files, you may be forced to include a top-level include file instead -- see recent glib changes). As long as the ABI remains the same, the dependent application will not benefit by recompilation (note: there are edge cases, for example, if rebuilding with a new API will enable additional features...though this could lead to problems as well and would require testing).
Quote:
Originally Posted by konsolebox View Post
Well I guess you do believe that as long as you see it works, it works, and let's wait for someone to notice that it doesn't.
This is how Slackware development works. Regardless of whether you recompile or reuse existing binaries, you will have to test to make sure everything still works. If you are not comfortable with this, then REALLY -- Slackware is not for you. As I stated before, many packages have not been recompiled since at least 2009.
Quote:
Originally Posted by konsolebox View Post
Give me a technical reason why, at least on the level of dissimilar headers which could contain settings applied in built libraries which are then still used by the old binary, which could now be different from the previous one.
This is an API vs ABI discussion. If the ABI remains compatible, it will work. If it becomes incompatible, then it won't. An API change isn't necessary for ABI breakage, and an API change doesn't necessarily break the ABI. Libraries are supposed to bump the major version in case of an ABI change, and while this doesn't always happen (not all programmers are experts at maintaining ABI compatibility), it does work in many cases.
 
Old 05-04-2013, 02:33 PM   #112
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,248

Original Poster
Blog Entries: 8

Rep: Reputation: 235Reputation: 235Reputation: 235
Quote:
Originally Posted by ponce View Post
I quote your original question (not to say the title of the topic): seeing the funtoo download page that imply to have, beside the existing i486, x86_64 (maintaned by Pat) and armv5 (maintained by mozes) ports, other 12 distributions, namely corei7, core2_64, atom_64, amd64-k10, amd64-k8, core2_32, atom_32, amd64-k8_32, athlon-xp, i686, armv6j_hardfp and armv7a_hardfp.
you have rebuilt many packages with some optimizations, but are you actually running what you've rebuilt? is everything going fine? rebuilds are useless if not tested (*everything* should be tested).
I actually really believe that packages compiled for stronger CPUs but still on the same general architecture doesn't give differences that could cause runtime errors, unless perhaps if some of the packages are hard-coded for a specific architecture, which I think if not old, are generally just having a bad programming practice. Still those kinds of packages should be rare. And even far rare I think to be included in Slackware.

Yet again at first I am aware that those distros would still need to be tested, so I thought that they could be one release candidate delayed from the major release. Perhaps a week or two after it there could be a final release. It's simple because you just have to exclude those packages that don't work and revert back to the generic version, and you don't have to force-fix them. If the generic versions are found to be needed to be fixed themselves, then it's a general problem to the release version as a whole.

Quote:
you could rebuild also what's missing, test it, and when you're *sure* everything works fine, maintain your own port following slackware-current, so you can have an idea to what does it mean maintaining a distribution, as you're asking Pat to maintain 12 more beside the two he's already kindly providing us: it's not just building some packages once, you seem to not understand this.
I don't even ask you to do this for the 12 more archs you asked Pat to provide, one should be enough to teach you the pain that this means.
Everything should be built easily and automated (from building packages to building the ISOs) if the SlackBuilds in the main are updated to allow newer CPUs and an automation script is already made. Even if the packages are continously updated if their SlackBuilds have a format that follows a standard, things would go well.

Again you don't have to test a package for every extension subarch you could have. You just have to make sure that it runs with the main generic platform, and that it's compatible with its co-packages, strictly if possible.
 
Old 05-04-2013, 02:41 PM   #113
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 7,068

Rep: Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145
like I asked, I really would like to know if you actually are running what you rebuilt...

Quote:
Originally Posted by konsolebox View Post
I actually really believe that packages compiled for stronger CPUs but still on the same general architecture doesn't give differences that could cause runtime errors, unless perhaps if some of the packages are hard-coded for a specific architecture, which I think if not old, are generally just having a bad programming practice. Still those kinds of packages should be rare. And even far rare I think to be included in Slackware.
"believing" it's not enough.

Quote:
Yet again at first I am aware that those distros would still need to be tested, so I thought that they could be one release candidate delayed from the major release. Perhaps a week or two after it there could be a final release. It's simple because you just have to exclude those packages that don't work and revert back to the generic version, and you don't have to force-fix them.
and who tells you that they will play well with the optimized versions of the other packages, have you tried it?

Quote:
Everything should be built easily and automated (from building packages to building the ISOs) if the SlackBuilds in the main are updated to allow newer CPUs and an automation script is already made. Even if the packages are continously updated if their SlackBuilds have a format that follows a standard, things would go well.
you probably have never done this so you don't know how you are wrong.

Quote:
Again you don't have to test a package for every extension subarch you could have. You just have to make sure that it runs with the main generic platform, and that it's compatible with its co-packages, strictly if possible.
and who do you think will run untested stuff?

and how can you call the result STABLE? because you "believe" it will be stable? LOL

Last edited by ponce; 05-04-2013 at 02:43 PM.
 
Old 05-04-2013, 02:41 PM   #114
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,248

Original Poster
Blog Entries: 8

Rep: Reputation: 235Reputation: 235Reputation: 235
Quote:
Originally Posted by chemfire View Post
Code:
        
        movl    $3, 28(%esp)
        movl    $4, 24(%esp)
        movl    28(%esp), %eax
        cmpl    24(%esp), %eax
        jle     .L2
        movl    $0, (%esp)
        call    exit
.L2:
        movl    $1, (%esp)
        call    exit
Consider then totally simplistic example above. Do you need a noop before cmpl? (No cpu really would) but there are odd cases where the ordering of instructions, insertion or not of noop, selection of branching methods etc, can cause a register value to be used before its stabilized. This is why you don't want to go crazy with letting the compiler optimize. You might introduce really subtle bugs. The compiler is going to be able to produce output for valid input no matter what the optimization flags are; and the assembler is going to be able to produce object code. You won't see problems until runtime and even then it might depend on other odd corner cases.
Does this still apply with new gcc's? And does that apply to using newer instructions? Or is it about another optimization? Because we still use -O2 in the example.

Last edited by konsolebox; 05-04-2013 at 02:43 PM.
 
Old 05-04-2013, 02:58 PM   #115
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761
Quote:
Originally Posted by konsolebox View Post
And what about the less known dependencies. Is every depending package also monitored for every update of a dependency? That's quite a large task if you could imagine the links.
It is a large task but the core Slackware team do initial testing and then later a sub-selection of Slackware users (those running -current) also test. The numbers of people involved (each with their own interests in different selections of software) mean that, yes it is reasonable to expect that most things are indeed tested. When problems do occur they are noticed and fixed before Slackware goes final. This system has been proven to work, if it didn't Slackware's reputation for stability would suffer and so far, after all these years, this has not happened.
 
Old 05-04-2013, 03:02 PM   #116
konsolebox
Senior Member
 
Registered: Oct 2005
Distribution: Gentoo, Slackware, LFS
Posts: 2,248

Original Poster
Blog Entries: 8

Rep: Reputation: 235Reputation: 235Reputation: 235
Quote:
Originally Posted by ponce View Post
like I asked, I really would like to know if you actually are running what you rebuilt...
No I'm not running what I rebuilt yet. I am assuming alright. Sorry if that's what a user who compile a bunch of packages far more manier than Slackware with even stronger optimization flags.
Quote:
"believing" it's not enough.
And haven't you guys did as well?
Quote:
you probably have never done this so you don't know how you are wrong.
Yeah I'm just imagining how it could be done again. Just like how I was so wrong as well before I proved things here. And I actually went far already with those stuffs. How bout you prove that you're correct instead.
Quote:
and who do you think will run untested stuff?
Probably some possible less conservative people I believe. You'll never know. I can't say there would be, you can't also say there won't.
Quote:
and how can you call the result STABLE? because you "believe" it will be stable? LOL
You're actually right, even though I actually admitted that it has to be tested, but please tell me that when you tried to optimize things yourself as well.
 
Old 05-04-2013, 03:07 PM   #117
ponce
LQ Guru
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 7,068

Rep: Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145Reputation: 4145
Quote:
Originally Posted by konsolebox View Post
No I'm not running what I rebuilt yet. I am assuming alright. Sorry if that's what a user who compile a bunch of packages far more manier than Slackware with even stronger optimization flags.And haven't you guys did as well?
leaving away that you should rebuild everything with a native toolchain, I don't have to prove anything, it's you that say that maintaining 14 different distributions it's easy, not me.
Quote:
Yeah I'm just imagining how it could be done again. Just like how I was so wrong as well before I proved things here. And I actually went far already with those stuffs. How bout you prove that you're correct instead.
as above.
Quote:
Probably some possible less conservative people I believe. You'll never know. I can't say there would be, you can't also say there won't.
you aren't running them yourself
Quote:
You're actually right, even though I actually admitted that it has to be tested, but please tell me that when you tried to optimize things yourself as well.
I actually tried it in the past, but after a while I gave up realizing it isn't worth the pain.

hopefully, this xkcd comic will explain you why
https://xkcd.com/1205/

Last edited by ponce; 05-04-2013 at 03:15 PM.
 
Old 05-04-2013, 03:26 PM   #118
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 2,557

Rep: Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761Reputation: 1761
Quote:
Originally Posted by konsolebox View Post
Just like how I was so wrong as well before I proved things here.
What did you prove exactly? It was fully expected that you could rebuild many packages but not that you could rebuild them all without manually updating the SlackBuilds. This is exactly what happened.

The downsides of doing a large number of 'optimised' Slackware variants still hold true:
  • It requires Pat to spend more time on SlackBuild maintenance (to ensure that rebuilds always work after every update)
  • It requires Pat to spend more time building
  • It requires more testing due to their being more packages
  • Further confusion about what Slackware version a given user should run

It is also still not clear what the benefits are. How much faster are your builds (have you done benchmarking)? Is their any market for this (yours if the first request I have read for 'optimised' Slackware variants)?

You still haven't proved that any of this is at all worthwhile.
 
Old 05-04-2013, 03:40 PM   #119
Erik_FL
Member
 
Registered: Sep 2005
Location: Boynton Beach, FL
Distribution: Slackware
Posts: 821

Rep: Reputation: 258Reputation: 258Reputation: 258
As a long time embedded software developer for Intel X86 I would like to put in my two cents.

Although the X86 architecture does undergo generational improvements, most new instructions tend to fall into two categories. The first are instructions of benefit to an operating system, usually for synchronization, locking, or multi-processor support. The second are instructions that benefit one specific kind of calculation problem such as cryptography or audio/video conversion.

Recompiling the kernel for the exact hardware covers the first category of improvements. Most applications that use the second category of instruction improvements have very specifically designed code, often assembly language. They detect the existence of the new instructions and do not depend on the C compiler to generate efficient code. My point is that the shotgun approach to optimizing the performance of an entire distro really doesn't provide much benefit.

I can say this from experience, because almost all significant performance improvements in software are achieved by redesigning the software (or parts of it) rather than changing compiler options. Most of the compiler options that affect performance are not architecture specific. They are generic compiler optimizations and are used as much as possible for released software. Optimization is disabled for debugging, and for some very specific modules that don't benefit from optimization and would malfunction with compiler optimizations.

If one compiles the kernel for their specific hardware platform, the majority of the performance benefit is obtained. I always compile my kernel after testing with the generic kernel.

Most of the performance improvements in the X86 architecture are made to existing instructions without adding new instructions. For the investment of time and money, it is a much better return to simply buy newer hardware than to spend time trying to optimize software with compiler options.

The most dramatic performance increase due to compiler options and the instruction set can be obtained by switching from a 32-bit kernel to a 64-bit kernel. Slackware does maintain a separate 64-bit build. For one concerned about performance, moving to a 64-bit CPU and 64-bit kernel is the most sensible solution with the greatest chance of providing real performance increases.

As a Slackware user, I would prefer Slackware to keep the focus on stability and compatibility rather than being able to build a version for each specific instruction set variation. I do not need scripts to make it convenient for me to re-build all of Slackware from source. Unless that benefits the Slackware developers and maintainers, I view it as a waste of time. Of course I can only speak for myself, and not the other Slackware users.

In my opinion, time should be spent on choosing a solid version of KDE for a Slackware release, and making Slackware less KDE-centric. To that end, I would much rather see an XFCE Slackware version without KDE and with more applications to replace those from KDE. That is a difficult task, considering that most applications depend on KDE, GNOME or Trinity. The challenge for Slackware will be how to avoid tying its fate directly to KDE. Perhaps it is time for Slackware to re-consider GNOME or look at Trinity.
 
5 members found this post helpful.
Old 05-04-2013, 03:42 PM   #120
Petri Kaukasoina
Senior Member
 
Registered: Mar 2007
Posts: 1,730

Rep: Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411Reputation: 1411
You might want to check how much adding a -march flag helps. Try some cpu intensive command you have noticed taking some time to execute. Build the package twice, with and without the -march flag. Then run the command, for example, three times with both versions. Do you see a difference?

For example
Code:
time xz a_large_file
(When I have done that before, I have only tried it with a couple of commands but I haven't seen any difference.)
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Optimized distros for my particular computer setup? Rick069 Linux - Software 3 09-30-2007 11:39 AM
Custom slackware CD with optimized packs sl4ckw4re Slackware 5 07-13-2006 04:03 PM
Any Debian-based distros that are optimized for 686? lefty.crupps Debian 8 06-16-2005 08:43 AM
Is Slackware booting already optimized? dhave Slackware 1 11-21-2004 12:09 PM
Real-life speed diference between 386,586 and 686 optimized distros Embedded Linux - Distributions 4 06-19-2003 12:21 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 02:12 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration