¿Por qué se instala Perl de manera predeterminada con la mayoría de las distribuciones de Linux?


Respuestas:


27

La respuesta es / no es sexy, dependiendo de tu punto de vista.

Perl es muy útil. Muchas de las utilidades del sistema están escritas o dependen de Perl. La mayoría de los sistemas no funcionarán correctamente si se desinstala Perl.

Hace unos años, FreeBSD hizo un gran esfuerzo para eliminar Perl como dependencia del sistema base. No fue una tarea fácil.


¿Se usa Perl en el núcleo mismo? Estoy mirando este artículo que afirma que el Kernel usa alrededor de 2,200 líneas de código Perl para estimar el tamaño de GNU Linux . Además, lo que provocó la pregunta; Al instalar Arch Linux, noté que Perl está instalado en el paquete base , ¿hay utilidades centrales que usan Perl?

99
@JoshVoigts el kernel en sí no usa perl no. Sin embargo, el proceso de construcción del núcleo utiliza una buena cantidad de perl. En cuanto a Arch, alguien más tendrá que responder esa pregunta.
Patrick

3
Por curiosidad, ¿con qué FreeBSD reemplazó a Perl?
Shadur

44
@ire_and_curses: ¡ Perl5 abandona el sistema base para 5.0 y posteriores! También a partir de 2011: FreeBSD: Fusión de sistemas de paquetes (bajo OpenBSD).
bahamat

77
El sistema base de FreeBSD es básicamente un repositorio de código fuente gigante con el núcleo, las utilidades y todo. Así que estaban manteniendo su propio tenedor de Perl en ese repositorio, lo que fue un gran esfuerzo y difícil de mantener actualizado con Perl. Por lo tanto, tenía sentido que eliminaran Perl del sistema base y simplemente lo instalaran como un puerto, lo cual es mucho más fácil de mantener actualizado (porque solo están obteniendo las versiones de Perl y compilándolas).
cjm

24

En la publicación original de Perry v1.0 de Larry Wall en el grupo de noticias comp.sources.misc el 18 de diciembre de 1987, dijo:

Si tiene un problema que normalmente usaría sed o awk o sh, pero excede sus capacidades o debe ejecutarse un poco más rápido, y no desea escribir lo tonto en C, entonces Perl puede ser para usted.

En una exposición muy posterior , elaboró ​​un poco más:

Pero las frustraciones de la programación de shell de Unix condujeron directamente a la creación de Perl, que realmente no tengo tiempo para contar. Pero, en esencia, descubrí que las secuencias de comandos de shell estaban intrínsecamente limitadas por el hecho de que la mayoría de sus verbos no están bajo su control y, por lo tanto, son inconsistentes entre sí. Y los sustantivos están empobrecidos, restringidos a cadenas y archivos, con la tipología de quién sabe qué ...

Más destructiva fue la mentalidad de que era un universo unidimensional: o bien programó en C o programó en shell, porque obviamente están en los extremos opuestos del One True Continuum. Perl surgió cuando me di cuenta de que las secuencias de comandos no siempre tenían que verse como lo opuesto a la programación, sino que un solo lenguaje podría ser bastante bueno para ambos. Eso abrió un gran nicho ecológico. Muchos de ustedes han visto mi antiguo diagrama de concha, con las dos dimensiones de manipulexidad y látigo.

Hoy, Perl es una alternativa / reemplazo estándar para las necesidades de scripting de shell y análisis de texto, y con mucha más potencia que las herramientas tradicionales. Debido a su extrema flexibilidad (algunos dirían poco elegante), Perl ha sido descrita como " la motosierra del ejército suizo de los lenguajes de secuencias de comandos ". Las tareas a menudo pueden ser significativamente más cortas, más fáciles o más extensibles cuando se resuelven con Perl. Muchas, muchas herramientas del sistema, scripts y programas más grandes se escriben habitualmente en Perl. Entonces, en el entorno moderno de Linux, Perl es ahora otra herramienta estándar de Unix, y realmente indispensable.


