If you currently run `apt install debcraft` in Ubuntu, you will get the tool built by me. It has largely the same goals as Canonical has expressed in this and similar docs, but no Launchpad integration. If you want to collaborate on making .deb maintenance easier, faster and more secure across all of the Debian and Ubuntu ecosystems, please reach out. You can use the "book a chat" link on my site https://optimizedbyotto.com/.
This is the first long-term supported MariaDB release with vector support for RAG applications, zero-configuration TLS, new Parsec authentication plugin and more
Both sbuild and Debcraft essentially still run a minimal hermetic Debian environment without network access inside them. The fact that sbuild exists is not a reason to not try out Debcraft. However the selling point in Debcraft is not that it has the build environments, but much more.
I know cases where an Atlassian customer was forced to self-host their Jira as their data/instance size was too large for Atlassian to be able to offer as a hosted service. Using TiDB is a clear path for Atlassian to reliably scale up the size of the databases they host for their customer instances.
The XZ Utils backdoor, discovered last week, and the Heartbleed security vulnerability ten years ago, share the same ultimate root cause. Both of them, and in fact all critical infrastructure open source projects, should be fixed with the same solution: ensure baseline funding for proper open source maintenance.
Hey fellow hackers, I just published a new blog post with some practical writing advice to help software professionals level up their communication skills.
As engineers and developers, we often focus heavily on technical skills while neglecting the importance of clear, compelling writing. But the reality is, our ability to communicate effectively can have a major impact on our careers.
You need bisect only as a last resort. Effective use of git blame, git log -p -S <keyword> etc has always been enough for me. Also, the projects I work with take 10+ minutes to compile even when cached, so doing tens of builds to bisect is much slower than just hunting for strings in git commits and code.
I've had git bisect work perfectly to show me that a commit that I would swear up and down couldn't cause the problem was what was causing the problem. In those kinds of situation git blame and git log are a bit useless since you can be looking right at the commit in question -- even looking at the diff in question -- and fail to actually 'see' it and go chasing down other rabbit holes that seem 'obviously' much more likely to be the cause. And this was typically after some customer updated for the first time in several years and so there was several years of changes to sift through to find the regression.
reply