Slackware es una distribución Linux creada por Patrick Volkerding en 1993. Originalmente basada en Softlanding Linux System (SLS), [5] Slackware ha sido la base de muchas otras distribuciones Linux, más notablemente las primeras versiones de las distribuciones SUSE Linux , y es la distribución más antigua que aún se mantiene. [6]
Slackware busca la estabilidad y simplicidad del diseño y ser la distribución Linux más " similar a Unix " . [7] Realiza la menor cantidad posible de modificaciones a los paquetes de software desde el origen y trata de no anticipar los casos de uso ni impedir las decisiones de los usuarios. A diferencia de la mayoría de las distribuciones Linux modernas, Slackware no proporciona un procedimiento de instalación gráfico ni una resolución automática de dependencias de los paquetes de software. Utiliza archivos de texto sin formato y solo un pequeño conjunto de scripts de shell para la configuración y la administración. Sin más modificaciones, se inicia en un entorno de interfaz de línea de comandos . Debido a sus muchas características conservadoras y simplistas, a menudo se considera que Slackware es el más adecuado para usuarios de Linux avanzados y con inclinaciones técnicas. [8] [9] [10] [11] [12] [13]
Slackware está disponible para las arquitecturas IA-32 y x86_64 , con un puerto para la arquitectura ARM . Si bien Slackware es en su mayor parte [14] software libre y de código abierto , no tiene una función formal de seguimiento de errores ni un repositorio de código público, y Volkerding anuncia periódicamente los lanzamientos. No existe un procedimiento formal de membresía para los desarrolladores y Volkerding es el principal colaborador de los lanzamientos.
El nombre "Slackware" se debe a que la distribución comenzó como un proyecto privado paralelo sin ningún compromiso previsto. Para evitar que se lo tomara demasiado en serio al principio, Volkerding le dio un nombre humorístico, que se mantuvo incluso después de que Slackware se convirtiera en un proyecto serio. [15]
Slackware hace referencia a la "búsqueda de Slack", un principio de la Iglesia del SubGenio , una religión paródica. Ciertos aspectos de los gráficos de Slackware reflejan esto [16] —la pipa que está fumando Tux, influenciada por la imagen de la cabeza de JR "Bob" Dobbs .
En muchas versiones de los archivos de texto install.end , que indican el final de una serie de programas al programa de instalación, se puede encontrar una referencia humorística a la Iglesia del SubGenio . En versiones recientes, incluida la versión 14.1 de Slackware, el texto está ofuscado por ROT13 . [17] [18]
Slackware se derivó originalmente del Softlanding Linux System (SLS), [19] la más popular de las distribuciones originales de Linux y la primera en ofrecer una colección de software integral que comprendía más que solo el núcleo y las utilidades básicas, [20] incluyendo una interfaz gráfica X11 , TCP/IP , redes UUCP y GNU Emacs . [21]
Patrick Volkerding empezó a trabajar con SLS después de necesitar un intérprete de LISP para un proyecto escolar en la entonces llamada Universidad Estatal de Moorhead (MSU). Encontró que CLISP estaba disponible para Linux y descargó SLS para ejecutarlo. Unas semanas después, su profesor de inteligencia artificial en la MSU le pidió a Volkerding que le mostrara cómo instalar Linux en casa y en algunas de las computadoras de la escuela. Volkerding había tomado notas describiendo las correcciones a los problemas que encontró después de instalar SLS y él y su profesor revisaron y aplicaron esos cambios a una nueva instalación. Sin embargo, esto llevó casi tanto tiempo como el que llevó instalar SLS, por lo que el profesor preguntó si los discos de instalación se podían ajustar para que las correcciones se pudieran aplicar durante la instalación. Este fue el comienzo de Slackware. Volkerding continuó realizando mejoras en SLS: corrigiendo errores, actualizando software, instalación automática de bibliotecas compartidas y la imagen del núcleo, arreglando permisos de archivos y más. En poco tiempo, Volkerding había actualizado aproximadamente la mitad de los paquetes más allá de los que SLS tenía disponibles.
Volkerding no tenía intención de ofrecer su versión modificada de SLS al público. Sus amigos de la MSU le instaron a que subiera sus modificaciones de SLS a un servidor FTP, pero Volkerding supuso que "SLS publicaría una nueva versión que incluiría estas cosas muy pronto", por lo que esperó unas semanas. Durante ese tiempo, muchos usuarios de SLS en Internet le pedían a SLS una nueva versión, por lo que finalmente Volkerding publicó un mensaje titulado "¿Alguien quiere un sistema 0.99pl11A similar a SLS?", al que recibió muchas respuestas positivas. Después de una discusión con el administrador de sistemas local de la MSU, Volkerding obtuvo permiso para subir Slackware al servidor FTP de la universidad. [15] Esta primera versión de Slackware, la 1.00, se distribuyó el 17 de julio de 1993 a las 00:16:36 (UTC), [1] y se suministró como veinticuatro imágenes de disquete de 3½" . [22] Después de que se hizo el anuncio, Volkerding observó cómo la avalancha de conexiones FTP colapsaba continuamente el servidor. Poco después, Walnut Creek CDROM ofreció espacio de archivo adicional en sus servidores FTP. [15]
El tamaño de Slackware aumentó rápidamente con la incorporación de software incluido, y en la versión 2.1, lanzada en octubre de 1994, se había más que triplicado hasta incluir setenta y tres imágenes de disquete de 1,44 M. [23]
En 1999, Slackware vio cómo su versión saltaba de la 4 a la 7. Los números de versión de Slackware iban por detrás de otras distribuciones, y esto llevó a muchos usuarios a creer que estaba desactualizado a pesar de que las versiones del software incluido eran similares. Volkerding tomó la decisión de aumentar la versión como un esfuerzo de marketing para demostrar que Slackware estaba tan actualizado como otras distribuciones de Linux, muchas de las cuales tenían números de versión 6 en ese momento. Eligió la 7, estimando que la mayoría de las otras distribuciones pronto tendrían este número de versión. [24]
En abril de 2004, Patrick Volkerding añadió los paquetes de X.Org Server al directorio testing/ de -current como reemplazo de los paquetes XFree86 que se estaban usando actualmente, con una solicitud de comentarios sobre cuál debería ser el futuro del sistema X Window en Slackware. Un mes después, cambió de XFree86 a X.Org Server después de afirmar que las opiniones eran más de 4 a 1 a favor de usar la versión X.org como la versión predeterminada de X. Afirmó que la decisión fue principalmente técnica, ya que XFree86 estaba demostrando causar problemas de compatibilidad. Slackware 10.0 fue la primera versión con X.Org Server. [25]
En marzo de 2005, Patrick Volkerding anunció la eliminación del entorno de escritorio GNOME en el registro de cambios de desarrollo. Afirmó que esto se había estado considerando durante más de cuatro años y que ya había proyectos que proporcionaban una versión más completa de GNOME para Slackware que la que proporcionaba el propio Slackware. Volkerding afirmó que el soporte futuro de GNOME dependería de la comunidad. [26] La comunidad respondió y, a octubre de 2016, hay varios proyectos de GNOME activos para Slackware. Estos incluyen Cinnamon , Dlackware, Dropline GNOME , MATE y SlackMATE. La eliminación fue considerada significativa por algunos en la comunidad Linux debido a la prevalencia de GNOME en muchas distribuciones. [27]
En mayo de 2009, Patrick Volkerding anunció el lanzamiento público (en desarrollo) de una variante x86_64 oficial, llamada Slackware64, mantenida en paralelo con la distribución IA-32 . [28] Slackware64 es una distribución pura de 64 bits en el sentido de que no admite la ejecución o compilación de programas de 32 bits, sin embargo, fue diseñada como "compatible con múltiples bibliotecas". Eric Hameleers, uno de los miembros principales del equipo de Slackware, mantiene un repositorio multilib que contiene los paquetes necesarios para convertir Slackware64 a multilib para permitir la ejecución de software de 32 bits. [29] Hameleers comenzó el puerto de 64 bits como una distracción del dolor de recuperarse de una cirugía en septiembre de 2008. Volkerding probó el puerto en diciembre de 2008 y quedó impresionado cuando vio aumentos de velocidad de entre el 20 y el 40 por ciento para algunos puntos de referencia en comparación con la versión de 32 bits. Para minimizar el esfuerzo extra de mantener ambas versiones en paralelo, los scripts de compilación de Slackware, llamados SlackBuilds, fueron modificados lentamente para soportar cualquiera de las arquitecturas, lo que permitió un conjunto de fuentes para ambas versiones. [30] Slackware64 vio su primer lanzamiento estable con la versión 13.0.
Entre el lanzamiento de la versión 14.1 en noviembre de 2013 y junio de 2016, Slackware tuvo un lapso de 31 meses entre lanzamientos, lo que marca el lapso más largo en la historia de lanzamientos. Durante este tiempo, la rama de desarrollo estuvo sin actualizaciones durante 47 días. Sin embargo, el 21 de abril de 2015, Patrick Volkerding se disculpó en el ChangeLog por la ausencia de actualizaciones y afirmó que el equipo de desarrollo utilizó el tiempo para "hacer un buen trabajo". Había más de 700 cambios de programa enumerados en esa entrada del ChangeLog, incluidas muchas actualizaciones importantes de la biblioteca. En enero de 2016, Volkerding anunció la adición renuente de PulseAudio , principalmente debido a que BlueZ abandonó el soporte directo de ALSA en v5.x, mientras que varios otros proyectos a su vez abandonaron el soporte para BlueZ v4.x. Sabiendo que algunos usuarios no estarían contentos con el cambio, afirmó que "los informes de errores, las quejas y las amenazas pueden dirigirse a mí". Estos cambios culminaron con el lanzamiento de Slackware 14.2 en junio de 2016. [31]
David Cantrell trabajó como miembro principal del equipo de Slackware entre 1999 y 2001, y describió ese período en el Vlog de Slackware ARM. [32] Patrick Volkerding proporcionó más información sobre ese período en dos entrevistas. [33] [34]
La filosofía de diseño de Slackware está orientada hacia la simplicidad , la pureza del software [35] y un diseño central que enfatiza la falta de cambios en las fuentes originales. Muchas opciones de diseño en Slackware pueden verse como una herencia de la simplicidad de los sistemas Unix tradicionales y como ejemplos del principio KISS [36] . En este contexto, "simple" se refiere a la simplicidad en el diseño del sistema, en lugar del uso del sistema. Por lo tanto, la facilidad de uso puede variar entre usuarios: aquellos que carecen de conocimientos de interfaces de línea de comandos y herramientas clásicas de Unix pueden experimentar una curva de aprendizaje pronunciada al usar Slackware, mientras que los usuarios con antecedentes en Unix pueden beneficiarse de un entorno de sistema menos abstracto. [ cita requerida ] De acuerdo con la filosofía de diseño de Slackware y su espíritu de pureza, la mayoría del software en Slackware usa los mecanismos de configuración originales proporcionados por los autores del software; sin embargo, para algunas tareas administrativas, se entregan herramientas de configuración específicas de la distribución.
No existe un sistema formal de seguimiento de problemas ni un procedimiento oficial para convertirse en colaborador o desarrollador de código. El proyecto no mantiene un repositorio de código público. Los informes de errores y las contribuciones, si bien son esenciales para el proyecto, se gestionan de manera informal. Todas las decisiones finales sobre lo que se incluirá en una versión de Slackware quedan estrictamente en manos del benevolente dictador vitalicio de Slackware , Patrick Volkerding. [37] [38] [39]
Las primeras versiones de Slackware fueron desarrolladas por Patrick Volkerding en solitario. A partir de la versión 4.0, los archivos oficiales de anuncios de Slackware incluyen a David Cantrell y Logan Johnson como parte del "equipo de Slackware". [40] Los anuncios posteriores, hasta la versión 8.1, incluyen a Chris Lumens. [41] Lumens, Johnson y Cantrell también son los autores de la primera edición de "Slackware Linux Essentials", la guía oficial de Slackware Linux. [42] El sitio web de Slackware menciona a Chris Lumens y David Cantrell como "antiguos alumnos de Slackware", que "trabajaron a tiempo completo en el proyecto Slackware durante varios años". [38] En sus notas de lanzamiento para Slackware 10.0 y 10.1, Volkerding agradece a Eric Hameleers por "su trabajo en el soporte de tarjetas inalámbricas USB, PCI y Cardbus". [43] [44] A partir de la versión 12.0, por segunda vez, se está formando un equipo en torno a Volkerding. Según las notas de la versión 12.2, el equipo de desarrollo está formado por siete personas. En las versiones posteriores se han añadido más personas. [45] Desde la versión 13.0, el equipo de Slackware parece tener miembros principales. Eric Hameleers ofrece una visión del equipo principal con su ensayo sobre la "Historia del desarrollo de Slackware", escrito el 3 y 4 de octubre de 2009 (poco después del lanzamiento de la versión 13.0). [37]
El sistema de administración de paquetes de Slackware, conocido colectivamente como pkgtools, puede administrar ( pkgtool ), instalar ( installpkg ), actualizar ( upgradepkg ) y eliminar ( removepkg ) paquetes de fuentes locales. También puede descomprimir ( explosivepkg ) y crear ( makepkg ) paquetes. La herramienta oficial para actualizar Slackware a través de una red o Internet es slackpkg . Fue desarrollado originalmente por Piter Punk como una forma no oficial de mantener Slackware actualizado. Se incluyó oficialmente en el árbol principal en Slackware 12.2, [46] habiendo sido incluido en extras/ desde Slackware 9.1. [47] Cuando se actualiza un paquete, instalará el nuevo paquete sobre el antiguo y luego eliminará cualquier archivo que ya no exista en el nuevo paquete. Una vez que se ha instalado un paquete con slackpkg se puede administrar con pkgtool u otros comandos de administración de paquetes. [48] Al ejecutar upgradepkg , solo confirma que los números de versión son diferentes , lo que permite degradar el paquete si se desea.
Los paquetes de Slackware son archivos tar comprimidos mediante varios métodos. A partir de la versión 13.0, la mayoría de los paquetes se comprimen utilizando xz (basado en el algoritmo de compresión LZMA ), utilizando la extensión de nombre de archivo .txz . [49] Antes de la versión 13.0, los paquetes se comprimían utilizando gzip (basado en el algoritmo de compresión DEFLATE ), utilizando la extensión .tgz . También se agregó soporte para la compresión bzip2 y lzip , utilizando las extensiones de nombre de archivo .tbz y .tlz respectivamente, aunque estas no se usan comúnmente.
Los paquetes contienen todos los archivos de ese programa, así como archivos de metadatos adicionales utilizados por el administrador de paquetes. El paquete tarball contiene la estructura de directorio completa de los archivos y está destinado a ser extraído en el directorio raíz del sistema durante la instalación. Los archivos de metadatos adicionales, ubicados bajo el directorio especial install/ dentro del tarball, generalmente incluyen un archivo slack-desc , que es un archivo de texto con formato específico que es leído por el administrador de paquetes para proporcionar a los usuarios una descripción del software empaquetado, [50] así como un archivo doinst.sh , que es un script de shell posterior al desempaquetado que permite la creación de enlaces simbólicos, la conservación de permisos en los archivos de inicio, el manejo adecuado de nuevos archivos de configuración y cualquier otro aspecto de la instalación que no se pueda implementar a través de la estructura de directorio del paquete. [51] Durante el desarrollo de 15.0, Volkerding introdujo soporte para un script de desinstalación douninst.sh que se puede iniciar al eliminar o actualizar un paquete. [52] Esto permite a los mantenedores de paquetes ejecutar comandos cuando se desinstala un paquete.
El administrador de paquetes mantiene una base de datos local en la computadora, almacenada en múltiples carpetas. En los sistemas 14.2 y anteriores, la base de datos principal de los paquetes instalados se mantenía en /var/log/ , sin embargo, durante el desarrollo de 15.0, Volkerding movió dos de los directorios a una ubicación dedicada bajo /var/lib/pkgtools/ para evitar la eliminación accidental al limpiar los registros del sistema. [52] Cada instalación de Slackware contendrá un directorio packages/ y scripts/ en la ubicación de la base de datos principal. El primero es donde cada paquete instalado tendrá un archivo de registro de instalación correspondiente (basado en el nombre del paquete, la versión, la arquitectura y la compilación) que contiene el tamaño del paquete, tanto comprimido como sin comprimir, la descripción del software y la ruta completa de todos los archivos que se instalaron. [53] Si el paquete contenía un script post-instalación doinst.sh opcional , el contenido de ese script se agregará a un archivo en el directorio scripts/ que coincida con el nombre de archivo del paquete correspondiente en el directorio packages/ , lo que permite al administrador ver el script post-instalación en un momento futuro. Cuando se elimina o actualiza un paquete, los registros de instalación y scripts antiguos que se encuentran en packages/ y scripts/ se mueven a removed_packages/ y removed_scripts/ , lo que permite revisar los paquetes anteriores y ver cuándo se eliminaron. Estos directorios se pueden encontrar en /var/log/ en 14.2 y anteriores, pero se movieron a /var/log/pkgtools/ durante el desarrollo de 15.0. En los sistemas que admiten el script de desinstalación douninst.sh , esos scripts se almacenarán en el directorio /var/lib/pkgtools/douninst.sh/ mientras se instala el paquete. Una vez eliminado, el script douninst.sh se moverá a /var/log/pkgtools/removed_uninstall_scripts/ .
El sistema de administración de paquetes no rastrea ni administra las dependencias ; sin embargo, al realizar la instalación completa recomendada, se cumplen todas las dependencias de los paquetes estándar. Para instalaciones personalizadas o paquetes de terceros, Slackware confía en que el usuario se asegure de que el sistema tenga todas las bibliotecas y programas de soporte del sistema que requiere el programa. Dado que no se proporcionan listas oficiales de dependencias para los paquetes estándar, si los usuarios deciden instalar una instalación personalizada o instalar software de terceros, deberán solucionar por sí mismos las posibles dependencias faltantes. Dado que el administrador de paquetes no administra las dependencias, instalará todos los paquetes, independientemente de si se cumplen o no las dependencias. Un usuario puede descubrir que faltan dependencias solo cuando intenta usar el software.
Si bien Slackware en sí no incorpora herramientas oficiales para resolver dependencias, algunas herramientas de software no oficiales respaldadas por la comunidad sí brindan esta función, de manera similar a la que APT hace para las distribuciones basadas en Debian y yum para las distribuciones basadas en Red Hat . Entre ellas se incluyen:
No existen repositorios oficiales para Slackware. Los únicos paquetes oficiales que proporciona Slackware están disponibles en el medio de instalación. Sin embargo, existen muchos repositorios de terceros para Slackware; algunos son repositorios independientes y otros son para distribuciones que están basadas en Slackware pero mantienen la compatibilidad de paquetes con Slackware. Muchos de estos se pueden buscar a la vez utilizando pkgs.org, que es un motor de búsqueda de paquetes de Linux. Sin embargo, mezclar y combinar dependencias de múltiples repositorios puede llevar a dos o más paquetes que requieren diferentes versiones de la misma dependencia, lo que es una forma de infierno de dependencias . Slackware en sí no proporcionará ninguna resolución de dependencias para estos paquetes, sin embargo, algunos proyectos proporcionarán una lista de dependencias que no están incluidas con Slackware con los archivos del paquete, comúnmente con una extensión .dep .
Debido a la posibilidad de problemas de dependencia, muchos usuarios optan por compilar sus propios programas utilizando SlackBuilds proporcionados por la comunidad. Los SlackBuilds son scripts de shell que crearán un paquete instalable de Slackware a partir de un archivo tar de software proporcionado. Dado que los SlackBuilds son scripts, no se limitan a compilar el código fuente de un programa; también se pueden utilizar para volver a empaquetar binarios precompilados proporcionados por proyectos u otros repositorios de distribuciones en paquetes Slackware adecuados. Los SlackBuilds que compilan el código fuente tienen varias ventajas sobre los paquetes precompilados: dado que se compilan a partir del código fuente del autor original, el usuario no tiene que confiar en un empaquetador de terceros; además, el proceso de compilación local permite la optimización específica de la máquina. En comparación con la compilación e instalación manual de software, los SlackBuilds proporcionan una integración más limpia con el sistema al utilizar el administrador de paquetes de Slackware. Algunos SlackBuilds vendrán con un archivo adicional con metadatos que permite que las herramientas automatizadas descarguen la fuente, verifiquen que la fuente no esté dañada y calculen dependencias adicionales que no son parte de Slackware. [56] Algunos repositorios incluirán tanto SlackBuilds como los paquetes Slackware resultantes, lo que permitirá a los usuarios construir sus propios paquetes o instalar un paquete prediseñado.
El único repositorio de SlackBuilds oficialmente respaldado [57] es SlackBuilds.org, comúnmente conocido como SBo. Este es un proyecto respaldado por la comunidad que ofrece SlackBuilds para compilar software no incluido en Slackware. Los usuarios pueden enviar nuevos SlackBuilds para software al sitio y, una vez aprobados, se convierten en el "mantenedor del paquete". Luego son responsables de proporcionar actualizaciones a SlackBuild, ya sea para solucionar problemas o para compilar versiones más nuevas proporcionadas por upstream . Para garantizar que todos los programas se puedan compilar y usar, se requiere que cualquier dependencia requerida del software no incluido en Slackware esté documentada y disponible en el sitio. Todos los envíos son probados por los administradores del sitio antes de agregarlos al repositorio. Los administradores tienen la intención de que el proceso de compilación sea casi idéntico a la forma en que se compilan los paquetes oficiales de Slackware, principalmente para garantizar que Volkerding "simpatizara con nuestra causa". Esto permite que los SlackBuilds que Volkerding considere que merecen la pena se incorporen al Slackware normal con cambios mínimos en el script. También evita que los usuarios sugieran a Volkerding que cambie sus scripts para que coincidan con los de SBo. [58] SBo proporciona plantillas [59] para SlackBuilds y los archivos de metadatos adicionales y anima a los encargados del mantenimiento de los paquetes a no desviarse a menos que sea necesario. [60]
Dos miembros del equipo de Slackware, Eric Hameleers y Robby Workman, tienen cada uno su propio repositorio de paquetes precompilados junto con los SlackBuilds y los archivos fuente utilizados para crear los paquetes. Si bien la mayoría de los paquetes son simplemente software adicional no incluido en Slackware y que consideraron que valía la pena mantener, algunos paquetes se utilizan como banco de pruebas para futuras actualizaciones de Slackware; en particular, Hameleers proporciona paquetes "Ktown" para versiones más nuevas de KDE . [61] También mantiene el repositorio "multilib" de Slackware, lo que permite que Slackware64 ejecute y compile paquetes de 32 bits. [29]
La política de lanzamiento de Slackware sigue un ciclo de lanzamiento basado en características y estabilidad, en contraste con los esquemas de tiempo limitado ( por ejemplo , Ubuntu ) o lanzamiento continuo ( por ejemplo , Gentoo Linux ) de otras distribuciones Linux. Esto significa que no hay un tiempo establecido para esperar un lanzamiento. Volkerding lanzará la próxima versión después de que sienta que se ha realizado una cantidad adecuada de cambios con respecto a la versión anterior y que esos cambios conducen a un entorno estable. Como afirmó Patrick Volkerding, "Normalmente nuestra política es no especular sobre las fechas de lanzamiento, ya que eso es lo que es: pura especulación. No siempre es posible saber cuánto tiempo llevará realizar las actualizaciones necesarias y atar todos los cabos sueltos relacionados. A medida que se vayan construyendo las cosas para el próximo lanzamiento, se irán cargando en el árbol -current". [62]
A lo largo de la historia de Slackware, generalmente intentaron entregar software actualizado al menos una vez al año. [37] Desde su inicio hasta 2014, Slackware tuvo al menos un lanzamiento por año. La actividad de lanzamiento alcanzó su punto máximo en 1994, 1995, 1997 y 1999, con tres lanzamientos cada año. A partir de la versión 7.1 (22 de junio de 2000), la progresión de lanzamientos se volvió más estable y generalmente se produjo una vez al año. Después de ese punto, los únicos años con dos lanzamientos fueron 2003, 2005 y 2008. Sin embargo, desde el lanzamiento de Slackware 14.1 en 2013, los nuevos lanzamientos se han ralentizado drásticamente. Hubo una brecha de más de 2 años entre 14.1 y 14.2 y más de 5 años hasta 15.0. [52] Tras el lanzamiento de la versión 15.0, Volkerding afirmó que se esperaba que Slackware 15.1 tuviera un ciclo de desarrollo mucho más corto, ya que las "partes complicadas" se resolvieron durante el desarrollo de la versión 15.0. [63]
Las últimas versiones estables x86 de 32 bits y x86_64 de 64 bits de Slackware son la versión 15.0 (lanzada el 2 de febrero de 2022), que incluye soporte para Linux 5.15.19. [64]
Volkerding también mantiene una versión de prueba/desarrollo de Slackware llamada "-current" [65] que se puede usar para una configuración más avanzada . Esta versión eventualmente se convertirá en la próxima versión estable, momento en el cual Volkerding iniciará una nueva versión -current para comenzar a desarrollar la próxima versión de Slackware. Si bien se sabe que esta versión es estable, es posible que algunas cosas fallen, por lo que -current tiende a no recomendarse para sistemas de producción. [66]
Actualmente, Slackware no tiene una política de duración de soporte oficialmente establecida. Sin embargo, el 14 de junio de 2012, aparecieron avisos en los registros de cambios de las versiones 8.1, [107] 9.0, 9.1, 10.0, 10.1, 10.2, 11.0 y 12.0 que indicaban que, a partir del 1 de agosto de 2012, ya no se proporcionarían parches de seguridad para estas versiones. La versión más antigua, la 8.1, se lanzó el 18 de junio de 2002 y tuvo más de 10 años de soporte antes de llegar al fin de su vida útil . Más tarde, el 30 de agosto de 2013, se hicieron anuncios en los registros de cambios de 12.1 [108] y 12.2 que indicaban su fin de vida útil el 9 de diciembre de 2013. Se indicó en las entradas del registro de cambios que tenían al menos 5 años de soporte. El 6 de abril de 2018, se declaró que las versiones 13.0, 13.1 y 13.37 [109] alcanzarían su fin de vida útil el 5 de julio de 2018. En las entradas del registro de cambios se indicó que contaban con soporte durante al menos 7 años (la versión 13.0 había recibido soporte durante casi 9 años). El 9 de octubre de 2023, el registro de cambios de la versión 14.2 indicó que las versiones 14.0, 14.1 y 14.2 llegarían a su fin de vida útil a partir del 1 de enero de 2024. [110]
Si bien no ha habido anuncios oficiales para versiones anteriores a 8.1, ya no reciben mantenimiento y están efectivamente al final de su vida útil.
Históricamente, Slackware se concentraba únicamente en la arquitectura IA-32 y las versiones estaban disponibles solo en 32 bits. Sin embargo, a partir de Slackware 13.0, está disponible una variante x86_64 de 64 bits que cuenta con soporte oficial en el desarrollo simétrico con la plataforma de 32 bits. Antes del lanzamiento de Slackware64, los usuarios que querían 64 bits debían utilizar puertos no oficiales como slamd64.
Slackware también está disponible para la arquitectura IBM S/390 en forma de Slack/390 y para la arquitectura ARM bajo Slackware ARM (originalmente conocido como 'ARMedslack'). Ambos puertos han sido declarados "oficiales" por Patrick Volkerding. [111] [112] Sin embargo, el puerto S/390 todavía está en la versión 10.0 para la versión estable y 11.0 para la versión de prueba/desarrollo, y no ha tenido actualizaciones desde 2009. [113] [114] Además, el 7 de mayo de 2016, el desarrollador de Slackware ARM anunció que 14.1 alcanzará el fin de su vida útil el 1 de septiembre de 2016 y que el desarrollo de -current cesará con el lanzamiento de 14.2, sin embargo, el soporte para 14.2 se mantendrá en el futuro previsible. [115] El anuncio de EOL para 14.1 se agregó al registro de cambios el 25 de junio de 2016, [116] y el anuncio de EOL para 14.2 se agregó al registro de cambios el 21 de diciembre de 2022. [117]
En julio de 2016, el desarrollador de Slackware ARM anunció que se habían mejorado las herramientas de desarrollo y compilación para reducir el esfuerzo manual que implicaba el mantenimiento del puerto ARM, y procedió a anunciar que se estaba desarrollando un puerto flotante de hardware de 32 bits. El puerto se lanzó en agosto de 2016 en forma "actual". [118]
El 28 de diciembre de 2020, se inició el trabajo de adaptación de Slackware a la arquitectura ARM de 64 bits (conocida como "AArch64"), con los modelos de hardware iniciales RockPro64 y Pinebook Pro de PINE64. Se completó funcionalmente en mayo de 2021 y tiene muchas mejoras con respecto al diseño y la implementación originales del puerto ARM, en particular en lo que respecta a la gestión y habilitación de nuevos modelos de hardware por parte de la comunidad ARM de Slackware. Además, los procesos de arranque e instalación se mejoraron significativamente, lo que hace que el proceso de instalación sea mucho más fácil y ágil.
El 29 de marzo de 2022, Slackware AArch64 se lanzó al público en su forma actual (en desarrollo) con soporte para RockPro64, Pinebook Pro y Raspberry Pi 3 y 4, con documentación de instalación en línea y guías de instalación en video. Además, el proyecto no oficial slarm64 [119] tiene un puerto para AArch64 y un puerto adicional para la arquitectura riscv64 .
En marzo de 2022, el desarrollo oficial del puerto ARM de 32 bits de Slackware cesó, y el desarrollo futuro se concentró únicamente en el puerto AArch64/ARM64. Esto se debió a que el hardware de 32 bits no podía seguir el ritmo del desarrollo de Slackware y estaba inhibiendo el desarrollo, y las limitaciones del hardware se convirtieron en un obstáculo para la adopción de las últimas tecnologías. Además, dado que la mayoría de las otras distribuciones principales dejaron de brindar soporte para ARM de 32 bits, algunas de las aplicaciones no se pudieron compilar y ya no se podía brindar soporte. Sin embargo, existe el puerto no oficial de Slackware BonSlack [120] que proporciona puertos tanto blandos (ARMv5) como duros flotantes (ARMv7) para ARM de 32 bits, con desarrollo y actualizaciones (a partir de la versión 14.2) alineados con Slackware oficial. Este proyecto también proporciona puertos para arquitecturas Aarch64 (ARM64), Alpha , HPPA (PA-RISC 1.1), LoongArch (64 bits), MIPS (32/64 bits), OpenRISC , PowerPC (32/64 bits), RISC-V (64 bits), S/390x , SH-4 , SPARC (32/64 bits) y x86 (32 bits con 64 bits time_t).
El 21 de diciembre de 2022, Slackware ARM 14.2 tuvo su EOL (fin de vida útil) declarado para el 1 de marzo de 2023.
Slackintosh es un port de Slackware Linux para la arquitectura PowerPC de la ROM New World de Macintosh , utilizada por las líneas Power Macintosh , PowerBook , iMac , iBook y Xserve de Apple desde 1994 hasta 2006. La última versión de Slackintosh fue la 12.1, lanzada el 7 de junio de 2008. [121] El sitio web de Slackintosh todavía está activo y la versión 12.1 está disponible para descargar [122] para aquellos que tienen computadoras Macintosh PowerPC más antiguas. Los desarrolladores del proyecto anunciaron en febrero de 2012 que el desarrollo estaba congelado y que la 12.1 podría recibir parches de seguridad durante un mes. [123] El mes siguiente, se anunció que la versión estable estaba congelada y no recibiría más actualizaciones a menos que alguien más decida hacerse cargo. [124] Esto nunca sucedió y Volkerding declaró oficialmente que el proyecto estaba muerto en julio de 2021. [52]
Slackware 14.2 [125] Los conjuntos de CD, los DVD individuales y la mercancía estaban disponibles en la tienda Slackware controlada por terceros, [126] pero debido a un pago insuficiente, Patrick Volkerding "les dijo que lo eliminaran o suspendería el DNS de la tienda". [127] [128] [129] [130] [131] [132] [133]
Las imágenes ISO de Slackware (2,6 GB) [134] para la instalación se pueden descargar de forma gratuita en el sitio web de Slackware a través de BitTorrent , espejos FTP y espejos HTTP. [135]
El puerto de Slackware para IBM S/390 ( EOL : 2009) [136] se puede descargar e instalar desde una partición DOS o desde un disquete. [137]
El puerto de Slackware para la arquitectura ARM [138] se puede descargar [139] e instalar a través de una red, utilizando Das U-Boot y un servidor de arranque TFTP [140] o desde un minisistema de archivos raíz. [141]
Slackware ARM también se puede instalar en una PC que ejecute QEMU [142] utilizando la misma técnica. [143]
Slackware AArch64 (ARM64) se instala directamente desde imágenes de tarjeta SD de manera similar a la instalación de Slackware x86 desde un DVD.
Estas actualizaciones corrigen varios errores y problemas de seguridad. ¡Gracias a jwoithe por la corrección de PCI!
Slackintosh-current no ha recibido ninguna actualización en los últimos 15 meses: es hora de cerrar esta rama y dejarla en mantenimiento para cualquiera que eventualmente se suba al carro.
Hola de nuevo, comunidad, finalmente ha llegado el momento. Realmente disfruto trabajando en el proyecto Slackintosh, pero el período de gracia de un mes ha pasado, por lo que es hora de cerrar incluso la rama -stable.
Slackware comenzó a principios de 1993, pero no fue hasta mediados de 1994 que Michael Johnston de Morse Telecommunications se puso en contacto conmigo y me preguntó si estaba interesado en que publicaran Slackware comercialmente... Desde entonces, Slackware siempre ha ganado suficiente dinero a través de acuerdos de publicación para ser mi trabajo de tiempo completo. No me quedé mucho tiempo con Morse porque solo me daban $1 por copia vendida. Cuando expiró el acuerdo inicial de seis meses, pasé a Walnut Creek CDROM, ya que estaban mejor establecidos y estaban dispuestos a darle a Slackware una parte justa de las ganancias. Su fundador, Robert Bruce, es mi socio actual en Slackware Linux, Inc.
Patrick Volkerding, fundador y dictador benévolo de por vida de la distribución Linux Slackware, publicó una nota en LinuxQuestions.org en la que detalla algunos problemas financieros. Parece que se deben principalmente a un trato que hizo con Slackware Store que salió muy mal... Tenga en cuenta que hay al menos una persona que solicita Bitcoin y que no está afiliada a Volkerding, en lo que parece una estafa de algún tipo; es particularmente triste porque es similar a lo que él alega que sucedió también con Slackware Store.
Volkerding dijo que había descubierto lo mal que estaban las cosas en 2017 cuando logró obtener algunas cifras de las personas que dirigían la tienda. "Pensé que las ventas eran así de malas y estaba bastante deprimido por eso. Otra nota al margen: la propiedad de la porción del 60% de la tienda cambió de manos a mis espaldas. Nadie pensó que fuera necesario informarme sobre esto. En ese momento, diría que las cosas empeoraron considerablemente para mí". La comercialización de Slackware se llevó a cabo inicialmente con Michael Johnston de Morse Telecommunications en 1994. Después de eso, Volkerding se trasladó a una empresa con el fundador de Walnut Creek CDROM, Robert Bruce. Más tarde, Volkerding se asoció con Bruce para crear una empresa de Slackware. iTWire ha escrito a la tienda Slackware buscando comentarios sobre las afirmaciones de Volkerding.
Bienvenido al proyecto de documentación de Slackware