Fedora starts to simplify Linux graphics handling The Fedora development team are planning some significant changes to the way the distro handles graphics, which will help to push forward the state of Linux graphics support – but it may hinder troubleshooting when things go wrong. The planned changes are coming in two stages. Initially, the imminent Fedora 36 release will …
Same here, bits of old kit repurposed to run Linux when original OS stopped being supported, keep them running until they peg out as
a) Useful to have a spare if main machine fails
b) Laptops, so occasionally get fired up to do a bit of work outside on a nice day instead of being stuck at a desktop.
I have machines that have marched forwards for decades. They don't do UEFI boot, and even if they did but they were in BIOS mode it's non-trivial to swap over.
So one day I'll update to Fedora N and it will break at reboot?!?
Yes, but not any time soon. The aim of their current changes is to forbid new installs that don't use UEFI:
Systems currently using Legacy BIOS for booting on x86_64 will continue to do so.
However, this modifies the baseline Fedora requirements and some hardware will no longer be supported for new installations.
If its a new install, the hardware most likely does support UEFI, even if it isn't currently turned on, so that's not so much of a problem is it?
This was all linked in the article:
While this will eventually reduce workload for boot/installation components (grub2 reduces surface area, syslinux goes away entirely, anaconda reduces surface area), the reduction in support burden extends much further into the stack - for instance, VESA support can be removed from the distro.
[...]
UEFI is required for many desirable features, including applying firmware updates (fwupd) and supporting SecureBoot. As a standalone change, it reduces support burden on everything involved in installing Fedora, since there becomes only one way to do it per platform. Finally, it simplifies our install/live media, since it too only has to boot one way per arch. Freedom Friends Features First - this is that last one.
Simplifying installation components... is the justification that low? Although ironically, completely removing BIOS decreases installation options. VESA, there's the graphics again. SecureBoot, there's the security claim again.
When Microsoft shoved UEFI down everyone's throats I thought it wouldn't matter. Now that Microsoft is shoving TPM down everyone's throats I thought it wouldn't matter... but apparently it's going to. I guess whatever Microsoft shoves down our throat will inevitably be all we have.
P.S. this would all be different if both UEFI + BIOS didn't already coexist nicely, but they do exist together.
But if I have an old machine without UEFI I will not be able to install the 'requires-UEFI' distro? I don't know how many machines that will cross off the list, but I'm guessing it's not a low number.
Oh I see, you're "Outraged of Tunbridge Wells" - no idea whether this actually affects you at all, but are appalled that it might. You can let me know how many of your old machines that are amd64 and have 2 GHz dual core processors lack UEFI support. Perhaps if you're still running older Socket 939 motherboards with Athlon X2..
Pretty much, if you meet the other base level requirements to run Fedora, you also have UEFI available, if not enabled. If you don't, the wondrous thing of Linux is that you can use a distro that is more aimed at running on older hardware rather than a bleeding edge distro. You can unclench those panties, and let the Fedora guys get on with their job of producing a modern OS.
Just means some day Fedora will not work on old machines. But I'm pretty sure there will be other Linux distros that will. Probably even a Fedora fork or respin will, as some Fedora users will decide they will not give up BIOS and x.org, unless you pry it from their cold, dead hands (I myself might be in that group, x.org still has the advantage over Wayland that it works with all desktops envs, not only the most bloated ones).
A bleeding-edge distro isn't a good fit for your equipment. They dropped IA32 support long ago, for example. And there are plenty of alternatives. RHEL8 will be supported until 2029. RHEL9 will be supported several years longer, and as it is currently in beta it is unlikely to adopt these BIOS deprecation changes from Fedora. Come 2030+ it might be time to retire your ancient equipment, or relegate it to legacy/contemporary OSes.
Sounds like Red Hat doesnt think. If they are going to make RHEL not work on new BIOS machine installs in the future. One thing is an absolute certainty, Businesses will use old hardware until it smokes when turned on. For most businesses old hardware is where they test out linux before making further adoptions. Sounds like a simple case of cutting off your nose to spite your face.
> Businesses will use old hardware until it smokes when turned on.
Most businesses throw out equipment in perfect working order the very moment the support contract expires. Lots of great cheap hardware on eBay because of it.
Where companies are running ancient hardware, they are doing it to keep their hard-to-replace ancient software going... They don't want to deploy the latest OS on it.
> The frame buffer device was depreciated?
Deprecated rather, but that's my exact question. Is fbdev deprecated as in will no longer ship with RedHat distros? Or are we talking kernel deprecation?
I'm more of an OpenSUSE man myself so the former case is a non issue, but I've used fbdev about two decades ago for a handheld data collector and last I checked it still has uses in embedded systems and HMIs (human machine interface, in an industrial automation context).
The kernel's fbdev device has been deprecated since 2015. It's a very old-fashioned mechanism for the kernel to display graphics on the system console
Wheels are a very old fashioned approach to transportation. If these guys were car-makers, they'd probably be planning to replace them with something else in the 2026 models. Maybe dozens of tiny feet. Or some sort of serpentine slithering device.
BTW, for those who, like me, have not the slightest idea what fbdev does, it appears to be a driver for the framebuffer. The framebuffer is an area of memory in the X86 architecture that contains a user accessible bitmap of the current video screen. DRM is a acronym for Direct Rendering Manager, not Digital Rights Management. And presumably what this change will do is gratuitously break the workflow of a few folks whose plain old software and perhaps custom hardware just works
References:
. Old proverb "If it ain't broke, don't fix it"
. A. C. Clarke: Superiority ("http://www.mayofamily.com/RLM/txt_Clarke_Superiority.html")
What a crap analogy.
How's your modern car with its carburettor? Those points still playing up? How is your arm after the crank start kicked back? Still, pretty sure that cast iron sub frame is holding those hand beaten panels well, although they are getting a little rusty these days. Just don't go to fast, those drum brakes without a servo can take a bit of stamping on to get them to work.
More like it may be time to stop using solid wooden wheels and try something a little more modern like metal rims surrounded by pneumatic rubber tires attached to axles that are cushioned by shock absorbers. Should make for a smoother ride and make for some easier maintenance in areas, just saying.
> may be time to stop using solid wooden wheels and try something a little more modern like metal rims surrounded by pneumatic rubber tires
Ironically, we're going the other way. Wooden wheels had high fuel/energy efficiency. Those "low rolling resistance" tires used in hybrids and other highly efficient cars are just rolling us part-way back from pneumatic tires towards wood.
If I understand this correctly:
Before, if you were writing the driver for a new graphics card you had to implement fbdev, KMS and DRM. For a car, fbdev is the equivalent of adding an internal combustion engine, petrol tank and gearbox to an electric car. In future, you will only need to implement KMS and DRM. Any software that tries to read the fuel gauge will get the answer "full" from the kernel. Any software that tries to change gear with get the response "gear changed" from the kernel which will also modify the way the accelerator pedal position gets converted to required torque from the motors.
User space software will not notice but kernel drivers will be simpler.
First case is a smaller 4k display. Without nomodeset the console text is tiny and unreadable without bring up a gui I do not often want.
Second case is that I have a situation where I need to ignore the intel igpu and jump into X with an nvidia card. I know there is another solution here, but it is a lot more work.
As for removing support for any computers without UEFI... are we really going to shut out machines that are perfectly functional but happen to not be newish hardware? This totally reminds me of Win11 requiring TPM and forcing older systems into ewaste prematurely.
Heck, if I'm building a qemu VM I don't waste time setting up uefi... it is an unnecessarily complex additional burden. I maybe understand the reasoning, but I disagree with this path.
> Heck, if I'm building a qemu VM I don't waste time setting up uefi... it is an unnecessarily complex additional burden. I maybe understand the reasoning, but I disagree with this path.
I think the likes of this Fedora policy change regarding UEFI will drive various Cloud Providers to support (or indeed by default use) UEFI for their instances. Some of the bigger Cloud Providers already support UEFI but many other providers do not yet.
Another "driver" for their enabling UEFI support is in order to support/rollout Arm instances as these also use/require UEFI.
The Alpine 3.15.0 release (in Nov 2021) [https://alpinelinux.org/posts/Alpine-3.15.0-released.html] made the switch from fbdev to DRM. There were a few minor hiccups at the time but in general it has worked fine.
Obviously if you have some obscure graphics card without a DRM driver you may have issues (I think one model of Aspeed card used for server IPMI boards only gained DRM support in a recent kernel).
It's a great distro for running on bare metal (particularly for servers) - no systemd, very reliable, no bloat, wide range of packages. It really reminds me of the olden days in all the good ways and it's my default for servers bare metal and virtual unless specific requirements preclude it.
I converted all my home machines from Grub2 to extlinux precisely because Grub2 is large and complex and is designed to handle so many boot situations that I couldn't trust it to be secure. (Extlinux is the variant of syslinux that boots from ordinary hard drives with ordinary filesystems. The things that apply to the vast majority of Linux boxes.)
Everyone is quoting Fedora which apparently says that this will only apply to 'a new install'. But what, exactly, is a 'new install'? Does that mean 'any install which is not an upgrade'? I started using Fedora at FC4, iirc. I have never done an upgrade. I just use the custom partition portion of Anaconda (or its predecessors), to keep all of my partitions except / and /var, which are re-formatted. All of my data remains untouched.
Is that a 'new install'? If so, all 5 computers in the house will be obsoleted as none of them use UEFI. This desktop has a UEFI-style bios interface, but boots from the "legacy" BIOS.
I don't care if fbdev goes away if the replacement software is transparent. I do care if X goes away (although wayland *may* be less of a problem in a couple of iterations. As far as I can tell wayland, at present, does not allow for a root user login, which is entirely stupid and idiotic. I know. I know. Root=BAD. Except that setting up a computer is a lot easier as root. AND I LIKE THAT. (From my cold dead fingers, etc. etc.)
Fedora needs to step back a little and really think about the unintended consequences of messing with some of this.
Thanks for the write-up, Liam, but if I could just ask for one thing for Christmas, it would be for people to understand the difference between a *proposed* Change and an *accepted* Change. I do recognize this isn't super obvious, and I'm going to propose we clarify this in six foot tall letters at the top of the page (only a minor exaggeration).
The "remove fbdev" Change is an *accepted* Change for Fedora 36, and it's been implemented already, and it's definitely going to be in (or, you know...*not* in, depending on how you look at it?) Fedora 36, coming soon.
The Legacy Xorg Driver Removal change (for removing the vesa and fbdev X drivers) and DeprecateLegacyBIOS change (for...deprecating BIOS) are *proposed* Changes. They aren't accepted. That means they might not happen. Proposed Changes get posted to the public devel@ list for discussion, and ones like these get a lot of it. Then, eventually, FESCo votes on whether to accept them or not. Changes *do* get rejected. Just because a Change has been proposed doesn't mean it's going to happen. Changes that involve not supporting hardware any more are particularly likely to get rejected. So far the response to DeprecateLegacyBIOS has a strong "bit too soon" flavor to it, and I would not be at all surprised if that one got rejected for now at least.
It'll happen *sometime*, most likely. BIOS ain't gonna live forever. But it may well not happen in Fedora 37, or at any definite time soon.
[Author here]
Thanks for the comment!
Were I feeling especially snarky, I would respond:
"... it would be for Red Hatters to understand that Red Hat processes don't apply to the rest of the Linux industry and so are often inscrutable to outsiders."
;-)
I am ex-RH myself -- very briefly -- and TBH I found the company culture quite hard to fathom myself.
Could I ask you to drop me a line? You can email me by clicking on the byline at the top of any of my articles. I'd very much like to gain a better understanding of this stuff.
Cheers!
> `But as Yogi Berra said: "In theory, there's no difference between theory and practice. In practice, there is."
Neither Yogi Berra nor Albert Einstein.
Quote Investigator puts it down to Benjamin Brewster (1882).
Quote: ".....Eventually, X.org itself will be removed, as the various desktops that Fedora offers shift over to Wayland....."
Someone here please explain to me how I'm going to use my usual remote console to manage remote machines if X.org is completely removed?
You know: $ ssh -X -C -l user -p 1234 192.168.1.100 The "-X" bit is the question....on my local LAN
Or: $ sftp -P 1234 user@32.33.34.250 ...when I need a file on a slow connection in Bankok
And please don't tell me I'll have to use VNC............
Yes, unfortunately, it does look like X.11 is going away, some time relatively soon.
As I understand it:
The modern X setup on end-user desktops -- all the fancy 3D-accelerated true-colour special effects -- don't work over a network anyway. It is 100% local-only... And that includes all the 3D composited desktops that require OpenGL: GNOME 3+, Cinnamon, Unity.
In my testing, although KDE 4/5 _claim_ to be able to do without this stuff, it doesn't actually work right in VMs.
Which means only the "boring old fashioned" desktops that don't use OpenGL gubbins work properly. LXDE/Pixel, LXQt, Xfce, maybe MATE.
Personally I do not use any of this X-over-the-network stuff and never have, I'm afraid.
The sysadmin types I talk to use ssh and so on, command-line stuff, and don't care about desktops much.
And no, VNC is on the way out too. GNOME 40+ and relatives favour MS RDP connections, rather than VNC.
It's a shame to lose X11. The "X over the network" has long been one of the coolest things about unix boxes.
When I started using Linux distributions about 28 years ago, the development goal seemed to be to make Linux distributions similar to commercial unixes like Ultrix, HP-UX, and Solaris. And the developers made a great job of it. RHEL was a really good system by about 2007.
Now Linux has effectively killed off all the commercial unixes. Maybe the guys who develop Linux nowadays have never used them or don't remember them. The goal these days seems to be to make Linux distributions work more and more like Windows. They get less unix-like and more windows-like with every release.
I've given up on RH and Ubuntu and gone back to Slackware, which seems to be the most unix-like of the modern distributions.
I'm a professional system administrator. SSH is one of my major tools but day in day out I'm logged into a GUI environment. What am I doing in that GUI you ask? Launching large numbers of SSH sessions running in an xterm window to connect to the server fleet. Also I have a web browser open. Handy thing is the internet.
What GUI do I run? Mate running on VNC in a FreeBSD VM. For security all VNC traffic goes over a SSH tunnel. It works and it fast.
One of the other things I run is xfreerdp to talk to Windows boxen.
Lately I've started testing running Mate in a Debian docker container. Results so far are promising.
If necessary I can access this entire setup from home or anywhere else that a VPN can carry my SSH traffic.
I regard anything in the Gnome 3 line as not worth looking at. Same goes for Wayland. I need remote X capabilities. I know my use case is specialized but so what, it doesn't mean my requirements aren't real.
In the pursuit of looking pretty many modern Linux desktops are functionally a huge step backwards.
I am changing from Mint to Slackware myself. When I finally abandoned Windows and went Linux full time, I found Mint and then realized systemd which explained a lot of "I don't remember this".
I am being more careful this change. Even Slackware is not immune to these types of changes, just not as great of an extent. I find is has elogind and eudev which are not systemd but... And it defaulted to KDE which was OK when I last seriously considered Linux, but it seems to have grown to to nearly a complete userland all it's own. I'm not totally against that per se, but it is part of the problem with a certain replacement init system that now handles so much more. At least with KDE the extra functionality is optional for now.
At this point I am considering a more basic Linux distro or maybe a BSD.
> Personally I do not use any of this X-over-the-network stuff and never have, I'm afraid.
> The sysadmin types I talk to use ssh and so on, command-line stuff, and don't care about desktops much.
I use it on a daily basis, working from home on a windows box, cygwin/X , ssh into the linux box at work, run linux GUI stuff.
Same when working in the office, we have a few dozen powerful linux boxes in the server room, ssh into a few of them, start our software, use the GUI to set the computations, let the computations run, see the QC screens being X11 forwarded to my local box, ssh into the next machine onward and upward.
yes, theoretically you can do this with VNX or !M or rdesktop or ... but anyone who says that has never tried to do this on a day to day basis .. i can have 3 smallish progress monitoring thingies in the top left corner of my left most monitor to see whats going on on all 3 machines, trying to see the same thing with VNS is a nightmare
Sorry, remote X is awesome ..
heck, i've been running jobs on machine across the globe using X11 forwarding over the equivalent of ISDN lines where the fact I could do GUI forwarding saved the company a fair amount in plane tickets (and saved me a huge amount of sleepless nights and jetlags)
Obi-Wan Kenobi said it best. It's your father's GUI. This is the tool of a System Administrator. Not as clumsy or as random as Gnome 3, but an elegant GUI for a more civilized age.
There are choices available for System Admins, you just won't find them in Fedora.
[Author here]
Just out of interest...
I presume that both "VNX" and "VNS" really mean VNC, is that right?
What is "!M" though? I cannot work that one out.
Back in the early 2000s, most of the professional Linux users I know migrated over to Mac OS X. OS X allowed them to do all the familiar stuff, including lots of ssh windows and so on, with a familiar shell and environment, but a lot less hassle.
I think for those still hanging on to Linux now, ~20 years later, who do not like the modern trends such as systemd, Wayland, GNOME shell and so on, and prefer an environment more like traditional UNIX, this is a good time to check out the BSD family.
I wrote about OpenBSD recently and I was genuinely surprised that it is much easier to install a working OpenBSD desktop with Xfce than it is to accomplish that on FreeBSD. And yes, that includes things like GhostBSD or MidnightBSD. PC-BSD turned into TrueOS and then died, sadly.
I hope to at some point soon investigate NetBSD as well, and perhaps write about it, too.
So effectively anything that uses the VGA interface from the 1990's wont be supported for displaying anything after the BIOS until the graphical UI starts. The only reason for the UEFI is to be able to call UEFI GOP operations I presume in the installer.
Some of us that have VFIO boot without any graphics console whatsoever - a USB serial cable connected to another works as a good console for you installs.
In anycase the modesetting code with udev is a pile of shit so getting the userspace to drive it isn't a bad idea.
Not sure why you'd drop BIOS support and require EFI -- what's that save, like one grub package?
But I do believe fbdev has not been required by anything in a long time, that all fbdev drivers have KMS equivallents now. As the "fbdev" name implies ("frame buffer device"), most fbdev drivers were like "Here, the graphics mode is set, here's your framebuffer" and stuff was just drawn straight into memory. Possibly a bitblt for accelerating scrolling. AFAIK all fbdev drivers were ported to KMS or the like long ago.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
