Prof. Dr. Stefan Edlich

Did you know you can use mittwald's hosted AI models (currently in beta) for coding assistance in both VS Code and JetBrains IDEs? Just pushed a bit of documentation (read more at https://lnkd.in/gPKSUHVV) that explains how to configure both JetBrains AI Assistant as well as Continue (for VS Code, or JetBrains IDEs) and Cline (also VS Code) to use open-source models like Qwen3-Coder-30B-Instruct via the mittwald API. All models are hosted on german servers, and no user data is stored (let alone used for training purposes).

29

"Hardwood--A minimal dependency #Parquet parser" Spent some time over the holidays building a Parquet parser in #Java, avoiding any dependencies besides compression algorithms. Far from complete, but the basics are there, e.g. it can parse the NY taxi ride data set. The goal is two-fold: a) I actually want such a library, i.e. Parquet support without pulling in Hadoop dependencies. b) I want to explore how far I can get building this mostly via AI. I think it's a perfect case for LLMs: a concise and well-defined problem, authoritative spec, lots of training material out there. Note the idea is *not* to vibe code this, but rather to use AI as a tool for building something which makes sense, is maintainable, extensible, and performant. It's still early, but any feedback will be welcome. I'm planning to keep iterating on this (e.g. right now there's no statistics or predicate push-down support yet) and publish a release to Maven Central eventually, if there's interest. Happy 2026! 👉 https://lnkd.in/evusse_H

147

17 Kommentare

🧩 Linux vs Zephyr: Different Paths Through Devicetree In a recent post, I talked about how Devicetree helps us at Frickly Systems GmbH manage different hardware revisions. But I didn’t mention where we actually use this information. For us, this mainly means Linux and the Zephyr RTOS. While the same Devicetree concept applies to both, the way each system uses it is quite different. Linux maintains a runtime representation of the system, so modules and drivers can dynamically load the information when needed. Zephyr, on the other hand, resolves everything at build time, using macros to generate code based on the Devicetree data. To keep it simple, let’s assume both start from a single Devicetree source file (.dts). 🐧 Linux In Linux, this source is compiled into a binary representation (.dtb). The bootloader loads this file and passes it to the kernel during boot. The kernel, and even userspace, can query this structure to obtain configuration details dynamically. The important part is that the kernel and Devicetree are compiled independently. That means a single kernel build can work with many different hardware setups just by using different .dtb files. ⚡ Zephyr Zephyr takes a compile-time approach. During the firmware build, the .dts file is converted into a C header file full of preprocessor definitions. Zephyr’s source code can then use macros to directly access Devicetree data. As a result, the information is compiled directly into the firmware, so each device type requires its own build, but that build is fully customized and optimized for its hardware. I find it fascinating how both Linux and Zephyr solve the same challenge of describing hardware, but with very different design philosophies. What’s your take? Do you prefer Zephyr’s compile-time efficiency, or Linux’s flexible runtime model? #FricklySystems #Devicetree #LinuxKernel #ZephyrRTOS #EmbeddedSystems #OpenSource #FirmwareDevelopment #EmbeddedLinux #EngineeringInsights

157

9 Kommentare

