My understanding is that the high prison population in the US is one of the things that keeps the unemployment rate so low. I think it's a poor reason to continue with things as-is, but it's one of the reasons I've read as to why nothing's likely to change any time soon.
I wouldn't think so. Hymnn strips the file of all DRM; what Real had done was essentially finding a way to get the iPod to play *their* protected files, just like files you bought off iTMS. Apple has evidently changed up the way their authentication behaves so this no longer works.
Since there's no DRM in a file that's been run through Hymn, there's no reason they shouldn't still work.
But this has been said a thousand times, and the only one who is listening is Xandros.
Sorry, but this is absolutely untrue. Xandros is one of the nicer bundlings out there, but their particular brand of easy doesn't mean they're the only ones working toward it.
Really, your complaint sounds aimed more at the component software than the actual distros, and great progress has been made in that realm in the past year. The Freedesktop.org initiative has done more for Linux usability in roughly a year's time than I've seen in the 6 or so years I've been using it. The new HAL stuff is still a little quirky, but for the most part runs beautifully. The whole aim is to have a consistent set of tools and behaviors across all distros, no matter how the config files are stored or the filesystem mounted.
The work *is* being done and it *is* making great progress. I know from personal experience that both Dropline Gnome on Slackware and Ubuntu Linux ship with HAL support enabled (though it's more polished in Ubuntu right now as Todd recently abandoned Dropline and the project is in a transition to community development). I believe I've also read that FC3 has HAL turned on by default.
This makes a bigger difference in usability than any amount of packaging I'd expect the Xandros people to be (reasonably) capable of, and should provide a relatively similar experience across various distros.
I keep a similar collection for my own internal use, but I really like the OpenCD for another reason - it gives me a nice collection of free apps with a nice frontend that I can give to customers and let them explore it on their own.
With some people, a nice, polished presentation is almost as important as a nice, polished product.
If the Gimp were anything close to Photoshop, I'd gladly use it. As it stands now, though, I feel there's a reason it gets written off as a toy in comparison - because it is. The reason you get that type of backlash though is because so many in the Slashdot community are convinced that it's a perfect replacement for Photoshop *now*, when it's nothing of the sort.
It's a good graphics editing program, and completely suitable for web graphics. But for photos or anything I'd actually want to print, it comes nowhere close to Photoshop right now, and it gets tiresome being told that it's the OSS "Photoshop killer".
Absolutely. The best example of this is to compare the histograms of the same image after it's been edited in 8 bit and 16 bit modes. The 8 bit histogram will generally show clipping all over the place, the 16 bit one will generally be relatively smooth in comparison.
My personal beef with the GIMP's interface has more to do with the UI for accessing the various tools. I'm completely indifferent as far as MDI vs SDI goes, though I would like an option to have the Gimp create a single "taskbar" item instead of one for each toolbox window, which is a pain for someone like me that usually has many apps open while I'm working with an image. The right-click-for-everything style interface is rather annoying compared to Photoshop where everything I need is within a click or two away.
Photoshop isn't the most intuitive interface in the world, but it's the best at what it does that I've come across. You mention the GIMP being more like Photoshop on Mac than Photoshop on Windows. Maybe in the window-management sense, but as far as actual workflow goes, the Photoshop interface is identical between Windows and Mac - right down to the keyboard shortcuts (replacing Alt/Option with Ctrl/Alt anyway:-)).
Because not all of Intel's fabs are equipped to produce chips at 90nm and the ones that are would be far more profitable if used to produce top of the line chips?
It'll be a sad day when and if film finally disappears from film schools.
As much as I wanted to, I couldn't afford film school myself. That said, when I was visiting friends at SCAD during the SCAD Film Festival about a month ago, the impression I got was that students are taught to cut and work with film, but pretty much any work they actually do is all digital at this point.
So rewarding open ended contracts, often leading to billions of dollars wasted on dead end projects is being more careful with your money than making companies produce results *BEFORE* they're paid?
The file browser does have problems, yes. As far as needing a location bar, tried pressing Ctrl-L? You *do* have that option.
The stutter in the run command is definitely a problem. No disagreement there.
I've never had particular issue with FF on any of my machines (including a P3 1GHz notebook), but it wouldn't surprise me if Konqueror seems faster as KDE precaches it on boot, the same trick IE has used for years. Personally, I'm not sure if I'd support hacking a similar feature into Gnome for Firefox/Epiphany/Galeon/whatever. So this is one that could go either way, really.
By base menu item, do you me the defaults in the Gnome menu? Generally program categories, etc, depending on your distro. Again, I'll agree with you there that it's annoying that there's no easy way to modify that. They did at least open up adding your own launchers for the individual categories.
The only menu I know of for configuring CD insert behaviour is Removable Storage. Could you elaborate? If it really is that bad, have you considered filing a bug report? The HAL stuff is very much in its infancy, so I'm sure there are still some major kinks in its behaviour.
Agreed on the Nautilus quirk, that one's always made me stratch my head as well. Same goes for the OSS/ALSA thing.
I'm not one to claim that Gnome isn't without its severe quirks here and there, but at the same time, I've found that it's the OSS DE closest to what I look for in a work environment. I used KDE almost exclusively until around 3.0 before giving Gnome 2.x a serious try.
Going back now, KDE feels cluttered and overwhelming compared to the simplicity of Gnome. This is the reason why I'll continue to use it as long as it continues to get better. The improvement it's seen in each release since 2.0 has been marked, and I'm sure that trend will only continue with future releases.
No, OpenGL isn't exclusively 3D, but the parts of it being used by Apple are.
Also, Quartz Extreme is most definitely using 3D hardware acceleration. Regular "old" Quartz used before 10.2 was purely 2D based, but Quartz Extreme leverages your 3D accelerator to render the desktop on screen - acting like "Everything is a textured polygon."
The problem is, 2D compositing is in the process of shifting to being 3D accelerated right now. OS X has been for a couple of years now, Longhorn will be, and X.org is in the process of doing so.
You end up with much smoother window rendering, and it allows you to add in things like desktop transparency and shadowing without much of a performance hit. A 2D only card may be "good enough" for some, but the desktop environments are quickly moving in a direction where that may no longer be the case by time this card would come to market. Going for at least rudimentary OpenGL support from the start would be a good idea.
Aren't companies allowed to make calls already if they have a "pre-established business relationship" with you? Has this changed or is the summary missing something?
I can't comment on the interior portions beyond the fact that the interior of the 1968 Corvair we own is no different from that of any other car from the vintage, so that wouldn't be the reason for singling out the Corvair.
The reason was Nader specifically cited for the Corvair's 'unsafeness' was the Corvair's unique swing style rear suspension. Nader claimed that it allowed the rear tires to fold under, causing rollover, which, as the NHTSA showed, was untrue. You assertation that the car was difficult to handle in comparison to contemporaries is also incorrect.
The Corvair tended toward oversteer in hard cornering, as opposed to the severe understeer of most of the boat-like American cars of the day. It's much easier to recover from a loss of control with a car that leans toward oversteer. In fact, the Corvair in the hands of a skilled driver handles comparably to many *modern* sports cars. There's a reason why the Corvair has a strong enthusiast community around it to this day in the amateur racing circuit. But maybe Nader was right and they're mistaken and the Corvair really *is* a horribly handling vehicle prone to rollovers under normal conditions. They wouldn't care about things like that, after all.
We're talking about a car that sported a fully independent suspension when that was something found only on the Corvette. If you do some research, you'll find that the Corvair's suspension borrowed heavily from the Vette's engineering.
So no, the Corvair wasn't perfect by any means, but the reality of how the car performed and Nader's version of the story are completely different things. A car that was in many ways superior to other cars of the time unfairly picked up the reputation of a deathtrap, when it wasn't the case at all. This is why I'm irked. I'm absolutely thrilled we have safer cars today, but it annoys me that one of the better cars being made at the time was essentially crucified over something that just plain wasn't true.
Too bad the S2000 is notorious for blowing clutches when driven agressively, it's a great car otherwise, but I don't know if I'd have one myself for this reason. Something just scares me when I've read of magazine test cars losing the clutch during testing.
There was never a major problem with the Corvair. Yes, the suspension did look funny when on a lift, and yes, Chevrolet did eventually redesign it to make it somewhat more stable (and better handling), but it was *NOT* the death trap Ralph Nader claimed it to be. In fact, the NHTSA performed a study in 1971 to test Nader's claims and found that the Corvair performed as well as any of contemporaries (better in fact than some imports like the VW) and did *not* have a rollover of the Corvair occur in any of their tests.
It irks me that Nader's career was kick started on a complete distortion of reality, and that he's never really been called out on it since then.
You know, it's interesting that you mention HL2, because I was about to bring up the Source engine as a suggestion for this. While I feel there are better looking engines out there already (Far Cry) in terms of raw visuals, as far as the character animation goes, nothing touches it right now. The facial animations are based on modeling the muscles of the face, making for an incredibly life-like result in comparison to other systems that are out there at the moment.
The other interesting thing is that in the 2003 E3 demo, Valve demonstrated that the models would lip sync with audio in a fairly convincing manner - even in other languages. I can't speak for how easy/automatic this is, but we should know soon as Valve announced today that the full SDK would be available next week. Other little details like specular highlights on a characters eyes giving them that gleam of life really add to the overall effect.
I think it'd probably take a little more work, but HL2 seems very well suited to this type of work. It may not be the absolute best a everything, but least as far as the character animation goes, I don't think anything else can really compare right now.
Absolutely. A book I highly recommend any programmer read is User Interface Design for Programmers. It's only about 150 pages in length, well illustrated, and easy to understand.
One thing the author (Joel Spolsky of Joel on Software recommends is conducting "hallway usability tests." Basically, as you work on a program, pull a non-geek to the side, and have them try to use the software while watching how they try to accomplish a given task. This can be done in 5 minutes, is practically free, and (depending on the project) you can use almost anyone - the office receptionist, a visiting friend, it doesn't matter. This is a great way to spot usability problems early on when they're still easy to fix.
Anyway, excellent book, it's centered around concepts like this with simple mantra to keep in mind. IE: Users don't read, Users are impatient, etc. It really makes to step back and take a look at how an every day person is going to attempt to use a computer, and I feel you'll be a better coder for it.
Let me just throw in a disclaimer here that I have nothing to do with the book or the author, I was just incredibly impressed with a book I picked up essentially as an impulse buy. It's earned its place as one of my favorite books in my programming library, and was worth every penny I spent on it.
It's possible, but from what I've read (and I can't find the link for the life of me, at the moment), dual core Opterons only take a relatively slight performance hit in comparison to true SMP Opteron with dedicated memory controllers for each chip.
Keep in mind that Athlons are nowhere near as sensitive to memory bandwidth as the P4 is. They don't need as fast a FSB to keep the pipeline full and single vs dual channel memory has less of an effect on performance. Again, much of this is due to Prescott's 31-stage pipeline compared to the 12-stage integer/17-stage floating point pipeline of the K8.
Both Intel and AMD have talked about eventually bringing out shared cache-coherent dual core chips that would help in this regard, but both are going to use split caches initially. This could end up being a major problem for Intel, if anyone, as we're now talking about having to keep *two* 31 stage pipelines fed.
So again, I'd imagine there would be at least some performance gain if AMD were to implememnt SMT into their chips, but I have to believe that the gains they would see would be rather minimal in comparison to the amount of effort involved in adding it to the chips. The P4's performance improves about 15% in most apps with HT enabled - (some do better, obviously, but others, like games, see no benefit at all). Given that Netburst suits itself to SMT much more so than the K8, I'd imagine that you'd see smaller returns on the effort with an SMT K8 and that the R&D time and money would be better spent elsewhere.
There are pictures floating around comparing 130nm single core Opterons to 90nm dual core Opterons. A dual core die produced on the smaller process is about the same size as a 130nm single core die, meaning they should cost about the same amount of money to produce, per chip.
Oh no doubt, I didn't mean to imply that SMT isn't without its advantages. Rather, I was pointing out that AMD is in no rush to implement it in their chips, and for good reason: relative to the P4, it would have a much smaller impact on performance, and they can make larger gains by focusing elsewhere. The deep pipeline design of the P4 is why spending the time implementing SMT on that chip made sense.
Since you mention IBM as "everyone else," it's worth noting that IBM's POWER line of CPUs are not only multicore, but SMT as well. It helps, but AMD lacking SMT right now really isn't a big deal right now, especially with multicore K8s coming in the next 6 months or so.
I'd just like to add on to this that the reason the Athlons and P-M's don't need Hyperthreading is that HT is essentially a latency hiding method to make up for the obscenely long Netburst pipeline. Basically, keeping the 30-stage pipeline full is difficult with a single thread, so allowing the processor to address multiple threads at the same time helps keep the pipeline full. I'd suggest reading Hannibal's excellent articles at Ars Technica if you wish to learn more on the subject.
Essentially, I've always felt that HT is more of a marketing gimmick than it is some new revolution in computing. While it might help performance some, AMD's upcoming dual core chips will do far more to help performance as it actually *is* a multiprocessor system rather than faking it like HT. Remember, K8 was designed with multicore in mind from the start, with Netburst, it's been hacked in.
I spent several hours last night fighting with an IMAP server package on NLD (which is SuSe, and therefore RPM, based). In order to install the package, I first needed to install an authentication library, no big deal, I can build an RPM from source, right?
Well, here's the catch, some of the dependencies defined in the spec file distributed with the source looked for dependencies with RedHat names. I already had the freaking packages installed, but the package name registered in the RPM database was *ONE* character different, and the dependency check would fail as a result. So I got to spend time hacking away at spec files til the blasted thing finally gave in.
It's things like this that make me believe that the sooner we can move to a standardized base, the better off we'll be. Linux lags so far behind Windows, let alone OS X and its drag and drop installs, in this regard that it's not even funny.
Slashdot Mirror
My understanding is that the high prison population in the US is one of the things that keeps the unemployment rate so low. I think it's a poor reason to continue with things as-is, but it's one of the reasons I've read as to why nothing's likely to change any time soon.
I wouldn't think so. Hymnn strips the file of all DRM; what Real had done was essentially finding a way to get the iPod to play *their* protected files, just like files you bought off iTMS. Apple has evidently changed up the way their authentication behaves so this no longer works.
Since there's no DRM in a file that's been run through Hymn, there's no reason they shouldn't still work.
Sorry, but this is absolutely untrue. Xandros is one of the nicer bundlings out there, but their particular brand of easy doesn't mean they're the only ones working toward it.
Really, your complaint sounds aimed more at the component software than the actual distros, and great progress has been made in that realm in the past year. The Freedesktop.org initiative has done more for Linux usability in roughly a year's time than I've seen in the 6 or so years I've been using it. The new HAL stuff is still a little quirky, but for the most part runs beautifully. The whole aim is to have a consistent set of tools and behaviors across all distros, no matter how the config files are stored or the filesystem mounted.
The work *is* being done and it *is* making great progress. I know from personal experience that both Dropline Gnome on Slackware and Ubuntu Linux ship with HAL support enabled (though it's more polished in Ubuntu right now as Todd recently abandoned Dropline and the project is in a transition to community development). I believe I've also read that FC3 has HAL turned on by default.
This makes a bigger difference in usability than any amount of packaging I'd expect the Xandros people to be (reasonably) capable of, and should provide a relatively similar experience across various distros.
I keep a similar collection for my own internal use, but I really like the OpenCD for another reason - it gives me a nice collection of free apps with a nice frontend that I can give to customers and let them explore it on their own.
With some people, a nice, polished presentation is almost as important as a nice, polished product.
If the Gimp were anything close to Photoshop, I'd gladly use it. As it stands now, though, I feel there's a reason it gets written off as a toy in comparison - because it is. The reason you get that type of backlash though is because so many in the Slashdot community are convinced that it's a perfect replacement for Photoshop *now*, when it's nothing of the sort.
It's a good graphics editing program, and completely suitable for web graphics. But for photos or anything I'd actually want to print, it comes nowhere close to Photoshop right now, and it gets tiresome being told that it's the OSS "Photoshop killer".
Absolutely. The best example of this is to compare the histograms of the same image after it's been edited in 8 bit and 16 bit modes. The 8 bit histogram will generally show clipping all over the place, the 16 bit one will generally be relatively smooth in comparison.
My personal beef with the GIMP's interface has more to do with the UI for accessing the various tools. I'm completely indifferent as far as MDI vs SDI goes, though I would like an option to have the Gimp create a single "taskbar" item instead of one for each toolbox window, which is a pain for someone like me that usually has many apps open while I'm working with an image. The right-click-for-everything style interface is rather annoying compared to Photoshop where everything I need is within a click or two away.
:-)).
Photoshop isn't the most intuitive interface in the world, but it's the best at what it does that I've come across. You mention the GIMP being more like Photoshop on Mac than Photoshop on Windows. Maybe in the window-management sense, but as far as actual workflow goes, the Photoshop interface is identical between Windows and Mac - right down to the keyboard shortcuts (replacing Alt/Option with Ctrl/Alt anyway
Because not all of Intel's fabs are equipped to produce chips at 90nm and the ones that are would be far more profitable if used to produce top of the line chips?
As much as I wanted to, I couldn't afford film school myself. That said, when I was visiting friends at SCAD during the SCAD Film Festival about a month ago, the impression I got was that students are taught to cut and work with film, but pretty much any work they actually do is all digital at this point.
So rewarding open ended contracts, often leading to billions of dollars wasted on dead end projects is being more careful with your money than making companies produce results *BEFORE* they're paid?
That's an interesting take on this, IMO.
FTFA:
"The vaccine is made from a patient's own dendritic cells and HIV isolated from the patient's own blood."
The file browser does have problems, yes. As far as needing a location bar, tried pressing Ctrl-L? You *do* have that option.
The stutter in the run command is definitely a problem. No disagreement there.
I've never had particular issue with FF on any of my machines (including a P3 1GHz notebook), but it wouldn't surprise me if Konqueror seems faster as KDE precaches it on boot, the same trick IE has used for years. Personally, I'm not sure if I'd support hacking a similar feature into Gnome for Firefox/Epiphany/Galeon/whatever. So this is one that could go either way, really.
By base menu item, do you me the defaults in the Gnome menu? Generally program categories, etc, depending on your distro. Again, I'll agree with you there that it's annoying that there's no easy way to modify that. They did at least open up adding your own launchers for the individual categories.
The only menu I know of for configuring CD insert behaviour is Removable Storage. Could you elaborate? If it really is that bad, have you considered filing a bug report? The HAL stuff is very much in its infancy, so I'm sure there are still some major kinks in its behaviour.
Agreed on the Nautilus quirk, that one's always made me stratch my head as well. Same goes for the OSS/ALSA thing.
I'm not one to claim that Gnome isn't without its severe quirks here and there, but at the same time, I've found that it's the OSS DE closest to what I look for in a work environment. I used KDE almost exclusively until around 3.0 before giving Gnome 2.x a serious try.
Going back now, KDE feels cluttered and overwhelming compared to the simplicity of Gnome. This is the reason why I'll continue to use it as long as it continues to get better. The improvement it's seen in each release since 2.0 has been marked, and I'm sure that trend will only continue with future releases.
No, OpenGL isn't exclusively 3D, but the parts of it being used by Apple are.
Also, Quartz Extreme is most definitely using 3D hardware acceleration. Regular "old" Quartz used before 10.2 was purely 2D based, but Quartz Extreme leverages your 3D accelerator to render the desktop on screen - acting like "Everything is a textured polygon."
The problem is, 2D compositing is in the process of shifting to being 3D accelerated right now. OS X has been for a couple of years now, Longhorn will be, and X.org is in the process of doing so.
You end up with much smoother window rendering, and it allows you to add in things like desktop transparency and shadowing without much of a performance hit. A 2D only card may be "good enough" for some, but the desktop environments are quickly moving in a direction where that may no longer be the case by time this card would come to market. Going for at least rudimentary OpenGL support from the start would be a good idea.
Aren't companies allowed to make calls already if they have a "pre-established business relationship" with you? Has this changed or is the summary missing something?
I can't comment on the interior portions beyond the fact that the interior of the 1968 Corvair we own is no different from that of any other car from the vintage, so that wouldn't be the reason for singling out the Corvair.
The reason was Nader specifically cited for the Corvair's 'unsafeness' was the Corvair's unique swing style rear suspension. Nader claimed that it allowed the rear tires to fold under, causing rollover, which, as the NHTSA showed, was untrue. You assertation that the car was difficult to handle in comparison to contemporaries is also incorrect.
The Corvair tended toward oversteer in hard cornering, as opposed to the severe understeer of most of the boat-like American cars of the day. It's much easier to recover from a loss of control with a car that leans toward oversteer. In fact, the Corvair in the hands of a skilled driver handles comparably to many *modern* sports cars. There's a reason why the Corvair has a strong enthusiast community around it to this day in the amateur racing circuit. But maybe Nader was right and they're mistaken and the Corvair really *is* a horribly handling vehicle prone to rollovers under normal conditions. They wouldn't care about things like that, after all.
We're talking about a car that sported a fully independent suspension when that was something found only on the Corvette. If you do some research, you'll find that the Corvair's suspension borrowed heavily from the Vette's engineering.
So no, the Corvair wasn't perfect by any means, but the reality of how the car performed and Nader's version of the story are completely different things. A car that was in many ways superior to other cars of the time unfairly picked up the reputation of a deathtrap, when it wasn't the case at all. This is why I'm irked. I'm absolutely thrilled we have safer cars today, but it annoys me that one of the better cars being made at the time was essentially crucified over something that just plain wasn't true.
Too bad the S2000 is notorious for blowing clutches when driven agressively, it's a great car otherwise, but I don't know if I'd have one myself for this reason. Something just scares me when I've read of magazine test cars losing the clutch during testing.
There was never a major problem with the Corvair. Yes, the suspension did look funny when on a lift, and yes, Chevrolet did eventually redesign it to make it somewhat more stable (and better handling), but it was *NOT* the death trap Ralph Nader claimed it to be. In fact, the NHTSA performed a study in 1971 to test Nader's claims and found that the Corvair performed as well as any of contemporaries (better in fact than some imports like the VW) and did *not* have a rollover of the Corvair occur in any of their tests.
It irks me that Nader's career was kick started on a complete distortion of reality, and that he's never really been called out on it since then.
You know, it's interesting that you mention HL2, because I was about to bring up the Source engine as a suggestion for this. While I feel there are better looking engines out there already (Far Cry) in terms of raw visuals, as far as the character animation goes, nothing touches it right now. The facial animations are based on modeling the muscles of the face, making for an incredibly life-like result in comparison to other systems that are out there at the moment.
The other interesting thing is that in the 2003 E3 demo, Valve demonstrated that the models would lip sync with audio in a fairly convincing manner - even in other languages. I can't speak for how easy/automatic this is, but we should know soon as Valve announced today that the full SDK would be available next week. Other little details like specular highlights on a characters eyes giving them that gleam of life really add to the overall effect.
I think it'd probably take a little more work, but HL2 seems very well suited to this type of work. It may not be the absolute best a everything, but least as far as the character animation goes, I don't think anything else can really compare right now.
Absolutely. A book I highly recommend any programmer read is User Interface Design for Programmers. It's only about 150 pages in length, well illustrated, and easy to understand.
One thing the author (Joel Spolsky of Joel on Software recommends is conducting "hallway usability tests." Basically, as you work on a program, pull a non-geek to the side, and have them try to use the software while watching how they try to accomplish a given task. This can be done in 5 minutes, is practically free, and (depending on the project) you can use almost anyone - the office receptionist, a visiting friend, it doesn't matter. This is a great way to spot usability problems early on when they're still easy to fix.
Anyway, excellent book, it's centered around concepts like this with simple mantra to keep in mind. IE: Users don't read, Users are impatient, etc. It really makes to step back and take a look at how an every day person is going to attempt to use a computer, and I feel you'll be a better coder for it.
Let me just throw in a disclaimer here that I have nothing to do with the book or the author, I was just incredibly impressed with a book I picked up essentially as an impulse buy. It's earned its place as one of my favorite books in my programming library, and was worth every penny I spent on it.
It's possible, but from what I've read (and I can't find the link for the life of me, at the moment), dual core Opterons only take a relatively slight performance hit in comparison to true SMP Opteron with dedicated memory controllers for each chip.
Keep in mind that Athlons are nowhere near as sensitive to memory bandwidth as the P4 is. They don't need as fast a FSB to keep the pipeline full and single vs dual channel memory has less of an effect on performance. Again, much of this is due to Prescott's 31-stage pipeline compared to the 12-stage integer/17-stage floating point pipeline of the K8.
Both Intel and AMD have talked about eventually bringing out shared cache-coherent dual core chips that would help in this regard, but both are going to use split caches initially. This could end up being a major problem for Intel, if anyone, as we're now talking about having to keep *two* 31 stage pipelines fed.
So again, I'd imagine there would be at least some performance gain if AMD were to implememnt SMT into their chips, but I have to believe that the gains they would see would be rather minimal in comparison to the amount of effort involved in adding it to the chips. The P4's performance improves about 15% in most apps with HT enabled - (some do better, obviously, but others, like games, see no benefit at all). Given that Netburst suits itself to SMT much more so than the K8, I'd imagine that you'd see smaller returns on the effort with an SMT K8 and that the R&D time and money would be better spent elsewhere.
There are pictures floating around comparing 130nm single core Opterons to 90nm dual core Opterons. A dual core die produced on the smaller process is about the same size as a 130nm single core die, meaning they should cost about the same amount of money to produce, per chip.
Oh no doubt, I didn't mean to imply that SMT isn't without its advantages. Rather, I was pointing out that AMD is in no rush to implement it in their chips, and for good reason: relative to the P4, it would have a much smaller impact on performance, and they can make larger gains by focusing elsewhere. The deep pipeline design of the P4 is why spending the time implementing SMT on that chip made sense.
Since you mention IBM as "everyone else," it's worth noting that IBM's POWER line of CPUs are not only multicore, but SMT as well. It helps, but AMD lacking SMT right now really isn't a big deal right now, especially with multicore K8s coming in the next 6 months or so.
I'd just like to add on to this that the reason the Athlons and P-M's don't need Hyperthreading is that HT is essentially a latency hiding method to make up for the obscenely long Netburst pipeline. Basically, keeping the 30-stage pipeline full is difficult with a single thread, so allowing the processor to address multiple threads at the same time helps keep the pipeline full. I'd suggest reading Hannibal's excellent articles at Ars Technica if you wish to learn more on the subject.
Essentially, I've always felt that HT is more of a marketing gimmick than it is some new revolution in computing. While it might help performance some, AMD's upcoming dual core chips will do far more to help performance as it actually *is* a multiprocessor system rather than faking it like HT. Remember, K8 was designed with multicore in mind from the start, with Netburst, it's been hacked in.
I spent several hours last night fighting with an IMAP server package on NLD (which is SuSe, and therefore RPM, based). In order to install the package, I first needed to install an authentication library, no big deal, I can build an RPM from source, right?
Well, here's the catch, some of the dependencies defined in the spec file distributed with the source looked for dependencies with RedHat names. I already had the freaking packages installed, but the package name registered in the RPM database was *ONE* character different, and the dependency check would fail as a result. So I got to spend time hacking away at spec files til the blasted thing finally gave in.
It's things like this that make me believe that the sooner we can move to a standardized base, the better off we'll be. Linux lags so far behind Windows, let alone OS X and its drag and drop installs, in this regard that it's not even funny.