angelo astorga wrote: >Hola lista, ando en busca de algun sistema WEB que >administre documentos y su historia, asociados a >usuarios y maneje documentos binarios, es decir, de >office... probe con un CVS pero no me sirve por el >tema de tipo de documento (solo texto).. > >
Subversion + Trac. -- Ricardo Mun~oz A. Usuario Linux #182825 (counter.li.org) From [EMAIL PROTECTED] Thu May 11 14:04:08 2006 From: [EMAIL PROTECTED] (augusto ingunza) Date: Thu May 11 15:04:11 2006 Subject: No levanta servicio S24ypbind en rc5.d Message-ID: <[EMAIL PROTECTED]> Amigos, quería hacerles una consulta con respecto a los servicios que se encuentran en /etc/rc5.d He puestoo un servicio en rc5.d con "chkconfig --level 5 ypbind on" sin embargo a pesar que tiene como nombre S24ypbind cuando levanta linux ese no lo levanta, pudiendolo hacer normalmente con "service ypbind start" todo lo demás si levanta. Estoy usando RedHat 4 WS con kernel 2.6.9-5.EL Gracias Augusto __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From [EMAIL PROTECTED] Thu May 11 11:05:17 2006 From: [EMAIL PROTECTED] (Diego Bello) Date: Thu May 11 15:19:16 2006 Subject: =?iso-8859-1?q?Re=3A_Tama=F1o_papel?= In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On 5/11/06, Alejandro Barros <[EMAIL PROTECTED]> wrote: > > El Miércoles, 10 de Mayo de 2006 23:18, Horst von Brand escribió: > > pmontecinos <[EMAIL PROTECTED]> wrote: > > > > [...] > > > > > Lo terrible es que en la Universidad tienes que entregar la tesis en > > > oficio, lo que entre otras cosas dificulta la realización de ésta es > > > latex, en A4 quedaría espectacular. > > > > No es /tan/ dificil cambiar el taman~o de papel, incluso definiendo uno > > personalizado... > > Pero sería un gran aporte a la estandarización que en la Universidad se > utilice algún de los estándares internacionales (ANSI, DIN, ISO) y no un > tamaño que el único país del mundo que lo usa es Chile > > > -- > Alejandro Barros > En la Santa María la memoria se hace en tamaño carta: http://www.bib.utfsm.cl/casacentral/normasmemoria.php?id=presentacion -- Diego Bello Carreño Estudiante Memorista de Ingeniería Civil Informática UTFSM, Valparaíso, Chile Usuario #294897 counter.li.org ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: http://listas.inf.utfsm.cl/pipermail/linux/attachments/20060511/a568e97f/attachment.html From [EMAIL PROTECTED] Thu May 11 15:29:25 2006 From: [EMAIL PROTECTED] (Alvaro Herrera) Date: Thu May 11 15:29:31 2006 Subject: No levanta servicio S24ypbind en rc5.d In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> augusto ingunza escribió: > Amigos, quería hacerles una consulta con respecto a > los servicios que se encuentran en /etc/rc5.d > > He puestoo un servicio en rc5.d con > "chkconfig --level 5 ypbind on" sin embargo a pesar > que tiene como nombre S24ypbind cuando levanta linux > ese no lo levanta, pudiendolo hacer normalmente con > "service ypbind start" todo lo demás si levanta. Quizas el script no es ejecutable? -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. From [EMAIL PROTECTED] Thu May 11 16:45:04 2006 From: [EMAIL PROTECTED] (Daniel Serpell) Date: Thu May 11 16:45:13 2006 Subject: Pregunta de C In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Hola! El Thu, May 11, 2006 at 10:22:10AM -0400, Alvaro Herrera escribio: > > Trate de ver lo que sucedia si ponia un canario abajo y otro arriba de > la variable, o sea > > int canario1 = 0x7e7e7e7e; > char *valor[tam]; > int canario2 = 0xe7e7e7e7; > > Sin embargo, me lleve una sorpresa porque mostrando las posiciones de > las variables en el stack, canario1 y canario2 aparecen junto con tam e > i, pegadas al principio del stack, mientras que valor aparece mucho mas > abajo! Deduzco que el compilador se toma la libertad de reordenar las > variables como le plazca. Esto es asi tanto con -O0, como -O2 y sin > especificar ninguna. Como expliqué en mi correo en oss-devel, el arreglo automático no reserva memoria de la misma manera que las variables locales normales, esto tiene mucho sentido ya que si se pusieran en el orden que tu esperabas, para acceder a "canario2" en tiempo de ejecución sería necesario calcular su dirección cada vez. El código que tu indicas es (casi) equivalente a: int canario1; char **valor; int canario2; valor = alloca( sizeof(tam) * sizeof(char *) ); La diferencia es que en mi ejemplo la dirección de memoria del arreglo se guarda en una variable local con nombre, en el caso tuyo se crea una variable local "invisible" con la dirección. > > Para programas a nivel usuario el stack es inmenso de grande, asi que seria > > muy muy raro que ocurriera eso. > > Bueno, el programa de ejemplo se cae con SIGSEGV cuando el "tam" es > mayor que algo de 1900000 (casi 2000000 realmente), lo cual por supuesto > es esperable. (Esto en x86-64 eso si). El tamaño del stack _no_ es tan grande, debido a limitaciones de la arquitectura. Básicamente, tienes que particionar la memoria en varias áreas: * Código, creciendo hacia arriba. * Datos inicializados, idem. * Heap, creciedo hacia arriba. * Bibliotecas compartidas. * Stack, creciendo hacia abajo. Para que el Stack y el Heap no se crucen con las biblitecas compartidas, es necesario fijar una barrera en alguna parte. La mayoría de las aplicaciones usan mucho más heap que stack, por lo que las bibliotecas compartidas se colocan más cerca del límite del stack. Esta barrera puede modificarse con el comando ulimit, si escribes: $ ulimit -s 8192 En mi caso, se reservan 8192Kb para stack de las aplicaciones. No es bueno reservar mucha memoria en el stack por varias razones: * El stack es limitado, como ya se explicó. La práctica común es usar heap para bloques grandes de memoria. * El stack guarda las variables locales, por lo que es muy importante que quede en el caché de la CPU. Manteniendo su uso bajo, se prioriza la localidad de datos y se mejora el rendimiento. * As más fácil depurar problemas de manejo de memoria en el heap que en el stack, gracias a la existencia de guardas entre los bloques de memoria. Daniel. PD: Buenos lugares para discutir estos temas son news://comp.lang.c y news://comp.unix.programmer
