Mensajes

Como dice anteriormente iba a hacer unas pruebas y las hice, lo único que funciona a mi para que mis procesadores trabajen bien es instalar mesa-utils.

http://packages.debian.org/squeeze/amd64/mesa-utils/filelist

en todos los sistemas que conozco es así ... es un bajón que pienses que tres binarios (particularmente esos, que simplemente son samples o "pruebas") hagan funcionar mágicamente un stack gráfico.

Es muy probable que sea el kernel. A mi con ArchLinux me pasó algo similar. Si el ordenador tiene un procesador bastante nuevo, la explicación es que desde el kernel tres y pico (3.3-3.4, por ahi) el kernel no gestiona bien la freqüencia del procesador (cpufreq). Los procesadores multicore que no están activos corren generalemente a 800Mhz para disminuir el consumo de electricidad. El kernel era incapaz de gestionar esto y independientemente de si corrias algo pesado o no, todos los cores corrian a la máxima capacidad (2.5-3 dependiendo del procesador).

Incapaz? nonono, me parece que estamos pifiando ... esto no le corresponde al kernel, sino a los daemons que son los que analizan el sistema y en base a eso USAN esta facilidad del kernel para modificar las frecuencias.
Podés actualizar tranquilamente cambiando el "perfil" a performance con el comando cpufreq-set o el equivalente de cpupower ...

Saludos.

P.S → ¿Sobre 50-60 grados? buscá las temperaturas operativas de la CPU que tenés ... podés estar cometiendo terrible negligencia

[privativo]

Edit: agregué algo después de ver el screencast, está marcado en el post como "[Edit]"

Estoy de acuerdo con Alex Mtx. Las temperaturas que veo a bote pronto son correctas hasta donde llega mi conocimiento, 40 ºC está bien para un portátil.

Más que bien.

1- en mi portatil con 2 gb de ram, se me congela por minutos si lo uso en modo bateria, si lo uso en modo corriente electrica no tengo tantas congelaciones pero los juegos anda muy lentos y se me paran. (Ubuntu 12.04). EN este pc uso drivers mantenidos privados de ATI, las actualizaciones lo hacén mas lento aún.

OK, estás hablando del driver privativo de AMD (que IMHO es muy malo)

En ambos casos use los juegos assault cube y warzone 2100 como veiculo de experiencia.
En ambos casos he instalado xorg edgers despues de ese ppa adicionado y de actualizar se me corrompe el ambiente gráfico me queda negro en el caso del desk o sea que despues ando editando xorg y puragando el ppa xorg edgers

Sabías que Xorg edgers es un ppa para drivers experimentales, no?
Que se te corrompa el ambiente gráfico es algo totalmente esperable de ese PPA.

Te traduzco : https://launchpad.net/~xorg-edgers

Packages for those who think development versions, experimental and unstable are for old ladies. We want our crack straight from upstream git! Well, straight, we want it built and packaged so we don't need to know what we're doing, except that we will break our X and put our computers on fire.

[...]

Paquetes para esos que piensan que las versiones de desarrollo, experimentales e inestables son para señoras mayores. Queremos nuestro crack directo desde el git upstream ! Bueno, simple, queremos compilarlo y empaquetarlo de manera que no necesitemos saber lo que hacemos, excepto que vá a romper nuestros X y prender fuego nuestras computadoras

"git upstream" se usa para referirse al código "en vivo" mientras se modifica.

Vos fijate.

EL problema es en la gestion del processador por lo que dicen y creo que los drivers gallium hacen que haya una mal uso de la cpu porque no hacen el uso correcto del driver.

Ajá ... no estarás corriendo el driver LLVMPipe? eso usa la CPU en vez de la GPU
quizá por eso tu CPU está ardiendo en llamas.

LO que voy a hacer es instalar el mint en el portatil y os doyel feedback. Hay mas gente como yo reportando lentitud de Ubuntu con nuevos kernels, pero no entiendo como con xfce o lxde me va elnto y colapsa el procesador.

¿Mint está basado en Debian? si no te anda el driver radeon QUIZÁ es por que el kernel usado en Debian está limpiado de todo firmware privativo ... los de radeon incluídos (se instalan por aparte)

http://wiki.debian.org/Firmware/

