> It matters (to me) because `wget`/`curl` plus `patch` is not some exotic lab setup.
If the point is to be able to do `curl https://...deadbeef.patch | patch -p1`, you can just change the extension provided to Github from `.patch` to `.diff`. That way, it just includes the hunks. E.g.
I've changed my mind regarding the email format not being a problem. I was thinking of emailed git commits as this ad-hoc thing, but I forgot that `git-format-patch` and `git-am` exist. It's not just an incompatibility between them and `patch`. If you have a line `---` in your git commit message, `git-format-patch` will not somehow escape it, resulting in git-am truncating your git commit message. The email commit format is kinda bad. Github `.patch` exports are just being compatible with `git-am`, so I don't think it's a bug with them.
This is Re:
> I do not yet know whether the bug belongs to GNU patch, GitHub’s .patch export, or the broader patch-format contract.
I don't think this is a problem with GNU patch or the patch format per se, just the emailed commit format. I think the patch format's good because it allows it to be embedded in other texts and also allows comments or extended syntax between hunks. For example, the lines
diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index 15ba592236e845..725a49a0eee72e 100644
not being part of the hunk and probably being seen as a comment by `patch`.
Simply changing `git-am` to accept commit messages being indented in the email format would allow Github fix the issue of their .patch exports being incompatible with `patch`, in addition to fixing that bug about commit messages being truncated when they have a `---` line.
Hmm... I don't have an ESP32-S3 to test, but looking at one of the esp32s3 linux builds online[1], the binaries are compiled for the xtensa arch. So it does seem to run natively rather than through some kind of emulation. Linux's source does have an arch/xtensa/ directory, so that arch seems to be supported on some level by the kernel. ESP32-S3's docs also mention having an MMU[2], though it's possible it's not sufficiently featureful.
Interesting! I've only seen the older projects which probably predate the ESP32-S3. I wonder how usable this is in reality though because you typically can only buy modules with up to 8MB of PSRAM, so you'd have to swap the PSRAM out for higher capacity or manufacture a custom board.
There's an aftermarket for phone batteries. They're new batteries produced by what I imagine are unaffiliated manufacturers. As long as the phone is popular enough, there should be enough market for manufacturers to make new batteries.
I'm not sure which I like more: A no-name lithium polymer battery going through its chemical charging process near me every night while I sleep, or a no-name lithium polymer battery doing the same thing somewhere else in the house every night while I sleep.
Both seems pretty non-ideal if it decides to go exothermic and start a fire. Neither will be actionable (what, I'm going to sue a nameless company in China?).
I am sure of this: Until this battery chemistry is sorted out to be unilaterally safer (which may never actually happen), or we switch to something else that is safer, or third-party manufacturers start bringing their face to the table instead of deliberately hiding in the shadows, I'm sticking to batteries that are sold by the company that made my phone.
I don't have room in my life to save a few dollars by buying cheap lipos from unknowable sources. There's too many corners that can be cut to save on process expense and QC, and they far too often are cut.
And to that end: A standard, legislated promise of 5 years of availability from sounds a lot better than what we have today.
Different programs may take different amounts of time to cleanup and close. To know if a signal failed takes human judgment or heuristic. A program receiving a signal is even able to show a confirmation dialog for the user to save stuff, etc. before closing.
That's a valid point. Another example is SIGHUP, which will cause some programs to exit but other programs to reload their config file. In certain very specific cases, that could even cause harm.
So really what "kill" would be doing is automating a common procedure, which is different than taking responsibility for doing it correctly. It would need to be configurable.
I still think it would be a net benefit since right now incentives push people toward doing something the wrong way (even if they know better). But I can also see how it might give people a false sense of security or something along those lines.
It's not common. If `kill` on its own (which does just SIGTERM) doesn't work, you're already in "something wrong is happening" territory, which is why:
>>> Given that this is the right way, it shouldn't be more tedious than the wrong way!
is also the wrong way to think about this. Trying a sequence of signals is not so much "the right way" as it is "the best way to handle a wrong situation". The right way is just `kill` on it's own. SIGTERM should always suffice. If it doesn't to the user's satisfaction for a nonjustifiable reason, then you can just `kill -9`, but this should be rare.
Trying a sequence of SIGINT, SIGHUP, and SIGABRT is technically better than SIGKILL but not really important unless you also want to write a bug report about the program's signal handling or fix it yourself. About SIGINT and SIGHUP, if SIGTERM doesn't work, it's unlikely that SIGINT or SIGHUP would. Likely, it would only be through oversight and the execution of default handlers.
`kill -9` is just like `rm -rf`. I wouldn't suggest that `rm` automatically run with `-r` or `-f` when `rm` on its own didn't work, and I wouldn't call automatically trying those flags "the right way".
Works on Android. Trying it on regular Firefox on Pinephone Pro results in:
> This page is slowing down Firefox. To speed up your browser, stop this page.
Weirdly, the image animation doesn't render until I hit the "Debug Script" button that Firefox presents, which pauses execution. It's only with the JS paused that the animation begins.
The pause is at the `for (; b < a + 60; )` loop that works an OscillatorNode. I guess a sound is supposed to be played. I checked youtube and sound works. I guess this loop prevents the firing of whatever event the animation depends on.
Loop terminates. It's just really slow. Only once it ends does the sound happen (haven't used OscillatorNodes before; probably normal).
Checked for sound on Android's Chrome. There's none. Checked youtube on Android's Chrome, sound works. Checked Firefox on Android, seems to have the same problem as desktop Firefox on Pinephone Pro. No web inspector on Android to check, but I waited and eventually the sound started playing. It's been several minutes and it's still playing. Image animation hasn't started.
> attach 10x length worth of AI appendix that would be helpful indexing and references.
Are references helpful when they're generated? The reader could've generated them themselves. References would be helpful if they were personal references of stuff you actually read and curated. The value then would be getting your taste. References from an AI may well be good-looking nonsense.
I agree wholeheartedly, I don’t see any balance in the effort someone dedicated to generating text vs me consuming it. If you feel there’s further insight to be gained by an llm, give me the prompt, not the output. Any communication channel reflects a balance of information content flowing and we are still adjusting to the proper etiquette.
Note, it's not one prompt (there aren't really "one prompt" any more, prompt engineering is such a 2023-2024 thing), or purely unreviewed output. It's curated output that was created by AI but iterated with me since it goes with and has to match my intention. And most of the time I don't directly prompt the agent any more. I go through a layer of agent management that inject more context into the agent that actually work on it.
If the point is to be able to do `curl https://...deadbeef.patch | patch -p1`, you can just change the extension provided to Github from `.patch` to `.diff`. That way, it just includes the hunks. E.g.
https://github.com/torvalds/linux/commit/dca922e019dd758b4c1...
I don't see it as a problem with the email format, because I can't imagine someone just patching from an email without looking at the email first.
reply