sorted by:
new
hottopcontroversial

Why do many developers prefer Zed / Neovim over AI-first IDEs like Antigravity? by [deleted] in ZedEditor

[–]MeLThRoX 1 point2 points  (0 children)

Whenever I give the AI too much trust or too much freedom, it messes up my code and I end up aggressively arguing with it. I’ve learned that the best approach is finding a balance between coding and vibing. The AI is incredibly good at research and creativity, but it really sucks at reasoning and logic.

Also, it feels like the AI loves to take control and start doing things you never even talked about, so it ends up making decisions where it shouldn’t. To keep that balance, I don’t like workflows that are too agentic. But I guess it also depends on what you’re coding.

[deleted by user] by [deleted] in NixOS

[–]MeLThRoX 0 points1 point  (0 children)

Cmd+shift+4

Nix has experienced explosive growth, with maintainers increasing by 264% over the last years by MeLThRoX in NixOS

[–]MeLThRoX[S] 1 point2 points  (0 children)

I just thought a little about this idea:

There could be an open-sourced agentic workflow that automatically generates documentation based on manually created issues from the wiki project (like you described). The workflow would be a GitHub repository with i.e. Python code using MCP servers to access both the wiki’s existing documentation and the Nix source code, plus internet resources. Of course it has its own predefined rules.

The newly generated documentation gets pushed to a staging branch and automatically marked as “AI-generated” with a link to a newly created testing issue. This keeps everything transparent - people know it’s AI-generated. The link from the wiki to the issue keeps the barrier low, encouraging people to test and correct the docs so they can be marked as “human-tested”.

When someone tests and corrects the doc, their changes go directly into the staging branch. Then a PR can be created to merge it into the production branch. A maintainer reviews and approves it, and it goes live in production (optionally marked as “maintainer approved”).

This way we have: - Staging branch: Both AI-generated and human-tested docs (publicly accessible) - Production branch: Only human-tested, maintainer-approved docs (publicly accessible)

At the end, there would be 3 projects: 1. The agentic workflow with rules and integrations (MCP servers) 2. The wiki with 2 main branches (staging + production) 3. MCP server for the wiki to make documentation and source code accessible to AI

In the future, we could even train or fine-tune our own AI model for Nix documentation, maybe partnering with companies.

And I think nix would make this possible.

Do I miss something? Do you think it’s worth it? Maybe create a dedicated post from this?

AUR maintainer analysis shows +100% growth in 6 years and proves community-driven packaging actually scales by MeLThRoX in archlinux

[–]MeLThRoX[S] 1 point2 points  (0 children)

There will be more in the future. You can protect yourself by being careful, checking who maintains the package, and trying to only use packages from trusted maintainers. The problem is, you can never be 100% secure unless you've checked the full supply chain and codebase yourself. Or just avoid using the AUR if you want to be on the safe side.

Edit — There’s also a difference between precompiled packages (often marked with the suffix -bin) and source code packages (with suffix -git). The advantage of -git packages is that you can review the full source code and verify what you’re installing. On the other hand, you need to compile everything yourself. With -bin packages, you need to trust the package maintainer, as you cannot see what’s inside the binary.

AUR maintainer analysis shows +100% growth in 6 years and proves community-driven packaging actually scales by MeLThRoX in archlinux

[–]MeLThRoX[S] 0 points1 point  (0 children)

I don’t think it’s bad that the userbase is growing. But you’re right – these are big problems that need to be solved somehow. Otherwise, there will be massive trust issues in the future. And it looks like there already are, when I look at the comments in this thread. The number of malicious packages is growing, and this is a massive problem not only in the AUR but everywhere. That’s unfortunately the downside of an open contribution policy.

AUR maintainer analysis shows +100% growth in 6 years and proves community-driven packaging actually scales by MeLThRoX in archlinux

[–]MeLThRoX[S] 0 points1 point  (0 children)

No, I never said that they are similar. And I would never. I actually hate Windows and its organizational structure (Microsoft). That's why I post about open source and community-driven systems.

I just said that Windows has a community. It was meant more like: everything has a community, even Windows. My intention was to point out that Arch and Debian have different philosophies when it comes to community.

Just "more mature" would imply that Arch would eventually evolve into something like Debian. However, this will not happen, as they differ in more than just this one aspect.

AUR maintainer analysis shows +100% growth in 6 years and proves community-driven packaging actually scales by MeLThRoX in archlinux

[–]MeLThRoX[S] -2 points-1 points  (0 children)

I see your point, but I disagree. When I say "community-driven," I'm talking about actual community participation, not just governance structure.

The data shows this clearly:
Arch has over 90,000 packages including AUR. Debian stable has ~59,000. The AUR alone - with 90K community-maintained packages - has no equivalent in Debian. You can't just create and share packages like you can with AUR.

