3 ms·

A few years ago, I learnt of one of the surprising constraints for Frama-C: it may only depend on code that could be patched by the maintainers of Frama-C. Tha

by Yoric 6y ago

A few years ago, I learnt of one of the surprising constraints for Frama-C: it may only depend on code that could be patched by the maintainers of Frama-C. That's because Frama-C is meant to be used on highly critical infrastructures (think nuclear plants) even in highly difficult times (think world war).

flohofwoe 6y ago
That's a good guideline for selecting external dependencies in general, also for "non-critical infrastructure" software. A slightly more relaxed version of that guideline would be: "never use dependencies that you don't feel comfortable creating or maintaining yourself".
rwmj 6y ago
Isn't that "all of open source" or do they mean something quite narrow by "could be patched by the maintainers of Frama-C"?
- snazz 6y ago
  It seems like they mean that the Frama-C maintainers only use (and vendor) dependencies that they are comfortable maintaining themselves.
- Yoric 6y ago
  The latter. And that includes the choice of a compiler.
jacquesm 6y ago
I have the exact same mentality when it comes to projects that I intend to operate for a longer time than just throwaway try-outs. If I can't understand what's going on under the hood then I'll be happy to pass. This is a limitation, of course. But at least it keeps me on a path where I don't bite off more than I can chew. Experience has led me to believe that any dependency you have is sooner or later going to turn into a either a liability or an obligation, this makes it much easier for me to see dependencies as costs rather than just as advantages. The number of dependencies for my current project is four, and each of those (vexflow, tone.js, lovefield, jquery) I'm in principle prepared to maintain myself. Even so, all of them have already proven to be here for the longer term. Ditto for tooling.

3 ms·

A few years ago, I learnt of one of the surprising constraints for Frama-C: it may only depend on code that could be patched by the maintainers of Frama-C. Tha

by Yoric 6y ago

flohofwoe 6y ago
That's a good guideline for selecting external dependencies in general, also for "non-critical infrastructure" software. A slightly more relaxed version of that guideline would be: "never use dependencies that you don't feel comfortable creating or maintaining yourself".
rwmj 6y ago
Isn't that "all of open source" or do they mean something quite narrow by "could be patched by the maintainers of Frama-C"?
- snazz 6y ago
  It seems like they mean that the Frama-C maintainers only use (and vendor) dependencies that they are comfortable maintaining themselves.
- Yoric 6y ago
  The latter. And that includes the choice of a compiler.
jacquesm 6y ago
I have the exact same mentality when it comes to projects that I intend to operate for a longer time than just throwaway try-outs. If I can't understand what's going on under the hood then I'll be happy to pass. This is a limitation, of course. But at least it keeps me on a path where I don't bite off more than I can chew. Experience has led me to believe that any dependency you have is sooner or later going to turn into a either a liability or an obligation, this makes it much easier for me to see dependencies as costs rather than just as advantages. The number of dependencies for my current project is four, and each of those (vexflow, tone.js, lovefield, jquery) I'm in principle prepared to maintain myself. Even so, all of them have already proven to be here for the longer term. Ditto for tooling.