Hobby kernel and userspace, built mostly from scratch
github.com
github.com
[1] Still available: http://www.acm.uiuc.edu/sigops/roll_your_own/
It's actually kind of hard to translate concisely, IMO the phrase that best captures the meaning of "ToAru-OS" is "There exists an OS". But it's kind of awkward.
If we used the Raildex translation, ToAru-OS would be "A Certain OS".
As someone studying the language, can you explain what the と portion of the name means? I am aware of the ある (有る) portion, "to exist", and that と is being used here to represent a clause, eg "Xと言った" (X said), "Xと思った" (X thought).
But in this case, there's nothing before とある, so why say と at all in this case? Why not just say あるOS?
Personally, I think of the "to" as emphasizing the specificity of the phrase, if that makes sense. It's not just that "an OS", it's this specific OS that's being referenced by "aru".
If hard, why so difficult? I'm more referring to a theoretical reason, rather than practical.
Practical Reasons: - drivers are required - C/ASM is hard (ie lack of contributors) - different hardware architectures need to be supported. That part I get.
Why in theory can you not have an operating system framework that allows people to "relatively easily" build a custom kernel (instead of using Linux) the same way something like Go allows me to "relatively easily" build a custom HTTP server (instead of using Apache)?
That being said, there are several such "modular" kernels implemented on top of Xen. For example Mirage is a framework for creating free standing Ocaml applications on top of Xen.
You get all the NetBSD drivers, IP stack etc that you can use, just add memory management, setup and so on, which is not much work, and link your application in to it. It is still under development but the basic stuff is all working well.
Then there's bugs and debugging. If you have a bug in your disk driver you can slowly lose data without noticing. Quite a lot of other bugs will lock your system and you need to debug painfully from whatever logs you can find. Building in a non-C language might make this a bit easier but won't save you from the hardware locking up.
Once you've done this, what have you gained? You have an OS with no userland and no applications. What bits of Linux/BSD do you actually want to replace with something else? The code is fairly modular and OSKit exists to help with this.
The nearest to what you describe is probably retrocomputing; people building their own considerably simpler systems from the ground up. If you want a simpler platform to start on without having to first build the platform, consider Raspberry Pi; the bootloader there effectively just pulls an ARM ELF executable off the SD card and starts executing it. Have a look at https://github.com/dwelch67/raspberrypi
First have to decouple Go from its runtime before you could build a kernel in it, not to mention everything else that goes w/ writing a kernel. Similarly, you can't use significant parts of C++ when building a kernel w/ it.
It seems like a lot of people are looking at Rust as a system programming language, though... (google rust kernel)
Even though you can easily implement custom HTTP server you cannot easily implement full custom Go runtime.
From the readme
Could anybody point me in the right direction? I'm a NodeJS web developer HTML/CSS guy. What would be the shortest/fastest path to me being able to write my own entirely custom UX?
Preferably something I could do in HTML/CSS/JS and be able to run on a desktop/laptop/phone. Thanks.
You could also look at building a graphical tool-kit (think GTK/QT) that can be used to render windows and their styling.
Finally, you could look at building a window manager with a bunch of applications which look the way you would like it to. This is probably the most achievable goal, but it also offers you the least flexibility with your rendering.
A couple of other points: - I would definitely recommend targeting a non-mac *nix environment. My understanding of the situation is that on Mac and Windows their is little support for external renderers and basically none for custom window managers. - Most people would consider JS is to be a pretty bad language to write one of these systems in. You will be able to use JS as the end user application programming interface if you like (a la Gnome 3), but you will likely have a tough time writing any of the three systems mentioned above in pure JS. HTML and CSS will likely only be useful for the front-end that you expose to the end users.
Finally,
> What would be the shortest/fastest path to me being able to write my own entirely custom UX?
In the field of hobby OS/systems programming the 'shortest and fastest' route is a very bad attitude to take. Building anything in this area takes time and patience, if you skim on either of these you likely won't get far.
I hope this is helpful -- good luck! Sam
You can get a lot smaller than 5mb source on that if you're willing to ditch the X protocol. You'd end up with something like RiscOS, Amiga Workbench, PC GEM, or very early MacOS.
> shortest/fastest path to me being able to write my own entirely custom UX
Take your existing windowing environment and language tooling and ask it for a fullscreen framebuffer. Draw in that. You can be up and running in minutes.
> Preferably something I could do in HTML/CSS/JS and be able to run on a desktop/laptop/phone
.. oh. That requires an entire pile of browser machinery and is very far from 'bare metal'. Fullscreen node-webkit?