4 ms·

Their OS is written in Zig! https://github.com/Ashet-Technologies/Ashet-OS Thought it might be of interest to people learning Zig. I bet there are some in

Their OS is written in Zig! https://github.com/Ashet-Technologies/Ashet-OS Thought it might be of interest to people learning Zig. I bet there are some interesting examples in there.

anitil 1y ago
I've been following Andrew Kelley's writing and zig is probably next on the list for me (previously would have been rust). The story from C to Zig and the ease of cross compilation makes it really tempting. I haven't looked in to the comptime capabilities much but it looks like it could help with some of the embedded work I do
rollcat 1y ago
The OS looks highly opinionated and I respect that. Better to have a single overarching vision than try to do too many things poorly. However I will question some design choices! - 32-bit only: the writing is on the wall, many vendors (HW&SW) are slowly moving to kill it off. I guess it's fine, but IMHO each ISA (regardless of pointer width) should just be considered a different ISA. Portability is good, it ensures your software doesn't hardcode too many assumptions about the platform - and weeds out bugs. Just treat an int like an int, and a pointer like a pointer. Distinct types. - Pure co-op multitasking: it will be completely fine, until you try serious in-system development. Hard reboot any time I make a mistake in a for-loop? Mercy, please :,) Implementing a simple watchdog via a timer interrupt will still keep all of the scheduling logic simple and stupid: it's just another case for a yield call, except now involuntary. The runaway process will simply never see completion, but seeing that it would never yield anyway, I don't see a problem just killing it. And most importantly, the sanity shall be preserved.
- ikskuh 1y ago
  Creator here! Yes, the OS is highly opinionated, as just making another linux is incredibly boring for me! The 32-bit only constraint is mainly due to my focus on smaller architectures, especially microcontrollers. x86_64 and aarch64 both have much more complex initialiastion schemes, and also use much more complex page table setups. Thus, i wanted to keep that out of the system, considering i'm targeting systems with a tiny fraction of the 4 GiB memory limit. The co-op multitasking is a part of the OS, and the OS doesn't give you preemptive multitasking. I never said i won't implement sanity safeguards! Just killing off a hanging process that doesnt yield for more than 1-5 secs is totally i scope and increases user friendlyness. but considering the system reboots in 1.2 s on target hw right now, the user will maybe just have hit reset by then :D
  - rollcat 1y ago
    > considering the system reboots in 1.2 s That's not the point - it's about usability. You'd be constantly losing work. > Just killing off a hanging process that doesnt yield [...] <3 !

Their OS is written in Zig! https://github.com/Ashet-Technologies/Ashet-OS Thought it might be of interest to people learning Zig. I bet there are some interesting examples in there.

anitil 1y ago

I've been following Andrew Kelley's writing and zig is probably next on the list for me (previously would have been rust). The story from C to Zig and the ease of cross compilation makes it really tempting. I haven't looked in to the comptime capabilities much but it looks like it could help with some of the embedded work I do

rollcat 1y ago

The OS looks highly opinionated and I respect that. Better to have a single overarching vision than try to do too many things poorly. However I will question some design choices! - 32-bit only: the writing is on the wall, many vendors (HW&SW) are slowly moving to kill it off. I guess it's fine, but IMHO each ISA (regardless of pointer width) should just be considered a different ISA. Portability is good, it ensures your software doesn't hardcode too many assumptions about the platform - and weeds out bugs. Just treat an int like an int, and a pointer like a pointer. Distinct types. - Pure co-op multitasking: it will be completely fine, until you try serious in-system development. Hard reboot any time I make a mistake in a for-loop? Mercy, please :,) Implementing a simple watchdog via a timer interrupt will still keep all of the scheduling logic simple and stupid: it's just another case for a yield call, except now involuntary. The runaway process will simply never see completion, but seeing that it would never yield anyway, I don't see a problem just killing it. And most importantly, the sanity shall be preserved.

ikskuh 1y ago
Creator here! Yes, the OS is highly opinionated, as just making another linux is incredibly boring for me! The 32-bit only constraint is mainly due to my focus on smaller architectures, especially microcontrollers. x86_64 and aarch64 both have much more complex initialiastion schemes, and also use much more complex page table setups. Thus, i wanted to keep that out of the system, considering i'm targeting systems with a tiny fraction of the 4 GiB memory limit. The co-op multitasking is a part of the OS, and the OS doesn't give you preemptive multitasking. I never said i won't implement sanity safeguards! Just killing off a hanging process that doesnt yield for more than 1-5 secs is totally i scope and increases user friendlyness. but considering the system reboots in 1.2 s on target hw right now, the user will maybe just have hit reset by then :D
- rollcat 1y ago
  > considering the system reboots in 1.2 s That's not the point - it's about usability. You'd be constantly losing work. > Just killing off a hanging process that doesnt yield [...] <3 !