Portada
mis comunidades
otras secciones
#13:
#11 Ya lo han anunciado, de los mismos creadores de CentOS: https://news.itsfoss.com/rocky-linux-announcement/ Un nuevo fork de Red Hat que seguirá la filosofía original de CentOS.
#5:
El problema es el mismo desde hace décadas, y se ha acentuado por el interés de algunos por 'aprovechar' (monetarizar se dice ahora) el trabajo de los demás. La confusión (interesada, creo yo) entre software libre, abierto, gratis, y 'creative' se mezcla con la razón por la cual cada uno se acerca a este tipo de software.
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 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".
Comentarios
El problema es el mismo desde hace décadas, y se ha acentuado por el interés de algunos por 'aprovechar' (monetarizar se dice ahora) el trabajo de los demás. La confusión (interesada, creo yo) entre software libre, abierto, gratis, y 'creative' se mezcla con la razón por la cual cada uno se acerca a este tipo de software.
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".
#5 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
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:
https://www.debian.org/News/1998/19981008
#3 Grub2 no.
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.
#4 Y estando lilo descontinuado, ¿Harán desarrollo propio?
Pd: el otro día hice una prueba y cambiando lilo por grub2 arrancaba más rápido.
#6 No está descontinuado.
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.
#6 #7 El que me parece que está algo retirado es ELILO, el LILO que soporta EFI.
#4 Consolekit2 sirve también para los BSDs, elogind es sólo para Linux.
#4 Además:
- Plasma5 y Xfce 4.14.
- Desaparece Wicd y se sustituye por NetworkManager
- Y por fin Postfix por defecto, en lugar del venerable Sendmail.
#33 > - Desaparece Wicd y se sustituye por NetworkManager
Esa me ha dolido, pero probablemente me escriba mi propio gestor de wireless.
#47 Del Changelog del día Sat Aug 1 19:08:49 UTC 2020:
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.
#55 No creo, deprecarán Python2 y adiós.
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.
#56 Tiene que quedar poco para la 15. Con el último merge de ktown a vtown se supone que en breve, yo espero que hacia el verano.
#55 https://slackbuilds.org/repository/14.2/network/connman/
#55 Patrick siempre tiene razón
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).
#59 No tenía ni idea de que hubieran discontinuado Salix, una pena. A lo mejor revive cuando salga slackware15.
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 trabajo pasé a Debian y es lo que dices, se acostumbra uno a lo fácil.... Tanto que a día de hoy sigo con Devuan en mi portátil, servidores y ordenadores de mi familia.
Cuando salga Slackware 15 veré si vuelvo a ella de alguna forma. Por ahora 14.2 es inviable y current es demasiado inestable para mi gusto.
#60 Gnome Dropline! eso pasó cuando Patrick se cansó de los vaivenes de Gnome y decidió no incluir Gnome como opción en la Slackware oficial.
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: WindowMaker, IceWM, y Enlightenment e16 (que fue el manejador de ventanas de Gnome durante un tiempo a finales de los 90!)
Aparte de Salix OS mantenía la compatibilidad con la rama stable de Slackware y mantenía muy bien la actualización de codecs y algunos paquetes como gslapt/slapt (los más parecido a apt para Slackware).
He usado SalixOS durante años... pero hace un año, no tenía ganas de compilar el kernel para añadir soporte para teléfonos móviles (USB y bluetooth para usarlos como PA como para intercambio de archivos) y como no quería distribuciones con Systend (probé Devuan) instalé antiX y Void en el mismo portátil
Cuando se libere una Slackware nueva, la probaré y si sigue siendo KISS... volveré a los orígenes!
#47 A mi me gusta el que desarrollaron Intel/Nokia para Mer OS y que sigue usando Jolla en Sailfish OS, se llama ConnMan.
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.
#12 entonces debo leer noticias de un universo paralelo donde Oracle demandó a Google por el uso que este último hizo de Java en Android. Que raro si es 100% libre según usted.
#17 Sí, en el universo paralelo de vd., Oracle habrá demandado a alguien por usar Java. Pero en nuestro planeta, lo que ocurrió fue que se demandó a Google por realizar una implementación de Java que no es compatible con el estándar, y seguir llamándole Java.
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 a bien enjaulada con cuidador psicópata, está condenada. Caso de Java y Oracle.
Tecnología domesticada y llevada a la libertad semi-vigilada, gran futuro. Caso de C# y Microsoft.
#c-1" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3424506/order/1">#1 ¿Microsoft? No será libertad de código salvo porque ahora se le antoja trabajar con este para no quedarse apartada. Y C# para quien adore a esa compañía, porque pienso que hay alternativas que no requieran Visuals ni Net ni nada del estilo.
El código libre ha venido para quedarse, y las grandes compañías harán todo lo posible para sacar provecho.
#c-9" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3424506/order/9">#9 Puedes editar c# con vi. No necesitas vs.
Y no es más dependiente de .net que java de la jvm.
#1 ¿Y cómo encaja tu película con que haya sido con Oracle cuando Java se hizo 100% software libre? No, no "semi-viligado" ni tonterías, sino 100% libre, GPL.
#12 yo ya paso de argumentar con los que se meten con Java sin conocimiento. Como los que dicen que es lento por ver aplicaciones de escritorio pesadas...
#15 Java es lento. Decir lo contrario es un caso claro de campo de distorsión de la realidad.
#21 ¿alguna fuente fiable? ¿es lento comparado con qué? lo tienes que comparar con lenguajes que tengan el mismo propósito, no lo puedes comparar con ensamblador
#23 No merece la pena, de verdad. La informacion sobre el performance de las jvm contra otros lenguajes de diferentes tipos esta al acceso de cualquiera. para que van a leer si pueden escupir falacias sin mas? Si acaso buscan hasta encontrar un par de articulos que les interese y pasan a la siguiente falacia. En cuanto se les deja claro la situacion desaparecen. Ni un minuto mas voy a perder respondiendo falacias.
#27 sin ser un experto entiendo que un programa que no tenga que ser interpretado por la maquina virtual debería ser más rápido que uno que si, no?
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?
#38 No ser lento tampoco quiere decir ser mas rapido que c++. La jvm tiene diferentes mecanismos para optimizar el proceso (JIT lleva en hotspot como 15 anyos...).
A un lenguaje no se le puede asignar un valor absoluto de rendimiento ya que este depende de multiples factores.
#41 que otros lenguajes podríamos comparar con java a nivel de rendimiento? entiendo que mi comparación con c++ no fuera la más adecuada pero aún así nunca he considerado java como un lenguaje pensado para obtener altos rendimientos sino pensado en la portabilidad entre diferentes sistemas sin necesidad de compilar para cada uno y por eso pensaba que en general era un lenguaje algo pesado
#c-42" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/3424506/order/42">#42 Yo lo que piloto es java , tampoco puedo darte un ranking incluyendo otras plataformas. Me imagino que sera mas rapido que cualquier lenguaje puramente interpretado, pero como digo al final depende mucho del escenario.
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 eficiente producir codigo mantenible y rocoso que codigo veloz. Esto llega a tal punto que muchos ingenieros en lugar de programar para optimizar crean abstracciones absurdamente complicadas que enlentecen la ejecucion voluntariamente .
Si eres un ingeniero de software en banca el 95% de tu trabajo es ligero en terminos de rendimiento. Cuando estas ante un algoritmo que se va a usar masivamente y es complicado es cuando realmente tienes que preocuparte.
#43 Muchas gracias por la explicación, yo es que tb soy desarrollador de lenguajes basados en la jvm (groovy ahora mismo) pero en realidad no tengo mucha idea de temas de rendimientos y me pareció interesante lo que comentabas
#44 supongo que como programador podras ver que la calidad de una aplicacion no se mide en los milisegundos que tarda en procesar una request (siempre y cuando no sean demasiados, en este caso pasaria a ser el centro de todos tus problemas )
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.
#45 está claro que a la hora de desarrollar hay que poner muchas cosas en la balanza y sobre todo pensar en para que se está programando, no es lo mismo el rendimiento que necesita una web que un sistema de renderizado de vídeo.
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
#38 Las aplicaciones Java (o de cualquier otra máquina virtual), aunque sea código "interpretado" por la misma, no significa que no pueda emitir código nativo. De hecho, esto es lo que hace la JVM, traducir aquellas partes de código que más se usan en una aplicación a código nativo, por lo que el rendimiento es bastante alto. Y además, puede hacerlo aplicando todas las optimizaciones posibles para el procesador en el que se ejecuta. Que no es siempre el caso de una aplicación (C o C++) que se compila, por ejemplo, para una arquitectura, pero no para un procesador concreto.
#49 pero por el hecho de estar pasando por la JVM para "interpretar" ese código entiendo que siempre será menos rápido que si no tiene que pasar por ahí, no?
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
#52 pero por el hecho de estar pasando por la JVM para "interpretar" ese código entiendo que siempre será menos rápido que si no tiene que pasar por ahí, no?
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 días) seguidos, por lo que una vez pasada esa primera etapa, ya funciona con un rendimiento muy similar a nativo, cuando no mejor.
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í, pero además hay una diferencia y es que tú puedes tener una aplicación C++ compilada hace 10 años, que no hará uso de las últimas características de tu nuevo procesador de 2020. Pero puedes tener un programa Java de hace 20, que sin recompilarlo ni nada, ejecutándolo en la última JVM, sí puede hacer uso de esas características modernas de tu procesador, pues la máquina virtual es capaz de emitir código nativo adaptado a procesadores modernos que ni siquiera existían cuando se desarrolló tu programa original.
#23 Lento comparado con otros lenguajes que no sean interpretados ni ejecutados en máquina virtual.
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 orígenes, pero por los factores antes mencionados una aplicación hecha en Java nunca va a ser tan rápida como la misma en un lenguaje compilado.
#27 (Y normalmente para los benchmarks se usa código especialmente pensado para los mismos. Cuando comparas aplicaciones reales la cosa cambia bastante.)
#15 A mi pe parece un gran lenguaje con un entorno de mierda. Todo se hace super recargado, los programas que gestionan los proyectos se me acaban haciendo más complicados que los proyectos en sí. Como quieras dejarlo simple y no depender de un ide todo es super farragoso, el otro día no veas la que lié para añadir simbolos de depuración a una construcción con ant...
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.
#18 Hay una gran diferencia. El Libreoffice colaboran muchos de los grandes, por lo que tienes músculo para hacer cosas. Falta por ver quien colaborará con CentosFork, porque quedarse sin el apoyo de Red Hat va a doler, y convertirte en otra Fedora no creo que ilusione a nadie.
A convertir CentOS en caso de Debian Testing.
#2 ¿Por cierto cuáles serán los cambios de la futura Slackware?
Supongo que grub2 fijo pero SystemD ni de coña.
#2 de hecho, parece mas debian unstable (por lo que leí)
https://news.itsfoss.com/rocky-linux-announcement/
No entiendo por qué se quejan. Uno de las cosas en la que más insistían los talibanes del SL era en que cualquiera podía modificar y mejorar el software. ¿Por que coño no lo hacen y dejan de llorar?
#11 Ya lo han anunciado, de los mismos creadores de CentOS: https://news.itsfoss.com/rocky-linux-announcement/ Un nuevo fork de Red Hat que seguirá la filosofía original de CentOS.
#13 Esto ya sucedió con los desarrolladores de OpenOffice hacia LibreOffice. Veremos si se repite la historia.
#11
Para que gente como tú pueda decir tonterías.
#14 ... y gente como tú pueda leerlas.
#11 Eres un poco troll y las explicaciones te la traen al pairo pero bueno, ahí van.
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 nos las vemos y deseamos para mantenerlos lo más aislados posibles.
Esto de hecho es un tiro en el pie a Red Hat, nosotros usamos Debian, pero en otras empresas se usaba CentOS como banco de pruebas y para servicios menores y Red Hat para aquellos que necesitan soporte en aquellas máquina criticas. Ahora tener que usar Red Hat incluso para pruebas es algo que muchas empresas pequeñas no se podrán permitir y muchas de esas pequeñas pasarán a ser grandes que tampoco usarán RedHat.
Eso sin contar con que no puedes usar redhat como contenedor, podías usar centos, pero ahora ni eso.
#29 sin ir más lejos en mi empresa se migraron todos los servidores a CentOS hará cosa de año y medio y no creo que a los sysadmin les haga ni puta gracia la noticia
#11 ¿Quién "coño" llora? Centos era un proyecto de la comunidad hace hasta bien poco. No dudes que lo volverá a ser.
#34 Después de SLC6 pasó a usarse CERN CentOS 7, y desde hace un año todo se estaba migrando a CentOS 8, el rebuild de RHEL.
Como dato, CERN tiene 44000 máquinas CentOS.
No sé si es muy conocido, pero centos es la distribución standard en la industria de efectos y vfx. Antes era redhat, y se pasó a centos. En los grandes estudios, grandes estructuras, se suele trabajar en linux. Con excepciones, ya que hay nichos que no lo cubren (por ejemplo adobe) , pero vamos, las granjas de estaciones son mayoritariamente linux, y donde dices linux, es 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 no obligar a la gente a pagar una suscripción por unos servicios que en realidad este nicho no usa. Podría ser Fedora, pero dado que en determinadas versiones vienen cosas de testeo, no sé si es lo que se convendría. Otro tema es el de systemd, ya que a raiz de centos 7, muchos programas que usan servicios , tuvieron que migrar a systemd. Yo eso lo ví en primera persona. Y sería un cachondeo volver atrás ahora.
Me pregunto que distro basada en rpm y systemd podría tomar el relevo.
#32 Queda Scientific linux y alguna otra basada en Red Hat y se me ocurre que muchas pueden migrar a openSuSE.
#32 Oracle Linux tiene compatibilidad 100% a nivel de binario. Y no hace falta suscripción para utilizarla
#39 oracle ni en pintura
Les cortaron las alas. Descripción gráfica
Polvorín en Fermilab y CERN
#24 Uuf todos esos servidores que habían migrado a Centos 8... Si fuera ellos ponía el LHC en modo overkill y lo enchufaba a la sede de IBM...
#24 ¿No usaban otro fork, https://scientificlinux.org ?
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
Después de años leyendo menéame en silencio he regresado para decir:
Larga vida a GNU/Linux debian