[cad-linux] Re: OT: Open data formats (continuation of previous thread)
- From: "Jeffrey McGrew" <JMcGrew@xxxxxxxxxxxxxx>
- To: <cad-linux@xxxxxxxxxxxxx>
- Date: Tue, 24 Sep 2002 13:20:07 -0700
> The oldest version of AutoCAD I've seen running (and this was=20
> several weeks ago) was version 2.15, I think. Like your old=20
> tools, software _does_ continue to work, even when there are=20
> superior options available. And that old tractor (or Jeep)=20
> -- if it wasn't modified, could it burn unleaded gas without=20
> burning up its valves? What happens when hydrogen or ethanol=20
> become the fuel of choice? The point being, the context in=20
> which "work" is defined is continuously changing.
Your examples are flawed (my car can burn unleaded gas without issue, =
due to how it was made in '68, a lot of racers use Alcohol right now =
with minimal modification, etc.) but I understand your point. The =
context and environment is continuously changing, I agree; but my =
counterpoint is that it doesn't automatically mean that you can't plan =
things so that they will still work (at least in some capacity) in the =
future. You have to admit that some of the non-compatibility between old =
and new software is due to the lack of concern on the developers part or =
purposeful manipulation of the parent company. It's not an *automatic* =
default of computers and software is what I'm saying.
> Software _is_ different than anything else. There are=20
> similarities to other more tangible objects, but they only go=20
> so far. My background isn't software, it's mechanical=20
> engineering, and after 8 years at Autodesk I'm finally=20
> starting to get the distinctions.
You're right; software is different from everything else in that it =
contains nether any form of warranty or liability. Software developers =
cry that it would be 'just too hard' if these things were required =
legally. Due to the EULA of software, any problems I have, even if they =
were the fault of the company that made the software, are my problem no =
matter how bad they are. The software doesn't even have to work! As soon =
as I click that 'I Agree' button on the screen, I sign away most of the =
rights that I have with any other thing I own. Now I agree that Software =
is different; however I strongly disagree with the fact that it has no =
regulation or requirements that every other product, even a simple damn =
music CD or Video Tape, has.
Open Source is not the best solution for software for me. I would love =
to buy something off the shelf and not have to twiddle with it. If it =
used an open file format that I could do what I need to with and =
functioned reasonably well I wouldn't CARE if it was open source or not. =
However, I'm on my own either way; with commercial software there is a =
implied 'value' and 'security' and 'support' but if you read the EULA =
not one of these things is included with the software. It's all just =
marketing. I can pay extra for these things, maybe, but I'm still =
completely on my own. With Open Source software, I'm still on my own; =
but at least I'm in control of my computer and data. At least I know any =
changes I make to the software and share with others won't be taken away =
from me. At least I didn't have to pay a lot of money for a deal that =
can be changed at any time by the company that makes the software. At =
least I won't be forced to upgrade or change my tools ageist my needs =
and wishes.
Have you read the EULAs for all the software you use? Do you really =
understand what you can't and can do with it?
> Your consideration of PDF files may do as well substituting=20
> ZIP, correct? I can put much more diverse information into a=20
> ZIP file, and lock and unlock it for protection too. =20
That's a good point; I know you're not a lawyer, but do you think that a =
ZIP file would be seen in the same 'non-editable' light by a court of =
law as a PDF would be?
> My understanding is that the antiquated TCP/IP stack powering=20
> the net doesn't allow IP telephony or video to work in a=20
> reasonable way. IPv6 deprecates IPv4 (today's standard),=20
> solves some of those problems and is starting to make=20
> headway. Don't expect the IPv4 stack to ever understand=20
> IPv6, by the way.
I know, I know; OK it was a bad example. What I'm just saying is that if =
you plan ahead you can make it possible for something to be useful for a =
very long time. When the IPv4 stack was developed the world wide web =
wasn't even a glimmer in anyone's eye; let alone voice-over-ip and =
video. And I would say that, while it's limiting today, IPv4 has been a =
HUGE success story. I mean, we're not all using FIDONET, Compuserve, =
IPX, Novell, ect. We're using a standard that was developed openly and =
can be used by anyone and is moderated not by a single company. Hey look =
at that- open standards can be good for everyone.
> Regarding a unified format for CAD: Take a look at the=20
> abundance of proposed standards for representing 3D graphics.=20
> None are successful. And, 3D graphics is at best 10% of the=20
> problem with CAD. Multiply the problems with 3D graphics by=20
> 10 (or perhaps take them to the 10th power) and you start to=20
> understand why I'm pessimistic.
Yes, it's a huge mess, and I think it's all because of greed and =
software companies stupid ideas to corner the market. ANSI Text is ANSI =
text, I can write a text file that you will be able to read on ANY =
computer ANYWHERE. I can write HTML and it will look the same =
EVERYWHERE. I can write 2D vector graphics as a postscript file and have =
it look and print the same EVERYWHERE. I can make a rendering into a =
JPEG and it will look the same EVERYWHERE.
Most of these proposed standards are developed and put forth by single =
companies, and that's why they fail IMHO. It's not like ANSI, or HTML, =
or JPEG, which were developed and managed by an independent standards =
board, industry group, or academia.
> The path to success in data=20
> exchange is focusing on tasks rather than bulk information=20
> transfer, IMHO. We should work to define very, very useful=20
> formats that solve particular task-oriented problems in the=20
> design process. The formats should be small, and highly=20
> focused. That way we can begin to layer them, and build our=20
> knowledge of what works and doesn't. This approach won't=20
> give you a format that works for everything, but it should=20
> (hopefully) start making formats themselves irrelevant.
I have to respectfully disagree. Because if each of these 'layer' =
formats can only be create with one companies product then it's not =
going to get very far. That's why IFC is building up steam; Timberline, =
Visio, Excel... all of them can use it, and those are completely =
different software with completely different uses. I think we need LESS =
formats, more flexible and universal formats, than multiple formats that =
we layer to get information across. Talk about a management nightmare!
Jeffrey McGrew=20
Other related posts: