QompOs would be part of QompItself, but there is no time yet.

The Qomp OperatingSystem, like the QompLanguage, would also make use of existing infrastructure, instead of going the OberonSystem way (something brand spanking new that few are fancy of, with no existing infrastructure).
* OberonSystem actually has quite a number of people who enjoyed the heck out of it, and find other systems quite limited in comparison.  But I see your point; people (myself included) had to relearn how to use a GUI, and most folks will not be willing to make that investment (although it only takes a day to get used to :-) ).  -- SamuelFalvo
** I actually tried it myself, but didn't spend enough time with it... I saw a chicken and egg problem (where to get users from) but still researched it greatly,  especially to land on articles or reading material about simplicity. 

It would offer unix compatibility, but encourage the users to convert their Perl/Bash style sysadmin scripts over to Qomp programs and scripts.

* QompOs would be more consistent and easier to use for system administrators, since less people would be using all sorts of different duct tape sysadmin languages... most of the sysadmin scripts and programs would all be written in Qomp, with of course some unfortunate people choosing their own favorite languages destroying the consistency a bit (NothingIsPerfect, EverythingSucks).
* QompOs would be OpenSource.
* QompOs would discourage DLL/DSO hell where possible, and store DLL/DSO's in local program directories since hard drives are big and versioning hell can be worse than the performance benefits of sharing one DLL across 5 programs.
* QompOs would look into MinixOs, PlanNine, BSD, and Windows for ideas, since Linus is not always right.
* QompOs cannot easily be described here, since I do not have time.