From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-28 21:22:46 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!headwall.stanford.edu!unlnews.unl.edu!newsfeed.ksu.edu!nntp.ksu.edu!news.okstate.edu!not-for-mail From: David Starner Newsgroups: comp.lang.ada Subject: Re: Progress on AdaOS Date: 29 Aug 2001 03:13:52 GMT Organization: Oklahoma State University Message-ID: <9mhmlg$9aa1@news.cis.okstate.edu> References: <9IFe7.12813$6R6.1221214@news1.cableinet.net> <9lghqu$ac6$1@nh.pace.co.uk> <3B7C3293.76F49097@home.com> <9lhefg$lgd$1@nh.pace.co.uk> <3B7D47F1.25D6FC78@boeing.com> <5ee5b646.0108171856.18631c4c@posting.google.com> <3B7F624B.7294D24F@acm.org> <9lr6je$5hj$1@nh.pace.co.uk> <9ltoi7$4is$1@nh.pace.co.uk> <3B82789B.8D195045@home.com> <9ltuo8$70n$1@nh.pace.co.uk> <3B829450.879B0396@home.com> <9mdh4e$q3v$1@nh.pace.co.uk> <9me03r$c302@news.cis.okstate.edu> <3B8AB6C8.910130C8@san.rr.com> <9metfo$aai2@news.cis.okstate.edu> <3B8BC332.214F95CA@san.rr.com> Reply-To: dstarner98@aasaa.ofe.org NNTP-Posting-Host: x8b4e5129.dhcp.okstate.edu User-Agent: slrn/0.9.7.2 (Linux) Xref: archiver1.google.com comp.lang.ada:12545 Date: 2001-08-29T03:13:52+00:00 List-Id: On Tue, 28 Aug 2001 16:13:42 GMT, Darren New wrote: > My point is to ask why not. My point is to ask "why limit yourself to > array-of-byte files" and you're answering "because anything else is not > a file." That's not helpful. The way I feel, you keeping asking "why limit yourself to citrus fruits as oranges" and I'm answering "because anything else isn't an orange." Until you give me a concrete definition for a file, this discussion isn't going anywhere. No matter how you define it, most files are arrays of bytes. Look up how hard drives and RAM work if you don't believe me. > Why not? Again, you're starting with a preconceived notion of "file" > being "an array of bytes", then claiming that the OS should be handling > that as the basic type. I don't even know what you mean by "the basic type" here. > For example, on the Amiga OS, files were tasks, as were device drivers, > etc. You could send a message to a file task to read and write portions > of the file into particular buffers, and when the message returned, the > I/O was complete. This allowed you to treat windows as files > (open("con:top/left/width/height/title")) and such. It allowed you to > write phenomes to the voice synthesizer and read lip positions back as > the sound was generated. Cool stuff like that. And, wow, open ("con:1/1/20/20/My Window / file") is so much clearer than Create_Window (Top => 1, Left => 1, Width => 20, Height => 20, Title => "My Window / file"). Oops, we need to escape the / somehow in your call, don't we . . . You're welcome to open a pipe to the voice synthesizer. It'll work just as well. > Imagine an OS where "files" are actually protected objects, fully typed, > that outlive your program's execution. Directories are simply persistant > protected objects that act as arrays mapping strings to these "files". So we have an space-inefficent tangle of data that's hard to transfer between systems running different OS's and probably even between different programs on the same system. >> An OS could certainly flatten that into a file. It would probably >> take a lot of work to make sure it wasn't an OS/program/libada specific >> file, though. > > I don't see any particular need to flatten it as such. Again, you're > trying to map "files" onto "array of bytes in a UNIX-like file system". > That's not the point. Hard drives, CDs, floppies and tapes are flat. Hence to store it you're going to need to flatten it. > There's a reason folks put names on files, on procedures, on users. The > same reason holds for individual pieces of data in a file. It's a win > whenever you store more than one piece of data in a file, like more than > one line in a text file, more than one user in a password file, etc. And > if you're only storing one atomic piece of data in a file, it's because > you're using the file's name as an index anyway. Have you never written > a program where the name of a file is calculated by the program? > "Image01.jpg", "Image02.jpg", ...? And how much of a win is storing that in one file over storing it in a directory and tarring / zipping it for transport? >> > The type for an "Active Server Page" with Ada code embedded in >> > HTML markup under control of CVS? >> >> text/x-asp. > > And how does CVS know it can handle this, text/* > and how does the web browser > know it needs to invoke the Ada compiler and not the Java compiler when > rebuilkding this page? I would assume it reads the start of the file. > The point is that no passive tagging system is going to be complete > enough that you can specify everything you need to know about the > program in the type tag. Sure. And? > My point is that a persistant data storage system modelled as named > arrays of bytes is just primitive. The addition of type tags tells you > what library to use to understand the interpretation of the untyped > array of bytes, which is just silly when you start trying to use it from > a language like Ada that actually has real types. I've used Ada. Every so often in Ada, you're juggling twenty different types and having to constantly convert between them. I fail to see the advantage to that in an OS. I don't want each program having its own set of types that are incompatible with everything else. I also want my editor to work any appropriate file, be it C, Ada, HTML, Tex, a diary, whatever. You ask how the web browser knows it needs to invoke the Ada compiler in my situation. How does the web browser know anything about the file in your situation? How does this type get created? What happens if you change it from Ada to Chill? How does the editor know what type to create? > Errr... When talking about designing and writing an OS, saying "oh, > don't worry, the device drivers will take care of it" doesn't work. Sure it does. It's called stratifaction. When talking about user mode utilities, we can hand certain things off to the kernel, and let the kernel worry about it. > Why > not let the real data be the one with the pointers and strong types and > such, and only use streams when you want to communicate with a different > OS? Because a plain text file is readable by 4 million different programs. Because the format for PNG is set in stone and readable by 40,000 different programs. However, the internal format for Emacs has been known to change between versions. It's hard to keep internal structures the same; much easier to conform to a consistent external standard. Also, I've worked with programs that used a database and those that use plain text files, and the latter seem more reliable. I got semi-regular database corruptions on GURU, whereas I never heard of one on GCA, and one on GCA probably would have been confined to one or two files and those could have been edited in Notepad. I've fixed a corruption in dpkg's available file with vim, whereas a binary database I would have had to reinstall and lose the data in the file. (Of course, that's probably part of the reason dpkg is so slow.) -- David Starner - dstarner98@aasaa.ofe.org Pointless website: http://dvdeug.dhis.org "I don't care if Bill personally has my name and reads my email and laughs at me. In fact, I'd be rather honored." - Joseph_Greg