Kernel nuevo en Woody OffTopic

[Felipe Covarrubias]

On Mon, 07 Feb 2005 02:01:55 -0300, Horst von Brand
<vonbrand en inf.utfsm.cl> wrote:
> > > > "No hay peor ciego que el que no quiere ver"
> > > > Al que le gusta RH/Fedora y cia, obviamente que Debian/Gentoo y
> > > > demas les pareceran arcaicas/complicadas
> > > Entonces ni hablar de Slackware que ni sistema de dependencias tiene =D
> > Para dar más control al usario. Yo prefiero eso.
> 
> Control para simplificar armar un sistema que no hay manera de reproducir,
> y control que permite crear un sistema con dependencias no resueltas (y que
> no funciona, por ende). Eso lo necesito tanto como un hoyo en la cabeza.

no es para tanto ó en su opinion si lo es?

tampoco podemos pensar que por que slackware no tiene sistema de
dependecias sea un sistema que no funciona ...

Leyendo este comentario y el sgte ( de otro tema ): 

>>> > Hola tengo el siguiente problema, en mi gateway tengo
>>> > un script iptables para hacer nat desde mi red, bueno
>>> > en particular:

>Felipe Covarrubias <hooper.007 en gmail.com> dijo:
>> Hola, necesitas agregar ese script para que se corra en el arranque,
>> segun la distribucion que usas es el comando para hacerlo.

>Horst von Brand <vonbrand en inf.utfsm.cl> wrote:
>No! Cuando %&#@* se fijaran si lo que alguien quiere hacer es una operacion
>que debiera ser comun, y por lo tanto una distribucion razonable tendra una
>manera "oficial" de hacerlo, antes de estar proponiendo soluciones parche?!

Pareciera que hvb solo quiero que la gente ocupe distribuciones tipo fedora ...
lo cual me da una repulsion similiar a que si me dijieran TIENES que
usar hasefroch...

Ciertamente esa es la forma en que "Yo" interpreto que llega en el
mensaje de hvb.

sobre lo cual estoy en desacuerdo no solo yo, ya que de ser un
pensamiento generalizado aquel (el de hvb) quiere decir que Toda la
gente que se preocupa de desarrollar
/Debian/Slackware/Gentoo/Archilinux/... etc.  estan todos equivocados
y haciendo cosas imnecesarias. Ya que como existe fedora y a fines,
todas las demas distros que no esten en ese espectro son "no
necesarias" (o tal vez no funcionan, como decia hvb)

Insisto: si fuera por eso hasefroch es Mucho más Automatico que
cualquier redhat entrerprise o a fines, y ademas tiene formas
Oficiales que han evolucionado en convertirse en sistemas de
soluciones excluyentes de otras, es acaso eso lo que busca redhat y
compañia !?, en mi opinion No. Sino que busca proveer interfaces
simples que simplifiquen el acceso y la labor a un administrador
ocupado con mucho trabajo y poco tiempo, lo cual no implica que de
principios el no pueda pensar en utilizar un solucion propia de el
mismo.

El no hacerlo y pensar siempre primero en la solucion oficial, me
parece una aptitud Realmente Poco Necesaria en una persona interesada
en crear, esarrollar, imnovar. para que hablar de Linux entonces, si
ya existian muchos sistemas "oficiales" a esas alturas.--- mejor ni
hablar ya que en sus primeras versiones nisiquiera tenia soporte para
red ( y eso si lo necesita ud. verdad!?).

Pues Yo Tambien, y toda la gente que desarrollo Linux ( hablo en
especifico: Kernel Linux ) tambien lo necesitaba aun en ese momento en
que la internet estaba mucho menos desarrollada que hoy pero les hera
necesario igualmente por diversas razones, y sin embargo no pensaron
que era imnecesario trabajar en el desarrollo de Linux, y lo hicieron
sin pensar que estaban haciendo soluciones parche, ya que para todo lo
que querian Linux existian sistemas oficiales con soluciones oficiales
que ya Funcionaban.
(Finalmente ellos prosperaron :D y aun Hoy siguen prosperando)

Y aun hoy en dia existe mucho hardware sin soporte de ningun tipo
(Ni Oficial, Ni Extra-oficial).

Yo no creo que todos deberiamos hacer las cosas a la manera "oficial"
de que habla hvb, nisiquiera Todos los que ocupan rh/fedora, etc.
deberian hacerlo a la "oficial" si no lo desean. por lo demas la
solucion no es parche, ya que hace uso de la herramienta que el mismo
sistema operativo provee como son las herramientas para agragar
scripts de inicio.
Ojo con todo esto No quiero decir que las soluciones a la oficial sean
malas o no las haya que usar, si pienso que ellas son una buena
referencia para solucionar problemas y muchas veces aplicables, aunque
no en menor medida el usar soluciones oficiales listas "cocinadas"
como por ejm. abrir un entorno de ventana para la configuracion de
"algo" esta ya tiene todas la opciones hechas y PRE_FIJADAS con lo
cual se pierde casi siempre dinamismo en la forma de implementar algo.

finalmente y despues de todo. no puedo dejar de lado la opcion de
hacer las cosas por uno mismo ya sea solo por diversion (como dijo
Linus, cuando publico Linux) o  solo por querer aprender mas y hacer
las cosas de una forma menos automatica,  y digo menos automatica por
que siempre aunque estemos usando una shell y tecleando
comandos+comandos+comandos, estamos usando comandos (valga la
rebundancia) Igualmente ya hechos y prefijados, aunque mucho menos
Prefijados que opciones en ventanas como hasefroch, ó lo que he visto
en ventanas de configuracion de algunas cosas en redhat (y a fines).
creo que los sistemas Linux nos dan a nosotros la posibilidad de Jugar
con el sistema operativo y el hardware y eso se hace a niveles
PRE_FIJADOS de automatizacion muy bajos, tener estas posibilidades es
algo desecha al menos para mi usar "Siempre" "Primero" La "solución"
"Oficial" (tal vez si fuera un administrador de alguna Red, podria
estar más cercano a la postura de usar soluciones oficiales por
simplicidad, pero no por ello, dire que AHÍ que usar la solución
oficial)

Bueno profesor hvb, espero que esta conversacion sea constructiva y no
auto-destructiva, quise hacer notar que Linux no solo se usa para
administrar redes por "tipos que solo quieren que funcione" (que sin
duda que los ahi) y hacer
notar mi opinion hacia la validez de la existencia de distribuciones
"menos" automaticas que redhat o a fines y que no cuentan con
soluciones oficiales tan explicitas y/o rigidas.

Salu2
Xhauuuu.....
atte. Felipe

-- 
Felipe Covarrubias
Estudiante Ingenieria Civil Electrónica
Departamento de Electrónica
Universidad Técnica Federico Santa María