TumuxOS
TumuxOS
After reading some book, articles, wikis and other os project, I want to start my own. But why my own OS and not helping somone else ? I'd like to learn OS dev from A to Z and I think the best road for that is doing it.
By the way, because I am an original person with a fine sense of humor, Tumux stand for "Tutul Make a UniX like" ^^"
What's the plan ?
Curently, I want tumux to be a posix compliant with multiboot v2 support. I will try to be as up-to-date as possible and using standard from GNU world and other. Posix would make porting GNU app easier.
I try to plan tumux as a micro-kernel. But, by definition, it'll be more like as modular as possible. Probably between both concept. Both ? yea because I plan to write a kernel with only memory and cpu managment, and high level of virtualisation for other stuff. If I go where I want, tumux would required modules to access all hardware. I think modular kernel aren't so module dependent. But micro-kernel use service into userland. So I think I more a mix of both.
Do I want help
Yes and no. It can be very interrsting to have other point of view and all constructive criticism is good for me. But I don't want to manage a team and I don't want to be constrained.
But I try to make the code readable, with comment and doc. So other people can read and help. Try to keep the code clean and keep in mind that one day maybe, these project will be bigger (dream but force me to keep code nice).
And script for automatic build is ready, clean script too.
So if you want to see, you're welcom. Try using fork/pull request
What's working
Not very much at thse time. My kernel boot from multiboot v2 compliant bootloader (grub2). Initialize paging and use higher half principle.
Because I code most of the time on a limited laptop, compilation time for testing is too big. So I use a testing git branch for that. Making it ugly.
Curently, I'm writing a minimalist C loader code into the kernel to setup paging for kernel, low and MBI and manage almost all kind of problem during the early stage.
I will try to keep some up-to-date informations here but the best place to check is the git.
TumuxOS github : https://github.com/Tutul-/tumuxOS
no website for now because it's not very usefull at these point!
The all project is under MIT license (check https://github.com/Tutul-/tumuxOS/blob/master/LICENSE, because I know it's not the real name for it so check wich one on that link).
By the way, because I am an original person with a fine sense of humor, Tumux stand for "Tutul Make a UniX like" ^^"
What's the plan ?
Curently, I want tumux to be a posix compliant with multiboot v2 support. I will try to be as up-to-date as possible and using standard from GNU world and other. Posix would make porting GNU app easier.
I try to plan tumux as a micro-kernel. But, by definition, it'll be more like as modular as possible. Probably between both concept. Both ? yea because I plan to write a kernel with only memory and cpu managment, and high level of virtualisation for other stuff. If I go where I want, tumux would required modules to access all hardware. I think modular kernel aren't so module dependent. But micro-kernel use service into userland. So I think I more a mix of both.
Do I want help
Yes and no. It can be very interrsting to have other point of view and all constructive criticism is good for me. But I don't want to manage a team and I don't want to be constrained.
But I try to make the code readable, with comment and doc. So other people can read and help. Try to keep the code clean and keep in mind that one day maybe, these project will be bigger (dream but force me to keep code nice).
And script for automatic build is ready, clean script too.
So if you want to see, you're welcom. Try using fork/pull request
What's working
Not very much at thse time. My kernel boot from multiboot v2 compliant bootloader (grub2). Initialize paging and use higher half principle.
Because I code most of the time on a limited laptop, compilation time for testing is too big. So I use a testing git branch for that. Making it ugly.
Curently, I'm writing a minimalist C loader code into the kernel to setup paging for kernel, low and MBI and manage almost all kind of problem during the early stage.
I will try to keep some up-to-date informations here but the best place to check is the git.
TumuxOS github : https://github.com/Tutul-/tumuxOS
no website for now because it's not very usefull at these point!
The all project is under MIT license (check https://github.com/Tutul-/tumuxOS/blob/master/LICENSE, because I know it's not the real name for it so check wich one on that link).
- max
- Member
- Posts: 616
- Joined: Mon Mar 05, 2012 11:23 am
- Libera.chat IRC: maxdev
- Location: Germany
- Contact:
Re: TumuxOS
Hey bro,
Wish you good luck with your project!!:)
Greets
HahaTutul wrote:By the way, because I am an original person with a fine sense of humor, Tumux stand for "Tutul Make a UniX like" ^^"
Wish you good luck with your project!!:)
Greets
Re: TumuxOS
Thanks. Actually your kernel is one of my inspiration ^^'
Re: TumuxOS
This is just my personal opinion, but don't take POSIX seriously.
The scope of POSIX is probably a lot larger than you think it is. It's so large in fact, that the OpenGroup knows it's unreasonable to expect operating systems to implement all of it, and arbitrarily decides that certain functionality is *compliant*, but not *required*. Which is to say that a program that's POSIX compliant isn't actually guaranteed to be able to be compiled for and executed on a POSIX system. POSIX also completely skips important stuff like user/group management, and standardizes a lot of stuff that's completely obsolete-on-arrival like catgets and SCCS source control. Some decisions are completely nonsensical like 0.5KiB block sizes for `df` / `du` / `tar` and how options are passed to `grep`; hence the existence of the POSIXLY_CORRECT environment variable and it's alias, POSIX_ME_HARDER. Even worse, POSIX has actually deprecated (made legacy) stuff that clearly *IS NOT* or *SHOULD NOT* be deprecated, like:
The scope of POSIX is probably a lot larger than you think it is. It's so large in fact, that the OpenGroup knows it's unreasonable to expect operating systems to implement all of it, and arbitrarily decides that certain functionality is *compliant*, but not *required*. Which is to say that a program that's POSIX compliant isn't actually guaranteed to be able to be compiled for and executed on a POSIX system. POSIX also completely skips important stuff like user/group management, and standardizes a lot of stuff that's completely obsolete-on-arrival like catgets and SCCS source control. Some decisions are completely nonsensical like 0.5KiB block sizes for `df` / `du` / `tar` and how options are passed to `grep`; hence the existence of the POSIXLY_CORRECT environment variable and it's alias, POSIX_ME_HARDER. Even worse, POSIX has actually deprecated (made legacy) stuff that clearly *IS NOT* or *SHOULD NOT* be deprecated, like:
- cc - the c compiler (replaced with c89, which was then deprecated again for c99. no c11 yet, but give it time.)
- cpio - archival tool used by redhat for the distribution of packages, which can copy files in and out of archives
- tar - the tape archival tool used by literally EVERYONE in the open source community.
- dis - disassembler
Re: TumuxOS
Thanks for you message. I don't plan to be 100% POSIX. But as most as I can be without becoming old school or laking good security or with lack of functionnality I want.
I use posix to have a base to build on. I don't plan to redone UNIX again. But I've to admit that POSIX, UNIX and others are a good base to learn from the past and check what part to keep and what part are obsolet.
I think about POSIX first to try to make porting some app easier. Like GNU stuff. I will read some Linux and BSD stuff too. But I don't like some concept that Linux use. Don't know now if it's because I don't know enought about OS or because Linux is a big blop of old and new stuff (like a frankenstein monster with a really nice look).
I'm currently looking for other standard in the open source community. Tumux is young enougt to decide that later. Most of it are for kernel to userland and upper area than just kernel initialization.
I'm also planning to be modern. With support for legacy i386 (easier to begin with that part but planning to go more modern with avoiding frankenstein as much as possible).
As I said, I want to try some concept in mind but I need a base to begin with
I will probably go without posix later, or with a posix compatibility layer in userland. Don't know for now. It's part of the adventure and I'm quite exited about that ^^
I use posix to have a base to build on. I don't plan to redone UNIX again. But I've to admit that POSIX, UNIX and others are a good base to learn from the past and check what part to keep and what part are obsolet.
I think about POSIX first to try to make porting some app easier. Like GNU stuff. I will read some Linux and BSD stuff too. But I don't like some concept that Linux use. Don't know now if it's because I don't know enought about OS or because Linux is a big blop of old and new stuff (like a frankenstein monster with a really nice look).
I'm currently looking for other standard in the open source community. Tumux is young enougt to decide that later. Most of it are for kernel to userland and upper area than just kernel initialization.
I'm also planning to be modern. With support for legacy i386 (easier to begin with that part but planning to go more modern with avoiding frankenstein as much as possible).
As I said, I want to try some concept in mind but I need a base to begin with
I will probably go without posix later, or with a posix compatibility layer in userland. Don't know for now. It's part of the adventure and I'm quite exited about that ^^
Re: TumuxOS
The security model of Unix systems isn't all it's cracked up to be. It assumes that all attacks come from the inside. Like your biggest threat is that your little brother is going to jump on your computer and install spyware when you step away to make a cup of coffee. (Interesting Trivia - the passwords of users used to be stored as plain-text in /etc/passwd. It took hundreds of times of people being "hacked" for users to come up with the idea to delegate the passwords to a separate encrypted file (/etc/shadow) with restricted read/write permissions). The fact that the security of Windows' systems is much worse is a red herring.
Sadly, there are no competing standards with POSIX, but I think a good way to start would be by asking yourself what an operating system does and why. For file systems, I recommend reading up about Plan9, SmallTalk, and relational databases. It'll completely change how you view them altogether. For multitasking, I suggest reading about CSP and Erlang; they're 2 different (yet compatible) perspectives on the topic of parallel computing. For graphics, I suggest completely ignoring any and all material about display servers, window managers, etc. It's an overengineered load of bullocks. The traditional desktop is a 2D projection of a 3D scene. Once you acknowledge that, it should be almost intuitive how much simpler you can make the design and the endless possibilities you can have for a user interface.
Sadly, there are no competing standards with POSIX, but I think a good way to start would be by asking yourself what an operating system does and why. For file systems, I recommend reading up about Plan9, SmallTalk, and relational databases. It'll completely change how you view them altogether. For multitasking, I suggest reading about CSP and Erlang; they're 2 different (yet compatible) perspectives on the topic of parallel computing. For graphics, I suggest completely ignoring any and all material about display servers, window managers, etc. It's an overengineered load of bullocks. The traditional desktop is a 2D projection of a 3D scene. Once you acknowledge that, it should be almost intuitive how much simpler you can make the design and the endless possibilities you can have for a user interface.
Re: TumuxOS
Thanks for that
Re: TumuxOS
Are you really familiar with the NT-security model, or it's just a blind unix-zealot mantra "yes, we suck but windows sucks moar"? If first, then could you please elaborate on what and how exactly is "much worse" there compared to unix rwx---r-r-r BS (best security )? I am genuinely interested, because I am learning it and planning to implement it, for me this is one of the most challenging parts in NT, it would be interesting to hear different views on the subject. from the knowledgeable people.Wajideus wrote: The fact that the security of Windows' systems is much worse is a red herring.
Re: TumuxOS
It's true that the NT permission system is more acurate for multi-user.
Unix-like come with the old ugo permission and a very complexe subgroup management to authorize multiple user or group.
It can be enough for small security like blocking all except root or prohibit the execution.
But NT come with special permission but I don't see when it can be usefull. Maybe an other system can be found. Or the best of the both.
Unix-like come with the old ugo permission and a very complexe subgroup management to authorize multiple user or group.
It can be enough for small security like blocking all except root or prohibit the execution.
But NT come with special permission but I don't see when it can be usefull. Maybe an other system can be found. Or the best of the both.
Re: TumuxOS
The entire point of that statement was to argue the irrelevance of the security of Windows' systems (that's what a red herring is). If anything, I was arguing *against* Unix-zealotry. The main reason why the Unix security model is slightly better has to do with the reduced number of attack vectors. Most security is enforced based on user / group id. This is done using the setuid and setgid functions, and the kernel can use a whitelist to restrict access to those functions.zaval wrote:Are you really familiar with the NT-security model, or it's just a blind unix-zealot mantra "yes, we suck but windows sucks moar"?Wajideus wrote: The fact that the security of Windows' systems is much worse is a red herring.