> We don't want GPUs artificially restricted from mining Ethereum.

Oh let's not make sweeping statements haha, I want to play video games much more than I want the ice caps to melt so some ancaps can play multiplayer excel. I'm not usually onboard with vendor restrictions like these, but if the card self-destructed Inspector Gadget style when it detected crypto mining, I'd be okay with that.

And I say that as someone who has turned off their in-wall space heater and replaced it with a 3090 mining ETH when idle. No e-waste, no wasted power, (in this case) just a heater that pays you back.

> much more than I want the ice caps to melt so some ancaps can play multiplayer excel.

brings to mind something I saw recently: "What is bitcoin? Well, it's like if you left your car idling 24x7 it would produce solved sudokus you can trade for black tar heroin"

> no wasted power

Electric heating can be much more efficient than what's effectively resistive heating with 500%+ efficiencies being possible.

Search for "heat pumps" or watch: https://www.youtube.com/watch?v=7J52mDjZzto

Someone else mentioned heat pumps to me in this context too, I'm unfortunately really limited in what I can use in my apartment. It's a condo complex made of brick put up in 1906 - without heating or air conditioning. I'm not in a position to install external hardware. My parents have a heat pump set-up in their house though!

Watched the video by the way, thanks!

I absolutely agree - in the case of Intel, they've been relatively benevolent and open about publishing the full details of drivers for their NICs, because they have a market demand to sell more NICs.

If there were some hidden feature that was not enabled on an Intel 100Gbps NIC, which could be enabled in an open source driver, I'm 100% in favor of doing that. Thankfully there isn't (all praise to our benevolent corporate overlords), but I can certainly see a scenario with another vendor where there might be.

I hope that if Intel were to ever go down the route of big ugly closed source binary blob to make a 100Gbps NIC function properly, that people would go buy hardware from another vendor. With some basic consumer grade 1Gbps ethernet stuff you can see this now on a base debian install, where you need to enable the 'non-free' repo and install a .deb for a Broadcom provided driver to make a NIC work. Because their driver is considerably less freely licensed than Intel's. One of the reasons why I try to steer away from any Broadcom network interfaces whenever possible.

Or in any other category of hardware. With the current chip shortage and lack of viable competing options, it really sucks that there's literally two high performance GPU vendors that exist on the planet, Nvidia or AMD/ATI, and no other choices.

To use most SFP+'s with Intel NICs, one has to load ixgbe with allow_unsupported_sfp=1 due to Intel's wanking. Ultimately this isn't a huge deal, but it's still an instance of corporate crap needlessly complicating Free software.

Super annoying behavior indeed.

But thanks to open source, being able to look at the driver and understanding how that SFP check is done, some people at the Serve The Home forum were able to figure out which EEPROM bit needs to be flipped for these cards to accept any and all SFP modules: https://forums.servethehome.com/index.php?threads/patching-i...

I saw that and wrote an automated patcher as a quick python hack to automate that: https://gist.github.com/ixs/dbaac42730dea9bd124f26cbd439c58e

Another popular solution in an environment where you might have to support six different vendors' equipment, some of which is closed source (juniper, etc) and demands certain SFP+ EEPROM codes, from one pool of spare equipment, is to purchase the optics with blank eeproms and a coding box to write the vendor ID code onto them over i2c bus as needed. There's four or five transceiver companies I can think of now which provide the solution to do that.