3 ms·

Though I'm no longer a fan of Perl, I like the idea that a reasonably up-to-date version can be expected on modern Linux systems. Disk space is so cheap, it se

Though I'm no longer a fan of Perl, I like the idea that a reasonably up-to-date version can be expected on modern Linux systems. Disk space is so cheap, it seems crazy to strip it out just to save a few megabytes, except perhaps on embedded platforms. I spend a lot of time fixing other people's stuff, and it's exasperating to log into a system only to discover that it's missing such basic tools. (emacs and strace are more important to me, but the idea is the same.)

Lammy 7y ago
It's worth the reduction in attack surface: https://www.cvedetails.com/vulnerability-list.php?vendor_id=1885 https://www.cvedetails.com/vulnerability-list.php?vendor_id=... I concede it is a little different on FreeBSD where the "base system" is developed in a single source tree and released as a complete OS. Third-party interpreters/libraries like Perl are more visibly alien there than on a Linux distro where everything effectively is.
- downerending 7y ago
  Hmm. As long as nothing is setuid, mere presence of different language interpreters doesn't sound like it would make much difference. I suppose a nicely set up host would be a bit more attractive as a target, and similarly a VMS box not be an attractive target, no matter how insecure it is. Still, I wouldn't want to switch back to VMS.
  - Lammy 7y ago
    Well in the case I'm remembering a lot of setuid system utilities were written in Perl and had to be re-written in C before the interpreter and libraries could be excised. I don't know to what extent Python 2 exhibits that problem for most *nix systems.
    - downerending 7y ago
      I agree completely with switching the language for various distribution utilities to more modern languages as needed. I'm rather arguing against removing vanilla language environments that have attained the status of being ubiquitous, e.g., to save space or militate against the usage of "old" languages.
  - rbanffy 7y ago
    I you find a VMS box deployed, you can bet it's controlling something really, really important nobody wants to mess with. Either that, or it's a machine someone forgot to decommission and that's still there, sitting in a cabinet, eagerly waiting for that terminal connection that'll never come.

Lammy 7y ago

It's worth the reduction in attack surface: https://www.cvedetails.com/vulnerability-list.php?vendor_id=1885 https://www.cvedetails.com/vulnerability-list.php?vendor_id=... I concede it is a little different on FreeBSD where the "base system" is developed in a single source tree and released as a complete OS. Third-party interpreters/libraries like Perl are more visibly alien there than on a Linux distro where everything effectively is.

downerending 7y ago
Hmm. As long as nothing is setuid, mere presence of different language interpreters doesn't sound like it would make much difference. I suppose a nicely set up host would be a bit more attractive as a target, and similarly a VMS box not be an attractive target, no matter how insecure it is. Still, I wouldn't want to switch back to VMS.
- Lammy 7y ago
  Well in the case I'm remembering a lot of setuid system utilities were written in Perl and had to be re-written in C before the interpreter and libraries could be excised. I don't know to what extent Python 2 exhibits that problem for most *nix systems.
  - downerending 7y ago
    I agree completely with switching the language for various distribution utilities to more modern languages as needed. I'm rather arguing against removing vanilla language environments that have attained the status of being ubiquitous, e.g., to save space or militate against the usage of "old" languages.
- rbanffy 7y ago
  I you find a VMS box deployed, you can bet it's controlling something really, really important nobody wants to mess with. Either that, or it's a machine someone forgot to decommission and that's still there, sitting in a cabinet, eagerly waiting for that terminal connection that'll never come.