?>/script>'; } ?> movimiento arriesgado ,pero estaria muy muy bien. Widgets Magazine

Autor Tema: movimiento arriesgado ,pero estaria muy muy bien.  (Leído 23946 veces)

0 Usuarios y 1 Visitante están viendo este tema.

*dudux

  • Visitante
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #20 en: 30-04-2012, 14:21 (Lunes) »
no se como explicarlo , y ademas a la mayoria esto os resbalara bastante,.

se me ha ocurrido lo siguiente...

cuando compilados un soft o libreria mediante "make" , como alguno ya sabra se le puede añadir la cantidad de hilos...acorde a los nucleos de nuetsra cpu.

si tenemos un quad core...seria

make -j4

---ayer compile un kernel en 15 minutos...me quede loco , esto me lo enseño berni ,(staff) , pero no lo recorde hata ayer..casi nunca lo usaba..y la verdad la diferencia es bestial.


se me ha pasado por la cabeza hacer lo siguiente.


el ejecutable "make" ...RENOMBRARLO A    MAKE-ORIGINAL

despues un script ..llamado obviamente make ...con la orden dentro

de buscar en proc la cantidad de nucleos y ejecutar despues

make-original -j-cantidad de nucleos detectados


asi , aunque nuestro comportamiento seria el mismo de siempre  (make)  ..el script se encargaria de calcular las cpu del sistema ..y añadirloa la orden make.


---------------------------------------------------------------------------------------------------------------------
a ver que me deciis.

Esta aprovecha todos los hilos que pueda.........aunque no podras hacer nada al mismo tiempo......

make -j

Desconectado USUARIONUEVO

  • Moderador
  • *
  • Mensajes: 15985
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #21 en: 30-04-2012, 14:26 (Lunes) »
no se como explicarlo , y ademas a la mayoria esto os resbalara bastante,.

se me ha ocurrido lo siguiente...

cuando compilados un soft o libreria mediante "make" , como alguno ya sabra se le puede añadir la cantidad de hilos...acorde a los nucleos de nuetsra cpu.

si tenemos un quad core...seria

make -j4

---ayer compile un kernel en 15 minutos...me quede loco , esto me lo enseño berni ,(staff) , pero no lo recorde hata ayer..casi nunca lo usaba..y la verdad la diferencia es bestial.


se me ha pasado por la cabeza hacer lo siguiente.


el ejecutable "make" ...RENOMBRARLO A    MAKE-ORIGINAL

despues un script ..llamado obviamente make ...con la orden dentro

de buscar en proc la cantidad de nucleos y ejecutar despues

make-original -j-cantidad de nucleos detectados


asi , aunque nuestro comportamiento seria el mismo de siempre  (make)  ..el script se encargaria de calcular las cpu del sistema ..y añadirloa la orden make.


---------------------------------------------------------------------------------------------------------------------
a ver que me deciis.

Esta aprovecha todos los hilos que pueda.........aunque no podras hacer nada al mismo tiempo......

make -j

si se trataba de eso..de que siempre buscara el numero de cpus y tal..pero

con el core i3 , podia estar compilando el kernel y hacer otras cosas...como crear modulos xzm , comprimir descomprimir.

la mejor opcion es crear el supermake como script, y utlizarlo solo en tareas pesadas.

por ejemplo utilizar
make -j4

para compilar aicrack ,,es una tonteria...no ganas mas que un segundo..ajjaja.

warcry

  • Visitante
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #22 en: 30-04-2012, 19:01 (Lunes) »

lo del kernel de 64 bits ...es un experimento que tengo a medias , con ayuda de geminis_demon , y supremo12345.

si os mudáis al 64 bits, entiendo que todos los módulos actuales quedarían inservibles??

Desconectado geminis_demon

  • Colaborador
  • *
  • Mensajes: 2378
  • Prácticas precisas precisan práctica
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #23 en: 30-04-2012, 19:53 (Lunes) »

lo del kernel de 64 bits ...es un experimento que tengo a medias , con ayuda de geminis_demon , y supremo12345.

si os mudáis al 64 bits, entiendo que todos los módulos actuales quedarían inservibles??

Correcto, pero con el wifislax package manager ( que ya está presente en wifislax 4.1 ), hacer nuevos modulos será coser y cantar, además haré un minitutorial explicando como se usa.
« Última modificación: 30-04-2012, 20:13 (Lunes) por geminis_demon »

MarArrOrt

  • Visitante
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #24 en: 30-04-2012, 21:59 (Lunes) »
Hola, me paso a comentar que teneis que comprobar que, al contrario que algunas aplicaciones, el detector no confunda los nucleos con los hilos que tienen algunos procesadores de Intel. Por ejemplo, mi procesador i7 2670QM tiene 4 nucleos i 8 hilos, pero Ubuntu me detecta 8 nucleos.

