samueldr

This message brought to you by github and gitlab.

(Yes, there is a double meaning to the initial sentence...)

@cadey @cas I'd rather have --allow-empty-message than not being able to trust commit messages being accurate. And yes, they may already not be. But when they're not, they were at least a human-made mistake. And why the fuck should the generated commit message be baked into the commit? Why not let generation happen on-demand such that when the models improve, the message improves?

@artemist how much code could a claude code clod?

@kate I think one important distinction here is that there is a clear cause, and that for some fucked-up reason they never thought about unreliable connection causing such situations... And that for some other fucked-up reason somehow my clients on other systems see the messages fine, but other people can't... I would have assumed that the messages for self would be propagated using the same rules across clients, whether they're me or another user? But I don't know the protocol one bit, so I couldn't say.

@daandemeyer Correct my if I'm missing something, but AFAICT the detection for serial output first relies on the EFI_SERIAL_IO_PROTOCOL count, which means that it will only count serial consoles exposed for I/O by the EFI runtime. The available serial devices may not all necessarily be exposed "faithfully" as I/O. First situation is the protcol not being implemented, or having no serial I/O devices exposed... That specific situation is fine as that will fallback to the existing kernel semantics. Where it's not fine is if a single serial I/O device is exposed, and that device is either not the correct device index (0), or not the correct hardcoded device type (i.e. on ARM ttyAMA0). For ARM, the device (ttyAMA0) is a very arbitrary decision that will only be true on systems that use the PL011 peripheral for their "debugging" console. Otherwise this AFAICT fails if for example ttyS2 is the debugging console, but the EFI_SERIAL_IO_PROTOCOL exposes only a single I/O device.

@Ember keep in mind that situations can be nuanced, and (more for anyone else reading this) don't go and abuse the maintainers, developers or contributors involved... There are clues easily accessible nearby if you really want to find out what it was.

@alexia none of those you listed.

@Ember not a real “DE”, as it's just bits I assembled together, so don't read too much as it being part of a specific environment.

@lispi314 Time to "pleasantly" keep thinking about the person on the other end. In this particular instance the situation might be more nuanced than just a "vibe coder"[sic] maintaining and working on a project.

@jak2k not a real “DE”, as it's just bits I assembled together, so don't read too much as it being part of a specific environment.

@coreboot@fosstodon.org @novacustom@mastodon.online @conservancy@social.sfconservancy.org Huh, @frameworkcomputer@fosstodon.org? Anything to announce?

@daandemeyer I'm also wondering how this ends-up working with non-headless systems where either there is no GOP in the EFI implementation, or where simple-framebuffer is being handed down to the kernel, but without the actual GOP protocol being available... If the desired outcome is that "when the kernel can output to the display, put the console on the display", this implementation may pick serial while the kernel would have previously used the display.

@baloo it's 🤔 "what if linux was a process you ran on your linux system?"

@daandemeyer not sure if applicable, but you might prefer not relying on tty.*\d identifiers, and instead use either the device paths or the variants with specific addressing: https://github.com/torvalds/linux/blob/9147566d801602c9e7fc7f85e989735735bf38ba/Documentation/admin-guide/kernel-parameters.txt#L959-L991 It would require double-checking whether or not the other earlycon parameter values work for console=, and when lacking console= if earlycon ends-up being preferred when provided. https://github.com/torvalds/linux/blob/9147566d801602c9e7fc7f85e989735735bf38ba/Documentation/admin-guide/kernel-parameters.txt#L1429

@baloo um, you'll find that as documented, it just does it by default!

@matthewcroughan @baloo works.

@mhoye@cosocial.ca FWIW, not that the article talks about it overtly, “surveillance pricing” is already here with the different reward programs with personalized offers. It'll only get worse from here. Don't expect to see what conspiracy theorists claim online, where “those e-ink labels will change prices during the day”. That is far too impractical. What is more likely to happen is this being handled through rebates on inflated “base” prices.

@cas@social.treehouse.systems 🤔 in the off chance people are curious, finding repos that includes paths such as core/systemdrivers/hwio/scripts on some git hosting hub might return .per files that can be used to check that the tool works. (I am under no relevant NDA.)

@endrift@social.treehouse.systems @mhoye@cosocial.ca 🤔 maybe we should git commit -m "$(printf 'code changes:\n\n' ; git diff --cached)" instead of writing useful commit messages... (j/k)

@ernie@writing.exchange when I “rehydrate” old code, I try to make commit(s) referring to the archive used, untouched, and attribute + backdate the authorship data. git commit --author="Ari Luotonen " --date=1995-06-05 --amend Thinking like an archivist, it allows another archivist to double-check that the data is as-expected. And it's better for transparency when fixes are being done. See for example here: https://github.com/samueldr-wip/tmp-wip/tree/archived/WIT.1994-06-05.tar.Zhttps://github.com/samueldr-wip/tmp-wip/tree/tedium/rebasedhttps://github.com/samueldr-wip/tmp-wip/compare/archived/WIT.1994-06-05.tar.Z...samueldr-wip:tmp-wip:tedium/rebased And well, since the files were not modified in-situ in your case, it gets a bit awkward, so by massaging the data just a bit, we can see the diff here: https://github.com/samueldr-wip/tmp-wip/tree/tedium/rebased-againhttps://github.com/samueldr-wip/tmp-wip/compare/aaf718eee66c9b92d7a1f9296ea063c013c5d27f...samueldr-wip:tmp-wip:tedium/rebased-again?w=1 (The w=1 parameter makes the diff ignore space changes on GitHub.)

@Ninji@wuffs.org I know you do these regularly, but still, this time I misread it as "Here are some random photos I've taken mistakenly", and now I wonder...