After the Mac Mini came out I held off getting one for my daughter, because I expected the price of G4s to drop as a result. It didn't happen. They did continue to drop, slowly, but there wasn't a big change. So I bought one finally (alas, just a little too soon to get Tiger on it).
This past month, though, there's really been a big difference. I've seen two G4s (pretty bare, admittedly, but they did include 450 MHz CPUs) for under $200!
My first exposure to a "native" TCP/IP implementation (anyone remember that winsock.dll you hadda get before Windows would get online?)
Did they do a complete socket implementation or only the half-assed one Microsoft and Be managed, where you had to use different calls on sockets or files?
Cyberpunk cop shopping channel...
on
3D Face Cameras
·
· Score: 1
This sentence just made me think "this is the stuff Case and Molly watch late at night after a hard day hacking into improbably glowing mainframes, on the cyberpunk cop shopping channel."
It [...] provides incredible accuracy in correctly mapping the individual being booked in 3D.
don't you think the main reason why there's so many worms for Windows and so few for Linux is that there are a hell of a lot more victims for Windows worms?
No.
The main reason is that the Microsoft HTML control is inherently insecure and unfixable without modifying every application that uses it to use a new API that puts that application in charge of determining what capabilities documents displayed via the control have, regardless of what 'security zone' they are in.
That is absolutely critical. There must be no mechanism in the browser itself for a script to request "unsandboxed" control, or for the document to request an ActiveX control that is not already installed and explicitly registered as a sandbox component. Not even if the user "approves" it through a security dialog. It must not be possible to initiate this from the document rather than from the application, no matter where the document is, no matter whether it's "trusted" or not.
Every time Microsoft comes out with a new service pack or hotfix I predict that a new way will be found to fake the system out. SP2 was supposed to be it, but no, they've just had to release a new hotfix because someone found an unsafe embeddable component that wasn't ever intended to be used from the browser. There will be more.
Back before 1997 "there's more Windows boxes" was a real point. But when Active Desktop was released that all changed. I managed to get IE and Outlook banned at work. A little while later the flood of viruses and worms started, almost all based on tricks that fooled the HTML control used by Outlook into embedding and running them. And that's continued to be the main engine driving the rich viral ecosystem on Windows ever since. Oh, there's unrelated exploits, and social engineering, but a virus writer can always go back and look in the HTML control when all else fails.
I expect a Pentium M 2.13 GHz (and it should be say 2.3 or 2.4 GHz by next year) will be a good deal faster then the current 1.67 GHz G4s
If the 2.13 GHz Pentium M is faster than the 1.67 GHz G4, it's only because of the faster memory bus, the G4 core is no slouch. I haven't seen a comparison between the Pentium M and the G4, but both have been compared with the Pentium 4... and based on that it looks like the fastest G4 cores would probably beat the fastest Pentium M cores.
The only problem is that damn 166 MHz memory bus on the G4.
But... Freescale should have the new G4-cored highly integrated chip they've been working on well before the switch, and it's going to have an even faster memory bus (2 * 667 vs 1 * 400 or 1 * 533) than the Pentium M.
So while the new Powerbook a year from now may be faster than your current model, that's basically going to be because, well, it's going to BE a year from now. It'd be faster (much faster) with the e600. You won't get more of a performance boost than you would have if Apple had stuck to the PPC.
I've seen things you people wouldn't believe. Powermacs on fire on the Low End Mac swap list. iMacs for pickup just to save the postage. All these Macs will be lost in the switch, like Lisas in the landfill. Time to upgrade.
Over the past month, more or less, I've seen used Powermac G4 prices drop significantly. That normally only happens to a model line when Apple releases a version of OS X that doesn't support them (like Beige G3s after Panther, pre-Firewire iMacs after Tiger). I've also seen G5s for sale on the Low End Mac swap list for the first time ever.
This time... Leopard may drop support for some or all G3s and maybe even the Yikes G4, but I don't anticipate AGP G4s being in trouble from Leopard, and in any case it's a year and a half off.
The reason for the lower prices? When it's explained, it's the expected Intel macs. If they're depressing used prices already, a year off, I wouldn't expect your PPC Macs to hold their value the way they have in the past.
There's no way a P4 will run a PPC emulation at 70% of the speed of native apps, unless there's something terribly wrong with native app performance. Optimization matters, and even if they're doing absolutely brilliant transcoding they're translating code optimized for a larger register file into the P4's tiny register set... if a native compiler can't beat that with one optimizer tied behind its back there's something seriously wrong with that compiler.
They're expecting to get 30 billion dollars from auctioning the bandwidth.
If they bought a $50 digital converter box for all 120 million households in the US (not just the 18 million analog-only households), that would leave them 24 billion to put towards balancing the budget (or pay for a couple of weeks more war in Iraq).
Having to take these extra steps defeats the object of a cross-platform UI library. The library should be handling this stuff.
Maybe they need to provide Java bindings for Tk, because it does a pretty good job of providing a compatible look and feel on any platform, including automatically putting the menu bar in the right place on Mac and Windows.
PS: I googled around a bit but I couldn't find an English-language site for Skole Linux, just news articles and what I guess was Norwegian. You got a link I could look at?
BSD or Linux doesn't really matter here. I prefer BSD, so that's what I used. I haven't tried cramming a similar Linux configuration into an old computer, but I'm sure it's possible. I'll just say "free UNIX" and you can read that as "BSD" or "Linux" as you like it.
There's a number of alternatives here, depending on just how old the computers are and what you want to run. Most of the "office suite" type applications for free UNIX, that I've looked at anyway, are pretty big and bloated. If all you're doing is running some library application (perhaps using a web interface), then you probably don't need much of a computer... really, a web browser *is* a thin client, and a pretty efficient one in terms of its network requirements.
Anyway, the directions you want to think about are:
1. Dataless clients. You have a disk in the client, but it's either just a local swap disk and you boot off the net, or it's a miminal OS image with maybe shared applications. Personalization is handled by having an account on a server so whenever you log in to a client you log into your account over the LAN. This was the original MIT Project Athena model.
Sun came up with an interesting variant on this using a cache file system on an otherwise net-booted box. Over time files (applications, libraries, and so on) get cached on the local disk, so the system just gets faster and faster... but administratively it's just like a diskless client.
2. Diskless clients. There's no local disk, you boot off a server, swap to a server, and so on. You still run applications locally, the server is just a file store and boot host.
3. Thin clients. This can mean anything from a box that's just a bitmapped terminal through an X terminal to something that runs lightweight applications locally and others remotely. A system that just boots up into a web browser would really be a thin client, though it's usually called a "kiosk".
What you probably ought to do is get one of these old boxes and install a free UNIX on it, and get a feel for the performance using the apps you're planning on providing. If it's accetable, it's almost certainly a heck of a lot easier to support 3 dataless clients than a thin-client solution. On the other hand I sure liked the simplicity of having 150 Xterminals on a handful of Alpha servers over having 150 PCs...
Windows thin clients are a bad economic case. You need to be running a REALLY beefy server and any client capable of running the thin client software is itself going to have to be more than fast enough to be entirely usable running a free UNIX.
Here is the case I am looking at: a museum with no money, and 3 old windows machines, plus one reasonably fast recent one.
Install a free UNIX on them. If the machine's fast enough to run any kind of thin client software at all it should be plenty fast enough to run the library applications themselves. Until it died (condensation from a vent dripped nasty moldy water on it) I was running FreeBSD on a Pentium 133 laptop with 64M RAM (maxed out!) Windowmaker as the window manager (no CPU-sucking Gnome or KDE) and Opera as a browser. I'm sure that any computer that hasn't been thrown out years ago is faster than that!
If the "fast recent machine" is going to run as a server, you'll need to install NT Server on it for multiuser support (Windows Terminal Server), which is expensive enough by itself that you'd be able to buy at least 3 fast new PCs for the same money.
The only economic case for blades is "windows doesn't scale". The economic case for Windows thin servers is "windows is a CPU hog". Get Windows out of the picture and the picture changes amazingly.
Ironic, that, because ten years ago we were using Windows boxes as thin clients for our Alpha servers. Of course we were able to suport 30 users on a 233 MHz Alpha using X11... if we'd had to give each user a server as capable as the typical Windows desktop today there'd have been no way it'd be affordable.
Gecko in Firefox not inherently safe... try KHTML?
on
Firefox 1.05 Released
·
· Score: 2, Interesting
Looks like the way the Javascript extensions for Chrome are integrated into Firefox are there in all the JS interpreter instances or contexts, they're just privileged. If the script is expected to be run from an untrusted environment, it's run at a lower privilege level.
In an inherently safe model, the interpreter wouldn't contain any mechanism to request unsafe actions... they'd simply be syntax errors. They would only be added explicitly when the script was known to be running from a safe environment.
Same with URI handlers: they would only be available from a reference within a safe environment.
As I understand it, KHTML is an inherently safe design. Extensions have to be explicitly loaded into an instance of the HTML display object through I/O slaves. Gecko, apparently, isn't... at least not in a broser that uses Chrome for its user interface. It's better than the Microsoft HTML control, but it's not an inherently secure design as it sounded like originally.
What are the options for a KHTML-based browser for Windows? On the Mac, of course, Safari is secure (so long as you turn off "open safe files after downloading"), but I haven't been following WIndows browsers that closely.
Profile paths are strange because...
on
Firefox 1.05 Released
·
· Score: 2, Informative
... they're there to prevent a path-guessing attack like the ones used to fake out the security zones in Internet Explorer.
I think the death penalty for the man responsible for the virus epidemic is too harsh, but perhaps some monetary damages that are sufficient for him to notice would deter him from pulling the same kind of monkey-business with browsers and active content again.
It's more a case of me making a fuss about an American mentioning first amendment rights in relation to something that takes place in Vancouver.
The subject of this subthread is why it wouldn't have happened in the US (not that there's any lack of artful stupidity in the US code, of course), so in that context I think that "first amendment" is actually appropriate.
I'm Australian, which means I grew up about as far from the US as you can get and still be on the same planet, and I knew about the first amendment years before I came to the US. Not caring about how the US government works just because you don't live in the US seems really really stupid. Particularly for a Canadian! It's like living next to a big factory that occasionally belches weird-smelling smoke and not bothering to find out what's going on inside.
That covers the retailer not being allowed to sell the book, but the guy who bought it in good faith has no contract with the publisher, what's the logic behind an injunction against him?
I know, that word doesn't mean what I think it means, but still... what legal theory supports preventing someone who bought a book in good faith without engaging in any agreement (or even reading a notice) to keep the details of the book secret from talking about what they read?
There's quite a few Cocoa Java apps out there, and some seem quite good... but I've found that I'm using very few of them... probably due to the fact that I'm a low-end Mac user. Cocoa already has a fairly significant overhead (presumably due to Aqua rather then Objective C, since NeXTSTeP was quite practical on a 68030). Java just gave it that little extra punch to push it over the top, kind of like turning the lag up to 11.
On faster machines I'm sure it's a lot better, and I would assume that they'd run under native Java on Intel rather than adding Rosetta's overhead to the devilish mix, so I doubt that performance is a direct issue for Apple. But the lack of adoption of Java by users could be.
And of course there's a huge difference between the object models of Java and Objective C. Unlike languages like F-Script, I doubt that it's just a matter of translating the calling mechanism, so I suspect maintaining the interface has been pretty labor-intensive.
As for Swing, what does that do to the native look and feel? What's an example of an application that uses it that I can try on Mac OS X?
Later Alphas are 4-issue RISC. It's hard to keep the threads from stalling.
Any modern processor has the same problem... I don't think any new core in the past five years hasn't been multi-issue, and most of them have bigger problems because they have longer pipelines and take a bigger hit when they have to stall the pipeline because of inter-instruction dependencies.
The Alpha instruction set gives the CPU a lot of leeway in reordering instructions: the instruction set itself is very regular; it has bunches of registers to give the compiler maximum ability to avoid dependency problems; and the compiler can explicitly place barriers to give the CPU even more clues. It's really a lot like the Power PC, except with more and wider registers and less legacy cruft in the instruction set, and it got out-of-order instruction issue (like the G5) back when the "G3" was pretty spiffy.
Now if you don't have OOO issue, the compiler has to work harder. We see that with the multi-core Power PC on the XBox, which is kind of an in-order version of the G5 core and the early comments from developers are that it's a big pain to write good code for.
So, Alpha isn't exceptionally hard to deal with, it's actually pretty normal for 2005... and was already a typical 2005 design back in 1997 or so.
It's a lot easier to generate good code for the Alpha than for something like the Pentium 4 where you have the same kind of scheduling issues and only 8 registers to work with and the relatively stupid "compiler" running in the CPU itself has to shuffle hidden registers around and guess at what it's really going to need.
Itanium is EPIC, very much the same thing
Not really. On the Itanium the way you express potential concurrency is to put the potentially concurrent instructions in a bundle, and the bundle size is implementation dependent with a slot for each functional unit. There's no leeway at all, here, the only way to get good speed on a new version of the architecture is to recompile for the larger bundles. For some people that's not that big a deal, like the control systems market where if you have relatively few customers and you upgrade the CPU at the same time as you upgrade the software you can keep them all in sync. But for commodity software it's a killer.
Meanwhile, code that's good on a single-threaded Alpha is still going to run pretty well on a multi-issue one. You don't need to recompile the code to get all your bundles lined up with the functional units again.
Slashdot Mirror
After the Mac Mini came out I held off getting one for my daughter, because I expected the price of G4s to drop as a result. It didn't happen. They did continue to drop, slowly, but there wasn't a big change. So I bought one finally (alas, just a little too soon to get Tiger on it).
This past month, though, there's really been a big difference. I've seen two G4s (pretty bare, admittedly, but they did include 450 MHz CPUs) for under $200!
My first exposure to a "native" TCP/IP implementation (anyone remember that winsock.dll you hadda get before Windows would get online?)
Did they do a complete socket implementation or only the half-assed one Microsoft and Be managed, where you had to use different calls on sockets or files?
This sentence just made me think "this is the stuff Case and Molly watch late at night after a hard day hacking into improbably glowing mainframes, on the cyberpunk cop shopping channel."
It [...] provides incredible accuracy in correctly mapping the individual being booked in 3D.
don't you think the main reason why there's so many worms for Windows and so few for Linux is that there are a hell of a lot more victims for Windows worms?
No.
The main reason is that the Microsoft HTML control is inherently insecure and unfixable without modifying every application that uses it to use a new API that puts that application in charge of determining what capabilities documents displayed via the control have, regardless of what 'security zone' they are in.
That is absolutely critical. There must be no mechanism in the browser itself for a script to request "unsandboxed" control, or for the document to request an ActiveX control that is not already installed and explicitly registered as a sandbox component. Not even if the user "approves" it through a security dialog. It must not be possible to initiate this from the document rather than from the application, no matter where the document is, no matter whether it's "trusted" or not.
Every time Microsoft comes out with a new service pack or hotfix I predict that a new way will be found to fake the system out. SP2 was supposed to be it, but no, they've just had to release a new hotfix because someone found an unsafe embeddable component that wasn't ever intended to be used from the browser. There will be more.
Back before 1997 "there's more Windows boxes" was a real point. But when Active Desktop was released that all changed. I managed to get IE and Outlook banned at work. A little while later the flood of viruses and worms started, almost all based on tricks that fooled the HTML control used by Outlook into embedding and running them. And that's continued to be the main engine driving the rich viral ecosystem on Windows ever since. Oh, there's unrelated exploits, and social engineering, but a virus writer can always go back and look in the HTML control when all else fails.
I expect a Pentium M 2.13 GHz (and it should be say 2.3 or 2.4 GHz by next year) will be a good deal faster then the current 1.67 GHz G4s
If the 2.13 GHz Pentium M is faster than the 1.67 GHz G4, it's only because of the faster memory bus, the G4 core is no slouch. I haven't seen a comparison between the Pentium M and the G4, but both have been compared with the Pentium 4... and based on that it looks like the fastest G4 cores would probably beat the fastest Pentium M cores.
The only problem is that damn 166 MHz memory bus on the G4.
But... Freescale should have the new G4-cored highly integrated chip they've been working on well before the switch, and it's going to have an even faster memory bus (2 * 667 vs 1 * 400 or 1 * 533) than the Pentium M.
So while the new Powerbook a year from now may be faster than your current model, that's basically going to be because, well, it's going to BE a year from now. It'd be faster (much faster) with the e600. You won't get more of a performance boost than you would have if Apple had stuck to the PPC.
I've seen things you people wouldn't believe. Powermacs on fire on the Low End Mac swap list. iMacs for pickup just to save the postage. All these Macs will be lost in the switch, like Lisas in the landfill. Time to upgrade.
Don't expect a kick in performance from the Intel switch.
Today's fastest powerbooks are still G4s at 1.67 GHz - an increase of just 34% in nearly 2 years.
2003 - Pentium M 1.7 GHz.
2005 - Pentium M 2.13 GHz.
Improvement: 25%.
Nobody is improving performance as fast as they used to, and the Power PC has actually done better than the Pentium over the same period.
used Macs hold value well
Over the past month, more or less, I've seen used Powermac G4 prices drop significantly. That normally only happens to a model line when Apple releases a version of OS X that doesn't support them (like Beige G3s after Panther, pre-Firewire iMacs after Tiger). I've also seen G5s for sale on the Low End Mac swap list for the first time ever.
This time... Leopard may drop support for some or all G3s and maybe even the Yikes G4, but I don't anticipate AGP G4s being in trouble from Leopard, and in any case it's a year and a half off.
The reason for the lower prices? When it's explained, it's the expected Intel macs. If they're depressing used prices already, a year off, I wouldn't expect your PPC Macs to hold their value the way they have in the past.
It's not the future we all hoped for.
Yeah! Where's my flying car?
There's no way a P4 will run a PPC emulation at 70% of the speed of native apps, unless there's something terribly wrong with native app performance. Optimization matters, and even if they're doing absolutely brilliant transcoding they're translating code optimized for a larger register file into the P4's tiny register set... if a native compiler can't beat that with one optimizer tied behind its back there's something seriously wrong with that compiler.
They're expecting to get 30 billion dollars from auctioning the bandwidth.
If they bought a $50 digital converter box for all 120 million households in the US (not just the 18 million analog-only households), that would leave them 24 billion to put towards balancing the budget (or pay for a couple of weeks more war in Iraq).
Having to take these extra steps defeats the object of a cross-platform UI library. The library should be handling this stuff.
Maybe they need to provide Java bindings for Tk, because it does a pretty good job of providing a compatible look and feel on any platform, including automatically putting the menu bar in the right place on Mac and Windows.
PS: I googled around a bit but I couldn't find an English-language site for Skole Linux, just news articles and what I guess was Norwegian. You got a link I could look at?
BSD or Linux doesn't really matter here. I prefer BSD, so that's what I used. I haven't tried cramming a similar Linux configuration into an old computer, but I'm sure it's possible. I'll just say "free UNIX" and you can read that as "BSD" or "Linux" as you like it.
There's a number of alternatives here, depending on just how old the computers are and what you want to run. Most of the "office suite" type applications for free UNIX, that I've looked at anyway, are pretty big and bloated. If all you're doing is running some library application (perhaps using a web interface), then you probably don't need much of a computer... really, a web browser *is* a thin client, and a pretty efficient one in terms of its network requirements.
Anyway, the directions you want to think about are:
1. Dataless clients. You have a disk in the client, but it's either just a local swap disk and you boot off the net, or it's a miminal OS image with maybe shared applications. Personalization is handled by having an account on a server so whenever you log in to a client you log into your account over the LAN. This was the original MIT Project Athena model.
Sun came up with an interesting variant on this using a cache file system on an otherwise net-booted box. Over time files (applications, libraries, and so on) get cached on the local disk, so the system just gets faster and faster... but administratively it's just like a diskless client.
2. Diskless clients. There's no local disk, you boot off a server, swap to a server, and so on. You still run applications locally, the server is just a file store and boot host.
3. Thin clients. This can mean anything from a box that's just a bitmapped terminal through an X terminal to something that runs lightweight applications locally and others remotely. A system that just boots up into a web browser would really be a thin client, though it's usually called a "kiosk".
What you probably ought to do is get one of these old boxes and install a free UNIX on it, and get a feel for the performance using the apps you're planning on providing. If it's accetable, it's almost certainly a heck of a lot easier to support 3 dataless clients than a thin-client solution. On the other hand I sure liked the simplicity of having 150 Xterminals on a handful of Alpha servers over having 150 PCs...
Windows thin clients are a bad economic case. You need to be running a REALLY beefy server and any client capable of running the thin client software is itself going to have to be more than fast enough to be entirely usable running a free UNIX.
Here is the case I am looking at: a museum with no money, and 3 old windows machines, plus one reasonably fast recent one.
Install a free UNIX on them. If the machine's fast enough to run any kind of thin client software at all it should be plenty fast enough to run the library applications themselves. Until it died (condensation from a vent dripped nasty moldy water on it) I was running FreeBSD on a Pentium 133 laptop with 64M RAM (maxed out!) Windowmaker as the window manager (no CPU-sucking Gnome or KDE) and Opera as a browser. I'm sure that any computer that hasn't been thrown out years ago is faster than that!
If the "fast recent machine" is going to run as a server, you'll need to install NT Server on it for multiuser support (Windows Terminal Server), which is expensive enough by itself that you'd be able to buy at least 3 fast new PCs for the same money.
The only economic case for blades is "windows doesn't scale". The economic case for Windows thin servers is "windows is a CPU hog". Get Windows out of the picture and the picture changes amazingly.
Ironic, that, because ten years ago we were using Windows boxes as thin clients for our Alpha servers. Of course we were able to suport 30 users on a 233 MHz Alpha using X11... if we'd had to give each user a server as capable as the typical Windows desktop today there'd have been no way it'd be affordable.
Looks like the way the Javascript extensions for Chrome are integrated into Firefox are there in all the JS interpreter instances or contexts, they're just privileged. If the script is expected to be run from an untrusted environment, it's run at a lower privilege level.
In an inherently safe model, the interpreter wouldn't contain any mechanism to request unsafe actions... they'd simply be syntax errors. They would only be added explicitly when the script was known to be running from a safe environment.
Same with URI handlers: they would only be available from a reference within a safe environment.
As I understand it, KHTML is an inherently safe design. Extensions have to be explicitly loaded into an instance of the HTML display object through I/O slaves. Gecko, apparently, isn't... at least not in a broser that uses Chrome for its user interface. It's better than the Microsoft HTML control, but it's not an inherently secure design as it sounded like originally.
What are the options for a KHTML-based browser for Windows? On the Mac, of course, Safari is secure (so long as you turn off "open safe files after downloading"), but I haven't been following WIndows browsers that closely.
... they're there to prevent a path-guessing attack like the ones used to fake out the security zones in Internet Explorer.
Honestly, I'll bet this doesn't make the carts any cheaper. Inkjet printers are like safety razors, the money's in the ink... not the printer.
I think the death penalty for the man responsible for the virus epidemic is too harsh, but perhaps some monetary damages that are sufficient for him to notice would deter him from pulling the same kind of monkey-business with browsers and active content again.
It's more a case of me making a fuss about an American mentioning first amendment rights in relation to something that takes place in Vancouver.
The subject of this subthread is why it wouldn't have happened in the US (not that there's any lack of artful stupidity in the US code, of course), so in that context I think that "first amendment" is actually appropriate.
I'm Australian, which means I grew up about as far from the US as you can get and still be on the same planet, and I knew about the first amendment years before I came to the US. Not caring about how the US government works just because you don't live in the US seems really really stupid. Particularly for a Canadian! It's like living next to a big factory that occasionally belches weird-smelling smoke and not bothering to find out what's going on inside.
That covers the retailer not being allowed to sell the book, but the guy who bought it in good faith has no contract with the publisher, what's the logic behind an injunction against him?
I know, that word doesn't mean what I think it means, but still... what legal theory supports preventing someone who bought a book in good faith without engaging in any agreement (or even reading a notice) to keep the details of the book secret from talking about what they read?
There's quite a few Cocoa Java apps out there, and some seem quite good... but I've found that I'm using very few of them... probably due to the fact that I'm a low-end Mac user. Cocoa already has a fairly significant overhead (presumably due to Aqua rather then Objective C, since NeXTSTeP was quite practical on a 68030). Java just gave it that little extra punch to push it over the top, kind of like turning the lag up to 11.
On faster machines I'm sure it's a lot better, and I would assume that they'd run under native Java on Intel rather than adding Rosetta's overhead to the devilish mix, so I doubt that performance is a direct issue for Apple. But the lack of adoption of Java by users could be.
And of course there's a huge difference between the object models of Java and Objective C. Unlike languages like F-Script, I doubt that it's just a matter of translating the calling mechanism, so I suspect maintaining the interface has been pretty labor-intensive.
As for Swing, what does that do to the native look and feel? What's an example of an application that uses it that I can try on Mac OS X?
Later Alphas are 4-issue RISC. It's hard to keep the threads from stalling.
Any modern processor has the same problem... I don't think any new core in the past five years hasn't been multi-issue, and most of them have bigger problems because they have longer pipelines and take a bigger hit when they have to stall the pipeline because of inter-instruction dependencies.
The Alpha instruction set gives the CPU a lot of leeway in reordering instructions: the instruction set itself is very regular; it has bunches of registers to give the compiler maximum ability to avoid dependency problems; and the compiler can explicitly place barriers to give the CPU even more clues. It's really a lot like the Power PC, except with more and wider registers and less legacy cruft in the instruction set, and it got out-of-order instruction issue (like the G5) back when the "G3" was pretty spiffy.
Now if you don't have OOO issue, the compiler has to work harder. We see that with the multi-core Power PC on the XBox, which is kind of an in-order version of the G5 core and the early comments from developers are that it's a big pain to write good code for.
So, Alpha isn't exceptionally hard to deal with, it's actually pretty normal for 2005... and was already a typical 2005 design back in 1997 or so.
It's a lot easier to generate good code for the Alpha than for something like the Pentium 4 where you have the same kind of scheduling issues and only 8 registers to work with and the relatively stupid "compiler" running in the CPU itself has to shuffle hidden registers around and guess at what it's really going to need.
Itanium is EPIC, very much the same thing
Not really. On the Itanium the way you express potential concurrency is to put the potentially concurrent instructions in a bundle, and the bundle size is implementation dependent with a slot for each functional unit. There's no leeway at all, here, the only way to get good speed on a new version of the architecture is to recompile for the larger bundles. For some people that's not that big a deal, like the control systems market where if you have relatively few customers and you upgrade the CPU at the same time as you upgrade the software you can keep them all in sync. But for commodity software it's a killer.
Meanwhile, code that's good on a single-threaded Alpha is still going to run pretty well on a multi-issue one. You don't need to recompile the code to get all your bundles lined up with the functional units again.