warcry

  • Visitante
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #25 en: 30-04-2012, 22:24 (Lunes) »

Correcto, pero con el wifislax package manager ( que ya está presente en wifislax 4.1 ), hacer nuevos modulos será coser y cantar, además haré un minitutorial explicando como se usa.

sabeis la que acabais de liar...

he probado el wifislax package manager, y es una gozada acabo de instalar el hardinfo (no esta mu logrado el tema de los sensores de temperatura en linux, el everest me los muestra todos...)

mi pregunta es cuando tu haces un modulo no comprueba las dependencias ni descarga las librerias con lo cual nos puede llevar a error no¿?

bien por otra parte y dado que yo tengo un phenom de 4 nucleos de 2,2 ghz la migracion a 64 bits no me supone nada pero sois conscientes que dejais sin soporte a todo aquel que tenga una maquina algo antigua, y ese era el principal problema de wifiway 3.x que el kernel dejaba fuera a bastantes dispositivos

Desconectado USUARIONUEVO

  • Moderador
  • *
  • Mensajes: 15985
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #26 en: 30-04-2012, 22:38 (Lunes) »

Correcto, pero con el wifislax package manager ( que ya está presente en wifislax 4.1 ), hacer nuevos modulos será coser y cantar, además haré un minitutorial explicando como se usa.

sabeis la que acabais de liar...

he probado el wifislax package manager, y es una gozada acabo de instalar el hardinfo (no esta mu logrado el tema de los sensores de temperatura en linux, el everest me los muestra todos...)

mi pregunta es cuando tu haces un modulo no comprueba las dependencias ni descarga las librerias con lo cual nos puede llevar a error no¿?

bien por otra parte y dado que yo tengo un phenom de 4 nucleos de 2,2 ghz la migracion a 64 bits no me supone nada pero sois conscientes que dejais sin soporte a todo aquel que tenga una maquina algo antigua, y ese era el principal problema de wifiway 3.x que el kernel dejaba fuera a bastantes dispositivos

y quien a dicho que se vaya a abandonar los 32bits ¿

serie 4 de wifislax a 32bits
serie 5 de wifislax a 64bits

Desconectado USUARIONUEVO

  • Moderador
  • *
  • Mensajes: 15985
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #27 en: 30-04-2012, 22:43 (Lunes) »
por otra parte , lo de los modulos mediante el gesto gslapt.


lo mas aconsejable, es ... arrancar la iso de serie ,,,

y sin modulos extras , entonces ya si , a trastear ,pero solo lo que queremos conseguir.

si por ejmplo quiero clementine..

me fijo que alguna de las que me da como resultado al buscAR ...me pone las dependencias ...esa es buena..puesto que bajara todo lo necesario

podemos marcar que solo descargue los paquetes...

y despues utlizar la opcion de crear xzm desde tzx descargados....esta en el menu del gestor de paquetes...

muy important tras crear el xzm  , ... limpiar el directorio , para que si vamos a crear otro , no se junten los paquetes de los dos .


en serio es muy facil...muy muy facil.

dedicadle unos minutos a comprender como funciona ... eso si , no inetnteis meter kde4 , por que rompereis..es lo unico que no podeis tocar.


pero no pasa na, la version de 64bits en la que estamos currando lleva kde4.  ;D

Desconectado geminis_demon

  • Colaborador
  • *
  • Mensajes: 2378
  • Prácticas precisas precisan práctica
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #28 en: 30-04-2012, 22:49 (Lunes) »
mi pregunta es cuando tu haces un modulo no comprueba las dependencias ni descarga las librerias con lo cual nos puede llevar a error no¿?

Pues si que devería resolver y descargar las dependencias, ¿estas seguro de que no lo hace?

Desconectado USUARIONUEVO

  • Moderador
  • *
  • Mensajes: 15985
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #29 en: 30-04-2012, 22:52 (Lunes) »
mi pregunta es cuando tu haces un modulo no comprueba las dependencias ni descarga las librerias con lo cual nos puede llevar a error no¿?

Pues si que devería resolver y descargar las dependencias, ¿estas seguro de que no lo hace?


es normal.......

cuando 3 o 4 sources devuelven el paquete buscado , los hay que si dan las dependencias y los hay que no ..si marcas uno de los resultados ,,de los que no da dependencias, solo te bajara ese marcado y no las dependencias...

es lo que te comente que me pasaba a mi una vez que lo probe, y la causa de que no lo llegasea sacar a modulo ...por aquel entonces no comprendia lo que pasaba.

Desconectado geminis_demon

  • Colaborador
  • *
  • Mensajes: 2378
  • Prácticas precisas precisan práctica
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #30 en: 30-04-2012, 22:59 (Lunes) »
Claro pero por eso estuvimos buscando los sources que no resolvian dependencias y quitamos los que encontramos, no? Si todavia quedan, habría que detectarlos y quitarlos de en medio, dejando solo los que resuelvan dependencias.

