Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@stop OOOHH IT'S A HAMMER AND STAKE
ooohhh
i thought you used something my phone didn't have a character for lmao -
@Parzi its a hammer and a nail.
-
@theKarlisK i tried, like, 23? 25? and half the "up-to-date" packages were sh scripts that referenced themselves or just flat-out corrupted (or 00h-fill), and the ones on the install media were the same but with lower version numbers. (It's real fun when you go to compile something, and suddenly, bash yells about overflowing PIDs every half-second 13 hours in!)
-
@Fast-Nop and then use what for the libvirt? (also the board doesn't support it)
-
@Parzi Then you'd not have the conflict between the discrete graphics card and the APU one in the first place, given that this Athlon isn't an APU.
Are you sure the mobo doesn't support that? The socket is the same, and they're from the same era, 2011/2012. -
@Fast-Nop it specifically only supports Llano APUs, and doesn't include normal Llano CPUs in the support list.
-
@Parzi That's a bummer. Maybe there was a BIOS update, but I guess you have already googled whether someone succeeded with a non-APU in that board.
-
@Fast-Nop Correct, and it's fully updated anyways. I need a full upgrade anyways, as DDR3 is beginning to go back up in price due to age, so if my sticks start dropping I can't replace them, and in total it's inefficient as fuck. I just don't have the money for anything that isn't a $500 sidegrade to an FX CPU. (Also, I have a sneaking suspicion my GPU is being held back some by the board and APU's PCI-e bus.)
-
@Parzi Does the BIOS have an option for disabling the internal graphics?
-
@Fast-Nop It does. It's only Debian that has an issue with it, and it's only Debian that's been having AMD APU issues en masse recently. I'm also then losing the one thing I need to keep.
-
@Parzi What irks me most with the closed drivers is that the kernel doesn't have a stable driver ABI so that the continuous goodwill of Nvidia is required for supporting new kernels - with old graphics cards that don't make Nvidia money. That's not a combo I'd trust.
-
@Fast-Nop i'd more heavily suggest gping the amdgpu route and making open-source drivers to hold nvidia to a standard and allow out-of-production GPUs on latest kernel?
-
@Parzi That's why I won't buy Nvidia in the first place.
On the other hand, Nvidia can afford their antics because desktop Linux is still a fringe phenomenon, and most of the gaming market is Windows.
Plus that AMD has good mid-range cards, but none that can compete with Nvidia's top of the line cards.
And AMD is still trying to compete for games while Nvidia is already on a different level for non-graphic applications (ML-CUDA) where AMD is years behind.
So we don't have 1:1 competition, and AMD's move to OSS was sparked by the insight that they don't have valuable assets to protect. That's why they're open. -
@Fast-Nop OpenCL is shaping up nicely, and AMD GPUs match Nvidia hardware pretty often. A lot of benchmarks are made with Intel CPUs, which seems to provide higher performance with Nvidia, while going for an equivalent AMD CPU gives higher performance with AMD GPUs. My guess would be this is some optimization thing they're doing, but idk.
(also this is another "well the api is closed which is better" argument, which isn't always a better thing. Nvidia's computing API is older, and therefore faster and more mature for the moment, stress on FOR THE MOMENT. Open-source can be better than closed-source as more people with skills get exposed to it, leading to better optimization and such.) -
@Parzi OpenCL is just no match. I remember e.g. the Leela Chess Zero project where they asked for community contribution of computing time for training the networks. AMD was so useless that it didn't even make sense.
There wasn't even ANY reaction in the AMD community, which is indicative of the situation: https://community.amd.com/thread/... -
Distributions don't really matter, the only thing you should worry about is stable release cycles vs rolling releases.
If you want stable: Pick either Ubuntu or the ubuntu-based Linux Mint. (I'd actually advise against Debian as they are too OSS-purist for my taste.)
If you want rolling release, get Manjaro. It's still arch-based but offers better stability out of the box, is more newbie-friendly.
All the other distros will most likely also work. There is virtually no real reason to prefer one over the other. One thing though: Community size and online resources matter which is why I stay away from the more fringe distros; though Fedora and what-have-you will also most likely work for you.
You could even just go by the name you like more. There's honestly not that big of a difference anymore.
So stop worrying and get going. You can still switch later. -
@k0pernikus Debian kernel has a problem with my hardware, as indicated in my first post, and Arch, unless it works OOB outside the one test machine, is off the table, because i'm not spending more than the initial install trying to get it working
Okay, so because my desktop has an APU (AMD A8-3850) and a dedicated GPU (AMD R9 380) in it, and i'm finally getting a (small, probably 240GB because budget) SSD for it, what Linux distro should I use? I'm planning on doing libvirt passthrough for Windows using my APU because fuck running it as a main anymore, it breaks too often. As far as I can tell, my options are as such, family-wise:
- Debian kernel: amdgpu doesn't like that I have an APU and GPU and refuses to see a screen (yes, even after all the Xorg configs and xrandr bullshit and kernel flags and...)
- RHEL: a lot of Red Hat-based distros (mainly Fedora) have packages that are broken out-of-repo and out-of-box recently, but maybe it'll like my hardware? (It's been a few Fedora releases since I last tried it, is this fixed? CentOS has such old packages that it's not even worth bothering with for my needs.)
- Arch kernel: go fuck yourself, i don't wanna take 1000 hours to get it running for a week, nor would the updates be any better than Windows' current problem (or even more so, as slightly more often than not Windows' broken updates just add annoyances and don't hose the system.)
did I miss any?
rant