unicolet.org

News broke recently that Claude Code found a 23yo old vulnerability in the Linux Kernel NFS driver . If, for one second, we stop with the fear mongering we can realize that this opens up lots of interesting opportunities for a better (more effective) approach to security testing. Instead of relying on outdated models like pentesting, we could "just" feed the application source code to an LLM and have it find vulnerabilities. This is enabled by the fact that understanding a large code base (or any code base for that matter) is more difficult (and practically impossible) than applying known attacks to the external surface area. LLM suddenly make the former convenient enough and actually cheaper than a pentest. Cyber Security consultancies need to update their business model. 

 More proof that we're stuck in the past: https://www.reddit.com/r/embedded/comments/1s1agqo/why_is_bom_management_still_stuck_in_excel_in_2026/ every hardware team I’ve worked with ends up with the same setup… some giant excel or google sheet for the BOM everyone complains about it, but no one really replaces it you get random versions, people overwriting stuff, no idea who changed what, etc but at the same time whenever I look at “proper” tools they feel heavy or just not worth the switch so yeah genuinely curious, what are you all actually using day to day? My latest talk about Continuous Compliance is about moving on from xls (to lower cognitive load): https://www.incontrodevops.it/talk/continuous-compliance/

After a 7 year break, I returned to  IDI - Incontro DevOps Italia  and it was a blast. Here are my first impressions: AI dominated conversations. It is clear that team or organization-level guidance is important and software development and operational best practices like small PRs, and low MTTR are crucial. Sprints could/should be made shorter (1w or less). Question is: how to keep a healthy ceremony-to-work ratio with shorter sprints? Spec-driven development helps capture the details of the work being done, which is also useful for later rework/inspection but might also be important for compliance reasons 🤔 Finally someone using Backstage (to build self-service ops). List of sessions I attended: Leveraging the edge for observability GitOps, Observability e AI: come chiudere il ciclo dell’AIOps Don’t fear the bot: mastering AI tools before they master you (most fun and engaging) Scaling DevOps Without Scaling Ops: Our Platform Engineering Journey sshlogin: securely authentic...

I wish, one day, to have the dedication to pursue designs like the former Apple Sleep Indicator Light: the animation was designed to mimic human breathing at 12 breaths per minute  Just amazing. Via:  https://unsung.aresluna.org/just-a-little-detail-that-wouldnt-sell-anything/

I've been following Martin Stellar for some time and I find his material has made me a much better Product person. His writing is simple, clear and engaging, especially his free academy material . I thoroughly recommend you follow Martin Stellar on LinkedIn and read his materials.

I recently came across " Things I’ve learned in my 10 years as an engineering manager " by Jampa Uchoa and I loved it so much I wish I wrote it. Here are my favorite parts:  Everyone needs to care about the product : the most evident symptom of this is not happening is when we decide to hire QA or UX because we think they have the knowledge to fix the problem. Instead, the problem stays the same, and the flow of work breaks down. 60% of your job is being the cheerleader: the author mentions being the cheerleader for the team, and I would argue that we should also be the cheerleaders for the product. Your goal is for your team to thrive without you : I don't recall who said that leaders should be evaluated on their team's performance after they've left. It was probably former Navy captain David Marquet in "Turn the ship around! "

Via https://www.anildash.com/2025/09/09/how-tim-cook-sold-out-steve-jobs/ There's no point in having fuck-you money in the bank if you never say "fuck you"!