tfrancisl

Seconding this. I'm not happy with the fact that the drivers are proprietary, I really prefer FOSS. But, I am tired of having to deal with FUD around performance and issues with NVIDIA devices which simply don't exist at scale.

I have friends who are stuck on Windows not because they play games with Windows-only anticheat, but because theyve been told by GNU heads that NVIDIA drivers simply don't perform acceptably on Linux.

Whether they did that or had an LLM one shot it, I dont really care. Commit history is pretty important if you ever want to try fixing bugs or improving features in the future.

250k lines of code in one commit is reason enough to disregard the project entirely, IMO. Vibe code if one wants, but that is just madness...

There is a project by a group of nix/nixos enthusiasts aiming to replace some of these core deps https://github.com/manic-systems/nixos-core. I havent tire-kicked it much, but it seems useful.

I can't blame you when the first few sentences almost always evoke one of the "creators of XYZ" (I don't know how you can say a model or model harness has a singular creator when the model was trained on everyone's data and the harness was built by a whole team?) and treats their word or experience as gospel.

Who cares what Cherny thinks? He is selling his product, and he will probably cash out soon enough while his credibility is as high as it is.

You don't sponsor people or projects to complete specific issues or build specific features in the first place. Sponsorship is a reward and token of appreciation for doing good work.

Better yet: give them cold hard cash instead of what is arguably monopoly money for many OSS devs. Ironically this is something GitHub made "easy" with sponsorships several years ago.

... which many would argue is between a patient and their doctor. We dont pay premiums for no reason, and the insurance company isnt really allowed to determine what "necessary" means.

It works on darwin and any linux just fine. Theyre even working on a "standalone" like HMs, if you really want to decouple your user programs from your system.

With some programs it is as simple as you show, but with others there are options around the config and other nix module nasties that I avoid if I can. hjem-rum is a sister project to hjem that provides some similar modules.

I'm saying that I value the completeness (thoroughness may be a better word) as well as the reproducability and portability that nix ensures over convenience. I cant tell you the amount of times I've pulled a precompiled tool and it just doesnt work because of one quirk of their packaging or another.

Also noting that I don't see the problem as "dotfile management" but as "system AND user configuration management" which extends beyond some plain text files in $HOME.

ed.: and home manager is just one tool which provides not only dotfile management, but drvs for installing particular programs and configuring then in highly opinionated ways -- I do not use it

Its the only complete, reproducible, and portable solution, in my opinion.

I like mise, but at the end of the day some programs are more complex than just pulling a precompiled, dynamically linked binary and hoping it works.

If you like home manager but also like to understand how your "home"/user programs are configured, take a look at hjem!

What a snakepit of a comment! I know there are tensions within nix but this feels like a classic case of Chestertons fence at a big scale.

Or nix without home manager, and ideally without flakes as well. Two solutions looking for problems, IME.

I use it with Spotify to track my listens and sort by artist, album and the like. It definitely still has value, even for Spotify users!

No, which is why I started my message with "No, ..."!

It seems the original author of the popular SDD toolkit for agent frameworks has gone no-contact. One of the maintainers has forked it. This is concerning as the original author maintains control of the associated NPM package.

I agree with the messaging generally, but unfortunately to fight implicitly unprofessional behavior with a terse response like this would look explicitly unprofessional!

No, this was in response to some questions about different approaches enterprises take to automated code quality review and complying with some arbitrary security standard out there. And this was a principal secops guy who thought the appropriate thing to do was to ask Copilot.

Being known as an RTFM type of person, I usually appreciate when a super nonspecific question is met with a link to the docs.

I worked as a developer at a company. I asked the business owner a question about a business task. He sent me a ChatGPT screenshot with the answer.

Something similar to this happened in a "public" chat space at my company, and, despite the fact that we are leaning into LLMs and agentic workflows quite a bit, the responses were generally "I aint reading all that" and "hey, dude, thats kinda unprofessional."

We should be shaming people who attempt to outsource all of their thinking to chatbots or agents. I think it would be effective.

Branches and worktrees exist and can effectively act as a "separate" history. At the end of the day you would still merge the changes in, possibly with a squash if you don't care about the little commits.

Just use git. If your agent (especially claude) doesnt seem to know how, there are skills and hooks and other options to make it work. My 2c.

Git is a particularly egregious one, imo. It has a simple cli and solves all of the problems presented here! Worktrees for "exploratory" work that you might throwaway, and otherwise atomic commits just make tracking changes and reasoning for changes easy.

Not to belabor my point, but I think "adding support to tools for common hallucinations" is a bad idea. Sounds like something a vibecoded project being spammed with issues by agents might do. Not so much a serious, mature project, though.

Let the Agent use the CLI and if it guesses the wrong option, you make that the RIGHT option

This sounds backwards and presumes that the statistics machines which are LLMs are getting it right when they "average" out to the wrong command. No, fix the agents behavior, dont change the CLI to accommodate it.

I dont want "agent-native CLIs" to proliferate because I'd rather we design CLIs for human use and programmatic (automation) use first. Agents are good at vomiting json between tool calls, I am not, and never will be.

Too many tools stray so wildly from UNIX principles. If we design for agents first we will likely see more and more of this.

2 questions. First, how does a vibe coded / generated fork or derivation pose security risks to the original work? Second, what is a "more appropriate channel" to express his opinions than the platform he has as a maintainer of a massively popular project?

I would argue that we don't see enough open source developers presenting their political or social views in the context of their works.

I think this is a false dichotomy. You can feel and be more protected against crime while also being exploited for your data by a shadowy camera company. We should let the state step in to regulate Flock et al, assuming we can do something about the corruption they're already involved in.

This is true. I often forget because my state has an equivalent law.

I would guess the only way to make this data available long term is by regulation. Then again, I would hope Flock is subject to FOIA already if they are collaborating with state or local law enforcement...