Subnostr

if AMD released ThreadRipper to the consumer market at the same time as they did to OEMs i would have built a system with Threadripper.

but they screwed the DIY market by announcing the product and then not releasing it for a year.

a lot of motherboard makers released motherboards for Threadripper that nobody bought because there were no CPUs to put in them.

Asus ended up re-releasing updated mobo a year later when AMD did finally release Threadripper to the DIY market but by that time Intel already came out with Sapphire Rapids Xeon that had DDR5 and PCIE5 while Threadripper was still on Gen 4 for both.

not only that Sapphire Rapids Xeon had OFFICIAL OVERLCOCKING SUPPORT from both Intel and motherboards, while Threadripper was theoretically overclockable but poorly supported by mobos beause of the whole botched release fiasco.

Intel actually reached out to the DIY Workstation market with the Sapphire Rapids while AMD has spat in our face. Going with Sapphire Rapids was an easy choice for me.

AMD certainly has had their moments over the years but overall they remain a 2nd tier manufacturer compared to Intel and Nvidia. Idiots like you buy them to "own" intel or Nvidia but you only own yourselves.

mleku 2y ago

kernel version 6 is where the problems started appearing in a big way.

ubuntu has never made kernel upgrading work, ever, period. it's not just video cards it's wifi and bluetooth and display power management and suspend always cocking it up.

the kernel development fixes one thing and breaks another.

i say the biggest problem is still the kernel, and because of its monolithic design, changing parts of it can break other parts, and then they fix the breaks caused by the first changes, and break other things.

AMD's open source drivers are perfectly solid, but they aren't all of the equation, the pci-e drivers and various other things, memory management, and power management especially, all have a role in this and none of them are directly related to these drivers.

it's a well known problem in software engineering that Domain Driven Design that when you don't cleanly separate concerns that you change one thing and break another, fix the break and you break another, etc etc ad lib to fade.

the era of linus torvalds c language based monoliths must eventually come to an end, and i don't mean by that we double down on complexity with rust. rust is a total mis-fit for kernel development, and none of the other languages really fit, only Go has the simplicity but without an alternative to GC it can't do kernels.

there needs to be a new generation of programming languages, and Rust is not the right direction, and neither is Go, and these really are the two du jour languages, neither of them are suited to low level programming.

honestly, we'd be better off if people would go back and look at BASIC and Assembler, and DDD and use some of the clever things that Pike brought to Go, the dynamic arrays, the channels and coroutines. these are inventions that enable much better architecting and that, i am quite certain, will resolve these issues.

in the meantime, you've got me thinking again about putting FreeBSD on my rig. i am not encumbered with the hybrid graphics power management hooey anymore, just a crappy vega, nvidia 710 kinda grade capability...

Reply to this note

Discussion