• 0 posts
  • 7 comments
Joined 10 months ago
Cake day: October 14th, 2025
  • Being kinda dumb never stopped any idea from being good. I don’t know about this one though.

    Combines are called that cause they combine a lot of the steps of harvesting into one machine. They cut the stalk and remove the grain from all the non-grain parts of the plant. That’s a lot of moving parts that all require a decent amount of force, that would all have to be driven by the pedals. I don’t know a ton about combines having never used one myself, but I think a lot of those processes benefit from being scaled up, that is, it’s more energy efficient per plant to build a machine that can process 50 plants at a time than one that can only handle 5, so you wouldn’t gain as much scaling down as you might expect. You could maybe build something that works, technically, but I imagine it would be less of a casual hang and more of a continuous, difficult workout for a team of professional cyclists.

    If you wanted to chill and have a drink with friends, you could winnow your grain the old-fashioned(ish) way: you just need to dump your grain out in a stiff breeze. If you have a fan and a hopper, you could just sit around and chat while the hopper empties, and add another bin of grain every few minutes.

  • I think you’re missing the trees for the forest. Yes, all those downsides make the current crop of LLM implementations pretty shitty for humanity, on balance, but none of them are intrinsic to LLMs, they are intrinsic to the current business practices that are attempting to profit from LLMs. LLMs are just math. Often computationally expensive math, sure, though they needn’t be. But I don’t think it helps anyone to say “LLMs are intrinsically bad and no one should use them” any more than it makes sense to say that blockchains are intrinsically bad and no one should use them (a common sentiment about a decade ago). I think a more realistic approach is to find out what real benefit can be had by using LLMs, and see if that benefit can be realized without all the downsides you mentioned.

    To take the case at hand, I think open source code review is probably a pretty good candidate domain for exploration, because there’s a large corpus of available text that could be obtained ethically, if LLM trainers bothered to put in the work. It seems like Torvalds isn’t concerned with that, and it looks like sashiko only supports LLMs that are known to have been trained on stolen data, which is shitty and I think Torvalds and the Linux maintainers should be taken to task for that. I think LLM makers should get permission from project maintainers before training on their codebases, just as natural-language rightsholders should be asked for permission before using their works for training. I think LLMs trained on ethically sourced data should be permissively licensed and, if they collect revenue, should be expected to kick some of that revenue upstream to the projects they benefit from. I also think such projects could be powered ethically: I have some plans for my own small solar powered server that will run batch jobs when production is higher than my storage capacity. Right now I’m mostly targeting Folding at Home, but I might well run my own LLM trainer if I get enough capacity, and I could see a similar distributed processing network for high-cost jobs from trusted open source LLM projects.

    I don’t think you’re wrong about the scope of the downsides, but I also don’t think it makes sense to take them all as a singular block and judge all possible LLM tools by all possible downsides. I think they are problems that can be engineered around with technical and social guidelines for use. And I think it will be down to the open source community to set those guidelines, because I don’t know of any other group that has the expertise and the motivation to do so.

  • I think asbestos is a good analogy, but I think your claims that the inherent downsides of LLMs outweigh any possible upsides are as-yet unfounded. I also think it’s kind of strange that you assume anyone who thinks otherwise is being disingenuous.

    Maybe they are too dangerous for broad use, and we need to regulate them like asbestos, or uranium. Maybe they shouldn’t be used outside of a laboratory setting or by anyone who doesn’t have extensive training with how to interact with them safely. It seems pretty clear that Torvalds has decided they’re worth the downside, and while I don’t know if that’s a good call, I don’t think he’s operating in bad faith to the detriment of the kernel project. That doesn’t sound like something he would do.

    I feel confident that I don’t have the expertise to say for certain one way or the other, though the experience I do have with software tools makes me think there’s probably an application for them where the downsides can be mitigated to the point where they become worthwhile. I think there’s probably some single-purpose or tailored application of LLMs related to textual analysis that don’t require the theft of the whole internet, and don’t require insane amounts of energy to run. I don’t think we have discovered them yet (at least I haven’t), but saying “this kind of software is only bad and can have no ethical uses, ever” seems premature.

  • The solution is to make sure those LLM tools help maintainers instead of just causing them pain. There’s no question on that side.
    We’re not forcing anybody to use it, but I will very loudly ignore people who try to argue against other people from using it.
    And no, AI isn’t perfect. But Christ, anybody who points to the problems at AI had better be looking in the mirror and pointing at themselves at the same time.
    Because it’s not like natural intelligence is always all that great either.
    The kernel project has been and will continue to be about the technology.
    Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that’s a side benefit, not the point of the project.
    This is NOT some kind of “social warrior” project, never has been, and never will be.
    In the kernel community we do open source because it results in better technology, not because of religious reasons.
    And so we make decisions primarily based on technical merit. Not fear of new tools.

    IMO it’s a pretty clear eyed take. LLMs are tools and, like all tools, are more fit for some purposes than others. And, like many tools, they’re hard to understand, easy to misuse, and dangerous when they are misused (intentionally or otherwise). And, like any tool, they can be used for evil if the user has a mind to do so. Just because they are currently being used to do great harm doesn’t mean they can’t also be put to good use.

    I think the FOSS community, in particular the Fediverse community, does itself a disservice by refusing to engage with them at all. They aren’t evil in and of themselves, they’re just new and selfish people will try to find an angle with them, same as it’s always been. I think it’s up to us to understand them and try to find a way to use them ethically. Show the world that it’s not that we invented scary Artificial Intelligence, it’s just that we created a cool, if wonky, search interface for text. Wonky in what way? Well, I think it’d be nice if there were robust FOSS tools and documentation I could use and/or contribute to, and learn about them with a community of my peers working for the common good, instead of having to either take the megacorps at their word or just renounce anything “AI branded” altogether, which doesn’t feel like a good long term strategy.

  • I want to be dead clear about this, because it’s the entire reason Gorai exists: this is not a robotics framework that happens to tolerate AI. It’s a robotics framework designed because of AI. The bet is simple — the robots worth building from here on out are going to be driven, at least in part, by agents. So we designed for that on day one, not as a bolt-on you duct-tape onto the side later.

    Seems like a shaky bet. I think I’d rather not have “agents” tightly coupled with my hardware controllers.

    second thing, this

    Safety enforced at the capability node, not trusted to the agent

    Misses the point of why thinking about software as agents is dangerous, particularly in the context of robotics. Two or more agents may simultaneously decide to take actions that, on their own, aren’t dangerous, but when performed at the same time can produce a dangerous situation that neither “agent” could foresee. the more agents, the more complicated bodies you have to account for in the system, and it quickly becomes unpredictable.