Back to home

Developer Documentation

This page contains developer-specific documentation.

1 - AI Policy

Large Language Models are tools, they should be used to aid a programmer and not replace them.

If LLMs must be used for a project, please ensure there is some degree of human input and oversight. Additionally, projects using LLM-generated code MUST place a disclaimer file in their source code tree.

FILE: LLM_DISCLAIMER

2 - Security Policy

All programs should periodically be audited by a member of the Everest Linux security team to ensure compliance with the distribution's design principle of security.

Patching security vulnerabilities should be considered a top priority, and are expected to be done in as timely of a manner as possible.

Please direct all questions to security@everestlinux.org.

3 - Coding Style

3.1 C

3.1.1 File Structure

Files should follow this format:

• Header comment, including program name and LICENSE
• Headers
• Macros
• Types
• Global variables
• Functions
• main (if applicable)

Note that function declarations should be defined in a separate header, ex:

#include "project_name.h"

Indentations should be a single tab and be equal to 8 characters for better readability.

3.1.2 Functions

Functions should have their return type on one line, their name and parameters one line down, and the bracket one line under the name and arguments.

Example:

CODE: Proper function formatting in C

static void
usage(int argc, char *argv[])
{
        printf("usage: %s [-a] [-b]\n", argv[0]);
}
  

3.1.3 Example Program

FILE: prog.c

/* Headers included from standard library */
#include <stdio.h>
#include <unistd.h>

/* Headers included locally */
#include "prog.h"
#include "somelib.h"

void
hello(void)
{
        printf("Hello\n");
}

int
main(void)
{
        hello();
        return 0;
}

FILE: prog.h

3.1.4 common.h

For large programs which include many header files, it is perfectly acceptable to define these includes in a separate header and then include that in each file.

FILE: common.h

FILE: prog.c

3.2 Best Practices

• Avoid abbreviation and single letter variables.
• Avoid deep nesting.

3.2.1 Rationale for Best Practices

Readability is the primary rationale for both of these practices.

If nobody except you is able to read your code, it is unreadable.

3.2.2 Following Best practices

Single letter variables should be eliminated whenever possible.

CODE: Avoiding single letter variables

/* The actual meaning of x is ambiguous without 
 * looking at its associated logic. */
int x;

/* Let's say x is referring to an x-coordinate
 * on a coordinate plane. In this scenario, it
 * would be appropriate to use a
 * more descriptive name. */
int x_position;

2 - Licensing

2.1 Disclaimer

WARNING:

2.2 Preferred Licenses

For all projects officially released under Everest, the GNU GPL family of licenses is preferred. It provides compatibility with all other existing Everest projects.

Most programs should be licensed under the standard GPL. For libraries, you might want to choose the LGPL, if you want to allow linking within proprietary programs. For web applications, always choose the AGPL.

2.3 Other Licenses

If you wish to use a non-GPL license for your project, that is perfectly permissible.

Before releasing your program, we ask that you add the following disclaimer to your README:

FILE: README

If you are an Everest developer and host a project on our Git server, but do not want it associated with Everest, please submit an electronically signed form stating the following:

FILE: WAIVER

2.3 Proprietary Licenses

Programs hosted on our Git servers are never to be released under proprietary licenses.

Distributing obfuscated binaries (for instance, using shc to hide the contents of a shell script) is also not allowed.

There will be no further discussion.