[Edit]: portaro, acabo de leer que usás un chipset r200 en el glxinfo ... insisto con que revises este link

Lo primero es ver que tengas los debidos paquetes (mesa/drm/dri/y el driver de xorg); revisar el log de xorg y el glGetString() con glxinfo (vendor, renderer, version, blah)

Código (bash) [Seleccionar] Expandir

grep LoadModule /var/log/Xorg.0.log
glxinfo | grep OpenGL


reinstalar mesa-utils,

En realidad mesa utils consta de más o menos esto y un par de demos más, lo que lo hizo correr seguro fue alguna dependencia.

Código [Seleccionar] Expandir

alex@Sylbit ~ $ equery files x11-apps/mesa-progs
* Searching for mesa-progs in x11-apps ...
* Contents of x11-apps/mesa-progs-8.0.1:
/usr
/usr/bin
/usr/bin/glxgears
/usr/bin/glxinfo


Asi que quien tenia razon eran tanto Alex MX como tonigellida.

No se trata de tener la razón .... hombre, vá por otro lado la cosa
Puedo sonar muy tajante por escrito, pero nada que ver con mi verdadera intención ... y quienes conozco (o con quienes compartí una charla de voz por skype o loquesea lo notan al toque)

Saludos.

P.S → lo que dice @pandacriss vale la pena echarle una mirada ... Optimus y similares son un toda una problemática para el stack gráfico y las distribuciones

[como dicen que este problema (el de mala gestion de procesador) se debe a los nuevos drivers gallium.]

Lo que yo hice fue volver a ubuntu 10.04 - Ultimate edition 2.6.3 que es de facil instalacion y trae ya muchos programas puestos asi que para ponerlo como me gusta a mi me lleva menos tiempo, hice esto porque pienso que los nuevos kernels van a dar este problema en los Intel mientras no haya un patch asi como dicen que este problema (el de mala gestion de procesador) se debe a los nuevos drivers gallium.

STOP ahí mismo .... Intel no posee drivers Gallium3D; i915 tiene un driver Gallium3D no oficial, pero al no ser oficial no se usa en general (creo que Google lo mantiene para sus Chromebooks si no me falla la memoria)
Los drivers Gallium si bien tienen un pequeño overhead al usar state trackers y mucho código de alto nivel en vez de chanchadas de bajo nivel específica al driver ... tampoco es tanto el impacto

Pensá que r300/r600 en muchos benchmarks compite contra Catalyst o lo supera ... y ES UN DRIVER GALLIUM3D
Si querés más información sobre Gallium, por favor pedila ... pero no repitas mala información

Me parece algo casi estupido que la comunidad de pcs más viejos  estén sufriendo esto, si nos vamos a poner a hacer 64 bits, nuevos drivers adicionados etc por lo menos tengamos el saber de considerar a los pcs que desde mucho tiempo atras se unieron a Linux por medio de sus users y si sabian mantenerlos con buenas prestaciones no deberia ser porque se van a adecuar nuevos drivers y nuevas estructuras que se va  generar un problema de este tipo..

A mí me parece estúpido instalar software con innovaciones, con tecnologías modernas, pensado para hardware nuevo y demás y pretender que corra igual en el hardware viejo como en el nuevo.
Siempre podés instalar una distro en su vieja versión o usar de las livianas; pero basta de ponerle lastre a linux con semejante idiotez.

NO PUEDE SER que no podamos levantar el piso al pedir aceleración gráfica para las interfaces ... incluso los celulares más pedorros de hace años la tienen.
Es ilógico pedir que un escritorio moderno acelerado por hardware corra en hardware de hace más de 5 años como corre en el hardware nuevo ... no existe eso

STOP THIS MADNESS.

El FLOSS siempre fue contemplativo con las máquinas viejas, pero hasta un punto ....dejemos de tirar tanto de la cuerda que mantener lo nuevo andando en lo viejo SÓLO ES LASTRE que daña al mundo del opensource y le roba tiempo a lxs desarrolladorxs de innovar.

Hay 800 entornos de escritorio .... Unity/KDE/GNOME son muy avanzados para tu hardware? usá algo apropiado a tu hardware y punto.

