5 ms·

Excellent writeup! Some observations unrelated to the bug. 1. Nice to see some details about the Debian build server implementation. I have always found it ra

Excellent writeup! Some observations unrelated to the bug. 1. Nice to see some details about the Debian build server implementation. I have always found it rather obscure. Compared to that OpenSUSE's OBS is refreshingly open. Not only can you just use their cloud service for free, but you can also rather easily set up your own instance. 2. Nice to see that the Debian build infra gets updated. I am a bit suprised that Perl code gets introduced in 2024. Isn't that a bit out of fashion for a reason: It's typically very hard to read code written by others. (As said unrelated. It did not cause the bug in TFA.)

Kwpolska 2y ago
sbuild is written in Perl, so it’s not surprising that new code for it is written in Perl.
aragilar 2y ago
I believe installing https://packages.debian.org/sid/sbuild-debian-developer-setup https://packages.debian.org/sid/sbuild-debian-developer-setu... will get you most of the way (but I've only ever done manual builds of packages, so I may be wrong).
deleted 2y ago
[deleted]
chubot 2y ago
Are you surprised that programs can live for 10 or 20 years? Most people who want to rewrite things in a language that's more fashionable don't have the experience maintaining working systems over 20+ years, like Debian does
- eyegor 2y ago
  I'll just pitch in as someone who's worked with several 40+ year old codebases and 3+ year old perl, the perl code is significantly harder to maintain. The language lends itself to unreadable levels of terseness and abuse of regex. Unless you use perl every day, the amount of time trying to understand the syntax vs the code logic is skewed too heavily towards obscure syntax. Even the oldest fortran/c is much easier to work with. Except maybe arithmetic gotos designed to minimize the number of functions. Those are straight evil and I'm glad no modern language supports them.
  - temporallobe 2y ago
    I also maintain older codebases and this is how I feel about Clojure. It’s far too terse and the syntax is nigh unreadable unless you are using it very often - add to that there seems to be a culture that discourages comments. OTOH so-called “C” languages seem much more readable even if I have haven’t touched them in years or have never written a line of code in them. On another note, I have done a lot of things with Perl and know it well, and I agree that it can be written in a very unreadable way, which is of course enabled by its many esoteric features and uncommon flexibility in both syntax and methodology. It is simultaneously a high-level scripting language and a low-level system tool. Indeed, I have caught myself writing “clever” code only to come back years later to regret it. Instead of “TMTOWTDI”it is has turned into “TTMWTDI” (there’s too many ways to do it).
  - shermantanktop 2y ago
    > Even the oldest fortran/c is much easier to work with. Could that be survivor bias? If that old Fortran was hard to work with, maybe it would have been rewritten, and left the set of “oldest code” in the process.
    - Gibbon1 2y ago
      I think it's just procedural languages with a lack of magic.
  - chubot 2y ago
    Sure, Perl can be hard to maintain. (I haven't used it in over 25 years, and don't expect to ever use it again) From your experience maintaining 40+ year old codebases, is it possible that improving the Perl codebase is the best choice in a certain situation? Or should we always be "surprised" that Perl exists? (honest question) In other words, I don't see the connection between "this code is hard to maintain" and "I am surprised that it exists" / "it should be rewritten".
  - Joel_Mckay 2y ago
    In general, I tend to observe languages that are minimally challenging for amateurs tend to build less sustainable mutagenic ecosystems. Example: * Prolog generated the worlds most functional 1 liner code, as it is bewildering for hope-and-poke programmers * Pythons ease of use combined with out-of-band library packages became a minefield of compatibility, security, and structural problems (i.e. became the modern BASIC) * NodeJS was based on a poorly designed clown JavaScript toy language, so naturally became a circus * Modern C++ template libraries became unusable as complexity and feature creep spiraled out of control to meet everyone's pet use-case * Rust had a massive inrush of users that don't understand why llvm compilers are dangerous in some use-cases. But considering 99% of devs are in application space, they will unlikely ever need to understand why C has a different use-case. While "Goto" could just be considered a euphemism for tail-recursion in some languages. We have to remember the feature is there for a reason, but most amateurs are not careful enough to use it in the proper edge-case. I really hope Julia becomes more popular, as it is the first fun language I've seen in years that kind of balances ease of use with efficient parallelism. wrote a lot of RISC Assembly at one time... where stacks were finite, and thus one knew evil well... lol =3
- deleted 2y ago
  [deleted]
rleigh 2y ago
sbuild is at least 25 years old, it might be nearer to 30 at this point. I did a lot of cleanup of it during the mid-2000s, including adding the schroot support to it which is being removed here, and that included abstracting virtualisation backends which allowed newer solutions to replace it. The original had to run as root to do a chroot(2) call, and it reused the same environment between builds. schroot removed the need to run as root, and it could provide a clean snapshot for each build. But it too is now rather dated--though the replacement tools often lack some of the features it has, like being able to build from ZFS cloned snapshots or Btrfs snapshots, or even LVM snapshots. We wanted it to be fast as well as safe, and the time-to-build and time-to-clean-up using these was and is excellent. Replacing key infrastructure is hard, particularly when it's working well and the cost of replacement is high, especially so when it's volunteer effort. It was cutting edge back when Perl was all the rage, but while Perl might no longer be the fashionable choice, tools written in Perl continue to work just as they always have. I found it dense and impenetrable even 20 years back, and I used to have the whole thing printed out on fan-fold paper from a dot matrix; it was about 3/4" thick and covered in annotations! Understanding several thousand lines of obscure regexes is a cautionary tale in how to write unmaintainable Perl, and was one of the motivations to clean it up, refactor it into meaningful functions, and document what it was doing so that it could be maintained with a little less effort.

