... And UNIX For All

[SoLDMG]

I made a list of things I wanted in the OS that I'm hoping to develop soon, and I'd like to hear your feedback on it, and other possible suggestions for it. The aim here is to create a UNIX-like system that is up to today's standards and applicable for everyone and everything.

Thanks in advance.

----

Things that I want from UNIX:
- A "toolbox", a set of small programs who do little on themselves, but do great things when used in co-operation with other programs (they'll probably share the same names and do the same things, so I won't have to adjust my own usage of Linux/MINIX).

Things I want for myself (mostly from the UNIX-HATERS book):
- I agree on the part about cryptic commands. I don't however want to clog up the /bin directory, so I want an "alias" function built into the shell. It sets an alias for a certain command, like "rm", and if you set an alias to "rm" as "remove" you'll run "rm" even though you typed "remove". This is user-specific, and this is different from the other "alias", as I find that something with too much functionality which could be easily removed and remain unnoticed.
- I want a sane "*" handling in the shell. It will display a yes/no question to ask you if you want to continue before bad news bears can attack and you DIY format your hard disk.
- I want a trash bin. I want this from Windows, I skipped this part in the UNIX-HATERS book. And it's logical, I mean, if a malicious shellscript "accidentally" deletes all your precious source files, you'd want to be able to get them back, right? It's logical. The trash bin will be /trash/<user>/, bundled with a file that specifies where the files were. It can be cleared using the "cleartrash" command, which removes everything in the users trash bin.
- In the previous point I talked about the deletion of files. Root directories like "/bin" will be undeletable (unless you're root and answer a yes/no-prompt), because they can be very crippling to the system if deleted.
- Better documentation. Preferably online, with complete downloads for those with bad internet.
- Better and more libraries (for better integration with the system's capabilities, for example copying and removing files within a program).

Some of these points may be adjusted later on, and more may be added.

[Bender]

- I want a trash bin. I want this from Windows

Are you sure? I think the trash bin is pretty much related to the Windows UI shell. 'Cause:

Code: Select all

C:\Users\GNUPC>del samplefile.bin

And nothing was there in the Recycle Bin. . Also, most Linux UIs provide a trash bin or something similar.
Yeah, but I like the idea of having something like /dev/trash/<username> or just /trash/...

[iansjack]

Congratulations - you have just described any modern Linux distribution. Now what is going to distinguish yours from all the others, and why not just use the Linux kernel and GNU utilities if all you want is to clone them?

[SoLDMG]

Congratulations - you have just described any modern Linux distribution. Now what is going to distinguish yours from all the others, and why not just use the Linux kernel and GNU utilities if all you want is to clone them?

- Monolithic kernels like Linux are flawed. Of course, Linux and BSD are very stable, but microkernels are the way to go when combined with reincarnation servers.

[SoLDMG]

- I want a trash bin. I want this from Windows

Are you sure? I think the trash bin is pretty much related to the Windows UI shell. 'Cause:

Code: Select all

C:\Users\GNUPC>del samplefile.bin

And nothing was there in the Recycle Bin. . Also, most Linux UIs provide a trash bin or something similar.
Yeah, but I like the idea of having something like /dev/trash/<username> or just /trash/...

Just the general idea of a trash bin will be implemented. And every deleted file will go there, instead of either marking a sector writeable or only pushing it off to the bin when you're using a GUI.

[bluemoon]

Things that I want from UNIX:
- A "toolbox", a set of small programs who do little on themselves, but do great things when used in co-operation with other programs (they'll probably share the same names and do the same things, so I won't have to adjust my own usage of Linux/MINIX).

This is arguable as part of the OS. Yet an OS may ship with those toolbox but no one would agree on the definition on small.
FreeBSD 10 now even do not ship with gcc and rely on the package manager to install it if needed.

Things I want for myself (mostly from the UNIX-HATERS book):
- I agree on the part about cryptic commands. I don't however want to clog up the /bin directory, so I want an "alias" function built into the shell. It sets an alias for a certain command, like "rm", and if you set an alias to "rm" as "remove" you'll run "rm" even though you typed "remove". This is user-specific, and this is different from the other "alias", as I find that something with too much functionality which could be easily removed and remain unnoticed.
- I want a sane "*" handling in the shell. It will display a yes/no question to ask you if you want to continue before bad news bears can attack and you DIY format your hard disk.

Many serious shell program support alias and wildcard. Some also blocks "rm -rf /" and other harmful actions and only proceed if you solve a differential equation.
Again a shell may be shipped with an OS, but it should not be tightly coupled with the OS.

- I want a trash bin. I want this from Windows, I skipped this part in the UNIX-HATERS book. And it's logical, I mean, if a malicious shellscript "accidentally" deletes all your precious source files, you'd want to be able to get them back, right? It's logical. The trash bin will be /trash/<user>/, bundled with a file that specifies where the files were. It can be cleared using the "cleartrash" command, which removes everything in the users trash bin.

The good news is, next-generation OS is moving to fully versioned system. Trash bin is not a good way to manage trash since user do empty them accidentally.

- In the previous point I talked about the deletion of files. Root directories like "/bin" will be undeletable (unless you're root and answer a yes/no-prompt), because they can be very crippling to the system if deleted.

Modern systems support protection on system files in some way. Even in Linux you can't delete /bin without going su.

[SoLDMG]

This is arguable as part of the OS. Yet an OS may ship with those toolbox but no one would agree on the definition on small.
FreeBSD 10 now even do not ship with gcc and rely on the package manager to install it if needed.

I think that a minimal devtool collection (C compiler, assembler, linker, etc.) should always be shipped with an OS install disk, but optional to install.

Many serious shell program support alias and wildcard. Some also blocks "rm -rf /" and other harmful actions and only proceed if you solve a differential equation.
Again a shell may be shipped with an OS, but it should not be tightly coupled with the OS.

I just found out that via Wikipedia that the UNIX-HATERS book is quite outdated, but that some aspects still are an issue to this day. I do agree, a shell should be portable across multiple systems, but it is just for my OS that those functions will be implemented in the shell.

[quote="bluemoon]
The good news is, next-generation OS is moving to fully versioned system. Trash bin is not a good way to manage trash since user do empty them accidentally.
[/quote]
I'm more for regular (like once every 2-3 days) system backups (including trash) than a full-blown version control system just for trash handling. Seems to me like a waste of processor time.

Modern systems support protection on system files in some way. Even in Linux you can't delete /bin without going su.

Again, the UNIX-HATERS book is outdated. Still, it puzzles me why it would be allowed in ancient UNIX. That's like allowing knives on an airplane (that was legal until 9/11).

[bluemoon]

Still, it puzzles me why it would be...

In the good old day, the philosophy is assume the user (or programmer) is correct.
For the bloody history, we realised human, including the unix inventors, do make mistakes.

[SoLDMG]

In the good old day, the philosophy is assume the user (or programmer) is correct.
For the bloody history, we realised human, including the unix inventors, do make mistakes.

Thankfully we finally did.

[iansjack]

Congratulations - you have just described any modern Linux distribution. Now what is going to distinguish yours from all the others, and why not just use the Linux kernel and GNU utilities if all you want is to clone them?

- Monolithic kernels like Linux are flawed. Of course, Linux and BSD are very stable, but microkernels are the way to go when combined with reincarnation servers.

Ah, I was going by your stated objectives; this is a new requirement. I wish you well considering the time it has taken to not perfect the GNU version of such a kernel.

A good individual research project though.

[linguofreak]

Congratulations - you have just described any modern Linux distribution. Now what is going to distinguish yours from all the others, and why not just use the Linux kernel and GNU utilities if all you want is to clone them?

- Monolithic kernels like Linux are flawed. Of course, Linux and BSD are very stable, but microkernels are the way to go when combined with reincarnation servers.

Certainly monolithic kernels are less than ideal, but currently available CPUs aren't great for building microkernels on, plus the memory model assumed by Unix and C (as well as by Windows nowadays) does not lend itself well to microkernels.

[SoLDMG]

Congratulations - you have just described any modern Linux distribution. Now what is going to distinguish yours from all the others, and why not just use the Linux kernel and GNU utilities if all you want is to clone them?

- Monolithic kernels like Linux are flawed. Of course, Linux and BSD are very stable, but microkernels are the way to go when combined with reincarnation servers.

Ah, I was going by your stated objectives; this is a new requirement. I wish you well considering the time it has taken to not perfect the GNU version of such a kernel.

A good individual research project though.

That's what I thought as well. It'd be easier to implement with a group but "surprisingly" *sarcasm* only one guy was interested. Oh well, I'll do it anyway and maybe later people will want to participate.

[SoLDMG]

Certainly monolithic kernels are less than ideal, but currently available CPUs aren't great for building microkernels on, plus the memory model assumed by Unix and C (as well as by Windows nowadays) does not lend itself well to microkernels.

Care to elaborate so I won't be surprised later on? I'm assuming you're talking about paging and taskswitching, right?

[iansjack]

It'd be easier to implement with a group

I think you are completely wrong there. I would say that such a research project needs good leadership if it is to be implemented by a group, which you have already indicated you are not prepared to supply. I think it will be much easier to do this a a single-person project so that you don't have to worry about people not agreeing with your concept of how things should be.

Once you have proper specifications, a workable plan of how to implement them, and some well-written code you may be able to pursuade people that your ideas are so good that they could profitably work with you. I'm afraid that, with what you have given us so far, you are unlikely to attract people with the knowledge and skills to be of any real use to you.

[linguofreak]

Certainly monolithic kernels are less than ideal, but currently available CPUs aren't great for building microkernels on, plus the memory model assumed by Unix and C (as well as by Windows nowadays) does not lend itself well to microkernels.

Care to elaborate so I won't be surprised later on? I'm assuming you're talking about paging and taskswitching, right?

Yeah, pretty much. Microkernels tend to implement the functionality traditionally provided by monolithic kernels with server processes (because of the memory model provided by most CPUs), but the thing is that many of those functionalities are better provided by a shared library. The difference between kernel-type shared libraries and userland shared libraries is that userland shared libraries only need access to the data areas of the tasks that call them, whereas kernel-type shared libraries have their own data that the code calling the library has to be prevented from accessing directly.

The solution to this in monolithic kernel systems on traditional hardware is to map the kernel-type libraries and their private data into an area that only kernel-type libraries can access. This protects their private data from userland code without significantly slowing down access to the libraries, but has the disadvantage of not protecting the libraries' private data areas from other kernel-type libraries. To protect the kernel-type libraries from each other on a traditional CPU, you have to move them into separate server processes and have other programs access their functionality via IPC, which slows things down. For some things (disk and user I/O), this may be acceptable, as there are often considerable latencies involved in waiting for the hardware or the user anyways. In these cases userland implementations of the relevant functionality often already exist for Linux.

An architecture that I think would work better for a microkernel than anything that currently exists would be something like this:

Start with Intel segmentation. Instead of having each segment descriptor specify a base in a paged address space defined elsewhere, have it specify a page directory so that the segment is its own paged address space.

The global descriptor table (or a set of global descriptor tables defined by a global descriptor directory) contains a descriptor for every segment that exists on the system. Programs cannot load selectors pointing into the GDT directly.

The local descriptor table, rather than containing a list of descriptors in the same format as the GDT, as on Intel systems, is an indirection layer on top of the GDT. When a program performs a segment load, the CPU uses the selector as an index into the LDT. An LDT descriptor consists of a selector pointing into the GDT and possibly some permission bits. The CPU uses the selector in the LDT descriptor to find the appropriate segment descriptor in the GDT and loads the segment register in question with information from the GDT descriptor (such as the page directory for that segment).

The GDT descriptor for each segment contains a field associating an LDT with that segment. At any given moment, there are two LDTs active, one for the current code segment, and one for the current stack / thread local data segment. Using a selector with the most significant bit cleared to load a segment register causes the low order bits of the selector to be used as an index into the LDT for the current code segment, using a selector with the most significant bit set causes the LDT for the current stack segment to be used.

If a program needs to call a library that has private data (lets say that the library is a device driver, and the private data has to do with multiplexing access to the device), it makes a far call to the library's code segment. This causes the library's LDT to be loaded as the code LDT. The segment containing the library's private data is mapped in the library's LDT, allowing the library to load that segment to access its private data. The library does its work, then invalidates the segment register that it used to access its private data segment and makes a far return to the original program's code segment. This causes the program's LDT to be loaded. The program's LDT does not have the library's private data segment mapped, which prevent the program from accessing the library's private data.