I know that Framework is working with Manjaro and Ubuntu to make those distros work out of the box with the FW16. Since both distros make customizations to their kernels, should we expect some time between the FW16 release and those changes getting sent upstream to base Linux kernels?
As far as I know, Framework is working directly with Fedora and Ubuntu, not Manjaro, though I suppose that could have changed.
While the distros they collaborate with directly will have official support and are more likely to work “out of the box,” I also know that in the case of previous FW laptops, people have gotten many other distros to work, sometimes quite quickly after launch. I would hope and suspect it will be a similar story with the FW 16.
3 Likes
Good to hear! And yeah I just checked their support page on Linux and it’s Fedora, I must’ve had selective vision since I used to run Manjaro haha. I also hope the compatibility comes quick, though largely I can suffice off of Ubuntu until then
I’ll just chime in and say stock Debian should be a priority, although I do understand going for Ubuntu out of the box as it tends to have more folks using it. But I personally much prefer Debian, especially now that Canonical is pushing Snap so hard, almost forcing it.
3 Likes
Given how most distros with relatively recent kernels mostly worked with the amd 13 right away (except for stuff like fan control and os set battery limits and stuff) and the 16 uses the same platform there is a good chance it’ll be fine day 1.
1 Like
I’m a big fan of Debian stable, I’ve run it on my personal laptop and home server for many years. But for the new Framework models with AMD Ryzen chips, those chips are just too new to work great with Debian stable (currently “bookworm”). I’m currently running Arch Linux, a “rolling release” distro, on my new Framework 13 AMD laptop, and I’ll probably go back to Debian stable after the next release. If you really want Debian, your best bet is probably Debian “testing” aka “trixie”, it either has or will have new enough kernel/firmware/mesa/etc by the time the Framework 16 ships.
Similarly for other distros, if they have a major release after roughly now, or if they’re “rolling”, then they’ll work.
2 Likes
Yeah “stable” distros and bleeding edge hardware tend to be a sub-obtimal combination.
Pretty much though there are still a bunch of improvements that are jet to be merged so a rolling release is a pretty good match with bleeding edge hardware.
1 Like
While I’ll give you that the 7840/7940 are new, 6 months from release is hardly bleeding edge.
I will say Framework has no direct control over what kernels/etc the distros use, that’s fair enough, but they could still make sure to support the current LTS kernel release for any drivers, BIOS interface, etc. Although something like fwup might not be possible without newer kernels, I’d have to research that one. But still, targeting the latest LTS kernel for as much as possible is a MAJOR positive, and should allow for forward porting/usage on newer kernels in probably nearly all cases of functionality.
I could certainly be wrong about that, I’m not a kernel dev, but unless someone points me to something saying that it’s extremely hard, very complicated, then I fail to see why Framework shouldn’t target that (in addition). Possibly not immediately, I will understand that. The more likely to be used distro or 2 first, but I fail to see why asking them to support latest LTS kernel is a terrible thing.
My (limited) experience is that Linux rarely runs smoothly on the most recent hardware. If you want to run on that hardware you need to be on the latest kernel and even then there will be issues, If you want to stick to an LTS kernel then you’re better off with a system that is a couple of generations old.
1 Like
2 years from release is barely not bleeding edge XD
We can agree to differ on this point.
But I think that targeting the current (and future) LTS kernel release, soon after release, is a completely reasonable ask. As I said, maybe newer kernel things like firmware update, that’s changed a lot since the current LTS kernel was released, might not be available, and I get that, but I’d love to get a fairly detailed set of reasons why the LTS kernel can’t be targeted from Framework.
When it’s time, you will see the listed of recommendations here: Framework | Linux Compatibility on the Framework Laptop
2 Likes
6.1 LTS works just fine and has all the base line support you would expect. Newer kernels have optimizations that aren’t stable candidates (for example amd pstate active mode doesn’t come until 6.3).
The real problem is Debian doesn’t update the AMD graphics firmware package. If you update the firmware package Debian with the LTS kernel should work just fine.
2 Likes
It is a reasonable ask but may not be realistic. For something that barely changed anything like intel 9th, 10th and 11th gen or 13th gen you’ll have “mostly working” pretty quick and hell those still got some room for improvement on the use of the heterogeneous cores. For a desktop that may be fine, as long as it boots and executes instructions it’s fine, on a laptop though you do want the best possible power management, or stuff like the ec support that hasn’t been merged jet. And that’s for platforms that actively help mainline support, stuff like allwinner socs that need to be mostly reverse engineered stay bleeding edge for years and won’t entirely work on mainline, let alone lts kernels for years.
Unfortunately, it’s just a bit backwards, for Linux. The linux kernel includes the drivers for the hardware “in-tree”, in the common and ideal case. The latest Linux LTS version includes what it includes, Framework doesn’t really have a say in that. As @Mario_Limonciello mentioned, some non-invasive patches with basic support (like just recognizing the hardware IDs and chip variants) are applied to LTS kernel trees systematically by the linux LTS maintainers, but significant feature support and improvements (like power management) are just added in new linux kernels.
Framework does pick hardware that has or will have Linux support, and it does work with Fedora and Ubuntu to make sure there are some backports and tweaks as necessary for there to be something working when hardware is shipped. To “target the latest LTS” fully, they’d have to pick older hardware. They do offer older hardware! but currently only 13" of course. If you want the best support for new hardware, you’ll need a brand new Linux kernel, which is available in some distros now, and will be available in all of them eventually.
Why can’t Linux be like Windows, where you run the latest driver installer from the manufacturer? It’s a long story, but anyway it is different. You can usually install a newer Linux kernel one way or another, like debian backports repo, user-contributed package like PPA or AUR, build it from source and tweak bootloader … that’s not something you can do in Windows, but in Linux that’s how you get the latest hardware support. (And there’s the firmware package that Mario mentioned.)
Because manufacturers use consultants to write drivers and consultants just make sure their own driver works without taking into account what it does to the rest of the system.
And seeing what many consultants do on Linux installations (yes, they program under Windows for Linux), the installation process would leave executable and configuration files in 777 mode, eventually sticky bit set for root (all seen).
In the end, we will have a system stable as Windows 95 was.
Jokes (partial only here 
) aside, the dkms already provides the ability for hardware manufacturers to provide kernel drivers. But not everyone knows how to do that.
1 Like
Here’s the specific rules for stable:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Same rules apply to either LTS or regular stable.