Re: fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
El miércoles, 17 dic 2014, a las 02:15 horas (UTC+1), libreydivagante escribió: P.D.2.: perdi mi correo unciegobailando, si alguien sabe como desuscribirlo sin entrar en el mismo... Explicándole la situación al maestro de las listas de Debian (listmas...@lists.debian.org). Por cierto, han llegado tres correos casi idénticos a la lista. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217102139.02708...@gmail.com
RE: [OT] Re: pin off bluetooth
Toolbar = Rich Text = Plain Text = OK. ¿En serio? X-) Siii, era en serio he aqui un torpe que intenta hacerlo bien, cojan palomitas ; ) No entiendo ... Pues que seleccione lo que seleccione no hace caso siempre sale como html. Ya he probado todas las opciones que ofrece y en todas sale como html. Creo que puede ser por noscript (addon). Siento las molestias Saludos,
RE: [OT] Re: pin off bluetooth
En el bluetooth, he encontrado una diferencia que me parece es clave En el debian que no pide pin: #hciconfig -a hci0: Type: BR/EDR Bus: USB BD Address: 0C:60:76:8C:AE:B2 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:1295 acl:0 sco:0 events:52 errors:0 TX bytes:717 acl:0 sco:0 commands:52 errors:0 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT Name: 'debian-0' Class: 0x420100 Service Classes: Networking, Telephony Device Class: Computer, Uncategorized HCI Version: 2.1 (0x4) Revision: 0x518f LMP Version: 2.1 (0x4) Subversion: 0x424c Manufacturer: Broadcom Corporation (15) Esa version de hci es distinta a la del pc que si pide pin para emparejar, las cuales son hci version 1.2...lm version 1.2 Supongo que hci v2.1 sera sid. Aqui los paquetes instalados, creo relevantes, haciendo caso a ramses: ii bluetooth 4.99-2 all Bluetooth support ii bluez 4.99-2 i386 Bluetooth tools and daemons ii bluez-alsa:i386 4.99-2 i386 Bluetooth ALSA support ii bluez-cups 4.99-2 i386 Bluetooth printer driver for CUPS ii bluez-firmware 1.2-3 all Firmware for Bluetooth devices ii bluez-gstreamer 4.99-2 i386 Bluetooth GStreamer support ii bluez-tools 0.1.38+git662e-3 i386 Set of tools to manage Bluetooth devices for linux ii gir1.2-gnomebluetooth-1.0 3.4.2-1 i386 Introspection data for GnomeBluetooth ii gnome-bluetooth 3.4.2-1 i386 GNOME Bluetooth tools ii libbluetooth3:i386 4.99-2 i386 Library to use the BlueZ Linux Bluetooth stack ii libgnome-bluetooth10 3.4.2-1 i386 GNOME Bluetooth tools - support library ii libmulticobex1 0.23-1.1 i386 multi-protocol cable OBEX library ii libobexftp0 0.23-1.1 i386 object exchange file transfer library ii libopenobex1 1.5-2+deb7u1 i386 OBEX protocol library ii obex-data-server 0.4.5-1+b3 i386 D-Bus service for OBEX client and server side functionality ii obexd-client 0.46-1+b1 i386 D-Bus OBEX client ii obexftp 0.23-1.1 i386 file transfer utility for devices that use the OBEX protocol ii obexpushd 0.11.2-1 i386 program for receiving files via Bluetooth or IRDA ii ussp-push 0.11-1 i386 Client for OBEX PUSH -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/dub109-w12a62e6172fc7c9547b7b3c7...@phx.gbl
Re: [OT] Re: pin off bluetooth
El dic 16, 2014 11:42 AM, Camaleón noela...@gmail.com escribió: El Tue, 16 Dec 2014 09:36:07 +, franiortiz hotmail escribió: Windows Live Hotmail To set plain text for a single message - (while composing your post) Toolbar = Rich Text = Plain Text = OK. ¿En serio? X-) A ver si mejora. (...) Pues va a ser que no. No entiendo qué complicación puede haber en seleccionar un formato de texto plano para los mensajes... Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.16.14.41...@gmail.com La misma complicación que tenemos al ver que respondes a cualquier cosa cuando la puedes tratar directamente con la otra persona por correo pv. Pero bueno a ti eso no te importa. Saludos.
Re: servidor de correo electronico.
On 16/12/14 14:43, Ala de Dragón wrote:
El 15/12/14, Ala de Dragón aladedra...@gmail.com escribió:
(...)
De momento voy a empaparme de dovecot y os voy contando.
(...)
Hola :D
Estoy encajando las piezas del puzzle. SMTP funciona correctamente y
entrega los correos a su destinatario. Puedo conectarme con mutt y
leer los correos en /var/mail/usuario.
Cuando me conecto a traves de telnet a POP3 Dovecot me da la
bienvenida, y mi cliente de correo se conecta, autentifica y recibe
una bandeja de entrada vacía. Voy a leer mas logs en profundidad pero
parece que Dovecot busca los correos en otro lugar. Si la memoria no
me falla creo haberle indicado que los almacenara en ~/mail
Mi pregunta es:
¿que sintaxis debo utilizar para que busque los correos dovecot en
/var/mail/usuario y no en su carpeta home, o como le indico a
postfix que los entregue en ~/mail?
Gracias por su tiempo
;)
Si te fijas bien, Postfix no hace entrega de correo en los buzones, en
realidad, una vez que Postfix acepta un correo para entrega local, llama
a un tercer programa que se encarga de la entrega del mismo, este
programa se lo conoce como (local delivery agent). En la configuración
por defecto de Postfix se usa a procmail, sin embargo, si estás usando
Dovecot, a mi juicio te conviene cambiarlo al binario de deliver de
Dovecot que hace lo mismo y además se integra con Dovecot en otras
formas, por ejemplo indexa los correos en cuanto se hace la entrega, no
cuando el usuario accede a su buzón (Puedes ganar en algo de performance)
Este es el parámetro en main.cf de postfix para usar deliver de Dovecot
mailbox_command = /usr/lib/dovecot/deliver -a ${RECIPIENT}
Si usas procmail entonces la configuración del tipo de buzón (mbox o
maildir), procmail la leerá de /etc/procmailrc (Tienes que crearlo
porque no existe y funciona con una configuración por defecto)
Por ejemplo para usar procmail con formato maildir guardando los
correos en /home/$usuario/Maildir
DEFAULT=$HOME/Maildir/
MAILDIR=$HOME/Maildir/
Si usas deliver de Dovecot, entonces, este usa la configuración de
ubicación de buzones del propio Dovecot.
El mismo parámetro pero con una conf para maildir en Dovecot:
mail_location = maildir:~/Maildir
Puedes usar la variable %u para indicar usuario, o ~ para referirte al
directorio home del usuario loggeado.
PD: No quiero complicar más el asunto pero si te interesa, en vez de
usar un binario como LDA que se ejecuta con cada entrega de correo,
puedes usar el protocolo LMTP (Local Mail Transport Protocol), que se
ejecuta todo el tiempo y solo hace entregas a buzones locales. En
Dovecot comparte la misma configuración que deliver.
Saludos
Federico
http://wiki2.dovecot.org/LDA/Postfix
http://wiki2.dovecot.org/MailLocation
http://wiki2.dovecot.org/LMTP
--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54917695.1090...@uncu.edu.ar
Re: fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
El 17/12/14 a las 06:21, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 02:15 horas (UTC+1), libreydivagante escribió: P.D.2.: perdi mi correo unciegobailando, si alguien sabe como desuscribirlo sin entrar en el mismo... Explicándole la situación al maestro de las listas de Debian (listmas...@lists.debian.org). Por cierto, han llegado tres correos casi idénticos a la lista. si, tuve problemas para suscribirme... me enviaba un mensaje la lista de que la confirmacion no se pudo realizar, asi que volvia con confirmar y a enviar el correo...bueno. Ahora si lo reenvio limpiamente. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5491891f.4000...@gmail.com
Re: servidor de correo electronico.
El 12/12/14 a las 19:04, Ala de Dragón escribió: Hola :-D Me gustaría desarrollar un proyecto de servidor de correo elec. y he andado curioseando por la lista y google. actualmente dispongo un fqn e ip fija en un vps.. https://workaround.org/ispmail/wheezy -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54918f8a.6040...@esilt.azcuba.cu
Re: fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
El 17/12/14 a las 06:21, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 02:15 horas (UTC+1), libreydivagante escribió: P.D.2.: perdi mi correo unciegobailando, si alguien sabe como desuscribirlo sin entrar en el mismo... Explicándole la situación al maestro de las listas de Debian (listmas...@lists.debian.org). Por cierto, han llegado tres correos casi idénticos a la lista. Es extraño, cuando envio mi correo no veo que ha llegado a la lista, hace 10 min te respondi y no ha caido aun, por supuesto que actualize la bandeja. Con mi anterior cuenta de correo no sucedia y podia ver a los pocos minutos mi envio en la bandeja de entrada. Uso icedove - thunderbird -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54918d98.5040...@gmail.com
Re: devuan
El Tue, 16 Dec 2014 19:55:16 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:16 horas (UTC+1), Camaleón escribió: (...) El resto de paquetes no ha tenido un CTTE de por medio, pero este sí. Es decir, no, no es lo mismo. Y no hay que olvidar del tipo de paquete del que estamos hablando: un bug en el gestor de servicios (o en un servicio que no se inicia con sysvinit) no tiene el mismo impacto que un bug en una aplicación cualquiera. En el primer caso te puedes quedar sin iniciar el sistema mientras que en el segundo a lo sumo te quedas sin poner iniciar una aplicación. Claro que no tiene la misma implicación. Pero siguiendo tu línea argumental: ¿y si el paquete libc6 tiene un fallo? _Todo_ el sistema deja de funcionar. Hasta sysvinit-core depende de él y no hay alternativas. Lo mismo es válido para el núcleo. (...) Creo que o no entiendes o no quieres entender la problemática. Que yo sepa, libc6 sigue teniendo el mismo estatus que tenía hace un año no así sysvinit que poco a poco va a quedar fuera de juego. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.14.22...@gmail.com
Re: Systemd y kernel 3.16.0.4 - Fallo al iniciar sistema - jessie
El 16/12/14 a las 23:58, libreydivagante escribió: Cuando se prende el pc logra cargar systemd para luego ejecutar aparentemente un x server color negro y alli queda. Tampoco es posible accecer a las ttys desde ctrl + alt + f1,2, etc. No estan, o bien son bloqueados. El modo recuperacion no sirve y el sistema termina decantando en la ya mensionada situacion. Por suerte habia instalado por equivocacion una .iso de wheezy desde la cual actualize y cuyo kernel es el 3.2. Es con este si funciona bien systemd y puedo llegar al escritorio y plena funcionalidad. el comando systemctl --failed me arroja un resutaldo de cero fallas. Se podra pesar que es un problema de actualizacion, pero lo dudo mucho, ya que esto mismo me sucedia habiendo instalado una imagen testing jessie semanal con escritorio xfce y mismo kernel -3.16.0.4-. Algunas veces lograba hacer que el sistema funcione, increiblemente tipeando cualquier tecla apenas terminada la seleccion del kernel en el grub, cuando comienza a cargar systemd. Quizas como dato sirva que mi pc no posee pila, asi que el tiempo nunca es el correcto, pero no parece ser un fallo de fechas de archivos y logs... P.D.: Se pueden imaginar como estoy puteando a red hat y systemd no? Saludos desde el sur. Ayer sucedio esto luego de enviado el mensaje: la ejecucion de systemd --failed termino recomendando systemctl list-unit-files el cual ejecuto. y logre ver, debido a que la consola era pequeña, solo la primera parte de los servicios y/o procesos listados. Donde acpid.path se encontraba activado y acpid.service desactivado. Sin mucho que perder acitve: systemctl enable acpid.service Reinicie tres veces de prueba y cargo el kernel 3.16.04 sin problema alguno. hoy me desperte pensando que estaba estaba resulto y no. Volvi a al problema ya descrito... Sucedió dos veces -el cuelgue con pantalla negra- y debi apagar el equipo abruptamente. En posterior reinicio presionando repetidamente asdf -o cualquier otra combinación, claro esta- en este momento.. booting the kernel please wait Pude cargar el kernel 3.16.0.4 y tener el sistema operativo sin problemas. P.D.: Me siento chabacano, soez, incluso un salvaje. Quizas siempre lo fui. Asdf, fuck the science!! -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54918fdd.1030...@gmail.com
Re: Fwd: fglrx-driver
El Tue, 16 Dec 2014 22:45:10 +0100, Javier Silva escribió: El 16/12/2014 15:51, Camaleón noela...@gmail.com escribió: El Mon, 15 Dec 2014 19:18:03 +0100, Javier Silva escribió: (ese html...) Lamento lo del html, pero me he quedado sin equipo y contesto desde el móvil y el maravilloso gmail no me deja responder en solo texto :-( y eso que lo he pedido como 2 millones de veces. Si eres consciente de que algo está mal, hombre... no lo hagas. Puedes esperar a tener acceso a un cliente de correo como dios manda para responder ¿no? ;-) El 14/12/2014 17:20, Camaleón noela...@gmail.com escribió: (...) Lamentablemente el driver radeon no funciona con esta tarjeta gráfica, al menos la versión que lleva Jessie. Desde que tengo esta gráfica he tenido que utilizar de manera forzosa el driver propietario y comenzé en Wheezy backports e instalando el driver desde testing. Lástima no haber visto este hilo antes o el problema que has mencionado, porque ahora tengo el equipo sin poder usarlo tras la actualización a Jessie. Vaya, pues qué mal... ¿seguro que tampoco funciona el driver radeon? Porque si es así también deberíais informar de eso o la gente que tenga una gráfica con ese chipset lo va a pasar muy mal con Jessie. El driver radeon no ha funcionado nunca con estas series de tarjetas y así lo indica la lista de chips soportados y estos no aparecen. El chipset que montan las radeon 7xxx pertenece a la familia southern island que sí está soportado por el driver libre aunque es posible que alguna funcionalidad concreta esté pendiente pero eso no le debe impedir su funcionamiento. Alguna idea para poder ir trabajando, a parte de redireccionar las X por ssh para arrancar los progranas que voy necesitando? Pues lo que dicen en el informe de fallo que es activar la tarjeta integrada (intel) aunque no sé si en vuestro caso tenéis sistemas gráficos híbridos y esto es una opción. No tengo tarjeta integrada intel, mi sistema es un AMD Phenom II con un zócalo AM3+ sin IGP, por lo que sólo dispongo de esta gráfica. Curiosamente la última live de GNOME sí que funciona perfectamente y sin el driver propietario. Claro, de hecho el driver radeon debería funcionar mejor en gnome-shell que el driver propietario. Tenía que haber seguido con Wheezy backports y el driver de testing que sí funcionaba perfectamente, ahora me tocará volver de nuevo a Wheezy si no encuentro una solución. Mientras lo resuleven, prueba con el radeon en jessie, al menos tiene que permitirte ejecutar un entorno gráfico 2D (como kde sin efectos, gnome- fallback, xfce, lxde, etc...). Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.14.31...@gmail.com
Re: [OT] Re: pin off bluetooth
El Wed, 17 Dec 2014 11:03:17 +, franiortiz hotmail escribió: Hombre, por fin texto plano... al final no era tan difícil ;-) En el bluetooth, he encontrado una diferencia que me parece es clave En el debian que no pide pin: #hciconfig -a hci0: Type: BR/EDR Bus: USB BD Address: 0C:60:76:8C:AE:B2 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:1295 acl:0 sco:0 events:52 errors:0 TX bytes:717 acl:0 sco:0 commands:52 errors:0 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT Name: 'debian-0' Class: 0x420100 Service Classes: Networking, Telephony Device Class: Computer, Uncategorized HCI Version: 2.1 (0x4) Revision: 0x518f LMP Version: 2.1 (0x4) Subversion: 0x424c Manufacturer: Broadcom Corporation (15) Esa version de hci es distinta a la del pc que si pide pin para emparejar, las cuales son hci version 1.2...lm version 1.2 Supongo que hci v2.1 sera sid. El paquete bluez de jessie y sid son la misma versión (5.23). Wheezy lleva una versión anterior (4.99) y raspbian ni idea de cuál usa :-? Pero esa versión de hci que ves ahí (2.1) se debe referir a la versión del dispositivo BT que tengas conectado porque debería de ser siempre la misma, pero si dices que obtienes dos valores distintos dependiendo de dónde lo ejecutes entonces ese dato puede hacer referencia al controlador/ adaptador BT del equipo. Aqui los paquetes instalados, creo relevantes, haciendo caso a ramses: (...) Por tu comentario anterior pensaba que ya habías encontrado el problema porque como comentabas, lo normal es que la primera solicitud de emparejamiento pida el PIN (como te pasa con otro equipo además de raspbian). Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.14.47...@gmail.com
Re: devuan
El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Eso no es lo que ha preguntado ;-) A partir de Jessie, systemd va a ser el gestor de servicios predeterminado y se va a potenciar su uso, no hay más vuelta de hoja. Todos los scripts de inicio se van a hacer pensando en systemd y probado en/por/para systemd. El kernel, las aplicaciones, los entornos de escritorio pro-systemd (gnome) y el resto de servicios todos sin excepción dirigen sus pasos hacia systemd. Upstart y sysvinit quedan en el banquillo, relegados a un segundo puesto. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Y si haces eso ya verás lo que tardan en degradar el informe de fallo a normal, que las prioridades las gestionan los mantenedores no los informantes. Y dependerá del mantenedor si corregir el problema o cuándo hacerlo. Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.15.02...@gmail.com
Re: Habilitar USB en Clientes Ligeros debian wheezy
El Tue, 16 Dec 2014 21:03:29 -0500, Didier Suárez R escribió: Hola lista tengo un servidor de clientes ligeros montado en debian wheezy, me funciona correctamente pero no puedo conectar dispositivos USB en los clientes. ¿Cómo puedo hacerlo? No sé si habrás leído la documentación/información sobre los dispositivos USB: http://wiki.ltsp.org/wiki/Tips_and_Tricks/Devices http://www.skolelinux.no/~klaus/newnotater/x2714.html Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.15.08...@gmail.com
Re: fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
El Wed, 17 Dec 2014 10:21:39 +0100, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 02:15 horas (UTC+1), libreydivagante escribió: P.D.2.: perdi mi correo unciegobailando, si alguien sabe como desuscribirlo sin entrar en el mismo... Explicándole la situación al maestro de las listas de Debian (listmas...@lists.debian.org). No hace falta, puede hacerlo directamente: Common glitches in the (un)subscription process https://www.debian.org/MailingLists/index.en.html#subunsub Por cierto, han llegado tres correos casi idénticos a la lista. Seguramente porque usa Gmail y no se ha dado cuenta de que los mensajes que manda a la lista de correo no se reciben ya que Gmail los trata como duplicados y los oculta. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.14.54...@gmail.com
Re: fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
El Tue, 16 Dec 2014 22:15:31 -0300, libreydivagante escribió: La verdad es muy dificil dar algun detalle mas. Cuando se prende el pc logra cargar systemd para luego ejecutar aparentemente un xserver color negro y alli queda. Tampoco es posible accecer a las ttys desde ctrl + alt + f1,2, etc. No estan, o bien son bloqueados. El modo recuperacion no sirve y el sistema termina decantando en la ya mensionada situacion. Das muy pocos datos pero puedes seguir estos pasos para depurar problemas con systemd: https://wiki.debian.org/systemd#Debugging Por suerte habia instalado por equivocacion una .iso de wheezy desde la cual actualize y cuyo kernel es el 3.2. Es con este si funciona bien systemd y puedo llegar al escritorio y plena funcionalidad. el comando systemctl --failed me arroja un resutaldo de cero fallas. Se podra pesar que es un problema de actualizacion, pero lo dudo mucho, ya que esto mismo me sucedia habiendo instalado una imagen testing jessie semanal con escritorio xfce y mismo kernel -3.16.0.4-. Algunas veces lograba hacer que el sistema funcione, increiblemente tipeando cualquier tecla apenas terminada la seleccion del kernel en el grub, cuando comienza a cargar systemd. La jessie que aún tengo de pruebas con systemd no tiene problemas de inicio y es raro que a estas alturas haya algún bug tan serio sin resolver que impida al sistema iniciarse. Quizas como dato sirva que mi pc no posee pila, asi que el tiempo nunca es el correcto, pero no parece ser un fallo de fechas de archivos y logs... (...) Tener la hora incorrecta en la BIOS no debe impedir que un equipo arranque y se inicie normalmente, otra cosa es que una vez cargado el SO tengas problemas de todo tipo por lo que te convendría instalar algún paquete de sincronización de tiempo. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.15.15...@gmail.com
Re: [OT] Es mejor un archivo grande o muchos pequeños
El Tue, 16 Dec 2014 12:52:01 -0500, Edwin De La Cruz escribió: Saludos cordiales. Antes que nada me disculpo por el OT, pero es que no se donde o como buscar. Y por el html... :-P El asunto es el siguiente: Estoy haciendo una aplicación que a su vez tiene varios hilos corriendo a la vez, estos hilos generan cierta informacion que necesito almacenar. He probado con SQLite, pero tengo problemas ya que algunas (muchas) veces cuando uno de los hilos de la aplicación necesita insertar información en la base de datos falla ya que se encuentra bloqueada por otro hilo. He subido el timeout pero solo ha mejorado un poco. Tambien tengo algo de temor ya que he leido que la base de datos podria corromporse si en un momento dos procesos escriben a la vez en la base de datos. Actualmente para este fin uso PostgreSQL, sin ningun problema, pero o que necesito es hacer la aplicacion mas independiente y facil de instalar, configurar, etc. (...) Es decir, buscas un sistema de bdd autónomo que permita concurrencia en operaciones de escritura (funcionalidad que sólo suelen incluir las bdd de esquema cliente/servidor como mysql, postgresql, etc...). No sé si habrás mirado la biblioteca BerkeleyDB (BDB), quizá te sirva para tu aplicación. He pensado en usar XML para cada registro que la aplicacion genera, de este modo ya no hay peligro de corrupcion de datos, como podria suceder en el caso de SQLite. No creo que SQlite llegue a ese punto (pérdida de datos), entiendo que debería devolver una respuesta de ocupado e impedir la escritura notificando al proceso que lo haya solicitado de este punto con lo cual podría programarse una función para reintentar de nuevo la escritura si se da esta situación. La Pregunta es la siguiente: es pesado (lento) para el procesador el tener que leer o copiar cientos o miles de archivos individuales, lo pregunto porque me ha pasado que cuando copio alguna carpeta que contiene ciento de archivos, todos menores a 10K, el proceso es muy muy lento. Bueno, una bdd siempre resulta más eficiente cuando se trata de una cantidad considerable de información que se tiene que manipular en espacios de tiempo cortos y además evitas depender de las características del sistema donde se vaya a ejecutar. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.15.37...@gmail.com
RE: servidor de correo electronico.
El 12/12/14 a las 19:04, Ala de Dragón escribió: Hola :-D Me gustaría desarrollar un proyecto de servidor de correo elec. y he andado curioseando por la lista y google. actualmente dispongo un fqn e ip fija en un vps.. https://workaround.org/ispmail/wheezy Revisastes Zimbra. slu2 WRC -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/bay177-w1425b8529db243478ad0e7b6...@phx.gbl
Re: servidor de correo electronico.
El Wed, 17 Dec 2014 09:27:01 -0300, Federico Alberto Sayd escribió: On 16/12/14 14:43, Ala de Dragón wrote: (...) ¿que sintaxis debo utilizar para que busque los correos dovecot en /var/mail/usuario y no en su carpeta home, o como le indico a postfix que los entregue en ~/mail? Gracias por su tiempo ;) Si te fijas bien, Postfix no hace entrega de correo en los buzones, en realidad, una vez que Postfix acepta un correo para entrega local, llama a un tercer programa que se encarga de la entrega del mismo, este programa se lo conoce como (local delivery agent). En la configuración por defecto de Postfix se usa a procmail, (...) Que yo sepa, lo cierto es que el valor predeterminado de la variable mailbox_command es nulo, es decir, ninguno. Postfix, como agente SMTP/LDA se encarga de entregar directamente los mensajes donde le digas (almacén local o comando externo, que puede ser cualquier otro agente/filtro de correo -procmail/maildrop- o un servidor pop3/imap -dovecot, cyrus, courier...). Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.15.53...@gmail.com
Re: fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
El 17/12/14 a las 12:15, Camaleón escribió: El Tue, 16 Dec 2014 22:15:31 -0300, libreydivagante escribió: La verdad es muy dificil dar algun detalle mas. Cuando se prende el pc logra cargar systemd para luego ejecutar aparentemente un xserver color negro y alli queda. Tampoco es posible accecer a las ttys desde ctrl + alt + f1,2, etc. No estan, o bien son bloqueados. El modo recuperacion no sirve y el sistema termina decantando en la ya mensionada situacion. Das muy pocos datos pero puedes seguir estos pasos para depurar problemas con systemd: https://wiki.debian.org/systemd#Debugging Por suerte habia instalado por equivocacion una .iso de wheezy desde la cual actualize y cuyo kernel es el 3.2. Es con este si funciona bien systemd y puedo llegar al escritorio y plena funcionalidad. el comando systemctl --failed me arroja un resutaldo de cero fallas. Se podra pesar que es un problema de actualizacion, pero lo dudo mucho, ya que esto mismo me sucedia habiendo instalado una imagen testing jessie semanal con escritorio xfce y mismo kernel -3.16.0.4-. Algunas veces lograba hacer que el sistema funcione, increiblemente tipeando cualquier tecla apenas terminada la seleccion del kernel en el grub, cuando comienza a cargar systemd. La jessie que aún tengo de pruebas con systemd no tiene problemas de inicio y es raro que a estas alturas haya algún bug tan serio sin resolver que impida al sistema iniciarse. Quizas como dato sirva que mi pc no posee pila, asi que el tiempo nunca es el correcto, pero no parece ser un fallo de fechas de archivos y logs... (...) Tener la hora incorrecta en la BIOS no debe impedir que un equipo arranque y se inicie normalmente, otra cosa es que una vez cargado el SO tengas problemas de todo tipo por lo que te convendría instalar algún paquete de sincronización de tiempo. Saludos, Tengo ntpdate pero en el inicio no se puede cargar che... Igualmente hay otro mensaje mas alarmente que este... sucede que tuve problemas con gmail y la forma en que me muestra la bandeja de entrada. Es mas reciente. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5491a3db.9010...@gmail.com
Re: fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
El 17/12/14 a las 11:54, Camaleón escribió: El Wed, 17 Dec 2014 10:21:39 +0100, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 02:15 horas (UTC+1), libreydivagante escribió: P.D.2.: perdi mi correo unciegobailando, si alguien sabe como desuscribirlo sin entrar en el mismo... Explicándole la situación al maestro de las listas de Debian (listmas...@lists.debian.org). No hace falta, puede hacerlo directamente: Common glitches in the (un)subscription process https://www.debian.org/MailingLists/index.en.html#subunsub Por cierto, han llegado tres correos casi idénticos a la lista. Seguramente porque usa Gmail y no se ha dado cuenta de que los mensajes que manda a la lista de correo no se reciben ya que Gmail los trata como duplicados y los oculta. Saludos, hace un rato que me di cuenta que Gmail... genial!! JAJA.. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5491a4c5.7060...@gmail.com
entorno grafico en wheezy
hola lista ya solucione el problema pero me queda la curiosidad, recientemente cambie mi hardware por una nueva tecnologia, anteriormente tenia un motherboard gigabyte con socket 775, ddr2 y ahora cambie para un motherboard asus, micro i3, ddr3, resulta que instale mi debian como siempre, mismo cd de instalcion mismos repositorios ect, y en el proceso de instalacion me asegure de haber marcado la opcion correspondiente con que implemente el entorno grafico, (digo me asegure por que lo hice dos veces), resulta que se instalo correctamente sin problemas, pero para sorpresa mia al levantar el sistema me levanta solamente en modo texto, a lo que posteriormente tuve que añadirle algunos paquetes para solucionar el problema, (gnome y gdm3, mas sus respectivas dependncias) hecho esto ya tuve mi entorno grafico, mi pregunta es la siguiente, a alguien mas le ha sucedido esto? no entiendo si anteriormente en otras arquitecturas de hardware simplemente con espesificar que quiero mi sistema con entorno grafico al levantar el mismo aparecia gnome sin prolemas, y ahora con un simple cambio de hardware no lo hace, pero para mas dudas, en otra pc con tecnologia similar sobre win7 implemente un virtual box y en este agregue una pc virtual dedicada a debian hice el mismo proceso y sucede lo mismo me levanta solo en modo texto, de antemano aclaro que el instalador que utilice para la pc virtual es otro pues me dedique a descargarlo nuevamente incluso desde otra fuente. si alguien tiene explicacion para esto se lo agradeceria, por que la verdad me tiene pensando un poco este dilema. gracias de antemano. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5491aa2d.1000...@cncc.cult.cu
Re: entorno grafico en wheezy
El Wed, 17 Dec 2014 11:07:09 -0500, Ariel escribió: hola lista ya solucione el problema ¿Mande? :-? pero me queda la curiosidad, recientemente cambie mi hardware por una nueva tecnologia, anteriormente tenia un motherboard gigabyte con socket 775, ddr2 y ahora cambie para un motherboard asus, micro i3, ddr3, resulta que instale mi debian como siempre, mismo cd de instalcion mismos repositorios ect, y en el proceso de instalacion me asegure de haber marcado la opcion correspondiente con que implemente el entorno grafico, (digo me asegure por que lo hice dos veces), resulta que se instalo correctamente sin problemas, pero para sorpresa mia al levantar el sistema me levanta solamente en modo texto, a lo que posteriormente tuve que añadirle algunos paquetes para solucionar el problema, (gnome y gdm3, mas sus respectivas dependncias) hecho esto ya tuve mi entorno grafico, mi pregunta es la siguiente, a alguien mas le ha sucedido esto? (...) Dependiendo del medio que uses para la instalación (mini iso, cd o dvd) te podrá instalar automáticamente los paquetes que selecciones o no, en cuyo caso tendrás que configurar los repositorios externos para que pueda instalar los paquetes a los que no tiene acceso de manera local. Ante la duda de cualquier problema con el instalador, podrás consultar los registros posteriormente (/var/log/installer). Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.16.23...@gmail.com
Re: devuan
El miércoles, 17 dic 2014, a las 16:02 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Eso no es lo que ha preguntado ;-) A partir de Jessie, systemd va a ser el gestor de servicios predeterminado y se va a potenciar su uso, no hay más vuelta de hoja. Todos los scripts de inicio se van a hacer pensando en systemd y probado en/por/para systemd. El kernel, las aplicaciones, los entornos de escritorio pro-systemd (gnome) y el resto de servicios todos sin excepción dirigen sus pasos hacia systemd. Eso es adivinación. Upstart y sysvinit quedan en el banquillo, relegados a un segundo puesto. Eso, en cambio, es algo que ocurre ahora, con Jessie. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Y si haces eso ya verás lo que tardan en degradar el informe de fallo a normal, que las prioridades las gestionan los mantenedores no los informantes. Y dependerá del mantenedor si corregir el problema o cuándo hacerlo. Vuelves a adivinar. Pero no, no me imagino a los mantenedores degradando informes de fallos mientras cientos o miles de usuarios ven como sus servicios o su ordenador no se inician. Si quieren terminar para siempre el proyecto Debian imagino que los desarrolladores lo harán de forma más elegante. Personalmente me inclino por una de estas dos perspectivas. - Los fallos son resueltos con regularidad, como hasta ahora (Sí, incluida Jessie). - Los mantenedores/desarrolladores deciden que el exceso de trabajo no merece la pena y expulsan a sysvinit (o upstart) de Debian. Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Uso varios tipos de servicios: correo de sistema (postfix), servidor HTTP para el sistema de documentación de Debian (lighttpd), DNS caché (pdnsd), etc. Y todos sin excepción me funcionan perfectamente con sysvinit en Jessie. Esa situación de perfecto funcionamiento es del todo incompatible con la afirmación de abandono. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217174934.76b00...@gmail.com
Re: devuan
El miércoles, 17 dic 2014, a las 15:22 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 19:55:16 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:16 horas (UTC+1), Camaleón escribió: (...) El resto de paquetes no ha tenido un CTTE de por medio, pero este sí. Es decir, no, no es lo mismo. Y no hay que olvidar del tipo de paquete del que estamos hablando: un bug en el gestor de servicios (o en un servicio que no se inicia con sysvinit) no tiene el mismo impacto que un bug en una aplicación cualquiera. En el primer caso te puedes quedar sin iniciar el sistema mientras que en el segundo a lo sumo te quedas sin poner iniciar una aplicación. Claro que no tiene la misma implicación. Pero siguiendo tu línea argumental: ¿y si el paquete libc6 tiene un fallo? _Todo_ el sistema deja de funcionar. Hasta sysvinit-core depende de él y no hay alternativas. Lo mismo es válido para el núcleo. (...) Creo que o no entiendes o no quieres entender la problemática. Que yo sepa, libc6 sigue teniendo el mismo estatus que tenía hace un año no así sysvinit que poco a poco va a quedar fuera de juego. Pues precisamente has puesto un mal ejemplo. Aunque el nombre del paquete no cambió, Wheezy usaba eglibc[1], mientras que Jessie vuelve a usar los fuentes de GNU. No hubo cruzada cuando se abandonó la biblioteca de GNU ni ahora, cuando se ha abandonado eglibc, aunque sí una lógica preocupación ante un cambio de tal magnitud. Sí que entiendo el problema: sysvinit está relegado a segundo plano actualmente y puede desaparecer de Debian en el futuro. Problema según quién, claro. Pero lo que no comparto es atribuirle en exclusiva debilidades que están en todos los sistemas de inicio (punto único de fallo) o presentar un imaginado y siniestro futuro como realidad presente. [1] http://www.eglibc.org/home Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217175238.104ea...@gmail.com
Re: devuan
El 17/12/14 a las 12:02, Camaleón escibió: El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Eso no es lo que ha preguntado ;-) A partir de Jessie, systemd va a ser el gestor de servicios predeterminado y se va a potenciar su uso, no hay más vuelta de hoja. Todos los scripts de inicio se van a hacer pensando en systemd y probado en/por/para systemd. El kernel, las aplicaciones, los entornos de escritorio pro-systemd (gnome) y el resto de servicios todos sin excepción dirigen sus pasos hacia systemd. Upstart y sysvinit quedan en el banquillo, relegados a un segundo puesto. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Y si haces eso ya verás lo que tardan en degradar el informe de fallo a normal, que las prioridades las gestionan los mantenedores no los informantes. Y dependerá del mantenedor si corregir el problema o cuándo hacerlo. Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Saludos, Entonces los usuarios comunes, finales, de escritorio como yo ¿En qué nos beneficia Systemd como gestor de inicio? ¿Qué deberemos ver o qué disfrutar? Porque se discute si es beneficioso o perjudicial. Ahora bien, sin saber lo que ustedes a nivel técnico infiero que si el gestor de inicio tendrá tantas dependencias, además de controlar los servicios del sistema es de pensar que si falla algo todo el sistema caerá al mejor estilo Windows. ¡Tamaño equipo de desarrollo debe tener systemd para soportar los fallos que irán apareciendo! ¿no? -- Sergio Bessopeanetto Buenos Aires - Argentina -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5491b361.5020...@inbox.im
Re: devuan
El Wed, 17 Dec 2014 17:49:34 +0100, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 16:02 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Eso no es lo que ha preguntado ;-) A partir de Jessie, systemd va a ser el gestor de servicios predeterminado y se va a potenciar su uso, no hay más vuelta de hoja. Todos los scripts de inicio se van a hacer pensando en systemd y probado en/por/para systemd. El kernel, las aplicaciones, los entornos de escritorio pro-systemd (gnome) y el resto de servicios todos sin excepción dirigen sus pasos hacia systemd. Eso es adivinación. Para nada, es una realidad. Cosa aparte es que haya quien no quiera verlo o tenga miedo (¿?) de las consecuencias de afirmar que es así. Upstart y sysvinit quedan en el banquillo, relegados a un segundo puesto. Eso, en cambio, es algo que ocurre ahora, con Jessie. Pues eso es lo que estoy diciendo. Y repito que no hay nada de malo en esa decisión, todo proyecto debe autodefinirse y apostar por unas opciones u otras sólo que hay formas distintas de adoptarlas y en eso (en la forma de implementar systemd) creo que en Debian se han equivocado de pleno. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Y si haces eso ya verás lo que tardan en degradar el informe de fallo a normal, que las prioridades las gestionan los mantenedores no los informantes. Y dependerá del mantenedor si corregir el problema o cuándo hacerlo. Vuelves a adivinar. Pocos informes de fallo habrás leído o seguido más allá de los que hayas puesto. De hecho, ajustar la prioridad de un informe de fallo es el procedimiento habitual. Pero no, no me imagino a los mantenedores degradando informes de fallos mientras cientos o miles de usuarios ven como sus servicios o su ordenador no se inician. Yo me lo imagino perfectamente. Es más (y ahora sí estoy adivinando) visualizo la respuesta: Verás, es que ahora el gestor de servicios es systemd y todos los paquetes se prueban contra systemd, ¿podrías instalarlo para ver si te funciona? El pobre informador incauto lo instala, le funciona y el bug queda cerrado a cal y canto. Al fin y al cabo, los empaquetadores saben (aunque no lo quieran decir en voz alta) que sysvinit no va a durar mucho. Si quieren terminar para siempre el proyecto Debian imagino que los desarrolladores lo harán de forma más elegante. Personalmente me inclino por una de estas dos perspectivas. - Los fallos son resueltos con regularidad, como hasta ahora (Sí, incluida Jessie). - Los mantenedores/desarrolladores deciden que el exceso de trabajo no merece la pena y expulsan a sysvinit (o upstart) de Debian. Supongo que ya sabrás cuál es la respuesta ¿no? :-) Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Uso varios tipos de servicios: correo de sistema (postfix), servidor HTTP para el sistema de documentación de Debian (lighttpd), DNS caché (pdnsd), etc. Y todos sin excepción me funcionan perfectamente con sysvinit en Jessie. Esa situación de perfecto funcionamiento es del todo incompatible con la afirmación de abandono. Cuando deje de funcionarte algo, hablamos. Cuando tengas que instalar una aplicación de terceros que no trabaje con systemd y tengas problemas con la compatibilidad de systemd y los scripts escritos para sysvinit, hablamos. Sigues sin entenderlo: no se trata de que tú o yo tengamos un problema o no lo tengamos, se trata de que a partir de jessie sysvinit va a ir desapareciendo del mapa y no sólo en Debian. Así lo han decidido, así está pasando y así va a ser. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.17.04...@gmail.com
Re: devuan
El Wed, 17 Dec 2014 17:52:38 +0100, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 15:22 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 19:55:16 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:16 horas (UTC+1), Camaleón escribió: (...) El resto de paquetes no ha tenido un CTTE de por medio, pero este sí. Es decir, no, no es lo mismo. Y no hay que olvidar del tipo de paquete del que estamos hablando: un bug en el gestor de servicios (o en un servicio que no se inicia con sysvinit) no tiene el mismo impacto que un bug en una aplicación cualquiera. En el primer caso te puedes quedar sin iniciar el sistema mientras que en el segundo a lo sumo te quedas sin poner iniciar una aplicación. Claro que no tiene la misma implicación. Pero siguiendo tu línea argumental: ¿y si el paquete libc6 tiene un fallo? _Todo_ el sistema deja de funcionar. Hasta sysvinit-core depende de él y no hay alternativas. Lo mismo es válido para el núcleo. (...) Creo que o no entiendes o no quieres entender la problemática. Que yo sepa, libc6 sigue teniendo el mismo estatus que tenía hace un año no así sysvinit que poco a poco va a quedar fuera de juego. Pues precisamente has puesto un mal ejemplo. El paquete (libc6) lo has elegido tú, no yo ;-) Aunque el nombre del paquete no cambió, Wheezy usaba eglibc[1], mientras que Jessie vuelve a usar los fuentes de GNU. No hubo cruzada cuando se abandonó la biblioteca de GNU ni ahora, cuando se ha abandonado eglibc, aunque sí una lógica preocupación ante un cambio de tal magnitud. ¿Y qué tiene que ver eso con lo que estamos hablando? :-? Independientemente de la fuente de la que se nutra la biblioteca, el estado del paquete no ha variado: mismas dependencias, misma compatibilidad, misma libertad... todo igual. Ya me gustaría a mí que el cambio de sysvinit a systemd hubiera sido como el de esta biblioteca. Mira, el ejemplo es perfecto: demuestra que las cosas se pueden hacer bien, cuando se quiere. Sí que entiendo el problema: sysvinit está relegado a segundo plano actualmente y puede desaparecer de Debian en el futuro. Problema según quién, claro. Huy, según nadie... claro, claro, como nadie se ha quejado, no han aparecido proyectos paralelos para evitar su uso, no hay un fork de la base de Debian, etc... Pero lo que no comparto es atribuirle en exclusiva debilidades que están en todos los sistemas de inicio (punto único de fallo) o presentar un imaginado y siniestro futuro como realidad presente. En este caso, piensa mal y acertarás. Podrían haber hecho las cosas de forma distinta, aún implementando systemd y dándole prioridad, podrían haberlo hecho sin levantar tanta polvareda y sin enfadar a sus usuarios, dándoles otra opción real... pero no. En fin, sólo espero que no se arrepientan. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.17.15...@gmail.com
Re: devuan
El Wed, 17 Dec 2014 13:46:25 -0300, Sergio Bessopeanetto escribió: El 17/12/14 a las 12:02, Camaleón escibió: El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: (...) Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Entonces los usuarios comunes, finales, de escritorio como yo ¿En qué nos beneficia Systemd como gestor de inicio? ¿Qué deberemos ver o qué disfrutar? Porque se discute si es beneficioso o perjudicial. Ahora bien, sin saber lo que ustedes a nivel técnico infiero que si el gestor de inicio tendrá tantas dependencias, además de controlar los servicios del sistema es de pensar que si falla algo todo el sistema caerá al mejor estilo Windows. ¡Tamaño equipo de desarrollo debe tener systemd para soportar los fallos que irán apareciendo! ¿no? Para ser sinceros, en este momento ya no importan las ventajas o inconvenientes, systemd es lo que hay en linux y si quieres evitar su uso el laberinto en el que te vas a meter no te va a compensar. Yo nunca me paré a pensar en las ventajas o problemas de sysvinit: funcionaba, era compatible con la mayor parte de los entornos linux/bsd/ unix, hacía lo que se le pedía (una función), era modular y sencillo de depurar. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.17.17.29...@gmail.com
BRILLO de pantalla en una Note HP-110 con Linux+XFCE
Estimada gente, Tengo un problema luego de una instalación nueva de un Linux+XFCE+OPENBOX. Funciona casi todo; salvo que el brillo de pantalla NO se puede cambiar de ninguna manera quedándo este MUY alto. Anteriormente con una versión vieja de LINUX-Debian+XFCE esto no ocurría. Las teclas de brillo NO producen efecto alguno. He buscado por la WEB pero con resultados negativos. La máquina es una Notebook HP-110 (funciona de maravillas y con OpenBox es muy rápida) El resultado del comando lshw -c video es el siguiente: *-display:0 descripción: VGA compatible controller producto: Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller fabricante: Intel Corporation capacidades: msi pm vga_controller bus_master cap_list rom configuración: driver=i915 latency=0 recursos: irq:44 memoria:5418-541f ioport:30c0(size=8) memoria:4000-4fff memoria:5400-540f *-display:1 NO RECLAMADO descripción: Display controller producto: Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller fabricante: Intel Corporation capacidades: pm bus_master cap_list Toda ayuda será agradecida. -- Saludos, Eduardo mailto:egis_e...@yahoo.com.ar -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/835461702.20141217151...@yahoo.com.ar
Re: servidor de correo electronico.
On 17/12/14 12:53, Camaleón wrote: El Wed, 17 Dec 2014 09:27:01 -0300, Federico Alberto Sayd escribió: On 16/12/14 14:43, Ala de Dragón wrote: (...) ¿que sintaxis debo utilizar para que busque los correos dovecot en /var/mail/usuario y no en su carpeta home, o como le indico a postfix que los entregue en ~/mail? Gracias por su tiempo ;) Si te fijas bien, Postfix no hace entrega de correo en los buzones, en realidad, una vez que Postfix acepta un correo para entrega local, llama a un tercer programa que se encarga de la entrega del mismo, este programa se lo conoce como (local delivery agent). En la configuración por defecto de Postfix se usa a procmail, (...) Que yo sepa, lo cierto es que el valor predeterminado de la variable mailbox_command es nulo, es decir, ninguno. Postfix, como agente SMTP/LDA se encarga de entregar directamente los mensajes donde le digas (almacén local o comando externo, que puede ser cualquier otro agente/filtro de correo -procmail/maildrop- o un servidor pop3/imap -dovecot, cyrus, courier...). Saludos, Gracias por la aclaración Camaleón, sí es cierto, Postfix puede hacer la entrega local él mismo e incluso entiende los dos tipos de buzones más usados mbox y Maildir. Hay que configurar la variable home_mailbox para decirle a Postfix que haga la entrega en el home del usuario, si no, por defecto lo deja en /var/spool/mail/$user A lo que me refería del LDA por defecto de Postfix es que Debian en particular preconfigura a procmail como LDA cuando lo instalas: **mailbox_command = procmail -a $EXTENSION En [1] hay más información sobre la entrega local por si a alguien le interesa. [1] http://www.postfix.org/local.8.html Saludos Federico
Re: BRILLO de pantalla en una Note HP-110 con Linux+XFCE
El miércoles, 17 dic 2014, a las 19:11 horas (UTC+1), Eduardo Jorge Gil Michelena escribió: Estimada gente, Tengo un problema luego de una instalación nueva de un Linux+XFCE+OPENBOX. Funciona casi todo; salvo que el brillo de pantalla NO se puede cambiar de ninguna manera quedándo este MUY alto. Anteriormente con una versión vieja de LINUX-Debian+XFCE esto no ocurría. Las teclas de brillo NO producen efecto alguno. He buscado por la WEB pero con resultados negativos. La máquina es una Notebook HP-110 (funciona de maravillas y con OpenBox es muy rápida) El resultado del comando lshw -c video es el siguiente: *-display:0 descripción: VGA compatible controller producto: Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller fabricante: Intel Corporation capacidades: msi pm vga_controller bus_master cap_list rom configuración: driver=i915 latency=0 recursos: irq:44 memoria:5418-541f ioport:30c0(size=8) memoria:4000-4fff memoria:5400-540f *-display:1 NO RECLAMADO descripción: Display controller producto: Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller fabricante: Intel Corporation capacidades: pm bus_master cap_list Toda ayuda será agradecida. ¿Tienes instalados los paquetes relacionados con ACPI? Prueba dpkg -l \*acpi* como usuario. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217192644.349b8...@gmail.com
Re: devuan
El miércoles, 17 dic 2014, a las 18:15 horas (UTC+1), Camaleón escribió: El Wed, 17 Dec 2014 17:52:38 +0100, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 15:22 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 19:55:16 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:16 horas (UTC+1), Camaleón escribió: (...) El resto de paquetes no ha tenido un CTTE de por medio, pero este sí. Es decir, no, no es lo mismo. Y no hay que olvidar del tipo de paquete del que estamos hablando: un bug en el gestor de servicios (o en un servicio que no se inicia con sysvinit) no tiene el mismo impacto que un bug en una aplicación cualquiera. En el primer caso te puedes quedar sin iniciar el sistema mientras que en el segundo a lo sumo te quedas sin poner iniciar una aplicación. Claro que no tiene la misma implicación. Pero siguiendo tu línea argumental: ¿y si el paquete libc6 tiene un fallo? _Todo_ el sistema deja de funcionar. Hasta sysvinit-core depende de él y no hay alternativas. Lo mismo es válido para el núcleo. (...) Creo que o no entiendes o no quieres entender la problemática. Que yo sepa, libc6 sigue teniendo el mismo estatus que tenía hace un año no así sysvinit que poco a poco va a quedar fuera de juego. Pues precisamente has puesto un mal ejemplo. El paquete (libc6) lo has elegido tú, no yo ;-) Aunque el nombre del paquete no cambió, Wheezy usaba eglibc[1], mientras que Jessie vuelve a usar los fuentes de GNU. No hubo cruzada cuando se abandonó la biblioteca de GNU ni ahora, cuando se ha abandonado eglibc, aunque sí una lógica preocupación ante un cambio de tal magnitud. ¿Y qué tiene que ver eso con lo que estamos hablando? :-? Todo. Se ha cambiado un paquete por otro distinto para el mismo fin (caso paralelo a sysvinit/systemd) sin que haya tanto jaleo. Donde se rompe el paralelismo es que con el sistema de inicio sí hay elección. Independientemente de la fuente de la que se nutra la biblioteca, el estado del paquete no ha variado: mismas dependencias, misma compatibilidad, misma libertad... Es decir, ninguna. todo igual. Ya me gustaría a mí que el cambio de sysvinit a systemd hubiera sido como el de esta biblioteca. Mira, el ejemplo es perfecto: demuestra que las cosas se pueden hacer bien, cuando se quiere. Pues fue un cambio mucho más brusco: no había posibilidad de gradación. Con systemd pude dar marcha atrás y volver a sysvinit porque coexistían en el repositorio. Con esa biblioteca no hubiese podido hacer nada excepto esperar a que resolviesen cualquier posible fallo. Sí que entiendo el problema: sysvinit está relegado a segundo plano actualmente y puede desaparecer de Debian en el futuro. Problema según quién, claro. Huy, según nadie... claro, claro, como nadie se ha quejado, no han aparecido proyectos paralelos para evitar su uso, no hay un fork de la base de Debian, etc... Teniendo en cuenta que muchas otras personas no han hecho nada parecido... pues eso, según quién. Pero lo que no comparto es atribuirle en exclusiva debilidades que están en todos los sistemas de inicio (punto único de fallo) o presentar un imaginado y siniestro futuro como realidad presente. En este caso, piensa mal y acertarás. Podrían haber hecho las cosas de forma distinta, aún implementando systemd y dándole prioridad, podrían haberlo hecho sin levantar tanta polvareda y sin enfadar a sus usuarios, dándoles otra opción real... pero no. En fin, sólo espero que no se arrepientan. Si se arrepienten dan marcha atrás o eligen otro sistema de inicio. Esto no es el fin del mundo. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217193330.05524...@gmail.com
Re: entorno grafico en wheezy
El 17/12/14 a las 13:07, Ariel escribió: hola lista ya solucione el problema pero me queda la curiosidad, recientemente cambie mi hardware por una nueva tecnologia, anteriormente tenia un motherboard gigabyte con socket 775, ddr2 y ahora cambie para un motherboard asus, micro i3, ddr3, resulta que instale mi debian como siempre, mismo cd de instalcion mismos repositorios ect, y en el proceso de instalacion me asegure de haber marcado la opcion correspondiente con que implemente el entorno grafico, (digo me asegure por que lo hice dos veces), resulta que se instalo correctamente sin problemas, pero para sorpresa mia al levantar el sistema me levanta solamente en modo texto, a lo que posteriormente tuve que añadirle algunos paquetes para solucionar el problema, (gnome y gdm3, mas sus respectivas dependncias) hecho esto ya tuve mi entorno grafico, mi pregunta es la siguiente, a alguien mas le ha sucedido esto? no entiendo si anteriormente en otras arquitecturas de hardware simplemente con espesificar que quiero mi sistema con entorno grafico al levantar el mismo aparecia gnome sin prolemas, y ahora con un simple cambio de hardware no lo hace, pero para mas dudas, en otra pc con tecnologia similar sobre win7 implemente un virtual box y en este agregue una pc virtual dedicada a debian hice el mismo proceso y sucede lo mismo me levanta solo en modo texto, de antemano aclaro que el instalador que utilice para la pc virtual es otro pues me dedique a descargarlo nuevamente incluso desde otra fuente. si alguien tiene explicacion para esto se lo agradeceria, por que la verdad me tiene pensando un poco este dilema. gracias de antemano. Mi'jo !! es dificil leer todo ese matete de texto, jeje!! Aparentemente el problema de no tener graficos -las Xs- se debe a falta de ser llamadas por un gestor de session. Has contado que tuviste que instalarlo haciendo gdm3. Ahora el se encarga de levantar las Xs. De bajar una .iso con cualquier escritorio y que este no levante a graficos a la primera vez, puede deberse tambien a los drivers necesarios para tu placa grafica, o quizas su configuracion. Ahi tenes para investigar si queres.. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5491d124.3030...@gmail.com
Re: devuan
El miércoles, 17 dic 2014, a las 18:04 horas (UTC+1), Camaleón escribió: El Wed, 17 Dec 2014 17:49:34 +0100, Manolo Díaz escribió: El miércoles, 17 dic 2014, a las 16:02 horas (UTC+1), Camaleón escribió: El Tue, 16 Dec 2014 20:32:57 +0100, Manolo Díaz escribió: El martes, 16 dic 2014, a las 19:09 horas (UTC+1), Eduardo Rios escribió: No entiendo mucho del tema, pero parece ser que desde Jessie en adelante, para que todos los servicios funcionen correctamente, se depende de systemd. No. Si un servicio solo va a funcionar correctamente con systemd, te va a obligar a instalarlo. Eso no es lo que ha preguntado ;-) A partir de Jessie, systemd va a ser el gestor de servicios predeterminado y se va a potenciar su uso, no hay más vuelta de hoja. Todos los scripts de inicio se van a hacer pensando en systemd y probado en/por/para systemd. El kernel, las aplicaciones, los entornos de escritorio pro-systemd (gnome) y el resto de servicios todos sin excepción dirigen sus pasos hacia systemd. Eso es adivinación. Para nada, es una realidad. Cosa aparte es que haya quien no quiera verlo o tenga miedo (¿?) de las consecuencias de afirmar que es así. Upstart y sysvinit quedan en el banquillo, relegados a un segundo puesto. Eso, en cambio, es algo que ocurre ahora, con Jessie. Pues eso es lo que estoy diciendo. Y repito que no hay nada de malo en esa decisión, todo proyecto debe autodefinirse y apostar por unas opciones u otras sólo que hay formas distintas de adoptarlas y en eso (en la forma de implementar systemd) creo que en Debian se han equivocado de pleno. Vale, no es necesario, pero si eliges cualquier otro, te arriesgas a que ciertos servicios no vayan o no lo hagan como esperas... No. Y en caso contrario solo hay que abrir un informe de fallo serio por carecer de una dependencia. Un paquete no puede alcanzar la distribución estable si cuenta con un solo fallo de este tipo sin corregir. https://www.debian.org/Bugs/Developer#severities Y si haces eso ya verás lo que tardan en degradar el informe de fallo a normal, que las prioridades las gestionan los mantenedores no los informantes. Y dependerá del mantenedor si corregir el problema o cuándo hacerlo. Vuelves a adivinar. Pocos informes de fallo habrás leído o seguido más allá de los que hayas puesto. De hecho, ajustar la prioridad de un informe de fallo es el procedimiento habitual. Sí, he visto reajustes en los dos sentidos, para aumentar o para disminuir la severidad. La desavenencia sobre la severidad real del fallo se da con cierta frecuencia. Lo que no he visto es conspiración. Pero no, no me imagino a los mantenedores degradando informes de fallos mientras cientos o miles de usuarios ven como sus servicios o su ordenador no se inician. Yo me lo imagino perfectamente. Es más (y ahora sí estoy adivinando) visualizo la respuesta: Verás, es que ahora el gestor de servicios es systemd y todos los paquetes se prueban contra systemd, ¿podrías instalarlo para ver si te funciona? El pobre informador incauto lo instala, le funciona y el bug queda cerrado a cal y canto. Al fin y al cabo, los empaquetadores saben (aunque no lo quieran decir en voz alta) que sysvinit no va a durar mucho. No tengo amistad con ninguno, así que no me han hecho ninguna confidencia al respecto pasada ya la quinta ronda de cervezas. Por cierto, ¿cómo lo sabes tú? Si quieren terminar para siempre el proyecto Debian imagino que los desarrolladores lo harán de forma más elegante. Personalmente me inclino por una de estas dos perspectivas. - Los fallos son resueltos con regularidad, como hasta ahora (Sí, incluida Jessie). - Los mantenedores/desarrolladores deciden que el exceso de trabajo no merece la pena y expulsan a sysvinit (o upstart) de Debian. Supongo que ya sabrás cuál es la respuesta ¿no? :-) No, pero lo sabré en un par de años. Entonces, entiendo que los desarrolladores se vuelquen con systemd y abandonen cualquier otro sistema de inicio. En Jessie no. En adelante cualquiera sabe. (...) Desde Jessie... sí. Ya me dirás, lo han puesto como predeterminado y han modificado los scripts de inicio de las aplicaciones y servicios para adaptarlos a systemd a todo correr... Uso varios tipos de servicios: correo de sistema (postfix), servidor HTTP para el sistema de documentación de Debian (lighttpd), DNS caché (pdnsd), etc. Y todos sin excepción me funcionan perfectamente con sysvinit en Jessie. Esa situación de perfecto funcionamiento es del todo incompatible con la afirmación de abandono. Cuando deje de funcionarte algo, hablamos. Cuando tengas que instalar una aplicación de terceros que no trabaje con systemd y tengas problemas con la compatibilidad de systemd y los scripts escritos para sysvinit, hablamos. Ese sería un argumento a favor de mantener a sysvinit. Sigues sin entenderlo: no se trata de que tú o yo tengamos un problema o no lo tengamos, se trata de que a partir de jessie sysvinit
de Alberto Cabrejas Pérez
Saludos lista, quisiera saber si existe alguna forma de instalar paquetes x86 en un sistema operativo amd64, por ejemplo Wheezy. -- Saludos, *Alberto Cabrejas Pérez* Administrador de Redes Informáticas ARTex S.A. Sucursal Granma http://www.artexsa.com http://www.scgra.artex.sa Linux Usuario Registrado # 31 666 Teléf.(0123) 48-1956, 48-1912, 48-1934 (Ext 107) Las autoridades sanitarias advierten: El uso prolongado de Microsoft Windows provoca dependencia...
Re: de Alberto Cabrejas Pérez
El jueves, 18 dic 2014, a las 01:11 horas (UTC+1), Alberto Cabrejas Pérez escribió: Saludos lista, quisiera saber si existe alguna forma de instalar paquetes x86 en un sistema operativo amd64, por ejemplo Wheezy. Sí, busca multiarch. Por cierto, es más fácil gestionar el correo si en el campo asunto aparece el asunto, algo así como Instalar aplicaciones i386 en SO amd64. Tu nombre ya lo tenemos en el campo remitente, no es necesario repetirlo. Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217204028.21763...@gmail.com
RE: [OT] Re: pin off bluetooth
To: debian-user-spanish@lists.debian.org From: noela...@gmail.com Subject: Re: [OT] Re: pin off bluetooth Date: Wed, 17 Dec 2014 14:47:58 + El Wed, 17 Dec 2014 11:03:17 +, franiortiz hotmail escribió: por fin texto plano... al final no era tan difícil ;-) Buenoo un poquillo si era, el noscript en iceweasel, bloqueando msads.net (publi grrr!!),msecnd.net y atdmt.com hace que hotmail siempre use html, elijas txt rico o plano... por si a alguien le pasa. El paquete bluez de jessie y sid son la misma versión (5.23). Wheezy ... En ambos pc (el que pide pin y el que no), instalo debian-lxde-whezzy, cambio repo para compiz e instalo,,cambio repo a sid e instalo, y finalmente lo dejo a stable y nunca mas lo toco, pero se me pudo colar el paquete en bluez en cualquiera de esos 2 repos. Pero esa versión de hci que ves ahí (2.1) se debe referir a la versión del dispositivo BT que tengas conectado... No habia pensado que fuera la version del protocolo bluetooth, pero tiene sentido porque el que NO pide pin trae un bluetooth integrado broadcom (v2.1) en un lenovo t400 (año 2008) y en el otro pc (asus904), en el que SI pide pin, pongo un pincho bluetooth por usb del año catapun (v1.2) Por tu comentario anterior pensaba que ya habías encontrado el problema Es cierto, encontre el problema porque en un principio pensaba que si no se instalaba frontend para bluetooth (o lo que sea), este funcionaba sin pin, que era lo normal. Pero raspibian me descubrio que eso era lo raro, lo probe en otro pc igual (asus) con pincho y efectivamente pide pin. Pero sin embargo en el lenovo con su broadcom integrado, el comando obexftp, ussp-push,... no necesitan pin para funcionar, lo acabo de probar con 2 desconocidos como ? porque ? Saludos,
Re: de Alberto Cabrejas Pérez
El Wed, 17 Dec 2014 19:11:47 -0500 Alberto Cabrejas Pérez albe...@scgr.artex.cu escribió: Saludos lista, quisiera saber si existe alguna forma de instalar paquetes x86 en un sistema operativo amd64, por ejemplo Wheezy. -- si Saludos, *Alberto Cabrejas Pérez* Administrador de Redes Informáticas ARTex S.A. Sucursal Granma http://www.artexsa.com http://www.scgra.artex.sa Linux Usuario Registrado # 31 666 Teléf.(0123) 48-1956, 48-1912, 48-1934 (Ext 107) Las autoridades sanitarias advierten: El uso prolongado de Microsoft Windows provoca dependencia... -- Angel Claudio Alvarez an...@angel-alvarez.com.ar -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217182539.e5e89642fcd1995e7ec4d...@angel-alvarez.com.ar
Re: fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
El Tue, 16 Dec 2014 22:15:31 -0300 libreydivagante libreydivaga...@gmail.com escribió: La verdad es muy dificil dar algun detalle mas. Cuando se prende el pc logra cargar systemd para luego ejecutar aparentemente un xserver color negro y alli queda. Tampoco es posible accecer a las ttys desde ctrl + alt + f1,2, etc. No estan, o bien son bloqueados. El modo recuperacion no sirve y el sistema termina decantando en la ya mensionada situacion. Por suerte habia instalado por equivocacion una .iso de wheezy desde la cual actualize y cuyo kernel es el 3.2. Es con este si funciona bien systemd y puedo llegar al escritorio y plena funcionalidad. el comando systemctl --failed me arroja un resutaldo de cero fallas. Se podra pesar que es un problema de actualizacion, pero lo dudo mucho, ya que esto mismo me sucedia habiendo instalado una imagen testing jessie semanal con escritorio xfce y mismo kernel -3.16.0.4-. Algunas veces lograba hacer que el sistema funcione, increiblemente tipeando cualquier tecla apenas terminada la seleccion del kernel en el grub, cuando comienza a cargar systemd. Quizas como dato sirva que mi pc no posee pila, asi que el tiempo nunca es el correcto, pero no parece ser un fallo de fechas de archivos y logs... P.D.: Se pueden imaginar como estoy putenado a red hat y systemd no? estas en jessie, no es stable Saludos desde el sur. P.D.2.: perdi mi correo unciegobailando, si alguien sabe como desuscribirlo sin entrar en el mismo... -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5490d933.6050...@gmail.com -- Angel Claudio Alvarez an...@angel-alvarez.com.ar -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217182816.b54941ccfd552bd09d48c...@angel-alvarez.com.ar
Activar Arquitectura 32 bits - Alberto Cabrejas Pérez
El 17/12/14 a las 18:25, Angel Claudio Alvarez escribió: El Wed, 17 Dec 2014 19:11:47 -0500 Alberto Cabrejas Pérez albe...@scgr.artex.cu escribió: Saludos lista, quisiera saber si existe alguna forma de instalar paquetes x86 en un sistema operativo amd64, por ejemplo Wheezy. -- si Angel, o yo entiendo mal o es de muy mal gusto lo que hiciste viejo... Uno no sabe como siente la persona que pregunta, y que esta necesitando realmente. Hasta aqui la escuela hoy. Saludos lista, quisiera saber si existe alguna forma de instalar paquetes x86 en un sistema operativo amd64, por ejemplo Wheezy. Bueno alberto, si es posible. previamente tenes que activar desde consola la arquitectura deseada de esta forma. dpkg --add-architecture i386 luego actualizas desde algun gestor grafico o bien: sudo apt-get update y ya puedes instalar librerias o aplicaciones para 32 bits. Es conocido que Skype y Teamweaver, por ejemplo, requieren paquetes en 32 bits para funcionar. Saludos desde el sur. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5491f933.8050...@gmail.com
Re: fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
El 17/12/14 a las 18:28, Angel Claudio Alvarez escribió: El Tue, 16 Dec 2014 22:15:31 -0300 libreydivagante libreydivaga...@gmail.com escribió: La verdad es muy dificil dar algun detalle mas. Cuando se prende el pc logra cargar systemd para luego ejecutar aparentemente un xserver color negro y alli queda. Tampoco es posible accecer a las ttys desde ctrl + alt + f1,2, etc. No estan, o bien son bloqueados. El modo recuperacion no sirve y el sistema termina decantando en la ya mensionada situacion. Por suerte habia instalado por equivocacion una .iso de wheezy desde la cual actualize y cuyo kernel es el 3.2. Es con este si funciona bien systemd y puedo llegar al escritorio y plena funcionalidad. el comando systemctl --failed me arroja un resutaldo de cero fallas. Se podra pesar que es un problema de actualizacion, pero lo dudo mucho, ya que esto mismo me sucedia habiendo instalado una imagen testing jessie semanal con escritorio xfce y mismo kernel -3.16.0.4-. Algunas veces lograba hacer que el sistema funcione, increiblemente tipeando cualquier tecla apenas terminada la seleccion del kernel en el grub, cuando comienza a cargar systemd. Quizas como dato sirva que mi pc no posee pila, asi que el tiempo nunca es el correcto, pero no parece ser un fallo de fechas de archivos y logs... P.D.: Se pueden imaginar como estoy putenado a red hat y systemd no? estas en jessie, no es stable Si es nomas lo que te dije en otro mensaje. Pero para niños como tu no aqui no hay mas escuela. Lo que naturaleza no da, salamanca no presta! Saludos desde el sur. P.D.2.: perdi mi correo unciegobailando, si alguien sabe como desuscribirlo sin entrar en el mismo... -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5490d933.6050...@gmail.com -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5491f9ca.1090...@gmail.com
Re: servidor de correo electronico.
On Wed, Dec 17, 2014 at 03:20:04PM -0300, Federico Alberto Sayd wrote: A lo que me refería del LDA por defecto de Postfix es que Debian en particular preconfigura a procmail como LDA cuando lo instalas: **mailbox_command = procmail -a $EXTENSION Cuando eso sucede es porque postfix detecta en el momento de instalarse que procmail también está instalado. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217223214.GA24068@nuc
Re: BRILLO de pantalla en una Note HP-110 con Linux+XFCE
El 17/12/14 a las 13:26, Manolo Díaz escibió: El miércoles, 17 dic 2014, a las 19:11 horas (UTC+1), Eduardo Jorge Gil Michelena escribió: Estimada gente, Tengo un problema luego de una instalación nueva de un Linux+XFCE+OPENBOX. Funciona casi todo; salvo que el brillo de pantalla NO se puede cambiar de ninguna manera quedándo este MUY alto. Anteriormente con una versión vieja de LINUX-Debian+XFCE esto no ocurría. Las teclas de brillo NO producen efecto alguno. He buscado por la WEB pero con resultados negativos. La máquina es una Notebook HP-110 (funciona de maravillas y con OpenBox es muy rápida) El resultado del comando lshw -c video es el siguiente: *-display:0 descripción: VGA compatible controller producto: Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller fabricante: Intel Corporation capacidades: msi pm vga_controller bus_master cap_list rom configuración: driver=i915 latency=0 recursos: irq:44 memoria:5418-541f ioport:30c0(size=8) memoria:4000-4fff memoria:5400-540f *-display:1 NO RECLAMADO descripción: Display controller producto: Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller fabricante: Intel Corporation capacidades: pm bus_master cap_list Toda ayuda será agradecida. ¿Tienes instalados los paquetes relacionados con ACPI? Prueba dpkg -l \*acpi* como usuario. Saludos. Una posible solución podría estar por instalar xbacklight, para luego ponerlo a que se inicie en el arranque. El comando siguiente establece el brillo en 60 en una escala de 0 a 100 xbacklight -set 60 En gnomeaplicaciones al inicio hago lo siguiente para que se cargue al inicio: Nombre: Brillo Comando: xbacklight -set 60 Comentario: Establece brillo de pantalla Me imagino que se puede hacer algo parecido en xfce. -- Germán Avendaño Ramírez Lic. Mat. U.D., M.Sc. U.N. Delegado Asamblea ADE Delegado VI Congreso Nal CUT GNU/Linux user # 531535 Sent from Debian GNU/Linux 7.7 (wheezy) -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/549210e0.6010...@autistici.org
Re: BRILLO de pantalla en una Note HP-110 con Linux+XFCE
El mié 17-dic-14, Germán Avendaño Ramírez gdavenda...@autistici.org escribió: Asunto: Re: BRILLO de pantalla en una Note HP-110 con Linux+XFCE Para: debian-user-spanish@lists.debian.org Fecha: miércoles, 17 de diciembre de 2014, 20:25 El miércoles, 17 dic 2014, a las 19:11 horas (UTC+1), Eduardo Jorge Gil Michelena escribió: Tengo un problema luego de una instalación nueva de un Linux+XFCE+OPENBOX. Funciona casi todo; salvo que el brillo de pantalla NO se puede cambiar de ninguna manera quedando este MUY alto. Anteriormente con una versión vieja de LINUX-Debian+XFCE esto no ocurría. Las teclas de brillo NO producen efecto alguno. Germán Avendaño Ramírez dijo: Una posible solución podría estar por instalar xbacklight, para luego ponerlo a que se inicie en el arranque. El comando siguiente establece el brillo en 60 en una escala de 0 a 100 xbacklight -set 60 En gnomeaplicaciones al inicio Hola: GRACIAS por el consejo del xbacklight. YA lo habia probado antes de preguntar y NO funcionó en esa máquina. En otras máquinas SI funciona. Pues lo instalé para comparar en máquinas en las que no hay problemas de video y en ellas el programa funciona de maravillas. Pero... en la Notebook no funciona... :-( Es un problema raro... porque funciona todo bien excepto esta porquería del brillo que me está dejando los ojos como dos huevos porque el brillo es muy intenso (el más alto) para colmo como yo trabajo en edición digital (se trabaja casi a oscuras) ese brillo me mata. Bueno... gracias por el dato. Veré que hago... Quizás instale todo de nuevo porque, si funciona bien, me ahorraré tiempo. Lo que que estoy viendo es la posibilidad de instalar un Debian SUPER-MINIMO (con los paquetes indispensables) y desde allí instalar OpenBOX y los programas que uso porque todas las distros que he probado será muy lindas pero vienen con muchas cosas que para mi no me sirven o no me gustan por lo tanto pierdo mas tiempo desinstalando cosas que han venido con la distro que el tiempo demandado en la instalación. Parece mentira pero es así SAludos a todos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1418865559.68862.yahoomailba...@web140604.mail.bf1.yahoo.com
[OT] Fwd: Un informático en el lado del mal. ¿Eres muy mayor para dedicarte a Seguridad Informática?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hola, Hoy me llegó este correo a la bandeja de entrada, y me pareció una buena idea compartirlo con ustedes. Un saludo, - Mensaje reenviado Asunto: Un informático en el lado del mal. ¿Eres muy mayor para dedicarte a Seguridad Informática? Fecha: Tue, 16 Dec 2014 20:08:13 + De: Un informático en el lado del mal noreply+feedpr...@google.com Responder-a:: Un informático en el lado del mal ch...@informatica64.com A: franci...@openmailbox.org Un informtico en el lado del mal /// Eres muy mayor para dedicarte a Seguridad Informtica? Posted: 15 Dec 2014 09:11 PM PST http://feedproxy.google.com/~r/ElLadoDelMal/~3/7FzJr7pyVNs/eres-muy-mayor-para-dedicarte-seguridad.html?utm_source=feedburnerutm_medium=email Una de las preguntas que muchas veces acaban por caer en mi buzón de correo electrónico es la de gente que me pregunta a qué edad comencé yo a trabajar en seguridad informática para saber si ellos son muy mayores para comenzar ahora con su edad. La mayoría suele decir cosas como soy muy mayor, ya es tarde para mí, o no empecé cuando tenía que haberlo hecho. Esos correos electrónicos vienen a decir siempre eso de ¿Soy muy mayor para dedicarme a Seguridad Informática?. Figura 1: ¿Soy mayor para aprender Seguridad Informática? Yo empecé en seguridad informática tarde, aunque si bien es cierto que en el mundo de la informática empecé bastante pronto. La primera vez que hice algo de hacking tendría unos 22 o 23 años ya que hasta ese tiempo me había dedicado a aprender informática en general y bases de datos, redes, programación, diseño gráfico, programación web y sistemas operativos en particular (por decir algo como particular). Lo cierto es que si tienes 40 años y llevas 15 o 16 años trabajando en el sector de la informática sin que haya tenido nada que ver con la seguridad informática no estás para nada en un estado tardío para comenzar. No pienso que así sea para nada, y espero que no lo pienses tú, pues te queda aún un cuarto de siglo por delante por trabajar. Más vale que te sientas joven y en forma, pues estás en la plenitud de tu vida laboral. Figura 2: Aprender nuevos conceptos es bueno para tu trabajo actual y futuro ¿Crees que sacarse una carrera universitaria a los 45 años es tarde? ¿Que aprender algo nuevo con 50 años es baldío? ¿Aprender a programar a los 55 años es imposible? Me pregunto ¿es que ya no te funciona el cerebro? Aprender seguridad informática requiera algo de tiempo, que es el principal problema. Pero este problema lo tendrías igualmente si quieres aprender cualquier otro area profesional. Necesitas tiempo para leer, para practicar y para coger cierta experiencia, pero nada más. Es cierto que si has dormido tu cerebro haciéndolo vago sin forzarlo a estudiar cosas nuevas durante un periodo de tiempo, entonces tal vez necesites despertarlo y ponerlo a funcionar. Además, seguro que cuando te pongas a aprender, los jóvenes de 18 años pueden estar más sueltos y rápidos que tú al principio... ¿y qué? Tómate tú tiempo, lee, estudia, aprende y sigue tu camino. Tienes madurez, experiencia profesional en muchos otros campos, y si has desarrollado habilidades como la constancia, la responsabilidad o la planificación, te puedes marcar tus propios objetivos y llegar más lejos de lo que te imaginabas. Figura 3: Leer es cómo la gente instala nuevo software en su cerebroTú puedes aprender seguridad informática igual que un chaval de 20 años, y dentro de 10 años te tendrás que adaptar al nuevo entorno. No te hagas reactivo al cambio. Que no te de vergüenza ser un principiante a los 40 años...De hecho es lo que más mola. Aprender algo nuevo desde cero. Disfrútalo sin prejuicios y vívelo con pasión. Aprende a hacer ataques de redes, cómo se hace un pentesting o a programar tus propias apps. No es tan difícil y te juro que es divertido. El día que ya no te guste este mundo de teclas y bits, entonces ese día deberás pensar en buscarte otra profesión, pero no me cuentes milongas de tengo 40 años, ya no tengo edad para programar. ¡Ja! ¡ni que programar fuera solo para jóvenes! Los buenos programadores están rifados, no importa los años que tengan, así que sé bueno en tu trabajo, disfrútalo con pasión y podrás sacarlo. Figura 4: En esta profesión nunca se deja de aprender Eso sí, solo si tú quieres salir de tu zona de confort. Si tú realmente quieres aprender y estás dispuesto a comenzar por el Hello World y no parar de interiorizar cosas nuevas nunca. Estudiar es algo que debe ser constante en tu vida, que debe seguir siendo un objetivo de tu día a día a pesar de que ya tengas un buen trabajo, o de que estés muy ocupado en tu vida. En el momento que lo dejes y te bajes del tren, será tu elección y de nadie más. No será de la edad, no será del tiempo que te queda, no será por que no puedes a tu edad. No será porque eres mayor. Sera porque ya no quieres. Más rápido o más despacio, tú puedes.
[OFF TOPIC] Tips para badblocks
Siempre ando buscando como hacer algo en internet y nunca aporto nada. Acá mis tips para usar badblocks, esta herramienta permite chequear si un disco tiene errores. http://www.emonge.com/doku.php/badblocks -- Esteban Monge Marín http://www.emonge.com e...@emonge.com mongejimene...@gmail.com estebanmo...@riseup.net Linux User: 478378 - Isaca COBIT - Cabinet Office ITIL Foundation - CompTIA A+ - Nagios Enterprises Certified Professional -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/747b3ed2105a2fb97c6eef498d4c7...@riseup.net
