In defense of the parent, upcoming can still be a relative term, albeit a bit misleading. For example: I'm running the 550 drivers still because my upstream nixos-unstable doesn't have 555 for me yet.
I love NixOS, and the nvidia-x11 package is truly wonderful and captures so many options. But having such a complex package makes updating and regression testing take time. For ML stuff I ended up using it as the basis for an overlay, and ripping out literally everything I don’t need, which makes it a matter of minutes usually to make the changes requires to upgrade when a new driver is released I’m running completely headless because these are H100 nodes, and I just need persistenced and fabricmanager, and GDRMA (which wasn’t working at all, causing me to go down this rabbit hole of stripping everything away until I could figure out why).
I was going to say specialisations might be useful for you to keep a previous driver version around for testing but you might be past that point!
Having the ability to keep alternate configurations for $previous_kernel and $nvidia_stable have been super helpful in diagnosing instead of rolling back.
Version 555.58.02 is under “latest” in nixos-unstable as of about three weeks ago[1]. (Somebody should check with qyliss if she knows the PR tracker is dead... But the last nixos-unstable bump was two days ago, so it’s there.)
`nvidia-smi` shows that my driver version is 550.78. I ran `nixos-rebuild switch --upgrade` yesterday. My nixos channel is `nixos-unstable`.
Do you know something I don't? I'd love to be on the latest version.
I should have written my post better, it implies that 555 does not exist in nixpkgs, which I never meant. There's certainly a phrasing that captures what I'm seeing more accurately.
I did not mean to chastise you or anything, just to suggest you could be able to have a newer driver if you had missed the possibility.
The thing is, AFAIU, NVIDIA has several release channels for their Linux driver[1] and 555 is not (yet?) the "production" one, which is what NixOS defaults to (550 is). If you want a different degree of freshness for your NVIDIA driver, you need to say so explicitly[2]. The necessary incantation should be
This is somewhat similar to how you get a newer kernel by setting boot.kernelPackages to linuxPackages_latest, for example, if case you've ever done that.
I had this configuration but was lacking a flake update to move my nixpkgs forward despite the channel, which I can understand much better looking back.
Thanks for the additional info, this HM thread has helped me quite a bit.
> Compared to the overall effort invested, that's careless, badly planned or underfunded.
Not at all. It's a pattern that's very easy to spot while the eyes of the world are looking for it. When it was needed, it worked exactly as it needed to work. Had the backdoor not been discovered, no one would have noticed--just like no one did notice for the past couple of years.
Had anyone noticed at the time, it would have been very easy to just back off and try a different tactic a few months down the line. Once something worked, it would be quick to fade into forgotten history--unlikely to be noticed until, like now, the plan was already discovered.
Like many others in this thread, I've enjoyed a ton of Orbital. My introduction was when 99x in Atlanta played "The Box" a few times and I picked up a copy of In Sides. Also, like many, I spent many a late night learning to code with some Orbital album as my soundtrack.
So many great tracks listed here and I'll add another: one of my personal favorites is their collaboration with Angelo Badalamenti "Beached" from the 2000 film The Beach.
Valve getting involved. Proton. SteamDB. The progress that's been made over the past couple of years is absolutely amazing. For a huge number of games and gamers, Linux is so close to being considered a viable option.
The big problem is that the games that don't work now are for political / financial reasons more than technical reasons--notably incompatible anti-cheat systems or developer refusal to enable the Linux support for their chosen anti-cheat. And these aren't small titles either: PUBG Battlegrounds, Call of Duty Modern Warfare, Fortnite, Destiny 2, Genshin Impact, just to name a few.
I play a variety of games and I would love to boot back into my Arch system as my main daily driver. But, I'm sadly still forced to keep Windows around because my desire to get off of Windows isn't as strong as my desire to continue to play some of my favorite games.
Always glad to see someone else who remembers that era at GT!
CS1311 - Data structures in pseudocode (or Scheme if you had the "X" class)
CS1312 - Build the game "Risk" in Java
CS2130 - Die a painful death at the hands of Jim Greenlee's compiler class.
I actually think the class needs a book or at least an extended article written about the end of the "shaft" era. I've never seen a professor brag about a student offering a bribe in order to pass.
It was interesting to see so many classmates panic in the class over how seemingly arbitrary the zeroes were given over minor mistakes. I, for example, was given a zero for a lab because I forgot to sign in. The grade for this lab was entirely based on signing in though because it was written incorrectly. The class just had tons of "life isn't fair, you should have paid attention" anecdotes.
Per the article, the size of "mid-size" trucks today is about the same as full-size trucks were in the 1990s.
When the pandemic began and I started working from home, I gave up my car because it just didn't make sense to have two and I've continued to work from home and we've continued with only one car. I've decided that I want my next vehicle to be a pickup truck because, as a home owner, I often need to do minor hauling. The truck I have in mind is something like a late 90s Ranger or Tacoma; but, I don't want to buy a 25 year-old vehicle. Unfortunately, the modern alternatives are all so huge (and expensive) that it puts me off the idea almost entirely.
I've been a user of Arch for the past several years and I've always been a huge proponent of the rolling release model. When I first picked up Arch, it was because I needed more modern versions of several tools than were packaged with Fedora or Ubuntu and Arch was a really easy way to get those updates. No more waiting 6 months for the next release cycle to get a new piece of software (yes, I know, "compile it yourself" is always an option--but, I've personally found that nothing destabilizes my system like adding a bunch of software from outside the package manager).
I find my own argument somewhat less compelling today. With systems like Flatpak gaining traction, we're seeing a trend towards separating the Operating System (and I'm thinking more of the overall foundations of a complete, modern system, not just OS = Linux kernel) from the applications for that operating system. Existing package managers handling the OS while Flatpak, AppImage, Snap, etc. become how applications are installed and managed seems to be a good direction.
To be clear, the divide today is far from perfect and we still run into the "Are you running the Flatpak or the distro version of X?" There are also compatibility issues to be worked out. All that said, I do still find the story of "a stable OS with up-to-date applications" compelling.
It's so rarely an issue on Arch. Between the massive official repos and the incredibly comprehensive AUR, I've only needed to do it a couple of times.
My initial comment was about needing to do that on non-arch systems. I've created my own RPM and DEB packages in the past as well; but, at least when I did it years ago, it wasn't as effective as a PKGBUILD on arch.
https://www.phoronix.com/news/NVIDIA-555.58-Linux-Driver