Re: [Mentalunix-developers] Debate over philOSophy. =\

[Alan G. <ala...@st...>]

First, When replying to stuff, it is customary to trim down the
orrigional text to just what you are replying to directly, As I have
done from the beginning of this thread.

Inclding the full text of the orrigional in the reply is foolish because
if two people did it as the length of the messages would grow at a
linear rate untill somebody's computer creashed. The message you sent
out was 21k which is above what usual list-ettiquite allows. 

Slashdot just posted a story about a system called "Pliant" which is
MUCH Closer to what I want. I'll be taking myself off this list right
after I have verified that this message has gotten out. Contiue this
thread by replying directly to me if you prefer.

> You do make me think about 15% of the time you rant.

I must congratulate you for being a discerning enough reader to actually
consider what I say instead of dismissing it immediately. 

> But you really have a few major misconceptions about how stuff works.

Maybe, or I might have thought about it at such great length that you
can't quite see how my ideas have evolved and therefore think they are
foolish.

> > That's a security problem. If the user code was properly sandboxed,
> > only that user would really care about what it was doing.
>
> But why should I let a user who has a cracking tool to continue to
> try and crack the system? No reason. If I saw they were running some
> wierd app in the logs, I might want to have a look see.
 
If your loggs pick up something you don't like then do whatever you
want... The loging mechanisms were never clear enough to me for me to
make any good use of them... 


> Well, there is no right to privacy from private companies. If I let
> you use my server, then I can look at your files.

That is a local policy decision... Not something for us OS G0Dz to hand
down... 

> > But why does the hardware need to be controlled?
> > Why not just controll the *software*?
> > If you limit the system to running only what goes through *your*
> > compiler you have *perfect* control over the software.
> > That should be enough to satisfy you, It'll satisfy me! ;)
> > And make for cheaper hardware too...
>
> Because, a programmer will only program if they don't have to worry
> about little things like what hard drive you use. Belive me, it is
> easier to use stuff like fs_read() or open_device() that actually
> writing the hundreds of lines of code to do the same! Why do it more
> than once, when you can do it once?

Naturally... Those calls you just presented are horribly low-level... 
There would be some convention between the programmer's environment and
the runtime system such that calls of any level of abstraction could be
provided. 

The highest-level interface I can think of and describe right here would
be based on objects... 

Something like: 

Send_to_subsystem(REQUEST_OBJECT, "foo");
Service_Request("foo", READ); 

This is a messed up C-like example but it does show how things could be
done on a very abstract and therefore powerful level... foo could be a
program, a service, anything you could choose... No reason at all to
mess with low-level device or even traditional filesystem calls. =)

I designed a system similar to this but didn't implement it because my
design was too primitive and didn't 3xp10!7 the various programming
languages as it should have... 


> > Not neccessarily.
> > Unix wasn't implemented in C till '83.
> > Before that it was in assembly. =\

> Yep. Yep. Yep. But lisp != good for an OS. Lisp interpresters are
> written in C.

Some BAD/first generation lisp environments may be implemented in C...
But here's a little secret: 

C compilers are written in C. 

Lisp environments (often including both compiler and runtime
interpriter)
are written in Lisp. 

Forth environments are written in Forth...

See a patern? 
If your language isn't good enough to support its own compiler then you
don't have anything worth using. ;) 

> > Bah!
> > If I were forced by some sadist to re-implement linux, I'd do it all
> > in FORTH. =) I consider C archaic even if it isn't yet obsolete...
>
> C is never obsolete. It can be extended.

If you are thinking about libraries, 
You have never used FORTH. 
 
> > > You need to learn how to use a computer to use UNIX.
> >
> > And just how do you use a computer? =P
>
> Or rather, you need to be able to use a shell and stuff.

command.com hasn't challenged me in years... 

> Not really. Developers developing for other developers is good
> sometimes. Not commercially, but in the free software world it works.
> If you don't have to make money, you should make it easy for fellow
> developers to use it, and make it so they have the power they want.
> Plus, when developing for other developers, you can show off your
> coding skills and become cool. The end users don't care how well you
> code.

Nor do they have an OS. =\ 

> Yep. But the source is free for those apps. You can take what works,
> trash what doesn't.
 
In theory... 

[rewriting linux]
> Not really. Remember, you don't have to do 100% rewrites. From your
> rants, it seems you'd need to do a 60% rewrite, not 100%

Well, looking at the existing systems will shave a lot of effort off of
the task of figuring out how to do certain things, what algorithms work
and stuff. But if I decide to go with a language that I find more
suitable for one reason or another, I will be faced with rewriting the
entire thing in that language. 

-- 
The 'apocolypse' happened in 1848.
Now if everybody would only just look... =\
http://users.erols.com/alangrimes/  <my website.

Unsolicited "spam" messages to this account are subject to usage fees
and
in cases of fraud or egregeous abuse, prosecution.