An anonymous reader writes "Phoronix has a new article where they provide Ubuntu 7.04, 7.10, 8.04, and 8.10 benchmarks and had ran many tests. In that article, when using an Intel notebook they witness major slowdowns in different areas and ask the question, Is Ubuntu getting slower? From the article: 'A number of significant kernel changes had went on between these Ubuntu Linux releases including the Completely Fair Scheduler, the SLUB allocator, tickless kernel support, etc. We had also repeated many of these tests to confirm we were not experiencing a performance fluke or other issue (even though the Phoronix Test Suite carries out each test in a completely automated and repeatable fashion) but nothing had changed. Ubuntu 7.04 was certainly the Feisty Fawn for performance, but based upon these results perhaps it would be better to call Ubuntu 7.10 the Gooey Gibbon, 8.04 the Hungover Heron, and 8.10 the Idling Ibex.'"
Were they testing each distribution on exactly the same hardware?
If so, that sounds completely fair to me that it would be slower. Go and (try to) install Vista on a machine that originally came with XP (pre-SP1) and see how much slower it is. Is that a fair test either? I think not.
As software gets more useful (and Ubuntu has, Vista not so much) it gets bigger and thus gets slower on the same hardware. Hardware advances at the same time though, so in real terms they keep about equal. When you test new software on old hardware of course it's going to be slower though.
When you test new software on old hardware of course it's going to be slower though.
That's hardly a given, lots of software gets better as it ages - new features are added, but also performance tweaks get added.
The problem is that software should be getting quicker on the same hardware, the alternative is bloaty apps that no-one wants to use. See Vista for the ultimate conclusion to that. You don;t want Ubuntu to end up the same, so its good that someone is pointing out performance issues. Hopefully the next release will have a few of these issues looked at and improved.
I heard this argument a wee too often. Maybe software should be more useful while at the same time NOT getting slower? Maybe that would be a good thing, as it would then run well on netbooks as well, what do you think?
You make it sound like it is inevitable and acceptable that newer software is slower than older software. I disagree. For one thing, one way to improve software is to make it faster. This is actually done sometimes. Secondly, even if you add features to software (which is another way to improve software), that doesn't have to make the software slower. In some cases, this may be inevitable, but in many cases it is not.
I personally see computers, and software, as tools for making life more efficient. When software becomes slower, efficiency is actually lost. When this isn't offset by providing me with a more efficient work flow, I lose efficiency. Since efficiency is the main reason I use computers in the first place, this is a big deal.
Indeed, it is common knowledge amoungst Real Programmers that you can run an arbitrarily large number of instructions per clock, allowing you to introduce entirely new functionality with zero performance hit. You just need to write everything in asssembler and have the right enchanted oils to annoint the heat sinks. By such a scheme CowboyNeal famously calculated the highest possible prime and now lives forever in a magic castle full of unicorns which shit rainbows.
(Hey, he used an absolute, I'm entitled to extrapolate it to its logical implications.)
Ok, the article completely ignores this (as do most of the above posters it appears). Each version of Ubuntu tested seemed to have different kernel builds. How much of the slowdown is due to the kernel being patched for security and bugs and how much is due to the software that has been added?
I think that's part of the point, yes? The concern is that for whatever reason - whether it be the new scheduler system in the kernel or the bloatware that Ubuntu includes, performance is degrading.
Good follow up would be to figure out specifically where - is it due to kernel changes? Then the problem may not be Ubuntu...
If you look closely you'll notice that (a) the benchmarks were run on a Thinkpad T60 laptop, and (b) there were significant differences on some benchmarks like RAM bandwidth that should have little or no OS components.
This sounds to me like the power management was dialing down the CPU on the later releases...
Many of the benchmarks (such as the lame, Java and RAM bandwidth benchmarks) are CPU-bound, and will run the majority of time in userspace. As the kernel should only be invoked for timer ticks, interrupts, TLB misses, etc (which would probably account for less than 1% of the CPU time), and change to the kernel should have minimal impact on the benchmarks.
The parent's comment that power settings have been misconfigured sounds spot-on.
Some of the benchmarks were hardware testing, and those showed variation. They should not, unless the compiler changed the algorithms used to compile the code between distros.
Benchmarking a multi-tasking system like Linux is a tough thing to quantify. The Linux kernel recently had a big scheduler change, this alone could account for shifting benhmark numbers. It may not actually "slowing down," but running multiple programs more evenly. The effective work is the same or better, which would mean "faster," but an almost useless benchmark would look slower.
by Anonymous Coward
on Monday October 27 2008, @08:16AM (#25525841)
... they are.
Seriously.
I can see several problems with the testing methodology as is:
* The test suite itself: The Phoronix test suite runs on PHP. That in itself is a problem-- the slowdowns measured could most likely be *because* of differences in the distributed PHP runtimes. You can't just say "hey, version Y of distro X is slower than version Z! LOLZ" because, WTF. You're pretty much also running different versions of the *test suite* itself (since you have to consider the runtime as part of the test suite). Unless you remove that dependency, then sorry, you can't measure things reliably. Which brings me to my second point...
* What exactly are they testing? The whole distro? The compiler (since most of the whole of each distro version is compiled with different versions of GCC)? The kernel? If they're testing the released kernel, then they should run static binaries that *test* the above, comparing kernel differences. If they're testing the compiler, then they should build the *same* compiled code on each version and run said compiled code (which is pretty much what I gather they're doing). If they're testing the utilities and apps that came with the distro, then they should have shell scripts and other tools (which run on a single runtime, not depending on the runtime(s) that came with the distro version). Because if you don't, you have no fucking clue what you're testing.
Honestly, I was unimpressed by the benchmarks. I happen to do performance benchmarking as part of my job, and I can tell you, you have to eliminate all the variables first -- isolate things to be able to say "X is slow". If you rely on a PHP runtime, use *exactly* the same PHP runtime for all your testing; otherwise, you'll get misleading results.
Disk access has been slowing everything down.
Variable elimination has been done, to varying extent, by multiple people here: https://bugs.launchpad.net/bugs/131094 [launchpad.net]
The GTK+ statistics are mind-boggling slow. That's what I notice most when I use Ubuntu or Fedora. On my non-Ubuntu laptop, I get the following results for GTK performance:
GtkDrawingArea - Pixbufs: 3.73s (on mine) vs 43-55s (Ubuntu) GtkRadioButton: 13s vs 29-60s
I just think that's ridiculous. What did they do to GTK+ to make it so slow?
Namely, graphics hardware. ATi graphics hardware and the FGLRX driver. FGLRX is known to have crappy 2D performance relative to its very strong 3D performance and the 2d performance that the open source driver excels at.
Meanwhile, 2D performance on Intel's hardware is smoking everyone else's pipe.
I hadn't noticed any general slowness when I upgraded from Feisty to Hardy (if anything, it was slightly faster), but I have noticed that when I run a document (even a short one) through groff, the resulting postscript file takes a lot longer to refresh in gv and evince. Alas, lots of googling revealed no similar situations, so it may just be something idiosyncratic with my set up.
I believe that PIE (position independent executable) along with some other security enhancements were turned on in Ubuntu around the time the slowndowns showed up. This would definitely cause at least some slowdown on the 32bit version since there aren't enough registers to begin with. I'm not sure if it causes any noticeable slowdown on the 64bit version, since the amd64 architecture has a lot more available registers, which would correlate with the person mentioning earlier that the 64bit version seemed fast.
"If you really want performance, run FreeDOS. Otherwise, shut up and get used to progress."
Jeez you're an idiot. I wouldn't have posted that under a registered nick either.
So people should just settle for bloat simply because of the advance of technology? Apple manages to make OS X faster than older versions. Other Linux distros do. Bad software isn't "progress".
I currently have three Ubuntu-based systems. I have customized the GNU/Linux distribution for each system. Anyone can do it.
One of the computers is an old (1998) Thinkpad notebook that doesn't have the video capability to run the full Ubuntu-Gnome GUI well. I do a minimal installation (the minimal CD is an official distribution of Ubuntu), then install about 25 select packages using a script that I call "Thinbuntu". This gives me a very functional GNU/Linux desktop for the old Thinkpad with the Long Term Support of the Ubuntu package system, including updates. It has all the features I need.
Apart from XP Embedded, where you can choose which parts of the OS are installed. It's not designed for home-use, but I've used it to make a 140MB version of XP that is blazingly fast. It can play media, has internet access, games, everything I need.
Not even talking about the advantage of being free:
- for optimization, I can select the window manager - for optimization, I can select the desktop environment - I get full compatibility with the open-source ecosystem - I can install programs from the huge apt-get application universe (including programming languages and tools) - I run it all from a very short script, unattended - it is fully supported, with automatic updates and no nonsense
Well, whatever it is, it shows why tests like this are important. Because the perceived slowdown is what users see and is what they will complain about. Sure, it's got more features and is still a lot faster than Vista, but you've got to be really careful not to cross the line into bloated and slow without realizing it.
Why do you think this? I mean do you have a good reason or is it just because you don't like mono? Take a look at some of the tests. "Computational: The Dhrystone 2 performance within the BYTE Unix Benchmark was also the fastest on Ubuntu 7.04. There was approximately a 20% drop in performance between 7.04 and 7.10 that remained consistent even in the 8.04 and 8.10 releases. " This is NOT in mono. "Database: In our SQLite test of measuring the time to perform 2,500 SQL inserts, the performance hadn't dropped off after Ubuntu 7.04 but instead after 8.04 LTS. In this performance drop it was over 2.5x slower. " SQLlite isn't written in mono. "but in our compilation benchmarks we spotted major performance losses following the Feisty Fawn release. It was noticeably slower to compile Apache, PHP, and ImageMagick in the 7.10, 8.04, and 8.10 releases." GCC isn't written in mono. I could go on and on but many of the benchmarks have nothing to do with mono at all. Heck I am not a big fan of mono but your statment is baseless.
In this case, anyways. The benchmarks had everything to do with X, GCC and Kernel performance numbers, which all slid over the intervals measured.
In other words, Ubuntus' not getting slower. The software that Ubuntu bundles is getting slower.
It's likely due to GCC's epic failure to better optimize code as 4.x progresses, but I'm not putting my money on anything until they've tested at least one other distro which builds with a different GCC version.
Why should I read this FA if the author apparently didn't finish high school?
The anonymous submitter and CmdrTaco's grammar skills have little to do with performance in Ubuntu. RTFA; it makes a good point and I for one hope that this observation is accepted by the Ubuntu developer's and something is done about it.
I just read it and found it pretty devoid of information. It is one of those mindless performance reviews in as many pages as possible.
Where are any measurements that look at where performance was lost? Running just the distros does nothing to isolate what got slower. Trying different kernels and different X servers would at least show an attempt at understanding what's going on. Why didn't they compare at least one Ubuntu version with a similar Fedora version, let alone Kubuntu or xubuntu?
As I expected: If a site employs people who can't write and has no editorial control that would weed out a glaring error like this you can't expect anything but quick and dirty superficial work. If an error like this that just jumps at you isn't caught, how many subtle errors in the data should I expect?
Why should I read this FA if the author apparently didn't finish high school?
Because intelligence and wisdom have nothing to do with "finishing high school"? I've got nothing past GCSE [wikipedia.org]s. Luckily for me, employers in the UK see past that.
Complete bullshit article, doesn't offer any useful information beyond a completely obvious conclusion -- the more features that are added to a given piece of software, the higher the demands on your PC.
I would think that those increased demands should be mostly in the form of slightly (a few MB) higher memory requirements to store the extra code for those features. Adding new functionality should not impact existing functionality. Haven't you heard of the zero-cost principle (idea from C++ and apparently Perl, "you don't pay for (as in take a performance hit from) what you don't use")?
It's not quite that simple. Performance in Java and media encoding was almost halved in the two newest versus the older versions of the OS. It's hard to imagine why that would be the case unless "more features" in Heron and Ibex are using up half the CPU time (and based on the other benchmarks, they ain't). I'd suspect test methodology rather than some oddity of OS performance but it's still something that needs to be addressed.
Xubuntu's performance targeting appears limited to choice of desktop environment, which was a small component of what these benchmarks tested. The big performance increases the article talks about were in databases, compilers, encryption, memory access, and audio/video encoding/decoding, none of which really have much to do with the desktop environment.
"Ubuntu" -- an African word, meaning "I'm sick of fucking with Linux in order to get it to do what I want but I really don't like the alternatives."
Yeah, I rocked Gentoo for a couple of years. I just want something that is fast, easy to use and gives me as little of a headache as possible. Linux is Linux and most of the knowledge learned in one distro will carry-over to another.
Mod the parent up, I'm in the exact same boat. Ran Gentoo for three years, loved it, but realized that I was spending a lot more time tinkering with the OS than actually USING the OS. That's perfectly fine for a server of some variety where really the tinkering IS the interaction, but for a desktop or something you're going to use more interactively on a daily basis it became too much of a pain.
Ubuntu gives me some of the strengths I liked (such as a simple, straightforward package manager, wide amount of customization without too much screwing around) without too many of the weaknesses (compiling all software, praying emerging the world doesn't break my desktop, so on and so forth).
It's not a bad distro at all and it's tiring to hear of people slamming it for not being Slackware or Gentoo. This may come as a revelation, but Linux is about choice.
Turning point for me was realizing that I was compiling more and more in, just in case I needed it, because rebuilding world just to enable that new USE flag was getting kind of old.
In other words, I was using it like Ubuntu. The only advantage I had was I would compile for -march=i686, and other optimizations which produce binaries which only work on recent CPUs (the '686' class) -- whereas Ubuntu was -mtune=i686, if I remember, so it was possible to run on a 486, but would run best on a 686.
And, hey, there were other things I would turn on that were Athlon XP specific, and so on... then I realized that, on amd64, the optimizations were basically exactly the same -- merely compiling for x86_64 gave me all the benefits anyway. At which point, what the hell -- Ubuntu would necessarily be at least as optimized as my Gentoo.
And, more recently, I've realized that since switching to Ubuntu, I spend much more time actually using the OS, rather than tweaking it. Despite having it already much more customized than any version of Windows ever was, I still don't spend as much time tweaking it as it takes to maintain Windows, let alone Gentoo.
What hardware? (Score:5, Insightful)
Were they testing each distribution on exactly the same hardware?
If so, that sounds completely fair to me that it would be slower. Go and (try to) install Vista on a machine that originally came with XP (pre-SP1) and see how much slower it is. Is that a fair test either? I think not.
As software gets more useful (and Ubuntu has, Vista not so much) it gets bigger and thus gets slower on the same hardware. Hardware advances at the same time though, so in real terms they keep about equal. When you test new software on old hardware of course it's going to be slower though.
Re:What hardware? (Score:5, Insightful)
Parent
Re:What hardware? (Score:5, Informative)
When you test new software on old hardware of course it's going to be slower though.
That's hardly a given, lots of software gets better as it ages - new features are added, but also performance tweaks get added.
The problem is that software should be getting quicker on the same hardware, the alternative is bloaty apps that no-one wants to use. See Vista for the ultimate conclusion to that. You don;t want Ubuntu to end up the same, so its good that someone is pointing out performance issues. Hopefully the next release will have a few of these issues looked at and improved.
Parent
Re:What hardware? (Score:5, Insightful)
I heard this argument a wee too often. Maybe software should be more useful while at the same time NOT getting slower? Maybe that would be a good thing, as it would then run well on netbooks as well, what do you think?
Parent
Re:What hardware? (Score:5, Insightful)
You make it sound like it is inevitable and acceptable that newer software is slower than older software. I disagree. For one thing, one way to improve software is to make it faster. This is actually done sometimes. Secondly, even if you add features to software (which is another way to improve software), that doesn't have to make the software slower. In some cases, this may be inevitable, but in many cases it is not.
I personally see computers, and software, as tools for making life more efficient. When software becomes slower, efficiency is actually lost. When this isn't offset by providing me with a more efficient work flow, I lose efficiency. Since efficiency is the main reason I use computers in the first place, this is a big deal.
Parent
Re:What hardware? (Score:5, Funny)
(Hey, he used an absolute, I'm entitled to extrapolate it to its logical implications.)
Parent
Security Patching? (Score:5, Informative)
Re:Security Patching? (Score:5, Interesting)
Good follow up would be to figure out specifically where - is it due to kernel changes? Then the problem may not be Ubuntu...
Parent
Re:Security Patching? (Score:5, Interesting)
I would like to see if this is an Ubuntu issue or Linux in general.
What about Fedora, OpenSuse, and Debian? How do they compare to Ubuntu?
Parent
Look carefully at the power management (Score:5, Interesting)
If you look closely you'll notice that (a) the benchmarks were run on a Thinkpad T60 laptop, and (b) there were significant differences on some benchmarks like RAM bandwidth that should have little or no OS components.
This sounds to me like the power management was dialing down the CPU on the later releases...
Re:Look carefully at the power management (Score:5, Interesting)
Mod parent up.
Many of the benchmarks (such as the lame, Java and RAM bandwidth benchmarks) are CPU-bound, and will run the majority of time in userspace. As the kernel should only be invoked for timer ticks, interrupts, TLB misses, etc (which would probably account for less than 1% of the CPU time), and change to the kernel should have minimal impact on the benchmarks.
The parent's comment that power settings have been misconfigured sounds spot-on.
Parent
I'm not convinced they know what they're doing (Score:5, Interesting)
Some of the benchmarks were hardware testing, and those showed variation. They should not, unless the compiler changed the algorithms used to compile the code between distros.
Benchmarking a multi-tasking system like Linux is a tough thing to quantify. The Linux kernel recently had a big scheduler change, this alone could account for shifting benhmark numbers. It may not actually "slowing down," but running multiple programs more evenly. The effective work is the same or better, which would mean "faster," but an almost useless benchmark would look slower.
Performance Problems AREN'T Where You Think... (Score:5, Interesting)
... they are.
Seriously.
I can see several problems with the testing methodology as is:
* The test suite itself: The Phoronix test suite runs on PHP. That in itself is a problem-- the slowdowns measured could most likely be *because* of differences in the distributed PHP runtimes. You can't just say "hey, version Y of distro X is slower than version Z! LOLZ" because, WTF. You're pretty much also running different versions of the *test suite* itself (since you have to consider the runtime as part of the test suite). Unless you remove that dependency, then sorry, you can't measure things reliably. Which brings me to my second point...
* What exactly are they testing? The whole distro? The compiler (since most of the whole of each distro version is compiled with different versions of GCC)? The kernel? If they're testing the released kernel, then they should run static binaries that *test* the above, comparing kernel differences. If they're testing the compiler, then they should build the *same* compiled code on each version and run said compiled code (which is pretty much what I gather they're doing). If they're testing the utilities and apps that came with the distro, then they should have shell scripts and other tools (which run on a single runtime, not depending on the runtime(s) that came with the distro version). Because if you don't, you have no fucking clue what you're testing.
Honestly, I was unimpressed by the benchmarks. I happen to do performance benchmarking as part of my job, and I can tell you, you have to eliminate all the variables first -- isolate things to be able to say "X is slow". If you rely on a PHP runtime, use *exactly* the same PHP runtime for all your testing; otherwise, you'll get misleading results.
Re:Performance Problems AREN'T Where You Think... (Score:5, Informative)
Variable elimination has been done, to varying extent, by multiple people here:
https://bugs.launchpad.net/bugs/131094 [launchpad.net]
Parent
GTK performance stats? (Score:5, Insightful)
The GTK+ statistics are mind-boggling slow. That's what I notice most when I use Ubuntu or Fedora. On my non-Ubuntu laptop, I get the following results for GTK performance:
GtkDrawingArea - Pixbufs: 3.73s (on mine) vs 43-55s (Ubuntu)
GtkRadioButton: 13s vs 29-60s
I just think that's ridiculous. What did they do to GTK+ to make it so slow?
Xorg, mainly. (Score:4, Informative)
Meanwhile, 2D performance on Intel's hardware is smoking everyone else's pipe.
Parent
Ghostview/Postscript? (Score:4, Interesting)
I hadn't noticed any general slowness when I upgraded from Feisty to Hardy (if anything, it was slightly faster), but I have noticed that when I run a document (even a short one) through groff, the resulting postscript file takes a lot longer to refresh in gv and evince. Alas, lots of googling revealed no similar situations, so it may just be something idiosyncratic with my set up.
Is PIE the primary cause? (Score:5, Interesting)
I believe that PIE (position independent executable) along with some other security enhancements were turned on in Ubuntu around the time the slowndowns showed up. This would definitely cause at least some slowdown on the 32bit version since there aren't enough registers to begin with. I'm not sure if it causes any noticeable slowdown on the 64bit version, since the amd64 architecture has a lot more available registers, which would correlate with the person mentioning earlier that the 64bit version seemed fast.
Re:Performance isn't its raison detre (Score:5, Interesting)
Let's see how that statement works in this situation:
It shouldn't be getting slower, but then again, performance isn't the reason Vista exists.
If you really want performance, run FreeDOS. Otherwise, shut up and get used to progress.
Parent
No wonder you posted AC (Score:4, Insightful)
"If you really want performance, run FreeDOS. Otherwise, shut up and get used to progress."
Jeez you're an idiot. I wouldn't have posted that under a registered nick either.
So people should just settle for bloat simply because of the advance of technology? Apple manages to make OS X faster than older versions. Other Linux distros do. Bad software isn't "progress".
Parent
Re:Performance isn't its raison detre (Score:5, Funny)
See, there's this thing called an analogy. It's kinda like a car...
Parent
Re:Cars! (Score:5, Funny)
Analogies are like matchbox cars full of chocolates... you never know how much spillover chinese paint you're going to get.
Parent
Re:Performance isn't its raison detre (Score:5, Funny)
An analogy is a simile, metaphorically speaking.
Parent
Re:Performance isn't its raison detre (Score:5, Funny)
I think that's a rhetorical tautology.
Parent
Re:Performance isn't its raison detre (Score:5, Insightful)
It's nice to see that the Ubuntu fanboys have moved so quickly to 'shut up and like it'.
It took Windows fanboys a decade to get there...
Parent
Flexibility and freedom are its raison d'Ãtre (Score:5, Insightful)
I currently have three Ubuntu-based systems. I have customized the GNU/Linux distribution for each system. Anyone can do it.
One of the computers is an old (1998) Thinkpad notebook that doesn't have the video capability to run the full Ubuntu-Gnome GUI well. I do a minimal installation (the minimal CD is an official distribution of Ubuntu), then install about 25 select packages using a script that I call "Thinbuntu". This gives me a very functional GNU/Linux desktop for the old Thinkpad with the Long Term Support of the Ubuntu package system, including updates. It has all the features I need.
Microsoft simply can't compete with this.
Parent
Re:Flexibility and freedom are its raison d'Ã (Score:5, Interesting)
Parent
Re:Flexibility and freedom are its raison d'Ã (Score:5, Funny)
Parent
Re:Flexibility and freedom are its raison d'Ã (Score:5, Insightful)
Not even talking about the advantage of being free:
- for optimization, I can select the window manager
- for optimization, I can select the desktop environment
- I get full compatibility with the open-source ecosystem
- I can install programs from the huge apt-get application universe (including programming languages and tools)
- I run it all from a very short script, unattended
- it is fully supported, with automatic updates and no nonsense
Parent
Re:Performance isn't its raison detre (Score:5, Funny)
So the soul-removal procedure went well, I see.
Parent
Re:Performance isn't its raison detre (Score:5, Funny)
FYI, actually having sex is usually more fun than declining it.
Parent
Re:Performance isn't its raison detre (Score:5, Insightful)
Parent
Re:Performance isn't its raison detre (Score:5, Interesting)
Parent
Re:Performance isn't its raison detre (Score:5, Insightful)
Why do you think this? I mean do you have a good reason or is it just because you don't like mono?
Take a look at some of the tests.
"Computational: The Dhrystone 2 performance within the BYTE Unix Benchmark was also the fastest on Ubuntu 7.04. There was approximately a 20% drop in performance between 7.04 and 7.10 that remained consistent even in the 8.04 and 8.10 releases. "
This is NOT in mono.
"Database: In our SQLite test of measuring the time to perform 2,500 SQL inserts, the performance hadn't dropped off after Ubuntu 7.04 but instead after 8.04 LTS. In this performance drop it was over 2.5x slower. "
SQLlite isn't written in mono.
"but in our compilation benchmarks we spotted major performance losses following the Feisty Fawn release. It was noticeably slower to compile Apache, PHP, and ImageMagick in the 7.10, 8.04, and 8.10 releases."
GCC isn't written in mono.
I could go on and on but many of the benchmarks have nothing to do with mono at all.
Heck I am not a big fan of mono but your statment is baseless.
Parent
You're completely wrong (Score:5, Insightful)
In other words, Ubuntus' not getting slower. The software that Ubuntu bundles is getting slower.
It's likely due to GCC's epic failure to better optimize code as 4.x progresses, but I'm not putting my money on anything until they've tested at least one other distro which builds with a different GCC version.
Parent
Re:You're completely wrong (Score:5, Informative)
In other words, Ubuntus' not getting slower. The software that Ubuntu bundles is getting slower.
Ubuntu is the software that it bundles.
Parent
Re:Had went on? (Score:4, Funny)
He would have been able to finish, had Ubuntu not been so slow that he was never able to finish his papers and turn them in on time.
Parent
Re:Had went on? (Score:5, Insightful)
Why should I read this FA if the author apparently didn't finish high school?
The anonymous submitter and CmdrTaco's grammar skills have little to do with performance in Ubuntu. RTFA; it makes a good point and I for one hope that this observation is accepted by the Ubuntu developer's and something is done about it.
Parent
Re:Had went on? (Score:5, Insightful)
I just read it and found it pretty devoid of information. It is one of those mindless performance reviews in as many pages as possible.
Where are any measurements that look at where performance was lost? Running just the distros does nothing to isolate what got slower. Trying different kernels and different X servers would at least show an attempt at understanding what's going on. Why didn't they compare at least one Ubuntu version with a similar Fedora version, let alone Kubuntu or xubuntu?
As I expected: If a site employs people who can't write and has no editorial control that would weed out a glaring error like this you can't expect anything but quick and dirty superficial work. If an error like this that just jumps at you isn't caught, how many subtle errors in the data should I expect?
Parent
Re:Had went on? (Score:5, Insightful)
Why should I read this FA if the author apparently didn't finish high school?
Because intelligence and wisdom have nothing to do with "finishing high school"? I've got nothing past GCSE [wikipedia.org]s. Luckily for me, employers in the UK see past that.
Parent
Re:"That's quick" (Score:5, Funny)
How many geeks have heard such phrases: " "That's quick" was the phrase my girlfriend after..."
Alas.
Parent
Re:Ubuntu isn't getting slower, no. (Score:5, Insightful)
Complete bullshit article, doesn't offer any useful information beyond a completely obvious conclusion -- the more features that are added to a given piece of software, the higher the demands on your PC.
I would think that those increased demands should be mostly in the form of slightly (a few MB) higher memory requirements to store the extra code for those features. Adding new functionality should not impact existing functionality. Haven't you heard of the zero-cost principle (idea from C++ and apparently Perl, "you don't pay for (as in take a performance hit from) what you don't use")?
Parent
Re:Ubuntu isn't getting slower, no. (Score:5, Interesting)
Parent
Re:Ubuntu isn't getting slower, no. (Score:5, Insightful)
They ran the tests on a modern laptop, and noticed a perceived slowdown. It would be idiotic to ignore that just because new features were added.
Parent
Re:xubuntu (Score:5, Informative)
Xubuntu's performance targeting appears limited to choice of desktop environment, which was a small component of what these benchmarks tested. The big performance increases the article talks about were in databases, compilers, encryption, memory access, and audio/video encoding/decoding, none of which really have much to do with the desktop environment.
Parent
Re:Ubuntu? No way. (Score:5, Insightful)
"Ubuntu" -- an African word, meaning "I'm sick of fucking with Linux in order to get it to do what I want but I really don't like the alternatives."
Yeah, I rocked Gentoo for a couple of years. I just want something that is fast, easy to use and gives me as little of a headache as possible. Linux is Linux and most of the knowledge learned in one distro will carry-over to another.
Parent
Re:Ubuntu? No way. (Score:5, Insightful)
Ubuntu gives me some of the strengths I liked (such as a simple, straightforward package manager, wide amount of customization without too much screwing around) without too many of the weaknesses (compiling all software, praying emerging the world doesn't break my desktop, so on and so forth).
It's not a bad distro at all and it's tiring to hear of people slamming it for not being Slackware or Gentoo. This may come as a revelation, but Linux is about choice.
Parent
Re:Ubuntu? No way. (Score:5, Insightful)
I was pretty much exactly the same.
Turning point for me was realizing that I was compiling more and more in, just in case I needed it, because rebuilding world just to enable that new USE flag was getting kind of old.
In other words, I was using it like Ubuntu. The only advantage I had was I would compile for -march=i686, and other optimizations which produce binaries which only work on recent CPUs (the '686' class) -- whereas Ubuntu was -mtune=i686, if I remember, so it was possible to run on a 486, but would run best on a 686.
And, hey, there were other things I would turn on that were Athlon XP specific, and so on... then I realized that, on amd64, the optimizations were basically exactly the same -- merely compiling for x86_64 gave me all the benefits anyway. At which point, what the hell -- Ubuntu would necessarily be at least as optimized as my Gentoo.
And, more recently, I've realized that since switching to Ubuntu, I spend much more time actually using the OS, rather than tweaking it. Despite having it already much more customized than any version of Windows ever was, I still don't spend as much time tweaking it as it takes to maintain Windows, let alone Gentoo.
Parent
Re:Real men (Score:5, Funny)
Obligatory [xkcd.com].
Parent
Re:Real men (Score:4, Funny)
Parent