tcl &mdash; csantosb https://infosec.press/csantosb/tag:tcl Random thoughts Wed, 13 May 2026 23:07:33 +0000 guix https://infosec.press/csantosb/use-guix <![CDATA[img br/ As one understands with time and a bit of experience, keeping track of the whole bunch of #dependencies necessary to handle daily when doing digital hardware design may reveal as an error-prone task. And yet, this is not to speak about regressions, incompatibilities and most important, #reproducibility of results. Luckyly enough, this is precisely the problem that #guix intends to solve, in an elegant, minimalistic and open way, using only #freesoftware. !--more-- br/ Nix Functional package management is a paradigm pioneer by nix and developed by Eelco Dolstra in his influential PhD Thesis. It is based on building each of the nodes in the graph of dependencies based solely in its inputs, contents, and node definition, producing a new node. The process repeats for every single node in the graph. In what concerns operating systems and software management, this comes to a radical different approach to classical package management. Simply put, every new build lives its life, regardless of the remaining builds. This makes it possible to have access to the kind of advanced utilities which ease our lives: declarative configurations, profiles, rollbacks, generations, etc. Forget the dependency hell. br/ Guix is founded on a similar approach, keeping its own set of rules as it only packages #freesoftware. There are around 30.000 of them as for today, including all the usual suspects. Within the context of #modernhw, guix is to be understood as a dependency management tool with advanced capabilities. Sure, it handles software, but there is no reason to use it exclusively as a software manager. It may handle IP blocks, documentation, bibliographic references, and more generally, all what concerns #plaintext files in a #gitforge. It understands versions, licences, dependencies, repositories and all kinds of relationships between them. Furthermore, it embeds a pragmatic language, guile, to script package definitions, declaring the behavior of nodes in our graph of dependencies. br/ Reproducibility The most relevant feature of guix turns out to be its bootstraping capabilities. Full source bootstrap comes to building the whole dependency graph right from the bottom, based on a core minimum of trusted binary seeds. From that point upwards the whole distribution is self-contained, as all that it builds is included in guix itself. Any available package is founded on a package definition included in guix, its source code available online in a #git repository, and its dependencies. Each of the latest, follows the same rules, down to the bottom of the graph where a trust seed is necessary. br/ Why is this necessary and useful for #modernhw ? Because it provides #reproducibility for free, as reproducible builds are granted here. Turns out that this is at the very heart of guix and produces #determinism, meaning that same operations will produce same outputs, no matter when, no matter what, no matter where. Game over to ambiguity. Determinism, coupled to its declarative nature, reveals as a simple means to track our dependencies history without ambiguity. br/ Let’s take an example, and say we have a Vivado project in the form of a set of #tcl files. To build the logic of our favourite #fpga, we require also a couple of external firmware dependencies as IP block in their own git repositories, with tagged revisions, being mutually dependent and incompatible, following the tag in use. Not all of them are compliant with our project. Each of the firmware modules incorporates its own set of VHDL versioned dependencies, along with its associated documentation. We need to provide a python testing framework (you guess it), along with its verification libraries. We need to create a static web site with the instructions on how to download, instantiate, compile and deploy each different version of our project for a couple of thousand users out there, each with a different #gnulinux system, version and configuration of installed software and libraries. Take it for granted, each user need a different version of our project, as they need to guarantee compatibility with their own internal developments. And we need to provide the correct version of every tool, compatible with our code and scripts. The right version, I do mean. Not any random version. br/ Can you imagine the pain ? Now, suppose that you could describe in a couple of #plaintext manifest files the status of your project. End of the history. Users willing to reproduce your project and dependencies only need to git clone the manifest files and install them locally, regardless of their system, of their present libraries or of their abilities. No problem if the host OS doesn’t provide the necessary software, guix handles the situation. Users just do make and the whole project is deployed, tested and simulated, using the right version of each node in the graph. This is Guix at its best. br/ Not yet convinced ? Take a look at here. br/ Feeling like tempted ? Start by a crash course to guix. br/]]> img
As one understands with time and a bit of experience, keeping track of the whole bunch of #dependencies necessary to handle daily when doing digital hardware design may reveal as an error-prone task. And yet, this is not to speak about regressions, incompatibilities and most important, #reproducibility of results. Luckyly enough, this is precisely the problem that #guix intends to solve, in an elegant, minimalistic and open way, using only #freesoftware.

Nix