Esto afecta a todos Ubuntus y debians con kernels 3, por ejemplo tu estas bajando comfusion o galpon pensando esto me sera bueno porque mi pc no da con unity o gnome 3 ye speras que funcionen bien todas las aplicaciones incluido algunos juegos que siempre usaste  pero no te vale la pena porque vas a tener a causa de ese problema el procesador colpasado y los juegos seran siempre lentos quando requieran media aceleracion gráfica .

PAra solucinarlo dicen que es hacer con que el xorg reconozca a intel pero eso ya me ultrapasa,  y removiendo el xserver.

Intel tiene un driver libre ... no hay que tocar absolutamente nada, anda sin problemas.
X.Org autodetecta los drivers libres y elige según corresponda.

Todas las distros traen los drivers libres radeon, nouveau e intel por default.

Salvo distros como Trisquel que limpian los firmwares (y esto puede afectar más a radeon y los drivers de las ultimas placas de nouveau).

Bueno seguro que los usuarios de Mac OS X caen  xD.

¿Hay alguna base por donde pueda empezar con los rootkit?

¿En modo kernel? Tendrías que arrancar con un libro sobre desarrollo sobre el kernel .... y acá viene la mala noticia: no es fácil (dependiendo de qué facilidades y qué uses del kernel).
la KBI (la interfaz binaria del kernel) de Linux es bastane inestable y esto está documentado en el tree del kernel : Documentation/stable_api_nonsense.txt
En la práctica tenés que apuntar a una versión del kernel y no esperar en un 100% que funcione en otras ...

Podés de última tomar un acercamiento más tímido y seguir jugando en modo usuario ... podés inspeccionar qué software querés engañar e interceptar librerías como libproc.so por un mecanismo  LD_PRELOAD o moviendo el enlace simbólico de esta librería por ld (y chequeando constantemente que el gestor de paquete no te lo cambie)

Podés también reemplazar binarios; son formas muy cutres que quizá en un desktop no duran mucho por la naturaleza de constante actualización que tiene (excepto sistemas oldstable como debian), pero te aseguro que en algún servidor de producción donde quien esté a cargo no tenga la viveza de chequear el sistema base contra checksums o use algo como los snapshots de ZFS ...  vas a estar bien

Tenés MUCHAS posibilidades siendo root

No tiene ninguna función podría crear alguna con execve pero bueno, conecto con netcat.

¿Probaste armarla en C? En Assembly te vas a volver loco incluso para algo tan chiquito como eso si no estás acostumbrado a desarrollar sobre ese lenguaje.

Nota: Y perdés portabilidad

P.D: El código es muy básico, me diste una solución para ps, pero que pasa con netstat?

Misma respuesta que para ps

Ademas en ese texto se interceptan las llamadas al sistema, creo que es lo que buscabas.

Si, pero que mire el link que le dejé de stackoverflow para complementar ... por que la tabla de syscalls se la marcó como readonly

Saludos.

Buscá el paquete nvidia-settings y ahí podés configurar la resolución ... pero primero borrá ese xorg.conf y seguido de eso ejecutá nvidia-xconfig.

Saludos.

Cuando miro las conexiones activas hay aparece, y en ps también, la oculto cambiando el nombre por un proceso común, pero es muy cutre no?

¿Toqueteando argv? si, ponele que es muy cutre ... pero hay gente que pisa el palito

Hay una práctica llamada "Hooking" si no me equivoco, pero todo es para windows, alguien puede echarme un cable para un unix-like?

http://www.linuxforu.com/2011/08/lets-hook-a-library-function/
http://stackoverflow.com/questions/2103315/linux-kernel-system-call-hooking-example

(Algo como lo segundo te interesaría en realidad, pero ahí ya hablamos de rootkit ... de una manera u otra necesitás ser root y los códigos son poco felices)

P.D: Muestro el código si alguien quiere.

Sería genial ... se te puede corregir y enseñar mucho más si mostrás el código.

Saludos.

¿estás haciendo literalmente esto?

Código (bash) [Seleccionar] Expandir

pkg_add -r en Freebsd 9 rc3

Por que si es así, te comento que tal paquete no existe ni existirá ...
Tengo la sensación de que querés actualizar el sistema, pero lo estás haciendo de la manera que se hace en linux y quizá no entendés que en FreeBSD el "sistema operativo base" y todo lo que vos le instalás arriba con pkg_add o vía ports se instala por separado y se maneja por separado.

