Well, yes and no. You can run a 90% stable Gentoo system and use only unstable packages for things like KDE and mplayer. I know you'll say you can use apt pinning to do the same thing, but it's not as easy to manage as per-package ~x86 flags.
Nono, the unstable branch of debian does not contain unstable software. Don't let the name confuse you. The packages in "unstable" are the same ones that you're running on Gentoo. There are no unreleased versions of software, it's just the latest official releases that the upstream developers have released as stable. The only debian branch that really contains unstable (as in CVS snapshots of) software, is called "experimental". There you will find things like release candidates and betas for some packages. If you stick to unstable you will only get software that has been deemed stable by the upstream authors. Unstable just means that all the packages haven't been extensively tested against each other to make sure there are absolutely no strange corner cases. This is exactly the same situation as on Gentoo. 99% of the time everything works just fine.
I think the OP was referring to the installation time, and not performance.
No I know. It just seems that since people have claimed that the performance difference is felt most on large complicated pieces of software like OO, you would want to go to the trouble of compiling it.
I just recently switched from Gentoo to Ubuntu, and there was one application in particular that I've noticed a huge speed decrease, and that's eclipse.
Yeah eclipse is a pig on my laptop as well (Debian). I don't know how Ubuntu handles it, but Debian installs a version of eclipse compiled with GCJ by default. Seems backwards, but that version actually seems to run slower than the one that runs on top of the Sun Java VM. I switched to the vm package and it seems better.
Of course not. Compare Debian unstable to Gentoo though, and they are probably very close. Debian stable is not anything like Gentoo, so the comparison is pointless. Debian unstable is very close to Gentoo, both providing the kind of "rolling" updates, where you really don't need to install releases, since you're already running the latest version of everything. Hell, if you want to install some packages from the "experimental" debian branch, you even get pre-release versions of some software. For example, at work I'm running Xorg 7.3rc and Openoffice 2.3 snapshot.
The reason why Gentoo can release faster is because Portage basically just downloads the source from SourceForge and runs "./configure && make && make install", usually using the default install options of the package.
Right, but I assume the package maintainer still has to check whether the thing even compiles, so he'll have to compile it himself first. The time difference in the end should be negligible. Also keep in mind that while the package might exist in gentoo, you can't actually use it until you've compiled it, so you can't discount the compilation time just because you're doing it instead of the packager.
Remember the term "RPM Hell"?
Vaguely, I never encountered it.
Q: Why were they doing this? A: The latest versions of packages were taking too long to appear in the RedHat repositories! This is precisely the reason I left RH and then tried Debian and Gentoo.
Fair enough, but you should try running Debian unstable. You get the new software fast without the hassle of compiling.
I have had to fix binary only packages because the vendor decided to fix a show stopping blatant bug in the next major relase which would come out 1 year later. I got running code only because I could get down and dirty with the binaries to find and fix it. Once is enough to convince people that binaries are just as fraught with errors as code that has source available.
What does this bug have to do with compiling from source? You seem to be confusing proprietary software with pre-built binaries. If a binary on Redhat/Suse/Debian has a problem, there is nothing stopping you from fixing that bug in the source and rebuilding that binary. Your argument makes no sense.
686 binaries didn't work well when P4 was out. Each CPU did have major differences and optimizations. Athlon Tbird is not a good example because it was a well rounded CPU. It does well on most codes. P4 OTOH, did poorly at some things and if the binary didn't take that into account, Gentoo compiled code did far better than the binaries.
Proof? And don't give me stuff like video encoding. Some binary distros give you optimized versions of those packages too, or you can always compile those few yourself. I mean general system performance that a user would notice.
Also with source, you can use other compilers than GCC.
In theory yes, but good luck compiling a lot of complex linux software with anything but GCC (and even then, specific versions of GCC). Try compiling Mozilla with GCC 4.2 for example. I'll save you some time and let you know it Doesn't Work.
If you like binaries so much, just look at what happened with RedHat 7.0. It was a disaster.
Redhat 7? Holy crap you're really reaching. That was back in 2000. Gentoo barely existed back then (1.0 came out in 2002). GCC was relatively crap back then, but that was 7 years ago. Things have changed in the meantime.
-O9 optimizations aside, the USE flags are what really make Gentoo shine. For folks who want to include or omit specific libraries/features, all built consistently across many apps, USE can't be beat. It's easy to build a tight, efficient system.
True, but is it worth the hassle? Right now you might decide that you really don't need to have VlC support the matroshka codec because you've never heard of it, so you leave it out to make it smaller, but then you encounter a file like that and have to rebuild VLC to make it work. The point is, that most of the time the developers of a package have a far better idea of what libs should be used than you do (exceptions apply of course). Unless you're targetting really constrained hardware, I don't see how all that time could be worth it. You'll spend way more time thinking about what to include than you will ever save from speed increases.
For big packages like OpenOffice or Mozilla -- that's why the devs gave us the pre-compiled bins. We're not all crazy, you know.:)
That's funny. Another guy said that Openoffice is where he notices the biggest difference:)
I'm not so sure about that. I was running a stock Debian kernel on an old Dell, and it was slow as hell. When I switched to a custom compiled kernel, I noticed a significant boost in performance. So I think making a blanket statement like yours is a little premature.
Debian provides different kernels optimized for different instruction sets (i486, 686, k7, amd64 etc). Compiling your own kernel to replace those won't make a significant difference in speed if you use the same options. Of course if you disable a bunch of features then yes it could be faster. But that is not the same as optimization on the compiler level.
Not necessarily. What if the package that's broken hasn't been updated in the repository yet? You may wait days, weeks, or months for the fix to appear.
So what if it also hasn't been updated in portage yet? I don't see the difference. The speed of package maintainers updating their packages is going to be roughly the same in any distro. I don't know how kubuntu operates, but on debian if some update is broken, I can just downgrade, and I don't have to recompile anything.
All precompiled binaries for distros are compiled for i386 or i586. I'm running nither so compiling from source with the CORRECT flags on my compiler makes a big difference.
Benchmarks? For most software the difference is going to be ~1%. You can't even perceive anything under 25% for most operations, since most operations are short anyway. Sure, if you do a lot of video encoding it might be worth compiling that for your specific CPU, but that's not an argument for Gentoo. You can compile single packages on any distribution, and Debian derivatives will even automate it for you. And in some distros the important packages (like the kernel, libc, mplayer etc) are already pre-built optimized for different processors.
More likely that one of those installs has java disabled. That makes a big difference in startup time. Sorry, but it's completely impossible that the code optimized for your processor is 400% faster than the non-optimized version on something as general as Openoffice. Most of the time spent loading OO is disk IO anyway. I don't know how you got your numbers or why they are what they are, but they definitely aren't due to differences in optimization flags to the compiler.
How would I go about enabling the r300 driver? Right now I'm still using the "ati" driver in xorg, and it certainly doesn't seem to accelerate anything. I've read about r300, but I can't figure out how to actually use it. Does it only exist in unreleased versions of X?
It probably won't be the default, but try Codeine. It's an amazingly simple video player, can handle DVDs just fine, and has one button, yet does everything you need from a video player 99% of the time (VLC for the other 1%).
I have used Linux for many years. I have tried out KDE from the very early versions of KDE/QT. However, the only thing that has always sent me back to Gnome in a day or two has been how farking ugly/blocky the QT widgets and toolkit, etc can be!
Oh dear. The look is dependant on the theme being used. Don't like it blocky? Choose a different theme! Just like GTK isn't ugly even though it appears so in thesescreenshots. There are obviously good and bad themes for both toolkits.
Oh, and why do the fonts in KDE look like blocky crap, however look so much smoother in Gnome on the same system with the same fonts?
Because Gnome uses 96DPI for all fonts, while KDE uses whatever value X11 gives it for the DPI. Due to lots of broken systems, this value is sometimes wrong. If you think it is wrong, go into the Control Center, click on Appearance -> Fonts, and choose 96DPI from the combo box and restart KDE.
Of course, if you don't use KDE apps you can't benefit from their integration. For me it's the opposite. I try to use as many KDE apps as possible. Sure, konqueror-the-web-browser is not quite as compatible or full featured as Firefox, but it integrates much nicer with the rest of KDE (spell check, password saving, file downloading, mimetype handling, keyboard shortcuts, file dialogs, configuration, widgets) that I use it 95% of the time over Firefox. Instead of Thunderbird I use Kontact and webmail, instead of Mplayer there is Codeine, and for most simple image editing tasks Krita and Kolourpaint are good enough so I rarely have to reach for the Gimp. The only app that really has no replacement is Openoffice, and with the KDE integration module it more or less fits into the desktop.
I would much rather see Konqueror and KOffice improve to surpass Firefox/Openoffice than have those projects given up. If you've ever seen the Mozilla codebase (or even worse, the Openoffice one) you wouldn't want anyone to be forced to work on that mess. Open source projects need to place the utmost importance on code quality to attract new developers. There aren't a lot of people willing to contribute to an open source project purely in their free time in the first place, and making the codebase hostile is a great way of scaring off those precious few. Without the commercial backing of Sun and the Mozilla foundation, neither Openoffice or Firefox would be even remotely close to where they are today. While all the grunt work has made them both into nice products, I don't like betting the farm on something that is essentially reliant on a constant influx of cash to keep going.
There's your Microsoft tax. By distributing documents in.doc format, the government is essentially telling you that you have to be able to afford Windows or be willing to steal it to read about what the government is producing. Of course, there are always alternatives (might be a computer running Windows at the local library), but that is not providing equal opportunity.
Interestingly enough, Konqueror/KHTML (on which Safari is based) is not vulnerable (just tried the demo). It does password saving as well, but apparently have found a way to avoid the problem.
It's a common excuse to blame the toolkit for your own incompetence.
Reminds me of a post on the Qt forums once, where a user said that Qt was really slow for drawing images, like 3 seconds to paint an image to the screen, but this user said that if he used OpenGL rendering, it was acceptably fast. Some people had already replied and said that if the standard method is too slow then you have to use OGL. Instead of asking the fundamental question of why it was so slow to start with. Well after I asked, it turns out this guy was looping through the image pixel by pixel and painting them to the screen one by one. So instead of painter->drawImage() he had over 400,000 function calls to draw a single pixel, and then came to the conclusion that Qt was slow.
Every time you do something that seems basic, but the tools you have make it hard or slow to do, then you need to re-evaluate how you're approaching the problem. Especially Qt is so mature that any common task you want to accomplish probably already has a function dedicated to it and won't require more than a few lines of code.
What exactly can't you do in Qt? I use it quite extensively, and have written quite a few custom controls, without any problems whatsoever. It would be interesting to hear what you think can't be extended easily.
You don't need the KDE libraries. Qt is an incredibly comprehensive framework. It's not just Widgets, its database access, xml, network, threading, lots of incredibly useful types etc.
And if you want the extra functionality of the kdelibs, you can legally use them, they are not GPL, they are LGPL, so you can link to them from a proprietary application with no problem (as long as you paid for Qt).
Huh? Looks about the same as on Windows. Sure, maybe it could be prettier, but it seems more or less fine to me. That thing is the search box that is always hidden until you hit CTRL CTRL to bring it up.. It's not like you have to look at it all the time.
Those are all reasonable (if minor features), but for point 3, consider trying the program Launchy, it's about 100 times better at launching apps with the keyboard than the start menu is. Once you've used it once, it learns what apps you use, so most apps you can start by typing a single letter. http://www.launchy.net/ Free and open source. Alt-space to bring it up.
Slashdot Mirror
Everybody has a condition. Everybody.
No, I really mean it. Everybody.
Let me guess, is yours hypochondria?
Here's knetworkmanager: http://packages.debian.org/unstable/kde/network-ma nager-kde
It's been in the official repos for quite a long time (can't remember exactly but I've been using it for probably more than 6 months).
Well, yes and no. You can run a 90% stable Gentoo system and use only unstable packages for things like KDE and mplayer. I know you'll say you can use apt pinning to do the same thing, but it's not as easy to manage as per-package ~x86 flags.
Nono, the unstable branch of debian does not contain unstable software. Don't let the name confuse you. The packages in "unstable" are the same ones that you're running on Gentoo. There are no unreleased versions of software, it's just the latest official releases that the upstream developers have released as stable. The only debian branch that really contains unstable (as in CVS snapshots of) software, is called "experimental". There you will find things like release candidates and betas for some packages. If you stick to unstable you will only get software that has been deemed stable by the upstream authors.
Unstable just means that all the packages haven't been extensively tested against each other to make sure there are absolutely no strange corner cases. This is exactly the same situation as on Gentoo. 99% of the time everything works just fine.
I think the OP was referring to the installation time, and not performance.
No I know. It just seems that since people have claimed that the performance difference is felt most on large complicated pieces of software like OO, you would want to go to the trouble of compiling it.
I just recently switched from Gentoo to Ubuntu, and there was one application in particular that I've noticed a huge speed decrease, and that's eclipse.
Yeah eclipse is a pig on my laptop as well (Debian). I don't know how Ubuntu handles it, but Debian installs a version of eclipse compiled with GCJ by default. Seems backwards, but that version actually seems to run slower than the one that runs on top of the Sun Java VM. I switched to the vm package and it seems better.
don't even try comparing Debian stable to Gentoo.
Of course not. Compare Debian unstable to Gentoo though, and they are probably very close. Debian stable is not anything like Gentoo, so the comparison is pointless. Debian unstable is very close to Gentoo, both providing the kind of "rolling" updates, where you really don't need to install releases, since you're already running the latest version of everything. Hell, if you want to install some packages from the "experimental" debian branch, you even get pre-release versions of some software. For example, at work I'm running Xorg 7.3rc and Openoffice 2.3 snapshot.
The reason why Gentoo can release faster is because Portage basically just downloads the source from SourceForge and runs "./configure && make && make install", usually using the default install options of the package.
Right, but I assume the package maintainer still has to check whether the thing even compiles, so he'll have to compile it himself first. The time difference in the end should be negligible. Also keep in mind that while the package might exist in gentoo, you can't actually use it until you've compiled it, so you can't discount the compilation time just because you're doing it instead of the packager.
Remember the term "RPM Hell"?
Vaguely, I never encountered it.
Q: Why were they doing this? A: The latest versions of packages were taking too long to appear in the RedHat repositories! This is precisely the reason I left RH and then tried Debian and Gentoo.
Fair enough, but you should try running Debian unstable. You get the new software fast without the hassle of compiling.
I have had to fix binary only packages because the vendor decided to fix a show stopping blatant bug in the next major relase which would come out 1 year later. I got running code only because I could get down and dirty with the binaries to find and fix it. Once is enough to convince people that binaries are just as fraught with errors as code that has source available.
What does this bug have to do with compiling from source? You seem to be confusing proprietary software with pre-built binaries. If a binary on Redhat/Suse/Debian has a problem, there is nothing stopping you from fixing that bug in the source and rebuilding that binary. Your argument makes no sense.
686 binaries didn't work well when P4 was out. Each CPU did have major differences and optimizations. Athlon Tbird is not a good example because it was a well rounded CPU. It does well on most codes. P4 OTOH, did poorly at some things and if the binary didn't take that into account, Gentoo compiled code did far better than the binaries.
Proof? And don't give me stuff like video encoding. Some binary distros give you optimized versions of those packages too, or you can always compile those few yourself. I mean general system performance that a user would notice.
Also with source, you can use other compilers than GCC.
In theory yes, but good luck compiling a lot of complex linux software with anything but GCC (and even then, specific versions of GCC). Try compiling Mozilla with GCC 4.2 for example. I'll save you some time and let you know it Doesn't Work.
If you like binaries so much, just look at what happened with RedHat 7.0. It was a disaster.
Redhat 7? Holy crap you're really reaching. That was back in 2000. Gentoo barely existed back then (1.0 came out in 2002).
GCC was relatively crap back then, but that was 7 years ago. Things have changed in the meantime.
-O9 optimizations aside, the USE flags are what really make Gentoo shine. For folks who want to include or omit specific libraries/features, all built consistently across many apps, USE can't be beat. It's easy to build a tight, efficient system.
:)
:)
True, but is it worth the hassle? Right now you might decide that you really don't need to have VlC support the matroshka codec because you've never heard of it, so you leave it out to make it smaller, but then you encounter a file like that and have to rebuild VLC to make it work. The point is, that most of the time the developers of a package have a far better idea of what libs should be used than you do (exceptions apply of course). Unless you're targetting really constrained hardware, I don't see how all that time could be worth it. You'll spend way more time thinking about what to include than you will ever save from speed increases.
For big packages like OpenOffice or Mozilla -- that's why the devs gave us the pre-compiled bins. We're not all crazy, you know.
That's funny. Another guy said that Openoffice is where he notices the biggest difference
I'm not so sure about that. I was running a stock Debian kernel on an old Dell, and it was slow as hell. When I switched to a custom compiled kernel, I noticed a significant boost in performance. So I think making a blanket statement like yours is a little premature.
Debian provides different kernels optimized for different instruction sets (i486, 686, k7, amd64 etc). Compiling your own kernel to replace those won't make a significant difference in speed if you use the same options. Of course if you disable a bunch of features then yes it could be faster. But that is not the same as optimization on the compiler level.
Not necessarily. What if the package that's broken hasn't been updated in the repository yet? You may wait days, weeks, or months for the fix to appear.
So what if it also hasn't been updated in portage yet? I don't see the difference. The speed of package maintainers updating their packages is going to be roughly the same in any distro. I don't know how kubuntu operates, but on debian if some update is broken, I can just downgrade, and I don't have to recompile anything.
All precompiled binaries for distros are compiled for i386 or i586. I'm running nither so compiling from source with the CORRECT flags on my compiler makes a big difference.
Benchmarks? For most software the difference is going to be ~1%. You can't even perceive anything under 25% for most operations, since most operations are short anyway. Sure, if you do a lot of video encoding it might be worth compiling that for your specific CPU, but that's not an argument for Gentoo. You can compile single packages on any distribution, and Debian derivatives will even automate it for you. And in some distros the important packages (like the kernel, libc, mplayer etc) are already pre-built optimized for different processors.
More likely that one of those installs has java disabled. That makes a big difference in startup time.
Sorry, but it's completely impossible that the code optimized for your processor is 400% faster than the non-optimized version on something as general as Openoffice. Most of the time spent loading OO is disk IO anyway.
I don't know how you got your numbers or why they are what they are, but they definitely aren't due to differences in optimization flags to the compiler.
How would I go about enabling the r300 driver? Right now I'm still using the "ati" driver in xorg, and it certainly doesn't seem to accelerate anything. I've read about r300, but I can't figure out how to actually use it. Does it only exist in unreleased versions of X?
It probably won't be the default, but try Codeine. It's an amazingly simple video player, can handle DVDs just fine, and has one button, yet does everything you need from a video player 99% of the time (VLC for the other 1%).
I have used Linux for many years. I have tried out KDE from the very early versions of KDE/QT. However, the only thing that has always sent me back to Gnome in a day or two has been how farking ugly/blocky the QT widgets and toolkit, etc can be!
Oh dear. The look is dependant on the theme being used. Don't like it blocky? Choose a different theme! Just like GTK isn't ugly even though it appears so in these screenshots. There are obviously good and bad themes for both toolkits.
Oh, and why do the fonts in KDE look like blocky crap, however look so much smoother in Gnome on the same system with the same fonts?
Because Gnome uses 96DPI for all fonts, while KDE uses whatever value X11 gives it for the DPI. Due to lots of broken systems, this value is sometimes wrong. If you think it is wrong, go into the Control Center, click on Appearance -> Fonts, and choose 96DPI from the combo box and restart KDE.
Of course, if you don't use KDE apps you can't benefit from their integration. For me it's the opposite. I try to use as many KDE apps as possible. Sure, konqueror-the-web-browser is not quite as compatible or full featured as Firefox, but it integrates much nicer with the rest of KDE (spell check, password saving, file downloading, mimetype handling, keyboard shortcuts, file dialogs, configuration, widgets) that I use it 95% of the time over Firefox. Instead of Thunderbird I use Kontact and webmail, instead of Mplayer there is Codeine, and for most simple image editing tasks Krita and Kolourpaint are good enough so I rarely have to reach for the Gimp. The only app that really has no replacement is Openoffice, and with the KDE integration module it more or less fits into the desktop.
I would much rather see Konqueror and KOffice improve to surpass Firefox/Openoffice than have those projects given up. If you've ever seen the Mozilla codebase (or even worse, the Openoffice one) you wouldn't want anyone to be forced to work on that mess. Open source projects need to place the utmost importance on code quality to attract new developers. There aren't a lot of people willing to contribute to an open source project purely in their free time in the first place, and making the codebase hostile is a great way of scaring off those precious few. Without the commercial backing of Sun and the Mozilla foundation, neither Openoffice or Firefox would be even remotely close to where they are today. While all the grunt work has made them both into nice products, I don't like betting the farm on something that is essentially reliant on a constant influx of cash to keep going.
>> Admittedly they only work on Windows
.doc format, the government is essentially telling you that you have to be able to afford Windows or be willing to steal it to read about what the government is producing. Of course, there are always alternatives (might be a computer running Windows at the local library), but that is not providing equal opportunity.
There's your Microsoft tax. By distributing documents in
Interestingly enough, Konqueror/KHTML (on which Safari is based) is not vulnerable (just tried the demo). It does password saving as well, but apparently have found a way to avoid the problem.
Debian also has Java packages in the repos (in libs/non-free).
Then you're doing your updates wrong or using the wrong widget for the job. An excellent Qt resource is the forum at http://www.qtcentre.org/forum/f-qt-programming-2.h tml/ Ask there and post the relevant code.
It's a common excuse to blame the toolkit for your own incompetence.
Reminds me of a post on the Qt forums once, where a user said that Qt was really slow for drawing images, like 3 seconds to paint an image to the screen, but this user said that if he used OpenGL rendering, it was acceptably fast. Some people had already replied and said that if the standard method is too slow then you have to use OGL. Instead of asking the fundamental question of why it was so slow to start with. Well after I asked, it turns out this guy was looping through the image pixel by pixel and painting them to the screen one by one. So instead of painter->drawImage() he had over 400,000 function calls to draw a single pixel, and then came to the conclusion that Qt was slow.
Every time you do something that seems basic, but the tools you have make it hard or slow to do, then you need to re-evaluate how you're approaching the problem. Especially Qt is so mature that any common task you want to accomplish probably already has a function dedicated to it and won't require more than a few lines of code.
For example, you couldn't create something as simple as a statusbar item with QT, AFAIK.
/
I think this is what you want: http://doc.trolltech.com/4.2/desktop-systray.html
What exactly can't you do in Qt? I use it quite extensively, and have written quite a few custom controls, without any problems whatsoever. It would be interesting to hear what you think can't be extended easily.
You don't need the KDE libraries. Qt is an incredibly comprehensive framework. It's not just Widgets, its database access, xml, network, threading, lots of incredibly useful types etc.
And if you want the extra functionality of the kdelibs, you can legally use them, they are not GPL, they are LGPL, so you can link to them from a proprietary application with no problem (as long as you paid for Qt).
Huh? Looks about the same as on Windows. Sure, maybe it could be prettier, but it seems more or less fine to me. That thing is the search box that is always hidden until you hit CTRL CTRL to bring it up.. It's not like you have to look at it all the time.
Those are all reasonable (if minor features), but for point 3, consider trying the program Launchy, it's about 100 times better at launching apps with the keyboard than the start menu is. Once you've used it once, it learns what apps you use, so most apps you can start by typing a single letter. http://www.launchy.net/ Free and open source. Alt-space to bring it up.
If your readers have to look up the subject of the article, you've got it wrong.
Because news should only ever be about things everyone already knows! Heaven forbid that you might learn something new.