Functional package management is a paradigm pioneer by nix and developed by Eelco Dolstra in his influential PhD Thesis. It is based on building each of the nodes in the graph of dependencies based solely in its inputs, contents, and node definition, producing a new node. The process repeats for every single node in the graph. In what concerns operating systems and software management, this comes to a radical different approach to classical package management. Simply put, every new build lives its life, regardless of the remaining builds. This makes it possible to have access to the kind of advanced utilities which ease our lives: declarative configurations, profiles, rollbacks, generations, etc. Forget the dependency hell.
Guix is founded on a similar approach, keeping its own set of rules as it only packages #freesoftware. There are around 30.000 of them as for today, including all the usual suspects. Within the context of #modernhw, guix is to be understood as a dependency management tool with advanced capabilities. Sure, it handles software, but there is no reason to use it exclusively as a software manager. It may handle IP blocks, documentation, bibliographic references, and more generally, all what concerns #plaintext files in a #gitforge. It understands versions, licences, dependencies, repositories and all kinds of relationships between them. Furthermore, it embeds a pragmatic language, guile, to script package definitions, declaring the behavior of nodes in our graph of dependencies.

Reproducibility

The most relevant feature of guix turns out to be its bootstraping capabilities. Full source bootstrap comes to building the whole dependency graph right from the bottom, based on a core minimum of trusted binary seeds. From that point upwards the whole distribution is self-contained, as all that it builds is included in guix itself. Any available package is founded on a package definition included in guix, its source code available online in a #git repository, and its dependencies. Each of the latest, follows the same rules, down to the bottom of the graph where a trust seed is necessary.
Why is this necessary and useful for #modernhw ? Because it provides #reproducibility for free, as reproducible builds are granted here. Turns out that this is at the very heart of guix and produces #determinism, meaning that same operations will produce same outputs, no matter when, no matter what, no matter where. Game over to ambiguity. Determinism, coupled to its declarative nature, reveals as a simple means to track our dependencies history without ambiguity.
Let’s take an example, and say we have a Vivado project in the form of a set of #tcl files. To build the logic of our favourite #fpga, we require also a couple of external firmware dependencies as IP block in their own git repositories, with tagged revisions, being mutually dependent and incompatible, following the tag in use. Not all of them are compliant with our project. Each of the firmware modules incorporates its own set of VHDL versioned dependencies, along with its associated documentation. We need to provide a python testing framework (you guess it), along with its verification libraries. We need to create a static web site with the instructions on how to download, instantiate, compile and deploy each different version of our project for a couple of thousand users out there, each with a different #gnulinux system, version and configuration of installed software and libraries. Take it for granted, each user need a different version of our project, as they need to guarantee compatibility with their own internal developments. And we need to provide the correct version of every tool, compatible with our code and scripts. The right version, I do mean. Not any random version.
Can you imagine the pain ? Now, suppose that you could describe in a couple of #plaintext manifest files the status of your project. End of the history. Users willing to reproduce your project and dependencies only need to git clone the manifest files and install them locally, regardless of their system, of their present libraries or of their abilities. No problem if the host OS doesn’t provide the necessary software, guix handles the situation. Users just do make and the whole project is deployed, tested and simulated, using the right version of each node in the graph. This is Guix at its best.
Not yet convinced ? Take a look at here.
Feeling like tempted ? Start by a crash course to guix.

]]> https://infosec.press/csantosb/use-guix Tue, 31 Jan 2023 23:00:00 +0000 on dependencies https://infosec.press/csantosb/on-dependencies <![CDATA[img br/ Digital hardware design implies dealing with a lot of scripts, configurations, packages, project files, documentation, specifications, bibliographies, data sheets, software, etc. and, of course, a lot of code. Each one comes with its own version history. This is not a problem, as we have #git. But when it comes to #dependencies between different sets, how do we handle the complexity ? !--more-- br/ Dependencies create a graph between each of its components (nodes). This way, documentation refers to a package, which complies with some scripts, related to project files for a given software. This forms a tree of dependencies, closely related, including duplicated dependencies, as one document may correspond to different pieces of code, forming a loop. And yet, this is not the whole picture. br/ Each node in the graph incorporates its own history of revisions: a given version of the documentation refers to a particular version of a firmware module, which links to a specific version of a data sheet, sending the user to a certain version of a bibliographic reference. This happens with the whole graph and is usually referred to as dependency hell. The complexity comes from the fact that, when one upgrades a node (to a more recent version), its new dependencies (new versions) are pulled along with it. But, in the most general case, those are also necessary for some other node in the graph, which prevents the upgrade from happening, unless more than one version of the node exists at some point in time. The mess arises. br/ Classical examples are software package managers, python being its most relevant example (specially due to the amount of dependency managers which coexist). Another good example is operating systems: when one decides to upgrade #librewolf web browser, all the necessary dynamic library dependencies of the new release must be pulled too; some of them maybe happens to be necessary for #emacs, which breaks. Package managers need to keep track of the whole history of graph of dependencies and deal with upgrades, software install and removal so as to keep a coherence between the whole system. Hell in heaven. OS must be seen as a set of nodes in a dependency graph moving forward in time, with obsoleted old releases impossible to reach anymore. br/ As engineers, this rings a bell. What happens when we upgrade proprietary software to support new hardware (Vivado, looking at you now) ?. A new software release implies new versions of IP cores, sometimes incompatible with previous versions, with different versions of documentation, sometimes incorporating its own set of regressions. #Tcl scripts may break, too, or require an upgrade of interpreters. The hell goes for long ... How do we check that our code performs correctly after an upgrade ? How to ensure that no side effects come with it ? Is it possible to be sure that data sheets are still relevant ? Is this paper compatible with the new upgrade ? Can we automatize all of that, or do we need to proceed by hand ? I guess you catch the idea. br/ modernhw makes it mandatory to use a tool to deal with dependencies. And a very good one, if you want my opinion, including all the necessary scripting capabilities and flexibility we need to cope with our scripts, configurations, packages, project files, documentation, specifications, bibliographies, data sheets, software, etc. and, of course, a lot of code. br/ Do we have such a tool ? Sure. Its name is #guix. br/]]> img
Digital hardware design implies dealing with a lot of scripts, configurations, packages, project files, documentation, specifications, bibliographies, data sheets, software, etc. and, of course, a lot of code. Each one comes with its own version history. This is not a problem, as we have #git. But when it comes to #dependencies between different sets, how do we handle the complexity ?
Dependencies create a graph between each of its components (nodes). This way, documentation refers to a package, which complies with some scripts, related to project files for a given software. This forms a tree of dependencies, closely related, including duplicated dependencies, as one document may correspond to different pieces of code, forming a loop. And yet, this is not the whole picture.
Each node in the graph incorporates its own history of revisions: a given version of the documentation refers to a particular version of a firmware module, which links to a specific version of a data sheet, sending the user to a certain version of a bibliographic reference. This happens with the whole graph and is usually referred to as dependency hell. The complexity comes from the fact that, when one upgrades a node (to a more recent version), its new dependencies (new versions) are pulled along with it. But, in the most general case, those are also necessary for some other node in the graph, which prevents the upgrade from happening, unless more than one version of the node exists at some point in time. The mess arises.
Classical examples are software package managers, python being its most relevant example (specially due to the amount of dependency managers which coexist). Another good example is operating systems: when one decides to upgrade #librewolf web browser, all the necessary dynamic library dependencies of the new release must be pulled too; some of them maybe happens to be necessary for #emacs, which breaks. Package managers need to keep track of the whole history of graph of dependencies and deal with upgrades, software install and removal so as to keep a coherence between the whole system. Hell in heaven. OS must be seen as a set of nodes in a dependency graph moving forward in time, with obsoleted old releases impossible to reach anymore.
As engineers, this rings a bell. What happens when we upgrade proprietary software to support new hardware (Vivado, looking at you now) ?. A new software release implies new versions of IP cores, sometimes incompatible with previous versions, with different versions of documentation, sometimes incorporating its own set of regressions. #Tcl scripts may break, too, or require an upgrade of interpreters. The hell goes for long ... How do we check that our code performs correctly after an upgrade ? How to ensure that no side effects come with it ? Is it possible to be sure that data sheets are still relevant ? Is this paper compatible with the new upgrade ? Can we automatize all of that, or do we need to proceed by hand ? I guess you catch the idea.
#modernhw makes it mandatory to use a tool to deal with dependencies. And a very good one, if you want my opinion, including all the necessary scripting capabilities and flexibility we need to cope with our scripts, configurations, packages, project files, documentation, specifications, bibliographies, data sheets, software, etc. and, of course, a lot of code.
Do we have such a tool ? Sure. Its name is #guix.

]]> https://infosec.press/csantosb/on-dependencies Tue, 31 Jan 2023 23:00:00 +0000