That's cheap. If you think that a safe first-party replacement battery will sell for less than the 79€ that the whole replacement effort takes, then you're fooling yourself.

I strongly suspect that there's also not good language for blocking against third-party batteries (and the phone manufacturers would have good reason to do so because it might result in overheating or worse with really bad third-party batteries).

MacPorts has some level of support for PowerPC, but anything that isn't in the most recent ~3-4 releases is likely to be cut off from any number of packages at useful versions. (There's substantial work down to support Rust on much older versions of macOS, but there's also versions above which Rust has cut off older macOS versions.)

I believe that there's a recommended stream for when you need older versions support, but it's definitely a secondary target from what I've been reading on the MLs.

I accept LLM contributions to most of my projects, but have (only slightly less) strict rules around it. (My biggest rule is that you must acknowledge the DCO with an appropriate sign-off. If you don't, or if I believe you don't actually have the right to sign off the DCO, I will reject your change.) I will also never accept LLM-generated security reports on any of my projects.

I contribute to chezmoi, which has a strict no-LLM contribution (of any kind) policy. There've been a couple of recent user bans because they used LLM‡ and their contributions — in tickets, no less — included code instructions that could not have possibly worked.

Those of us who have those rules do so out of knowledge and self-respect, not out of gatekeeping or ignorance. We want people to contribute. We don't want garbage.

I think that there needs to be something in the repo itself (`.llm-permissions`?) which all agents look at and follow. Something like:

    # .llm-permissions
    Pull-Requests: No
    Issues: No
    Security: Yes
    Translation Assistance: Yes
    Code Completion: Yes

The one thing that I will never add or accept on my repos is AI code review. This is my code. I have to stand behind it and understand it.

‡ I disagree with those bans for practical reasons because the zero-tolerance stance wasn't visible everywhere to new contributors. I would personally have given these contributors one warning (closed and locked the issue and invited them to open a new issue without the LLM slop; second failure results in permanent ban). But I also understand where the developer of chezmoi is coming from.

     {macports.halostatue.ca:austin @halostatue}

There is a chance — depending on how stubborn the cloud infrastructure provider is (and both Google and AWS can be very stubborn because they don't like admitting that they just might possibly be wrong; I have no experience with Azure but imagine its the same) — that Coveralls will be unable to recover from this because rebuilding the infrastructure from zero on a different provider is going to be hard even if there is 100% IaC and even if there's a solid database backup outside of that provider that's accessible.

I hope they can, because they're a reasonable service and provide a lot of value to open source projects for coverage measurement.

That said, I have seen a number of reliable paths to getting extremely slow responses and eventually 500s from the coveralls servers while trying to look at the coverage details. It has felt like there's been a slow decline in Coveralls server quality because of that. (I've never really reported any of these because (a) I hoped that they were seeing these in their logs, metrics, or notifications and (b) I'm not a paying customer and it's easy for me to `open cover/excoveralls.html` or the equivalent.)

