piranha wrote:
I don't have time to comment on all of them, but...
Quote:
3. No traditional filesystem (instead use a single file which is a database containing various entities)
These entities would not resemble the current files we are used to. However, the database would contain all the
descriptive information (and more) that these files currently contain.
I don't like that because that file would have to be loaded at each read/write per applications, resulting in possible conflicts and decreased stability. Plus, thats much slower.
Why would the database have to be accessed at each read/write of an application?
The only reason the database needs to be accessed is when an application needs information to carry on with it's functioning. This would only occur at the time the application starts and if some object within the database is loaded by the application.
I am surprised to hear you say that it would be much slower as database accesses are very fast these days given the proper engine. I would like to hear others opinions on this method.
Quote:
Quote:
4. One large function library that all applications and the kernel use.
With no possibility for additions? That makes the OS less usable, and that library would be HUGE.
Of course there would be possibility for additions. Requests would be made to the development community that are responsible for the O/S development. This is the same case with all other open source projects. The library would not be huge as there would be a lot less redundancy involved. Consider the .NET library. It isn't that big, but does a lot of things and is continuously being added to.
My biggest problem with the current way of doing things is that there are a huge number of libraries out there. For a programmer to become proficient in making use of all of the diversity demands a huge amount of time and at the initial stages of that programmers learning curve it is very likely the coding will not be efficient (i.e., fraught with bugs, etc). Also, think of the amount of resources that have been involved in "re-inventing the wheel" so to speak. There is so much redundant code from library to library. What a waste of time and resources.
Quote:
Quote:
5. Library functions are loaded on demand and based on this system design would not necessarily have to be unloaded.
With everything loaded there is a very good chance it would not exhaust all available memory (with the exception of
machines that have under 1 Gig of Ram which this O/S would not support anyway).
Ah, that explains #4. Loaded on demand? So, while the application is executing? Doesn't seem that efficient...
I am surprised at this comment as that is exactly what happens with DLLs under all versions of Windows and with dynamic libraries under Linux.
Quote:
Quote:
6. No windowing GUI
How are that simpler? Command line? Few users would be OK with that.
I was not clear enough. There would be a GUI it just would not allow multiple windows to be created. Each application would be full screen. Just that alone makes it easier for the user. Also keep in mind: I am not intending this O/S for technical types that easily know ther way around an O/S. This is intended for people who have very little understanding of computer usage.
Quote:
Quote:
7. All applications are built (programmed) using Meta-data: Basically the application and interactions are "described"
rather than coded in the traditional sense.
That makes the applications very inflexible. How would that work? No coding?
The only limitations that would exist would be from the limitations of the current library. But that would only be for a short time until the next O/S update was available. The O/S could be patched between reboots if required. The Meta-data would describe what library calls to make and how to make use of the calls. This kind of paradigm already is in use via XAML and XML and other assundry mechanisms.
For example, the meta-data would describe how many frames exist. It would describe the buttons and other widgets that are in use and what those buttons and widgets do.
Quote:
#4: Couldn't the virus be programmed as meta-data?
I suppose there is a possibility; however, there is no way to hide such things as currently can be done. There also is no way to infect some other executable. All one would need do is de-install the associated meta-data, for the application that was installed, to resolve the problem. This severely limits the nasty behavior of such entities.
Quote:
#6: Makes the application less usable and less useful, more difficult to program.
Remember this important point: This O/S is not intended for experts. It is intended for the general public. The general public does not have the requirements that you might have.
The applications would have as much functionality as the general public requires. This would be mainly governed by the library in use at any particular point in time.
Quote:
#7: How would that reduce confusion when most are used to it? What would be in it's place?
Note: I said "non-windowing GUI". This means that there is a GUI. Windows result in confusion. For example, think of the last time when a window popped behind another window and you didn't realize it had happened. Can you imagine how that would complicate the life of the general public? This is only one of the many difficulties that can occur.
Quote:
#9: But drastically reduces speed and stability. And how does that prevent viruses?
I don't see how it would reduce speed and stability.
Virus' are prevented purely from the fact that the only people doing any "real" programming are a trusted group and the actual applications are created from meta-data that makes use of the libraries code (not code that anyone can put together).
Quote:
#10: I disagree.
How can you not agree that there would more stability? Could you elaborate?
Quote:
#11: Linux rarely has to reboot, from my personal experience.
I would agree whole heartedly. The problem is that the general public does not use Linux.
Quote:
#12: How? I would think that because the program runs slower the boot-up time would be longer.
Demand loaded libraries would improve bootup speeds simply from the point that they don't all have to be loaded at bootup time.
How would "the program" run slower?
Quote:
One big problem for me is that nearly no applications would fit into this system without rewriting everything. There are some good ideas/intentions, but I don't like the solutions (IMHO. But others may like it).
I do like the idea of a better GUI, but I'm confused on what you mean.
You are absolutely right: Existing programs would not fit into this system. It demands a complete new approach that leaves all existing software behind (with the exception that pieces of code could be re-used in building the O/S and it's libraries and drivers).
-JL[/quote]