CalcProgrammer1

I mean, the open source driver already is out. The nouveau driver has been in the kernel for like a decade now. The userspace part has been in Mesa for just as long, though largely was unused due to nouveau not being able to use high clock speeds. That isn't the case anymore, and since the beginning of the year you've been able to test drive the new NVK Vulkan driver on nouveau with GSP enabled to get actually reasonable performance in several select games. NVIDIA isn't creating a new driver, they're contributing to one that already exists. Since this particular patch set is so huge I don't know it will make it into the next kernel release right away but this guy was the former nouveau maintainer, I expect he knows the necessary standards to get his code accepted.

Just fitting objects into the smallest box isn't everything according to the article. This is trying to identify fragile objects and recommend appropriate protective packaging where required to minimize the risk of damage in shipping. If you use a conventional packing algorithm to pack dishes and vases into the smallest box you will receive a box of glass shards on your doorstep. Is AI the best solution? I'm not sure, but using actual statistics of damaged goods and their means of packaging sounds like a worthwhile consideration.

This...actually seems like a good use of AI? I generally think AI is being shoehorned into a lot of use cases where it doesn't belong but this seems like a proper place to use it. It's serving a specific and defined purpose rather than trying to handle unfiltered customer input or do overly generic tasks,

I don't really see why they would hire him to achieve this goal. He had already quit as maintainer. He was out of the picture unless he resigned specifically due to accepting an offer from NVIDIA, but if that was the case and they wanted Nouveau stopped then why is he now contributing a huge patchset? If they hired him and he quit nouveau they could've had him work on the proprietary driver or their own open out of tree kernel driver, but they specifically had him (or at least allowed him) to keep working on nouveau.

Also, if they really wanted to EEE nouveau into oblivion, they would need to get every single prominent nouveau, nova, and NVK developer on payroll simultaneously before they silence them all because once one gets silenced why would any of the others even consider an NVIDIA offer? Especially those already employed at Red Hat? It doesn't really make sense to me as an EEE tactic.

What has been apparent over the past few years is that NVIDIA seems to be relaxing their iron grip on their hardware. They were the only ones who could enable reclocking in such a way that it would be available to a theoretical open source driver and they did exactly that. They moved the functionality they wanted to keep hidden into firmware. They had to have known that doing this would enable nouveau to use it too.

Also, they're hopping on this bandwagon now that NVK is showing promise of being a truly viable gaming and general purpose use driver. Looking at the AMD side of things, they did the same thing back when they first started supporting Mesa directly. They released some documentation, let the community get a minimally viable driver working, and then poured official resources into making it better. I believe the same situation happened with the Freedreno driver, with Qualcomm eventually contributing patches officially. ARM also announced their support of the Panfrost driver for non-Android Linux use cases only after it had been functionally viable for some time. Maybe it's a case of "if you can't beat them, join them" but we've seen companies eventually start helping out on open drivers only after dragging their feet for years several times before.

I'm cautiously optimistic. While I could see NVIDIA hiring him to stifle nouveau development, it doesn't really seem worth it when he already quit as maintainer and Red Hat is already working on nova, a replacement for nouveau. I got into Linux with Ubuntu 6.06 and remember the situation then. NVIDIA and ATI both had proprietary drivers and little open source support, at least for their most recent chipsets of the time. I was planning on building a new PC and going with an NVIDIA card because ATI's drivers were the hottest of garbage and I had a dreadful experience going from a GeForce 4 MX420 to a Radeon X1600Pro. However, when AMD acquired ATI they released a bunch of documentation. They didn't immediately start paying people to write FOSS Radeon drivers, but the community (including third party commercial contributors) started writing drivers from these documents. Radeon support quickly got way better. Only after there was a good foundation in place do I remember seeing news about official AMD funded contributors to the Mesa drivers. I hope that's what we're now seeing with NVIDIA. They released "documentation" in the form of their open kernel modules for their proprietary userspace as well as reworking features into GSP to make them easier to access, and now that the community supported driver is maturing the see it viable enough to directly contribute to.

I think the same may have happened with Freedreno and Panfrost projects too.

This is my cautious optimism here. I hope they follow this path like the others and not use this to stifle the nouveau project. Besides, stifling one nouveau dev would mean no other nouveau/nova/mesa devs would accept future offers from them. They can't shut down the open driver at this point, and the GSP changes seem like they purposely enabled this work to begin with. They could've just kept the firmware locked down and nouveau would've stayed essentially dead indefinitely.

I just use the default case for the most part. I have a third party case from Amazon with a larger internal storage compartment I use when traveling as I can fit a battery bank, bluetooth earbuds, and extra cables in it.

Fuck Riot. Never playing their games again. If you're going to have a shitty anticheat at least give people the option to play in anticheat disabled lobbies. Besides, they should be doing anticheat at the server level not spying on the boot sequence of client PCs. That shit is unnecessary for a fucking banking app let alone a goddamn game. It's just a game, let us enjoy it rather than making such a ridiculously over the top response to cheating.

It's not just 32 on 64 bit, new Macs use ARM64 processors so x86/x86_64 code is effectively obsolete on Mac. I would love to see Valve pour resources into a cross platform x86 on ARM64 emulation layer though, it would benefit Linux as well.

I have both, mainly got the Ally as an experiment. The Deck is absolutely the way to go. Windows is a dreadful experience in general, but especially so on a handheld. No touchpads means awful mouse control, but Windows means an OS designed around mouse control. Asus' software feels like a big hack (because it is) haphazardly glued on top of a stock Windows desktop. Steam Big Picture works OK but the Steam menus are limited in functionality compared to using them on SteamOS and the Deck. Meanwhile, the Deck is an incredibly polished product and the SteamOS interface is controller-first. You can still go to the desktop and use it as a PC, but you won't wind up there accidentally like you will on the Ally. The SteamOS gaming mode is built around operating with a controller and everything works well.

As for running Linux on the Ally? It is doable, but the experience is nowhere as good as the Deck. No seamless sleep and resume< issues with button mapping, limited tweaking of power limits, and more. Just get a Deck OLED and be happy.

I started using Linux with Ubuntu 6.06 and at the time I was really into the game Jedi Academy. It used OpenGL and thus ran fairly well on Wine. I upgraded from an NVIDIA GeForce 4 MX420 to an ATI Radeon X1600Pro and the ATI drivers were absolute garbage so I kinda gave up on Linux gaming for a while. I was set on going NVIDIA on my next PC but around that time AMD bought ATI and opened up their documentation, leading to rapid improvements in the open source AMD drivers. Went with a Radeon HD 5870 and not long after I built that PC I was gaming in Wine again, though poorly on non OpenGL games still. Then Steam for Linux officially released and a lot of native games became available but I was still running Windows Steam in Wine as native Steam didn't play Windows games. Then the Gallium Nine project offered a way to play DX9 games with significantly improved performance and I played a lot of Skyrim on Linux as well as a lot of other DX9 games. Then Vulkan happened and soon DXVK and Proton and the modern Linux gaming landscape evolved quite rapidly until we got to where we are today.

Most of the laptops I've seen the external port is connected to the dGPU.

Most gaming laptops these days don't support true GPU switching as it requires a hardware mux to switch the display between the GPUs. Every gaming laptop I've used from the past decade has been muxless and only used render offloading.