Funny you should bring up package management... Linux may have lots of different package managers, but within the same distro the package management remains the same. Contrast that to commercial unixes, where many third party proprietary apps have their own nonstandard installers... Or windows, where virtually all apps have their own nonstandard binary installers. Or OSX where some apps drag+drop, some use apple's installer and some use their own installers. If you consider each distro as an OS in it's own right, then most linux based systems have it a lot better. Certainly the big distros have pretty consistent package management.
Why can't media cards compete with UMD? That's not an irrelevant comparison at all. Media cards are superior to UMD, because theyre writeable, larger capacity and smaller. UMD cannot compete with media cards because it's not writeable... Media cards however can do anything UMD can and more, they are a superior alternative.
Ubuntu hasn't been fixed... They implemented a kludgy workaround to get around microsoft's buggy DSDT compiler. The DSDT in your laptop is still broken, and Ubuntu is now broken-by-design to try and cope with the broken DSDT. Saying Ubuntu got fixed is effectively blaming Ubuntu for a problem which was never of their causing.
Developers who should be working on improving standards support, are instead spending their time trying to improve compatibility with IE bugs. Firefox is more or less equal to other modern browsers in standards support (IE stands out by being hugely behind everything else) And finally, if the most common browser doesnt support something no web developers will use it anyway because a big chunk of their audience wont be able to see it, so there is little practical value in other browsers pulling even further ahead of IE.
The guy 5 years ago should not have been permitted to make such a stupid mistake. Similarly, you should not be permitted to make a serious mistake that will have repercussions 5 years after you've left. Had there been a proper risk assessment process in place 5 years ago, you'd not be in trouble now. And it should be your job to clean up the mess, not just create a new one that your replacement will have to clean up in a few years time. If it causes a lot of disruption, and costs a lot to fix, perhaps they will be more vigilant about preventing it happening again.
So your saying that these legacy apps do such ridiculous things that it's simply not possible to describe their behaviour using the standard formatting options available on ODF/OOXML?
Or do they just do simple things, like slightly reduce font sizes, or adjust line spacing etc... Things like this are trivially easy to handle during conversion to a new format, simply change the appropriate option in the new file as you convert and the output will look the same as the input, although the programs will show different font sizes etc, they will actually look the same because the older program is buggy.
And converting back is just the same, if you know what format your converting to you can do the size conversions in reverse.
Microsoft were invited to join the ODF process, and refused. This is because they wanted to maintain the status quo as long as possible...
Other standards they participated in were already established, and thus they had no choice. With ODF they preferred to ignore it and hope it would go away, had they supported it then the migration to ODF format would be in full swing right now, and the biggest reason people keep using msoffice would have been eliminated.
As for supporting legacy documents, that is not the business of the file format, that is the business of the conversion program. It's utterly ridiculous to use such vague tags as "format like word 95" in a modern format, and this does nothing to improve support.
Did word 95 and similarly old kludgy apps do something so ridiculous with it's formatting that it cannot be described in current formats? Why can't the conversion process simply convert the word95 formatting into an equivalent representation?
And if it did do something so stupid, why not have a tag that describes the actual behaviour, instead of something vaguely referencing an external program? Someone may have a need/desire to implement the same behaviour in new documents. Conversely, if this behaviour is nothing special that can't be described using the existing formatting functions of the format, why does it needs its own tag?
Why do legacy documents need to be prserved explicitely within the format? Is the format somehow inadequate that it has no other method of specifying word 95 compatible formatting? As an example, one of the issues i read about was that some old version of word would use a font 2 points smaller when "small caps" was turned on, surely the conversion process could simply reduce the font size within the output file, rather than having to use an explicit backwards compatibility kludge? There's no sense in polluting a new format with crap like that. Compatibility with older formats belongs in the converter, not the format spec.
You've also forgotten the formula issues disclosed recently, where the spec doesn't fully document how formulae should be handled.
It's your fault for getting locked in to proprietary products in the first place. You bought proprietary products over which you have no control, no guarantee that support will continue to be provided and no alternative supplier. The company providing it went bust, and now your screwed. You've nowhere to get fixes from, and because you didn't demand something interoperable and replaceable in the first place, you're now faced with a costly migration. And the fact your running this proprietary application on a proprietary os (windows) means that you've made this mistake more than once.
Face it, you shouldnt use any application without doing a proper risk assessment first. You need to have multiple sources for the app and/or drop in replacements... You need to have a continued avenue for support, even if you have to hire contract programmers to work on the code (and thus you should always get the source).
Getting locked in to something only available from one vendor is a huge risk, how long before businesses start doing proper risk assessments for things like this?
They need to publish a complete and standardised set of APIs, and then any third party software which complies with the published APIs will continue to work, *or* the change in API will be noted and it can be stated up front. Instead, Microsoft documentation is often poor and incomplete, resulting in third party developers having to guess.
If Microsoft would be up front and transparent, they could legitimately pin any failures on third parties for not following the specs closely enough.
It's better than that... They removed the IE based rendering engine, that has been so completely battered with security holes there can't be too many left yet, in favour of the word one which is just starting to be attacked, and is based on much older kludgier code.
Your right, it *shouldnt* matter. If all browsers complied with standards, it wouldnt make any difference which one you were using. That's why people are against IE, which doesnt comply with standards. It's goal is to force people to use it, by getting sites rewritten in a nonstandard way such that they don't work with standards compliant browsers. Aside from that, even if you do make a standards compliant site, IE is so far behind other browsers, that if you want to use any of the more modern technologies you either have to write nasty kludges, or exclude IE users from your site. And for the same reason, you have to test your sites first in a proper browsers, and again to make sure IE doesnt break them horribly, and then implement the aforementioned kludges.
Encryption is actually a really amusing example... How the hell can anyone possibly trust a proprietary implementation of encryption?
Do they use a proprietary cipher? Can you be sure this cipher is cryptographically secure? How can you possibly be without having a cryptographer *YOU* trust, and who has no vested interest in the vendor, analyse it. Even if they use a standard cipher like DES or AES, how can you be sure it's been implemented correctly? Simple errors when implementing an encryption cipher can render even the strongest of ciphers worthless. And how about all the ancillary stuff, like how the keys and salts etc are derived, are they doing this in a secure way? To give a simple example, what if they only take the first 2 characters from your password for use as the key, or if they convert your password to lowercase etc, anything like this significantly reduces the available keyspace.
So how can you trust a vendor who's trying to sell you an encryption product? Because the *tell* you it's secure? Because they paid a cryptographer to say the same thing? The only way to know for sure, is to have someone who has the necessary skills and who you trust analyse the code. This is easy with open source, but difficult or impossible with proprietary. Aside from that, if any open source product becomes popular enough (eg OpenSSL) then skilled people will have already looked at the implementation.
Just look how Adobe got caught out using ROT13, how do you know that any of the proprietary encryption products out there don't use something like ROT13 or worse?
They identify themselves differently in the user-agent strings sent to web servers, which means some browser-sniffing code rejects you because it doesn't know what "ice weasel" is... It's the same reason that IE pretends to be an ancient version of mozilla.
ODF references an external spec for formulas, IE the "OpenFormula" spec, which is also available from oasis-open.org Just like it references some other open specs for other parts, it makes no sense to reinvent the wheel.
Whats worse is that... There is a standard for these ACPI scripts, as you pointed out it's not great but at least there is one. There's also a compiler for them, written by Intel that complies with the standard. But most hardware makers don't use Intel's compiler that complies with standards... They use Microsoft's compiler that completely breaks the standards, thus OS authors can't just implement according to Intel's published standards, they have to reverse engineer Microsoft's unpublished variations.
Well, lower powered cards are usually more than capable of playing older games. And there's plenty of benefits to having older games nowadays. New games are often incredibly buggy, and receive several updates over their lifespan. If you play older games, then those updates have already happened so your experience of the game won't be so buggy as the early adopters. Plus, there are more likely to be nocd cracks available, so you don't have to deal with keeping physical media around all the time. And finally, older games are often to be found in bargain buckets for a fraction of the cost of their newer brethren (assuming you actually buy them in the first place). All of the above, plus the fact older games are no less playable (and often moreso) than newer ones.
For a search engine, you don't want users spending a long time looking at your site. The longer they spend looking at your site, the less effective your search engine is because the users had to spend longer looking for whatever it is they're after. As such, a metric like this is irrelevant, and the number of visits (and shortness of visits) is actually a far more valid way to measure search engines.
Current versions of software are GPLv2, future versions will be GPLv3... Novell are bound to update their distro to include newer versions in the future, or else face being left behind by all the other distros. They are not retroactively applying the license, Novell will be updating their product and including with the new update, new licensing terms. Microsoft's coupons cover the SUSE Enterprise distributions and updates, they don't specify a particular version, and nor do they have an expiry date.
Well, those of us who don't want to play the latest games in the highest resolutions, that is the majority of people... Someone will come out with lower powered budget versions.
Only UMD disks are not small, compared to all the myriad of media card formats... I can get a 2GB MiniSD card for $10, which is a fraction of the size of a UMD disk. What exactly are they trying to compare to?
But a pointless one... You can now get 2GB MicroSD cards, which are absoloutely tiny... I'm sure the slightly larger SD cards come in sizes over 4gb, enough for a full DVD, and even full size SD cards are physically smaller than UMD or nintendo's cartridge format... So why not just use standard media cards, like the ones mentioned above or one of the other types?
Slashdot Mirror
Funny you should bring up package management...
Linux may have lots of different package managers, but within the same distro the package management remains the same.
Contrast that to commercial unixes, where many third party proprietary apps have their own nonstandard installers...
Or windows, where virtually all apps have their own nonstandard binary installers.
Or OSX where some apps drag+drop, some use apple's installer and some use their own installers.
If you consider each distro as an OS in it's own right, then most linux based systems have it a lot better. Certainly the big distros have pretty consistent package management.
Why can't media cards compete with UMD? That's not an irrelevant comparison at all.
Media cards are superior to UMD, because theyre writeable, larger capacity and smaller.
UMD cannot compete with media cards because it's not writeable...
Media cards however can do anything UMD can and more, they are a superior alternative.
Ubuntu hasn't been fixed...
They implemented a kludgy workaround to get around microsoft's buggy DSDT compiler.
The DSDT in your laptop is still broken, and Ubuntu is now broken-by-design to try and cope with the broken DSDT.
Saying Ubuntu got fixed is effectively blaming Ubuntu for a problem which was never of their causing.
Firefox should support more that's true, however:
Developers who should be working on improving standards support, are instead spending their time trying to improve compatibility with IE bugs.
Firefox is more or less equal to other modern browsers in standards support (IE stands out by being hugely behind everything else)
And finally, if the most common browser doesnt support something no web developers will use it anyway because a big chunk of their audience wont be able to see it, so there is little practical value in other browsers pulling even further ahead of IE.
The guy 5 years ago should not have been permitted to make such a stupid mistake.
Similarly, you should not be permitted to make a serious mistake that will have repercussions 5 years after you've left.
Had there been a proper risk assessment process in place 5 years ago, you'd not be in trouble now. And it should be your job to clean up the mess, not just create a new one that your replacement will have to clean up in a few years time.
If it causes a lot of disruption, and costs a lot to fix, perhaps they will be more vigilant about preventing it happening again.
So your saying that these legacy apps do such ridiculous things that it's simply not possible to describe their behaviour using the standard formatting options available on ODF/OOXML?
Or do they just do simple things, like slightly reduce font sizes, or adjust line spacing etc... Things like this are trivially easy to handle during conversion to a new format, simply change the appropriate option in the new file as you convert and the output will look the same as the input, although the programs will show different font sizes etc, they will actually look the same because the older program is buggy.
And converting back is just the same, if you know what format your converting to you can do the size conversions in reverse.
Microsoft were invited to join the ODF process, and refused. This is because they wanted to maintain the status quo as long as possible...
Other standards they participated in were already established, and thus they had no choice. With ODF they preferred to ignore it and hope it would go away, had they supported it then the migration to ODF format would be in full swing right now, and the biggest reason people keep using msoffice would have been eliminated.
As for supporting legacy documents, that is not the business of the file format, that is the business of the conversion program. It's utterly ridiculous to use such vague tags as "format like word 95" in a modern format, and this does nothing to improve support.
Did word 95 and similarly old kludgy apps do something so ridiculous with it's formatting that it cannot be described in current formats? Why can't the conversion process simply convert the word95 formatting into an equivalent representation?
And if it did do something so stupid, why not have a tag that describes the actual behaviour, instead of something vaguely referencing an external program? Someone may have a need/desire to implement the same behaviour in new documents. Conversely, if this behaviour is nothing special that can't be described using the existing formatting functions of the format, why does it needs its own tag?
Why do legacy documents need to be prserved explicitely within the format?
Is the format somehow inadequate that it has no other method of specifying word 95 compatible formatting?
As an example, one of the issues i read about was that some old version of word would use a font 2 points smaller when "small caps" was turned on, surely the conversion process could simply reduce the font size within the output file, rather than having to use an explicit backwards compatibility kludge?
There's no sense in polluting a new format with crap like that. Compatibility with older formats belongs in the converter, not the format spec.
You've also forgotten the formula issues disclosed recently, where the spec doesn't fully document how formulae should be handled.
It's your fault for getting locked in to proprietary products in the first place.
You bought proprietary products over which you have no control, no guarantee that support will continue to be provided and no alternative supplier. The company providing it went bust, and now your screwed. You've nowhere to get fixes from, and because you didn't demand something interoperable and replaceable in the first place, you're now faced with a costly migration. And the fact your running this proprietary application on a proprietary os (windows) means that you've made this mistake more than once.
Face it, you shouldnt use any application without doing a proper risk assessment first.
You need to have multiple sources for the app and/or drop in replacements...
You need to have a continued avenue for support, even if you have to hire contract programmers to work on the code (and thus you should always get the source).
Getting locked in to something only available from one vendor is a huge risk, how long before businesses start doing proper risk assessments for things like this?
They need to publish a complete and standardised set of APIs, and then any third party software which complies with the published APIs will continue to work, *or* the change in API will be noted and it can be stated up front.
Instead, Microsoft documentation is often poor and incomplete, resulting in third party developers having to guess.
If Microsoft would be up front and transparent, they could legitimately pin any failures on third parties for not following the specs closely enough.
But if your site doesnt work on browser X, then you'l never get many hits from that browser...
Much better would be to:
Code the site to open standards
*TEST* it in any browser that sees more than 5% usage
It should still work in any other browser, if the site follows open standards then it's the browser that is broken anyway.
It's better than that...
They removed the IE based rendering engine, that has been so completely battered with security holes there can't be too many left yet, in favour of the word one which is just starting to be attacked, and is based on much older kludgier code.
Your right, it *shouldnt* matter.
If all browsers complied with standards, it wouldnt make any difference which one you were using.
That's why people are against IE, which doesnt comply with standards. It's goal is to force people to use it, by getting sites rewritten in a nonstandard way such that they don't work with standards compliant browsers.
Aside from that, even if you do make a standards compliant site, IE is so far behind other browsers, that if you want to use any of the more modern technologies you either have to write nasty kludges, or exclude IE users from your site.
And for the same reason, you have to test your sites first in a proper browsers, and again to make sure IE doesnt break them horribly, and then implement the aforementioned kludges.
Tho one of the other things mentioned in the document says:
- Selection of solutions that provide greatest value for least cost
If the formats are open, it's only a matter of time before microsoft is given the boot and replaced with something cheaper.
Encryption is actually a really amusing example...
How the hell can anyone possibly trust a proprietary implementation of encryption?
Do they use a proprietary cipher? Can you be sure this cipher is cryptographically secure? How can you possibly be without having a cryptographer *YOU* trust, and who has no vested interest in the vendor, analyse it.
Even if they use a standard cipher like DES or AES, how can you be sure it's been implemented correctly? Simple errors when implementing an encryption cipher can render even the strongest of ciphers worthless.
And how about all the ancillary stuff, like how the keys and salts etc are derived, are they doing this in a secure way? To give a simple example, what if they only take the first 2 characters from your password for use as the key, or if they convert your password to lowercase etc, anything like this significantly reduces the available keyspace.
So how can you trust a vendor who's trying to sell you an encryption product? Because the *tell* you it's secure? Because they paid a cryptographer to say the same thing? The only way to know for sure, is to have someone who has the necessary skills and who you trust analyse the code.
This is easy with open source, but difficult or impossible with proprietary. Aside from that, if any open source product becomes popular enough (eg OpenSSL) then skilled people will have already looked at the implementation.
Just look how Adobe got caught out using ROT13, how do you know that any of the proprietary encryption products out there don't use something like ROT13 or worse?
They identify themselves differently in the user-agent strings sent to web servers, which means some browser-sniffing code rejects you because it doesn't know what "ice weasel" is...
It's the same reason that IE pretends to be an ancient version of mozilla.
ODF references an external spec for formulas, IE the "OpenFormula" spec, which is also available from oasis-open.org
Just like it references some other open specs for other parts, it makes no sense to reinvent the wheel.
Whats worse is that...
There is a standard for these ACPI scripts, as you pointed out it's not great but at least there is one. There's also a compiler for them, written by Intel that complies with the standard.
But most hardware makers don't use Intel's compiler that complies with standards... They use Microsoft's compiler that completely breaks the standards, thus OS authors can't just implement according to Intel's published standards, they have to reverse engineer Microsoft's unpublished variations.
Well, lower powered cards are usually more than capable of playing older games.
And there's plenty of benefits to having older games nowadays. New games are often incredibly buggy, and receive several updates over their lifespan. If you play older games, then those updates have already happened so your experience of the game won't be so buggy as the early adopters.
Plus, there are more likely to be nocd cracks available, so you don't have to deal with keeping physical media around all the time.
And finally, older games are often to be found in bargain buckets for a fraction of the cost of their newer brethren (assuming you actually buy them in the first place).
All of the above, plus the fact older games are no less playable (and often moreso) than newer ones.
For a search engine, you don't want users spending a long time looking at your site.
The longer they spend looking at your site, the less effective your search engine is because the users had to spend longer looking for whatever it is they're after. As such, a metric like this is irrelevant, and the number of visits (and shortness of visits) is actually a far more valid way to measure search engines.
Current versions of software are GPLv2, future versions will be GPLv3...
Novell are bound to update their distro to include newer versions in the future, or else face being left behind by all the other distros.
They are not retroactively applying the license, Novell will be updating their product and including with the new update, new licensing terms.
Microsoft's coupons cover the SUSE Enterprise distributions and updates, they don't specify a particular version, and nor do they have an expiry date.
Well, those of us who don't want to play the latest games in the highest resolutions, that is the majority of people...
Someone will come out with lower powered budget versions.
Only UMD disks are not small, compared to all the myriad of media card formats... I can get a 2GB MiniSD card for $10, which is a fraction of the size of a UMD disk.
What exactly are they trying to compare to?
But a pointless one...
You can now get 2GB MicroSD cards, which are absoloutely tiny... I'm sure the slightly larger SD cards come in sizes over 4gb, enough for a full DVD, and even full size SD cards are physically smaller than UMD or nintendo's cartridge format...
So why not just use standard media cards, like the ones mentioned above or one of the other types?
It creates pdfs without clickable links, and without a proper index...