First Lenovo laptop with Fedora now available on the web!

This weekend the X1 Carbon with Fedora Workstation went live in North America on Lenovos webstore. This is a big milestone for us and for Lenovo as its the first time Fedora ships pre-installed on a laptop from a major vendor and its the first time the worlds largest laptop maker ships premium laptops with Linux directly to consumers. Currently only the X1 Carbon is available, but more models is on the way and more geographies will get added too soon. As a sidenote, the X1 Carbon and more has actually been available from Lenovo for a couple of Months now, it is just the web sales that went online now. So if you are a IT department buying Lenovo laptops in bulk, be aware that you can already buy the X1 Carbon and the P1 for instance through the direct to business sales channel.

Also as a reminder for people looking to deploy Fedora laptops or workstations in numbers, be sure to check out Fleet Commander our tool for helping you manage configurations across such a fleet.

I am very happy with the work that has been done here to get to this point both by Lenovo and from the engineers on my team here at Red Hat. For example Lenovo made sure to get all of their component makers to ramp up their Linux support and we have been working with them to both help get them started writing drivers for Linux or by helping add infrastructure they could plug their hardware into. We also worked hard to get them all set up on the Linux Vendor Firmware Service so that you could be assured to get updated firmware not just for the laptop itself, but also for its components.

We also have a list of improvements that we are working on to ensure you get the full benefit of your new laptops with Fedora and Lenovo, including working on things like improved power management features being able to have power consumption profiles that includes a high performance mode for some laptops that will allow it to run even faster when on AC power and on the other end a low power mode to maximize battery life. As part of that we are also working on adding lap detection support, so that we can ensure that you don’t risk your laptop running to hot in your lap and burning you or that radio antennas are running to strong when that close to your body.

So I hope you decide to take the leap and get one of the great developer laptops we are doing together with Lenovo. This is a unique collaboration between the worlds largest laptop maker and the worlds largest Linux company. What we are doing here isn’t just a minimal hardware enablement effort, but a concerted effort to evolve Linux as a laptop operating system and doing it in a proper open source way. So this is the culmination of our work over the last few years, creating the LVFS, adding Thunderbolt support to Linux, improving fingerprint reader support in Linux, supporting HiDPI screens, supporting hidpi mice, creating the possibility of a secure desktop with Wayland, working with NVidia to ensure that Mesa and Nvidia driver can co-exist through glvnd, creating Flatpak to ensure we can bring the advantages of containers to the desktop space and at the same way do it in a vendor neutral way. So when you buy a Lenovo laptop with Fedora Workstation, you are not just getting a great system, but you are also supporting our efforts to take Linux to the next level, something which I think we are truly the only linux vendor with the scale and engineering ability to do.

Of course we are not stopping here, so let me also use this chance to talk a bit about some of our other efforts.

Toolbox
Containers are popular for deploying software, but a lot of people are also discovering now that they are an incredible way to develop software, even if that software is not going to be deployed as a Flatpak or Kubernetes container. The term often used for containers when used as a development tool is pet containers and with Toolbox project we are aiming to create the best tool possible for developers to work with pet containers. Toolbox allows you to have always have a clean environment to work in which you can change to suit each project you work on, however you like, without affecting your host system. So for instance if you need to install a development snapshot of Python you can do that inside your Toolbox container and be confident that various other parts of your desktop will not start crashing due to the change. And when your are done with your project and don’t want that toolbox around anymore you can easily delete it without having to spend time to figure out which packages you installed can now be safely uninstalled from your host system or just not bother and have your host get bloated over time with stuff you are not actually using anymore.

One big advantage we got at Red Hat is that we are a major contributor to container technologies across the stack. We are a major participant in the Open Container Initiative and we are alongside Google the biggest contributor to the Kubernetes project. This includes having created a set of container tools called Podman. So when we started prototyping Toolbox we could base it up on podman and get access to all the power and features that podman provides, but at the same make them easier to use and consumer from your developer laptop or workstation.

