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?
You're talking about a semantic issue. Your argument is basically the same as saying "Why do we need a bold tag in HTML, why can't we just specify a style that uses a heavier weight?" There are cases where there are semantic differences between small caps and merely using a smaller font style. Word processing documents are not just words with formatting (though many people treat them that way), they have tables of contents, links, indexes, styles, etc... semantic markup.
The whole point is to preserve the original semantic information, not do nasty (and lossy) conversions that destroy the original semantic content, which always has to make assumptions as to the meaning of those semantics. That's a process that will always be error prone, and in certain fields (legal, medical, etc..) that's simply not acceptable.
Let's take an example. Suppose you have 10,000 legal documents written in Word 95, and many of them use "small caps" to indicate a specific legal meaning. Now, let's convert the documents to ODF, and those "small caps" are merely converted to a smaller font. Ok, it may look the same, but what if I want to search through my document management systems for all documents that have terms with the specific meaning that small caps were meant to represent? If the documents are converted with that semantic information intact, I need only return all documents with 'small caps'. How do you do that with the converted document? You can't really.
That's the danger of conversion. Not all data is in the data.
Wrong. ODF and OOXML are not strictly word processing formats. They're *ARCHIVAL* formats as well. One reason for the choice of XML was so that third party applications can easily use them, such as document management systems. PDF just makes it more difficult for those apps to do their job. In a way, you're right though... and that's why Microsoft has developed XPS.. XML Paper Specification, to make it easier for DMS's and archives to work with such documents.
However, that doesn't change the fact that there are literally billions of legacy documents, and they need to be in a format that is both machine and *HUMAN* readable, PDF is not that.
Oh no, beware of the bloggers? Umm, it's Microsoft who got Peter Quin fired for using ODF.
No. The bloggers are merely the mouthpieces of their employers (just as Brian Jones and other Microsoft bloggers are for theirs), voicing their employers agenda. There's nothing to 'beware' of.
And for the record, Peter Quin wasn't just "using ODF", they were excluding Microsoft, likely in collusion with Sun. This is easily evidenced by the fact that early on Quin said that they'd consider Microsoft if they opened up their office format, because they didn't believe Microsoft would do so. They later backtracked on that promise when Microsoft did just that. I don't condone what Microsoft did in Mass, but I don't think Quin and Co were being honest either, or they would have lived up to the promises they made about considering Office when certain conditions were met, rather than outright pretending they never said it.
And how can they "make it hard for Microsoft" when there are several existing, open source applications that use ODF?
All of which, other than OpenOffice, are reduced functionality applications that make only partial use of ODF, and functionally are complete subsets of OOo. Office is not a subset of OOo, and it has features that OOo doesn't have, nor can be supported by the ODF spec.
Suppose you were a database vendor, like Oracle. Then, suppose your competitors got together and created a "standard" Database format, and that format was based on MySQL. Do you really expect that Oracle would be able to make their high end database product work in the MySQL format? Or the MSSQL format? Or the DB2 format? Unlikely.
There are plenty of ways to extend ODF with vendor-specific extensions.
Are you serious? You seriously don't believe that Microsoft wouldn't be roasted alive for "extending" ODF? That they'd be accused of perverting it, and trying to extinquish it? Wow.
Do they really need something like, say, yet another way of word-wrapping? (Maybe, but only if they want to preserve the internals of long-dead legacy applications in every format in the future... they DO have a formatLikeWord95 flag in there, and it's not alone). But while ODF is full of open standards, Microsoft stuffed every Microsoft proprietary "standard" into OOXML.
The difference is that Microsoft deprecated all that functionality. It *allows* it, but doesn't require it, nor does it recommend it's use. It's there strictly to support the *BILLIONS* of legacy documents that already exist, without wich conversion would be an impossible task. The whole point of an XML format is to make it more parsable by third party tools such as search engines and document management systems. If you can't convert the documents without fear of losing data, it makes those products useless for legacy archives.
As for why, haven't you read the Halloween memos?
Are you one of those people that actually believes that memo was anything other than an analysts opinion? I guess that explains a lot.
Ahh, C/C++ were well outside their control. And they didn't need to control the language itself, just to have their own Windows APIs to keep control. XML is similar. Also, just who do you think isn't a Microsoft competitor? I see that you left Java off of that list, too.
You missed the point. Microsoft still participated in those committees. What does Java have to do with anything anyways? It's a proprietary technology owned completely and totally by Sun. Even though they've now GPL'd it, they're still in control of it (until someone forks it, and that fork becomes dominant). What was your point, and how does it relate to this discussion?
And just what, pray tell, do you think they need that they can put in OOXML but not ODF? Unless you mean the garbage dump of legacy code represented by all those bugs they're carrying forward (the Excel date bug, the formatting quirks of every word processor format Office has ever been able to
What bullshit! Microsoft where asked to join in with the ODF Specs and they REFUSED!
Maybe you should read the whole comment before saying something so stupid. I specifically addressed that, and you seem to have ignored it.
They refused because it wasn't a genuine invitation. It's like when you invite the next door neighbor to your party so they can't complain about the noise, but you desperately hope they say no, and make plans to make them uncomfortable and sideline them if they actually do show up.
They invited them because they knew Microsoft would refuse, given the makeup of the working group, and who was in control of it. I mean, come on.. even the name of the group was biased. It was called the "Open Office XML Format Technical Committee" IBM, Sun, and Adobe employees make up almost half the membership of the committee.
Please don't play dumb. Regardless of where you stand on the OOXML issue, you have to know that Sun and IBM used OASIS as a tool in their fight against their #1 competitor. This is clearly obvious by simply reading the tone, and content of their blog entries. They see it as war, and are constantly fighting the adoption of OOXML despite the fact that Microsoft has never once done ANYTHING to stand in the way of the adoption of ODF, other than when OOXML was being excluded from consideration. Microsoft even voted for ODF standard acceptance. Playing dumb about this is just as disingenuous as IBM and Sun's attempts. Just admit it, and don't act all hurt that Microsoft saw through the charade.
You know as well as I do that Sun and IBM would not have allowed Microsoft to influence ODF in any meaningful way, so what purpose would there have been for them to participate?
So where are the "paginateLikeFrameMakerV2.73" (and similar... that particular version number was totally made up) tags in OOXML so I can retain my non-MS legacy documents?
Actually, there are such tags. For instance, suppressTopSpacingWP is there for Word Perfect documents and there's a date format that is there because of bug in Lotus 123. However, i doubt there is a gigantic legacy archive of framemaker documents out there, unlike word or excel documents.
Most of those legacy documents will not need to be edited, now, will they? So just converting them to PDF would be sufficient.
PDF is a far more complex format than either OOXML or ODF. It requires a postscript engine to translate. One of the big wins of ODF and OOXML is that XML documents are easily indexed by search engines, something that is significantly harder to do with PDF.
If they wanted to do something good for the customers, they wouldn't just be using OpenDocument, they'd join the group developing it.
You know as well as I do that the offer by Oasis for Microsoft to participate is disingenuous. The group is dominated by Microsoft's competitors who would do everything in their power (as evidenced by the blog articles they write on a daily basis, and legal maneuvering they keep coming up with) to sideline and make their participation in the group moot.
I believe that Microsoft would have participated in ODF if they believed their requirements for a file format would be met (ie. one that would support legacy documents and allow 100% document fidelity). I am certain they believed that participating in the Oasis group would have been a pointless exercise in futility, and they would end up with the same useless (to them, because it won't represent legacy documents) spec they have now.
You'll want to spin this as a power struggle, and claim that Microsoft wouldn't participate because they would not have been abke to control things. To that, i counter that Microsoft has participated in many standards, such as C, C++, XML itself, etc.. all without control over the working group. But the difference here is that the ODF committee was, by nature of it's makeup consisting almost entirely of their competitors, deliberately hostile to Microsoft.
It's no surprise they decided not to participate, and develop their own XML format. ODF was never intended to support Office, and was likely positioned to make it difficult for Microsoft to do so.
You really have to look at this from the political aspect, as well as the technical one. Read between the lines.
I'm not saying that OOXML is a great format. In fact, I think it sucks. But it does something ODF doesn't, and was deliberately prevented from doing, and something that is vitally important to the success of an open format, and that's legacy documents support.
If they wanted to do something good for their customers they would be using ODF, which is a complete, reasonable and free standard.
I'm sorry, are we talking about the same ODF here? Even OASIS doesn't agree with you, as they've already set up 2 working groups to address the incompleteness of it, namely accessibility and formulas. The one piece they still haven't addressed is legacy documents from Microsoft, Word Perfect, Lotus, and others, which is a HUGE problem for anyone that will want to convert their archive of documents to an open standard.
Other than the Accessibility and formula issues, I agree that ODF is a great office file format for new documents, but it's a royal pain in the ass if it's your job to keep legecay documents identical while converting to the new format.
The purpose they serve is to provide a means for converted legacy documents to retain information that would otherwise be lost. Those fields are deprecated, not just optional, and are actively suggested that they NOT be implemented. They're not intended to be used in any NEW documents, and I find it highly unlikely that Microsoft would let any apps create deocuments with them. It's pure paranoia, fear mongering, and FUD to suggest what you are suggesting.
The fact is that ODF, while a great office format for new documents, falls flat on its face when it comes to preserving legacy documents, something that is required by LAW in many cases. The whole purpose of the new file format standards is to allow documents to be read long after the applications that created them are dead and buried. ODF forgets about legacy documents, which means that unless a document converts perfect, or you hire a lot of staff to reformat documents that don't convert correctly, you're stuck keeping them in proprietary formats if you want to meet your archival responsibilities. ODF, and it's proponents, ignore this vital issue.
If OASIS had considered this problem, and addressed it in ODF, say by allowing application defined supplmentary tags for legacy support purposes, then this might never have been an issue. But by ignoring the legacy documents out there, they left the door wide open for Microsoft to argue this side of things and draw support.
There are many factors that define the performance of an OS. One of them is the number of features it provides, and another is the timetable in which said features are delivered. Yet another is legacy compatibility.
BeOS was new. It didn't have to be compatible with anything. But give it 10 years, and 2 Gazillion hacks to let old software continue to work. Give it hundreds or thousands of features, many of which are probably no longer even used by many people, but still have to be there because some small subset needs them. Give it features built upon other features and security patches upon other patches.
Commercial software vendors seldom have the ability to ship software when it's ready, they have to meet timelines. Look at OS X, each new release cycle takes longer and longer because as the OS matures, it takes more and more time to wade through the existing code to change it. It gets slower because more conditionals have to be added to check for compatibility or security issues, or because it needs to do more than it used to.
Linux (the kernel), on the other hand, seems to get better and better, faster and faster, with each new release. There is a reason for that, though. No commercial pressure to release, they can set an arbitrary release date and simply ship whatever features are ready, and do so relatively frequently because they don't have to worry about a large and complete OS release, just the kernel.
Distro vendors, on the other hand, seem to be taking longer and longer between releases (not counting Debian, which has always been glacial), because as the body of software grows, it takes more and more work to maintain it. Distro quality depends largely upon how long they spend stabilizing releases.
The important thing to keep in mind is that BeOS was not a mature OS. In many ways, they had done just enough to get it going. My guess is that once they had the resources, it would have fattened up to the size of OSX or Windows easily, and all that performance you saw when it was young and new would go out the window.
BeOS had a lot of problems as well, for instance the OS was written in C++, which meant that when you wrote drivers, they had to be in C++. The software loaded fast, because it wasn't very mature. It was like loading notepad or kedit. Simple and easy, but once big apps were running on it, they wouldn't be quite so snappy as they loaded in the dozens or maybe even hundreds of components.
Apart from the corrections already brought up, the Amiga was rife with limitations and problems of its own. It worked great in the narrow range that it was designed for, but had all kinds of other issues. For example, upgrading the video was a hack job that usually require patching the ROM libraries with ones that new about the new video hardware. It was tightly integrated, which meant doing anything outside what it was designed for was often difficult and expensive.
And I was an amiga fanatic. And, while I held out hope that Commodore would get their act together and provide the features that were rumored and needed (DSP's, retargetable graphics, etc..) I always knew it would never happen. If only Dave Haynie had been allowed to do what he wanted, but then again that probably would have made it too expensive for people to buy.
Office 2007 will save any document you open in it's original format, thus if you open an.doc file from 2003, then click save, it will re-save it in 2003 format. You have to explicitly tell it to save in.docx to get it to upgrade the format. You really don't know what you're talking about if you make this claim.
What's even more, when you install any version of Office since Office 2000, unless you tell it to delete the old version (it asks you specifically), it will install side-by-side versions, and you can run both simultaneously. I've been on the beta programs, and had to use both, so I know this to be true. There was a weird bug in Office 97 that didn't allow 2000 and 97 to be used simultaneously without some hacking, but this hasn't been true of any version since.
As for Outlook, i've downgraded PST files from both Office 2007 and Office 2003 to earlier versions without any kind of trouble, so I don't know what the author of the article is talking about. The only problem is with unicode versions, but that's a choice you can make to upgrade to that.
So doesn't this mean that smbfs is now dead? Or stuck at 3.0.x? Since the Linux kernel will not be going GPLv3, from my understanding of what Linus has said.
There are many reasons to be against this sort of thing. Cost has been said already. It's forcing states to pay for this, without funding it federally. Second, this country has been against a national ID card for decades. In fact, Social Security was guaranteed to not be used as a national ID card. The fear is that the government can track your every move with this card, as it will be required by more and more services. Currently, state ID cards are not linked to the government in any meaningful way. Yeah, they can look up your data, but that's about it. With a single, computerized ID system, every time you make a purchase that requires your ID (Cigarettes, alcohol, porn) can be recorded. Every time you get on an airplane, the government knows about it. They can datamine so much information about you, that your privacy is effectively nil.
Yes, we're already a computerized society, and they can already do a lot of this. That's bad, but the disparate nature of the databases makes doing such searches difficult and expensive, thus relegating it to important suspects. With this information at the governments fingertips, the cop that pulls you over for 'speeding' could see everywhere you've used your ID. Maybe take you downtown for questioning because you happen to go to the same night club as a wanted fugitive. Or maybe he's a bible thumper and wants to "punish" you for some blight against his beliefs on your record.
Is all that Paranoid? You bet. But the best defense of your privacy is to not allow people to have access to it, regardless of whether it's for the "greater good" or not. You're privacy is not private if the government has access to it, regardless of whether you think you have anything to hide or not.
While I agree with you in principle, I disagree with the argument that civilians cannot hope to defeat the government because of mismatch in firepower. I think Iraq has shown, without a doubt, that even highly trained and well equiped soldiers are no match for sheer numbers of people, and the average american has access to a lot more firepower than the average iraqi.
Also, the military is made up of the people. There will be many deserters or outright mutiny if the revolution were large enough.
Not that i'm encouraging such a thing, but should such an event occur, unless the US were willing to nuke it's own people, it could very well succeed.
The problem is, despite everything else, most people are comfortable. It takes a lot of uncomfortable people to get a good revolution. Downtrodden, completely depressed people. And it takes an organized, and charasmatic leader.
I'm not sure why you think the article is by someone unidentified. It was written by Adam Barr, one of the networking guys at Microsoft involved with the TCP/IP stack up until 2000, then he left Microsoft and wrote a book called "Proudly serving my corporate masters" about working for Microsoft, he was then later rehired a few years later and is still working there as far as I can tell.
Key phrases you may have missed:
"So, a short time after this, work was begun on a new version of TCP/IP, written entirely by Microsoft. "
That's not an implication, that's an outright statement, made by someone that is authoritative.
here's another:
"Eventually the new, from scratch TCP/IP stack was done and shipped with NT 3.5 (the second version, despite the number) in late 1994. The same stack was also included with Windows 95. "
Again, not an implication, an outright statement.
He does say, at the time, that since he no longer worked for Microsoft, he couldn't guarantee there was currently no BSD code in there, but it's quite clear that as of when he quit, there wasn't anything substantial that could be classified as having a BSD origin.
But all that is really beside the point, as first you claimed that Microsoft wrote their first stack for NT and that it sucked and they had to replace it with a BSD stack in windows 2000. None of that is true. The BSD stack sucked (largely because it was STREAMS based) and was replaced with rewritten code.
You're not making any sense here. The real history is that when Microsoft released Windows NT, Novell *REFUSED* to write a client for it. Microsoft was forced to write their own client for interoperability. It wasn't until later that Novell decided to try and play nice, but their client was so intrusive, replacing core DLL's that it made things an unstable mess.
The netware client on NT eventually got better, but it took a long time. I would not call that "stable".
Actually, no. Windows used the BSD based stack (licensed from spider software, who in turn paid UC Berkeley for a license, so it wasn't stolen) up until Windows 2000, then it rewrote the stack from scratch, according to this article:
Actually, that's not true. The GPL gives you a single right that you did not have before, that is to distribute unchanged or modified versions of a piece of software governed by the GPL. However, as a result of agreeing to the GPL and gaining that one right, you lose several other rights, for a net negative right loss.
The rights that you lose are the ability to distribute code you have developed under any license you choose (when that code is deemed a derivitive of the GPL'd work, which includes merely linking to the code in question). You lose the right to enforce any patents you may own on that code. You lose the right to control distribution and the right to control use. You also lose the right to control translations into other languages, and the right to control who may derive from your work. And, of course, you lose the right to control who gets your source code.
In the above, i'm referring to code that is entirely written by you that merely links to GPL'd code, not where you have taken someone elses code and modified it.
I'm not saying that's a bad thing, i'm merely saying that the argument that you have more rights because of the GPL is not very well thought out.
Actually, the GPLv3 is starting to get into use scenarios. For example, the whole TiVoization clause relates to how the softwware is used. DRM and Patents effect use as well, although these things still apply to distribution, it's blurring the boundaries.
Also, shrink wrapped licenses have been upheld in court so long as a method of returning the software if you don't agree with the license for a full refund is available.
I keep seeing this comment, but it's a bit disingenuous. Yes, it's true that the first evaluation for NT4 required those things, but a secondary review in 1999 allowed NT4 to retain those items. In other words, NT4 did in fact achieve full C2 with networking and floppy.
Uhh.. what are you referring to? There hasn't been any IIS related malware (virus or worm) for over 5 years.
Also, Netcraft counts host names, not servers. There is no current information on how many servers are IIS versus Apache, but netcraft information on physical server market from around 2001 indicates that with similar hostname ratios as today IIS had about 50% of the server marker.
I find that thought very suspect, for a lot of reasons.
The biggest is that Microsoft wasn't the only one involved in the early networking. IBM was as well. LanMan was a joint effort, and I find it highly unlikely that IBM would need Novell's assistance to make networking work correctly.
Slashdot Mirror
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?
You're talking about a semantic issue. Your argument is basically the same as saying "Why do we need a bold tag in HTML, why can't we just specify a style that uses a heavier weight?" There are cases where there are semantic differences between small caps and merely using a smaller font style. Word processing documents are not just words with formatting (though many people treat them that way), they have tables of contents, links, indexes, styles, etc... semantic markup.
The whole point is to preserve the original semantic information, not do nasty (and lossy) conversions that destroy the original semantic content, which always has to make assumptions as to the meaning of those semantics. That's a process that will always be error prone, and in certain fields (legal, medical, etc..) that's simply not acceptable.
Let's take an example. Suppose you have 10,000 legal documents written in Word 95, and many of them use "small caps" to indicate a specific legal meaning. Now, let's convert the documents to ODF, and those "small caps" are merely converted to a smaller font. Ok, it may look the same, but what if I want to search through my document management systems for all documents that have terms with the specific meaning that small caps were meant to represent? If the documents are converted with that semantic information intact, I need only return all documents with 'small caps'. How do you do that with the converted document? You can't really.
That's the danger of conversion. Not all data is in the data.
Wrong. ODF and OOXML are not strictly word processing formats. They're *ARCHIVAL* formats as well. One reason for the choice of XML was so that third party applications can easily use them, such as document management systems. PDF just makes it more difficult for those apps to do their job. In a way, you're right though... and that's why Microsoft has developed XPS.. XML Paper Specification, to make it easier for DMS's and archives to work with such documents.
However, that doesn't change the fact that there are literally billions of legacy documents, and they need to be in a format that is both machine and *HUMAN* readable, PDF is not that.
Oh no, beware of the bloggers? Umm, it's Microsoft who got Peter Quin fired for using ODF.
No. The bloggers are merely the mouthpieces of their employers (just as Brian Jones and other Microsoft bloggers are for theirs), voicing their employers agenda. There's nothing to 'beware' of.
And for the record, Peter Quin wasn't just "using ODF", they were excluding Microsoft, likely in collusion with Sun. This is easily evidenced by the fact that early on Quin said that they'd consider Microsoft if they opened up their office format, because they didn't believe Microsoft would do so. They later backtracked on that promise when Microsoft did just that. I don't condone what Microsoft did in Mass, but I don't think Quin and Co were being honest either, or they would have lived up to the promises they made about considering Office when certain conditions were met, rather than outright pretending they never said it.
And how can they "make it hard for Microsoft" when there are several existing, open source applications that use ODF?
All of which, other than OpenOffice, are reduced functionality applications that make only partial use of ODF, and functionally are complete subsets of OOo. Office is not a subset of OOo, and it has features that OOo doesn't have, nor can be supported by the ODF spec.
Suppose you were a database vendor, like Oracle. Then, suppose your competitors got together and created a "standard" Database format, and that format was based on MySQL. Do you really expect that Oracle would be able to make their high end database product work in the MySQL format? Or the MSSQL format? Or the DB2 format? Unlikely.
There are plenty of ways to extend ODF with vendor-specific extensions.
Are you serious? You seriously don't believe that Microsoft wouldn't be roasted alive for "extending" ODF? That they'd be accused of perverting it, and trying to extinquish it? Wow.
Do they really need something like, say, yet another way of word-wrapping? (Maybe, but only if they want to preserve the internals of long-dead legacy applications in every format in the future... they DO have a formatLikeWord95 flag in there, and it's not alone). But while ODF is full of open standards, Microsoft stuffed every Microsoft proprietary "standard" into OOXML.
The difference is that Microsoft deprecated all that functionality. It *allows* it, but doesn't require it, nor does it recommend it's use. It's there strictly to support the *BILLIONS* of legacy documents that already exist, without wich conversion would be an impossible task. The whole point of an XML format is to make it more parsable by third party tools such as search engines and document management systems. If you can't convert the documents without fear of losing data, it makes those products useless for legacy archives.
As for why, haven't you read the Halloween memos?
Are you one of those people that actually believes that memo was anything other than an analysts opinion? I guess that explains a lot.
Ahh, C/C++ were well outside their control. And they didn't need to control the language itself, just to have their own Windows APIs to keep control. XML is similar. Also, just who do you think isn't a Microsoft competitor? I see that you left Java off of that list, too.
You missed the point. Microsoft still participated in those committees. What does Java have to do with anything anyways? It's a proprietary technology owned completely and totally by Sun. Even though they've now GPL'd it, they're still in control of it (until someone forks it, and that fork becomes dominant). What was your point, and how does it relate to this discussion?
And just what, pray tell, do you think they need that they can put in OOXML but not ODF? Unless you mean the garbage dump of legacy code represented by all those bugs they're carrying forward (the Excel date bug, the formatting quirks of every word processor format Office has ever been able to
What bullshit! Microsoft where asked to join in with the ODF Specs and they REFUSED!
Maybe you should read the whole comment before saying something so stupid. I specifically addressed that, and you seem to have ignored it.
They refused because it wasn't a genuine invitation. It's like when you invite the next door neighbor to your party so they can't complain about the noise, but you desperately hope they say no, and make plans to make them uncomfortable and sideline them if they actually do show up.
They invited them because they knew Microsoft would refuse, given the makeup of the working group, and who was in control of it. I mean, come on.. even the name of the group was biased. It was called the "Open Office XML Format Technical Committee" IBM, Sun, and Adobe employees make up almost half the membership of the committee.
Please don't play dumb. Regardless of where you stand on the OOXML issue, you have to know that Sun and IBM used OASIS as a tool in their fight against their #1 competitor. This is clearly obvious by simply reading the tone, and content of their blog entries. They see it as war, and are constantly fighting the adoption of OOXML despite the fact that Microsoft has never once done ANYTHING to stand in the way of the adoption of ODF, other than when OOXML was being excluded from consideration. Microsoft even voted for ODF standard acceptance. Playing dumb about this is just as disingenuous as IBM and Sun's attempts. Just admit it, and don't act all hurt that Microsoft saw through the charade.
You know as well as I do that Sun and IBM would not have allowed Microsoft to influence ODF in any meaningful way, so what purpose would there have been for them to participate?
So where are the "paginateLikeFrameMakerV2.73" (and similar... that particular version number was totally made up) tags in OOXML so I can retain my non-MS legacy documents?
Actually, there are such tags. For instance, suppressTopSpacingWP is there for Word Perfect documents and there's a date format that is there because of bug in Lotus 123. However, i doubt there is a gigantic legacy archive of framemaker documents out there, unlike word or excel documents.
Most of those legacy documents will not need to be edited, now, will they? So just converting them to PDF would be sufficient.
PDF is a far more complex format than either OOXML or ODF. It requires a postscript engine to translate. One of the big wins of ODF and OOXML is that XML documents are easily indexed by search engines, something that is significantly harder to do with PDF.
If they wanted to do something good for the customers, they wouldn't just be using OpenDocument, they'd join the group developing it.
You know as well as I do that the offer by Oasis for Microsoft to participate is disingenuous. The group is dominated by Microsoft's competitors who would do everything in their power (as evidenced by the blog articles they write on a daily basis, and legal maneuvering they keep coming up with) to sideline and make their participation in the group moot.
I believe that Microsoft would have participated in ODF if they believed their requirements for a file format would be met (ie. one that would support legacy documents and allow 100% document fidelity). I am certain they believed that participating in the Oasis group would have been a pointless exercise in futility, and they would end up with the same useless (to them, because it won't represent legacy documents) spec they have now.
You'll want to spin this as a power struggle, and claim that Microsoft wouldn't participate because they would not have been abke to control things. To that, i counter that Microsoft has participated in many standards, such as C, C++, XML itself, etc.. all without control over the working group. But the difference here is that the ODF committee was, by nature of it's makeup consisting almost entirely of their competitors, deliberately hostile to Microsoft.
It's no surprise they decided not to participate, and develop their own XML format. ODF was never intended to support Office, and was likely positioned to make it difficult for Microsoft to do so.
You really have to look at this from the political aspect, as well as the technical one. Read between the lines.
I'm not saying that OOXML is a great format. In fact, I think it sucks. But it does something ODF doesn't, and was deliberately prevented from doing, and something that is vitally important to the success of an open format, and that's legacy documents support.
If they wanted to do something good for their customers they would be using ODF, which is a complete, reasonable and free standard.
I'm sorry, are we talking about the same ODF here? Even OASIS doesn't agree with you, as they've already set up 2 working groups to address the incompleteness of it, namely accessibility and formulas. The one piece they still haven't addressed is legacy documents from Microsoft, Word Perfect, Lotus, and others, which is a HUGE problem for anyone that will want to convert their archive of documents to an open standard.
Other than the Accessibility and formula issues, I agree that ODF is a great office file format for new documents, but it's a royal pain in the ass if it's your job to keep legecay documents identical while converting to the new format.
The purpose they serve is to provide a means for converted legacy documents to retain information that would otherwise be lost. Those fields are deprecated, not just optional, and are actively suggested that they NOT be implemented. They're not intended to be used in any NEW documents, and I find it highly unlikely that Microsoft would let any apps create deocuments with them. It's pure paranoia, fear mongering, and FUD to suggest what you are suggesting.
The fact is that ODF, while a great office format for new documents, falls flat on its face when it comes to preserving legacy documents, something that is required by LAW in many cases. The whole purpose of the new file format standards is to allow documents to be read long after the applications that created them are dead and buried. ODF forgets about legacy documents, which means that unless a document converts perfect, or you hire a lot of staff to reformat documents that don't convert correctly, you're stuck keeping them in proprietary formats if you want to meet your archival responsibilities. ODF, and it's proponents, ignore this vital issue.
If OASIS had considered this problem, and addressed it in ODF, say by allowing application defined supplmentary tags for legacy support purposes, then this might never have been an issue. But by ignoring the legacy documents out there, they left the door wide open for Microsoft to argue this side of things and draw support.
There are many factors that define the performance of an OS. One of them is the number of features it provides, and another is the timetable in which said features are delivered. Yet another is legacy compatibility.
BeOS was new. It didn't have to be compatible with anything. But give it 10 years, and 2 Gazillion hacks to let old software continue to work. Give it hundreds or thousands of features, many of which are probably no longer even used by many people, but still have to be there because some small subset needs them. Give it features built upon other features and security patches upon other patches.
Commercial software vendors seldom have the ability to ship software when it's ready, they have to meet timelines. Look at OS X, each new release cycle takes longer and longer because as the OS matures, it takes more and more time to wade through the existing code to change it. It gets slower because more conditionals have to be added to check for compatibility or security issues, or because it needs to do more than it used to.
Linux (the kernel), on the other hand, seems to get better and better, faster and faster, with each new release. There is a reason for that, though. No commercial pressure to release, they can set an arbitrary release date and simply ship whatever features are ready, and do so relatively frequently because they don't have to worry about a large and complete OS release, just the kernel.
Distro vendors, on the other hand, seem to be taking longer and longer between releases (not counting Debian, which has always been glacial), because as the body of software grows, it takes more and more work to maintain it. Distro quality depends largely upon how long they spend stabilizing releases.
The important thing to keep in mind is that BeOS was not a mature OS. In many ways, they had done just enough to get it going. My guess is that once they had the resources, it would have fattened up to the size of OSX or Windows easily, and all that performance you saw when it was young and new would go out the window.
BeOS had a lot of problems as well, for instance the OS was written in C++, which meant that when you wrote drivers, they had to be in C++. The software loaded fast, because it wasn't very mature. It was like loading notepad or kedit. Simple and easy, but once big apps were running on it, they wouldn't be quite so snappy as they loaded in the dozens or maybe even hundreds of components.
Apart from the corrections already brought up, the Amiga was rife with limitations and problems of its own. It worked great in the narrow range that it was designed for, but had all kinds of other issues. For example, upgrading the video was a hack job that usually require patching the ROM libraries with ones that new about the new video hardware. It was tightly integrated, which meant doing anything outside what it was designed for was often difficult and expensive.
And I was an amiga fanatic. And, while I held out hope that Commodore would get their act together and provide the features that were rumored and needed (DSP's, retargetable graphics, etc..) I always knew it would never happen. If only Dave Haynie had been allowed to do what he wanted, but then again that probably would have made it too expensive for people to buy.
Sorry, I call BS.
.doc file from 2003, then click save, it will re-save it in 2003 format. You have to explicitly tell it to save in .docx to get it to upgrade the format. You really don't know what you're talking about if you make this claim.
Office 2007 will save any document you open in it's original format, thus if you open an
What's even more, when you install any version of Office since Office 2000, unless you tell it to delete the old version (it asks you specifically), it will install side-by-side versions, and you can run both simultaneously. I've been on the beta programs, and had to use both, so I know this to be true. There was a weird bug in Office 97 that didn't allow 2000 and 97 to be used simultaneously without some hacking, but this hasn't been true of any version since.
As for Outlook, i've downgraded PST files from both Office 2007 and Office 2003 to earlier versions without any kind of trouble, so I don't know what the author of the article is talking about. The only problem is with unicode versions, but that's a choice you can make to upgrade to that.
CIFSFS? Isn't that redundant? lol.
Still, doesn't this mean that new features of Samba can't be ported to work as a kernel level driver?
So doesn't this mean that smbfs is now dead? Or stuck at 3.0.x? Since the Linux kernel will not be going GPLv3, from my understanding of what Linus has said.
There are many reasons to be against this sort of thing. Cost has been said already. It's forcing states to pay for this, without funding it federally. Second, this country has been against a national ID card for decades. In fact, Social Security was guaranteed to not be used as a national ID card. The fear is that the government can track your every move with this card, as it will be required by more and more services. Currently, state ID cards are not linked to the government in any meaningful way. Yeah, they can look up your data, but that's about it. With a single, computerized ID system, every time you make a purchase that requires your ID (Cigarettes, alcohol, porn) can be recorded. Every time you get on an airplane, the government knows about it. They can datamine so much information about you, that your privacy is effectively nil.
Yes, we're already a computerized society, and they can already do a lot of this. That's bad, but the disparate nature of the databases makes doing such searches difficult and expensive, thus relegating it to important suspects. With this information at the governments fingertips, the cop that pulls you over for 'speeding' could see everywhere you've used your ID. Maybe take you downtown for questioning because you happen to go to the same night club as a wanted fugitive. Or maybe he's a bible thumper and wants to "punish" you for some blight against his beliefs on your record.
Is all that Paranoid? You bet. But the best defense of your privacy is to not allow people to have access to it, regardless of whether it's for the "greater good" or not. You're privacy is not private if the government has access to it, regardless of whether you think you have anything to hide or not.
While I agree with you in principle, I disagree with the argument that civilians cannot hope to defeat the government because of mismatch in firepower. I think Iraq has shown, without a doubt, that even highly trained and well equiped soldiers are no match for sheer numbers of people, and the average american has access to a lot more firepower than the average iraqi.
Also, the military is made up of the people. There will be many deserters or outright mutiny if the revolution were large enough.
Not that i'm encouraging such a thing, but should such an event occur, unless the US were willing to nuke it's own people, it could very well succeed.
The problem is, despite everything else, most people are comfortable. It takes a lot of uncomfortable people to get a good revolution. Downtrodden, completely depressed people. And it takes an organized, and charasmatic leader.
I'm not sure why you think the article is by someone unidentified. It was written by Adam Barr, one of the networking guys at Microsoft involved with the TCP/IP stack up until 2000, then he left Microsoft and wrote a book called "Proudly serving my corporate masters" about working for Microsoft, he was then later rehired a few years later and is still working there as far as I can tell.
Key phrases you may have missed:
"So, a short time after this, work was begun on a new version of TCP/IP, written entirely by Microsoft. "
That's not an implication, that's an outright statement, made by someone that is authoritative.
here's another:
"Eventually the new, from scratch TCP/IP stack was done and shipped with NT 3.5 (the second version, despite the number) in late 1994. The same stack was also included with Windows 95. "
Again, not an implication, an outright statement.
He does say, at the time, that since he no longer worked for Microsoft, he couldn't guarantee there was currently no BSD code in there, but it's quite clear that as of when he quit, there wasn't anything substantial that could be classified as having a BSD origin.
But all that is really beside the point, as first you claimed that Microsoft wrote their first stack for NT and that it sucked and they had to replace it with a BSD stack in windows 2000. None of that is true. The BSD stack sucked (largely because it was STREAMS based) and was replaced with rewritten code.
You're not making any sense here. The real history is that when Microsoft released Windows NT, Novell *REFUSED* to write a client for it. Microsoft was forced to write their own client for interoperability. It wasn't until later that Novell decided to try and play nice, but their client was so intrusive, replacing core DLL's that it made things an unstable mess.
The netware client on NT eventually got better, but it took a long time. I would not call that "stable".
Actually, no. Windows used the BSD based stack (licensed from spider software, who in turn paid UC Berkeley for a license, so it wasn't stolen) up until Windows 2000, then it rewrote the stack from scratch, according to this article:
/ 6/19/05641/7357
http://www.kuro5hin.org/?op=displaystory;sid=2001
Actually, that's not true. The GPL gives you a single right that you did not have before, that is to distribute unchanged or modified versions of a piece of software governed by the GPL. However, as a result of agreeing to the GPL and gaining that one right, you lose several other rights, for a net negative right loss.
The rights that you lose are the ability to distribute code you have developed under any license you choose (when that code is deemed a derivitive of the GPL'd work, which includes merely linking to the code in question). You lose the right to enforce any patents you may own on that code. You lose the right to control distribution and the right to control use. You also lose the right to control translations into other languages, and the right to control who may derive from your work. And, of course, you lose the right to control who gets your source code.
In the above, i'm referring to code that is entirely written by you that merely links to GPL'd code, not where you have taken someone elses code and modified it.
I'm not saying that's a bad thing, i'm merely saying that the argument that you have more rights because of the GPL is not very well thought out.
Actually, the GPLv3 is starting to get into use scenarios. For example, the whole TiVoization clause relates to how the softwware is used. DRM and Patents effect use as well, although these things still apply to distribution, it's blurring the boundaries.
Also, shrink wrapped licenses have been upheld in court so long as a method of returning the software if you don't agree with the license for a full refund is available.
Which NT4 cert was that?
/ news/c2summ.mspx?mfr=true
http://www.microsoft.com/technet/archive/security
"Windows NT 4.0 evaluation included servers and workstations in six different roles, operating in both TCP/IP networked and stand-alone modes."
I keep seeing this comment, but it's a bit disingenuous. Yes, it's true that the first evaluation for NT4 required those things, but a secondary review in 1999 allowed NT4 to retain those items. In other words, NT4 did in fact achieve full C2 with networking and floppy.
Uhh.. what are you referring to? There hasn't been any IIS related malware (virus or worm) for over 5 years.
Also, Netcraft counts host names, not servers. There is no current information on how many servers are IIS versus Apache, but netcraft information on physical server market from around 2001 indicates that with similar hostname ratios as today IIS had about 50% of the server marker.
I find that thought very suspect, for a lot of reasons.
The biggest is that Microsoft wasn't the only one involved in the early networking. IBM was as well. LanMan was a joint effort, and I find it highly unlikely that IBM would need Novell's assistance to make networking work correctly.