Comment by ysofunny

10 months ago

why cannot more people learn about git and branching

you want your merges in? patch it in your own branch

the real crux of the issue is the quality of "the offical version", the real issue, then, is about official branding.

I remember back in the day there were multiple kernel versions by different mantainers.... then again I'm probably missing the forest for the trees or something

11 comments

ysofunny

Reply
Gigachad  10 months ago

Because forked kernels is how we ended up with all those SBCs which could only run some ancient version of linux. If you can't mainline it, you are committing to maintaining a fork forever, and the more changes you require, the more maintenance that fork will be.

The Linux kernel quite intentionally makes maintaining a fork a pain in the ass to pressure vendors to mainline their drives. But now mainline maintainers are refusing to accept those drivers. So it's unlikely we will ever see Macbooks properly supported on Linux.

  • account42  10 months ago

    But the Rust advocates are already telling everyone that they will handle all maintenance of rust code in the kernel and existing maintainers won't have to do a thing. If that was true it wouldn't matter if the rust code is in a separate tree.

WhyNotHugo  10 months ago

The kernel is continuously changing (which IMHO is also an issue), so keeping a fork requires a lot of work to continuously adapt to those changes.

This is why forks made for specific devices are seldom updated for more than a few months (or a couple of years if you're very lucky).

  • ysofunny  10 months ago

    maybe we need something better than git. meh.

    I feel like this problem should have a technical solution.

    maybe a VCS good enough that this isn't as big an issue? (along the lines of pijul?) or

    maybe something from formal verification methods to better enforce or more clearly explain why some drivers cannot be accepted. then again, I don't think the computer science is quite there yet

    • yuliyp  10 months ago

      The VCS has nothing to do with it. Code has all sorts of subtle dependencies. When changes are made, other things are liable to break. When they're in someone else's fork, the person making the change is obviously not going to make sure that fork will stay working.

      Either the change is accepted upstream meaning that everyone else making changes to the mainline needs to keep it working, or it isn't and they don't.

    • dikei  10 months ago

      It's not about the VCS, it's about API compatibility being broken.

      If your code is out-of-tree, every time someone changes an API that break your build, it's your responsibility to update your for and fix it.

      If your code is mainline, the people who change API and break the compilation are on the hook to fix it.