mjhjmtu

A google search reveals this slashdot story yielding this github repository that hasn't had a commit since 2016. There are 22,602 forks listed on github.com but these are going to be mostly (if not virtually all) simply development forks for torvalds/linux.

I have read before that Linux has become quite crufty. It seems to me that, at least in terms of user experience, Linux has become much more polished than I remember 10+ years ago (obviously this is not an accurate assessment of the kernel; I am only now reading K&R and have never dipped into the kernel source except a cursory glance that yielded a "whoa, I can't understand a line of this", but I am aware of a great amount of development regarding linux-on-the-laptop features in the kernel, for example). Regardless, I know I've seen BSD people complaining about Linux cruft. Considering the neovim fork of vim based on vim's cruft, I would think similar efforts would be rewarding for the kernel.

What prompts this question was this article on LWN discussing attempts to compile Linux with clang. I've read that the kernel uses many quirks/special features specific to gcc for optimization (though the linked article seems to downplay them compared to my memory), and I began to wonder if anyone had attempted to refactor/fork the kernel to make it more portable, or at least compilable outside of the gnu-environment. I also understand that gcc iteself is crufty, and Linus himself has criticized it.

I know I am not alone in my personal distaste for RMS and GNU and interest in Linux devoid of GNU; I am aware of Alpine Linux which does without gnu tools, but the kernel is still compiled with gcc, isn't it? There are many references to alternative toolchains and userland software, but I am specifically wondering about the kernel and whether there are forks that eliminate gcc/gnu dependencies--consider this a subsidiary question of the title--it seems to me it would be a waste to ask it separately.

I am specifically wondering about the kernel and whether there are forks that eliminate gcc/gnu dependencies--

No-one is going to finish the work syncing up clang & Linux and then maintain that as a long-term fork. Especially when there's such interest and willingness from mainline. Unless it was a small part of a big visible project, which you would have found. (As you did...).

consider this a subsidiary question of the title--it seems to me it would be a waste to ask it separately.

Android, as mentioned by the first answer.

Some parts get merged so maybe it's not as bad as it was. I'm not really up to date on this. Mainline certainly gets work for some ARM CPU related stuff e.g. BIG.little. And Android repeatedly rebase on mainline versions; Google is not going to fall too far behind.

But it's a long running fork. It doesn't run on "upstream first" rules. They're carrying a lot of hardware support.

IMO "Android" and "Google" are good pointers to the levels of resource you need for something that justifies being called a fork of Linux.

Android has also been a problem in that devices running it ship with kernels containing large amounts (often millions of lines) of out-of-tree code. -- https://lwn.net/Articles/738225/

Also RHEL kernels, which have terrifying names like 2.6.32-754 as of 2018. These are not just security updates; they will include support for some new hardware, while at the same time aiming to provide closer behaviour to the base kernel version e.g. 2.6.32. I believe fork is a appropriate word for the resources RH require to maintain this.

Running well on a wide range of recent hardware is costly, and hence valuable. That's mostly what the Linux kernel project is, and I'd say it's the single most important factor to understand these two forks.

You might compare the code size of vim and Linux on openhub.net and think, oh, Linux is "only" about 20x the size. However the difference in number of commits is significantly larger; the rate of churn is quite ferocious.

Also, it's not just that kernel code is harder to get right... though it is... but also it's hardware support. When your apparently harmless refactoring ends up breaking a few devices, you need to have access to those specific devices to debug and fix the problem.

Hardware support makes me think of https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset :-P.

In this world of server virtualization, you might also think there would be fork(s) optimized for it, as they would not need to keep up with so much different hardware. I can't think of any good examples though. You could look up "unikernels"; there seem to be several not based on Linux.

linux-rt / PREEMPT_RT also comes to mind as an out of tree patch set. This is a patch set which is rebased on successive mainline versions. 200 KB (compressed) of specialist code is a respectable patch set. Some large pieces of it have been merged in, at at least one point.

Android is a fork of Linux. According to linus.
https://www.youtube.com/watch?v=duDC_u4ydVo
not very helpful i am sure, you are probably looking for one that is good for desktop use.. android is not