Like I said, within the context of UTC, leap seconds should not be accounted for. UTC is an arbitrary time system and can have both static rules, like leap years, and dynamic rules, like leap seconds. Every conforming UTC system should operate like the leap second never occurred. All interval calculations will remain correct under those conditions.
Such a time system should not be used for "real" time sensitive systems like celestial mechanics, crypto certificates, or medical devices. There are better time systems for that. Accordingly, mapping between UTC and some other system will not necessarily yield a one-to-one mapping.
unless your problem domain needs to store the occurrence of leap seconds, when they appear are irrelevant. Regardless of when they appear, time monotonically increases. There is simply a skip. By its nature, the skip is meant to be invisible. Any time system based on UTC shouldn't try to factor in leap seconds while doing arithmetic because every UTC system will see that leap second as never existing in the first place. Systems that involve motion like satellites or systems that involve crypto should use an alternate time system and map between the two.
I am optimistic this strange concept will be overturned in good time, perhaps even by the Ninth Circuit, upholding the district courts decisions in Vernor and Augusto in pending appeals.
I think you'll be waiting quite a while. Google Blizzard vs Glider for a taste of what the courts have to say about EULA's. You might also want to pop over here for more information about the Psystar/Apple battle.
Really, what good are the dots? It doesn't prevent someone from looking over your shoulder. A villain can just look at your keyboard while you type. Maybe its of some use on a public terminal, but I check my six before I type in a security password anyway.
The obscured pass(word|phrase|key) has been the most aggravating while trying to type in a strong WiFi password on an IPhone (pre 2.something-or-nother update). Try it. The aggravation is pure ecstasy. Luckily Apple has wised up and shows you the last character you've typed at least.
And how about disabling paste from a security box. You can't verify your passkey when you're troubleshooting. A determined villain can get to it anyway, especially if they have access to your machine. Don't even get me started on the 'super' secure entry boxes where you can't paste TO the security edit box.
I don't think that'll work. You're setting up a system where more unscrupulous individuals could make a mint. If there's a big demand for a $250 laptop in richer countries, someone is bound to try to capitalize on the difference in price. What will happen is that those free or near-free machines going to third world kids will be stolen or 'lost'. They'll wind up on the grey market for $200 or thereabouts.
Considering how much the guts have in common with a TI development kit, I would say what took them so long? You can get the TI kit pretty cheaply now. Check out the Beagle Board at ArsTechnica.
Why don't publishers give up a little profit and put games on SD Cards? Look how cheap an SD Card reader is. With a little code judo, you can tie a game to the SD Card it's placed on. (The SD Cards have secure areas, and mfg registers and stuff.) Every copy of a game would be different. In essence, watermarked. What do you get?
The game is tied to a physical object. Now you can return it, resell it, etc.
You can install as many times and on as many computers as you like. Installing is simply a form of caching to make loading faster. Code on the SD Card authenticates the game.
Authentication can be lazy. The game doesn't need to be authenticated every time. So you don't need the card all of the time.
The cached instance of the game can be patched.
When the game is pirated, the watermark can give you more information about how and where the game got into the wild.
No need for online authorization means no worries about DRM servers going down.
And of course, no need for SecureROM and the like.
Using an SD Card could make PC Games more like console games.
If you read the article you would see that, where listed, the Xeon 3.2 ghz 2mb is the speed king. It's performance is virtually identical with the 4mb (slower bus) part -- and cheaper to boot. Anandtech says as much in their conclusion.
Go to Dell and they quote $1,499 for a Xeon 3.2 2mb as a second processor in their servers. Everyone knows that you don't buy your second processor from Dell because you pay a premium. What you're probably getting from Pricewatch is a bunch of hits from someone's pre-pricedrop processors. You will have to wait until the new prices get into the channel.
Not really. If a company wants to include the software in their own custom tool, then they have to release their custom tool under the GPL. Now their taxes paid for that research code just like your taxes did. Probably more so since corporations pay much more tax on average. I hear that corporations and the rich are responsible for most of the tax collected by the IRS but I don't have ratios. I'll see if I can find the link.
Why can't they use that research code in proprietary work? The original is still there. And the original can still be improved if need be. Any duplication of work would just be
The public work may actually reduce the cost of the proprietary product since the company can only charge for the value that they add. Any educated consumer can way the pros and cons of using the public version or the proprietary version.
Maybe even, the product has nothing to do with engineering but the algorithms and/or code works in a completely different domain -- with some tinkering. So now the company must either grow their own solution or give away their jewels. Even though their tax dollars have paid for a solution that is there today.
Hell, "graphics" is in their name! What's wrong with giving NVidia and ATI a little competition, especially at the gamer and prosumer level? How about a sub $1,000 card that does digital video in and out, accelerates OpenGL with *precision* and spanks NVidia at games?
Hell they can tweak on of their old boards and milk it all it's worth. And it shouldn't cut into their fat margin business.
SMT sounds good but I think (HP/Intel)'s EPIC will ultimately turn out to be the most elegant solution. When they finally get it right. While IBM and Compaq are throwing more cores at the problem, HP/Intel are trying to improve the core itself. You can always put mutiple EPIC cores on a MCM and do the SMT thing too.
The problems with compilers and EPIC is that current popular languages like C, C++ and Java, are not designed for parallel machines. There are extensions that add explicit parallel keywords to these languages but they're all non-standard. Anyway, explicitly stating what statements can run in parallel increases the application programmer's burden. And extracting parallelism from a imperative language puts a helluva burden on the compiler writer.
Now languages like Lisp or Scheme should lend themselves well to the EPIC architecture. It's easier to extract implied parallelism from a functional language because more of the scheduling decisions are left up to the compiler. A Scheme like lowlevel language should produce code that screams on EPIC.
I think HP/Intel are in unfamiliar territory -- both on architecture and languages. Once they gain that experience, later generation EPICs should be phenomenal.
Talk about a system for the big, slow and obtuse IT department.
Problem 1: Instead of finding a more efficient way to provide services to the user and at the same time manage their desktop, they do this. What's wrong with thin X servers? Better yet, how about throwing all those resources at creating businessware for Plan9?
Problem 2: The mainframe guys fell out of favor because of their iron grip on IT resources. They coudn't adapt or change direction fast enough to let smaller depts tailor systems to their business needs. (Not to mention the huge overhead costs they get hit with -- "hey let's make the IT dept a profit center!") Now the LAN guys are heading in the same direction. I wonder what the guys who actually bring in the money will use to circumvent them. Pilots and WinCE maybe?
Problem 3: This is supposed to make PC's more reliable how? We already have buggy software and buggy systems. Now we're going to transmit those internal signals over a wire. Big iron has scads more reliability than a PC ever will. Mainframes have processors just to watch the processors. This Mobility system is just a way to build a poor man's mainframe with out any of the reliability. I'm not pushing mainframes, but if you're going to build an empire, you might want to do it right and not half-ass.
This rant applies to WinFrame/MetaFrame/Terminal Services too.
There is no magic here. Java compiles to native code just as C or C++ does. At
run-time however (when Java compiles) there is optimization information on
what your program actually does that is not available at "build-time" when C++
compiles which thsu results in ebtter optimisation of the code.
I'll have to say "bull" on this one. What extra information would byte code
have that source code wouldn't? Sound's like a perpetual motion machine to me.
Just feed the byte code back into a "byte byte code compiler" and get super duper
optimized code. Seriously, though optimizing code paths in a running program
is the only thing Java has up on plain ole C++. I say plain old, because C++
makes compile time vs. optimization vs. size trade offs. But if you look at super optimizing
compilers Digital/Compaq's new C/C++ compiler or add on packages like Intel's
VTune or the GNU Super Optimizer, you start to see some of the tricks that
Sun uses on Java.
The reason Java performs pretty decently nowadays is because Sun had to
invest heavily in alternative algorithms and compile strategies. Example
is the benchmark Sun showed proving Java could
allocate/deallocate memory faster than C++. It only proved that Sun's memory
algorithm was better. If you could bolt their memory allocator onto a
C++ compiler, you'd probably see the pendulum swing the other way.
Comparing Java to C++ is like comparing different CPU architectures. On
the surface they may appear equal (or one appears better) but when you start
to look at the work per clock you start to get an idea of how efficient
each CPU really is. Java may have cool tricks, but you're going to lose
performance some where. If you thought C++ programs took forever to load,
look at Java. Now, instead of the inconvenience of waiting for code to compile,
you now have the inconvenience of waiting for it to load (or load parts of it) -- only
to get achieve the performance plain ole C++ has been providing for years.
Think about it. A machine with only 3.2 GB/s bandwidth can't sustain 6.2GFlops. Let's do 32 bit single precision fp. That's 4 bytes. Time 6.2 billion. Equals 24.8GB/s. Double this for double precision. The CPU simply will not ever reach projected peak performance. But that's besides the point.
The CPU only runs at 300 Mhz and is heavily optimized for vector style processing. Everything else suffers. Removing FP for the moment, the performance of the rest of the chip is no better than a PII at the same speed. Check comp.arch for more information.
The fullscreen anti-aliasing is cool but check out the XBox programming in the latest issue of Dr. Dobbs. The XBox pipeline is fully reconfigurable.
Think of it as Unix pipes. You're pluggin the output of one piece into the input of another. That sounds even cooler.
Check out the Linux Today dialogues between RMS and Tony Stanco here. Also featured here at Slashdot but I'm too lazy to find it right now. I think Stanco's arguments can be applied here as well.
The are two ways to become rich. One way is to control tangible property like real estate, rail ways, etc -- the means of production in the classical sense. The other means is to control the expression of your ideas. Eliminating IP law leaves you with the former only.
Economically, with the means of production so completely controlled by the rich, there is little left for the poor. The poor is then left with their intellectual prowess. They must either work for the rich (use their skills) thereby ensuring the rich get richer or they may attempt to sell their ideas thereby obtaining a larger share of the economic pie or even becoming rich themselves. Why limit their options because it inconveniences a few?
But I think there's more to it than just property and control. At the most basic level, humans have a tendency to think in the terms "mine" and "yours." "My" ideas are what makes me "me" and sets me apart from "your" ideas which make you "you". To say that "my" ideas are not "mine" is to say that I am not an individual. This idea of ownership is why copyright and patents are acceptable to people today. And were acceptable to people in the past.
So, people may give away the expression of their ideas. But it is theirs to give. If they attach terms that you must abide by to gain access to the work, and if you find those terms acceptable, then what harm is done?
The problem isn't the format. It's the components. How a.doc file is created and read is pretty well documented and understood. The problem is that all the streams or virtual files inside of them are created by components that change from version to version.
Even in TeX you have to hunt down the correct macro includes (a "component" in the TeX sense) if they're not installed inside the document. 'Twould be a lot of duplicated macros and wasted space if every document carried with it the requisite macro libraries that it needed to draw itself. That's why TeX has a bunch of standard macros that you don't have to send along with the document.
So let's say you only embed the macros that the document uses -- not every single one in a library. What do you have? A document that is renderable but not 100% editable. Because the macros that support some additional features are not present.
As soon as you start relying on external libraries (macros for TeX, components for COM or whatever) you run into component hell. The problem isn't figuring out the file, it's providing the required library/component functionality that a document needs. Each component has it's own operating context that itself depends on the document context.
All of this is why you get blank glyphs in TeX. And why translaters can only get 85% there for.doc files.
Does the format provide any real benefit to the customer? I don't know. The format seems to be geared more towards programmers (MS's) than customers. Which (in an ideal world) would lead to more efficiently designed applications.
I do know that the format is a red herring. Look at how MS is so excited about XML. It's all the components that need to be duplicated. A Office2000 document in TeX would be no more translatable than the.doc one it produces right now.
Explain to me just how the proprietary.doc format is superior to the open TeX format then. This obviously is not it, because they both react the same to this situation.
Not that I like.doc format or anything but the principle of the.doc format is the same as any component object container.
So, what makes.doc better is also what makes the KOffice format better or any other component storage format. If memory serves me, Tex is more closely related to Postscript than a document format. Sure it can create Postscript output, but it can just as easily drive a typesetting machine directly. The Tex engine is hardcoded to understand certain formats of resources like fonts or graphics. I think there are macros that get around this, but I'm not sure. (It's been a while so if this isn't true anymore, then I stand corrected.)
A compound file and the program that interprets the streams is generic. It doesn't know anything about the streams in the file. It defers that knowledge to the reader/writer which may have a better way of storing it's document than the generic format. The gist is that new formats can be added without changing any of the underlying mechanisms.
Functionally, there probably isn't any real difference between a Tex file and and a compound doc file. I just think that with a compound file layout, things that you have to explicitly state in Tex is handled by the low level machinery automatically. Sort of comparing C to C++. Example, because of the class of stream in a COM or OpenDoc file, your application menu changes to allow you to edit the stream.
It boils down to the fact that no matter what format you have, without the necessary renderers on your machine, you're out of luck. (As you indicated.) Tex is cool because documents are specified using Tex's macros. But it forces your application to think in frames and columns and runs when a tree or a graph might be better.
The very nature of a component object model makes transferring document across different platforms, even different computers on the SAME platform aggravating at times.
You just HAVE to have some component that can interpret a stream available to completely decode a document. This is true of ANYa component model. You want to see how difficult decoding a compound document is? Try grabbing the dead OpenDoc spec at look at their bento container. It's design goal is exactly like *.doc. And that was designed from the get-go to be cross platform.
Think of it as component hell. And it is unavoidable no matter who does it. This goes for KOffice as well. Complexity is a run away train. I should say entropy. Since we're tending towards chaos here.
Yes. The BSD license. Where others using *my* code are under absolutely no obligation to share their changes, period, and they can even go make a *billion* dollars off it without showing me a red cent, or even telling me.
Dude, don't player hate:)
If you release your code for free, and someone else finds that they can get people to pay for it, despite there being a free alternative (yours), then why get angry? Because you couldn't capitalize on your own program? Because someone would rather pay for someone else's version instead of getting yours for free? Or is it that you want others to put the spit and polish on while you sit back and stroke your ego?
I understand your need to see your program remain free. And it does, no matter what someone else does to it. The source to X didn't suddenly disappear after copmanies started producing their own X servers. Kerebos (spell?) is still around despite those zany boys at Microsoft.
The GPL isn't about your freedom. It's about the user's freedom. Look at it this way. If you decide to offer a commercial version of your program in addition to a GPL'ed version, what happens when people change the GPL'ed version? They're work doesn't become your work. You can't take their mods and roll it into the commercial version. That haven't signed the copyright on their additions over to you. You have to use their additions according to the GPL.
You've just lost true ownership of your program. The control you have is only the control the community allows you to have. Granted you have a lot of say since you're the original author. But the program is truly not yours anymore.
Don't get me wrong. Use the GPL. Enjoy the GPL. Just understand the GPL.
Slashdot Mirror
Like I said, within the context of UTC, leap seconds should not be accounted for. UTC is an arbitrary time system and can have both static rules, like leap years, and dynamic rules, like leap seconds. Every conforming UTC system should operate like the leap second never occurred. All interval calculations will remain correct under those conditions.
Such a time system should not be used for "real" time sensitive systems like celestial mechanics, crypto certificates, or medical devices. There are better time systems for that. Accordingly, mapping between UTC and some other system will not necessarily yield a one-to-one mapping.
unless your problem domain needs to store the occurrence of leap seconds, when they appear are irrelevant. Regardless of when they appear, time monotonically increases. There is simply a skip. By its nature, the skip is meant to be invisible. Any time system based on UTC shouldn't try to factor in leap seconds while doing arithmetic because every UTC system will see that leap second as never existing in the first place. Systems that involve motion like satellites or systems that involve crypto should use an alternate time system and map between the two.
I think you'll be waiting quite a while. Google Blizzard vs Glider for a taste of what the courts have to say about EULA's. You might also want to pop over here for more information about the Psystar/Apple battle.
Really, what good are the dots? It doesn't prevent someone from looking over your shoulder. A villain can just look at your keyboard while you type. Maybe its of some use on a public terminal, but I check my six before I type in a security password anyway.
The obscured pass(word|phrase|key) has been the most aggravating while trying to type in a strong WiFi password on an IPhone (pre 2.something-or-nother update). Try it. The aggravation is pure ecstasy. Luckily Apple has wised up and shows you the last character you've typed at least.
And how about disabling paste from a security box. You can't verify your passkey when you're troubleshooting. A determined villain can get to it anyway, especially if they have access to your machine. Don't even get me started on the 'super' secure entry boxes where you can't paste TO the security edit box.
I don't think that'll work. You're setting up a system where more unscrupulous individuals could make a mint. If there's a big demand for a $250 laptop in richer countries, someone is bound to try to capitalize on the difference in price. What will happen is that those free or near-free machines going to third world kids will be stolen or 'lost'. They'll wind up on the grey market for $200 or thereabouts.
Considering how much the guts have in common with a TI development kit, I would say what took them so long? You can get the TI kit pretty cheaply now. Check out the Beagle Board at ArsTechnica.
Why don't publishers give up a little profit and put games on SD Cards? Look how cheap an SD Card reader is. With a little code judo, you can tie a game to the SD Card it's placed on. (The SD Cards have secure areas, and mfg registers and stuff.) Every copy of a game would be different. In essence, watermarked. What do you get?
Using an SD Card could make PC Games more like console games.
One more thing about Sony...
My local EB Games is having a sell on PS3's. $100 off. The PS3 can't be moving all that well if they're being discounted already.
If you read the article you would see that, where listed, the Xeon 3.2 ghz 2mb is the speed king. It's performance is virtually identical with the 4mb (slower bus) part -- and cheaper to boot. Anandtech says as much in their conclusion.
Go to Dell and they quote $1,499 for a Xeon 3.2 2mb as a second processor in their servers. Everyone knows that you don't buy your second processor from Dell because you pay a premium. What you're probably getting from Pricewatch is a bunch of hits from someone's pre-pricedrop processors. You will have to wait until the new prices get into the channel.
Not really. If a company wants to include the software in their own custom tool, then they have to release their custom tool under the GPL. Now their taxes paid for that research code just like your taxes did. Probably more so since corporations pay much more tax on average. I hear that corporations and the rich are responsible for most of the tax collected by the IRS but I don't have ratios. I'll see if I can find the link.
Why can't they use that research code in proprietary work? The original is still there. And the original can still be improved if need be. Any duplication of work would just be
The public work may actually reduce the cost of the proprietary product since the company can only charge for the value that they add. Any educated consumer can way the pros and cons of using the public version or the proprietary version.
Maybe even, the product has nothing to do with engineering but the algorithms and/or code works in a completely different domain -- with some tinkering. So now the company must either grow their own solution or give away their jewels. Even though their tax dollars have paid for a solution that is there today.
for my pee cee?
Hell, "graphics" is in their name! What's wrong with giving NVidia and ATI a little competition, especially at the gamer and prosumer level? How about a sub $1,000 card that does digital video in and out, accelerates OpenGL with *precision* and spanks NVidia at games?
Hell they can tweak on of their old boards and milk it all it's worth. And it shouldn't cut into their fat margin business.
SMT sounds good but I think (HP/Intel)'s EPIC will ultimately turn out to be the most elegant solution. When they finally get it right. While IBM and Compaq are throwing more cores at the problem, HP/Intel are trying to improve the core itself. You can always put mutiple EPIC cores on a MCM and do the SMT thing too.
The problems with compilers and EPIC is that current popular languages like C, C++ and Java, are not designed for parallel machines. There are extensions that add explicit parallel keywords to these languages but they're all non-standard. Anyway, explicitly stating what statements can run in parallel increases the application programmer's burden. And extracting parallelism from a imperative language puts a helluva burden on the compiler writer.
Now languages like Lisp or Scheme should lend themselves well to the EPIC architecture. It's easier to extract implied parallelism from a functional language because more of the scheduling decisions are left up to the compiler. A Scheme like lowlevel language should produce code that screams on EPIC.
I think HP/Intel are in unfamiliar territory -- both on architecture and languages. Once they gain that experience, later generation EPICs should be phenomenal.
Talk about a system for the big, slow and obtuse IT department.
Problem 1: Instead of finding a more efficient way to provide services to the user and at the same time manage their desktop, they do this. What's wrong with thin X servers? Better yet, how about throwing all those resources at creating businessware for Plan9?
Problem 2: The mainframe guys fell out of favor because of their iron grip on IT resources. They coudn't adapt or change direction fast enough to let smaller depts tailor systems to their business needs. (Not to mention the huge overhead costs they get hit with -- "hey let's make the IT dept a profit center!") Now the LAN guys are heading in the same direction. I wonder what the guys who actually bring in the money will use to circumvent them. Pilots and WinCE maybe?
Problem 3: This is supposed to make PC's more reliable how? We already have buggy software and buggy systems. Now we're going to transmit those internal signals over a wire. Big iron has scads more reliability than a PC ever will. Mainframes have processors just to watch the processors. This Mobility system is just a way to build a poor man's mainframe with out any of the reliability. I'm not pushing mainframes, but if you're going to build an empire, you might want to do it right and not half-ass.
This rant applies to WinFrame/MetaFrame/Terminal Services too.
I'll have to say "bull" on this one. What extra information would byte code have that source code wouldn't? Sound's like a perpetual motion machine to me. Just feed the byte code back into a "byte byte code compiler" and get super duper optimized code. Seriously, though optimizing code paths in a running program is the only thing Java has up on plain ole C++. I say plain old, because C++ makes compile time vs. optimization vs. size trade offs. But if you look at super optimizing compilers Digital/Compaq's new C/C++ compiler or add on packages like Intel's VTune or the GNU Super Optimizer, you start to see some of the tricks that Sun uses on Java.
The reason Java performs pretty decently nowadays is because Sun had to invest heavily in alternative algorithms and compile strategies. Example is the benchmark Sun showed proving Java could allocate/deallocate memory faster than C++. It only proved that Sun's memory algorithm was better. If you could bolt their memory allocator onto a C++ compiler, you'd probably see the pendulum swing the other way.
Comparing Java to C++ is like comparing different CPU architectures. On the surface they may appear equal (or one appears better) but when you start to look at the work per clock you start to get an idea of how efficient each CPU really is. Java may have cool tricks, but you're going to lose performance some where. If you thought C++ programs took forever to load, look at Java. Now, instead of the inconvenience of waiting for code to compile, you now have the inconvenience of waiting for it to load (or load parts of it) -- only to get achieve the performance plain ole C++ has been providing for years.
Think about it. A machine with only 3.2 GB/s bandwidth can't sustain 6.2GFlops. Let's do 32 bit single precision fp. That's 4 bytes. Time 6.2 billion. Equals 24.8GB/s. Double this for double precision. The CPU simply will not ever reach projected peak performance. But that's besides the point.
The CPU only runs at 300 Mhz and is heavily optimized for vector style processing. Everything else suffers. Removing FP for the moment, the performance of the rest of the chip is no better than a PII at the same speed. Check comp.arch for more information.
The fullscreen anti-aliasing is cool but check out the XBox programming in the latest issue of Dr. Dobbs. The XBox pipeline is fully reconfigurable.
Think of it as Unix pipes. You're pluggin the output of one piece into the input of another. That sounds even cooler.
Check out the Linux Today dialogues between RMS and Tony Stanco here. Also featured here at Slashdot but I'm too lazy to find it right now. I think Stanco's arguments can be applied here as well.
The are two ways to become rich. One way is to control tangible property like real estate, rail ways, etc -- the means of production in the classical sense. The other means is to control the expression of your ideas. Eliminating IP law leaves you with the former only.
Economically, with the means of production so completely controlled by the rich, there is little left for the poor. The poor is then left with their intellectual prowess. They must either work for the rich (use their skills) thereby ensuring the rich get richer or they may attempt to sell their ideas thereby obtaining a larger share of the economic pie or even becoming rich themselves. Why limit their options because it inconveniences a few?
But I think there's more to it than just property and control. At the most basic level, humans have a tendency to think in the terms "mine" and "yours." "My" ideas are what makes me "me" and sets me apart from "your" ideas which make you "you". To say that "my" ideas are not "mine" is to say that I am not an individual. This idea of ownership is why copyright and patents are acceptable to people today. And were acceptable to people in the past.
So, people may give away the expression of their ideas. But it is theirs to give. If they attach terms that you must abide by to gain access to the work, and if you find those terms acceptable, then what harm is done?
The problem isn't the format. It's the components. How a .doc file is created and read is pretty well documented and understood. The problem is that all the streams or virtual files inside of them are created by components that change from version to version.
.doc files.
Even in TeX you have to hunt down the correct macro includes (a "component" in the TeX sense) if they're not installed inside the document. 'Twould be a lot of duplicated macros and wasted space if every document carried with it the requisite macro libraries that it needed to draw itself. That's why TeX has a bunch of standard macros that you don't have to send along with the document.
So let's say you only embed the macros that the document uses -- not every single one in a library. What do you have? A document that is renderable but not 100% editable. Because the macros that support some additional features are not present.
As soon as you start relying on external libraries (macros for TeX, components for COM or whatever) you run into component hell. The problem isn't figuring out the file, it's providing the required library/component functionality that a document needs. Each component has it's own operating context that itself depends on the document context.
All of this is why you get blank glyphs in TeX. And why translaters can only get 85% there for
Does the format provide any real benefit to the customer? I don't know. The format seems to be geared more towards programmers (MS's) than customers. Which (in an ideal world) would lead to more efficiently designed applications.
I do know that the format is a red herring. Look at how MS is so excited about XML. It's all the components that need to be duplicated. A Office2000 document in TeX would be no more translatable than the .doc one it produces right now.
Not that I like .doc format or anything but the principle of the .doc format is the same as any component object container.
So, what makes .doc better is also what makes the KOffice format better or any other component storage format. If memory serves me, Tex is more closely related to Postscript than a document format. Sure it can create Postscript output, but it can just as easily drive a typesetting machine directly. The Tex engine is hardcoded to understand certain formats of resources like fonts or graphics. I think there are macros that get around this, but I'm not sure. (It's been a while so if this isn't true anymore, then I stand corrected.)
A compound file and the program that interprets the streams is generic. It doesn't know anything about the streams in the file. It defers that knowledge to the reader/writer which may have a better way of storing it's document than the generic format. The gist is that new formats can be added without changing any of the underlying mechanisms.
Functionally, there probably isn't any real difference between a Tex file and and a compound doc file. I just think that with a compound file layout, things that you have to explicitly state in Tex is handled by the low level machinery automatically. Sort of comparing C to C++. Example, because of the class of stream in a COM or OpenDoc file, your application menu changes to allow you to edit the stream.
It boils down to the fact that no matter what format you have, without the necessary renderers on your machine, you're out of luck. (As you indicated.) Tex is cool because documents are specified using Tex's macros. But it forces your application to think in frames and columns and runs when a tree or a graph might be better.
The very nature of a component object model makes transferring document across different platforms, even different computers on the SAME platform aggravating at times.
You just HAVE to have some component that can interpret a stream available to completely decode a document. This is true of ANYa component model. You want to see how difficult decoding a compound document is? Try grabbing the dead OpenDoc spec at look at their bento container. It's design goal is exactly like *.doc. And that was designed from the get-go to be cross platform.
Think of it as component hell. And it is unavoidable no matter who does it. This goes for KOffice as well. Complexity is a run away train. I should say entropy. Since we're tending towards chaos here.
Dude, don't player hate :)
If you release your code for free, and someone else finds that they can get people to pay for it, despite there being a free alternative (yours), then why get angry? Because you couldn't capitalize on your own program? Because someone would rather pay for someone else's version instead of getting yours for free? Or is it that you want others to put the spit and polish on while you sit back and stroke your ego?
I understand your need to see your program remain free. And it does, no matter what someone else does to it. The source to X didn't suddenly disappear after copmanies started producing their own X servers. Kerebos (spell?) is still around despite those zany boys at Microsoft.
The GPL isn't about your freedom. It's about the user's freedom. Look at it this way. If you decide to offer a commercial version of your program in addition to a GPL'ed version, what happens when people change the GPL'ed version? They're work doesn't become your work. You can't take their mods and roll it into the commercial version. That haven't signed the copyright on their additions over to you. You have to use their additions according to the GPL.
You've just lost true ownership of your program. The control you have is only the control the community allows you to have. Granted you have a lot of say since you're the original author. But the program is truly not yours anymore.
Don't get me wrong. Use the GPL. Enjoy the GPL. Just understand the GPL.