after a nuclear war, the remaining people will probably not be able to spin up a modern operating system on their improvised chips. How do you build a simple, reliable, legacy-free OS from scratch? What ideas 💡 and techniques should be passed down to those people?
If we think hard enough about this, I think we’ll agree that closed-source systems are basically designed to be almost impossible for people outside the sponsoring organization to reproduce (for an example, consider [ReactOS](https://reactos.org/), which launched as [a project to produce a system compatible with Windows 95](https://reactos.org/wiki/FreeWin95) and [then changed to focus on Windows NT](https://reactos.org/wiki/ReactOS/History), and after more than 25 years, is still not capable of being a daily use system.
But we may also determine that most open-source systems are likewise not designed in such a way that reconstruction is viable. The Linux kernel is *huge* these days.
Additionally, in my opinion, they’d probably want to use programming languages designed for readability, ease of learning, and error-reduction first (that is, more like #COBOL than #C, more like #Java than #CPlusPlus, more like !Smalltalk and #Lisp / #Scheme than #Perl / #Raku and #JavaScript) and then performance and low-level access.
I think it is a mistake to assume that one could start with a modern version of #gcc or #llvm or #msvc … because it is not a given that the software itself and someone who knew how to use it (and update, modify, and adapt it) would still exist.
Interact with end users on technical problems. Tier 1, 2 and 3 support for #CentOS and related open source products. Drive resolution of those problems, which include: Open source software issues. Questions around open source software usage. Questions around use and best practices. Review of the architecture and design where software is implemented. Conduct professional services and training engagements. Research, understand, and advocate open source software. Interact with various open source communities. Drive early resolution of issues. Make strategic contributions to the CentOS core and surrounding ecosystem, provide bug fixes ahead of the community where needed Be a part of the on-call rotation. Present knowledge via articles, blogs, and conference presentations.
Requirements:
Technical knowledge, skills and expertise in complex infrastructure, web-based software and enterprise software Strong knowledge of the Linux #kernel and system architecture. Understanding of software best practices; #SDLC, #SCM and #Agile development principles. Ability to develop with #C / #C++ in a UNIX environment. Utilization of common #Linux C/C++ build tools such as #gcc. Solid understanding of CentOS 6.x and 7.x and included frameworks like #firewalld, #systemd, etc. Strong #RHEL/CentOS background required #Debian / #Ubuntu, #SUSE / #openSUSE / #SLES, other distro background a bonus C, shell scripting, #perl, etc Virtual Machine experience with #qemu / #kvm, #Azure, #AWS, #VirtualBox, #Vagrant General experience such as: radius/Kerberos, lda, ipa/idm, monitoring, vpn, containers, centralized systems management, automation (ansible, chef, puppet, etc), version control (git, etc) or security hardening (CIS, STIGS, PCI-DSS, etc) Excellent written, verbal, and presentation skills Knowledge of open source packages Database administration; #postgresql / #mysql / #mariadb experience very desirable Experience with Linux distro package building (#rpm, #deb, #ipkg, etc) preferred Existing contributions to the CentOS community a major plus
It uses a Forth for bootstrapping a LISP, which in turn will be able to to make progressively more generic things.
The #mes project has a mini-scheme that implements a C compiler that can soon compile #tcc well enough to compile #gcc. A future iteration of mes will be using stage0.
This is all useful for building a whole OS from mostly source and just a few hundred bytes of machine code.