Rodrigo Carlos E Linfati Medina wrote:
>a mi me paso algo similar con una intel 865perl ( audio snd-intel8x0 )
>se arreglo haciendo un update a el kernel o parcharlo con un alsa mas
>nuevo.....
>
>
>
>
>
mismo caso pero tuve que sacar de blacklist que tiene el dicover a la
tarjeta de sonido y agregar obviamente el usuario al grupo audio, digo
obvio porque hay que hacerlo pero a veces se olvida, en si a mi se me
olvido y perdi media hora buscando como hacer sonar el bicho este :)
saludos
From [EMAIL PROTECTED] Mon Apr 25 14:26:39 2005
From: [EMAIL PROTECTED] (Horst von Brand)
Date: Mon Apr 25 14:26:42 2005
Subject: SCM: Linus Torvalds (Linux),
Larry McVoy (BitKeeper) and Andrew Tridgell (Samba, rsync, etc.)
In-Reply-To: Your message of "Mon, 25 Apr 2005 11:58:14 -0400."
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
"Marcos Ramirez A." <[EMAIL PROTECTED]> dijo:
> On Fri, 2005-04-22 at 22:11 -0400, Horst von Brand wrote:
> > No dije que fuera falso, solo que todo indica que es una fraccion (me late
> > muy menor) de la situacion.
> Algo de logica elemental: Si un argumento dice "solo use telnet" (AT) y
> el otro dice "fue usando telnet + el cliente BK" (HvB) estamos frente a
> un caso en que es _imposible_ (se contradicen) que ambas sean ciertas a
> la vez, por ende, a lo menos una /debe/ ser falsa.
Dije que "uso bk", no que haya usado un /cliente/ bk. Acceder al servidor
es "uso", cierto?
> > > o lo que dice HvB es falso.
> > Te aseguro que eso es lo que creo.
> creer algo no lo hace cierto. Para el caso, tampoco falso, por eso se
> necesita algun tipo de demostracion.
Indique porque me parecia poco plausible la "confesion" de AT.
> > > > Si haces eso contra un servidor bk,
> > > > [...] resto de la teoria borrada
>
> > > Interesante teoria. Cuando pueda probarla sin lugar a dudas presentela
> > > de nuevo.
>
> > Es absolutamente necesario acusar de esta forma?!
> Hasta el momento toda su argumentacion se ha basado en creencias
> personales, suposiciones, conjeturas y alguna que otra descalificacion y
> ataque personal (cito "La gota que rebalso el vaso fue un *imbecil* se
> puso a trabajar en ingenieria reversa de bk").
Sigo pensando lo mismo. Hubo una manga de imbeciles que se pusieron a
trabajar en esto, poniendo en claro riesgo el permiso de uso de la
herramienta. Tales actividades eran a todas luces ilegales, dado que
ingenieria reversa esta legalmente permitida solo en caso que no hayan
otros mecanismos de interactuar con el sistema (y BitMover dio toda clace
de facilidades al respecto). Notese que la situacion de SMB es /bien/
diferente al respecto, y alli la ingenieria reversa /si/ era legal (porque
de no, ya se estarian secando en la carcel, Hasefroch mediante).
Y, finalmente, si alguien dice desarrollar software bajo altos estandares
de toda clase, incluso como imperativo etico, me parece totalmente
inconsecuente darse la vuelta y condonar actividades ilegales "porque asi
es mas conveniente/libre/cool".
> > > > Un discreto "telnet servidor 5000" no da tiempo para "gestiones" de
> > > > ninguna clase...
> > > Hum ... prohibiremos el telnet ahora?
> > Quien habla de prohibir? Solo que si hoy haces "telnet mitarro algunport"
> > seguramente no llegare directamente al punto de iniciar gestiones para
> > parar esa actividad.
> Y porque habria de pararlo?! Si tiene un servicio disponible para que
> _cualquiera_ acceda a el, eso es lo minimo que puede pasar. Puedo usar
> el medio que quiera y no tengo ninguna obligacion de usar las
> herramientas que a la persona que puso el servicio le gustaria que
> usara.
Precisamente por esa razon es que creo que la explicacion de "simple
telnet" es un cuento.
Ver p.ej.
<http://www.theregister.co.uk/2005/04/22/tridgell_releases_sourcepuller/>
(AT anuncia un cliente bk, desarrollado /usando conexiones al servidor/),
comentarios sobre todo el proceso que llevo a la decision de LMcV en
<http://kerneltrap.org/node/4966>, hubo conversaciones que duraron 5
samanas (!) llegando al acuerdo verbal que la actividad terminaria, cosa
que no ocurrio (el analisis de LMcV en ese articulo es bastante iluminador,
"la comunidad" quedo como un ente no confiable), otra vision de lo mismo en
<http://www.newsforge.com/article.pl?sid=05/04/11/118211>.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
From [EMAIL PROTECTED] Mon Apr 25 14:31:49 2005
From: [EMAIL PROTECTED] (Horst von Brand)
Date: Mon Apr 25 14:31:52 2005
Subject: Resolucion FC4
In-Reply-To: Your message of "Mon, 25 Apr 2005 11:58:13 -0400."
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
"Gabriel Gutierrez" <[EMAIL PROTECTED]> dijo:
> Instale un equipo con FC4 test 1, en el cual anteriormente tenia
> instalado FC3. Durante la instalacion, no tuve ningun problema pero al
> reiniciar el equipo este presento una lentiud impresionte ... pero
> realmente impresionante.
Intenta FC4t2 + updates. Hay tantos cambios que da miedo...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
From [EMAIL PROTECTED] Mon Apr 25 14:35:41 2005
From: [EMAIL PROTECTED] (Horst von Brand)
Date: Mon Apr 25 14:35:44 2005
Subject: links q apuntan a mismo ejecutable
In-Reply-To: Your message of "Mon, 25 Apr 2005 12:59:38 -0400."
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Victor Hugo dos Santos <[EMAIL PROTECTED]> dijo:
> estaba mirando en el sistema y me ha venido una curiosidad...
>
> en la carpeta /usr/bin (para dar un ejemplo) existe:
>
> [EMAIL PROTECTED]:/usr/bin $ ll vim*
> -rwxr-xr-x 1 root root 1041656 2005-04-03 07:56 vim
> lrwxrwxrwx 1 root root 3 2005-04-04 12:13 vimdiff -> vim
> -rwxr-xr-x 1 root root 1600 2005-04-03 07:56 vimtutor
>
> o sea, "vimdiff" es un link q apunta para "vim"... mas al momento de
> ejecutarlos "./vim" y "./vimdiff" estés cargan a "vim" con parámetros
> distintos (al menos esto creo)... ahora la pregunta es:
Alte trucke. Popular en sendmail y otros. Hasta bash lo hace.
El programa mira argv[0], y con eso sabe con que personalidad debe
ejecutarse.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
From [EMAIL PROTECTED] Mon Apr 25 14:42:13 2005
From: [EMAIL PROTECTED] (Leonardo Soto M)
Date: Mon Apr 25 15:13:21 2005
Subject: links q apuntan a mismo ejecutable
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
El lun, 25-04-2005 a las 12:59 -0400, Victor Hugo dos Santos escribió:
> hola,
>
> estaba mirando en el sistema y me ha venido una curiosidad...
>
> en la carpeta /usr/bin (para dar un ejemplo) existe:
>
> [EMAIL PROTECTED]:/usr/bin $ ll vim*
> -rwxr-xr-x 1 root root 1041656 2005-04-03 07:56 vim
> lrwxrwxrwx 1 root root 3 2005-04-04 12:13 vimdiff -> vim
> -rwxr-xr-x 1 root root 1600 2005-04-03 07:56 vimtutor
>
> o sea, "vimdiff" es un link q apunta para "vim"... mas al momento de
> ejecutarlos "./vim" y "./vimdiff" estés cargan a "vim" con parámetros
> distintos (al menos esto creo)... ahora la pregunta es:
>
> - esta es una característica del link en si (no lo creo mucho) ??
> - es el programa vim q averigua cual es el nombre del ejecutable (en
> este caso link) y pasa los parámetros de acuerdo a esto ???
Mas bien el propio binario (vim) averigua que es argv[0] (el nombre de
lo ejecutado) y actua en consecuencia.
--
Leonardo Soto M.
Desarrollador de Software | Administrador de Sistemas
<[EMAIL PROTECTED]> | <[EMAIL PROTECTED]>
http://www.eltallervirtual.cl/blogs/index.php/leo