Our initial motivation was also driven by the fact that for image based operating systems like Fedora Silverblue and Fedora CoreOS, where the host system is immutable you still need some way to be able to install packages and do development, but we quickly realized that the pet container development model is superior to the old ‘on host’ model even if you are using a traditional package based system like Fedora Workstation. So we started out by prototyping the baseline functionality, writing it as a shell script to quickly test out our initial ideas. Of course as Toolbox picked up in popularity we realized we needed to transition quickly to a proper development language so that we wouldn’t end up with an unmaintainable mess written in shell, and thus Debarshi Ray and Ondřej Míchal has recently completed the rewrite to Go (Note: the choice of Go was to make it easier for the wider container community to contribute since almost all container tools are written in Go).

Leading up towards Fedora Workstation 33 we are trying figure out a few things. One is how we can make giving you access to a RHEL based toolbox through the Red Hat Developer Program in an easy and straightforward manner, and this is another area where pet container development shines. You can set up your pet container to run a different Linux version than your host. So you can use Fedora to get the latest features for your laptop, but target RHEL inside your Toolbox to get an easy and quick deployment path to your company RHEL servers. I would love it if we can extend this even further as we go along, to for instance let you set up a Steam runtime toolbox to do game development targeting Steam.
Setting up a RHEL toolbox is already technically possible, but requires a lot more knowledge and understanding of the underlaying technologies than we wish.
The second thing we are looking at is how we deal with graphical applications in the context of these pet containers. The main reason we are looking at that is because while you can install for instance Visual Studio code inside the toolbox container and launch it from the command line, we realize that is not a great model for how you interact with GUI applications. At the moment the only IDE that is set up to be run in the host, but is able to interact with containers properly is GNOME Builder, but we realize that there are a lot more IDEs people are using and thus we want to try to come up with ways to make them work better with toolbox containers beyond launching them from the command line from inside the container. There are some extensions available for things like Visual Studio Code starting to try to improve things (those extensions are not created by us, but looking at solving a similar problem), but we want to see how we can help providing a polished experience here. Over time we do believe the pet container model of development is so good that most IDEs will follow in GNOME Builders footsteps and make in-container development a core part of the feature set, but for now we need to figure out a good bridging strategy.

Wayland – headless and variable refresh rate.
Since switching to Wayland we have continued to work in improving how GNOME work under Wayland to remove any major feature regressions from X11 and to start taking advantage of the opportunities that Wayland gives us. One of the last issues that Jonas Ådahl has been hard at work recently is trying to ensure we have headless support for running GNOME on systems without a screen. We know that there are a lot of sysadmins for instance who want to be able to launch a desktop session on their servers to be used as a tool to test and debug issues. These desktops are then accessed through tools such as VNC or Nice DCV. As part of that work he also made sure we could deal with having multiple monitors connected which had different refresh rates. Before that fix you would get the lowest common denominator between your screens, but now if you for instance got a 60Hz monitor and a 75Hz monitor they will be able to function independent of each other and run at their maximum refresh rate. With the variable refresh rate work now landed upstream Jonas is racing to get the headless support finished and landed in time for Fedora Workstation 33.

Linux Vendor Firmware Service
Richard Hughes is continuing his work on moving the LVFS forward having spent time this cycle working with the Linux Foundation to ensure the service can scale even better. He is also continuously onboarding new vendors and helping existing vendors use LVFS for even more things. We are now getting reports that LVFS has become so popular that we are now getting reports of major hardware companies who up to know hasn’t been to interested in the LVFS are getting told by their customers to start using it or they will switch supplier. So expect the rapid growth of vendors joining the LVFS to keep increasing. It is also worth nothing that many of vendors who are already set up on LVFS are steadily working on increasing the amount of systems they support on it and pushing their suppliers to do the same. Also for enterprise use of LVFS firmware Marc Richter also wrote an article on access.redhat.com about how to use LVFS with Red Hat Satelitte. Satellite for those who don’t know it is Red Hats tool for managing and keeping servers up to date and secure. So for large companies having their machines, especially servers, accessing LVFS directly is not a wanted behaviour, so now they can use Satelitte to provide a local repository of the LVFS firmware.

