OSDev.org

I have seen quite a number of OS implement snaps and all those ad-hoc utilities made me think: if you are implementing a UNIX-like, should you just implement all required routine calls like port newlib and throw GNU coreutils (and maybe also bash) onto it? Porting GNU coreutils and GNU bash can be a challenging task, but if the port is successful using the system will be a lot easier. (try maintain the system with some pretty shell scripts? Or maybe use init scripts that is interpreted by bash?)

EDIT: Count dash (Debian's Almquist shell) in too, as it is largely compatible to bash but a lot lighter. Also, busybox instead of GNU coreutils+bash/dash

Yo:

Well, I'd say that porting software in general is good: kernels are all about abstracting the hardware for other software to use. If nothing ends up being run on the kernel's userspace, it is a bit of a wasted effort, at least from a "completeness" aspect.

Whichever apps you'd prefer to target for porting are up to you

--Peace out,
gravaera

If you do this, your system will make quick progress and it will feel like yet another Unix. If you consider this good or bad is a matter of taste.

I like to implement the entire core system myself (kernel, libc, system libraries and programs, most utility programs, ...) and then port the programs I don't want to write (such as the compiler). Once my C library and kernel got functional enough, it became possible to port third-party software. I've ported a bunch of GNU software, which has helped a lot fill in the missing pieces expected from an Unix environment. In particular, I've had luck porting GNU binutils, GNU bison, GNU compiler collection, GNU diffutils, GNU gettext, GNU gmp, GNU grep, GNU groff, GNU gzip, GNU hello, GNU libiconv, GNU m4, GNU make, GNU mpc, GNU mpfr, GNU patch, GNU sed, GNU tar, and GNU tls. The GNU userland is great to port because it started out as portable (there was no GNU system yet at the time), so people have been porting them ever since. The autoconf/configure scripts can be ugly, but they are the porter's best friend.

If you are just starting out, don't think too much about this yet. Focus on implementing the kernel and supporting a good C library (whether you made it yourself or ported one). You can then try to cross-compile software and see what works and what doesn't. It's hard to predict what a software package needs from libc and this is work for long down the road.