4
  1. Perl fue desarrollado para Unix porque las herramientas no eran lo suficientemente potentes. Para deportes, puedes buscar awky seden él (Perl).
  2. Perl se inspiró (entre otras cosas) en el shell de Unix (y C, que es muy importante para Unix, o al revés, tal vez).
  3. Además, Perl se puede distribuir bajo una licencia GNU . Algunas personas lo considerarían irrelevante desde un punto de vista técnico, pero muestra la mezcla.
  4. Lo último que se me ocurre es LAMP, que es un "paquete de software" de redes. (Compruébelo en Wikipedia: la P es, o al menos fue, Perl; la L es Linux.) (Pero este último punto es un poco "pollo o huevo").

55
La P en LAMP en estos días es mucho más a menudo PHP o Python. Creo que Perl es más un uso heredado del acrónimo.
darvids0n

Notepad ++ se lanza bajo una licencia GNU (específicamente, la GNU GPL). AFAIK hay poca "mezcla" entre Notepad ++ y varias distribuciones de Linux. Solo por mencionar un contraejemplo a su punto # 3.
un CVn el

@ MichaelKjörling: ¿No estaría de acuerdo con que ciertas licencias dificultarán la difusión de su aplicación (o, en este caso, un lenguaje de programación) en el mundo Linux, mientras que otras no pondrán tales obstáculos? Eso no significa que podría obtener una licencia para ingresar a una distribución, si realmente pensara que eso fue lo que dije. (Creo que no)
Emanuel Berg

@darvidsOn: Sí ... eso es lo que dije (?). (Supongo que es una coincidencia que esos grandes lenguajes de script comiencen con una P.)
Emanuel Berg,

@EmanuelBerg Usted mencionó la "mezcla" entre Perl y Linux basándose en el hecho de que Perl tiene una licencia GNU. Existe una gran cantidad de software tanto en los puertos de FreeBSD como en muchas distribuciones de Linux que tienen otras licencias, y una gran cantidad de software que no se ejecuta en ninguna de las dos licencias GNU (GPL, LGPL, FDL, ...).
un CVn

1

Creo que la respuesta a esta pregunta es en parte histórica, en parte práctica.

En cuanto a la historia, Perl es un lenguaje con clase. Es más elegante que Python (sin mencionar PHP), aunque no tengo idea de qué es "mejor" (si eso de alguna manera podría analizarse formalmente, lo cual dudo). Y los chicos con clase que usan (o usan) Perl suelen ser los que deciden qué debería ser parte de una distribución de Linux.

En cuanto a lo que es práctico, Perl sigue siendo el pegamento de muchas cosas: sistemas operativos y la web por igual (de nuevo, LAMP, sin olvidar Python o PHP). Entonces, ¿por qué no incluir nada que sea útil para muchos propósitos? Y aún más, ¿por qué eliminar todo lo que está allí (y que no causa ningún daño) y que es útil?

Pero, como sucede, hay una nota al respecto en el último número de The Linux Magazine (# 151, junio de 2013). Aparentemente, para compilar el kernel de Linux se emplean un par de scripts cortos y simples de Perl. (Nuevamente, el papel de "pegar" de Perl en los sistemas operativos). Ahora, uno de los desarrolladores del núcleo ha estado enviando parches de una reescritura de esos scripts, esta vez no en Perl, sino como "scripts de shell Unix" (es que sh?) De esa manera, Perl no tendría que estar instalado para nadie que compila el núcleo. Pero ese parche (enviado varias veces) no se ha recogido. Y una de las razones de esto es que, una vez en el frío, es probable que Perl no pueda entrar. A la gente le gusta Perl, y no quieren separarse de él.

Ahora, esto solo toca los límites de esta pregunta, ya que probablemente una minoría muy pequeña de usuarios de Linux probablemente compile el núcleo. Pero es otra pieza más del rompecabezas (y sospecho que hay muchos).


1
No es un comentario para ti, Emanuel, pero para las personas que no quieren separarse de Perl, ¿qué tan difícil puede ser instalarlo si lo necesitas / lo quieres?
MattBianco
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.