PipeWire
One of the changes we been working on that I am personally extremely excited about is PipeWire. For those of you who don’t know it, PipeWire is one of our major swamp draining efforts which aims to bring together audio, pro-audio and video under linux and provide a modern infrastructure for us to move forward. It does so however while being ABI compatible with both Jack and PulseAudio, meaning that applications will not need to be ported to work with PipeWire. We have been using it for a while for video already to handle screen capture under Wayland and for allowing Flatpak containers access to webcams in a secure way, but Wim Taymans has been working tirelessly on moving that project forward over the last 6 Months, focused a lot of fixing corner cases in the Jack support and also ramping up the PulseAudio support. We had hoped to start wide testing in Fedora Workstation 32 of the audio parts of PipeWire, but we decided that since such a key advantage that PipeWire brings is not just to replace Jack or PulseAudio, but also to ensure the two usecases co-exist and interact properly, we didn’t want to start asking people to test until we got the PulseAudio support close to being production ready. Wim has been making progress by leaps and bounds recently and while I can’t 100% promise it yet we do expect to roll out the audio bits of PipeWire for more widescale testing in Fedora Workstation 33 with the goal of making it the default for Fedora Workstation 34 or more likely Fedora Workstation 35.
Wim is doing an internal demo this week, so I will try to put out a blog post talking about that later in the week.

Flatpak – incremental updates
One of the features we added to Flatpaks was the ability to distribute them as Open Container Initiative compliant containers. The reason for this was that as companies, Red Hat included, built infrastructure for hosting and distributing containers we could also use that for Flatpaks. This is obviously a great advantage for a variety of reasons, but it had one large downside compared to the traditional way of distributing Flatpaks (as Ostree images) which is that each update comes as a single large update as opposed to the atomic update model that OStree provides.
Which is why if you would compare the same application when shipping from Flathub, which uses Ostree, versus from the Fedora container registry, you would quickly notice that you get a lot smaller updates from Flathub. For kubernetes containers this hasn’t been considered a huge problem as their main usecase is copying the containers around in a high-speed network inside your cloud provider, but for desktop users this is annoying. So Alex Larsson and Owen Taylor has been working on coming up with a way to do to incremental updates for OCI/Docker/Kubernetes containers too, which not only means we can get very close to the Flathub update size in the Fedora Container Catalog, but it also means that since we implemented this in a way that works for all OCI/Kubernetes containers you will be able to get them too with incremental update functionality. Especially as such containers are making their way into edge computing where update sizes do matter, just like they do on the desktop.

Hangul input under Wayland
Red Hat, like Lenovo, targets most of the world with our products and projects. This means that we want them to work great even for people who doesn’t use English or another European language. To achieve this we have a team dedicated to ensuring that not just Linux, but all Red Hat products work well for international users as part of my group at Red Hat. That team, lead by Jens Petersen, is distributed around the globe with engineers in Japan, China, India, Singapore and Germany. This team contributes to a lot of different things like font maintenance, input method development, i18n infrastructure and more.
One thing this team recently discovered was that the support for Korean input under Wayland. So Peng Wu, Takao Fujiwara and Carlos Garnacho worked together to come up with a series of patches for ibus and GNOME Shell to ensure that Fedora Workstation on Wayland works perfectly for Korean input. I wanted to highlight this effort because while I don’t usually mention efforts which such a regional impact in my blog posts it is a critical part of keeping Linux viable and usable across the globe. And ensuring that you can use your computer in your own language is something we feel is important and want to enable and also an area where I believe Red Hat is investing more than any other vendor out there.

