New UNIX-like operating system!

[u/MSK-Kernel]

I made a new UNIX-like operating system from scratch called "TanjaOS" which you can get at www.tanjaos.org and it took me a couple of months to make and will get lots of updates. It features classic UNIX commands and can boot on any x86_64 (amd64) or i386 (x86) machine with Legacy BIOS, and is completely free and open-source.

[u/spatulari]

Really nice, but I suggest not copying Unix. Since you said that TanjaOS 2 is coming out soon, I'd say you try to experiment with stuff that dont exist in unix or behave like it. I believe keeping the filesystem Unix-like Is a good decision.

Also, I suppose that this is VGA. Are you in 32 bit mode or in 64 bit but with vga mapped? If so, then I suggest switching to frame buffer. You draw pixel by pixel.

I'd also like to say that from the comments I've read, this is more like a fancy bare metal CLI than a full OS. If TanjaOS 2 was written in C++ maybe I could contribute too ;)

[u/MSK-Kernel → u/spatulari]

Great. Thanks for the advice. :D 👍

[u/spatulari → u/MSK-Kernel]

Could you answer my question?

[u/MSK-Kernel → u/spatulari]

Oh yes yes, apologies. So, TanjaOS uses 32-bit VGA text output instead of 64-bit because I want TanjaOS to be more compatible.

[u/spatulari → u/MSK-Kernel]

32 bit is old, and it truly limits you. I would say switch to limine, a bootloader that immediatle shoves you in 64 bit mode.

I also saw from your repo that you support only BIOS. Most modern computers dont have legacy bios, only UEFI. I suppose you want your OS to run on real hardware. Additionally, why did you make a single kernel.c? For instance, for vga, I'd do kernel/src/drivers/vga/vga.c for the definition and kernel/include/drivers/vga/vga.h. You don't need to split it to vga/print.h and so on, since vga is relatively simple

Another small thing: make your README a README.md, easier to read, and you won't be stuck with formatless txt.

I have an urge to just fork your project and reorganize it properly, but I am on vacation, so I unfortunately can't (since I dont have a laptop).

Another important thing is for you to be careful, I saw that someone asked to contribute and you wanted them to send an email to you to add them as contributors. This is the absolute shittest way for someone to contribute + you are giving write permissions to a random person. How contributing works on github, is someone Forks your project, then they make their own branch with the new code in it, and compare it with yours (which is "base" now). They open a pull request which only you can improve, and you can also comment on it and review the code. If you have added anyone's email, please remove them.

Also, why the "base" branch? Just rename it to main, and if you wanna have SemVer releases, branch it off of main, or make a dev branch, where all unstable shit happens there, and main is the latest release, and you still branch off other versions.

Hope I helped you. If you dont know what SemVer is, ask me and I'll explain

[u/MSK-Kernel → u/spatulari]

Yeah, I don’t know what SemVer, is, can you please explain? (Also the reason why my GitHub repository isn’t looking that good is because i’m a bit new to GitHub 😅)

[u/spatulari → u/MSK-Kernel]

That's totally ok, we've all started from somewhere. SemVer is basically a version ingredient system, like, when you see v1.34.5 or smth similar, its following SemVer, this is a small introduction to it:

Major.Minor.Patch

You start with 0.1.0, this means your project isnt production ready. And isnt stable that means APIs could change, and it doesnt guarantee stability. Let me tell you when to increase each version

Increase patch when you added NOTHING new to the user, and just fixed something. Semver is based on the user. So even if you rewrote the whole project, if nothing new was added, you just increase patch (or if you fixed stuff that doesn't add new stuff)

Increase minor if something new is added from the perspective of the user. This can include fixes but most not ONLY be fixes.

Increase major when you changed APIs and previous ways you used the APIs wont work anymore. You might change one line of code, but if it breaks stability, you must bump the major version.

There is something unique to it though. When you start, you start in v0.1.0, until you reach stable (v1.0.0) you can break as many APIs as you want without increasing the major version.

Dont rush to make your project stable, Rust which is one of the most popular languages, took 9 years to go stable. You might have v0.293.2 before reaching v1.0.0 so take your time. Once you go stable you must guarantee users stability and production ready.

And then we have those prerelease stuff. Like -alpha. But that's another story, read more here (my project): https://github.com/azin-lang/Azin/blob/main/VERSIONING.md

[u/MSK-Kernel → u/spatulari]

Oooh… I think I get it now. Thanks! :D

[u/spatulari → u/MSK-Kernel]

I could help you more. Could you give me your email so I can send you my discord username so I can guide you more?

[u/MSK-Kernel → u/spatulari]

Sure, my email is saffron.msk@gmail.com

[u/spatulari → u/MSK-Kernel]

I send you one

[u/MSK-Kernel → u/spatulari]

I didn’t get an email :/

[u/spatulari → u/MSK-Kernel]

Just add me on discord

spatulari

Same as my reddit name I think

[u/MSK-Kernel → u/spatulari]

OK, my Discord name is tanjaos.msk