How long do you expect them to support Intel processors though? It’s been like 6 years since the last MacBook release had any Intel processor, and Apple doesn’t make OS updates anymore, so it doesn’t surprise me that Homebrew stopped too.

Are you implying that a 6 year old hardware is as good as a paperweight? Outside of the Apple fairyland this is just bonkers.

I'm not blaming the Homebrew project/developers here, but the fact that many people are okay with deprecating perfectly fine hardware.

No, he’s asking what you think a reasonable support timeline is. An open source project supporting hardware 6 years old is pretty awesome.

6 years is really not a long time at all. You can probably find heaps of open source software out there that compiles and runs perfectly on 20 year old PCs. It's not like the maintainer has to do much to retain support--they just have to not make the software dependent on new operating systems.

Bits don't rot.

Bits certainly don’t rot and you’re welcome to stay on the latest stable version that runs on your architecture.

And if you want new bits with the new features, those aren’t the same bits and that work isn’t free.

Exactly. That's all I'm asking for. If version X works on my system today and version Y needs an OS bump, well... that sucks and is avoidable, but whatever. I expect to be able to obtain and use version X tomorrow and into the future. That's it. I'm not asking to make version Y work for me, but it would be nice if they didn't add the OS dependency.

But increasingly, developers can't even manage to keep version X around and working, despite them having to simply not do anything to it to keep it from breaking.

How many of those 20 year old projects had to go through an architecture change that the manufacturer no longs supports? Come on man be reasonable.

Ask MacPorts, which goes all the way back to Leopard-era PowerPC!

Homebrew doesn't have to lift a finger to support Intel Macs. It already does! All they have to do is not kill support for them.

Hey, it's their software, they are all volunteers and can do whatever they want. I'm grateful for the short window of time in which I was able to use their software. I don't get to decide their support period, but I will still hopelessly complain about it. "Deliberately breaking compatibility with a computer because it is old" is my biggest axe to grind with the whole software industry, and I'll shake my fists at this cloud until I die.

How does MacPorts manage to do it?

Why don't you ask them?

I would not expect the software to continue to get updates, but I would expect the software to continue to work.

I'm salty today because I tried to run Fusion 360, and found that Autodesk just out of the blue decided that 1. My computer is too old to run the software (which ran just fine a few weeks ago on the same computer); 2. That I needed to update the software, and 3. The update will not run on my "old" computer. They took software that ran fine on my computer and deliberately pulled the rug out. Fuck Autodesk. I'm spending the entire afternoon exporting dozens of files I have on their cloud, one at a time, since they apparently can't even manage to keep an existing version of the software running.

NixOS is an open source project that runs great on my 2013 Dell laptop. I think the real point of distinction is that brew depends on Apple's OS and SDK, which somewhat ties their hands, while other OSs don't.

I managed to sell my battered old 32-bit Thinkpad on eBay last year. I couldn’t put Trixie on it, but Bookworm installed fine.

There's been a huge step up in basically everything going from intel to apple silicon. It's not a comparable hardware in any sense, and as such, it really does feel like it became a paperweight? I know I never wanted to see an intel macbook ever again the moment I tried M1. It's maybe hard to comprehend how different it is if you haven't used both. And at the same time I'm happy with my x86 desktop for 10+ years. Only thing that really improved in that span was storage.

So I wouldn't say this applies globally to apple users/products, but the post-intel era is a special case. If nothing else, they are helping the environment by not feeding that (literally) hot garbage with more electricity.

You're on macOS. you should know full well that they do not care about those values.

I have one of the last Intel Macs and works perfectly fine (on Sonoma). How long should I expect working tech being supported?

I am already looking at Linux, but still need to get out of the Apple ecosystem. I am not going to spend +2500 Euros every 5 years on a laptop

Sonoma will be getting its last security update imminently (possibly tomorrow).

And given the performance jump from Intel to Apple Silicon, the perceived difference is 10+ years even.

1) usable for most tasks != pleasent to use for most tasks

2) using an Intel Mac as your main computer, for most tasks != using it as a home server

Years, honestly. After all, Intel Macs just received a major macOS release from Apple only 12 months ago. MacPorts manages to support all the way back to Leopard!

It’s not perfect but I’ve just tested and reader mode does work for this website.

Torpedoing how?

How in the world do you need 30k LOC for your CI/CD??

1. be the kind of guy who thinks more LOC = more betterer

2. ask an LLM to do the needful and never ever look at the results except to count LOC

Because it's complex and I'm stuffing 30-50 PRs a day through it. 7 GHA workflows across four self-hosted runners.

I'm on my third iteration, after constantly log jamming previous versions. Most steps aren't "run pytest", they're gates that guard against an LLM's bias to continuously add more and more complexity to a system.

I'm aware of the irony of having a complex system to mitigate complexity, but the key difference is these rules bound complexity growth. If you're legitimately interested in the details, let me know. I'm too tired to write up much more but would be willing to drop in a LLM-authored summary of the details.

The complexity of a ci/cd workflow is independent of the number of PR a day.

Could you drop the LLM-authored summary in a GitHub gist (or so) and link here?

(Suggesting this route, so that we don't spam HN too much.)

Already posted above. And I wish I had thought of your gist idea before posting it.

What are the project's capabilities? I have also written a personal finance application, and it's ~3k LOC total. And have several projects that are dramatically more complicated than a typical personal finance app, and are 30-50k.

This begs the question: If you're using LLMs heavily, wouldn't it be better from a time, correctness, and token perspective to have a more compact and maintainable code base? We don't know what the personal finance app does, how quickly it runs, how much it improves your finance management, how easy it is to install and update etc, or how maintainable it is by people or LLMs. What you did post is a red flag of consequence, without mitigating factors: We know only the red flag.

Another perspective: I use LLMs heavily as well, but don't find they appreciably increase code verbosity, for a given set of features/requirements.

I work for a gigantic financial institution with ~2000 devs pushing code daily with 100s of apps that need to be built and I'd be shocked if we were above 50kLOC for all the CI/CD stuff. It's probably far less considering the point of CI/CD is reproducibility and ease of adding to...

With some models, if you're not forcefully terse, probably 28k LOC of comments!

Great, number go up. Have the features led to actual customer growth, or just increased productivity?

Yes lots and lots of growth.

Yeah, with all the AI needs we’ll just have to transition to fusion energy.

And geothermal.

Not even for the environmental aspects, just purely from energy demands, at any spot on the Earth where a data center could go.

Is this assuming or studying human maintenance?

I’ll dig up the references but I believe they were studying what happened to LLM performance as the complexity and verbosity of the code went up (ie- just letting the LLM rip without doing explicit code cleanup and simplifying).

Please. I’m sorry, but you kind of can’t avoid needing to think about types unless you use a language like JavaScript which is super loose with its type conversions, and you especially can’t avoid in a language like Go. With generics in Go you don’t even need to prefill the types like you go with a lot of other cases, so I’m dubious about the cognitive overhead.

No need to insult JavaScript. In two out of three times the "JavaScript" written will be something like:

    interface Box<T> { value: T }

    function map<T, U>(input: Box<T>, func: (value: T) => U): Box<U> {
        return { value: func(input.value) }
    }

The percentage of people that use LLMs so much that their language would change based on its responses is small enough that I’d doubt it would happen. Maybe for technical groups that use it more, but not for the general population.

Define “direct”, “access”, and “reality”.