ch71r22

It sounds like you are more tapped into this space than me. I'm not trying to push any angle. Apologies if it sounded like I was trying to diminish dat or other projects. I think all of these projects are interesting

A few years ago, I was pretty excited about this but just as a casual observer. I'm out of the loop now

I'd be interested to hear what projects you think are the most exciting to follow these days

Beaker Browser was so cool! Paul Frazee and Tara Vancil. It was always super experimental. I think it ended when Paul left to join other decentralization-focused devs starting to build Bluesky and the AT Protocol.

The way I remember it, back then they were building Beaker on dat in collaboration with dat devs, which I think was basically just Mathias Buus (mafintosh) who was part of an org called Hyperdivision. Now Mathias is continuing the dat/hypercore stuff at Holepunch (building Keet and Pears). It still seems cool, but I think a lot of the most exciting stuff in the dat ecosystem stopped when Paul Frazee left

So I think that original Beaker/dat/hypercore vision has probably moved mostly into the AT Protocol (Bluesky, tangled, etc.). I haven't been following that as much lately. I wonder if anyone is working on something like Beaker Browser for the AT Protocol, or if that even makes sense

Ok I rewatched that now. Maybe this could work? I'm still not sure how much confidence to place in their system for merge gating

Having land as a skill seems weird to me. You could write in your land skill that it should make sure CI is passing, but I wouldn't want to leave it up to the LLM to decide if CI is passing. I'd rather that be a decision enforced by the git remote

I think to make this work the way I imagine merge checks should work, I'd have to set up my git remote to only allow fast forward merges with checks passing. I don't think this work very well with my org's current merge queue setup, but might work better for people not using a merge queue

It sounds like it has no CI / merge gating solution. This doesn't look like a substitute for pull requests -- just a way of sharing edit history.

I don't buy the argument that being able to trace down the initial LLM prompts that led to a line of code will meaningfully accelerate review. That's just like a more advanced git blame. Reviewers will need to understand the code for themselves. A more advanced git blame doesn't really help with that

Just looking at the final version of the PR without all the intermediate history may be better since it won't sidetrack you with half-baked thoughts and assumptions from the development process. You can just focus on the result

There are cool things about this, but I'm not convinced it's actually useful. Even less convinced it's a replacement for pull requests. GitHub isn't great but I don't think this is really tackling the problems with GitHub

Another inspiring book in this vein is Tending the Wild by M. Kat Anderson. It looks at how Native Americans in California lived and managed the landscape. It gets really specific about which plants they'd use and how.

A big part of the book is about reconceptualizing this idea of the romantic "wild" nature. I think it's interesting because it's an example of people who actually lived in a "back to nature" kind of way, but it doesn't look like a rural homestead or anything like that. It's also different in how it's collective not individualistic. The author cites Muir and Berry as influences

For me, yes. I was introduced to Scratch on a field trip as a 5th grader and went home and tinkered with it, making a bunch of games. I later got a Lego Mindstorms kit. As a teenager I learned Java through the Minecraft server modding community and YouTube. I'm now a software engineer for my career.

Yeah I would like to try Tangled if I can set it up in a completely private configuration

How easy is it to set up and run this for private repos?

It looks like it has so many cool features -- stacked PRs, jujutsu support, CI in Nix VMs. But I've never tried it because it sounds like (at least by default) it's some sort of decentralized, peer-to-peer public thing

The original discussion was based on actionable suggestions about an opt-out system for Sachiko

That's a false equivalence. AI is not the same as aluminum cans.

All technologies have political, social, ethical, and economic aspects, and not all technologies are the same. AI is not, in reality, powered by CO2-neutral electricity. As the article mentions, AI is the fastest-growing energy user in the world, so it probably merits a deeper look than aluminum cans.

It's disingenuous because it's attacking something that the article didn't say. It didn't say "kernel devs should prompt less because it uses up water."

The real argument was that AI has many externalities that should be considered (climate change, water use, energy prices, putting people out of jobs) and that Linux, as a relevant and influential political actor, should engage with these topics. It's not even giving a final determination about what Linux should do, it's just disagreeing with Torvalds' total rejection of ethical arguments about AI.

Even if you believe that the technical merits outweigh the other costs, it seems at least reasonable to engage on those grounds. But Torvalds isn't doing that.

Also, simply stating that the "cat is out of the bag" and "Pandora's box is open" isn't really an argument. These are thought-terminating cliches; not logical arguments

The article isn't trying to find a particular example. It's talking about the overall stance of Linux on AI use. It argues that maintainers should consider political/moral/ethical arguments around climate change, effect on water supplies, energy prices, etc.