aard

Currently my mk4 is printing pretty much 24/7 with IS profiles. I’m applying some lubricant roughly once per week - sometimes I notice the printer starts making strange noises, mostly I notice when rods have zero residue between prints, and just add a bit.

All my software can be configured using dedicated configuration files (.c)

Bosch has a bunch that are quite useful for sanding in corners: https://www.boschtools.com/us/en/sanding-polishing-43817-ocs-ac/

I didn’t do enough testing with different materials for a conclusive answer - but that was my guess as well.

I should have 3 different glow filaments somewhere, one PETG, two PLA. Typically I preferred the PLA versions - they had a bit more uniform glow. The PETG one had brighter spots, but as it was mostly transparent individual spots were more visible than with the PLA prints.

I have a custom TrueType font embedding the UCS bitmap fonts so I can use it with modern font renderers which dropped support for those old font formats.

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”

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.

Somebody is pretty salty for no good reason. The maintainers own patch is nicer code than the suggested patch - and the change is small enough that there just isn’t anything available to guide the reporter to a better solution without wasting everyone’s time.

I’d probably have added a thanks for debugging effort into the commit message myself - but “please accept my patch because I want to have code in the kernel” is a very stupid thing to say, and the maintainer offering a suitable problem to fix is more than I’d have done in that situation.

Also: The Wii is about to turn 17. And is holding up surprisingly well. My kids love the sports and dance games - and none of the newer platforms really managed to provide the same feeling for that kind of activity games.

Bourne shell is orders of magnitude worse clusterf*ck than JavaScript, yet it’s rarely criticized.

Both have their place. Bourne shell scripts are great as a container for connecting the various tools you have around - and for that kind of relatively simple script is way easier to use than something like Powershell. If you use it for something more complex you’re probably an idiot.

Same with Javascript - if you need to annoy someone with popups on a website, or have something dance around in the window it’s a great language. If you use it for something else you’re probably also an idiot.