Two major events today: 1️⃣ Launch of the yearly SPS in Germany 🏭 2️⃣ Release of Claude Code Opus 4.5 ✨ This morning I am keeping half an eye on my LinkedIn feed showing posts from SPS, while I test the capabilities of Opus 4.5. Such a crazy time to live in, where every x months coding models become y % better. And there are no signs that things are slowing down. But industrial automation is stuck. We can't use the modern coding workflows with the 'legacy' automation IDE's. Yes during SPS multiple vendors are presenting some kind of solutions. But here are the problems: ❌ Coding agents have no direct access to the code, everything runs through API's/MCP/... ❌ No git for tracking the agents. (Or worse: broken git) No granular commits and reviews for what the agents are doing. No diffs. No SDLC. ❌ No or limited BYOM (Bring your own Model). ❌ Separate licensing for the coding agents WITHOUT the model. ❌ ... ? The root causes are: 1️⃣ Legacy IDE's that shield the code from direct access 2️⃣ No CLI commands for things like code compiling (coding agents need feedback loops) 2️⃣ Fragmented IEC-61131 dialects (yes most automation engineers stayed in a single vendor ecosystem, but agents are general, and will be massively confused by this) But at least there's good news: next-gen IDE's are coming! This is what has already been announced/released: - Simatic AX - Beckhoff PLC++ - Codesys Go! - B&R Automation Studio Code ... and more coming that are not announced yet. My recommendation? Stop putting effort in legacy IDE's. We'll need to transform our coding workflows. It will take effort. Using coding agents with legacy IDE's will be almost impossible to control. Spend the effort by taking the opportunity to switch to a next-gen IDE. Talk to your vendor. Don't take 'not ready' for an answer. (Send me a DM if you don't know which person(s) to talk to) And if you're one of the automation vendors? Well we have been asking to fix the IDE's and toolchains since many years. At least some of you realized the need and took action a while ago. But there is no way to hold this back. We are losing competitiveness, speed and talent. Things still feel like they are moving relatively slowly. Yet soon it will be suddenly. How about the DCS system? Well ... you all know that I live and breathe process automation. There also is a viable path forward there. But no vendor seems to see the path through the trees yet ... 🤷‍♂️. I am not at SPS, so add a comment if I missed something ... 🫵 👇

28

2 Kommentare

🚀 Just published my first technical article with ML Con Magazine by entwickler.de – and it’s all about AI-powered coding environments! 🧠 In “Vergleich KI-unterstützter Coding-IDEs”, I compare three of the most promising tools in the market: Cursor Windsurf (formerly Codeium) VS Code with GitHub Copilot These tools don’t just autocomplete code — they offer intelligent agents, contextual chat, and deep integration into your coding workflows. But how do they really perform in daily dev life? 📊 My article takes a deep dive into: AI capabilities & integration depth Practical UX & developer productivity Architecture and everyday usability Whether you’re already using Copilot or exploring agentic IDEs like Cursor, this comparison might help you choose the right setup for your needs. 📝 The article is currently available in German only, but an English version is on the way! 🔗 Read it here: https://lnkd.in/eG5NwWDG #AIDevelopment #CursorIDE #GitHubCopilot #Windsurf #AIWorkflow #AgenticCoding #DeveloperTools #MLCon #AIIDE #ProductivityTools

14

Check out this interesting report from the latest Schloss Dagstuhl – Leibniz-Zentrum für Informatik (LZI) Perspectives Workshop on technical debt which brought together researchers, software tool vendors, and software engineering practitioners. This report summarizes the results of the workshop and status of the discipline of technical debt management. There is a widespread consensus in academia and the industry that managing technical debt should be treated as a core software engineering practice. However, there are also gaps that should be addressed by future research effort.   One of these gaps is related to managing technical debt related to architecture and design. The industry is challenged by the complexity and difficulties around managing technical debt on architecture and design level. This involves, for example, measuring the complexity in different dimensions, detecting and quantifying design flaws and hot spots. However, studies have proven that it is the leading source of technical debt in large-scale projects resulting in increased complexity and cost. Thus, there is a need to elevate the role of architecture in the context of managing technical debt and extend the focus beyond code-level issues. This is even more important considering the rise of AI-based coding tools and assistants which involves the risk that technical debt is accumulated more quickly.   https://lnkd.in/eupxHfQD   #ArchitecturalChangeManagement #TechnicalDebt #SoftwareQuality #SoftwareEngineering #SoftwareArchitecture #AICodingTools #AI

16

𝗙𝗣𝗚𝗔 𝗕𝘂𝗶𝗹𝗱𝘀 𝗶𝗻 𝘁𝗵𝗲 𝗖𝗹𝗼𝘂𝗱 𝗔𝗿𝗲 𝗣𝗼𝘀𝘀𝗶𝗯𝗹𝗲 — 𝗦𝗲𝗿𝗶𝗼𝘂𝘀𝗹𝘆 No, cloud builds aren’t always the most efficient choice. But 𝘀𝗮𝘆𝗶𝗻𝗴 𝙩𝙝𝙚𝙮’𝙧𝙚 𝙞𝙢𝙥𝙤𝙨𝙨𝙞𝙗𝙡𝙚 𝗶𝘀 𝘀𝗶𝗺𝗽𝗹𝘆 𝗼𝘂𝘁𝗱𝗮𝘁𝗲𝗱 Until recently, I believed that too — mainly due to concerns about toolchain size and NIC-based licensing. And yes, those are real issues on some platforms (e.g. GitHub-hosted runners). But they don’t apply everywhere. I set up an FPGA build environment for the 𝗢𝗽𝗲𝗻 𝗟𝗼𝗴𝗶𝗰 𝗙𝗣𝗚𝗔 𝗦𝘁𝗮𝗻𝗱𝗮𝗿𝗱 𝗟𝗶𝗯𝗿𝗮𝗿𝘆 on 𝗔𝗪𝗦 — with 𝗳𝗶𝘅𝗲𝗱 𝗡𝗜𝗖𝘀, 𝗽𝗲𝗿𝘀𝗶𝘀𝘁𝗲𝗻𝘁 𝘃𝗼𝗹𝘂𝗺𝗲𝘀 (~$16/month for 200GB), an it works well. This weekend I got rid of the fixed cost for persistent volumes by recreating them from 𝘀𝗻𝗮𝗽𝘀𝗵𝗼𝘁𝘀on an as-needed basis - making it the most cost effective solution in the case of Open Logic. You can find Open Logic here: https://lnkd.in/eM7dshwU 𝗚𝗲𝗻𝗲𝗿𝗮𝘁𝗶𝘃𝗲 𝗔𝗜 𝗵𝗮𝘀 𝗰𝗵𝗮𝗻𝗴𝗲𝗱 𝘁𝗵𝗲 𝗴𝗮𝗺𝗲. Setting up cloud infrastructure is no longer just for experts. GenAI assistance makes it accessible to FPGA developers (like me) and no a cloud pro. 𝗪𝗵𝗲𝗿𝗲 𝗰𝗹𝗼𝘂𝗱 𝗯𝘂𝗶𝗹𝗱𝘀 𝘀𝗵𝗶𝗻𝗲: occasional builds, bursty workloads. 𝗪𝗵𝗲𝗿𝗲 𝗹𝗼𝗰𝗮𝗹 𝗯𝘂𝗶𝗹𝗱𝘀 𝘀𝘁𝗶𝗹𝗹 𝘄𝗶𝗻: consistent performance, sensitive IP. Bottom line: Stop saying cloud builds are impossible. 𝗘𝘃𝗮𝗹𝘂𝗮𝘁𝗲 𝘄𝗵𝗮𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗳𝗶𝘁𝘀 𝘆𝗼𝘂𝗿 𝗻𝗲𝗲𝗱𝘀. #OpenLogic #VHDL #OpenSource #HardwareDesign #FPGA #DigitalDesign #Community #VUnit #GHDL #HDL #CircuitDesign #VLSI #AMD #Xilinx #Vivado #Altera #Quartus #Efinix #Efinity #FuseSoC #Questa #Microchip #Gowin #AWS

79

9 Kommentare

Accidental quality. That's what I call the hidden trap in traditional example-based tests. In my recent talk at Techcamp Hamburg, I spoke about how enumerating test cases creates a dangerous illusion of safety, while the real bugs hide in the blindspots we never think to check. Property-based testing flips the narrative: it searches for bugs instead of just testing for them. If you have 1000 users and you are writing 50 handpicked test cases, are you sure you are not missing any particular use-case? https://lnkd.in/eTyjrPPi

19

https://lnkd.in/eN2DZ-Mw Very interesting and inspiring read. We all had the experience with LLM that the same question asked twice get different answers from the same model. This probably makes it hard for people to trust AI doctors on their diagnoses or AI Banker who approves or rejects loans. This blog post shares their finding of the root cause and even proves this can be fixed. The study shows the non-determinism has to do with floating-point non-associativity. That is, with floating-point number calculation on computer: (a+b)+c ≠ a+(b+c) Python (0.1 + 1e20) - 1e20 >>> 0 0.1 + (1e20 - 1e20) >>> 0.1 The randomness of the order of calculation inside kernel comes from the variance in batch size! In other words, when we ask the same question twice, the answer somehow depends on the requests received from other users at the same time! So it's possible to sacrifice the efficiency to eliminate this kernel batch variant.The blog post has implemented a solution that consistently produces near identical output 1000 times with less-than-double the time. IMHO, anyone who still doesn't believe in the power of AI will be the first batch of people replaced by AI.

7

New Rust blog post on why we need (at least) ergonomic, explicit handle creation: https://lnkd.in/eDVBEhzu > **This blog argues that we should make it ergonomic to be explicit**. This wasn't always my position, but after an impactful conversation with Josh Triplett, I've come around. I think it aligns with what I once called the soul of Rust: we want to be ergonomic, yes, but we want to be **ergonomic while giving control**. I also like Tyler Mandry's *Clarity of purpose* contruction, *"Great code brings only the important characteristics of your application to your attention"*. The key point is that *there is great code in which cloning and handles are important characteristics*, so we need to make that code possible to express nicely. This is particularly true since Rust is one of the very few languages that really targets that kind of low-level, foundational code.

41