two thumbs and now building nvidia drivers by hand. waste of my opposable thumbs
Discussion
Loading...
@hipsterelectron opposable thumbs were a mistake
👍🪓🐔
👍🪓🐔
@lkundrak we lost everything when we lost the toes of our ape form
this time it failed for a good reason but i'm about to make it fail for horrifyingly nihilistic reasons again
OMG GUESS WHO HAS TWO THUMBS AND NEEDS TO COMPILE THEIR KERNEL FUCKING AGAIN AFTER UPDATING GCC
i'm about to literally fix all of this for everyone but i need to fix this to do everything else
the problem is never ever gcc's fault. the problem is your fucking tooling
sometimes the problem is gcc's fault
@hipsterelectronhttps://tech.lgbt/@somebody/114492884140168697 if you knew the horrors that lurk within GCC you would howl with rage and understand immediately (a fraction of) why this one is actually replacing every single thing down to the last copper supplier (ea nasir joke) (laugh track)
for those keeping track at home that will make 4 full compiles of the beautiful collaboration that interfaces with our hardware
~152 more replies (not shown)
i've decided to set the scheduler strategy to CONFIG_PREEMPT_VOLUNTARY over the linux-zen default of CONFIG_PREEMPT because this laptop has obnoxious specs and they describe CONFIG_PREEMPT as being like for embedded systems (and laptops) whereas CONFIG_PREEMPT_VOLUNTARY is singly characterized as for desktops and i have this thing plugged in 99% of the time
they are pretty clear in the docs for each of these choices why this can't be a dynamic setting because it's about compiling in explicit pre-emption points. kind of an interesting result for such a dynamic process like a scheduler
oh wow but you can change it on the kernel command line and they so it's a very small increase in code. compilers are amazing
i kinda wanna try LTOing this just to see if it will crash my system somehow
i think i'm gonna turn off things like profiling which i don't need right now
kexec is so cool lol
oh hell yes missed CONFIG_SCHED_AUTOGROUP before. linux very much does try to separate build jobs from desktop applications
CONFIG_RCU_NOCB_CPU has a tantalizing description of reducing jitter at the cost of greater context switching. with so many of these switches they really try very hard to make it clear there is no clear right answer (or presumably it wouldn't be config in the first place)
lmao
Say Y here if you hate IPIs.
Say N here if you hate read-side memory barriers.
this is a safe space!!!! we run on spite here!!!!
i delved into the RCU configuration and read some of the great docs and i changed absolutely nothing in the config but had a great time
DAMN! just learned about /proc/pressure. very VERY useful. cargo should be aware of this; maybe my pants could be. i wonder if the make jobserver uses this if available for -j?
i'm gonna enable LTO and then immediately regret it and cancel. or even worse i won't regret it until it's too late. i wanna see what a real fucked up LTO looks like even though i know the only people who run with that option are like google with massive 200-cpu servers
i ABSOLUTELY know this to be true because you literally can't set it in menuconfig and the only supported value is clang's ThinLTO. will mark as TODO to try enabling LTO with gcc and make jobserver
kinda funny about why the status quo is like this. google benefits from the clout saying "yeah yeah yeah we LTO the KERMEL we are FUTURW" regardless of the performance bc as you recall google does not care about computer performance. whereas presumably if gcc lto was not actually useful it wouldn't be worth anyone's time to plumb it into the kernel makefiles
we are now at the drivers/
i do not need like all of these drivers i should just drop them all......i'll let this finish then reboot
[takes deep breath]
nvidia.o: error: objtool: isLibosPreserveLogBufferFull+0x84: 'naked' return found in MITIGATION_RETHUNK build
NVIDIA DRIVERS HAVE NAKED LESBIANS THUNKING EACH OTHER WITH OBJECT FILES
this message is reproduced for literally every exported symbol in every object file. i will not be deterred
i love cute shit like this from makepkg
Bugs? You must be kidding; there are no bugs in this software. But if we happen to be wrong, please report them to the issue
tracker
it's a good man page so they're allowed to be cute. i guess you could be sufficiently cute to make a bad man page.......it would be an impressive feat
the ceph network filesystem seems vaguely interesting but very corporate and the way they spread their config dependencies (the config dependencies part is at least pretty well done) very deeply into separate subtrees makes it unlikely someone would take the time to remove it all unless they get upset like me and tear it all out
like whack a mole but nothing moves you just can't whack the mole without first answering their riddles three
the one part about the dependencies that is not at all well engineered is not giving you a way to disable/enable all dependencies as necessary for the one you want to work. i also think gitignoring .config is a strange decision because it is ridiculously important for users to track their config changes and git is a tool for doing so
omg this shade from CONFIG_FTL
You may find that the algorithms used in this code are patented
unless you live in the Free World where software patents aren't
legal - in the USA you are only permitted to use this on PCMCIA
hardware, although under the terms of the GPL you're obviously
permitted to copy, modify and distribute the code as you wish. Just
not use it.
OMG IT'S THE SAME FOR EVERY PROPRIETARY FLASH LAYER LMAO
still think it's ridiculous to have a dependency system for config that can stop you from deselecting something without a corresponding way to burn the whole edifice down. maybe this is because .config is also gitignored lol. layers of decision making (....i should really just name mine something else. oops)
i'm now disabling things that the arch linux zen config should clearly have disabled like the CONFIG_MTD_MTDRAM test device driver. i think arch is very low effort on these things though :/
i should switch to alpine again
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled