SLSA adoption

Why are you still misunderstanding when other replies already explained?

AUR has always been AT YOUR OWN RISK.

To use your analogy, the house is an underwater cave with a big scary sign warning you that you will die, you go in without training, and blame the cave for not being safe.

My man, this thread has already achieved the intended outcome (or has just temporally coexisted).

There is no need to argue anymore. Enjoy your computers.

> If I need something, I'll just build it myself

That's basically what the AUR is.

In that the AUR involves running a build command and scripts that you didn't put together.

I'm not sure if you're trying to strawman or are inexperienced.

No, this in no way or shape looks like installing a legitimate dependency to the target audience (expert users). This is a package manager, you don't install dependencies via post_install.

No it didn't, it's still in the employee handbook. As the saying goes, a lie will go around the world before the truth can put its pants on.

What changed was Google's motto, and it changed from "don't be evil" to "do the right thing". The given reason is that the prior motto also included inaction.

What if avoiding causing a death instead results in thousands of deaths? Do you give yourself a moral high five and stick your head in the sand?

That is not my call to make.

In a life-or-death situation, maybe a Christian could make the decision to take another life, then spend the rest of their life burdened by the guilt and sorrow of breaking the unambiguous 6th Commandment. There is room for repentance in this context.

That is *far* from the reality of the "defense" industry, however. Making widgets so that some dude at a computer terminal has an easier time drone-striking buildings full of kids halfway across the world is, essentially, evil.

That's clearly wrong, because capital doesn't just appear out of thin air. You are ignoring that there's clearly rare skills involved that enable a few to become very successful. Your strawman only applies to the second generation that inherits wealth, and case in point inherited wealth tends to disappear in a couple of generations further proving that skill is required to build and maintain wealth.

I think this is a cope. It is not only the tech sectors facing poor labor market, it's everything. People can't find jobs

Idk why you're downvoted. Practically everyone i know is unemployed, underemployed, or failing to find a new job to replace one they don't like/isn't paying enough/has bad prospectus.

Lucky engineer types like me in the last group, but many of my college educated friends in that middle group. Shit is rough

It's not for performance, it's for Rust.

If the first stereotype of Rust programmers is announcing that a project is in Rust before any other desirable software property (e.g. stable, performant, etc), the second stereotype is that Rust programmers love rewriting stuff in Rust, just for the sake of Rust.

(The 2.a. corollary is that they love rewriting GPL projects specifically and downgrading them to MIT/Apache)

But there is already gitoxide, an established git reimplementation in git. It even provides a library

gitoxide was started in 2018, back when we were all writing code by hand, and has some reasonable adoption in the rust ecosystem. It's not feature complete, but if that was the issue then surely fixing that would be better than starting from scratch

It's not for Rust, it's for Library.

Well, it's sort of for Rust. GitButler is written in Rust and Jujutsu is written in Rust and we're both depending on fork/exec'ing to an unknown Git binary with no linkable library and no control over the subprocess to do a range of networking stuff. Neither Gitoxide or libgit2 are capable of this either, as much as I love and support those projects.

This project is entirely about providing a feature complete (even if sloppy) library implementation of Git, which does not otherwise exist.

> It's not for Rust, it's for Library.

Prove it - put it under GPL, like the original sources you ingested were.

The moat is not the model, it's the harness. I wager that's one of the main reasons why Google made Antigravity closed source.

I don't feel strongly about anything most folks are arguing back and forth about, but this one is obviously wrong.

Everybody and their brother has made an agent. There are toolkits. You can whip one up in an afternoon.

Not only that, I've found models often perform worse, or at least cost more and take longer, in a big complicated agent like Claude Code, including Anthropic models. They want proprietary doodads hanging off the side (multi agent orchestration, memory, things of that nature) to matter, because they can lock you into tools like that. But, top models can do everything with bash.

But harness is relatively easy to code yourself?

They're just system prompt composer, with some tool functions that the LLM can invoke. I've vibe coded my own in just one day.

I don't understand why this is being presented as an either/or thing.

The moat is actually the harness AND the model, and one of the reasons that Claude works so well is because the model is actually trained with its usage in that specific harness in mind, and the harness is designed to deal with Claude model's idiosyncracies. Easy to validate, just run Claude through some other harness and compare, then just run some other model through Claude's harness and compare

But is there anything preventing them from putting their own proprietary wolfram alpha/prolog/super duper expert system in there?

I guess... but I think, at its core, a good coding harness usually includes:

- well-crafted system prompt that follows best practices

- good contextual reminder prompts (when an llm got stuck in an infinite loop and times out, forgets how to use tools, or needs recurring best practice reminders, etc)

- well-written ergonomic tools the llm can use (read/write files, read diffs, browse the internet, etc)

I dont think these are anything special. The deepest moat I can think of is, proprietary models can be specifically trained to use their proprietary harnesses, so they are more token-efficient and make less tool call and file editing mistakes.

However in my experience, I'm as comfortable working with my own homemade harness as with Claude Code, so I don't think it's a deep moat...

Only that it would just slow down the model and make it dumber.

You can't tool and harness a weak model into strength and you probably don't improve top models with boondoggles.

Could you explain your analogy here, what does a moat have to do with a harness?