But regardless of which itanium vendor you use, the most important component (the processor) and most likely the support chipset too, come from a single source (intel). Sun and fujitsu on the other hand both produce their own complete systems.
There also used to be a number of other companies producing sparc processors, like ross/bridgepoint, cypres, hitachi, bull etc...
So with itanium you still have intel as a single point of failure, which is not the case with sparc or x86, or even PPC.
Linux and BSD also run on Sparc... Microsoft have recently severely cut back their support for itanium.
As for where you buy the server, sure you can buy an itanium box from many vendors, but the cpu will only come from intel. With sparc the processor and/or the entire system can come from Fujitsu or Sun, you actually have _MORE_ choice if you go with Sparc...
I happen to agree... I will only buy proprietary software if it's superiority over a free alternative is equal to or greater than the cost to purchase the software. In a world like this, proprietary vendors have to compete, they have to improve their software and provide value over any free alternative. Most companies don't, they would rather lock you in with proprietary formats than convince people to use their product by choice.
As for me, i`m not loyal to any piece of software, if something better comes along i will quite happily switch. But if it costs more money, it has to be sufficiently better to justify the extra cost. I also won't switch to any product that aims to keep me locked in, that's a common trap i don't want to fall into.
I hate it when some movie company decides my country is unworthy of seeing it's latest creation... And they put blockages in place such as dvd regioning, to prevent us from importing a foreign copy.
Firefox already has vastly superior CSS support to current versions of IE... As for why this support is improving so slowly, maybe it's because so few (if any?) sites actually use these functions, most sites out there are designed for IE6 which is already massively behind firefox, so there just isn't that much incentive to keep improving the CSS support.
Well client->server could be any protocol, so long as the backend server supported the jabber server to server protocol... Now that gtalk has opened up server to server, and they're planning on producing interoperability with AOL, what's the chances that AOL will implement a jabber server to server system that ties in to their proprietary backend systems?
I'm sure macs support ACPI, i seem to remember that even the PPC ones did... The difference however, is that they support ACPI and MS-ACPI which is quite different (and the reason why linux acpi support doesn't work on some machines, since it strictly follows the intel acpi specs)
Card manufacturers merely rebrand physical hardware produced by a third party chipset manufacturer... They will often change chipset suppliers according to who is cheaper.
qemu also has the "kqemu" virtualization layer, which lets it natively execute code if the emulated platform shares the same processor type as the host machine, which would enable these intel based macs to run windows reasonably quickly.
Support for EFI is a standard linux kernel option, and i doubt it would be hard to support apple's partitioning scheme... They already used their own partitioning scheme on PPC machines, and linux supports that just fine.
I also believe EFI is the standard firmware used on Itanium systems too, so linux already must support it to run on such systems.
They don't, because the windows drivers don't either.
So in that respect, linux wireless support is better than windows, we can use all the windows drivers *and* do rfmonitor mode on certain cards, not to mention use wireless cards on non x86 architectures.
That's why Jabber is such a good idea... It works very much like email, you can use any provider and communicate with any other. Companies seem to make plenty of money providing email services, so providing jabber in the same way would work too.
So just like email, you will get free providers, value-add paid providers, your local isp providing the service, vanity domains etc... And because there's no single user database, you won't need to have a username like bert432489237489327.
I run Asterisk on 3 different 64-bit Alpha systems running linux, it runs flawlessly, much better than it ever did on an x86 machine... One of them even has a zaptel card installed, which also works perfectly...
I did however have major trouble getting Asterisk to work on sparc.
It's still an issue for 64bit XP, which was released long after the widespread availability of SATA (and 64bit amd64 processors)
Sure people *could* write windows drivers, but usually they don't... They simply wait for the vendor to write one, they can't reuse their existing 32bit drivers like linux users can. They would have to develop a new driver from scratch, contrast this with the linux world where not only does sourcecode for fully working 32bit drivers exist which can often simply be recompiled, and in the case of new hardware there are often drivers for older but similar hardware (like your epson printer) that can provide limited functionality immediately, and be used as a basis to provide full functionality. Again, windows users would be forced to start from scratch since 99% of windows drivers don't have sourcecode available.
I always thought Big Mac Ethernet was the first 100mb chipset (lance ethernet being their 10mb option), which was only available as an addon sbus card and never became widely popular (whereas the happy meal was shipped as standard on newer ultrasparc systems)
// And this is different on Windows How? All the manufacturer has to do in most instances is simply recompile their drivers as well.
But the point is that they haven't... 32-bit drivers for a lot of older hardware were provided by microsoft and not the individual vendors in any case.
Windows users are relying on the vendor to recompile (and test) their drivers for 64bit systems, vendors have no real incentive to do this for non-current hardware, since they want to sell the latest hardware, even if it was just as simple as a recompile (and many wouldn't be, 64bit windows is new and authors of windows drivers have never given 64bit cleanliness much thought).
By contrast, the sourcecode for these drivers is available for linux... Most linux drivers have been 64bit clean for years (thanks mostly to the alpha and other 64bit platforms on which linux has been running for 10+ years) and are a simple recompile on AMD64. You can recompile the kernel to support these drivers yourself, or use the drivers a distributor compiled.
So in order to run 64bit windows on my existing AMD64 machine, i need a new nic, new videocard, and new soundcard... Not to mention the fact that i need to get a floppy drive so i can load SATA drivers to even install windows... 32bit windows won't install without a floppy drive either, but that's another matter, and it does support all my other hardware.
Modern linux distributions by contrast, install very easily and support all the hardware in this machine out of the box.
It doesn't, the 64bit version lacks support for a LOT of older peripherals that were supported by the 32bit versions... My soundblaster pci, and dec tulip ethernet cards for instance, don't work with 64bit XP (32bit picks them up by default) and my radeon 7200 (original radeon) has no XP64 support at all.
By contrast, Linux actually supports a lot more hardware because the vast majority of the drivers for 32bit systems also work when recompiled for a 64bit system (and has done for years, a lot of hardware works on 64bit linux/alpha as well)
And if you know what you want installed, you can leave it overnight easily... I migrated from 1 machine running gentoo to another, i simply copied my homedir, took a package list from the original machine and told the new system to build those packages... Few hours later, all was ready for me, exactly how the old system had been but now optimized for the newer machine.
Someone needs to work on modularising openoffice or something... Lightweight is good most of the time, but every now and again someone will send you a file that uses an advanced feature (and everyone uses a different 5% of the feature set, so a lightweight app won't suit many people unless its modular), it would be good to be able to load/install additional modules when needed, but keep a lightweight base 99% of the time with just the features you actually use.
Well, if you've ever tried to import/export word files from ms publisher, you'l see just how difficult it is to implement the word format... The team developing publisher must have access to whatever documentation exists, and yet they can't open word files at all well, even openoffice does a much better job.
Slashdot Mirror
But regardless of which itanium vendor you use, the most important component (the processor) and most likely the support chipset too, come from a single source (intel).
Sun and fujitsu on the other hand both produce their own complete systems.
There also used to be a number of other companies producing sparc processors, like ross/bridgepoint, cypres, hitachi, bull etc...
So with itanium you still have intel as a single point of failure, which is not the case with sparc or x86, or even PPC.
Linux and BSD also run on Sparc...
Microsoft have recently severely cut back their support for itanium.
As for where you buy the server, sure you can buy an itanium box from many vendors, but the cpu will only come from intel. With sparc the processor and/or the entire system can come from Fujitsu or Sun, you actually have _MORE_ choice if you go with Sparc...
I happen to agree...
I will only buy proprietary software if it's superiority over a free alternative is equal to or greater than the cost to purchase the software.
In a world like this, proprietary vendors have to compete, they have to improve their software and provide value over any free alternative. Most companies don't, they would rather lock you in with proprietary formats than convince people to use their product by choice.
As for me, i`m not loyal to any piece of software, if something better comes along i will quite happily switch. But if it costs more money, it has to be sufficiently better to justify the extra cost. I also won't switch to any product that aims to keep me locked in, that's a common trap i don't want to fall into.
I hate it when some movie company decides my country is unworthy of seeing it's latest creation... And they put blockages in place such as dvd regioning, to prevent us from importing a foreign copy.
Firefox already has vastly superior CSS support to current versions of IE...
As for why this support is improving so slowly, maybe it's because so few (if any?) sites actually use these functions, most sites out there are designed for IE6 which is already massively behind firefox, so there just isn't that much incentive to keep improving the CSS support.
Well client->server could be any protocol, so long as the backend server supported the jabber server to server protocol... Now that gtalk has opened up server to server, and they're planning on producing interoperability with AOL, what's the chances that AOL will implement a jabber server to server system that ties in to their proprietary backend systems?
I'm sure macs support ACPI, i seem to remember that even the PPC ones did...
The difference however, is that they support ACPI and MS-ACPI which is quite different (and the reason why linux acpi support doesn't work on some machines, since it strictly follows the intel acpi specs)
Card manufacturers merely rebrand physical hardware produced by a third party chipset manufacturer... They will often change chipset suppliers according to who is cheaper.
qemu also has the "kqemu" virtualization layer, which lets it natively execute code if the emulated platform shares the same processor type as the host machine, which would enable these intel based macs to run windows reasonably quickly.
Support for EFI is a standard linux kernel option, and i doubt it would be hard to support apple's partitioning scheme... They already used their own partitioning scheme on PPC machines, and linux supports that just fine.
I also believe EFI is the standard firmware used on Itanium systems too, so linux already must support it to run on such systems.
Because most bioses shadow themselves into ram in order to run faster...
They don't, because the windows drivers don't either.
So in that respect, linux wireless support is better than windows, we can use all the windows drivers *and* do rfmonitor mode on certain cards, not to mention use wireless cards on non x86 architectures.
That's why Jabber is such a good idea... It works very much like email, you can use any provider and communicate with any other. Companies seem to make plenty of money providing email services, so providing jabber in the same way would work too.
So just like email, you will get free providers, value-add paid providers, your local isp providing the service, vanity domains etc... And because there's no single user database, you won't need to have a username like bert432489237489327.
I run Asterisk on 3 different 64-bit Alpha systems running linux, it runs flawlessly, much better than it ever did on an x86 machine... One of them even has a zaptel card installed, which also works perfectly...
I did however have major trouble getting Asterisk to work on sparc.
OpenDocument isn't intended to weaken commercial software, it's intended to improve the position of consumers.
The availability of standard image formats hasn't stopped Adobe from selling photoshop.
It's still an issue for 64bit XP, which was released long after the widespread availability of SATA (and 64bit amd64 processors)
Sure people *could* write windows drivers, but usually they don't... They simply wait for the vendor to write one, they can't reuse their existing 32bit drivers like linux users can. They would have to develop a new driver from scratch, contrast this with the linux world where not only does sourcecode for fully working 32bit drivers exist which can often simply be recompiled, and in the case of new hardware there are often drivers for older but similar hardware (like your epson printer) that can provide limited functionality immediately, and be used as a basis to provide full functionality. Again, windows users would be forced to start from scratch since 99% of windows drivers don't have sourcecode available.
I always thought Big Mac Ethernet was the first 100mb chipset (lance ethernet being their 10mb option), which was only available as an addon sbus card and never became widely popular (whereas the happy meal was shipped as standard on newer ultrasparc systems)
// And this is different on Windows How? All the manufacturer has to do in most instances is simply recompile their drivers as well.
But the point is that they haven't...
32-bit drivers for a lot of older hardware were provided by microsoft and not the individual vendors in any case.
Windows users are relying on the vendor to recompile (and test) their drivers for 64bit systems, vendors have no real incentive to do this for non-current hardware, since they want to sell the latest hardware, even if it was just as simple as a recompile (and many wouldn't be, 64bit windows is new and authors of windows drivers have never given 64bit cleanliness much thought).
By contrast, the sourcecode for these drivers is available for linux... Most linux drivers have been 64bit clean for years (thanks mostly to the alpha and other 64bit platforms on which linux has been running for 10+ years) and are a simple recompile on AMD64. You can recompile the kernel to support these drivers yourself, or use the drivers a distributor compiled.
So in order to run 64bit windows on my existing AMD64 machine, i need a new nic, new videocard, and new soundcard... Not to mention the fact that i need to get a floppy drive so i can load SATA drivers to even install windows...
32bit windows won't install without a floppy drive either, but that's another matter, and it does support all my other hardware.
Modern linux distributions by contrast, install very easily and support all the hardware in this machine out of the box.
It doesn't, the 64bit version lacks support for a LOT of older peripherals that were supported by the 32bit versions...
My soundblaster pci, and dec tulip ethernet cards for instance, don't work with 64bit XP (32bit picks them up by default) and my radeon 7200 (original radeon) has no XP64 support at all.
By contrast, Linux actually supports a lot more hardware because the vast majority of the drivers for 32bit systems also work when recompiled for a 64bit system (and has done for years, a lot of hardware works on 64bit linux/alpha as well)
And if you know what you want installed, you can leave it overnight easily...
I migrated from 1 machine running gentoo to another, i simply copied my homedir, took a package list from the original machine and told the new system to build those packages...
Few hours later, all was ready for me, exactly how the old system had been but now optimized for the newer machine.
There is a 64bit JVM already, the problem is things like flash which are only available as native binaries, and not for 64bit hardware.
Actually C# is more of a java clone, since java has been around a lot longer.
Someone needs to work on modularising openoffice or something...
Lightweight is good most of the time, but every now and again someone will send you a file that uses an advanced feature (and everyone uses a different 5% of the feature set, so a lightweight app won't suit many people unless its modular), it would be good to be able to load/install additional modules when needed, but keep a lightweight base 99% of the time with just the features you actually use.
Well, if you've ever tried to import/export word files from ms publisher, you'l see just how difficult it is to implement the word format...
The team developing publisher must have access to whatever documentation exists, and yet they can't open word files at all well, even openoffice does a much better job.
Well, VirtualPC also runs on windows, and behaves similarly to vmware when it does (virtualization rather than emulation).
On the other hand, theres tools like qemu coming along that work just fine on OSX, and there's no reason vmware couldn't be ported to OSX/x86.