GLX on EGL
We meet with NVidia on a regular basis to discuss topics of shared interest and one thing we been looking at for a while now is the best way to support Nvidia binary driver under XWayland. As part of that Adam Jackson has been working on a research project to see how feasible it would be to create a way to run GLX applications on top of EGL. As one might imagine EGL doesn’t have a 1to1 match with GLX APIs, but based on what we seen so far is that it should be close enough to get things going (Adam already got glxgears running :). The goal here would be to have an initial version that works ok, and then in collaboration with NVidia we can evolve it to be a great solution for even the most demanding OpenGL/GLX applications. Currently the code causes an extra memcopy compared to running on GLX native, but this is something we think can be resolved in collaboration with NVidia. Of course this is still an early stage effort and Adam and NVidia are currently looking at it so there is of course a chance still we will hit a snag and have to go back to the drawing board. For those interested you can take a look at this Mesa merge request to see the current state.

16 comments ↓

#1 Pekka Paalanen on 09.01.20 at 07:29

That is very interesting, thanks.

You mention “variable refresh rate”. Are you talking about actual VRR (extending front porch on-demand to smoothly achieve lower than programmed refresh rate) or do you mean only the capability to run multiple monitors at different fixed refresh rates?

#2 uraeus on 09.03.20 at 17:46

the second :)

#3 L. on 09.01.20 at 09:53

I doubt Lenovo will do anything serious about Linux. I see them as Dell – hoping, by empty declaration, to dupe us all into buying their hardware.
Look, I have two Lenovo laptops: E14 Gen 2(20T6S00W00) and E495(20KUS01U00), both are AMD… and not a single piece of firmware is available in/via LVFS.
This same goes for Lenovo ThinkServers – no LVFS, no serious Linux support.
So as of today my verdict is – unless you cannot live without trackpoint, then go for some less known but Linux dedicated brands.

#4 uraeus on 09.01.20 at 13:42

They are ramping up, but of course with both Dell and Lenovo, you have to get their officially Linux supported systems to get the full package. Over time hopefully for things like firmware we will see full coverage from most vendors through the LVFS, but for now these offerings clearly state which systems have full Linux support and thus also firmware update support.

#5 Jason Evangelho [FORBES] on 09.01.20 at 10:16

“we are now getting reports of major hardware companies who up to know hasn’t been to interested in the LVFS are getting told by their customers to start using it or they will switch supplier. So expect the rapid growth of vendors joining the LVFS to keep increasing.”

Can you supply any more detail about these vendors? This would make a terrific standalone story at Forbes. You have my email!

#6 red.herring on 09.01.20 at 20:25

Two questions:

1. why is toolbox a thing when lxd exists? This looks like NIH is strong with redhat and stuff people dislike about canonical can be seen here. Can you elaborate on this: differences And/or why extending lxd wasn’t an option?

2. Why is not the as opensource company taking a harder stance with Nvidia regarding their driver? Doesn’t it seem weird (hypocritical?) when a company that has over 1billion usd income built around a gpl2 core is helping a vendor that despises it?

#7 uraeus on 09.03.20 at 17:54

Debarshi already responded better than I could to your first question. As for your second question about NVidia. We are taking a harder stance than any other major Linux vendor by not shipping the NVidia driver pre-installed, but instead requiring users to install through GNOME Software themselves. We are the only vendor which supports the development of Nouveau, the open source Nvidia driver. But the fact of the matter is that a lot of users and customers are relying on NVidia hardware and we have to accommodate that. And I also think its a mischaracterization to say NVidia despite the GPL, they have some concerns about how it affects their business models, but since we are meeting with them on an almost weekly basis I also know they are looking at these issues and are trying to figure out if there are ways to resolve them.

#8 Liam on 09.02.20 at 01:30

If Google can’t get Nvidia to budge why would you expect rh to be able to do better?
What’s rh’s leverage? Nvidia doesn’t need the Linux desktop, and there’s no danger of them losing the compute market.
So, what do you expect? RH has been working helping to fund nouveau for many years but you’re not going to build a complete open source driver for a modern gpu with less than a few dozen dedicated developers and docs.

#9 Walter Bishop on 09.02.20 at 11:15

Waiting impatiently for the day that Pipewire is the only audio server needed, screen capture works ootb on Wayland and Flatpaks don’t look ugly any more without intervention. Keep up the good work!