Kwpolska 2y ago

sbuild is written in Perl, so it’s not surprising that new code for it is written in Perl.

aragilar 2y ago

I believe installing https://packages.debian.org/sid/sbuild-debian-developer-setup https://packages.debian.org/sid/sbuild-debian-developer-setu... will get you most of the way (but I've only ever done manual builds of packages, so I may be wrong).

deleted 2y ago

[deleted]

chubot 2y ago

Are you surprised that programs can live for 10 or 20 years? Most people who want to rewrite things in a language that's more fashionable don't have the experience maintaining working systems over 20+ years, like Debian does

eyegor 2y ago
I'll just pitch in as someone who's worked with several 40+ year old codebases and 3+ year old perl, the perl code is significantly harder to maintain. The language lends itself to unreadable levels of terseness and abuse of regex. Unless you use perl every day, the amount of time trying to understand the syntax vs the code logic is skewed too heavily towards obscure syntax. Even the oldest fortran/c is much easier to work with. Except maybe arithmetic gotos designed to minimize the number of functions. Those are straight evil and I'm glad no modern language supports them.
- temporallobe 2y ago
  I also maintain older codebases and this is how I feel about Clojure. It’s far too terse and the syntax is nigh unreadable unless you are using it very often - add to that there seems to be a culture that discourages comments. OTOH so-called “C” languages seem much more readable even if I have haven’t touched them in years or have never written a line of code in them. On another note, I have done a lot of things with Perl and know it well, and I agree that it can be written in a very unreadable way, which is of course enabled by its many esoteric features and uncommon flexibility in both syntax and methodology. It is simultaneously a high-level scripting language and a low-level system tool. Indeed, I have caught myself writing “clever” code only to come back years later to regret it. Instead of “TMTOWTDI”it is has turned into “TTMWTDI” (there’s too many ways to do it).
- shermantanktop 2y ago
  > Even the oldest fortran/c is much easier to work with. Could that be survivor bias? If that old Fortran was hard to work with, maybe it would have been rewritten, and left the set of “oldest code” in the process.
  - Gibbon1 2y ago
    I think it's just procedural languages with a lack of magic.
- chubot 2y ago
  Sure, Perl can be hard to maintain. (I haven't used it in over 25 years, and don't expect to ever use it again) From your experience maintaining 40+ year old codebases, is it possible that improving the Perl codebase is the best choice in a certain situation? Or should we always be "surprised" that Perl exists? (honest question) In other words, I don't see the connection between "this code is hard to maintain" and "I am surprised that it exists" / "it should be rewritten".
- Joel_Mckay 2y ago
  In general, I tend to observe languages that are minimally challenging for amateurs tend to build less sustainable mutagenic ecosystems. Example: * Prolog generated the worlds most functional 1 liner code, as it is bewildering for hope-and-poke programmers * Pythons ease of use combined with out-of-band library packages became a minefield of compatibility, security, and structural problems (i.e. became the modern BASIC) * NodeJS was based on a poorly designed clown JavaScript toy language, so naturally became a circus * Modern C++ template libraries became unusable as complexity and feature creep spiraled out of control to meet everyone's pet use-case * Rust had a massive inrush of users that don't understand why llvm compilers are dangerous in some use-cases. But considering 99% of devs are in application space, they will unlikely ever need to understand why C has a different use-case. While "Goto" could just be considered a euphemism for tail-recursion in some languages. We have to remember the feature is there for a reason, but most amateurs are not careful enough to use it in the proper edge-case. I really hope Julia becomes more popular, as it is the first fun language I've seen in years that kind of balances ease of use with efficient parallelism. wrote a lot of RISC Assembly at one time... where stacks were finite, and thus one knew evil well... lol =3
deleted 2y ago
[deleted]

rleigh 2y ago

sbuild is at least 25 years old, it might be nearer to 30 at this point. I did a lot of cleanup of it during the mid-2000s, including adding the schroot support to it which is being removed here, and that included abstracting virtualisation backends which allowed newer solutions to replace it. The original had to run as root to do a chroot(2) call, and it reused the same environment between builds. schroot removed the need to run as root, and it could provide a clean snapshot for each build. But it too is now rather dated--though the replacement tools often lack some of the features it has, like being able to build from ZFS cloned snapshots or Btrfs snapshots, or even LVM snapshots. We wanted it to be fast as well as safe, and the time-to-build and time-to-clean-up using these was and is excellent. Replacing key infrastructure is hard, particularly when it's working well and the cost of replacement is high, especially so when it's volunteer effort. It was cutting edge back when Perl was all the rage, but while Perl might no longer be the fashionable choice, tools written in Perl continue to work just as they always have. I found it dense and impenetrable even 20 years back, and I used to have the whole thing printed out on fan-fold paper from a dot matrix; it was about 3/4" thick and covered in annotations! Understanding several thousand lines of obscure regexes is a cautionary tale in how to write unmaintainable Perl, and was one of the motivations to clean it up, refactor it into meaningful functions, and document what it was doing so that it could be maintained with a little less effort.