So submit a bug, and watch it's progress. Many of the people who write code, have no real need for a spreadsheet, so they have very little idea what features real users actually need unless those users tell them!
They may provide users with a single area to associate with security, but they also provide malware authors with a single target for their malware to sieze control of and disable and/or modify...
Typo correction is an awfull feature, it encourages people to make such typos... When these people then go to a machine without such a feature, it will hinder them greatly. Aside from the fact that most common mis-spellings of popular domains have already been registered by scam artists anyway.
The handheld market isn't *that* young... The Gameboy was competing against the Sega game-gear in the 90s, and despite the obvious superiority of the game gear (colour screen etc), the gameboy still sold much better.
That's still 1 1/2 years, assuming no owners of voodoo cards had access to any of the beta released of xp x64 to begin porting the driver... What's worse tho, is that 64bit windows is over 10 years behind the first 64bit OS, despite running (in a limited fashion, not taking advantage of 64bit features) on 64bit hardware since early releases of NT (mips, alpha etc)
I also have an original SBLive card, which works perfectly under 64bit linux, but none of the 64bit versions of windows seem to support it... It also works on 64bit linux on a 64bit alphastation. I have the same issue with old tulip 10/100 network cards, no 64bit windows supports them, even tho the cards were designed for 64bit machines, and are well supported by tru64 and openvms on the alpha.
Glide was a dedicated gaming API, specifically tailored to the voodoo hardware... OpenGL on the other hand, is a more general purpose graphics API designed to run on a wide range of hardware, and is designed for quality rather than gaming performance.
Yes, indeed... I had the good fortune to play glquake on an SGI Onyx connected to a 24" screen via 13W3 (shielded cable) back in those days, it put the voodoo cards to shame.
Someone on the linked forum made a joke about Amiga drivers for the voodoo boards... They're even still being sold! http://www.vesalia.de/e_mediator.htm
It's better to have something that works well when it's ready, than to have a rushed half assed job that's ready much earlier, but doesn't do the job... Especially in the military, would you want hurriedly built planes falling apart over enemy territory?
The trunking is a feature of the phone, not of the backend PBX software... You can use cisco phones with asterisk, i`m using a 7960 at home with multiple asterisk servers (the 7960 has support for 6 "lines"), and the vlan trunking works on it, although i don't use it at home... Many of the Nortel phones support trunking too, tho i can't speak for any of the other vendors. In terms of the backend, linux will also support trunking if you need such a facility on the backend.
Packet filtering capabilities should be an integral part of every TCP stack, the fact that a market has grown up around providing these features to an OS which lacks them is ridiculous, and such a market deserves to cease to exist...
When it comes to anti-spyware and anti-virus, these are both a bad idea in any case... It's foolish to allow this malware onto your machine and then try to remove it. Microsoft should be improving the OS so it's more resillient to such things, and therefore has no need for additional packages to remove them. Conversely, if microsoft have a dominant antivirus/antispyware package, then they may aswell not have one at all, because malware authors will have a single target to aim at, and will quickly develop standard ways to evade and/or neuter these packages.
There is a project called x86abi which aims to meet these needs, however it's not very far along in it's development and could do with some support... http://www.x86abi.org/
Well, i`m sure they could, but that would enable competitors to compete more effectively... It's much easier to lock users in to a crap proprietary product than it is to make your product actually stand on it's merit.
It worked for Apple, OSX is a huge step up from OS9.... Nowadays, with virtualization built in to modern processors, it's a good time to scrap backwards compatibility and let one (or more) instances of legacy systems run within virtualization. This would not only remove the legacy cruft from the main OS, but would enable you to run old apps that break on current versions of windows too.
If you keep the UI the same, then people won't upgrade. To the average end user, that's all they see, and couldn't care less about what goes on underneath.
Itanium is a different matter, because EFI is the default firmware on an itanium box and so there was no choice. But you bring up an interesting point, they clearly had the code to support EFI but just didn't use it.
Windows has pretty good power management functions in many ways, but they aren't very flexible...
In particular, windows is very keen on accessing the disk, to the extent that the disk is often kept spinning constantly under normal use... Linux however, supports "laptop mode" whereby any writes to the disk are cached and delayed (potentially dangerous, but you know how much battery life you have so theres no chance of a power cut) and either written when the disk is forced to spin up anyway (for a read etc) or at a set time (spin up, write, spin down)... With reads too, it can do readahead so it reads in more data than necessary and caches it, so it has to spin up the disk and read less often.
Also, cpu frequency scaling seems to be more flexible, you can set the cpu clock to a particular rate, or put it in automatic powersave/ondemand/performance modes.
Actually, Intel designed and published the ACPI specs, and produce a reference interpreter and compiler for the DSDT... Seeing as how close Intel and Apple are nowadays, i would imagine Apple's ACPI implementation complies with Intel's specs.
On the other hand, Microsoft make their own compiler which has many subtle differences from Intels, in particular it has an ability to ignore many errors that violate the spec and are thus flagged by Intel's compiler. Their implementation of ACPI implements the same tollerence of errors as their compiler, so the two work together well. The disadvantage for the rest of us, is that microsoft have never published the changes they made to the ACPI spec, and many systems compiled using their compiler will fail to work on a fully standards compliant ACPI interpreter. You would imagine that Apple, not being in posession of microsoft's internal documentation regarding their version of ACPI, would choose to use the official Intel spec, which is readily available from their site.
EFI? Future? EFI has been around for years, however microsoft never bothered to support it so no motherboard manufacturers implemented it either. Apple only used it because they had their own OS, and therefore didn't have to wait for microsoft to support anything. It has already been confirmed that vista will not support EFI, so you'l be waiting several years for another version of windows that does.
Other questions that do arise however, how proprietary is EFI? can other vendors produce clones of it, or are they tied to intel in some way?
But there still needs to be facilities to load drivers into the kernel, and there will almost certainly be bugs found which may result in malicious kernel modules being loaded. You could also put the disk in another machine, and modify the kernel on disk before booting it...
Well, that's no true test of 64bit, that's a comparison of 2 processors... Why not try running a 64bit and 32bit os side by side on identical hardware. Not that it's worth it, 64bit xp is laughable right now, and there's really no point using it, which is why noone does.
Slashdot Mirror
Exactly, so bundling a firewall is something they *should* do, every other OS does it anyway.
So submit a bug, and watch it's progress.
Many of the people who write code, have no real need for a spreadsheet, so they have very little idea what features real users actually need unless those users tell them!
They may provide users with a single area to associate with security, but they also provide malware authors with a single target for their malware to sieze control of and disable and/or modify...
Well, CPU cycles are produced as a direct result of the consumption of electricity, which does have a cost associated with it...
Typo correction is an awfull feature, it encourages people to make such typos...
When these people then go to a machine without such a feature, it will hinder them greatly.
Aside from the fact that most common mis-spellings of popular domains have already been registered by scam artists anyway.
The handheld market isn't *that* young...
The Gameboy was competing against the Sega game-gear in the 90s, and despite the obvious superiority of the game gear (colour screen etc), the gameboy still sold much better.
That's still 1 1/2 years, assuming no owners of voodoo cards had access to any of the beta released of xp x64 to begin porting the driver...
What's worse tho, is that 64bit windows is over 10 years behind the first 64bit OS, despite running (in a limited fashion, not taking advantage of 64bit features) on 64bit hardware since early releases of NT (mips, alpha etc)
I also have an original SBLive card, which works perfectly under 64bit linux, but none of the 64bit versions of windows seem to support it... It also works on 64bit linux on a 64bit alphastation.
I have the same issue with old tulip 10/100 network cards, no 64bit windows supports them, even tho the cards were designed for 64bit machines, and are well supported by tru64 and openvms on the alpha.
Glide was a dedicated gaming API, specifically tailored to the voodoo hardware...
OpenGL on the other hand, is a more general purpose graphics API designed to run on a wide range of hardware, and is designed for quality rather than gaming performance.
Yes, there was a glide emulator...
I remember people using it to run UltraHLE (the N64 emulator, which only supported glide) on non voodoo cards.
Yes, indeed...
I had the good fortune to play glquake on an SGI Onyx connected to a 24" screen via 13W3 (shielded cable) back in those days, it put the voodoo cards to shame.
Someone on the linked forum made a joke about Amiga drivers for the voodoo boards...
They're even still being sold!
http://www.vesalia.de/e_mediator.htm
It's better to have something that works well when it's ready, than to have a rushed half assed job that's ready much earlier, but doesn't do the job...
Especially in the military, would you want hurriedly built planes falling apart over enemy territory?
The trunking is a feature of the phone, not of the backend PBX software...
You can use cisco phones with asterisk, i`m using a 7960 at home with multiple asterisk servers (the 7960 has support for 6 "lines"), and the vlan trunking works on it, although i don't use it at home...
Many of the Nortel phones support trunking too, tho i can't speak for any of the other vendors.
In terms of the backend, linux will also support trunking if you need such a facility on the backend.
Packet filtering capabilities should be an integral part of every TCP stack, the fact that a market has grown up around providing these features to an OS which lacks them is ridiculous, and such a market deserves to cease to exist...
When it comes to anti-spyware and anti-virus, these are both a bad idea in any case... It's foolish to allow this malware onto your machine and then try to remove it. Microsoft should be improving the OS so it's more resillient to such things, and therefore has no need for additional packages to remove them.
Conversely, if microsoft have a dominant antivirus/antispyware package, then they may aswell not have one at all, because malware authors will have a single target to aim at, and will quickly develop standard ways to evade and/or neuter these packages.
There is a project called x86abi which aims to meet these needs, however it's not very far along in it's development and could do with some support...
http://www.x86abi.org/
Well, i`m sure they could, but that would enable competitors to compete more effectively...
It's much easier to lock users in to a crap proprietary product than it is to make your product actually stand on it's merit.
It worked for Apple, OSX is a huge step up from OS9....
Nowadays, with virtualization built in to modern processors, it's a good time to scrap backwards compatibility and let one (or more) instances of legacy systems run within virtualization.
This would not only remove the legacy cruft from the main OS, but would enable you to run old apps that break on current versions of windows too.
If you keep the UI the same, then people won't upgrade.
To the average end user, that's all they see, and couldn't care less about what goes on underneath.
Itanium is a different matter, because EFI is the default firmware on an itanium box and so there was no choice.
But you bring up an interesting point, they clearly had the code to support EFI but just didn't use it.
Windows has pretty good power management functions in many ways, but they aren't very flexible...
In particular, windows is very keen on accessing the disk, to the extent that the disk is often kept spinning constantly under normal use... Linux however, supports "laptop mode" whereby any writes to the disk are cached and delayed (potentially dangerous, but you know how much battery life you have so theres no chance of a power cut) and either written when the disk is forced to spin up anyway (for a read etc) or at a set time (spin up, write, spin down)...
With reads too, it can do readahead so it reads in more data than necessary and caches it, so it has to spin up the disk and read less often.
Also, cpu frequency scaling seems to be more flexible, you can set the cpu clock to a particular rate, or put it in automatic powersave/ondemand/performance modes.
Actually, Intel designed and published the ACPI specs, and produce a reference interpreter and compiler for the DSDT...
Seeing as how close Intel and Apple are nowadays, i would imagine Apple's ACPI implementation complies with Intel's specs.
On the other hand, Microsoft make their own compiler which has many subtle differences from Intels, in particular it has an ability to ignore many errors that violate the spec and are thus flagged by Intel's compiler. Their implementation of ACPI implements the same tollerence of errors as their compiler, so the two work together well.
The disadvantage for the rest of us, is that microsoft have never published the changes they made to the ACPI spec, and many systems compiled using their compiler will fail to work on a fully standards compliant ACPI interpreter.
You would imagine that Apple, not being in posession of microsoft's internal documentation regarding their version of ACPI, would choose to use the official Intel spec, which is readily available from their site.
EFI? Future? EFI has been around for years, however microsoft never bothered to support it so no motherboard manufacturers implemented it either.
Apple only used it because they had their own OS, and therefore didn't have to wait for microsoft to support anything.
It has already been confirmed that vista will not support EFI, so you'l be waiting several years for another version of windows that does.
Other questions that do arise however, how proprietary is EFI? can other vendors produce clones of it, or are they tied to intel in some way?
But there still needs to be facilities to load drivers into the kernel, and there will almost certainly be bugs found which may result in malicious kernel modules being loaded.
You could also put the disk in another machine, and modify the kernel on disk before booting it...
Well, that's no true test of 64bit, that's a comparison of 2 processors...
Why not try running a 64bit and 32bit os side by side on identical hardware.
Not that it's worth it, 64bit xp is laughable right now, and there's really no point using it, which is why noone does.