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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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-09-03 10:35:56 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!195.64.68.27!newsgate.cistron.nl!isdnet!enst!enst.fr!not-for-mail From: "M. A. Alves" Newsgroups: comp.lang.ada Subject: Ada OS talk (was: Progress on AdaOS) Date: Mon, 3 Sep 2001 18:36:30 +0000 (GMT) Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: avanie.enst.fr 999538555 53258 137.194.161.2 (3 Sep 2001 17:35:55 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Mon, 3 Sep 2001 17:35:55 +0000 (UTC) To: Return-Path: X-X-Sender: In-Reply-To: <3B92A8A2.C577815D@san.rr.com> Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.4 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:12660 Date: 2001-09-03T18:36:30+00:00 > Anyway, it *would* be libraries implementing the types of files. Yes. That is what I meant with "different levels". I still think you need a storage element level as a building block for the file types and other elaborations. And this would be the role of the kernel. > just suggesting that serialization isn't a necessary component of a > "file", any more than you need to explicitly load and store pages for > virtual memory in modern systems. By serialization you mean a (do_first, do_next, end_error) sort of thing? I think the best building block is the (un)bounded array of storage elements, which is more than this. But of course I may be wrong. > > Not having directories in the kernel tends to mean that directories aren't > > implemented in any coherant standard way. > > No more than a lack of image types in a kernel means that images aren't > implemented in a coherent standard ways. FORTH simply has library > routines to handle directories. My point exactly. > > Because whether it's GIF87 or 89 is a mostly irrelevant fact, and there's > > zero chance of confusing the two once you know it's a GIF file. Some thing > > much more interesting is whether it's a picture of Robert Dewar or Tucker Taft, > > but that's something no one's talked about putting in the type. > > Well, my basic point there was that if you're going to have "strongly > typed files", as suggested by the original web pages, then the ability > to treat an image file as raw bits is a bad thing. The suggestion is > that a files data type cannot change without a change in content, but > this is just wrong. Certainly I can change a file's type from raw text > to HTML on most modern systems (including the Mac) without changing the > content. This is all fine, but, again, not at all kernelian. I am being extremely kernelist as a lesson learned (negatively) from AdaOS history. They did not concentrate on the kernel--and the project failed I think because of this at least in part. The current discussion is excelent, but is about things outside the kernel. And to get a kernel _done_ I think a it should be simple viz. provide a simple structure viz. the (un)bounded array of storage elements as a building block and then when the thing is going we can implement directories, file types etc. In short: give me a OS that only handles "raw bits" and I can build everything upon that; furthermore, aim at such an OS and you will get it done; aim at a full-featured-OS-language-like OS and you will not even get it started. -- , M A R I O data miner, LIACC, room 221 tel 351+226078830, ext 121 A M A D O Rua Campo Alegre, 823 fax 351+226003654 A L V E S P-4150 PORTO, Portugal mob 351+939354002