I love play some games, here's my pages about them: My deep rock galactic config My team fortress 2 writtings Maybe I'll use some markdown formating there, because I think it's more readable even in read mode. Btw, all this pages were inspered by spoon's website. Writting custom mountpoint type for Linux is too confusing. I understand there's a lot of moving parts in Linux, and VFS is so flexible, but I just can't understand sops vs inode operations. Do I need Inodes for my virtual system or I can just use sops? I don't know. If someone wants to write a filesystem, please, read the (Linux) docs! Elixir bootlin is very helpfull too. I love plan9. And I love proof assistants too. == Do we actually need dynamic binaries now? We have KSM for memory compression and btrfs for storage compression, so I should ask: is there any reason why we should keep dynamic linking? All programs will have the same code in the filesystem, then it will be compressed down to a one single instance (or even more). And when they all will load into the memory, the KSM will link all that pages to the same memory region without any overhead. So I think there's no reason too use dynamic linking because all its optimizations are useless and it just complicates things. Still, static link everything anyway, it will be faster, robust and cool. --- By the way, this site is a git repo which updates every time I push something there. I find git-hooks cool. --- Maybe GNU/Hurd was right and microkernel is the way to go. KTLS could be good if handshake was made in kernel, OSS was the only reasanoble way audio subsystem could go and fuse api is better than VFS, but the gap between kernel space and user space is too big for us to have useful APIs in programs. Even audio mixing is done in the userspace because "kernel attack vector must be minimal". The usefulness of the kernel must be minimal too, I guess? --- Here goes my random stash of long term ideas: Link --- Cool random projects that, in my opinion, are the foundation of modern society: List --- *at(2) syscalls are the best addition to the Linux and UNIX in general! I can't stress enough how helpful are they for C development. No more dealing with string allocations, trailing slashes and snprintf quirks, just base = openat(AT_FDCWD, "/some/path", O_DIRECTORY | O_RDONLY); child = mkdirat(base, "another/path", 0755); fstatat(child, "file", &stat, 0); Heck, I don't even return pathes anymore, I just return fds and I am happy! That's how we handle memory management problems: we eliminate memory management, not the problems themselves. I also want to talk about how fucking good openat(fd, path, mode) is: - If path is absolute, fd simply ignored and it same as open(path, mode); - If path is relative and fd was opened as dir, it opens path relative to fd; - If path is relative and fd is special AT_FDCWD, it opens relative to the current directory! One syscall, 2 arguments, 3 usecases already, and I haven't started talking about O_PATH yet! Sometimes I hate Linux's overcomplicated design, but not syscalls! They are the best! --- Forget everything I've written above about good Linux syscalls, the fact that splice(2) and sendfile(2) can't save socket's content into file directly is a nightmare!