Era inevitable que a medida que las corporaciones adquirieran un rol mayor en el desarrollo de Linux, las prioridades cambiarían. Sobre todo con la llegada de firmas que no vienen del mundo del código abierto. Pasó cuando Oracle compró Sun y sigue pasando ahora que IBM controla al más importante jugador del mundo Linux. No es culpa de las corporaciones si los miembros de las comunidades de proyectos de código abierto creyeron que el aporte de dinero y desarrolladores era por amor a la causa.
|
etiquetas: ibm , centos , redhat , linux 
Me viene a la cabeza la 'polémica' suscitada cuando Debian decidió (acertadamente opino) optar por Gnome porque KDE usaba software de Trolltech (QT) que no cumplía con sus normas, Talibanes en esa época no era un adjetivo menor.
"Free as in beer".
Me acuerdo de aquello. Qt sí cumplía con las normas de Debian. Quien no cumplía con las normas de Debian era KDE por ser GPL y estar enlazado con Qt, que no era compatible con la GPL. Como resultado, KDE no se podía distribuir legalmente. Por aquí lo explican:
www.debian.org/News/1998/19981008
Edit: Según el enlace, Qt no era libre. Posteriormente a ese enlace, Qt sí era libre pero seguía sin ser compatible con la GPL.
SystemD no.
PAM y elogind.
Y están preparando un pack de paquetes en /testing para
hacer un "shim" compatible con Pulseaudio sin tenerlo instalado.
Pd: el otro día hice una prueba y cambiando lilo por grub2 arrancaba más rápido.
Sobre arranque más rápido, LILO tiene la opción "compact".
Y en velocidad da igual, ambos arrancan el initramfs y eso depende del kernel.
- Plasma5 y Xfce 4.14.
- Desaparece Wicd y se sustituye por NetworkManager
- Y por fin Postfix por defecto, en lugar del venerable Sendmail.
Esa me ha dolido, pero probablemente me escriba mi propio gestor de wireless.
extra/wicd/wicd-1.7.4-x86_64-3.txz: Removed.
This is unmaintained, possibly insecure, and doesn't work with Python
versions newer than 2.7.18. NetworkManager is a better choice these days.
Al principio tampoco me gustó porque yo siempre he usado Wicd, pero después pensé que como siempre Pat tiene razón.
De todas formas, si es imprescindible para ti, seguro que existe un slackbuild o puedes hacerlo tu mismo.
Lo del changelog lo tengo asociado a un alias en la terminal con hurl | less, siempre le echo un vistazo para ver cuando puedo pasarme a la v15.
Después de que la gente de SalixOS descontinuase su distribución estoy "evaluando" (alrededor de un año!); dos distribuciones que la sustituyen bastante bien: antiX Linux y Void Linux.
Pero... Slackware es otra cosa y volveré a instalarla en cuanto Patrick la suelte la versión 15.
Después seguro que hecho de menos el XBPS de Void o el apt de antiX... que son mucho más sencillos y flexibles que slackpkg (incluso que aplicaciones como slapt/gslapt).
Slackware fue mi distribución principal en mis años mozos (la usé exclusivamente para todo desde la 9.1 a la 12.2). La llevaba incluso en un macbook con el Gnome de dropline. ¡El firewall del cpd de mi casa era una Slackware ejecutándose en un 486 con 8MB de Ram!
También usé durante un tiempo Zenwalk que era parecida a Salix en cuanto a concepto.
Al final, por necesidades del… » ver todo el comentario
A mi no me gustaba KDE (yo procedo UNIX y comencé a usar Linux con Slackware desde 1994... en mi PC pricipal, aunque también tenía Debian a mano por motivos profesionales), por eso la implementación que hacían la gente de Salix OS con XFCE siempre me resultaba más "natural" (más próximo al CDE de UnixWare). Aunque al principio usé los WM:… » ver todo el comentario
Aunque se desarrolló de forma modular para hardware muy variado (todo tipo de cacharros) algunas distribuciones Linux que no implementan SystemD, lo usan.
Se instala por defecto en distribuciones GNU/linux como antiX Linux; se maneja de forma muy sencilla por medio de comandos, tiene una GUI y es muy estable.
OpenJDK es un proyecto GPL, y si alguien dice que eso no es libre, estaría bien demostrarlo, porque entonces tampoco lo sería el kernel de Linux o muchos otros proyectos que todo el mundo usa a diario.
Tecnología domesticada y llevada a la libertad semi-vigilada, gran futuro. Caso de C# y Microsoft.
El código libre ha venido para quedarse, y las grandes compañías harán todo lo posible para sacar provecho.
Y no es más dependiente de .net que java de la jvm.
por eso siempre he pensado que una app en c++ debería ser por defecto más rápida que la misma en java.
que tipo de lenguajes comparas con la performance de los que corren sobre la jvm?
A un lenguaje no se le puede asignar un valor absoluto de rendimiento ya que este depende de multiples factores.
A groso modo podria decir que esta un pelin mejor que c# y es mucho mas rapido que python (esto si que es claro). No obstante el rendimiento bruto tampoco es tan importante como la gente que no se dedica al software imagina. A nivel de proyecto es muchisimo mas… » ver todo el comentario
Por alguna extrana razon la gente de fuera del mundo del software piensa que los programadores optimizamos centrando en rendimiento cada una de las lineas que producimos. Me temo que es por los gamers-rata que sufren problemas de rendimiento en sus juegos y extrapolan al resto de la industria.
Yo por suerte o por desgracia siempre he desarrollado cosas que no necesitaban que nos fijáramos tanto en el rendimiento como en la mantenibilidad del código y supongo que de ahí vienen mis deficiencias en lo relativo a los rendimientos de los diferentes lenguajes
por ejemplo si pudiéramos compilar java para una maquina concreta como podemos hacer con c++ supongo que sería más rápido que hacerla pasar por la jvm
Sí, siempre será menos rápido porque la máquina virtual debe "calentar" para preparar ese código nativo. Lo que ocurre es que en la clase de sistemas donde Java se usa mucho, como servidores, aplicaciones web, incluso para high-frequency trading, normalmente el programa está funcionando durante muchas horas (o… » ver todo el comentario
Arrancar cualquier aplicación Java implica primero inicializar la máquina virtual, y segundo pasar el bytecode por el intérprete al menos una vez para generar el código máquina necesario. Todo esto ya lo hace más lento que un lenguaje compilado. Y si encima metemos en la ecuación al recolector de basura ya ni te cuento.
Sí, los intérpretes de Java se han optimizado muchísimo con respecto a sus… » ver todo el comentario
En el otro extremo tienes C, que sobre el papel debería ser más farragoso para todo por ser más antiguo y es todo lo contrario, tanto cmake como make son mucho más intuitivos que ant o no digamos gradle.
Supongo que grub2 fijo pero SystemD ni de coña.
Para que gente como tú pueda decir tonterías.
El problema viene de que muchos habían instalado CentOS 8 pensando que iban a tener parches hasta 2028, pero ahora han acortado hasta 2021.
En tema servidores esto es importante porque en muchas empresas hay muchos servidores que están ahí por empleados que se fueron antes de hubiera salido la primera versión de Docker o por efecto de fusión/absorción de otras empresas. En nuestro caso Debian 6 y Centos 6 y… » ver todo el comentario
Como dato, CERN tiene 44000 máquinas CentOS.
La verdad es que no tengo ni idea que puede suponer esto. Se dejó atrás redhat me imagino que por los costes y por… » ver todo el comentario
Larga vida a GNU/Linux debian