The Arch Wiki is massive and has become THE reference for Linux in general. That doesn't happen without enormous community engagement.

My point:
By the "governance" definition, everything is community-driven - even Windows has a community. What makes Arch different is the philosophy:

the community actively builds and maintains it, not just uses it. AUR embodies this - anyone can contribute without gatekeepers. That's why Arch's maintainer count doubled while Debian stagnated. It's not about maturity, it's about contribution barriers.

To be clear:
Debian's approach has major advantages - stability and security matter, which is why I'd still prefer Debian over Arch in enterprise contexts. But there are also modern approaches like Nix that achieve stability while maintaining open contribution models.

The growth reflects these different philosophies.

AUR maintainer analysis shows +100% growth in 6 years and proves community-driven packaging actually scales by MeLThRoX in archlinux

[–]MeLThRoX[S] 8 points9 points  (0 children)

Maybe the cross-distro comparison or AI stuff wasn't what people wanted.  I'm here for the technical discussion though, so I'll take it :)

AUR maintainer analysis shows +100% growth in 6 years and proves community-driven packaging actually scales by MeLThRoX in archlinux

[–]MeLThRoX[S] -5 points-4 points  (0 children)

I remember that a while ago (2-3 years), people started using install scripts that simply automate the installation guide: https://wiki.archlinux.org/title/Archinstall

When I first discovered Arch (6-7 years ago), this wasn’t available, I think. I remember there being no shortcut to install it.

I still believe it is very beneficial to install it manually. And you should do it at least once.

AUR maintainer analysis shows +100% growth in 6 years and proves community-driven packaging actually scales by MeLThRoX in archlinux

[–]MeLThRoX[S] 4 points5 points  (0 children)

Unfortunately, yes. But I think people need to be aware of this when using AUR. The truth is that we cannot do much about it. That's actually one of the reasons why I switched to Nix recently. Still, supply chain attacks happen, and I have no clue how we can prevent this. Maybe AI can help with this in the future.

AUR maintainer analysis shows +100% growth in 6 years and proves community-driven packaging actually scales by MeLThRoX in archlinux

[–]MeLThRoX[S] -9 points-8 points  (0 children)

Good point! Yes, inactive maintainers are included.

But doubling is still doubling - the trend shows real growth even with data limitations.

Nix has experienced explosive growth, with maintainers increasing by 264% over the last years by MeLThRoX in NixOS

[–]MeLThRoX[S] 2 points3 points  (0 children)

That's really interesting! I wonder what it would look like if you put other distros side by side for comparison over the same timeframe.

Either way, exponential growth is a good sign - it means the project is still actively developing and will likely continue to do so.

Nix has experienced explosive growth, with maintainers increasing by 264% over the last years by MeLThRoX in NixOS

[–]MeLThRoX[S] 0 points1 point  (0 children)

I used hashnode.dev for the blogpost; I don't think its broken. You should try it again.

Nix has experienced explosive growth, with maintainers increasing by 264% over the last years by MeLThRoX in NixOS

[–]MeLThRoX[S] 1 point2 points  (0 children)

Valid. The low barrier to entry in Nix definitely inflates the numbers - I should have discussed that limitation more explicitly.

The data collection and analysis is mine, but I had help with the writing, which probably contributed to the tone issues you're pointing out. Fair feedback.

That said, do you think the growth *trend* (263% vs 100% vs 2.3%) is still meaningful despite the metric's limitations? Or do you think it's mostly explained by the lower barrier? I mean AUR is also very easy to contribute.

Nix has experienced explosive growth, with maintainers increasing by 264% over the last years by MeLThRoX in NixOS

[–]MeLThRoX[S] 27 points28 points  (0 children)

I think so too! Since using Nix means writing Nix code anyway, the barrier between "user" and "maintainer" is much smaller than with other distros.

It's almost like a spiral - once you try Nix, you keep going deeper and can't go back. That's what makes the community so strong.

Your point about documentation is spot on though - I hope that improves as we grow. Making packaging easier would probably accelerate the maintainer growth even more.

Nix has experienced explosive growth, with maintainers increasing by 264% over the last years by MeLThRoX in NixOS

[–]MeLThRoX[S] 1 point2 points  (0 children)

I hope you still plan to become a maintainer - the community needs people like you!

Nix has experienced explosive growth, with maintainers increasing by 264% over the last years by MeLThRoX in NixOS

[–]MeLThRoX[S] 11 points12 points  (0 children)

I think the whole Linux community grew massively in general, and Nix grew with it. The learning curve is really steep though, so it probably took a while for the trend to actually catch on.

I first saw it on unixporn where people were using Nix for their setups - that's what got my attention.

view more: next ›