#10 Debarshi Ray on 09.02.20 at 13:50

> why is toolbox a thing when lxd exists?

You could also also ask: “Why is Docker a thing when LXC exists”?

Except, Docker does exist, and now with the Open Container Initiative (or OCI) it’s an even bigger thing.

Then Podman came along, implemented the OCI specification and Docker’s command line interface, and right about the time when we were trying to make development more approachable on Silverblue, Podman introduced rootless OCI containers.

This was the ideal combination for us. No daemons, no need for root credentials, and aligned with something that has massive mainstream adoption.

I don’t see how that’s NIH.

#11 Eric Mesa on 09.04.20 at 19:53

That’s pretty exciting stuff. I keep forgetting to use toolbox outside of Silverblue. That would really help a lot with keeping dependencies clean.

Definitely looking at getting a Lenovo when it’s time to replace the laptop.

#12 Arrows hobby rc jet on 09.05.20 at 01:46

That’s pretty exciting stuff. I keep forgetting to use toolbox outside of Silverblue. That would really help a lot with keeping dependencies clean.

Definitely looking at getting a Lenovo when it’s time to replace the laptop.

#13 Luke on 09.06.20 at 09:44

This is excellent to see! See my email address. Have a few items I’d love to run by you that may be of interest.

#14 Bubba Walsh on 09.07.20 at 23:12

Linux on Lenovo is all good and well but why does it cost $37 more than the same one loaded with Win10 pro? I would expect it to be ~$100 cheaper than the Win version. Hopefully that will change or maybe it is a typo but I would go with the Win option and load it myself then give or sell someone the windows license.

#15 red.herring on 09.08.20 at 20:37

@Liam: per uraeuses comment, they are having weekly meetings, so they have some leverage. pressure from multiple vendors would help. they could develop driver for nvidia if those would release the docu (dave did this previously for amd, no?).

@debarshiray:
i didnt mean that like a provocation, but really it looks to me like new tool was developed where we already have one that provides the same. reasons:
(1) lxd supports what was written in the article,
(2) it was written in go
(3) it downloads images automatically.
(4) is i dont need to be root to use it if you belong to a certain group (so if you thought about which user is used to run the daemon, i really dont know).
i am using lxd for the same purposes toolbox was mentioned in the article. as an alternative to canonical developed tool, systemd-nspawn could be used (could it?).
so,
– what could be he reason to make a new tool that provides features as good tools available already? you mentioned a thing or two, but not sure if this covers it (oci, no-daemon, no-root).
– maybe the right question is – what can toolbox do that other tools cant?

@uraeus:
regarding nvidia.. (trying to structure my thougths so it doesnt look like a rant, which it probalbly is):
– rh is having weekly meetings with nvidia where nvidia is not contributing neither docu nor the code (my assumption – is this true?)
– while rh is having those meetings, rh funded developers are wasting their efforts reverse engineering the driver which can be solved relativelly quickly by those devs if nvidia would release documentation (no support from nvidia)
– nvidia support in linux is actually “not the best”, considering eglstreams and instead, people are blaming linux because their “windows driver is good” (negative option making on opensource due to shitty driver and desktop situation)
– nvidia, semiconductor company currently more valuable than intel, does not want to properly support linux with opensource driver by hiring 10 devs (no support)
– you think it is your job to ensure working hardware by providing drivers, while this is completely responsibility of the hardware company. if their driver doesnt work because you cant see the terminal to install a binary driver, they should be the one providing the open source one. are they actually involved here? (negative impact on customers to keep control)
– nvidia has proven to be is anti-competitive and of ethically questionable business practices (remember geforce partner program?)
– nvidia can provide no-cuda driver / vulkan only as opensource, but choose not to. so, how dont they despise gpl?
– most distingushed person in the linux world has stated that nvidia is the worst hardware vendor kernel developers have ever had to work with. so, 2nd time, how come they do not despise gpl2?

#16 Wow on 09.14.20 at 16:19

Thank you for your support in Korean.