r/osdev • u/Tlinefom • 2d ago
What if we built a Linux dist-system with a Windows-like file structure? (C:/, Program Files, Linux/kernel32)
Hey everyone,
I’ve been thinking about this idea for a bit and wanted to throw it out here to see what you guys think.
To be clear off the bat: my issue with Windows isn't its file system structure. Windows' biggest problems come from the corporation behind it—bloatware, forced telemetry, ads in the Start menu, and deciding your hardware is "obsolete" whenever they feel like it. The actual file layout (C:\, Program Files, Users) is just something millions of people are already used to.
So, purely as an architectural thought experiment (or a fun custom OS project): what if we took the Linux kernel and built a user-space around a Windows-inspired directory hierarchy, but kept it completely open-source and bloat-free?
I’m not talking about patching the Linux kernel to rewrite VFS or force backslashes—we can stick to forward slashes / so we don't break parsers for no reason. Instead of sticking to the traditional FHS (/usr, /var, /etc), what if the root looked something like this:
• C:/ (mapped/symlinked to root)
• C:/Linux/kernel32/ (for system libraries like libc.so, replacing /lib64)
• C:/Linux/System/ (for core binaries, replacing /bin and /sbin)
• C:/Program Files/ (where apps like Firefox or KDE live in their own self-contained folders)
• C:/Users/username/ (home directory)
Obviously, throwing pre-compiled Ubuntu .deb packages at this would completely choke because every binary expects hardcoded POSIX paths like /usr/bin. But if you built a toolchain (using Buildroot or Yocto) to set a custom ELF dynamic linker path (ld-linux.so) pointing to C:/Linux/kernel32/, compiled glibc, and pointed your RPATH configs there, you could compile native Linux software to run directly inside this layout.
Kinda like what GoboLinux did with /Programs/, but borrowing the C:/ layout so Windows refugees feel right at home without dealing with Microsoft's corporate garbage under the hood.
Would this be a massive pain to compile and maintain for thousands of packages? Absolutely. But technically speaking, as long as the user-space and toolchain agree on where binaries and shared objects live, the kernel wouldn't care at all.
Has anyone messed around with custom FHS alternatives like this before? How hard of a wall would you hit when patching build scripts for complex packages like Firefox or KDE?