Re: OT: devuan
2014-12-03 10:29 GMT+01:00 ZorroPlateado <i32lelor.debian@gmail.com>:
>
>> El 29/11/2014, a las 21:47, unciegobailando <unciegobailando@mail.com> escribió:
>>
>> El 29/11/14 a las 17:37, unciegobailando escibió:
>>> El 29/11/14 a las 16:10, Felix Perez escibió:
>>>> El día 29 de noviembre de 2014, 3:41, unciegobailando
>>>> <unciegobailando@mail.com> escribió:
>>>>> El 28/11/14 a las 19:02, Ricardo Delgado escibió:
>>>>>>
>>>>>> Al parecer un grupo se propone realizar un fork
>>>>>>
>>>>>> https://devuan.org/
>>>>>>
>>>>>> Slds
>>>>>>
>>>>>
>>>>> ...aun no hay nada, ni imagen, ni repositorios... eso si, ya estan
>>>>> pidiendo
>>>>> donaciones! jiji..
>>>>>
>>>>
>>>> Y esto:
>>>> https://github.com/devuan/devuan-baseconf/blob/master/data/etc/apt/sources.list.d/devuan.list
>>>>
>>>>
>>>> No lo he revisado, pero creo que para partir ya es algo.
>>>>
>>>>
>>>
>>> estuve estudiando el asunto un rato, y pude enterarme que por suerte el
>>> "fork" parece ser solo dirigido con el cometido de realizar una imagen
>>> minima del sistema debian sin dependencias de systemd y compitible con
>>> la paqueteria ya compilada en los repositorios oficiales. Si utilizaran
>>> openrc, upstart o sysvinit, aun no se sabe.
>>> Gracias a las "arduas" discuciones y plateamientos surgidos en esta
>>> lista pude entender que esto es algo *muy necesario* para
>>> administradores y sistemas que operen como servidores.
>>> El usuario final de escritorio, entre los que me incluyo, actualmente
>>> no tiene problemas tecnicos o de rendimiento con systemd.
>>> Aunque personalmente, lo este usando en un debian jessie y tambien en
>>> otro sid, no dejo de estar alerta con respecto a su 'agresiva' escalada
>>> en importancia.
>>> Como tantos otros usarios de gnu/linux, tendre que conformarme con lo
>>> que hay y sin colaborar, ya que apenas puedo editar ficheros por aqui y
>>> por alla casi siempre segun alguna guia, y gestionar paquetes desde apt
>>> o aptitude. Hasta alli llega mi genio nomas.
>>> Saludos.
>>>
>>
>> P.D.:
>>
>> No deja de ser por lo menos anectodico (segun pude comprender) que los "cucos" de los actuales sistemas gnu/linux fueron y son:
>>
>> 1-Network-manager
>> 2-SElinux
>> 3-pulseaudio
>> 4-systemd
>>
>> Siendo los ultimos tres desarrollos de Red Hat y encontrando cada uno de ellos en sus lanzamientos e implementaciones fuertes criticas y rechazos (quien no ha tenido algun inconveniente con network-manager o pulseaudio por lo menos?).
>>
>> Creo que es bueno tener presente esto y mantener firme vigilia ante la extraña mano de Redhat.
>> Opino sin paranoias ni especulaciones.
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>> Archive: https://lists.debian.org/547A30FA.4070107@mail.com
>
> Ya lo he dicho por la lista, vete a la documentación de la última Red HELL 7,
> en concreto a como se manejan las interfaces de red ahora en un servidor,
> para fliparlo todo con la cli de network-manager.
Lo dije en un anterior thread. Todas esas caracterísitcas las puedes
desahabilitar en RHEL7 (y sus clones). Absolutamente todas. Lo puedes
hacer y seguir haciéndolo al modo tradicional. RedHat no se va a
"jugar" su modelo enterprise así como así.
Como comenté, la implantación de systemd en sistemas RHEL7 (y
derivados) es la más "descafeinada" de todas. Pero sigue siendo
systemd.
>
> SELinux, todo kiski que no quiera dejarse horas en mantenerlo en paralelo
> con los servicios que lleves lo desactiva en la instalación.
SELinux no tiene nada que ver con systemd. Viene de serie desde las
versiones RHEL5. Es decir, lo puedes deshabilitar o lo puedes
utilizar. Eso dependerá del entorno donde despliegues.
>
> También han metido alguna cambio a lo que se refiere el firewall.
Si, el que utiliza Fedora.
>
> Y claro, ahora meten por defecto XFS como sistema de ficheros porque
> es capaz de gestionar mayores almacenamientos y tal y tal pero que hace
> dos días tenía fallos fundamentales de rendimiento, un sistema que
> pertenecía a IRIX y fue portado otra arquitecturas. Y no lo entiendo
> cuando deberían estar a piñón con btrfs…. que seguro para RedHELL 8
> lo meten por defecto.
Lo de XFS es directamente incierto. Llevo utilizando XFS desde que
RedHat lo declaró como full supported (y de eso ya hace 4 años, si no
me falla la memoria) y cero problemas, en entornos de producción
exigentes ...
Brtfs no será realidad, probablemente, hasta RHEL8 (a nivel de full support).
>
> Y ahora vamos con systemd, los chicos de FeeBSD anuncian algo parecido,
> en Solaris tienen también algo similar para gestión de los servicios.
>
FreeBSD va a hacer un "simulador" para poder instalar GNOME, y solo
para GNOME. Eso sí, si el invento no sale y merma la estabilidad,
GNOME se va al carajo en FreeBSD. El escritorio no es el target de
FreeBSD.
Lo de Solaris, es solo a nivel servicio (se llama SMF) y aunque
contempla algo de logs binarios, ni de lejos es la animalada que han
hecho con systemd ...
Por cierto, para añadir más muescas a la culata de systemd: ahora
también controla containers LXC
(http://www.freedesktop.org/software/systemd/man/machinectl.html) ...
Lo que dije en su momento: destructivo, se mire por donde se mire ...
Reply to: