halostatue

There's support and "support".

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.

GhosTTY accepts LLM contributions, but has strict rules around it: https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.m...

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

On those repos where I know there's no LLM permissions, I add `.no-llm` because I've instructed Kiro to look for that file before doing anything that could change the code. It works about 95% of the time.

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.

You're welcome to add me as a co-maintainer on this if you submit it to macports/macports-ports:

     {macports.halostatue.ca:austin @halostatue}

I maintain https://github.com/macports/macports-ports/blob/master/sysut... amongst other things regularly.

This will not be a fun retrospective (the status updates are brutal and clear) -- and I've only been using Coveralls for open source projects for years.

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.)

Disclaimer: I haven't tried this yet.

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.)

> There is no real universal intuition you can build up for programming. There is no point at which you've mastered some degree of fundamentals that you would ever be able to cross language family boundaries trivially.

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.)

It isn't necessarily. A _bad_ video can often be worse than a bad description, because I can read a bad description and reformulate and clarify. This is compounded when the video skips the prerequisite steps that a description often needs to add.

So: TL;DW.

Not at all.

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.)

TL;DW.

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.

I primarily use lazygit for diff/patch editing as I'm preparing PRs so that commits are in a useful order for reviewers (at least those who choose to go commit-by-commit).

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).

I'm not vegan, but ovo-lacto vegetarian, so B12 deficiency isn't anything I've ever had to worry about.

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.

Not sure how you got that from anything I’ve written, because it’s not what I said.

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.

Tallow is still higher in long chain SFAs than vegetable saturated fats, which are less healthy than short and medium chain SFAs (but neither is as good as PUFAs).

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".

I have no disagreement with this and I think I said as much.

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.

I won't bother as I'm vegetarian, which means that I really don't care the "supposed" benefits (which likely pale compared to the ingestion of long chain saturated fats present in beef tallow, as opposed to the short and medium chain saturated fats present in coconut oil). Beef tallow is irrelevant to me except for restaurateurs or food manufacturers who use it without disclosing it. (One should disclose its use in any case. For people who avoid pork, knowing that your product contains "beef lard" instead of "whatever lard was cheapest this week" matters, because they can't do "pork lard".)

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.

Compared to what and for what purpose?

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).

Not to be flippant, but we know that the answer to that is "No" because of Betteridge's Law of Headlines[1].

I haven't read the article ("too hard, didn't care"), but as a foodie:

- in certain food circles, it never went away - industrially, McD's in at least North America used beef tallow as one of the par-frying oils for their fries well into the 21st century -- which caused a stir amongst vegetarians and Hindu who had assumed that the fries were vegetarian (I remember stories here in Canada in 2002-2003) - beef tallow is now fascionable, which accounts for the reactionary resurgence for something that never really went away - the science is very clear that the new guidance from RFK's worm-eaten brain is junk - the science is also very clear that while saturated fats like beef tallow are bad for you compared to olive oil and seed oils, they're better than hydrogenated fats and trans-fat products that were pushed on the world for a couple of decades a couple of decades ago

Beef tallow is a net good inasmuch as it helps ensure whole animal use, but that doesn't make it healthy or suitable for all diets.

[1]: https://en.wikipedia.org/wiki/Betteridge's_law_of_headlines

For years, pipx did almost all the work that I needed it to do for safely running utility scripts.

uv has replaced that for me, and has replaced most other tools that I used with the (tiny amount of) Python that I write for production.

> The whole decision seems like a joke to me and a lost opportunity to set a decent design standard.

That would require that the individuals involved actually have taste. Instead, as with everything else from this administration, it's a toot on their favourite dog whistle.

I'm not sure when that behaviour might have changed, but I have seen it do so. Same with yarn when not specifying a frozen lockfile.

I switched to pnpm as my preferred package manager a couple of years ago because of this, and even that still requires explicit specification.

It was an unpleasant surprise, to say the least.

npm did not always do it right, and IMO still does not do it completely right (nor does pnpm, my preferred replacement for npm -- but it has `--frozen-lockfile` at least that forces it to do the right thing) because transitive dependencies can still be updated.

cargo can also update transitive dependencies (you need `--locked` to prevent that).

Ruby's Bundler does not, which is preferred and is the only correct default behaviour. Elixir's mix does not.

I don't know whether uv handles transitive dependencies correctly, but lockfiles should be absolute and strict for reproducible builds. Regardless, uv is an absolute breath of fresh air for this frequent Python tourist.

