Pros of Linux

• Massive community support and extensive documentation
• Wide hardware compatibility and driver support
• Battle-tested in production environments for decades

Cons of Linux

• Complex codebase with a steep learning curve for new contributors
• Slower development cycle due to rigorous review process
• Legacy code and compatibility requirements can hinder innovation

Code Comparison

Linux (kernel/sched/core.c):

static void __sched notrace __schedule(bool preempt)
{
    struct task_struct *prev, *next;
    unsigned long *switch_count;
    struct rq *rq;
    int cpu;

Serenity (Kernel/Scheduler.cpp):

void Scheduler::pick_next()
{
    VERIFY_INTERRUPTS_DISABLED();
    VERIFY(!s_active_thread || s_active_thread == Thread::current());
    VERIFY(g_scheduler_lock.is_locked());

The Linux code snippet shows the core scheduling function, while Serenity's code demonstrates the next thread selection process. Linux uses C, while Serenity uses C++. Serenity's code includes more assertions and checks, reflecting its focus on correctness and debugging.

Pros of ReactOS

• Aims for Windows compatibility, potentially supporting a wider range of existing software
• Longer development history, with a more established community and codebase
• More extensive hardware support due to its focus on real-world compatibility

Cons of ReactOS

• Less modern design philosophy compared to SerenityOS's fresh approach
• Slower development pace due to the complexity of reverse-engineering Windows
• More constrained by legacy design decisions to maintain compatibility

Code Comparison

ReactOS (C-style API):

NTSTATUS NTAPI NtCreateFile(
    PHANDLE FileHandle,
    ACCESS_MASK DesiredAccess,
    POBJECT_ATTRIBUTES ObjectAttributes,
    PIO_STATUS_BLOCK IoStatusBlock,
    PLARGE_INTEGER AllocationSize,
    ULONG FileAttributes,
    ULONG ShareAccess,
    ULONG CreateDisposition,
    ULONG CreateOptions,
    PVOID EaBuffer,
    ULONG EaLength
);

SerenityOS (C++ API):

ErrorOr<NonnullRefPtr<File>> File::open(String const& filename, int options, mode_t mode)
{
    auto custody_or_error = VFS::the().resolve_path(filename, current_directory());
    if (custody_or_error.is_error())
        return custody_or_error.error();
    return File::open(custody_or_error.value(), options, mode);
}

This comparison highlights the different approaches: ReactOS closely mimics Windows APIs, while SerenityOS adopts a more modern C++ style with error handling and object-oriented design.

Pros of Haiku

• More mature project with a longer development history
• Larger community and contributor base
• Better hardware support and driver compatibility

Cons of Haiku

• Less modern UI design compared to Serenity
• Slower development pace in recent years
• Limited support for newer technologies and standards

Code Comparison

Both projects are operating systems written primarily in C++, but they have different approaches to system calls and API design.

Haiku system call example:

status_t
_kern_open_directory(int fd, const char *path, bool traverseLink)
{
    return vfs_open_dir(fd, path, traverseLink);
}

Serenity system call example:

ErrorOr<NonnullRefPtr<OpenFileDescription>> Process::sys$open(Userspace<const Syscall::SC_open_params*> user_params)
{
    VERIFY_NO_PROCESS_BIG_LOCK(this);
    TRY(require_promise(Pledge::rpath));
    auto params = TRY(copy_typed_from_user(user_params));
    // ... (additional implementation)
}

Serenity's system calls tend to be more verbose and use modern C++ features, while Haiku's are often simpler and more C-like in style.

Pros of Minoca OS

• Smaller codebase and footprint, potentially easier to understand and modify
• Designed for embedded systems, offering better support for resource-constrained devices
• Cross-platform support, including x86, ARM, and RISC-V architectures

Cons of Minoca OS

• Less active development and smaller community compared to Serenity
• Fewer features and applications out of the box
• Limited desktop environment and graphical capabilities

Code Comparison

Minoca OS (kernel initialization):

KSTATUS
OsInitialize (
    PKERNEL_INITIALIZATION_BLOCK Parameters
    )
{
    KeInitializeSpinLock(&OsGlobalLock);
    return OsInitializePhase1(Parameters);
}

Serenity (kernel initialization):

extern "C" [[noreturn]] void init()
{
    asm volatile("cli");
    gdt_init();
    idt_init();
    // ...
}

Both projects show different approaches to kernel initialization, with Minoca OS using a more structured function-based approach, while Serenity uses a simpler C++ style initialization.

Pros of Harvey

• Based on Plan 9, offering a unique and innovative operating system design
• Supports multiple architectures, including x86, ARM, and RISC-V
• Lightweight and minimalist, suitable for embedded systems and research

Cons of Harvey

• Smaller community and less active development compared to Serenity
• Limited desktop environment and user-friendly features
• Fewer modern applications and compatibility with contemporary software

Code Comparison

Harvey (Plan 9-inspired system calls):

int
sys_open(char *name, int mode)
{
    return syscall(OPEN, name, mode);
}

Serenity (POSIX-like system calls):

int
open(const char* pathname, int flags, mode_t mode)
{
    return syscall(SC_open, pathname, flags, mode);
}

Both projects aim to create modern, open-source operating systems, but with different approaches. Harvey focuses on Plan 9 principles and minimalism, while Serenity aims for a more familiar Unix-like environment with a graphical user interface. Serenity has gained more popularity and active development in recent years, offering a more complete desktop experience. Harvey, on the other hand, provides a unique platform for exploring alternative operating system designs and concepts.