Debian Planet










Welcome to Debian Planet

Search

Apt-get into it.
Main Menu

  • Home

  • Topics

  • Web Links

  • Your Account

  • Submit News

  • Stats

  • Top 10

  • Debian

    These are important Debian sites one should not be without!

  • Official Debian site

  • Package search

  • Mailing list archives

  • Bug reports

  • Debian on CD

  • Unofficial woody CD ISOs

  • Unofficial APT sources

  • Developers' Corner

    Other great Debian news sources:

  • Debian Weekly News

  • Kernel Cousin Debian

    (Debian mailing lists digested)
  • Community Groups

    Need help? You're not alone on this planet.

  • debianHELP

    (User support site)

  • Debian International

  • DebianForum.de

    (Deutsch)

  • EsDebian

    (español)

  • DebianWorld

    (français)

  • MaximumDebian

    (Italiano)

  • DebianUsers

    (Korean)

  • Debian-BR

    (Português)

  • IRC

    The place to get help on a Debian problem (after reading docs) or to just chat and chill is #debian on irc.debian.org.

    Many of the Debian Planet staff live there so pop by and say hello.

    Wanna write?

    Got that latest or greatest scoop? Perhaps you have some important news for the Debian community? Submit a news item!

    Or perhaps you've written a rather ground breaking insight into some aspect of Debian and you feel compelled to share it with others? Knock up a longer editorial article and send it to the editors.

    Sponsorship

    DP is sponsored by Xinit Systems and kieser.net.

    Domains paid for and hosted by uklinux.net.

    Buy your Debian merchandise at DebianShop.com.

    Who's Online

    There are currently, 59 guest(s) and 1 member(s) that are online.

    You are Anonymous user. You can register for free by clicking here.

      
    apt-get -b source-dist-upgrade
    Contributed by Anonymous on Tuesday, November 27 @ 13:54:10 GMT

    /dev/random
    As we all us know, a lot of Debian users have Pentiums II, Athlons, etc, and our nice x86 Debian is fully built for 386, so there's a lot of speed lost. Some movements grew up like the one who built the entire potato distribution for 586... but it's not enought. Potato isnt unstable, 586 isn't the same as 686... we can have more optimized code. By the way, a user can download and build for his own some packages and obtain suth optimizations, but it's very boring to download and build the packages manually. Why not something like apt-get dist-upgrade what downloads, builds and installs the new source packages? Imagine a entire system build optiimized for your athlon... imagine it...

    DanielS: Just get sbuild and set up a personal build daemon, and feed it a list of every package you want to build.

     
    Related Links

  • More about /dev/random
  • News by DanielS

    Most read story about /dev/random:
    HOWTO get your G400/450 singing and dancing

    Last news about /dev/random:

    Printer Friendly Page  Send this Story to a Friend
  • "apt-get -b source-dist-upgrade" | Login/Create Account | 40 comments
    Threshold


    The comments are owned by the poster. We aren't responsible for their content.

    Errr... (Score: -1, Flamebait)
    by Anonymous on Tuesday, November 27 @ 14:49:37 GMT

    Why run x86 at all? There are so much better architechures out there (Alpha alpha yeah yeah!)

    [ Reply ]


    Re: Errr... (Score: 0)
    by Anonymous on Tuesday, November 27 @ 14:59:53 GMT

    Sure. But i think this idea is good, with ANY architechture, not only x86

    [ Reply ]


    Re: Errr... (Score: 0)
    by Anonymous on Tuesday, November 27 @ 15:11:06 GMT

    Price does come into play as well. I can't afford an Alpha, nor can I build one from scratch.

    [ Reply ]


    it's not that much faster (Score: 1)
    by kfs27 on Tuesday, November 27 @ 15:08:51 GMT
    (User Info)

    i can see compiling some of the huge bloatware packages so they don't lag as much...but the speed difference optimized is practically nothing...can't you all stop complaining about optimized code...

    [ Reply ]


    Re: it's not that much faster (Score: 1, Informative)
    by Anonymous on Tuesday, November 27 @ 15:17:43 GMT

    Sorry, you can't make blanket statements like that; sometimes optimization makes a huge difference, sometimes it doesn't

    [ Reply ]


    no, he's right (Score: 1)
    by Crag on Tuesday, November 27 @ 20:43:29 GMT
    (User Info)

    Unless you're doing scientific computing on a cluster, or ray-tracing, or something else time sensitive, you probably won't notice the difference. Anyone who does want to tinker with their machine that intimately should probably look at *BSD, where they have 'make world' and such.

    Kids these days don't know how good they have it.

    [ Reply ]


    Re: no, he's right (Score: 0)
    by Anonymous on Wednesday, November 28 @ 20:26:27 GMT

    Eh, I've heard that pentium optimized tar is up to 40% faster when not bottlenecked at the disk or RAM.


    -l

    [ Reply ]


    Try it yourself, then (Score: 1)
    by Crag on Thursday, November 29 @ 00:52:48 GMT
    (User Info)

    a) good luck finding a machine not bottlenecked at the disk or ram

    b) how much time do you spend waiting for tar?

    c) tar, or tar+gz or tar+bz2 or what?

    d) show me the data, that '40%' sounds like instant information

    e) as I said before, if you care that much about speed you probably know how to find out what your bottlneck is and address it. The 'pentium-builder' package is probably of interest, as well as the sbuild programs mentioned elsewhere. However, it's likely to be easier/cheaper (when including time spent in cost) to simply upgrade.

    f) Even if EVERYTHING is 40% faster at the CPU when compiled for Pentium or 686, that's still only a 40% improvement system-wide (what took 100 seconds now takes 60). If only tar is improved by 40% and everthing else is improved by 5%, it's probably not worth the trouble.

    [ Reply ]


    Re: no, he's right (Score: 1, Interesting)
    by Anonymous on Friday, November 30 @ 15:41:20 GMT

    Scientific computing is exactly what I do and I find it a pain having to recompile lots of packages everytime they get upgraded in the archive. And its not a 386 v. 686 issue; that doesn't make a huge difference. Its things like function inlining and certian memory bandwidth optimizations that for some libraries can make a huge difference.

    [ Reply ]


    Re: it's not that much faster (Score: 0)
    by Anonymous on Tuesday, November 27 @ 15:23:45 GMT

    I agree with your "blanket statement". I spent forever compiling my entire system once and only noticed a differance when running my window manager. Mozilla wasn't really noticeably faster either.

    If I had my pick of things I'd like optimized it'd be X, windowManager, graphical web browser, and kernel. IME anything else is really a waste of time.

    [ Reply ]


    Re: it's not that much faster (Score: 0)
    by Anonymous on Tuesday, November 27 @ 15:32:57 GMT

    mplayer worked a lot faster when i compiled it with gcc-3.0 instead of gcc-2.95... so what if i compare 386 vs athlon code? I think the entire system will feel like with +30% more of clock frequency

    [ Reply ]


    Re: it's not that much faster (Score: 0)
    by Anonymous on Tuesday, November 27 @ 22:24:14 GMT

    Or the 5% that's actually more probable. I doubt you'll see 30% gains.

    [ Reply ]


    Re: it's not that much faster (Score: 0)
    by Anonymous on Wednesday, November 28 @ 02:26:31 GMT

    You must be good if you can tell the clock frequency that a program seems to be running at.

    I think you mean a 30% speed gain, but i really doubt you would get that, even from a different compiler version.

    [ Reply ]


    Re: it's not that much faster (Score: 0)
    by Anonymous on Wednesday, November 28 @ 16:50:26 GMT

    Hmm, I did the same benchmark on mplayer two month ago, and I only noticed a slight speed improvement with gcc-3.0.2-pre.

    [ Reply ]


    Re: it's not that much faster (Score: 0)
    by Anonymous on Wednesday, November 28 @ 04:09:44 GMT

    Exactly, just put some thought into the things you compile. If you want lots of general speedups, just recompile libraries instead of applications. Libraries that lots of things depend on and anything that runs in tight loops are all you need.

    Stuff like Mozilla and Nautilus probably bottleneck more on disk and memory bandwidth than CPU speed anyway (perhaps 'gcc-3.0 -Os' might speed them up?).

    The only things I build for myself are SDL, xmame/xmess, mplayer, and libcss. I suppose I could grow a pair and do libc and X for a sizeable speed gain, but having those two wigging out on me would kinda suck.

    [ Reply ]


    Re: it's not that much faster (Score: 0)
    by Anonymous on Wednesday, November 28 @ 20:30:27 GMT

    Stuff like Mozilla and Nautilus probably bottleneck more on disk and memory bandwidth than CPU speed anyway

    Not to mention the kernel. Memory-intensive apps like those were taking a big hit with bad segmentation problems in the Linux kernel memory allocator. It's been fixed now, but goes to show how many factors there are in making a big app work efficiently.

    -l

    [ Reply ]


    Re: it's not that much faster (Score: 0)
    by Anonymous on Thursday, November 29 @ 16:12:23 GMT

    No, but its some. And I want that, even if

    its only 1 percent or 2.

    And, many packages i've compiled easily

    runs 30-40% faster than the prebuilt ones.

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 0)
    by Anonymous on Tuesday, November 27 @ 15:51:49 GMT

    Am I right to assume that DanielS means dbuild in stead of sbuild? And is the package automatically build for the cpu dbuild is running on or should you specifically export some flags before compilation (or something else)?

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 2, Informative)
    by ajk (ajk@debian.org) on Tuesday, November 27 @ 17:22:52 GMT
    (User Info) http://www.iki.fi/gaia/

    Am I right to assume that DanielS means dbuild in stead of sbuild?

    No. Dbuild is obsolete; sbuild is part of buildd, which is the system that the autobuilders use, but it's not packaged. Look here for instructions.

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 1, Interesting)
    by Anonymous on Tuesday, November 27 @ 16:01:26 GMT

    Yes, you're able today to build a list of packages for your architechture, but the idea is to do it all automatically, as easy as apt-get dist-upgrade. I think the idea is possible, and will kick ass if somebody writes it...

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 1, Insighful)
    by Anonymous on Tuesday, November 27 @ 17:21:47 GMT

    Plus, if anyone implements the patch mechanism mentioned some time ago on debian-devel (IIRC), dial-up users will get the bleeding edge without too much download time. Source patches should be smaller than binary ones 🙂

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 2, Informative)
    by piman on Tuesday, November 27 @ 20:09:19 GMT
    (User Info) http://www.sacredchao.net

    # cat > some_file

    mozilla

    xserver-xfree86

    galeon

    fileutils

    ^D

    # for I in `cat some_file`; do apt-get -b source; if [ -e $I*deb ]; then dpkg -i $I*deb; fi; done

    There may be a little manual intervention required after this, still.

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 1)
    by piman on Tuesday, November 27 @ 20:14:01 GMT
    (User Info) http://www.sacredchao.net

    Oh, and

    # dpkg -l | awk -F" " '{print $2}' > some_file

    Will generate an appropriate some_file for your system.

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 2, Informative)
    by Anonymous on Tuesday, November 27 @ 20:58:10 GMT

    Not even close; too many truncated package names. More like:

    dpkg --get-selections | egrep -w 'install|hold' | awk '{print $1}' > some_file

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 0)
    by Anonymous on Tuesday, November 27 @ 22:08:05 GMT

    this is not automatic like apt-get dist-upgrade. if someone writes it, it will kick ass, sure.

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 2, Insighful)
    by MBCook on Tuesday, November 27 @ 21:03:45 GMT
    (User Info)

    Well, apt is smart enough to be able to get x86 packages for me instead of alpha or ppc, so it seems like it should be easy to teach it to get 686 packages. If that's not avalible then get 586. If that's not there 386, etc.

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 1)
    by Schoinobates2Volans on Tuesday, November 27 @ 21:11:52 GMT
    (User Info)

    Except there are no 586 or 686 packages.

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 0)
    by Anonymous on Wednesday, November 28 @ 18:22:02 GMT

    The Debian archive is already so huge that to put extra packages for 686/586/486/386/atholon/P4/SSE/MMX/etc would create such a huge archive that it would be impossible for it to get the wide spread mirroring it gets now.

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 1, Insighful)
    by Anonymous on Thursday, November 29 @ 01:46:23 GMT

    This is why a apt-get -b source-dist-upgrade can be useful. The packages build in the users machines for the processor they use and there's no need to keep packages for all procesors in the mirrors, and no need for a compilefarm. When debian can afford it, prepackaged accelerated binaries will be cool, but by the moment the fetch-&-build idea is very good.

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 1, Interesting)
    by Anonymous on Wednesday, November 28 @ 00:11:36 GMT

    Why not modify the apt code to allow for specific architecture compilations with the build option?

    This would allow the advanced end user to pick and choose which packages to tweak and which packages to leave normal.

    This would save development time, save storage space, and a lot of headaches 😀

    Stef

    [ Reply ]


    Great for Pine, nVidia drivers and friends (Score: 1, Interesting)
    by Anonymous on Thursday, November 29 @ 07:50:04 GMT

    This would be great for packages that Debian is not allowed to distribute in binary form. Right now, whenever I feel like upgrading the Debian-provided nVidia drivers I have to manually re-build them from source. Granted, this is a lot easier than maintaining them by hand would be, but on the other hand it is a lot harder than having this process automated would be.

    I think this would be an excellent idea, but not because the optimization issue.

    Cheers //Johan

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 0)
    by Anonymous on Thursday, November 29 @ 14:34:28 GMT

    You might want to look at the Debian policy proposal related to this issue, in the BTS as #120418.

    Take care,

    [ Reply ]


    Care to provide a link? (Score: 1)
    by Bob_Robertson on Tuesday, December 04 @ 05:27:41 GMT
    (User Info)

    What, prey tell, is a "BTS"? Can you provide a link, or more descriptive locator than just a number?


    Bob-

    [ Reply ]


    Re: Care to provide a link? (Score: 1)
    by ajk (ajk@debian.org) on Wednesday, December 05 @ 21:42:46 GMT
    (User Info) http://www.iki.fi/gaia/

    It's the Bug Tracking system.

    [ Reply ]


    Thank you. (Score: 0)
    by Anonymous on Friday, December 07 @ 07:15:24 GMT

    17576 different possible TLA's (three letter acronyms) and people like the Denizens of Doom and the Department of Defense even re-use some of them.

    [ Reply ]


    off topic compiler optimization (Score: 0)
    by Anonymous on Thursday, November 29 @ 16:13:11 GMT

    bye the way are they someone who know good flag for compiler ?

    I use to put that

    -O2 -march=i686 -fomit-frame-pointer -Wall -malign-functions=4 -fschedule-insns2 -malign-double -fexpensive-optimization

    But I'm not really this is the best options.

    what do you think about that ?

    [ Reply ]


    Re: dbuild rocks! thanks for hint DanielS (Score: 0)
    by Anonymous on Thursday, November 29 @ 19:55:41 GMT

    .

    [ Reply ]


    The Debian Planet Collaborative CPU Optimization Project (Score: 1)
    by Bob_Robertson on Tuesday, December 04 @ 00:49:11 GMT
    (User Info)

    The kernel is already available in multiple versions for CPU, I'm quite happy to see that myself. Thank you Kernel Package Maintainers from the bottom of my stack.


    However, recompiling a long list of packages for specific CPU's, when they will run (and run rather well if not perfectly) as 386 binaries, is a waste of their time. I might say that keeping the kernel in multiple versions is a waste of their time too, but having built kernels I am very happy to let them do it.


    So what is left of generally used, common things that benefit from being recompiled? I read here "libraries", maybe the primary X systems. Ok, sounds good.


    Since the command line tools exist to download source, compile and install a specific package, rather than argue about what the likely speed gain is let's put together a list, script like, of the command line entries to update the most common and/or most effective packages to recompile.


    If (installed package x) = (latest package x on server)

    Then (get source; compile source; install)

    If (installed package y) .....


    I cannot imagine that even a 5% increase in speed of X wouldn't be a GoodThing(tm), since X effects everything when it's running, and for lots of people X is the application they use most. That and the primary libraries would be first on the list if the arguments in this thread are any indication.


    One of the biggest gripes against Micro$oft is their use of hardware to excuse abominable programming practices. Here is a very simple and effective idea, easily hosted as a text file on Debian Planet itself. It leverages the greatest benefit of Debian, online packages easily accessed individually, already tested by hundreds of brave volunteers.


    Call it the Debian Planet Colaborative CPU Speed Project or something. "It's time for Golfing With God, with the Reverend Dr. Jonny Fever..."


    Bob-

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: 1)
    by ahurt on Tuesday, December 04 @ 03:29:55 GMT
    (User Info) http://users.starpower.net/apolhurt

    OK. I'm getting the hang of this, now.

    What should I build first?

    I found this in src/mozilla-0.9.6/debian/scripts/archmap:

    arch=$(dpkg --print-gnu-build-architecture)

    So I got to thinking (second or third time this month!), went to the command-line, and did a 'dpkg -print-gnu-build-architecture'.

    I got 'i486' on my Pentium-233MMX. Big surprise, I'm sure, for everyone here.

    So I'm thinking that I should build gcc first (since I'm going to use this for every other build?)

    Or should I build the deps first.

    Chicken, or the egg?

    Thanks, all, for letting me participate.

    ah

    [ Reply ]


    Re: apt-get -b source-dist-upgrade (Score: -1, Offtopic)
    by Anonymous on Saturday, December 08 @ 03:57:57 GMT

    IMHO: The egg

    [ Reply ]


    Based on: PHP-Nuke

    All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2000 by Debian Planet

    You can syndicate our news using the file backend.php.