altosdev-kernel Mailing List for alternative OS development (Page 2)
Status: Planning
Brought to you by:
dozz
Menu
▾
▴
altosdev-kernel — Kernel development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
(51) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Danil I. K. <ki...@st...> - 2002-03-12 12:36:26
|
Still alive. > > Anyone alive out there? > > > _______________________________________________ > altOSdev-kernel mailing list > alt...@li... > https://lists.sourceforge.net/lists/listinfo/altosdev-kernel > |
|
From: Alexey M. <tkt...@cs...> - 2002-03-12 07:29:03
|
I think about design. > Anyone alive out there? > > -- See you later, d. +358 040 817 8540 |
|
From: Benjamin J. <bsj...@mi...> - 2002-03-12 04:14:34
|
Yah...I'm still in college and have finals this week so I haven't been talkative. Raz0rSharp Kernel Panic wrote: > Anyone alive out there? > > -- > Regards, > Kernel Panic mailto:rzh...@he... > > _______________________________________________ > altOSdev-kernel mailing list > alt...@li... > https://lists.sourceforge.net/lists/listinfo/altosdev-kernel |
|
From: Kernel P. <rzh...@he...> - 2002-03-11 20:03:26
|
Anyone alive out there? -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Alexey M. <tkt...@cs...> - 2002-03-09 12:31:45
|
Hei, And so what do you thinks about streams? && What do you think about hot swap? -- See you later, d. +358 040 817 8540 |
|
From: Kernel P. <rzh...@he...> - 2002-03-09 10:11:39
|
Hello, Benjamin. On Saturday, March 09, 2002 at 9:42:06 AM you wrote: BJ> Ok, I'm running Linux (redhat 7.2 and Debian potato on different BJ> machines) and Windows 2000 on another partition of the redhat 7.2 BJ> machine. What tools will I need to get in order to develop with you BJ> guys? Or will the typical cc / gcc and related tools work? If you are going to use Linux as your development system, you perhaps don't need anything else. In case you're gonna use Windows you should download the DJGPP (or any other) port of GCC (www.delorie.com); you should also get the binutils with ELF support enabled instead of those that are shipped with DJGPP. I put them at http://elfbinutils.narod.ru along with some instructions on how to set everything up. What you will also most probably need is Bochs, a PC emulator (http://bochs.sourceforge.net). There are versions both for Windows and Linux. It makes use of a harddrive image, so you'll need some tools to write to DOS filesystem images. If you use Linux, you've got mtools, and there is also a Windows port of them.. -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Benjamin J. <bsj...@mi...> - 2002-03-09 08:43:07
|
Ok, I'm running Linux (redhat 7.2 and Debian potato on different machines) and Windows 2000 on another partition of the redhat 7.2 machine. What tools will I need to get in order to develop with you guys? Or will the typical cc / gcc and related tools work? Thanks, Raz0rSharp |
|
From: Alexey M. <tkt...@cs...> - 2002-03-09 08:12:25
|
> Hello, dozzer. Hei, > I wonder what's so special about streams? Isn't it just another form > of what is known as IO control under DOS/Windows? If so, what are > advantages/disadvantages of the two? Do they have anything to do with > two channels (command and data ones)? Detailed explanation would be > nice =) . No, it is not the same. It is general purpose form of inter process communication which can be applied for device drivers and user applications. The main difference of stream is that it is demand to transfer data with correspondence to specefied binary protocol. The control channel transfers commands and data channel transfers raw data. You may imagine that stream is the pair of two sockets, but with different realization. The control channel needs to transfer small packets of control sequences, so it can be realized to be transfered as fast as it possible. The data channel can be realized in the common way as a common socket. The adventage of that layout is that we can receive commands and answer to it immediately don't waiting for whole data. Then we can receive next command even we din't read all data of previous command. The adventage of using unified form of interprocess communication. You can build common application where you send your's graphical representation to GUI, read files and write them -- all these you do through streams. The program (shell for example) which calls execve and performs your application can redirect your streams in any way.. the pepresentation can be redirected to machine A and application can be performed on machine B. If you'll create children processes and communicate with them through streams, they can be performed on different machines - and your application will know nothing about it. The streams help to create distributed applications. Let imaging more sophisticated example. You have machine A and machine B. Machine A has no mouse, machine B has two. When you load up drivers, you redirect stream from one on machine B to machine A. Now, for all applications on machine A mouse will be present. How to realize that in kernel - another question. -- See you later, d. +358 040 817 8540 |
|
From: Kernel P. <rzh...@he...> - 2002-03-08 19:28:49
|
Hello, dozzer. I wonder what's so special about streams? Isn't it just another form of what is known as IO control under DOS/Windows? If so, what are advantages/disadvantages of the two? Do they have anything to do with two channels (command and data ones)? Detailed explanation would be nice =) . -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Kernel P. <rzh...@he...> - 2002-03-08 15:15:57
|
Hello, dozzer. On Friday, March 08, 2002 at 2:46:11 PM you wrote: AM> Hei, but dozzer sounds better for me.. I use automatic templates in The Bat, I'm just to lazy to correct everything myself =) . AM> This is good idea, what did you do in linking phase... how do you link AM> modules together? I load 3 files, as I wrote, then process all the relocations in each file. And that's it.. (It's not completed yet, though; but will be soon.) I can mail you the sources as soon as I finish it.. >> I've rebuilt binutils 2.11.2 (the latest as of >> now) to support ELF, so if anyone is interested I can upload the >> executables somewhere so that you can download them. AM> Ok.. do it for me at least. http://elfbinutils.narod.ru. There are also some instructions on how to set them up. Just copy the files from the ZIP into the bin directory in your djgpp installation (and backup the originals =) ). -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Alexey M. <tkt...@cs...> - 2002-03-08 14:00:37
|
Hei,
As i mentioned before, all communication between processes are performed
using signals and streams. About signals we talk later, let talk about
streams.
The stream is the form of inter process communication. Stream consist of 2
channels; one of them is using for commands transfering and second for
data transfering. Transfering commands should be faster than data transfering
in kernel realization (cuz commands transferring has less data than
data transferring, so we can implement it to work faster).
The communication between processes is implemented using streams. If one
process needs to open stream "/dev/gui/level1" it do it with appropriate
system call. Kernel transfers command to VFS, which knows that "/dev/gui"
is the mountpoint of device gui and requests it for stream named "level1"
Each process has special entry point for requests about stream
creation. The GUI receives this request and creates stream from his side.
As a fact, "/dev/gui/level1" is only a stream name, stream is a number of
internal kernel structure... The GUI receives request and creates the
thread which will perform communication with application through this
stream... It is common client-server architecture.
It can be described like that.
Process open stream "/dev/gui/level1" with system call
1. Kernel creates the new stream number and remember that on the one
side of stream is our process.
2. Kernel sends request to VFS in order to get the informaion who will
be on other side of stream..
2.1 VFS knows that "/dev/gui" is the mount point of gui module.
2.2 It calls the special entry point in module in order to know is it
possible for module to send and receive data through this stream.
2.2.1 GUI looking for his streams names,... yappi
2.2.2 He found that "level1" is a stream name and function level1
should perform the communication through this stream
2.2.3 GUI creates the thread for function level1 and passes to it
the number of stream.
2.2.4 GUI returns to VFS information that he accepts stream
creationg.
2.3 VFS returns to kernel the gui process id
3. Kernel remembers the information about the second side of stream
4. Kernel returns to the process the number of created stream.
What should do the thread in GUI? It should read from command channel of
stream for commands from process and sends through stream
information about events.
I suggest 3 level of GUI services:
1. Raw GUI service;
In this service we care about redrawing and other stuff. The GUI in
this case will only send us information about events and we redraw and
etc.
2. Component GUI service.
Like using X protocol we will send GUI through stream information
about compoments of window, their properties and GUI sends for us back
in stream information about events but we don't need to readraw
anything cuz using standart components.
3. Raw text service.
For console applications.. The was text output into stream will be
shown in window and user input will be sent to application through
stream.
Application can use any level... for example super modern MP3player can
use first level to get the strange window form and buttons. The text
editor can use second level to minimize code.. He sends the GUI level 2
his representation in some format and catches events that GUI sends to
him.. he can perform save and load when user selects save and load from
menu and etc... Simple console applications like super hacker utility or
common ping can use GUI level 3, to not be worried about application
graphical representation.
Level 1:
Application sends to GUI:
1. Bitmaps of window,
2. Mask of windows to know the window area,
3. The mask of events, that application wants to catch,
4. Or just a request to draw in window some graphics.
Application receive from GUI:
1. Event information (mouse event, keyboard event),
2. Request to redraw some area of window (event too).
Level 2:
Application sends to GUI:
1. The defenition of window and all elements it contains
2. Request to affect to specified element of window (insert text into
common text label element, for example).
Application receives from GUI:
1. Events, but specified for elements (for example, user selects "load"
from menu).
2. Request redraw some area IN some ELEMENT!
Level 3:
Application sends to GUI:
1. Raw text (GUI creates the window using service level 2 and creates
standart text edit element in it, when GUI receive the text, it
shows it in this element)
Application receives from GUI:
1. Raw key values, that user pressed.
--
See you later,
d.
+358 040 817 8540
|
|
From: Alexey M. <tkt...@cs...> - 2002-03-08 13:46:35
|
> Hello, Alexey Malev. Hei, but dozzer sounds better for me.. > AM> It maybe rather usefull to get ready-to-use kernel with sources, > AM> which was wrote by another group of developers, and use it in own > AM> needs? > Ehh.. I guess we would end up having another Linux clone.. Anyway, do > you know of any implementation of your stream model in any OS? I'm not > familiar with that.. As for me, it's much more interesting to write > everything yourself, of course using some other open source code for > references.. At least you will understand any single line of code > you've written. Yap. I meant that we can get kernel with sources and reuse it in the way we need, i.e. replace any IPC except signals and add streams. But you are right.. it is better to write all from scratch. > Well, not only DJGPP.. That's just a DOS port of GNU tools.. If anyone > has, say, a Linux box, he/she will use native Linux tools.. I hope > there also exists a Mac port of them. That means, we should be using > GNU tools (not restricted to DJGPP). Yap. You are right again.. > This implies doing no changes to the kernel itself. ..I guess, that's > what's called modularity =) . Even at the boot stage.. This is good idea, what did you do in linking phase... how do you link modules together? > AM> You can load djgpp from internet and the installation we need gets only > AM> 8M and grub is approx. 1M. > The problem is, that DJGPP only ships with COFF and AOUT executable > formats built into the binutils. This way, you'll have to rebuild > binutils to enable ELF support. I strongly suggest using ELF as this > is the only most-commonly used executable format which is flexible > and yet simple enough. I've rebuilt binutils 2.11.2 (the latest as of > now) to support ELF, so if anyone is interested I can upload the > executables somewhere so that you can download them. Ok.. do it for me at least. > AM> But we still not decided, who will load modules? Who will link > AM> them with kernel? > What exactly do you mean? You answered this question above in your letter.. -- See you later, d. +358 040 817 8540 |
|
From: Kernel P. <rzh...@he...> - 2002-03-08 12:22:17
|
Hello, Alexey Malev. On Friday, March 08, 2002 at 7:20:14 AM you wrote: AM> It maybe rather usefull to get ready-to-use kernel with sources, AM> which was wrote by another group of developers, and use it in own AM> needs? Ehh.. I guess we would end up having another Linux clone.. Anyway, do you know of any implementation of your stream model in any OS? I'm not familiar with that.. As for me, it's much more interesting to write everything yourself, of course using some other open source code for references.. At least you will understand any single line of code you've written. AM> Kernel Panic can give us several suggestions about kernel structure, AM> abilities and implementation.. Hei Kernel, Can you? I was hoping I wasn't the only one here who could.. ;) Well.. I suggest doing a microkernel (which implies IPC in form of streams, e.g.).. That's the general idea =) . If anyone has any more specific questions/suggestions, post them here.. AM> Another important thing is to select development instruments; I suggest AM> djgpp for kernel compilation and grub for booting.. Does everyone agree? Well, not only DJGPP.. That's just a DOS port of GNU tools.. If anyone has, say, a Linux box, he/she will use native Linux tools.. I hope there also exists a Mac port of them. That means, we should be using GNU tools (not restricted to DJGPP). As to grub.. I had a different idea, which I've almost implemented as of now. As we (at least I) would like that the OS can be compatible with other ones (that is, the user wouldn't have to delete his/her windows/unix partition to just give it a try), we shouldn't make the kernel depend on the filesystem/drive type. If you look at FreeBSD or Linux, they can only boot from their native filesystems, because they have only ufs/ext2fs support built into the kernel. Which is bad. I have done this (almost) this way (without grub, but that's not the point): our bootsector gets loaded by the MBR, it then loads the filesystem driver, which loads the last-stage loader. The latter uses the filesystem driver to load the kernel, kernel-mode filesystem driver, kernel-mode low-level disk driver (as the kernel can't use BIOS in pm), and links them together. And that's it. I'm currently doing the linking stage, as it proved the most difficult one. All other drivers (FAT16, ATA) and the bootsector (FAT16) are done. When this is done, the kernel will be able to run on virtually any drive hardware and filesystem, provided that an appropriate driver exists. This implies doing no changes to the kernel itself. ..I guess, that's what's called modularity =) . Even at the boot stage.. AM> You can load djgpp from internet and the installation we need gets only AM> 8M and grub is approx. 1M. The problem is, that DJGPP only ships with COFF and AOUT executable formats built into the binutils. This way, you'll have to rebuild binutils to enable ELF support. I strongly suggest using ELF as this is the only most-commonly used executable format which is flexible and yet simple enough. I've rebuilt binutils 2.11.2 (the latest as of now) to support ELF, so if anyone is interested I can upload the executables somewhere so that you can download them. AM> But we still not decided, who will load modules? Who will link AM> them with kernel? What exactly do you mean? -- Regards, Kernel Panic mailto:rzh...@he... |
|
From: Alexey M. <tkt...@cs...> - 2002-03-08 07:59:39
|
Hei,
As i mentioned before, all communication between processes are performed
using signals and streams. About signals we talk later, let talk about
streams.
The stream is the form of inter process communication. Stream consist of 2
channels; one of them is using for commands transfering and second for
data transfering. Transfering commands should be faster than data transfering
in kernel realization (cuz commands transferring has less data than
data transferring, so we can implement it to work faster).
The communication between processes is implemented using streams. If one
process needs to open stream "/dev/gui/level1" it do it with appropriate
system call. Kernel transfers command to VFS, which knows that "/dev/gui"
is the mountpoint of device gui and requests it for stream named "level1"
Each process has special entry point for requests about stream
creation. The GUI receives this request and creates stream from his side.
As a fact, "/dev/gui/level1" is only a stream name, stream is a number of
internal kernel structure... The GUI receives request and creates the
thread which will perform communication with application through this
stream... It is common client-server architecture.
It can be described like that.
Process open stream "/dev/gui/level1" with system call
1. Kernel creates the new stream number and remember that on the one
side of stream is our process.
2. Kernel sends request to VFS in order to get the informaion who will
be on other side of stream..
2.1 VFS knows that "/dev/gui" is the mount point of gui module.
2.2 It calls the special entry point in module in order to know is it
possible for module to send and receive data through this stream.
2.2.1 GUI looking for his streams names,... yappi
2.2.2 He found that "level1" is a stream name and function level1
should perform the communication through this stream
2.2.3 GUI creates the thread for function level1 and passes to it
the number of stream.
2.2.4 GUI returns to VFS information that he accepts stream
creationg.
2.3 VFS returns to kernel the gui process id
3. Kernel remembers the information about the second side of stream
4. Kernel returns to the process the number of created stream.
What should do the thread in GUI? It should read from command channel of
stream for commands from process and sends through stream
information about events.
I suggest 3 level of GUI services:
1. Raw GUI service;
In this service we care about redrawing and other stuff. The GUI in
this case will only send us information about events and we redraw and
etc.
2. Component GUI service.
Like using X protocol we will send GUI through stream information
about compoments of window, their properties and GUI sends for us back
in stream information about events but we don't need to readraw
anything cuz using standart components.
3. Raw text service.
For console applications.. The was text output into stream will be
shown in window and user input will be sent to application through
stream.
Application can use any level... for example super modern MP3player can
use first level to get the strange window form and buttons. The text
editor can use second level to minimize code.. He sends the GUI level 2
his representation in some format and catches events that GUI sends to
him.. he can perform save and load when user selects save and load from
menu and etc... Simple console applications like super hacker utility or
common ping can use GUI level 3, to not be worried about application
graphical representation.
Level 1:
Application sends to GUI:
1. Bitmaps of window,
2. Mask of windows to know the window area,
3. The mask of events, that application wants to catch,
4. Or just a request to draw in window some graphics.
Application receive from GUI:
1. Event information (mouse event, keyboard event),
2. Request to redraw some area of window (event too).
Level 2:
Application sends to GUI:
1. The defenition of window and all elements it contains
2. Request to affect to specified element of window (insert text into
common text label element, for example).
Application receives from GUI:
1. Events, but specified for elements (for example, user selects "load"
from menu).
2. Request redraw some area IN some ELEMENT!
Level 3:
Application sends to GUI:
1. Raw text (GUI creates the window using service level 2 and creates
standart text edit element in it, when GUI receive the text, it
shows it in this element)
Application receives from GUI:
1. Raw key values, that user pressed.
--
See you later,
d.
+358 040 817 8540
|
|
From: Alexey M. <tkt...@cs...> - 2002-03-08 06:20:32
|
Hei, The interesting idea came to my crazy head this night. Why should we write general, simple things? It maybe rather usefull to get ready-to-use kernel with sources, which was wrote by another group of developers, and use it in own needs? No, It is bad idea. If you have ideas about OS organization and visual representation.. talk about them.. I think, that Danil has a lot of ideas about GUI... ;) He has a Mac, as far as I remember. Kernel Panic can give us several suggestions about kernel structure, abilities and implementation.. Hei Kernel, Can you? Another important thing is to select development instruments; I suggest djgpp for kernel compilation and grub for booting.. Does everyone agree? You can load djgpp from internet and the installation we need gets only 8M and grub is approx. 1M. Ok, I feel that no one want to talk here. I decided to set requirements to the first workable version of kernel. But we still not decided, who will load modules? Who will link them with kernel? -- See you later, d. +358 040 817 8540 |
|
From: Alexey M. <tkt...@cs...> - 2002-03-07 23:20:12
|
> BJ> What is the intended hardware for this to run on? > I guess, i386. This is the only thing I know and as it's also the most > commonly used architecture, it should be easy to get help somewhere, > if we can't figure out something, to test it etc. Yap, You can look at http://menuetos.org , It is OS which was wrote in assembler.. it should be fast... but slow... it should have low-requirements to hardware... but it is needed to have 32 meg min. and vesa 2.0, 3.0 to run it.. It is example what we shouldn't do! Yes, We write our OS in {asm,C,C++} but it should be possible to load it on old >=i386 PC. -- See you later, d. +358 040 817 8540 |
|
From: Alexey M. <tkt...@cs...> - 2002-03-07 23:10:37
|
> What is the intended hardware for this to run on? x86 > I would like to know if I'll be able to test it or if I'll have to find > some expensive machine in order to load our OS. I assumed that OS possible to load on my old notebook (p150,24m,800x600x24). -- See you later, d. +358 040 817 8540 |
|
From: Ben J. <bsj...@mi...> - 2002-03-07 20:14:46
|
Good! I have intel architecture machines so I would very much like it if we could develop this for i386...but I guess that's up to everyone. Ben On Thu, 7 Mar 2002, Kernel Panic wrote: > Hi, Benjamin. > > March, 7, 2002 at 6:14:04 you wrote: > > BJ> What is the intended hardware for this to run on? > I guess, i386. This is the only thing I know and as it's also the most > commonly used architecture, it should be easy to get help somewhere, > if we can't figure out something, to test it etc. > > -- > Regards, > Kernel mailto:rzh...@he... > > > _______________________________________________ > altOSdev-kernel mailing list > alt...@li... > https://lists.sourceforge.net/lists/listinfo/altosdev-kernel > |
|
From: Kernel P. <rzh...@he...> - 2002-03-07 19:51:21
|
Hi, Benjamin. March, 7, 2002 at 6:14:04 you wrote: BJ> What is the intended hardware for this to run on? I guess, i386. This is the only thing I know and as it's also the most commonly used architecture, it should be easy to get help somewhere, if we can't figure out something, to test it etc. -- Regards, Kernel mailto:rzh...@he... |
|
From: Benjamin J. <bsj...@mi...> - 2002-03-07 05:14:38
|
What is the intended hardware for this to run on? I would like to know if I'll be able to test it or if I'll have to find some expensive machine in order to load our OS. Thanks, Raz0rSharp |
|
From: Alexey M. <tkt...@cs...> - 2002-03-07 03:12:06
|
Hei, You may found 3 articles now in docs section on our site. Read it and comment here. Note, that there only a drafts that will be refined and enlarged by your's comments. The goals inside: Describes the principles how it should be designed from developers point of view. Read it carefully, If you have an experience in OS development write your comments. Any way, you need to read it. The goals outside: The document which describe how OS should be organazed from user's point of view. It describes the main goals of OS. You should add your ideas here and I post it there. Any person can comment it. The streams: My attempt to describe streams in 2 words... not so bad abouts streams, but I wrote there something about OS... you may skip it, because the main goal of this document was to describe what stream is. Sorry for size of files, I'll rebuild it later. -- See you later, d. +358 040 817 8540 |
|
From: Alexey M. <tkt...@cs...> - 2002-03-07 02:32:38
|
Hei all, > I'm down with whatever. I just want some group programming experience > along with a big project under my belt. I guess that's my only feedback > right now. OK > Any ideas when you guys want to get started? In about 2 weeks would be > best for me, and then for the next 6 months I should have a decent > amount of time to commit. ~10.04.2002 -- See you later, d. +358 040 817 8540 |
|
From: Benjamin J. <bsj...@mi...> - 2002-03-07 02:25:48
|
I'm down with whatever. I just want some group programming experience along with a big project under my belt. I guess that's my only feedback right now. Any ideas when you guys want to get started? In about 2 weeks would be best for me, and then for the next 6 months I should have a decent amount of time to commit. See ya, Ben |
|
From: Alexey M. <tkt...@cs...> - 2002-03-06 23:44:28
|
> AM> Let the system communication with user will be only through
> AM> GUI. But I supposed that the console applications will be wrote by
> AM> someone further for experienced users.
> Ok, let it be. Yeah, we'll have to support console apps anyways.. BTW,
> are we going to support Linux or BSD binaries? That would simplify the
> matters enourmously, since we would already have a working compiler
> and all the stuff related to it.. I, personally, would stick to Linux
> (though I love BSD better).
OK, It is not the problem to realize the elf loader for example.. it can
be ported from opensources to this system.. the only is needed to realize
standart runtime library for our OS.
It is better use ready-to-use format rather than imagine own executable
file format and have a lot problems with compiling and executing
it further.
>> multi-user concept no, single yes
> It wouldn't be really that hard to implement. If you take a look at
why? do you need the multi-user support at your home computer? why shall
we waste system resources for useless multi-user ability? It is server's
problem, we are clients from that point of view.
> AM> If it used for several users, they can use secured server for
> AM> keeping personal data and connect to it when they need.
> Consider several users using the same computer. How are there desktop
> settings going to be maintained? Even Windows (not to mention NT)
> supports multi-user configurations (not entirely, though, but in some
> sense). We have to take into account the fact that several users can
> share one computer, so we have to at least implement some basic
> multi-user support ('cause it will be a pain to add it in future to an
> already working system).
OK. I didn't think about it.. as I said before We can realize application
which login to server with personal folders, mount them, change the
desktop with correspondence to user preference which are stored in
personal data...
--
See you later,
d.
+358 040 817 8540
|
|
From: Alexey M. <tkt...@cs...> - 2002-03-06 23:34:06
|
Forwarded from Kernel Panic by dozz.
--message--
Thnx. I was using Opera, and it didn't display the whole page (guess
it's a sourceforge bug).
Well, regarding your articles.. I fully agree with the first one, but
I have some doubts with certain statements in the second one.
AM> Let the system communication with user will be only through
AM> GUI. But I supposed that the console applications will be wrote by
AM> someone further for experienced users.
Ok, let it be. Yeah, we'll have to support console apps anyways.. BTW,
are we going to support Linux or BSD binaries? That would simplify the
matters enourmously, since we would already have a working compiler
and all the stuff related to it.. I, personally, would stick to Linux
(though I love BSD better).
AM> The alternative OS is the Personal OS. It is mean that there is no
AM> multi-user concept. This OS doesn=92t restrict users in using local
AM> resources.
It wouldn't be really that hard to implement. If you take a look at
other OSes' kernel code the percentage of the multi-user support code
is extremely low. Furthermore, if we use, say, ext2fs, ufs of ntfs
filesystems, we'll already have some facilities for multi-user
support. I guess we could at least leave the possibility to add this
in future if we don't want to implement it straight away.
AM> If it used for several users, they can use secured server for
AM> keeping personal data and connect to it when they need.
Consider several users using the same computer. How are there desktop
settings going to be maintained? Even Windows (not to mention NT)
supports multi-user configurations (not entirely, though, but in some
sense). We have to take into account the fact that several users can
share one computer, so we have to at least implement some basic
multi-user support ('cause it will be a pain to add it in future to an
already working system).
--=20
Regards,
Kernel Panic mailto:rzh...@he...
P.S. Is there anyone else alive on this mailing list??
|
