important-guidelines/README.md

Null Linux is a Linux distribution that aims to be the Linux distribution with the lowest ram consumption that can still run a Graphical User Interface (GUI).

Null Linux attempts to accomplish the goal of fitting a functional GUI within 32 Megabytes of memory, by using extremely small and hand-made software made by the Null Linux Project Contributors.

Null Linux is a natural successor of TinyCore Linux.

Some pieces of software Null Linux attempts to modify (under correct licensing) or create to have the lowest memory allocations and usage possible:

• Several Patches to the Linux Kernel
• Fork of TWM
• Custom Made LIBC Implementation.
• A built from scratch, POSIX Compliant Coreutils implementation
• A fork and stripped down version of DASH Shell
• A hand-rolled DRM wrapper library.
• Stripped Down version of the runit init/PID1

Project Guidelines

1. C17, and only C17. All Null Linux created or modified software will be in C17. If the project uses compiler-specific extensions, you must force a single C17-compatible compiler in the build system with no fallback.

2. Autotools or Makefile, nothing else. All C projects can use either the GNU Autotools build system or a hand-created GNU Makefile. CMake, Meson, or any other build system is strictly not permitted.

3. AI drafts, humans ship. The use of Artificial Intelligence IS permitted, but should be manually reviewed by living breathing Homo sapiens sapiens. AI work should be the draft, not the finished product.

4. Repository structure. Every repository must follow a loose structure, but must remain similar to:

include/              Your headers. Headers do not mix with implementations.
src/                  Said implementations.
Makefile              Or configure.ac + Makefile.am (autogen.sh is required for autotools).
bin/{release,debug}   Debugging should be in the workflow. Nothing is bug free. Release is
                      ALWAYS -O2 or -O1, unless you give a damn good reason why it isn't.
                      Examples include: compiler bugs, breaking optimizations.
benchmarks/           You MUST benchmark your software. If it isn't memory-lean, it's not
                      going in Null Linux. Benchmarks can be done any way, but should have
                      a developer-eased abstraction. Examples: make bench.
README.md             You should be introducing your software.
docs/                 Very important. People should be able to know what your software is
                      doing without looking at optimized C code.
CONTRIBUTING.md       People should know how to help you.
-STYLEGUIDE.md-       Optional.
compile_commands.json Nobody likes their LSP. Nobody likes it more to be yelled at 24/7 for
                      100% good code.
.clangd               Who doesn't do this?
.clang-format         Make your code look pretty for the love of christ.
.clang-tidy           If nobody likes the LSP, everybody despises the linter.
thirdparty/           If you use external libraries, you WILL be vendoring them. Dependency
                      hell should not be a problem, and yet a 50 year old language still
                      hasn't figured it out.

5. Be very lean on RAM usage. Null Linux is trying to minimize memory usage to the extreme, so nobody is benefitting from your "neat abstraction".

6. The kernel is yours. LibC is nice. A little TOO nice. If it's small, if it's lean, you have ZERO reason to link with libC at ALL. Linux specific syscalls can do you well.