The "DRM" acronym for Direct Rendering Manager goes all the way back to the 1999 Linux driver for 3dfx graphics cards. It predates the "Digital Rights Management" acronym by at least 5 years.
For what it's worth, the Oxford English Dictionary gives two citations for the phrase, one from January 1996 and one from May 2005. It's not obvious to me from the quoted text whether the 1996 citation actually has quite the same meaning as we're talking about here.
It's from something in PR Newswire, and it says: "As an industry consultant Bob has been a leader in developing business strategies and cooperative relationships in the area of digital rights management and content distribution."
And what's not clear to me is whether that's "digital (rights management)" -- i.e., using computer technology to enforce copyright etc., the usual present-day use of the term -- or "(digital rights) management" -- i.e., everything to do with handling copyright etc. in the specific context of digital data.
It's a dumb name, to be sure, especially in an open-source context where everyone knows what "DRM" is and will have an overwhelmingly negative reaction to it.
Doesn't make it any less annoying, from my own perception anyway. I have known about DRM standing for Direct Rendering Manager for years, but it's really annoying even today.
Sure, but it'll take a little longer to recognize the context, because the acronym is overloaded. It's like IPC. Or how "inflammable" means both "not flammable" and "extremely flammable".
How prominent was the phrase 'digital rights management' when Linux's direct rendering manager was created (Wikipedia says 1999)? The FSF's 'Defective by Design' anti-DRM campaign didn't start until 2006.
not at all, I recall that no one (outside of the music industry perhaps) used the phrase 'digital rights management' until iTunes added DRM to music in 2003/2004, other things like the copy protection for videotapes/DVDs/games were just generically called copyprotection, or other domain specific terms such as activation (in the case of things like windows XP), not DRM.
Now what? FreeBSD and Nvidia? Dont threaten me with a good time. FreeBSD is so clean that i would love to build a sleek custom variant even if just for my own use, but i need graphics drivers. A “proper” nvidia driver would be amazing.
NVIDIA does have "official" freebsd drivers (including display drivers/etc) but it's obviously not as easy as with AMD. I've never tried using NVIDIA (or graphics at all) on freebsd tbh and I don't know whether the experience works well or not.
I do know there is no nvenc though oddly. because that's built around linux APIs too lol.
but yeah freebsd is pleasantly uneventful and well-documented, and the handbook tells you like 90% of the sysadmin job too. and it's well-integrated with zfs and time-tested.
it's a shame that docker is built around linux, that's where all the inertia is these days.
As a FreeBSD user I haven't run anything else since 2005 and that has been the foundation of my workstation builds. Intel CPU/chipset and nVidia. FreeBSD driver was a bit slower to update to new version, and it never received any of the supplementary software, but that came along the line.
Edit : the summary of quality of drivers is right in the last paragraph in the article.
> Edit : the summary of quality of drivers is right in the last paragraph in the article.
yeah, honestly the problem with linux is the unstable kernel ABI, which BSD does not suffer from. And BSD also doesn't have the copyleft "can't link to anything not GPL'd" problem either.
it's not that NVIDIA's linux teams aren't good, actually they do a pretty good job with the linux driver, has a working GPGPU userland, etc (although the UI makes the windows one look futuristic, and there's been some spats around wayland etc). it's that the linux kernel doesn't care about ABI because of aggressive in-tree'ing of compatible modules, and proprietary binary modules will never be compatible with GPL unless there's some kind of a shim (like they've added). which does not apply to freebsd.
as I said, freebsd is astonishingly boring with how competently engineered and well-documented and stable the whole thing is, and it's a shame that docker/k8s is where the momentum is going. Jails are a great option (and docker is only just now starting to tackle some of the security theoretically open up a lot of support for linux applications/etc. it's just something that most orgs (rightly) won't devote even a minute to looking into, because it's not where the momentum is going.
not talking about backend services/etc here, but, if I had to design a long-life appliance where it needs to run for a long time with minimal supervision and oversight, and have minimal support costs, freebsd+zfs open up some neat options. FreeBSD is stable and long-life, so you're not going to find some critical system component churned out from under you by poettering or someone like that. And ZFS lets you deploy system updates as images/snapshots and do rollbacks to a known-safe version if something goes wrong or it fails to boot etc.
Great post. I feel the same. I look at the heroics done to make the linux Intel and AMD drivers work, and it seems like the current nvidia driver is far simpler. Eg, a binary blob with native wrappers. The only time it breaks is when the wrappers are stale; eg the kernel APIs that it depends on have changed. I run current, and I've only had an issue around the driver failing to compile or run correctly a handful of times in 2 decades, which is saying a lot for an out-of-tree driver.
Absolutely. And those hoops that occasionally happened through the years would happen to any 3rd party kmod package, regardless.
Nowadays for workstation usage RELEASE is good because it has quarterly. No need to track other branches to stay current with the packages, 4 times per year is enough for 99.9% of desktop users. So those kmod hoops are largely gone.
I ran FreeBSD on my nvidia laptop for around a year some time ago and the display drivers seems to work, as long as it was only as a display driver. It was an issue if you wanted vulkan, but that was recently added to the driver. Though if you wanted to play games or get hardware accel to work you would have to run it through a hacked glibc
Thanks for sharing. It would appear i was seriously out of date with the freebsd world, particularly nvidia drivers. I might dual boot linux and freebsd. As my first love, freebsd is the only os out there that i can say to me looks the most logical. I am curious if my wifi and sound speakers (infamous cirrus amps for which i had to modify my acpi tables to work in linux, trivial but not sure how in freebsd) work.
theoretically this is a job for branded zones too, BSD actually solved this problem better a long time ago! just write a shim that hooks whatever linux layer to the kernel layer.
smartOS and proxmox both fill that niche for "hyperv, but it's application containers" niche perfectly. Or full VMs if you want too!
but for both the "making docker work with BSD" and "making BSD work with docker" approaches, the question is how much time a company will spend on an alternative, upstart tech for something as foundational as their container deployments, without a really compelling reason. the answer is likely "zero" and justifiably so. it doesn't matter that you can run a linux vm, it won't matter that zones work with docker or that docker can use OCI. nobody wants to discover a whole new set of bugs and footguns with a niche technology stack.
netflix really ran with it, but even they did not put application servers/containers on BSD, they just used it as a NAS store. which is fine, and that's something that can be encapsulated without letting BSD escape into the rest of your ecosystem. but even though the linux ecosystem is in a state of constant meltdown and rebirth, it's at least the enemy you know.
I wonder if that will change now that redhat has slammed the door on non-commercial users. like where do you even go after that? ubuntu is clownshoes (and the snapd stuff has offended a lot of users). Debian I guess, or OpenSUSE. But SUSE is quite niche as well. Debian is probably the "sufficiently boring" answer, but freebsd could be a good alternative too if places gave it a chance.
as I said it's very impressive how boring freebsd is. Most likely the thing you are trying to do will be either building/loading some module in /etc/rc.conf, or editing some config file in /etc/, or copying some template from /usr/local. And you just do it, there's no surprises, and you move on.
The only time I had problems with the Nvidia driver on FreeBSD was when KMS was introduced because it broke my existing configuration (visible screen tearing during video playback with mplayer in a floating window managed by i3). The solution wasn't pretty, but works to this day.
Time flies. That coincides roughly with my switch to linux server side and macos desktop wise. But each time i gave freebsd a try somehow my gpu didnt work well. Have to try this again. I can run linux in a vm for docker and such but hope drivers work for my wifi and sound.
I've returned to FreeBSD after many years, and I just built 14.0 to get CUDA working. CUDA doesn't need this to run AFAIK. This is about the kernel providing a module that allows a direct rendering interface. CUDA doesn't render to the screen. IIRC, DRI/drm are kernel drivers for graphics that map the GPU video memory window into your process so you don't have to copy data or send it though a pipe or some such nonsense. it was a video optimization from the early days of Linux graphics when copying
Long time FreeBSD'r myself going back to 2.2 and this has been the sticking point of the last couple of years for my org. Everything seems to depend on CUDA these days!