warcry

  • Visitante
Re: Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #31 en: 30-04-2012, 23:01 (Lunes) »
Tranquilos, que todavía no lo he probado muy a fondo, por eso pregunto, ya que cuando he hecho el módulo del hardinfo me ha parecido que se descargaba menos cosas que cuando lo he instalado, pero no he llegado a probar el módulo

yo también estoy en el móvil
saludos

Desconectado USUARIONUEVO

  • Moderador
  • *
  • Mensajes: 15985
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #32 en: 30-04-2012, 23:18 (Lunes) »
Claro pero por eso estuvimos buscando los sources que no resolvian dependencias y quitamos los que encontramos, no? Si todavia quedan, habría que detectarlos y quitarlos de en medio, dejando solo los que resuelvan dependencias.


pues para empezar y lo mas grave es que las oficiales no resuelven dependencias.

suelen ser las de slacky y sbo ,las que si lo hacen.

Desconectado geminis_demon

  • Colaborador
  • *
  • Mensajes: 2378
  • Prácticas precisas precisan práctica
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #33 en: 01-05-2012, 00:20 (Martes) »
Pues tio, es triste pero cierto, las oficiales no resuelven dependencias.. y hay 2 mas que tampoco lo hacen.

La ultima vez no lo miré tan detenidamente pero ahora me he puesto a comprobarlas una a una, y estos son los resultados:

SOURCE=ftp://ftp.slackware.com/pub/slackware/slackware-13.37/:OFFICIAL  <- NO RESUELVE
SOURCE=http://darkstar.ist.utl.pt/slackware/addon/slacky/slackware-13.37/  <- SI RESUELVE
SOURCE=http://repository.slacky.eu/slackware-13.37/  <- SI RESUELVE
SOURCE=http://darkstar.ist.utl.pt/slackware/addon/gnomeslackbuild/gsb-3.2_slackware-13.37/  <- SI RESUELVE
SOURCE=http://darkstar.ist.utl.pt/slackware/addon/gsb/gsb-3.2_slackware-13.37/  <- SI RESUELVE
SOURCE=ftp://ftp.slackware.org.uk/salix/i486/13.37/  <- SI RESUELVE
SOURCE=ftp://slackware.mirrors.tds.net/pub/slackware/slackware-13.37/  <- NO RESUELVE
SOURCE=ftp://ftp.fu-berlin.de/unix/linux/mirrors/slackware/slackware-13.37/  <- NO RESUELVE

Desconectado USUARIONUEVO

  • Moderador
  • *
  • Mensajes: 15985
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #34 en: 01-05-2012, 00:43 (Martes) »
Pues tio, es triste pero cierto, las oficiales no resuelven dependencias.. y hay 2 mas que tampoco lo hacen.

La ultima vez no lo miré tan detenidamente pero ahora me he puesto a comprobarlas una a una, y estos son los resultados:

SOURCE=ftp://ftp.slackware.com/pub/slackware/slackware-13.37/:OFFICIAL  <- NO RESUELVE
SOURCE=http://darkstar.ist.utl.pt/slackware/addon/slacky/slackware-13.37/  <- SI RESUELVE
SOURCE=http://repository.slacky.eu/slackware-13.37/  <- SI RESUELVE
SOURCE=http://darkstar.ist.utl.pt/slackware/addon/gnomeslackbuild/gsb-3.2_slackware-13.37/  <- SI RESUELVE
SOURCE=http://darkstar.ist.utl.pt/slackware/addon/gsb/gsb-3.2_slackware-13.37/  <- SI RESUELVE
SOURCE=ftp://ftp.slackware.org.uk/salix/i486/13.37/  <- SI RESUELVE
SOURCE=ftp://slackware.mirrors.tds.net/pub/slackware/slackware-13.37/  <- NO RESUELVE
SOURCE=ftp://ftp.fu-berlin.de/unix/linux/mirrors/slackware/slackware-13.37/  <- NO RESUELVE


pero hay que dejaralas igualmente , por que las que si resuelven , pueden no tener todos los packetes...recuerda que ya te dije que justamente las oficiales eran ademas de todo lo que se habla aqui SON LAS MAS LENTAS , a la hora de rsponder las peticiones de listado.

pero retipo , son necesarias al menos las 3 oficiales...

podiamos dejar las 3 oficiales..y de las otras solo las que si resuelven.

lo dejo en tu mano ...yo estoy liadisimio con wicd  , ahora no me va NINGUNO ..jajajajaj diosss

Desconectado geminis_demon

  • Colaborador
  • *
  • Mensajes: 2378
  • Prácticas precisas precisan práctica
Re: movimiento arriesgado ,pero estaria muy muy bien.
« Respuesta #35 en: 01-05-2012, 01:02 (Martes) »
jajaja ok, ya te sigo informando por privado que este tema ya está mas que desvirtuado.