Building a faster, smarter, Chromebook experience with the best of Google

Re:Building a faster, smarter, Chromebook experience with th... by lmm on Wednesday June 12, 2024 @11:26PM (#40665636)

Linux offers no stable driver API; they claim that submitting your drivers into the kernel tree is a good substitute, but they have strict requirements on what kind of code they will accept and also decline contributions out of basically organisational politics reasons. So in practice you're locked out from any old or obscure hardware unless you have a lot of time to spend playing kernel politics, keeping up with their API changes, or both.

[ Parent | on HN ]

Re:Building a faster, smarter, Chromebook experience with th... by Zambyte on Thursday June 13, 2024 @12:22AM (#40665909)

I wonder if Linus has ever made the connection between this problem and his stance against applying the Unix philosophy to kernels :P

[ Parent | on HN ]

Re:Building a faster, smarter, Chromebook experience with th... by account42 on Thursday June 13, 2024 @09:18AM (#40669304)

> they have strict requirements on what kind of code they will accept and also decline contributions out of basically organisational politics reasons

They accept only code which they will be able to maintain, yes. That excludes spaghetty or implementations of complex undocumented APIs that are useless without a binary blob. Nothing unreasonable about that.

[ Parent | on HN ]

Re:Building a faster, smarter, Chromebook experience with th... by Wytwwww on Thursday June 13, 2024 @11:22AM (#40670798)

It's unreasonable if there aren't any reasonable alternatives.

[ Parent | on HN ]

Re:Building a faster, smarter, Chromebook experience with th... by account42 on Friday June 14, 2024 @03:50AM (#40678583)

How is it unreasonable that the kernel developers expect those that want to rely on their existing and continued work to put in a modicum of effert to not make said kernel developers life more difficult?

[ Parent | on HN ]

Re:Building a faster, smarter, Chromebook experience with th... by lmm on Thursday June 13, 2024 @06:49PM (#40675733)

Perhaps. In my experience a bad driver is better than no driver; not wanting bad code in your codebase is reasonable, but gets less reasonable when you also refuse to offer an API. And even if your code does meet their quality requirements, it can still get rejected for kernel-politics reasons.

[ Parent | on HN ]

Re:Building a faster, smarter, Chromebook experience with th... by account42 on Friday June 14, 2024 @03:48AM (#40678569)

Unless you are going to provide examples then I am going to assume that " kernel-politics" refers to things like rejecting "drivers" that can only used with a closed source userspace blob. In those cases the reasons have technical merit - how are the kernel developers supposed to maintain an effectively proprietary API without any idea how it is being used.

[ Parent | on HN ]

Re:Building a faster, smarter, Chromebook experience with th... by lmm on Sunday June 16, 2024 @06:05PM (#40700509)

No, I'm talking about cases of not liking the way of doing things, e.g. how we ended up with CFS which was a watered-down reimplementation. (ReiserFSv4 is another example of code that met the technical bar and was rejected for purely non-technical reasons, as much as few would disagree with that).

[ Parent | on HN ]

Re:Building a faster, smarter, Chromebook experience with th... by 1oooqooq on Thursday June 13, 2024 @11:42AM (#40671036)

> in practice you're locked out from any old or obscure hardware unless you have a lot of time to spend playing kernel politics, keeping up with their API changes, or both.

no sympathy. you're also out of luck using old hardware in the first place because the manufacturer wants you to buy the new version. they will help you LESS than Linux devs. you're point is very unhelpful to the discussion, unless you got drivers updates from the manufacturer

[ Parent | on HN ]

Re:Building a faster, smarter, Chromebook experience with th... by lmm on Thursday June 13, 2024 @06:47PM (#40675714)

> you're also out of luck using old hardware in the first place because the manufacturer wants you to buy the new version. they will help you LESS than Linux devs.

The manufacturer probably doesn't exist any more. They wrote decent drivers and supported them for a number of years, that should be enough. Or maybe a dedicated fan wrote some OSS drivers at some point in the past. On both Windows and FreeBSD that's good enough; once a driver has been written, it largely stays working, so I can keep using my hardware. This really is a unique downside of Linux.

[ Parent | on HN ]