Que tiene de malo openca?
en todo yo encontré varios colocando PKI en sourceforge.
Tengo una PKI implementada para tema de correo, web y aplicaciones Java
con alrededor de 1000 certificados.
[EMAIL PROTECTED] escribió el 23/09/2008 11:51:52:
> Hola, con algunos compañeros, estamos tratando de probar la
> implementación de una infraestructura de PKI, para esto hemos visto
> que existe openca que permite administar via web el tema de
> certificados, desearia conocer si existen otras posibilidades,
> actualmente estamos trabajando sobre fedora y vemos que no existe un
> paquete sino que se debe hacer uso de fuentes.
>
> atte
>
>
> Rosemary
>
From [EMAIL PROTECTED] Tue Sep 23 12:39:56 2008
From: [EMAIL PROTECTED] (Aldrin Martoq)
Date: Tue Sep 23 12:40:21 2008
Subject: PHP 4 en RHEL (y otras distro "enterprise") [Was: Re:
Canonical does not contribute to Linux plumbing.]
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On Tue, 2008-09-23 at 10:44 -0400, Germán Póo-Caamaño wrote:
> On Tue, 2008-09-23 at 09:49 -0400, Aldrin Martoq wrote:
> > Windows es un perfecto ejemplo de mantener compatibilidad hacia atras a
> > todo nivel. O al reves, Linux es un perfecto ejemplo de matar la
> > compatibilidad hacia atras:
> > - Los binarios de hace 3 an~os ya no sirven sin workarounds, adios
> > software propietario! ;
> > - El codigo de hace 6 meses ya no compila, acabo de bajar eog-2.23.92 y
> > me exige intltool-0.40.0 ;
> Creo que el ejemplo de EOG no concurre. Porque si quieres utilizar
> cualquier característica nueva de otros programas que dependes,
> necesariamente debes instalar nuevas versiones de dichas dependencias.
> Es decir, si quieres utilizar una nueva función que te provee una
> versión nueva de una biblioteca, no veo para que no utilizarla?
Es solo un ejemplo. Precisamente, en otros ambientes lo normal es que se
mantiene una version/API/interfaz etc; esto porque la mayoria del codigo
esta en la misma plataforma (como Swing o las cosas de i18n en java,
cosas _bastante_ estables).
> Aún puedes instalar intltool 0.40. Aunque probablemente, el
> requerimiento no sea tan extremo.
> Si quieres comparar compatibilidad hacia atrás, lo que tendrías que
> hacer es tomar una versión más antigua de eog e intentar compilarla
> ahora.
Precisamente el punto, aqui no esta el problema de botar la
compatibilidad hacia atras y asi se avanza mas rapido.
> > - GNOME ha cambiado varias veces de implementaciones de CORBA hasta
> > "volver" a D-Bus y bibliotecas compartidas;
> 2 veces. MICO es sus muy primeros inicios, luego ORBit. Siempre se
> culpó a CORBA por ser lento, pero la verdad es que ORBit es rápido.
ORBit puede ser rapido, pero es la arquitectura la lenta y costosa. Ah,
y falto Bonobo...
> Y para compatibilidad entre escritorios, es más fácil/rápido crear un
> nuevo componente (agnóstico), que elegir una tecnología por sobre otra.
> > - Otros ejemplos mas que no se me ocurren...
> Netscape. Reescribir todo el código. Pero ello ameritó el artículo
> "Things you should never do".
> http://www.joelonsoftware.com/articles/fog0000000069.html
Quizas me exprese mal. No es reescribir todo, es botar lo malo sin asco.
En la practica reescribimos todo pero no se parte de cero.
--
Aldrin Martoq <[EMAIL PROTECTED]>
http://aldrinvideopodcast.podshow.com/
