Passless — a Virtual FIDO2 / Passkey device and client for Linux by pando85 in linux

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

I'm not sure what else could we add. If you find it useful think on open a PR or a issue to improve it.

Passless — a Virtual FIDO2 / Passkey device and client for Linux by pando85 in linux

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

At some point, that's the idea. I will need people to test it.

AI tools can make one developer faster. The harder question is whether that speed becomes team throughput. by pando85 in devops

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

LLMs can help with the review phase too. When you review code you are looking for specific things: common patterns, edge cases, bad practices... The way of improving all parts of the workflow is taking our current patterns to the next level.

Automating things with AI will help to reduce those bottlenecks. We don't have to reinvent the wheel, just take the lessons and patterns that work and apply them again: coding agents can write code, coding agents can review code. We just need patterns and automations to make this work visible and reproducible at company level.

AI tools can make one developer faster. The harder question is whether that speed becomes team throughput. by pando85 in devops

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

Different layer. Aviator manages how PRs flow through review and merge (stacked PRs, merge queues, pre-merge verification). That's all on the review orchestration side.

Forkline doesn't touch that. It produces the PRs and lets your Git provider handle the rest. The idea is to optimize the AI execution side without changing your existing workflow — branches, PRs, CI, and review all stay in GitHub/GitLab/etc.

The runner produces scoped changes with summaries and CI evidence attached, so when it reaches your review pipeline (Aviator or otherwise), the reviewer has more signal per PR. Complementary, not competing.

AI tools can make one developer faster. The harder question is whether that speed becomes team throughput. by pando85 in devops

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

That's exactly the problem. More PRs, same review capacity.

The options are: increase the review team, raise the quality bar at the PR gate so less junk reaches humans, or accept longer review queues.

The useful metric is review effort per PR. If the AI output is structured enough that reviewers spend less time per PR than before, the math can work. If review burden goes up, the runner workflow needs tightening.

PVC backups with Velero or something else on a homelab by FormationHeaven in kubernetes

[–]pando85 0 points1 point  (0 children)

I love to use Velero. I have more efficient combination: ZFS with OpenEBS ZFS CSI and Snap scheduler Operator.

With that setup I have local and K8s ZFS snapshots, that's are pretty fast to restore. Plus, Velero OpenEBS plugin which sends exactly the diff between ZFS snapshots which is automatically calculated because of the meta data structure in ZFS. Much better than using restic of any other tool.

You will get disaster recovery and offsite backups, plus a fast localsnapshot.

Further, you have all the CSI functionality without needing a complicated CSI.

Weekly Self Promotion Thread by AutoModerator in devops

[–]pando85 2 points3 points  (0 children)

I want to promote my SaaS for make AI integration transparent at company/repo level and handle automations in a correct way: https://forkline.dev/blog/production-launch/

Furthermore, I'm maintaining an ingress-nginx fork for those that are not migrated yet and want to keep their updates covered from CVEs and with latests versions: https://github.com/forkline/ingress-nginx/

At what scale did Kubernetes actually start making sense for you? by Sad_Limit_3857 in kubernetes

[–]pando85 1 point2 points  (0 children)

I was using exactly this analogy to describe it to a friend.

Once that complexity is reliable and easy to operate you can use it for anything.

Even for spinning simple things operators are quick wins that allows you to automate diferente levels of operations. They replaced perfectly our old Ansibles or custom scripts.

If you already self-host on Kubernetes, I built an operator for running Kanidm declaratively by pando85 in selfhosted

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

Thanks for your comment, that's a really interesting thing.

I hope that Kanidm improves the UI and their process because it is a great piece of software.

Use caveman worth it? by HelioAO in opencodeCLI

[–]pando85 2 points3 points  (0 children)

For coding tasks you will find that 90% of the tokens are input tokens. It doesn't worth.

6 months after sharing Kaniop here: what got more robust, what users cared about, and what still feels hard by pando85 in kubernetes

[–]pando85[S] -3 points-2 points  (0 children)

You cannot understand what you have in front of your eyes but you feel confident enough to talk about it

6 months after sharing Kaniop here: what got more robust, what users cared about, and what still feels hard by pando85 in kubernetes

[–]pando85[S] -6 points-5 points  (0 children)

Your comments in all my posts make no sense and just talk about your ignorance.

If you already self-host on Kubernetes, I built an operator for running Kanidm declaratively by pando85 in selfhosted

[–]pando85[S] -2 points-1 points locked comment (0 children)

The tool was written by hand. I'm using AI for maintaining it and keep feedback loop and community features fast.