In cold weather, one should always dress for 5℃ warmer than the temperature outside when you have a bike longer than 5 km. Runners pretty much have to do the same. Your body heat and good layering will take care of everything else.

Don't need one in Toronto within a ½ day or so of the snow stopping for the major bicycle routes (including the MGT).

Calgary apparently also does a good job of clearing its bike lanes.

And I do my Costco shopping by bike year-round. I think I've used the car for large purchases at Costco twice in the last year.

I _rarely_ drive my car anywhere in Toronto, and find the streets on bike safer than most of the sidewalks in January -- they get plowed sooner than most homeowners and businesses clear the ice from their sidewalks.

And in Toronto we're rank amateurs at winter biking. Look at Montreal, Oslo, or Helsinki for even better examples. Too bad we've got a addle-brained carhead who doesn't understand public safety or doing his own provincial as our premier.

MacPorts separates `node` and `npm` packages like many package managers do:

    npm10 @10.9.3 (devel)
    
    Description:          npm is a package manager for node. You can use it to install and publish your node programs. It manages dependencies and does other cool stuff.
    Homepage:             https://www.npmjs.com/
    
    Library Dependencies: nodejs22
    Conflicts with:       npm3, npm4, npm5, npm6, npm7, npm8, npm9, npm11
    Platforms:            any
    License:              MIT
    Policy: openmaintainer

The Portfile that I created specifies that if `npm` is present in $PATH (which isn't the user's $PATH because MacPorts uses `sudo`) then it should be used and assumed correct; otherwise, it says that the `npm10` port must be installed (because the instructions for oxdraw indicate that one must run `npm install && npm build`).

I've made a private MacPorts port[1]; if I find that I use it frequently enough, I might contribute it to the main MacPorts port repo[2].

One thing that's missing from my perspective (and this is probably true for Homebrew packaging as well, but I don't do that) is Git tags / GitHub releases associated with your Cargo releases.

I can work around it for now by using an explicit release (`9ccd9bf53f9a309ccda42b5c17e9c1056493fb90` is what I'm assuming was your 0.1.0 release point).

I've also assumed that npm10 is sufficient (which currently installs node22 on MacPorts).

[1] https://github.com/halostatue/ports

[2] https://github.com/macports/macports-ports

[3] https://github.com/halostatue/ports/commit/e7331a7fcae362b0d...

As noted, the maintainer is eccentric. They will not do anything that requires JavaScript.

I think that trusted publishing has had a bigger impact than the gem signing that was introduced years ago and never worked well because the infrastructure wasn't present.

It would be better if he did kill it.

The maintainer is eccentric. He refuses to use anything that runs JavaScript out of a sense of "Free Software Purity", which means that he cannot use most of the ecosystem to which Ruby has migrated.

He has only contributed to Ruby via the ruby-core mailing list (he does not use the RubyMine interface which backs ruby-core) and the main Ruby git repo hosted by the Ruby team, never anything on GitHub.

I'm sort of surprised that the RubyGems MFA threshold hasn't been updated (it was 180M total downloads in 2022; my gems combined have > 2.5B downloads, so I was never not going to pass the threshold), but he's under 70M downloads shy and each release gets about 15M downloads or so.

I think that his position is irresponsible in today's threat environment, but given the amount of work that I'm doing for OSS maintenance that's just responding to bloody Dependabot updates…

> … Firefox's origin is in a hacker rebellion against corporatist awfulness

It literally was not.

The Mozilla project and foundation (which led to the MPL) was a dying corporation's attempt to ensure that its source code would outlive its destruction by a monopolist. There was some push from hacker idealists inside said corporation to make this happen, but it still took the corporation's positive action in order for this to happen and not result in everything being sold to the highest bidder in a firesale.

Firefox was an independent hacker's reimagining of what just Mozilla the Browser might be if it didn't have all the other parts which made Mozilla the Suite. After it picked up steam and development stalled on the excessively complex suite, it was adopted back into the Mozilla Foundation and has become what people have used for a couple of decades.

Pure speculation on my part, but I think reasonably well informed: if Firefox hadn't been adopted back into the Mozilla Foundation, it's highly unlikely that the Foundation would have remained relevant but it's also highly unlikely that Firefox would have survived even as long as it has. There simply wasn't enough momentum for it to become a Linux-like project, and Firefox would have disappeared from desktop even faster.