The trick is to always keep roughly a year worth of corn stored, and only sell off the excess.
After the initial 'getting the base running' I usually pay merchants that accept it in corn, up to the amount where they end up giving me all their silver on top of what I wanted to buy.
and send everyone to harvest at the first sign of blight
That sounds like a good strategy until blight happens in the middle of a massive invasion.
I still do mostly corn, but with smaller fields with gaps in between. Makes it easier to take fields out of use if I don't need them and they'd just be wasting work time, and I can ignore blight without losing too much if something else is going on.
While that's generally true we might want to look into utilizing available cores more - but I guess with LLM it might be harder to scale that while keeping file size the same.
A lot of the current compression programs only use one thread properly - which was still perfectly fine a few years ago, but thanks to AMD cores have become cheap. Few years ago most notebooks would come with two cores, and either two or four threads, with higher end models with 4c/4t. Something bigger pretty much didn't exist for notebooks, and was expensive for desktops.
Nowadays you can get 16 cores in a reasonably priced notebook, and if it benefits your work you won't think much about spending a bit extra for a 32 or 64 core CPU in your workstation - where just 6 years ago you'd have had no option for such a notebook, and paid the equivalent of a not too shabby car for the workstation.
It seems to be available in Factory nowadays. Add the X11:Wayland repo for faster updates. You probably also want to install xdg-desktop-portal-hyprland.
I have my own packages in OBS where I occasionally build the latest git version - initially I've been updating it every few days, nowadays it's mature enough that sometimes I lag behind the released versions.
You mentioned a pull request, and that it got edited - which in my workflow is pulling the commit and amending it.
Git has different fields for author and committer - and modifying a commit should leave the author field intact, and just change the committer field. It is possible that github does something weird (I'm usually not doing much in their web UI) - but coming from working with git directly I'd expect you to be present in the author field.
That's roughly what I meant - he should've come out of that experience having learned a lot (there's even an explanation why the other code is better on the mailing list), and had the option of working on a different problem (while he didn't say which I assume it was selected to be more beginner friendly). And instead he's throwing a temper tantrum - that's too risky behaviour for hiring.
From the perspective of the CI guy: Just cross compile from Linux.
You can get the Windows compilers for free - just CLI build tools are enough for your case. The setup can be a bit messy, though. Also, if it's a GCC only codebase so far there's a decent chance it has constructs which will not compile on MSVC. It will not necessarily be faster, though.
So yeah, his patch may be underwhelming. But the help and credit he got for days or weeks of unpaid work was basically nothing. You may be okay with spending days and only getting credits for the bug report, but I suspect many aren't and will not contribute again after such an experience.
Especially in this particular case the effort is in debugging the problem, not doing the actual fix - which is the bug report, where he got credited for. lkml is not the place for "how I debugged this problem" - that'd be what goes into his blog. And if you look around you'll see a lot of "how I helped solving this problem" kind of blog posts.
This change is so simple that guiding him to do it in a good way would involve fixing it yourself in the explanation - and then you'd not show the code so he can do it himself? That's just silly. If he cares about that he came out of that with quite a bit of experience on how to handle it the next time - and he mentions he even got an (assumed to be starter friendly) other issue suggested if he wants to have code in the kernel.
From the perspective of hiring people he turned this from a "nice work debugging a problem, might be a useful candidate" to "tries getting low quality code merged for vanity reasons, let's avoid that guy"
Nowadays I'd recommend a simple postfix + dovecot setup. If you care about a web-UI and possibly some groupware functions put SOGo on top.
You did receive credit. A good bug report allows reproducing and ideally fixing the issue - which can involve considerable effort. This is the difference between your report, and the one you linked from 6 years ago.
Like I said, I'd probably have added an additional thanks for that in my commit message - but I'm unfamiliar with the kind of reports this particular subsystem typically receives, so it is quite possible your report is just something average coming in there.
I personally prefer to include code suggesting a fix in my bug reports - but I usually don't expect it to be just merged as I'm not familiar with surrounding code. I also don't expect that to receive an additional mention - it's just part of the report, and is often cleaner in demonstrating the issue than a problem description.
Two years in and providing a USB-C adapter my wife is still complaining that her current phone doesn't have a headphone jack.
For my daughter I selected the phone mostly for repairability combined with colour choice, which landed me with Nokia - which ended up having a headphone jack. Didn't pay attention to that, but she's happy it is there.