Live data from Hacker News

With Android Oreo, Google is introducing Linux kernel requirements

betanews.com

11–20 of 74 posts

Re: With Android Oreo, Google is introducing Linux kernel requirements

#11

Describing Linux as "horrendously difficult to use" is disingenuous at best. There are so many different variations between distros and what people mean when they say "Linux" that to categorize them all in this tone is hardly professional. I'm not familiar with betanews.com, but it does claim to be a tech site.

Knowing how to use Linux is easy if you have a decent mental model of CPU, memory, hard drive, network, drivers. Most people outside of tech don't and would be hopelessly lost debugging many Linux issues., the same way they're lost debugging iOS issues or Windows issues.

That all said, it has gotten much more user friendly with e.g. Ubuntu over the past decade or so and hopefully the aforementioned state of affairs begins to change. The language chosen is harsh, but outside of our community, I'd argue that's commonly true without massive training for users.

Re: With Android Oreo, Google is introducing Linux kernel requirements

#12

Describing Linux as "horrendously difficult to use" is disingenuous at best. There are so many different variations between distros and what people mean when they say "Linux" that to categorize them all in this tone is hardly professional. I'm not familiar with betanews.com, but it does claim to be a tech site.

That's part of the problem. You face a problem, look online for a solution, and find answers that pertain only to different distros than what you're using. It hasn't gotten much better as far as I can tell. I used Linux as my primary desktop for a few years around 2002-2005 (Red Hat, Fedora, and Ubuntu). Back then, configuration was mostly automatic, though you had to do stuff like install the NVIDIA kernel blob manually. When things broke, it was at least possible to fix it by dropping into the CLI.

I recently tried to set up Fedora running a VNC or RDP server, and after a couple of days of futzing I gave up. I guess Wayland has managed to regress on that from where X was a decade ago? Systemd also made startup issues impossible to debug, and also apparently f--ked up with how log files are stored? It's a mess.

Re: With Android Oreo, Google is introducing Linux kernel requirements

#13
Why and what kernel requirements does Treble have ? What's wrong with kexec or similar non proprietary solutions ? I'm not a kernel hacker but human enough to turn suspicious when something receives nothing but good news. Can anyone please shed some light ?

Re: With Android Oreo, Google is introducing Linux kernel requirements

#15
post #3
post #2

This appears to be the source: https://source.android.com/devices/architecture/kernel/modul... Device tree is mandatory and vendors are encouraged to upstream the code. It sounds like Google has an eventual goal of building a single kernel that can boot on most devices which is a great thing for everyone.

I do not think it can be done. I am mantaining a kernel for ARM a family of SBCs. Device trees are great compared to old platform files, however they are not enough. We have a lot of commits to fix other things that DT cannot access.

Just curious, has that been discussed on the kernel mailing list?

Re: With Android Oreo, Google is introducing Linux kernel requirements

#16
post #3
post #2

This appears to be the source: https://source.android.com/devices/architecture/kernel/modul... Device tree is mandatory and vendors are encouraged to upstream the code. It sounds like Google has an eventual goal of building a single kernel that can boot on most devices which is a great thing for everyone.

I do not think it can be done. I am mantaining a kernel for ARM a family of SBCs. Device trees are great compared to old platform files, however they are not enough. We have a lot of commits to fix other things that DT cannot access.

Not really an issue if you upstream these changes. That's a big "if" though, that can be a painful process.

It also means that you'd have to wait for the kernel to be released and then google to pick it up before you can use an "official" kernel for your device. In the meantime you'll have to ship your own customized version. I'm not really sure how that's going to work.

Re: With Android Oreo, Google is introducing Linux kernel requirements

#17

Describing Linux as "horrendously difficult to use" is disingenuous at best. There are so many different variations between distros and what people mean when they say "Linux" that to categorize them all in this tone is hardly professional. I'm not familiar with betanews.com, but it does claim to be a tech site.

I came here to comment the same thing. Have they even tried Ubuntu? Most Debian derivatives are remarkably easy to use, if not easier than Windows (single GUI to install software, no worries about finding the right drivers 99% of the time).

Re: With Android Oreo, Google is introducing Linux kernel requirements

#18
post #12

Describing Linux as "horrendously difficult to use" is disingenuous at best. There are so many different variations between distros and what people mean when they say "Linux" that to categorize them all in this tone is hardly professional. I'm not familiar with betanews.com, but it does claim to be a tech site.

That's part of the problem. You face a problem, look online for a solution, and find answers that pertain only to different distros than what you're using. It hasn't gotten much better as far as I can tell. I used Linux as my primary desktop for a few years around 2002-2005 (Red Hat, Fedora, and Ubuntu). Back then, configuration was mostly automatic, though you had to do stuff like install the NVIDIA kernel blob manu…

My experiences are similar. The more time passes the harder (???) it gets to work with Linux. I had to bump my Linode machines forward to avoid getting left behind by the Ubuntu upgrade train and the transition to systemd broke all my services and made everything harder to debug. Not pleasant.

I used to operate under the assumption that I could sit down and use Linux if I needed to - and I started a job that required just that, and it was fine. I'm increasingly less certain of that, because things seem to change rapidly and it's very hard to find documentation that is clear and up-to-date. It's already hard enough to figure out how to do things like add a shortcut to Ubuntu's app launcher.

Re: With Android Oreo, Google is introducing Linux kernel requirements

#19

Describing Linux as "horrendously difficult to use" is disingenuous at best. There are so many different variations between distros and what people mean when they say "Linux" that to categorize them all in this tone is hardly professional. I'm not familiar with betanews.com, but it does claim to be a tech site.

It is filler for an article that covers part of one section of the AOSP documentation.

I scanned the Kernel section of the AOSP documentation and it appears to be a far more comprehensive summary of the new requirements, as well as some nice background information (such as the kernel development process).

The overview to that section is here: https://source.android.com/devices/architecture/kernel/

Re: With Android Oreo, Google is introducing Linux kernel requirements

#20
post #9
post #3

Earlier quoted context omitted.

I do not think it can be done. I am mantaining a kernel for ARM a family of SBCs. Device trees are great compared to old platform files, however they are not enough. We have a lot of commits to fix other things that DT cannot access.

I'm curious as to what things DT cannot access. Is this a general issue (and if so have you spoken to the DT maintainers?), or is this because the systems you are working on are doing something unexpected?

I've had situations where we had to add a small functionality to a driver. For instance a secondary functionality that wasn't supported in the upstream version. It's very rare for drivers of complex components to support 100% of the functionality.

An example that comes to mind was a video chip that also had a GPIO pin that we needed to control. The chip had a driver in the kernel but it didn't have support for the GPIO (it is after all a very secondary function). That required a small patch.

It would of course have been possible to upstream it but then that meant implementing a "clean" patch (using the kernel GPIO API etc... instead of a one liner to toggle the PIN high on dereset) then submitting it upstream, maybe doing a couple of back and forth... Some will bother to do it, many won't.

Post reply on HN