Magnus Olsen wrote:
Should this not need alot of cpu power and memory use
?
if it need alot of memory most of i486 does only have 32MB
today reactos can run on a i486 with 32MB with out any problem.
but I feel in this way it need alot more memory that 32MB.
Anything will of course use cpu power and memory. As for exact figures,
that would be guesswork, as it depends heavily on how the system is
implemented, and I wouldn't know of any benchmarks of similar systems on
such machines.
the second problem I feel it need alot of harddisk
space
and it will need alot of harddisk space, that goes wast
I want a os that does not wast harddisk space.
That depends entirely on how the data is stored. As an example, RDF (I
don't know what RosFS will use, but I know RDF well and it's just an
example of how storage methods can matter) can be stored in numerous
ways, one way is using RDF/XML, which looks a bit like this (omitting
namespace declarations and such for clarity):
<rdf:RDF>
<rdf:Description rdf:about="some_url">
<dc:title>Some title</dc:title>
<dc:description>A very interesting description.</dc:description>
</rdf:Description>
</rdf:RDF>
Another way is using Notation3:
<some_url> dc:title "Some title" ;
dc:description "A very interesting description." .
As you can see this last representation is quite a bit less verbose than
the previous representation.
next problem
I do not like the idea have a sql server install to use it.
it will need alot of cpu power it will be to havey for i486
I agree the system should be somewhat scalable, but as Rick mentioned it
will probably be an embedded server, which is a bit more light weight.
And there is also a good chance a full-blown sql server isn't needed (at
least not for everyone) and could be replaced by a specialized database
engine.
For example, the server I'm using for some RDF data at the moment is
only about 900KB and that includes parsers for a number of RDF
representations and Curl. Depending on what the minimum requirements of
RosFS will be it's server probably wouldn't have to be much larger than
that. A small server like this would mostly use memory as cache, and
that can be controlled depending on the needs. And the CPU requirements
depend on how much data it needs to handle and usually aren't that bad
(MySQL is quite fast for example, and even a relatively unoptimized
server like I use spits out records faster than you can imagine, over a
TCP/IP connection that is).