Writing an Operating System in Ada
in [ADA]
|
Prev: GNAT requires body of generic unit to be present at build?
Next: ASISEyes : show you the ASIS interpretation of an Ada source
From: Dmitry A. Kazakov on 15 Jan 2010 16:48 On Fri, 15 Jan 2010 13:05:38 -0800 (PST), Maciej Sobczak wrote: > On 15 Sty, 09:37, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >> The problem is what do you do with the blob beyond undoubtedly enjoyable >> moving it for one memory stick to another. > > Nothing, because as long as the blob is on the stick, there is nothing > else I might want to do with it. > The blob becomes useful only when it is loaded into memory. How does it? >> Because your file system has completely nothing to do with the contents, >> there is neither any gain nor any loss. > > The added value is that of name resolution. I can name my file (OK, > blob) as "my_homework_program.adb" and this intermediary naming layer > helps me with recognition of the content - otherwise I would have to > deal with sector numbers. The added value is exactly the same as that > of DNS, so that I do not have to type in the IP address of the > newsgroup service that I'm using right now. You don't need names for something, which is useless. You said it is useless when on the stick (which is of course wrong). > The purpose of the file system is to bring understanding to the > digital mess and the current file systems do their job pretty well. Sorry, but I don't know which kind of understanding you mean. In any case, "understanding" is not the purpose of the file system. There are certain functionality a persistent store must provide. Among them enumeration, efficient indexing, naming, notifications, journaling, identification, distribution, authentication, consistency and so on. Modern file systems is a persistent store that fulfills some of these requirements. "Understanding" is not in this list. >>> In this context, the advantage of the file system is that it does not >>> impose any assumptions about the OS itself. >> >> How so? It requires the file system to be implemented on each OS you wanted >> to attach the device to. > > And the fact that my USB stick works everywhere shows that this > assumption is realistic. The assumption that the target OS is pure-OO > would not be. Assumption? It is not an assumption, it is a fact, that somebody sat down and wrote the implementation of FAT for the OS X1. Why he or someone else could not do this for an OO X2 persistence layer? >>> I'm afraid that the omnipresent computing will bring us omnipresent >>> untypedness - or at least this is the current trend, if popularity of >>> programming languages is to be taken as any indication... >> >> Is there an increase in the number of commercial projects done in those >> languages? > > Are you sure you are still living in a world where > "commercial" (whatever that means) is equivalent to "leading"? It is an equivalent to "measurable". You can measure involvement in serious projects by investments in. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: nobody on 15 Jan 2010 17:45 Shark8 wrote: > On Jan 12, 3:39 pm, nobody <nob...(a)nowhere.com> wrote: > >>Shark8 wrote: >> >>>The problem about having no I/O is that there are some file-formats >>>which ARE sequential-in-nature as opposed to Random-access/Record-in- >>>nature: Midi and Huffman encoding (actually MOST compression would >>>fall here) are to examples off the top of my head. Or am I >>>misunderstanding what you mean? >> >>That is just implementation details that should(can) be hidden from the >>application code. Stick to the objects. Don't forget associations. > > > Aren't associations rather trivial if we derive all files from some > base tagged-type and use the tag as the type-identifier? Only for -to one. But how about -to many and -to one or many or .... For me associations are also almost always bidirectional. So just a simple tag reference may not be enough and standardised ways to navigate would be great.
From: Lucretia on 15 Jan 2010 19:13 On Jan 13, 8:37 pm, Shark8 <onewingedsh...(a)gmail.com> wrote: > Nifty. I came across your blog a while back as I was looking up some > Ada 2005 features (thank you for your explanation, in particular); > it's pretty good, IMO. If you'd like to pop me an e-mail or IM and > talk-shop about OS/OS-design I'd be more than happy to do so. {The > same goes for everyone else who's interested.} I don't really use IM, feel free to drop by #Ada on Freenode tho :) Luke.
From: Maciej Sobczak on 16 Jan 2010 16:18 On 15 Sty, 22:48, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > > The blob becomes useful only when it is loaded into memory. > > How does it? By becoming a typed entity that is referenced within the actively executed program. This is the moment when blob becomes useful. > > The added value is that of name resolution. > You don't need names for something, which is useless. You said it is > useless when on the stick (which is of course wrong). Ah, so we are again at the discussion style that will lead us nowhere. But let's try for a while. Several posts ago you have requested to execute actions on objects. "Play" was an action on the movie - you wanted that. When I said that the blob (a file, essentially) becomes useful when it is loaded into memory, I meant that it is the interpretation of the blob that gives it some requested capabilities. You want it to "Play", but I might want it to blur or sharpen instead. The point is that I can blur or sharpen a "movie" thanks to the fact that I see it at a different level that you wanted to see it and that would not be possible with pure-OO approaches (unless you allow Unchecked_Conversion, but that brings us back to blobs anyway). > > The purpose of the file system is to bring understanding to the > > digital mess and the current file systems do their job pretty well. > > Sorry, but I don't know which kind of understanding you mean. Apparently you do not understand. :-) > In any case, > "understanding" is not the purpose of the file system. Well, I use it for this purpose. > There are certain functionality a persistent store must provide. Among them > enumeration, efficient indexing, naming, notifications, journaling, > identification, distribution, authentication, consistency and so on. Modern > file systems is a persistent store that fulfills some of these > requirements. "Understanding" is not in this list. Because you did not put it on that list. I'm not going to discuss it this way. http://en.wikipedia.org/wiki/File_System "file system is a method of storing and organizing computer files and the data they contain to make it easy to find and access them" For me, "organizing" and "easy to find" are two aspects of "understanding what is on the drive". In any case, I understand what I have on my drive. > > And the fact that my USB stick works everywhere shows that this > > assumption is realistic. The assumption that the target OS is pure-OO > > would not be. > > Assumption? It is not an assumption, it is a fact, that somebody sat down > and wrote the implementation of FAT for the OS X1. Why he or someone else > could not do this for an OO X2 persistence layer? The only way to implement any persistence layer across different OSs is to have it not coupled to any OS. If you have pure-OO OS (that is, when *everything* in this system is OO) then it's persistence layer cannot be implemented on other, non-OO OSs. Current file systems (the ones with blobs) serve well as "common denominators" and this is exactly their value. > > Are you sure you are still living in a world where > > "commercial" (whatever that means) is equivalent to "leading"? > > It is an equivalent to "measurable". You can measure involvement in serious > projects by investments in. That's one approach. Another is to measure involvement by participation. In the age of social-this, social-that and social- whatever, the accounting is different. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada
From: Dmitry A. Kazakov on 16 Jan 2010 17:15
On Sat, 16 Jan 2010 13:18:46 -0800 (PST), Maciej Sobczak wrote: > On 15 Sty, 22:48, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >>> The blob becomes useful only when it is loaded into memory. >> >> How does it? > > By becoming a typed entity that is referenced within the actively > executed program. This is the moment when blob becomes useful. So the file containing a movie is useless? > Several posts ago you have requested to execute actions on objects. > "Play" was an action on the movie - you wanted that. When I said that > the blob (a file, essentially) becomes useful when it is loaded into > memory, I meant that it is the interpretation of the blob that gives > it some requested capabilities. Is there any player that loads movies into the memory? That must be a very curious one. I also assume that data bases are all totally useless if their contents do not fit into the memory? There still exist text editors capable to handle files bigger than the virtual memory. Note that your argument its bogus, because being logically continued, no object is useful if not in the CPU cache. But, wait, those are useless too, because not in the registers. Wait, no, they must be on the wire in the CPU to be useful. >> In any case, >> "understanding" is not the purpose of the file system. > > Well, I use it for this purpose. Others uses microscopes to crack nuts... >> There are certain functionality a persistent store must provide. Among them >> enumeration, efficient indexing, naming, notifications, journaling, >> identification, distribution, authentication, consistency and so on. Modern >> file systems is a persistent store that fulfills some of these >> requirements. "Understanding" is not in this list. > > Because you did not put it on that list. I'm not going to discuss it > this way. > > http://en.wikipedia.org/wiki/File_System > > "file system is a method of storing and organizing computer files and > the data they contain to make it easy to find and access them" System is a method? (:-)) That sort of definition does not deserve to be discussed. >>> And the fact that my USB stick works everywhere shows that this >>> assumption is realistic. The assumption that the target OS is pure-OO >>> would not be. >> >> Assumption? It is not an assumption, it is a fact, that somebody sat down >> and wrote the implementation of FAT for the OS X1. Why he or someone else >> could not do this for an OO X2 persistence layer? > > The only way to implement any persistence layer across different OSs > is to have it not coupled to any OS. I cannot comment on that, because I don't know the meaning of the word "coupled" you are using here. > If you have pure-OO OS (that is, > when *everything* in this system is OO) then it's persistence layer > cannot be implemented on other, non-OO OSs. That is a logical fallacy: X has no A AND X has A => X is not X X=OS, A=OO. Yes, if the OS is defined as not supporting persistent objects, then no OS can support them. > Current file systems (the ones with blobs) serve well as "common > denominators" and this is exactly their value. And the unicycle is the common denominator of all vehicles, therefore cars with four wheels are useless... >>> Are you sure you are still living in a world where >>> "commercial" (whatever that means) is equivalent to "leading"? >> >> It is an equivalent to "measurable". You can measure involvement in serious >> projects by investments in. > > That's one approach. Another is to measure involvement by > participation. In the age of social-this, social-that and social- > whatever, the accounting is different. I must disappoint you. That measurement was used first in the age of slavery, when the time assigned to the activity (then performed by slaves) was the measure. This measure is quite poor because workers are different and activities are too. This is why slavery, corv�e, socialized economies gave way to the free market ones. One can use that "different" accounting to fool others, but better not oneself. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |