Desarrollo de apps para Linux

• En Linux de escritorio y móvil hay demanda de nuevo software, pero en las tiendas de apps y repositorios faltan aplicaciones, por lo que el mensaje es enfocarse en desarrollar apps más que nuevas distribuciones
• Incluso una app nacida de una necesidad personal, si se desarrolla de forma abierta, puede convertirse en material de aprendizaje y en una comunidad, lo que puede llevar a la expansión del ecosistema Linux
• La diversidad de cientos de distribuciones es una carga, pero aprovechando sistemas de empaquetado y distribución bien documentados, se pueden entregar apps a usuarios de distintos entornos
• GNOME, KDE Frameworks, elementary OS, Electron y Ubuntu Touch ofrecen distintas rutas de desarrollo con Gtk, Qt, Vala, JavaScript·HTML·CSS y QML, entre otros
• Existen medios de distribución como AppCenter, AppImage, Flatpak, Open Build Service y Snapcraft, además de posibilidades de monetización mediante apps de pago, servicios y tiendas de apps basadas en apoyo económico

---

Por qué Linux necesita más apps

• Los usuarios de Linux de escritorio y móvil tienen demanda de nuevo software
• Las tiendas de apps y repositorios de Linux tienen menos aplicaciones que las plataformas cerradas
• A los entusiastas de la tecnología se les anima a dedicar su pasión y creatividad a nuevas aplicaciones para usuarios de Linux, en lugar de crear más distribuciones Linux
• El mensaje central es: “dejen de crear distribuciones Linux y creen aplicaciones”

El impacto del desarrollo de apps en el ecosistema

• Si tienes una idea para una app que necesitas personalmente, es posible que otros usuarios con necesidades similares también la tengan
• Si desarrollas una aplicación públicamente, incluso desarrolladores más nuevos podrán aprender y empezar, lo que ayuda a la siguiente generación de desarrollo de apps para Linux
• El desarrollo de aplicaciones es un trabajo creativo, y la sensación de logro al completar un proyecto también puede ser una recompensa
• Desarrollar apps ayuda a formar comunidad, y la comunidad Linux a menudo quiere ayudar a que los desarrolladores tengan éxito
• La capacidad de desarrollar software es una habilidad con demanda, y también hay muchos recursos gratuitos para aprender
• La idea de que los usuarios de Linux no apoyan económicamente a los desarrolladores es un malentendido; las apps y servicios de pago populares pueden crear nuevas fuentes de ingresos

Apuntar a distintas distribuciones Linux

• A diferencia de otras plataformas, Linux tiene una enorme variedad de objetivos, con cientos de distribuciones
• Una vez publicada, una aplicación normalmente puede funcionar en varios entornos
• Existen sistemas de empaquetado y distribución bien documentados para que los desarrolladores entreguen sus apps a los usuarios
• Cada framework de desarrollo y distribución Linux tiene rutas recomendadas para llevar apps a los usuarios
• Cuando estés listo para compartir tu app, puedes consultar en la documentación de desarrollo las guías de empaquetado recomendadas

Rutas para empezar a desarrollar

• GNOME

  • El proyecto GNOME crea el escritorio GNOME Shell y ofrece soporte para desarrollo basado en Gjs y Gtk
  • En Gtk se pueden usar lenguajes populares como Python, C, C++, Rust y JavaScript
  • GNOME Developer Center

• KDE Frameworks

  • KDE ofrece el escritorio Plasma y herramientas y frameworks para crear aplicaciones
  • KDE Frameworks se ha usado para desarrollar una amplia variedad de aplicaciones de escritorio
  • Utiliza principalmente el toolkit Qt y el lenguaje de programación C++
  • KDE Frameworks Getting Started

• elementary OS

  • elementary OS busca ser un sistema operativo rápido, abierto y respetuoso de la privacidad como alternativa a Windows y macOS
  • Sus desarrolladores construyen un escritorio y un ecosistema para el desarrollo de apps
  • La guía para desarrolladores recomienda Vala y Gtk
  • elementary OS Developer Guide

• Electron

  • Electron permite crear apps de escritorio multiplataforma con JavaScript, HTML y CSS
  • Los desarrolladores pueden aprovechar la enorme biblioteca de módulos de node para crear apps basadas en tecnologías web
  • Electron Documentation

• Ubuntu Touch

  • Ubuntu Touch es un sistema operativo de código abierto diseñado para funcionar en distintos dispositivos como teléfonos, tablets y PC
  • Las apps nativas de Ubuntu Touch se crean con QML o HTML, y su comportamiento se define con JavaScript, C++, Python, Rust y Go
  • Ubuntu Touch Documentation

Opiniones de desarrolladores sobre el ecosistema de apps Linux

• Neil McGovern, de la GNOME Foundation, considera que para llevar Linux al público se necesita un ecosistema de apps próspero, y que todos deberían poder desarrollar para Linux para acercarse al objetivo de un escritorio abierto
• Aleix Pol, de KDE e.V., dice que para convertir Linux en el sistema operativo que la gente quiera usar, se necesitan grandes apps, y que las herramientas de desarrollo permiten crear lo que uno imagina
• Daniel Foré, fundador de elementary, considera que no solo existe la oportunidad de crear grandes apps para Linux de escritorio, sino también de crear APIs de plataforma e influir en la dirección del escritorio
• Jan Sprinz, integrante de la junta de la UBports Foundation, dice que el desarrollo de apps para Linux es completamente distinto al de los ecosistemas cerrados, y que aunque compitan técnicamente, colaboran por una visión más grande

Cómo compartir y distribuir apps

• AppCenter

  • Es una tienda de apps abierta con modelo pay-what-you-want y también un servicio de compilación para desarrolladores independientes
  • AppCenter Dashboard se integra con GitHub y ofrece soporte para lanzamientos y seguimiento de issues
  • AppCenter Dashboard

• AppImage

  • Las aplicaciones de escritorio Linux pueden distribuirse en formato AppImage para llegar a usuarios de distribuciones Linux comunes
  • Promueve el enfoque de empaquetar una vez y ejecutar en cualquier lugar
  • AppImage Packaging Guide

• Flatpak

  • Es un framework para distribuir aplicaciones de escritorio en Linux
  • Fue creado por desarrolladores con muchos años de trabajo en el escritorio Linux y se opera como un proyecto independiente de código abierto
  • Flatpak Documentation

• Open Build Service

  • openSUSE Build Service es la instancia pública de Open Build Service
  • Se usa junto con el desarrollo de la distribución openSUSE y para ofrecer paquetes para varias distribuciones como Fedora, Debian, Ubuntu y SUSE Linux Enterprise a partir del mismo código fuente
  • openSUSE Build Service Help

• Snapcraft

  • Snapcraft es una herramienta de línea de comandos para crear snaps
  • Los snaps se presentan como paquetes de apps para escritorio, nube e IoT que son fáciles de instalar, seguros, multiplataforma y sin dependencias
  • Snapcraft Documentation

[GN⁺]

Opiniones de Hacker News

• Creo que la premisa está equivocada en el sentido de que Linux todavía no tiene un conjunto de frameworks centrales con ABI estable
  Las plataformas competidoras tienen muchos más frameworks básicos como CoreImage, CoreAudio, CodeML, SceneKit y AppKit, y se rompen con menos frecuencia
  snap o flatpak en Linux también son interesantes, pero se parecen más a una forma de esquivar el problema con infraestructura y gestión de paquetes, en lugar de resolverlo en los propios frameworks y lenguajes de programación que les piden a las apps usar

  • La comunidad entusiasta de Linux suele oponerse activamente a esa dirección. Porque quiere que todo sea modular y se ensamble según una aplicación específica
    En Linux también hay conjuntos que son estándares de facto, pero cambian y se deprecian, así que son menos estables. Aun así, es mejor de lo que parece desde afuera, y con Snaps se pueden mitigar algunos problemas
    Pero si la gente elige una distribución que no tiene esos estándares, en el momento en que no soportas todo tipo de configuraciones raras pierdes a la mitad de los usuarios potenciales
  • Alguna vez leí en algún lado que hoy el objetivo más estable en Linux es Win32 vía Wine o Proton
  • Se suponía que el núcleo de eso eran los frameworks de GNOME o KDE y los estándares de FreeDesktop; al menos ese era el plan hace 20 años
    Pero, como dice el artículo, la mayoría sigue enfocada en crear distribuciones, y naturalmente es difícil que surja un único stack que pueda seguirles el ritmo a todas esas distribuciones peculiares
    Al final, Google tomó el kernel de Linux y le puso encima dos conjuntos de frameworks centrales basados en Java y JavaScript, y para el consumidor general esas distribuciones de Linux terminaron siendo las ganadoras
  • Creo que la responsabilidad principal recae en los desarrolladores de glibc. Cosas como el abuso de nombres de versión y la reciente incorporación de nuevos tipos de reubicación ELF hacen que distribuir binarios de juegos entre varias distribuciones sea doloroso
    Normalmente, un desarrollador de juegos compila en una distribución grande y reciente y lo sube a Steam, pero si esa distribución tiene glibc 2.36, muchas veces el binario termina con nombres de versión que exigen glibc 2.36 o superior
    Al final hay que usar la directiva symver de binutils gas para forzar nombres de versión compatibles con una glibc lo suficientemente antigua. Personalmente, considero razonable apuntar a unos 5 años, quizá 7 u 8: https://sourceware.org/glibc/wiki/Glibc%20Timeline
    El desarrollador de juegos promedio casi no conoce estos problemas, y aunque los conozca no va a hacer un trabajo tan doloroso por el 1% del mercado. En el caso de libgcc y C++, también hay que enlazar estáticamente libstdc++ para evitar ese problema de ABI
    Aun así, el motor Godot ofrece contenedores de build que tienen en cuenta estos puntos, y Unity también parece bastante prolijo en ese aspecto. No estoy seguro de UT5.x
    En cambio, hay motores que no están preparados, como los juegos basados en Electron. Si no hay una versión de GTK+ adecuada para distribuciones como Enlightenment, Qt, X11 puro o Wayland, puede que no se ejecuten
    Tampoco es fácil empaquetar correctamente todo el motor Google Blink para distribución binaria apuntando a una amplia variedad de distribuciones ELF/Linux
    ELF/Linux es hostil a la distribución solo binaria por la ruptura general de ABI, especialmente en los SDK y las bibliotecas centrales
    Si los binarios de juegos ya son así de difíciles, las apps lo serán aún más. Veo a los desarrolladores terminando por decir: “no me importa, instalen y usen solo Microsoft SUSE GNU/Linux; no damos soporte para lo demás”
  • Si Linux tuviera la amplitud de frameworks que ofrece macOS, hace rato habría hecho mis proyectos personales apuntando a Linux
    Es impresionante tener tantas herramientas que puedes usar de inmediato sin preocuparte casi por el periodo de soporte, qué fork conviene más o si encajan bien con otras bibliotecas de terceros. Reduce mucho la fricción y te deja simplemente construir
    El ecosistema de KDE Qt y el lado de GNOME/GTK son lo más cercano, pero todavía no llegan a ese nivel

• Puede que no conozca el patrón para decidir cuándo agregar dev y version en el nombre de un paquete, o qué significan los 1 o 0 arbitrarios al final, pero creo que la primera distribución de Linux que tenga reglas consistentes para los nombres de paquetes se va a ganar a la gente
  libgnutls-dev
libgtk-3-0
libwayland-server0
libxcb1
libx11-6
libffi-dev
libncurses5-dev

  • -dev es bastante fácil, porque contiene los headers
    Los números indican la versión cuando se pueden instalar varias versiones al mismo tiempo. Aunque puede haber excepciones, como xcb1, donde forma parte del nombre de la biblioteca
    Por ejemplo, en algún momento probablemente se podían instalar libgtk-3-0 y libgtk-2-$something al mismo tiempo. Es muy posible que hayan dejado el nombre para que, al eliminar después libgtk-2, no se rompieran las referencias a libgtk-3-0 en tutoriales existentes
    El 0 al final de libwayland-server0 tampoco lo entiendo bien. Veo que en /var/lib la misma biblioteca aparece con varios sufijos .$number, pero nunca investigué exactamente qué problema resuelve eso
  • Separar binarios y código fuente es una convención de Debian. Si solo vas a usar una biblioteca, alcanza con el paquete que no es -dev; si vas a desarrollar con esa biblioteca, también necesitas el -dev, que instala los headers
    El 1 o 0 del final no tiene nada especial: simplemente forma parte del nombre del paquete o de la versión
  • En Arch y sus distribuciones derivadas, por lo general no existe eso
    Eso sí, -dev se refiere a las cosas que solo hacen falta cuando vas a desarrollar contra esa biblioteca
    Los números son el número de versión mayor, es decir, el número de compatibilidad. Gracias a eso se pueden instalar fácilmente varias versiones mayores de las que dependen distintos paquetes, sin conflictos
  • Si vas a compilar un programa, instala el paquete -dev. Normalmente no deberías preocuparte directamente por paquetes -dev con número; si hacen falta, el paquete sin número debería traerlos como dependencia
    Durante la compilación se registra qué sufijo numérico, es decir, qué versión de ABI, se usó. Debería coincidir con el sufijo .so.N, pero no se busca directamente de esa manera
    Este enfoque permite instalar varias copias incompatibles de una biblioteca y que se use la adecuada. Las distribuciones normalmente limpian las antiguas en cada lanzamiento grande
    Al instalar, deberían usarse automáticamente las dependencias registradas durante la compilación
  • Existe GoboLinux y, desde mi punto de vista, resuelve todo esto sin ser tan complejo como Nix. Pero a nadie le importó

• Este es uno de los mayores problemas que frenan a toda la plataforma Linux. Suele presentarse como una ventaja, pero no lo veo así
  Los desarrolladores destacan la gran cantidad de opciones como una ventaja de Linux, pero para muchos usuarios se convierte en la paradoja de la elección y termina haciéndolos volver a la plataforma que ya usaban
  En macOS y Windows hay menos opciones, pero las opciones disponibles están mucho más pulidas y menos fragmentadas
  Por ejemplo, ¿cuántos gestores de ventanas en mosaico hacen falta? ¿No se podría elegir el mejor gestor de ventanas en mosaico y crear un mejor dock y applets? ¿Y apps y launchers que se integren con el paradigma del gestor de ventanas en mosaico?
  En cambio, muchas veces lo que queda son 10 gestores de ventanas en mosaico y programas de workaround a medias montados encima

  • La gente no analiza exhaustivamente todas las opciones antes de elegir. Mira unos pocos candidatos y elige uno según popularidad o accesibilidad
    Un ecosistema exitoso hace que elegir una opción visible dé un resultado suficientemente bueno
    El aumento de distribuciones Linux en su mayoría son pequeñas diferencias que no reducen una adecuación significativa, y solo lo consideran un problema los poquísimos que ya no tenían dificultad para elegir una distribución
    En cambio, casos como Wayland sí son un problema real, porque de pronto la plomería y el hardware importan, y para elegir una combinación usable hay que conocer algo de la estructura interna
    Tampoco tiene mucho sentido comparar Mac o Windows con Linux. Para el 95% de los consumidores, el sistema operativo es una característica fija de la computadora o una función, no un producto separado
    Si el paquete completo les encaja, pueden comprar una computadora con ese sistema operativo instalado, pero no intentarán instalarlo por separado en su dispositivo Windows o Mac
    Las personas con suficiente conocimiento técnico como para estar satisfechas no se van a confundir demasiado porque aparezcan 3 derivadas más de Ubuntu y 2 derivadas más de Arch
  • Crear gestores de ventanas en mosaico es divertido. Colaborar para crear software no es solo un medio para obtener algún resultado, también es un fin en sí mismo
    Ser desarrollador de código abierto significa poder definir por cuenta propia los objetivos y los medios, y en el desarrollo de software comercial muchas veces no existe esa libertad
    Aparecen asperezas, pero entra en juego el efecto IKEA y al final terminas tomándole cariño
  • Este problema pertenece al ámbito que deben resolver las distribuciones. Quien no quiera muchas opciones puede usar una distribución que tome muchas decisiones por él, no hace falta presionar para eliminar opciones de todo el ecosistema
    Si todos usan el mismo software, se vuelve un ecosistema de monocultivo más vulnerable a ataques. Windows también fue objetivo de tantos virus porque el blanco era grande y consistente
    Si vulnerabas la máquina Windows de un usuario común, podías vulnerar las demás de forma parecida. Apuntar a Linux es mucho más difícil
    Además, es software libre. Si no le estás pagando a alguien para que lo haga, en su mayor parte es trabajo voluntario, y no podemos decirles a los demás en qué deben usar su tiempo de voluntariado
    Si hay tantos grupos y aun así nadie quiere sumarse, también habría que revisar la estructura social dominante. Un punto de partida podría ser eliminar los códigos de conducta que permiten castigar incluso comportamientos fuera del proyecto
  • Creo que hay más launchers y docks que gestores de ventanas en mosaico
    Y tampoco sé bien qué habría que mejorar. Cosas como Ulauncher o Albert son mucho más potentes que lo disponible en otras plataformas, y no sé cómo se podría mejorar más la UI
  • Que haya tantos gestores de ventanas en mosaico como la gente quiera crear

• Es bueno que haya más software. Pero antes de crear algo desde cero, me pregunto si no sería mejor contribuir a algo que ya existe, o elegir un proyecto abandonado o que necesita ajustes para compilarse y ejecutarse en compiladores y hardware modernos.
  También me pregunto si existe en algún lado una base de datos de proyectos inactivos o muertos que valga la pena revivir.

  • Puede que algo ya existente no esté hecho de la forma que tengo como objetivo.
    Otro proyecto puede estar dirigido por alguien con quien es difícil convivir, o tener una comunidad que no acepta propuestas ni parches.
    Los procesos sociales y los bloqueos pueden hacer que se pierda la motivación para contribuir. No todos pueden ser jugadores de equipo optimistas y sin personalidad.
    En mi caso, es mejor empezar desde cero. Porque puedo controlar todas las variables, no tengo que tocar infraestructura social o técnica existente, no tengo que convencer a nadie de que mis ideas son buenas, y no quiero pasar más tiempo en discusiones y debates que en código.
    La experiencia de desarrollo en solitario es mejor. Porque no está atada a la política ni a procesos sociales, y tratar de ser jugador de equipo solo me ha causado sufrimiento.
  • En la mayoría de las áreas hay demasiados intentos de baja calidad, y si ese esfuerzo se concentrara en algunos proyectos principales, podrían salir unas cuantas apps excelentes.
    Colaborar puede parecer una carga y algo difícil, pero al final se trata de producir resultados, y es tiempo mejor invertido que dedicarlo a proyectos que terminarán abandonados.
  • Me pregunto si alguno de los principales repositorios de paquetes de Linux reúne estadísticas que permitan buscar apps muy usadas pero sin mantenimiento o con funciones incompletas.

• Hay muchas quejas de que faltan herramientas para crear apps compatibles con varios sistemas operativos, pero no estoy de acuerdo. Incluso si miramos solo soluciones que no sean Electron, existen opciones.
  Telegram usa Qt para distribuir una app nativa de buen rendimiento en los tres sistemas operativos.
  Flutter compila a código nativo en los tres sistemas operativos y en móviles.
  Kirigami es un framework QtQuick que permite crear apps ejecutables para móviles y escritorio.
  Simplemente hay que crear apps. No hay razón para usar esto como excusa para culpar a Linux.

  • Flutter se comporta de forma ligeramente distinta en cada plataforma, lo que da una experiencia sutilmente mala en todas ellas. Kirigami o Qt Quick tampoco parecen opciones realistas.
    En Windows, macOS y móviles casi no hay comunidad ni proyectos serios. No quiero menospreciar el lado de KDE, pero esa es la realidad.
    La licencia de Qt Quick tampoco es sencilla en iOS, o resulta muy cara si se va por la vía comercial.
    En cambio, grandes empresas invierten en Electron y producen herramientas de nivel producción muy pulidas; además, tiene una comunidad enorme y un ecosistema de librerías, y no es un lenguaje poco familiar como Dart.
    Telegram realmente hace un esfuerzo extra. El cliente es excelente.
  • La app de Telegram basada en Qt también funciona bien en macOS, pero la mayoría de los usuarios de Apple eligen el cliente Swift/Cocoa para macOS e iOS[0].
    [0]: https://github.com/overtake/TelegramSwift

• El problema es que el software OSS ni siquiera suele intentar competir con el mercado
  Quienes usan software OSS dan por hecho que la UX será deficiente, y de hecho muchas veces lo es
  El software propietario común se adapta para mejorar la experiencia del usuario final porque existe el riesgo de que el usuario no pague, pero en OSS normalmente no existe ese riesgo. El código abierto también necesita estar expuesto a riesgos provenientes del usuario final
  Intenté cambiar eso con Notes[1], pero sentí que es difícil vivir solo de publicidad. También probé con pagos por funciones premium como Kanban, pero la app es FOSS por completo, así que cualquiera puede compilarla fácilmente desde el código fuente
  Para mi próxima app[2], pienso pasarla a código cerrado antes del lanzamiento. No puedo asumir el riesgo de que mi esfuerzo no sea recompensado
  Creo que, si puedo cobrar, podré invertir más en apps centradas en la UX para Linux, así que también será beneficioso para la comunidad Linux. Quizá publique algunas partes como código abierto, y tal vez en un futuro lejano lo publique todo
  [1] https://github.com/nuttyartist/notes
  [2] https://www.get-plume.com

  • La intersección entre usuarios de Linux y personas que valoran la libertad es grande. Para mucha gente, una app de notas que no sea de código abierto no es una opción desde el inicio, por el vendor lock-in y los problemas de privacidad
    Por eso, si no haces el programa de código abierto, es muy probable que pierdas más que si lo haces de código abierto y aceptas el riesgo de que algunos no paguen
    Creo que hay mucha más gente dispuesta a pagar por usar código abierto que gente dispuesta a usar software propietario
    Que sea de código abierto no significa que tengas que distribuir el código a todo el mundo; si cobras, podrías dar el código fuente solo a los usuarios de pago. Eso sí, ellos tendrían derechos para modificarlo y redistribuirlo
    Si no te interesa el código abierto, puedes usar Notion o Evernote. Si buscas una app de notas open source moderna, recomiendo Logseq
  • Me parece que estás tomando la decisión correcta. Ganar dinero suficiente para vivir con código abierto es extremadamente difícil, y la escala es varios órdenes de magnitud menor que la de quienes viven del software comercial
  • Entiendo la frustración, pero también hay contraejemplos. No lo digo con intención de menospreciar
    Primero, Notes se ve bastante parecido a Standard Notes. Si hiciste Notes usando OSS copyleft, creo que es difícil quejarse a menos que pagues regalías por el trabajo de otros programadores incluido ahí
    Segundo, probablemente soy un usuario atípico. He usado Linux por más de 20 años, pero no puedo escribir bien ni un script de Bash ni una línea de Perl
    Pero como no sé programar y agradezco el trabajo de otros y la libertad que me da, he gastado mucho más dinero en software de lo que suelen gastar las personas en otras plataformas
    Apoyo a varios proyectos y servicios, como Kaisen y Debian, las utilidades principales de la FSF y Emacs, KDE, Firefox de Mozilla, Betterbird, Syncthing, LaGrange, Joplin, ClipTo, SoulSeek y envs.net
    En algunos pago cada año, en otros cada mes y en otros solo una vez
    Cuando apareció Standard Notes, también pagué una suscripción de 7 años, pero dejé de usarlo después de unos dos meses porque no quedé satisfecho. Hay cosas que uso mucho, como Alacritty, pero para las que no he encontrado cómo donar, y trato de minimizar esos casos
  • Personalmente, creo que KDE está muy por delante de macOS y Windows
    De hecho, siento que macOS tiene uno de los peores gestores de ventanas entre las plataformas populares. Es bonito y fácil de usar, pero si quieres hacer algo más allá de lo básico, necesitas conjuros mágicos que no se descubren de forma natural
    Claro, cada quien tiene sus gustos
  • Tengo algunas ideas. Aunque sigo bastante este ámbito, nunca había oído hablar de esa app, y la competencia es extremadamente intensa
    Hice clic para ver el precio premium y, aunque en términos anuales es razonable, solo vi una opción de suscripción mensual, así que sentí que eso se complica
    En este tipo de apps, es más probable que done a que pague por una versión premium. A Obsidian le funcionó bien ese modelo
    No creo que el acceso anticipado a funciones tenga mucho valor, pero mucha gente pagó para apoyar el trabajo
    También creo que una estructura con un gran ecosistema open source alrededor de un producto central cerrado les da a las personas una razón para pagar

• Habría estado bien que el artículo incluyera algunos ejemplos
  No se me ocurre fácilmente alguien que esté creando una distribución cuando en realidad debería estar creando una aplicación. Forzándolo un poco, ¿quizá LinuxCNC? Pero eso tiene requisitos específicos de kernel, así que quizá una distribución personalizada tenga más sentido

  • Un entorno de escritorio es, en la práctica, una aplicación que se puede instalar fácilmente con uno o dos clics o comandos
    No entiendo muy bien que una distribución derivada de otra derivada se distribuya solo por incluir un entorno de escritorio distinto

• Más que “dejen de hacer distribuciones Linux y hagan aplicaciones”, creo que es mejor dejar de escuchar a quienes quieren decirte qué debes y no debes hacer

  • A mí también me molestó ese tono
    Aun así, el mensaje y la información en sí son buenos
    Personalmente, lo habría dicho como “los usuarios de Linux no quieren más distribuciones; quieren software”. Al menos yo sí
  • También hay que dejar de escuchar a quienes dicen que dejes de escuchar a quienes quieren decirte qué debes y no debes hacer. No todo es relativo; hay buenas y malas decisiones

• Hace poco me pasé de Mac a Linux, porque quería usar un equipo usado de buen rendimiento como máquina de uso diario.
  Antes ya había instalado Linux en varias máquinas, pero esta vez no es solo un hobby.
  Ubuntu da buen soporte a mi hardware y periféricos, pero la tienda de apps se siente incompleta y metida a la fuerza. Aun así, casi todo funciona como esperaba.
  Quisiera probar también Mint, Debian y Arch, pero me da cautela porque parece que mucho software está escrito pensando en Ubuntu.

  • Linux Mint está basado en Ubuntu, así que puede usar paquetes de Ubuntu sin problemas. De hecho, se puede ver prácticamente como un Ubuntu mejor.
    También existe una versión de Mint basada en Debian, pero eso es más bien una medida de seguridad para no depender críticamente de Ubuntu.
    Hoy en día, aunque uses una distribución poco común, no suele haber grandes problemas. Si el gestor de paquetes predeterminado no ofrece la app que quieres, puedes usar AppImage, Flatpak o Snap.
  • De lo escrito para Ubuntu, casi no hay nada que no vaya a correr en Arch o en la mayoría de las distribuciones modernas.
    Cuando usaba Arch, tuve que acostumbrarme a las suposiciones que la gente hace tomando Ubuntu como referencia, pero en la mayoría de los casos solo era cuestión de parchar archivos de configuración o definir variables de entorno.
    Esas son habilidades útiles y transferibles a otros lugares.
  • También vale la pena probar Fedora al menos una vez.
    Pienso que me habría gustado haberlo probado antes.

• No veo por qué alguien haría eso. Es más difícil, y los usuarios de Linux no pagan por cosas que no valen la pena.

  • Porque al mundo le conviene que haya más software gratuito de calidad.