1. 9
  1.  

  2. 2

    I gotta say, there’s just a huge amount of code rot and duplicated features in the kernel.

    1. 3

      Do you have examples of that? Do you think cleaning this up would be an interesting task to introduce new kernel developers, or are things too intertwined?

      1. 1

        Some stuff is just obsolete but kept around. Why does the latest Linux kernel have cramfs and SquashFS and ROMFS?

        Other stuff was added in to scratch some particular itch, when it would’ve been better to extend an existing subsystem. Why does Linux have SMACK and SELinux? It’s been demonstrated that anything that can be done in SMACK can be done in SELinux but both are kept because “SELinux’s syntax is too hard” (so rather than write a userspace translator/compiler, thousands of lines of code are running in kernelspace….)

        (In general it’s just confusing that there’s AppArmor, Exec Shield, grsecurity, PaX, seccomp, SELinux, Smack, and Tomoyo. Some of their functionality overlaps, some of it doesn’t. Which do you use? When do you use it? Can you use them in combination? When? Why?)

        Some kernel information is accessible via special files in /proc. Other stuff in /sys. Other stuff in debugfs. Other stuff in a sui generis ring buffer. Other stuff via Netlink sockets…

        (IMHO Plan 9 got this right. If there’s information that needs to be exported to userspace, it shows up as a file. The end.)

        There’s a lot of stuff in /proc that has nothing to do with processes. This has been cleaned up over the years, but it’s not done yet.

        Now, of course, I’m writing this on a machine running Linux. My complaints are made out of love and wanting Linux to be the best it can be, not because I think it’s terrible. And of course, it’s easy to judge sitting over here not having written software that’s running on literally billions of devices…