We’re excited that so many of you have chosen Framework over others in this very crowded laptop space. We’re also excited that we have a very vibrant Linux community that have rallied around Framework and the Framework Laptop. With the explosion of interest and folks joining our community, we’ve also seen quite a bit of misinformation on the web and in our community around Linux version support and what should just, “work”. We’re seeing a pretty significant spike in customers contacting Framework Support frustrated that they can’t get Framework hardware to function on their favorite version of Linux. As we’ve stated in our support articles and publicly, we have only verified that the hardware in the Framework Laptop is working without issue in Ubuntu 21.04.3+ (NOT 20.04.3) and Fedora 35. Yes, it’s entirely possible that other versions/flavors of Linux work too! That said, some require technical expertise and deeper Linux knowledge to fidget with drivers and perform some advanced troubleshooting to get the hardware working. If you are on a version of Linux that is on an older kernel, you just won’t be able to get the WiFi or Fingerprint Reader working, it’s not possible as it’s newer tech that requires a newer kernel to function. Asking kindly, if you are attempting to install a version of Linux outside of the above listed versions and run into compatibility problems, we ask that you troubleshoot with our Linux community instead of contacting Framework Support frustrated that things aren’t working as intended. Linux compatibility is, and will always be, a challenge given the sheer number of flavors to choose from, kernel they are based on, etc. While we understand and sympathize with your frustration, our agents are unable to solve problems that are not within their power to solve and/or troubleshoot.
Thank you for your understanding and we hope that you enjoy your Framework Laptop however you choose to enjoy it. Happy Holidays.
We can troubleshoot general laptop usage issues while on a supported OS, but we are unable to troubleshoot OS-related problems not specifically related laptop functionality.
We do not officially support eGPUs so we are unable to troubleshoot issues that could arise due to compatibility issues with our hardware. It’s best that troubleshooting of non-standard peripherals be done through the community until we as a company have declared official support.
We can troubleshoot general laptop usage issues while on a supported OS, but we are unable to troubleshoot OS-related problems not specifically related laptop functionality.
I agree. It reminds me my past comment that is about system design of Travis CI vs GitHub Actions to support.
I definitely feel that something like this should be pinned, or at least placed somewhere with high visibility.
I think it’s incredible that Framework embraces Linux from the get-go, and I certainly feel that Framework and Linux go hand-in-hand, both in terms of vision and in exposure. Unfortunately, a lot of people have only a partial understanding or a complete misunderstanding of what makes things “work”, in the case of Linux and laptops.
Maybe it would be helpful if a member of the community/a Framework team member made a “quick tips” on helping people understand how Linux and Framework work together? For example, a small snippet on how a newer kernel is necessary for drivers, security patches, functionality, etc., and that questions regarding distros/Linux issues should be directed towards those distros, rather than Framework?
You should get the Framework certified for Ubuntu with Canonical for Ubuntu 22.04. Then you can always tell customers that the machine is certified for use with Ubuntu 22.04 if whatever distro or version they tried didn’t work. You could also tell users up-front that the Framework works with Ubuntu 22.04 as a part of the spec sheet, no guessing. I don’t know if RedHat has a similar program for RHEL but if they do that’ll probably be the other one do get. That said Ubuntu certification would catch most users that would have a problem they can’t resolve themselves. Finally, Ubuntu 22.04 LTS has 5-year runway so even if you don’t keep up with newer versions, you’ll have lots of time to evaluate if you want to certify another version and which one.
Lenovo has done this for their ThinkPad line and so has Dell for some models. I imagine it shouldn’t be an impossible task to do at least until your motherboard matrix is still as small as it is. According to my anecdata as a professional Linux user, myself and colleagues buy those models and run Ubuntu LTS for trouble-free operation. Framework is now the obvious choice replacing ThinkPads, Latitudes and XPSes, as far as the hardware but it would be amazing if the software is just as obvious. Of course maybe 22.04 would “just work” anyway so you could get away without doing any official testing work for certification, but if that’s the case, you should at least test that and make it clear in some front page material that - yes the Framework has been tested for and works with Ubuntu 22.04.
Also in case it isn’t obvious, you have a pretty good chance of cornering the professional Linux market. And that 1-2% of laptop users is still a shit ton of computers. It’s also a lasting one by virtue of the type of users.
This can’t be done for any rolling distribution since there’s no stable target with reasonably long lifespan to test and/or certify against.
OK. Thanks! I basically updated with your sentence. I replaced “Framework Support” with “Framwork support”, as I believe “Framework Support” is not proprietary noun. and replaced “by Framework” with “by the company”, as “Framework” is not the official name of the company.
RHEL9, which has kernel 5.14, is currently in Beta.
RHEL8.5 has kernel 4.18, and this is the version current as of November 2021. Kernel is from 2018.
Yeah, no. Just no. Don’t use an enterprise server OS like RHEL on a (new) laptop. Yes, Red Hat can backport things into it, but odds of them spending time to backport fingerprint readers and so on for laptops in their extremely Enterprise Server/Cloud-oriented OS product?
Fedora 35 is on the list. Use that for desktop, and if you need an RHEL environment then use a VM or, better yet, a detatched development environment that you can work on from your Fedora laptop. Supporting newest laptops is basically the anthisesis of what RHEL exists to do, and what Fedora exists for.
As far as my understanding goes, Arch works well on the Framework. At the moment of writing, the latest stable linux package in Arch official repositories is 5.16.0, while linux-lts is 5.15.14, and both seem to support all the hardware installed in the Framework laptop. Arch has even a dedicated entry for the Framework laptop in its wiki, so it may be even mistaken as a “supported” distro; but it is not, and I can understand why: the typical Arch user (me) tends to customise the OS a lot, and most of the issues become OS related, rather than hardware ones. Nevertheless, I think that certifying the Framework for one, or even two widespread Linux distros can only be a good thing!
Most of this post makes complete sense, and I’m glad we could get a clear response. Just wondering, which version of the kernel will allow the WiFi/Fingerprint reader to work?
Support seemed to be spotty in the 5.12 kernel series, was good in 5.13 but there were regressions in some versions, and seems much more solid in 5.14 and 5.15. I think I’ve seen mention that there have been a few regressions in 5.16 now.
(Technically, the lightdm parts are optional, gdm can happily launch you into xfce, no problem, same as it can bring you into i3 or bspwm etc etc.)
Give or take a few config files that I hope they have available in a package. Same thing, really. Ubuntu and Xubuntu are the same systems, only the DE is different. And the DE does not handle your hardware compatibility.
If you want to be really safe, just do that in a TTY session before installing XFCE. After all, the question was whether supporting Ubuntu means that Xubuntu would also be known-good. The answer I illustrated is: well, it’s the same distribution, just a different DE package.
That said, as long as you keep your head on straight it’s not an issue, really. Yes, using multiple GTK-based environments might lead to a bunch of “fun”. But doing something like ripping out Gnome, replacing it with XFCE, and then adding a bit of DWM or i3 or suchlike is no problem. Or just keeping Gnome but installing a few window managers on the side.
The wildcard in the case of Ubuntu and it’s reskins is: I do not know if they make their “skins” available as a package. That’s a neat thing Manjaro does, for example: if you installed the Manjaro XFCE edition, and you decide you want their Gnome instead, all you do is to remove XFCE, remove the XFCE “configuration package”, then install Gnome plus the Manjaro Gnome config package. Boom. No need to download a new ISO and reinstall a whole OS just because you want to swap out some of the applications running on your OS.
These apt-based distributions really are making things so darn complicated when they don’t have to, don’t they? Apparently everything is impossible as long as apt is involved…
Job done.
Now, will you understand the basic point being made, or nitpick? Configurations files are just configuration file. Yeet them if they cause you a problem.
(Now, this assumes the person wants Manjaro’s special themes. This is even easier if using something that doesn’t skin the DE to hell and back with 500 unwarranted extensions. This operation is super simple and reinstalling a whole OS because one wants to switch DE is silly.)
GNOME likes to toss them all over the place. This isn’t an apt-specific issue either. Package managers (generally) WILL NOT track configuration files produced post-install, as that is not their domain. I also recall that GNOME creates a lot of files in non-standard places, so getting rid of them won’t be too clean.