(I have tried the major alternative, codecov.io, in the past, but it's been a long time and I find it disappointing that they appear not to keep their example repos / documentation up to date.)

I would want the equivalent of the trixie-slim Docker image (Debian 13, no documentation). It's ~46 Mb instead of ~4Mb as a Docker image, but gives a reasonably familiar interface.

(This is largely based on some odd experiences with Elixir on Alpine, which is where I am doing most of my work these days.)

I don't really agree with you on this, even though I agree with everything else here. Then again, I am an outlier where I've used ~40 programming languages in my career. There are a couple of language families (array languages like APL, exotics like BF) where I cannot read it because I've had no real opportunity to learn them, and there's a significant difference in being able to read a language and use a language (I can read, but not really use Haskell -- although I have shipped a couple of patches to small libraries).

I despair at the number of developers in the profession who understand only one or two programming languages…and badly at that.

(It's worth noting that I wholly disagree with the original post. 24 years ago I chose Ruby over Python because of syntax. Ruby appealed to me, Python didn't — purely on syntax. I never pretended that Python was less capable, only that its syntactic choices drove me away from choosing it as a primary language. I'm comfortable programming in Python now, but still prefer using most other languages to Python … although these days that has more to do with package management.)

So: TL;DW.

Video-first is generally as ridiculous as SEO-driven recipes where I can't start cooking what I want to cook because I have to go through someone's nonna's best friend's sister's cooking life story.

It's great that this video gets to the point in the first 33 seconds, but make me want to watch your video.

This post made me not care.

I get video bug reports all the time at work -- but it's accompanied with a description of what the problem is that makes it worth my time to watch the video. (Sometimes, with a well-written description, I don't need the video but watch it to make sure my understanding matches.)

I don't watch video complaints. I don't watch most YT videos except at 2x because by time the person who made the video got started saying what they're trying to say, I could have finished a text article version of the same thing.

Most people speak way too slowly for me to be interested in what they're saying, especially when they could have written an article that is more information dense and it typically shorter in any case.

Videos have value for enhancing reports, but are mostly useless as reports themselves.

So yeah, it's too damned much to ask to watch a video.

Aside from the fact that I've built workflows for lazygit related to patch editing, the main issue I'd have with `difi` is I use vim and won't use nvim (which should have the tagline "not vim", not "neo vim", because it's not vim in very important ways).

With appropriate fortified foods (synthesized bacterial sources adding B12 to nutritional yeast, plant milks, etc.), vegans don't need to worry about it either.

A quick bit of research suggests that as much at 16% of meat eaters have B12 deficiency, so it's a systemic problem.

What I said is the FDA shouldn’t be promoting junk recommendations as if it were gold-standard science.

There are good scientific reasons to avoid animal fats in one’s diet. There are no good scientific reasons to add them back to one’s diet.

In moderation, they aren’t harmful and may indeed improve the flavour or texture of certain dishes when had in moderation. I personally love making butter sage gnocchi or ravioli (it doesn’t work as well with olive oil), but I only make it every couple of months.

Beyond everything else, we know that replacing animal protein with plant protein is a good way to improve health. But it’s not accessible or acceptable to everyone. It’s also not necessarily a good use of some land — land that might be perfectly suited to raising goats is poor for growing crops for human consumption.

That sort of overwhelms the omega ratios. As I understand it, both fish oil and (fresh) flax seed oil are still better than tallow.

With RFK's dismantling of good science, politics can't be put aside, as his reasons are essentially "because I said so".

But the premise of the original article (that beef tallow ever went away, which is required for a comeback) is deeply flawed, and the fascionable junk science from RFK is the dumbest possible reason to use beef tallow.

Just don't expect me (a vegetarian) to eat anything that has beef tallow, and expect me to be very pissed off if I later learn a restaurant or food manufacturer uses beef tallow without disclosing it, because that's taking choice away from me.

But the reality is that there's insufficient science for the promotion of beef tallow in RFK's health treason. For large groups of people it's off limits due to personal dietary restrictions (religious or animal product avoidance) and would be contraindicated for anyone who currently has cardiovascular diseases involving high cholesterol.

Use beef tallow, don't use beef tallow. I don't care unless I'm possibly eating food that you have prepared or manufactured (because I don't want rendered animal fats in my food). But don't pretend that it's a health food. It isn't, but can still be eaten in moderation by anyone who _doesn't_ mind beef products in their food.

Olive oil? Peanut oil? No and (mostly) no.

Compared to hydrogenated margarine that was pushed a couple of decades ago before we learned about trans-fats? Of course.

If you use it when cooking for guests, you should disclose that you're using it (especially for non-meat dishes) because it may add extra fat that they're not OK with or consider inappropriate for personal dietary consumption (they're vegetarian, don't eat beef products, whatever).

I have a friend for whom we can't use anything that has sunflower oil in it, which is _really hard to avoid_ in surprising ways (there are spice blends that I use which have a bit of sunflower oil in the mixes).