pkg_add no es un equivalente a algo como apt-get/yum/zypper y no toca componentes del sistema, por lo que cambiarle el "repositorio" de FreeBSD 8.2 a 9.x no ganás nada.
Tu sistema FreeBSD binariamente vá a seguir siendo 8.2, pero por ejemplo; imaginate que vas a bajar los binarios del Firefox, pkg_add baja el compilado contra la 9.x de FreeBSD y eso lo vas a seguir corriendo sobre la 8.2 y puede no funcionar ese programa (o comportarse mal)

Decidí explicártelo de manera simple y gráfica (Kolourpaint ftw !!)



En linux tendría que estar todo metido dentro de un solo cuadradito, por que se maneja todo junto de un solo lugar y no se separa nada.
Lo que querés usar, como ves en la gráfica ... es freebsd-update(8)


Saludos.

Hoy me hago un tiempito y veo esa guía, aunque sería genial que tomes una versión más nueva como la rama 9.x que usa bsdinstall y genera lindos logs de instalación.
sysinstall está declarado como obsoleto (tiene sus añares) y se recomienda a todxs alejarse de ese sistema de instalador x')

Saludos.

disculpen, por que habra cierta rivalidad entre Bsd y Linux? los usuarios de bsd llaman noobs o toys a los de linux......lo que me da a entender que es mejor el bsd, sera cierto?

Wow, qué poquito me ando pasando por el foro (bueno, cerca de final de año unx siempre tiene el tiempo en cuentagotas, chanfles !).
A ver, es un tema un poco complejo ... la rivalidad en realidad pasa mucho por un tema de licencias y no es tanto entre desarrolladores/comunidad de Linux, sino de GNU ... todxs los demás en realidad están "en el medio" y repiten lo que un grupo u otro dice.

Aunque el licenciamiento es uno de los motivos, otros es que Linux cada vez se fue distanciando más de la imagen de un sistema Unix tradicional al incorporar tecnologías como systemd (con su journal y gestor de sesiones) que requieren de cosas específicas de Linux y no son amigables con otras plataformas ... también tenés refritos de argumentos de cómo en linux todo el software está "tightly coupled", es decir que hay fuerte relación entre componentes importantes del sistema con cosas como Firefox por que justamente no hay una separación de "sistema base" de todo lo que demás que instalás (y con el famoso merge de fedora a /usr que otras distros andan contemplando, se hace más difícil separar un sistema base del resto del software).
Otro ejemplo es que la comunidad de GNU/Linux es más tolerante con los hacks y soluciones temporarias a los problemas (ya que el código se está moviendo todo el tiempo, y es el motivo por lo que no tienen KBI estable), en FreeBSD se prefieren soluciones más elegantes a los problemas o directamente nada (hay KBI mucho más estable y el código se mueve a otro ritmo, lógico ) ... aunque esto genere que las cosas tarden un poco más en funcionar.

También tenés diferencias desde lo que es el governance (el sistema de "dictadores benevolentes" de Linux vs el sistema más democrático de FreeBSD), aunque no se suele escuchar mucho en las discusiones al respecto.

En fin ... son muchos temas con los que se arman flame war y esos son los primeros que me llegan a la cabeza con una pregunta tan amplia, aunque hay muchos motivos más por los que hay fricción.

Un poquito de eso se charló en este hilo, fijate:
http://foro.elhacker.net/unixunixlike/porque_el_sistema_de_freebsd_tiene_un_nucleo_mas_maduro-t362631.0.html


Pasaba súper rápido ... perdón por la brevedad de la respuesta, pero si tenés alguna otra duda la vemos (que justo hoy tengo examen),

Saludos.

Hola !!
¿Podrías detallar un poquito cómo instalaste? (las opciones que elegiste)
¿Qué versión de FreeBSD?
¿Cómo estaban las particiones antes de instalar?
¿Cómo particionaste?
¿Qué esquema de particiones usás?
¿Instalaste el boot loader de FreeBSD o dejaste el grub de Debian?

Si tenías datos en ese disco ... ¿Tenés backups?

Por ahora eso.

Saludos.