3 ms·

Thanks for the feedback. As noted by folks elsewhere in the comments here, the lived experience with Linux on the Framework Laptop is highly dependent on which

by nrp 4y ago

Thanks for the feedback. As noted by folks elsewhere in the comments here, the lived experience with Linux on the Framework Laptop is highly dependent on which distribution you use, and specifically, the distros policy on taking on and delivering kernel updates. Our policy at Framework has been to publish setup guides for the most popular distros. Where we've been able to build bridges and get contacts in place with distro maintainers, we also deliver them hardware and reach out to them when folks in the community run into issues. The obvious issue with this is that when issues occur upstream, we end up reactive to them alongside Framework Laptop customers. There are several possible solutions to this (which are not mutually exclusive): 1. Building our own Linux distribution for the Framework Laptop. We don't believe this is a good business to get into, and we've seen strong distro preferences in the community that mean that even if we did this, we may not address a plurality of customers' needs. 2. Partner more deeply with specific Linux distributions to attempt to validate kernel updates on Framework hardware before they are accepted for release. We see this as much more viable than option 1, and it's something we are discussing with distros (and we would love to work with additional ones on this). 3. Provide more clarity in our recommended Linux distributions and setup guides around which ones have more conservative kernel policies that are unlikely to run into issues (Ubuntu LTS with an OEM kernel for example) vs ones that more aggressively update and have more risk of driver breakage as a result (basically all of the other distros we currently list). Also as noted in this thread, the risks here will be higher for newer platforms (Intel 12th Gen) than older platforms (Intel 11th Gen). This is something we are now going to prioritize based on feedback we've gotten in the community. We're always open to any and all additional feedback.

ruscurdotau 4y ago
Appreciate the response. My main advice would be to try and be as upstream-focused as possible. Partnering with distros is great, but if your hardware is well supported upstream, you cover everything anyone would ever want to use. If there's fixes that need to go into older distro kernel it's typically trivial to get them backported if they're already upstream. Making Ubuntu work fixes Ubuntu, making upstream work fixes everything - and you're gonna have a lot of users that like living on the edge with distros that follow upstream closely like Arch and Fedora anyway. Critically, the bulk of the resources on the distro side that would test your hardware as part of their regular testing are quite distant from upstream (Ubuntu is the closest, Fedora is largely community driven, RHEL and SLES aren't appealing desktop distros for most users), so having some upstream testing in-house would probably help a lot in getting ahead of problems. Maybe you could try and get boards into kernelci.org? They're mostly focused on ARM SoCs but they have x86 boards in there too, though I don't think there's much on the desktop side. The i915 driver which has caused me much pain and suffering over the last couple of weeks has some test automation that could be run too: https://intel-gfx-ci.01.org/ https://intel-gfx-ci.01.org/ I'm sure there has to be more upstream automated testing initiatives for laptops but I'm not super familiar with that space. Oh and if anyone's interested I gave a talk back in 2020 about how Linux kernel testing is fundamentally boned here: https://www.youtube.com/watch?v=9Fzd6MapG3Y https://www.youtube.com/watch?v=9Fzd6MapG3Y Good luck!
hericium 4y ago
> We're always open to any and all additional feedback. Same as to questions regarding AMD?
- nrp 4y ago
  Yep, we've heard the ask and the feedback. I wrote a response in an earlier in an earlier thread on why we don't communicate on hardware plans: https://news.ycombinator.com/item?id=32180273 https://news.ycombinator.com/item?id=32180273
tga 4y ago
It would be of great help and peace of mind if you would partner with _one_ reference distro (realistically Ubuntu, Fedora, Debian, Arch or maybe SUSE) and prove that the hardware can be _fully_ supported in their LTS release.
- ruscurdotau 4y ago
  Ubuntu is probably the best option there
Spunkie 4y ago
Building your own distro or "partnering" with a specific distro is just about the opposite of what I would want to see. Hire more kernel devs full time, sponsor some more, get the hardware in their hands, make it their job to do nothing but fix or improve frameworks, and then get your shit merged upstream not in some random distro.

by nrp 4y ago

ruscurdotau 4y ago

Appreciate the response. My main advice would be to try and be as upstream-focused as possible. Partnering with distros is great, but if your hardware is well supported upstream, you cover everything anyone would ever want to use. If there's fixes that need to go into older distro kernel it's typically trivial to get them backported if they're already upstream. Making Ubuntu work fixes Ubuntu, making upstream work fixes everything - and you're gonna have a lot of users that like living on the edge with distros that follow upstream closely like Arch and Fedora anyway. Critically, the bulk of the resources on the distro side that would test your hardware as part of their regular testing are quite distant from upstream (Ubuntu is the closest, Fedora is largely community driven, RHEL and SLES aren't appealing desktop distros for most users), so having some upstream testing in-house would probably help a lot in getting ahead of problems. Maybe you could try and get boards into kernelci.org? They're mostly focused on ARM SoCs but they have x86 boards in there too, though I don't think there's much on the desktop side. The i915 driver which has caused me much pain and suffering over the last couple of weeks has some test automation that could be run too: https://intel-gfx-ci.01.org/ https://intel-gfx-ci.01.org/ I'm sure there has to be more upstream automated testing initiatives for laptops but I'm not super familiar with that space. Oh and if anyone's interested I gave a talk back in 2020 about how Linux kernel testing is fundamentally boned here: https://www.youtube.com/watch?v=9Fzd6MapG3Y https://www.youtube.com/watch?v=9Fzd6MapG3Y Good luck!

hericium 4y ago

> We're always open to any and all additional feedback. Same as to questions regarding AMD?

nrp 4y ago
Yep, we've heard the ask and the feedback. I wrote a response in an earlier in an earlier thread on why we don't communicate on hardware plans: https://news.ycombinator.com/item?id=32180273 https://news.ycombinator.com/item?id=32180273

tga 4y ago

It would be of great help and peace of mind if you would partner with _one_ reference distro (realistically Ubuntu, Fedora, Debian, Arch or maybe SUSE) and prove that the hardware can be _fully_ supported in their LTS release.

ruscurdotau 4y ago
Ubuntu is probably the best option there

Spunkie 4y ago

Building your own distro or "partnering" with a specific distro is just about the opposite of what I would want to see. Hire more kernel devs full time, sponsor some more, get the hardware in their hands, make it their job to do nothing but fix or improve frameworks, and then get your shit merged upstream not in some random distro.