Solo ingresa a esta direccion
http://www.puydi.com/?referido=ajo
y prueba
viernes, 25 de enero de 2008
lunes, 3 de diciembre de 2007
Busquedas por categoria en la wikipedia
viernes, 9 de noviembre de 2007
DESCARGAR JUEGO DE LA PANTERA ROSA
miércoles, 4 de julio de 2007
Como eliminar Gvulcan VII
En algun foro encontre lo siguiente para eliminar el G-Vulcan VII
el virus g vulcan afecta los archivos de word (.doc), los oculta y los reemplaza por el virus (.exe), el virus lo activamos cada vez que abrimos una carpeta y automáticamente todos los archivos word que hay en ella se dañan, este virus hace que se nos apague el computador, lo cual es muy molesto, aparte de que ningún antivirus lo detecta, Nod32 detecta la archivos de word con extension .exe y dice algo como aplicacion de VBasic potencialmente peligrosa, te preguntara que debe hacer se eliminar o que depende de como lo configures.
para librarnos de este virus hagamos lo siguiente:
1. eliminar todos los archivos word infectados, los podemos reconocer porque todos pesan 52,0 kb, no hay que preocuparse por borrarlos pues los archivos originales están ocultos y se pueden recuperar.
2. el virus se ubica en c/windows/sistem32/com/inf/.ex... la carpeta inf esta oculta por lo que antes de buscarlo hay que ir a
herramientas/opciones de carpeta/ver y allí desactivar la opción (ocultar archivos protegidos por el sistema operativo), después de esto ya la puedes encontrar y debes eliminar la carpeta inf
3.hasta aquí el virus ya esta eliminado pero queda un problema al abrir las carpetas por lo que vamos al registro de windows para borrar el rastro, entonces hacemos lo siguiente:
inicio/ejecutar(escribimos "regedit" sin las comillas) y se nos abre el registro, allí vamos a
HKEY_CLASSES_ROOT/Directory/sh... allí cambiamos el predeterminado que dice "explorer" por "abrir" sin las comillas.
entre las carpetas que se abren abajo cuando estamos en shell hay una que dice explorer esa hay que eliminarla.
4. recuperar los archivos de word, como ya desactivaste la opción (ocultar archivos protegidos por el sistema operativo) de
opciones de carpeta, ahora ve a las carpetas donde tenias tus archivos y hay están todos, como no les pude quitar la opción que los mantiene ocultos lo mejor es abrirlos y guardarlos con otro nombre.
después de todo esto vas a opciones de carpeta y activas la opción que habías desactivado.
Has todo esto y ya tu computador vuelve a la normalidad, espero que les sirva.
También busca el archivo CMDOW.EXE y eleiminalo.
el virus g vulcan afecta los archivos de word (.doc), los oculta y los reemplaza por el virus (.exe), el virus lo activamos cada vez que abrimos una carpeta y automáticamente todos los archivos word que hay en ella se dañan, este virus hace que se nos apague el computador, lo cual es muy molesto, aparte de que ningún antivirus lo detecta, Nod32 detecta la archivos de word con extension .exe y dice algo como aplicacion de VBasic potencialmente peligrosa, te preguntara que debe hacer se eliminar o que depende de como lo configures.
para librarnos de este virus hagamos lo siguiente:
1. eliminar todos los archivos word infectados, los podemos reconocer porque todos pesan 52,0 kb, no hay que preocuparse por borrarlos pues los archivos originales están ocultos y se pueden recuperar.
2. el virus se ubica en c/windows/sistem32/com/inf/.ex... la carpeta inf esta oculta por lo que antes de buscarlo hay que ir a
herramientas/opciones de carpeta/ver y allí desactivar la opción (ocultar archivos protegidos por el sistema operativo), después de esto ya la puedes encontrar y debes eliminar la carpeta inf
3.hasta aquí el virus ya esta eliminado pero queda un problema al abrir las carpetas por lo que vamos al registro de windows para borrar el rastro, entonces hacemos lo siguiente:
inicio/ejecutar(escribimos "regedit" sin las comillas) y se nos abre el registro, allí vamos a
HKEY_CLASSES_ROOT/Directory/sh... allí cambiamos el predeterminado que dice "explorer" por "abrir" sin las comillas.
entre las carpetas que se abren abajo cuando estamos en shell hay una que dice explorer esa hay que eliminarla.
4. recuperar los archivos de word, como ya desactivaste la opción (ocultar archivos protegidos por el sistema operativo) de
opciones de carpeta, ahora ve a las carpetas donde tenias tus archivos y hay están todos, como no les pude quitar la opción que los mantiene ocultos lo mejor es abrirlos y guardarlos con otro nombre.
después de todo esto vas a opciones de carpeta y activas la opción que habías desactivado.
Has todo esto y ya tu computador vuelve a la normalidad, espero que les sirva.
También busca el archivo CMDOW.EXE y eleiminalo.
sábado, 2 de junio de 2007
autogenerador de repositorios para ubuntu
lunes, 14 de mayo de 2007
crear un buscador para wikipedia
Una forma de crear un índice de búsquedas para una bd de gran tamaño
AQUI ESTA EL TEXTO ORIGINAL
" Buscador para la wikipedia ( jugando con sphinx )
Desde hace algún tiempo, estaba pensando en hacer un buscador que indizara una gran cantidad de texto para comprobar que problemas reales se tienen cuando se trata con cantidades ingentes de información. Para ello habia dos opciones, escoger una base de datos con muchos registros o escoger una con menos registros pero si una cantidad grande de texto por cada uno de ellos.
Pero, ¿Cuantos son muchos registros?. Respecto a temas de indización y búsquedas de texto completo considero imposible (en cuanto a rendimiento) seguir usando el motor FULLTEXT de MySQL a partir de unos 300.000 registros.
Se sopesaron las diferentes bases de datos (por supuesto, libres) que podrían usarse para este estudio y se llego a dos en concreto:
* Wikipedia: unos 200.000 registros con mucho texto
* FreeDB: alrededor de 1.000.000 con poco texto
Teniendo en cuenta, que el FreeDB tiene muchos resultados duplicados y poco texto (que afearía un poco los resultados), decidí aventurarme por la wikipedia en castellano. El idioma también fue un detonante, ya que tenia intención de aplicarle despues un stemmer en castellano.
Al llegar a este punto solo queda definir las fases:
* Descarga e importación de la base de datos
* Configuración y construcción de los índices
* Creación de un pequeño sitio web para el buscador
Descarga e importación de la base de datos
La Wikipedia ofrece la descarga de unos dump de base de datos en formato xml (y algunos en sql), que luego pueden ser importados a la base de datos que tengamos de mediawiki. La página que explica todo esto es http://en.wikipedia.org/wiki/Wikipedia:Database_download.
Para ver que parte de la wikipedia necesitaba y no descargar absolutamente todo (pesa bastante), eché un ojo a este esquema de la base de datos .
Las tablas necesarias son únicamente:
* text: contiene el texto de las páginas
* page: contiene los titulos y ciertos parámetros como si es redirección o el espacio de nombres
* revision: contiene la referencia de revisiones
Los dump en castellano en cuestión se pueden bajar de http://download.wikimedia.org/eswiki/latest/.
Ponemos a bajar el dump que nos vale eswiki-latest-pages-articles.xml.bz2
Para poder crear las tablas de MySQL a partir del dump se tuvo que usar las herramientas de las que provee el propio software de MediaWiki. Así que tras descargarlo y desempaquetarlo, se configuran los parametros de acceso en el archivo LocalSettings.php y mediante el script importDump.php se rellenan las tablas deseadas tal y como se explica aqui.
Configuración y construcción de los índices
Aquí llega la parte seria, se va a indizar una tabla de 1GB de texto. Puntos interesantes a estudiar:
* Tamaño del índice
* Tiempo de construcción
* Tiempo de consulta del índice para consultas simples
* Tiempo de consulta del índice para consultas complejas (booleanas, frase...)
La herramienta que se va a usar es Sphinx, porque es la que conozco (obvio pero importante) y porque mas que el medio en este estudio ella es el fín. Es decir, lo que quiero demostrar es que esta herramienta es muy rápida aun cuando la cantidad de información es muy grande.
Se definen dos índices: uno para el título del artículo y otro para el contenido.
Definicion del titulo
PLAIN TEXT
CODE:
1.
source titulosrc
2.
{
3.
type = mysql
4.
sql_host = host
5.
sql_user = user
6.
sql_pass = pass
7.
sql_db = wikidb
8.
sql_port = 3306
9.
sql_query_pre =
10.
sql_query = \
11.
SELECT page_id, page_title \
12.
FROM page WHERE page_namespace = 0 \
13.
AND page_is_redirect = 0
14.
15.
}
16.
17.
index titulo
18.
{
19.
source = titulosrc
20.
path = /ruta-sphinx/var/data/titulo
21.
docinfo = extern
22.
morphology = none
23.
min_word_len = 1
24.
charset_type = utf-8
25.
charset_table = 0..9, A..Z->a..z, a..z, U+C9->U+E9, U+C1->U+E1, \
26.
U+DA->U+FA, U+D1->U+F1, U+D3->U+F3, U+CD->U+ED, U+E1, \
27.
U+E9, U+FA, U+F1, U+F3, U+ED
28.
}
Definicion del contenido
PLAIN TEXT
CODE:
1.
source contenidosrc
2.
{
3.
type = mysql
4.
sql_host = host
5.
sql_user = user
6.
sql_pass = pass
7.
sql_db = wikidb
8.
sql_port = 3306
9.
sql_query_pre =
10.
sql_query = \
11.
SELECT page_id, page_title,old_text \
12.
FROM page,revision,text \
13.
WHERE page_id = rev_page AND \
14.
rev_text_id = old_id AND \
15.
page_namespace = 0 \
16.
AND page_is_redirect = 0
17.
}
18.
index contenido
19.
{
20.
source = contenidosrc
21.
path = /ruta-sphinx/var/data/contenido
22.
docinfo = extern
23.
morphology = none
24.
min_word_len = 1
25.
charset_type = utf-8
26.
charset_table = 0..9, A..Z->a..z, _,a..z, U+C9->U+E9, U+C1->U+E1, \
27.
U+DA->U+FA, U+D1->U+F1, U+D3->U+F3, U+CD->U+ED, U+E1, \
28.
U+E9, U+FA, U+F1, U+F3, U+ED
29.
}
Ahora toca crear los índices con el indexer de sphinx. Y es justo aqui cuando me llevo una sorpresa desagradable: tarda muchísimo en general en índice de contenido, unos 15 minutos. Los índices generados ocupan 4.1 megas el del titulo, y 530 megas el del contenido.
Creación de un pequeño sitio web para el buscador
El site se ha hecho plagiando al amigo google un poco (y a todos en general) e intentando que tuviera el interfaz más simple posible. El buscador de la wikipedia permite hacer consultas sin saber absolutamente nada sobre tecnología (aparte claro, de rellenar un campo y darle a buscar) pero posibilita también a la vez el uso de consultas avanzadas. Para ello se usa el modo de consulta extendido.
La función de query a sphinx tiene esta pinta:
PLAIN TEXT
PHP:
1.
function querySPHINX($tag,$indice,$off=0)
2.
{
3.
$port = 3312;
4.
5.
$cl = new SphinxClient ();
6.
$cl->SetServer ( "localhost", $port );
7.
$cl->SetLimits ($off, 10 );
8.
$cl->SetMatchMode ( SPH_MATCH_EXTENDED );
9.
$resultado = $cl->Query ( $tag, $indice );
10.
$num_encontrados = $resultado['total_found'];
11.
12.
13.
if($num_encontrados!=0 && is_array($resultado) && is_array($resultado["matches"]))
14.
{
15.
//como los ids resultantes son los indices, se devuelve con array_keys
16.
return array($num_encontrados,array_keys($resultado['matches']));
17.
}
18.
else
19.
{
20.
return false;
21.
}
22.
}
Las consultas normales llevan un AND implícito: si consultamos seat ibiza sobre el titulo veremos que solo nos saca el resultado que tiene las dos palabras a diferencia de seat | ibiza
Se pueden negar términos. Poniendo un - se pueden excluir palabras de la búsqueda. Por ejemplo si buscamos ibiza obtendremos unos resultados normales pero si ponemos ibiza -seat -dama -ciudad -isla tendremos unos resultados mucho más filtrados.
Es posible hacer busquedas de frase poniendo comillas. Entonces no sólo se buscarán todas las palabras sino que además deberán estar en el mismo orden. Esto permite hacer busquedas de fragmentos mayores (sobre el contenido) "Proverbios que dicen las viejas tras el fuego".
Por último, se dispone de un tipo de consulta, a mi juicio muy útil y potente que es el modo de frase por proximidad. Si el modo de frase buscaba una serie de palabras juntas y en un orden concreto, el modo por proximidad añade un cuantificador que permite que las palabras no estén exactamente igual a la frase pero si cerca. Pero ¿Cuánto de cerca?, pues es configurable. Si hacemos la consulta "kernel linux" se obtendrán los resultados que en el contenido tengan "kernel linux" y en cambio para "kernel linux"~5 se recogerán los resultados de los artículos que tengan las palabras kernel y linux en una distancia máxima de 5 palabras.
Se ha añadido también un pequeño informe de tiempos de ejecución que establece tres fases a medir:
* Consulta a sphinx: tiempo de query a sphinx. Es realmente el parametro a estudiar
* Recuperación de datos: tiempo de recogida de la información de la base de datos.
* Salida a pantalla: construcción de resúmenes (sólo en caso de contenido) e impresión por pantalla
En este informe podemos ver lo realmente rápido que es sphinx, teniendo en cuenta que una búsqueda en el contenido (que es el índice grande) tarda del orden de 2 milisegundos. No es nada comparado con los 20 milisegundos que le cuesta construir los resúmenes y escupir por pantalla la información.
Datos obtenidos
Los tiempos que se ponen a continuación son los de búsqueda en sphinx siempre sobre el índice de contenido y no incluyen en el tiempo ni consulta a base de datos ni impresión por pantalla.
* Tamaño del índice: 530 megas
* Tiempo de construcción del índice 15 minutos
* Consulta normal (AND): seat ibiza 0,001 segundos
* Consulta normal (OR): seat | ibiza: 0.002 segundos
* Consulta normal (NOT): ibiza -isla -seat: 0.0026 segundos
* Consulta PHRASE: "ortega y pacheco": 0,013 segundos
* Consulta PHRASE proximidad: "ortega y pacheco"~5:0,013 segundos
Conclusiones
Sphinx es realmente rápido para búsquedas de texto completo aun cuándo se tiene un índice muy grande. Además nos provee de unos modos de búsqueda avanzada muy útiles al introducir unos operadores muy fáciles e intuitivos. Pero no todo es bueno, el tiempo que se tardó en construir el índice es, a mi juicio, excesivo ( revisaré los parámetros por si es cosa mía, que también es posible).
Por hacer
En breve se le harán un par de retoques al buscador pero adelanto que se le incorporará un stemmer de castellano que yo mismo hice para sphinx. Es posible que escriba las consultas para motor fullext de mysql y postee la comparativa de resultados. Tampoco descarto, ahora que ya tengo la base de datos montada, probar otras alternativas como CLucene. No estaría de más convertir el código de wiki a html en los resúmenes de los resultados (que pereza). "
AQUI ESTA EL TEXTO ORIGINAL
" Buscador para la wikipedia ( jugando con sphinx )
Desde hace algún tiempo, estaba pensando en hacer un buscador que indizara una gran cantidad de texto para comprobar que problemas reales se tienen cuando se trata con cantidades ingentes de información. Para ello habia dos opciones, escoger una base de datos con muchos registros o escoger una con menos registros pero si una cantidad grande de texto por cada uno de ellos.
Pero, ¿Cuantos son muchos registros?. Respecto a temas de indización y búsquedas de texto completo considero imposible (en cuanto a rendimiento) seguir usando el motor FULLTEXT de MySQL a partir de unos 300.000 registros.
Se sopesaron las diferentes bases de datos (por supuesto, libres) que podrían usarse para este estudio y se llego a dos en concreto:
* Wikipedia: unos 200.000 registros con mucho texto
* FreeDB: alrededor de 1.000.000 con poco texto
Teniendo en cuenta, que el FreeDB tiene muchos resultados duplicados y poco texto (que afearía un poco los resultados), decidí aventurarme por la wikipedia en castellano. El idioma también fue un detonante, ya que tenia intención de aplicarle despues un stemmer en castellano.
Al llegar a este punto solo queda definir las fases:
* Descarga e importación de la base de datos
* Configuración y construcción de los índices
* Creación de un pequeño sitio web para el buscador
Descarga e importación de la base de datos
La Wikipedia ofrece la descarga de unos dump de base de datos en formato xml (y algunos en sql), que luego pueden ser importados a la base de datos que tengamos de mediawiki. La página que explica todo esto es http://en.wikipedia.org/wiki/Wikipedia:Database_download.
Para ver que parte de la wikipedia necesitaba y no descargar absolutamente todo (pesa bastante), eché un ojo a este esquema de la base de datos .
Las tablas necesarias son únicamente:
* text: contiene el texto de las páginas
* page: contiene los titulos y ciertos parámetros como si es redirección o el espacio de nombres
* revision: contiene la referencia de revisiones
Los dump en castellano en cuestión se pueden bajar de http://download.wikimedia.org/eswiki/latest/.
Ponemos a bajar el dump que nos vale eswiki-latest-pages-articles.xml.bz2
Para poder crear las tablas de MySQL a partir del dump se tuvo que usar las herramientas de las que provee el propio software de MediaWiki. Así que tras descargarlo y desempaquetarlo, se configuran los parametros de acceso en el archivo LocalSettings.php y mediante el script importDump.php se rellenan las tablas deseadas tal y como se explica aqui.
Configuración y construcción de los índices
Aquí llega la parte seria, se va a indizar una tabla de 1GB de texto. Puntos interesantes a estudiar:
* Tamaño del índice
* Tiempo de construcción
* Tiempo de consulta del índice para consultas simples
* Tiempo de consulta del índice para consultas complejas (booleanas, frase...)
La herramienta que se va a usar es Sphinx, porque es la que conozco (obvio pero importante) y porque mas que el medio en este estudio ella es el fín. Es decir, lo que quiero demostrar es que esta herramienta es muy rápida aun cuando la cantidad de información es muy grande.
Se definen dos índices: uno para el título del artículo y otro para el contenido.
Definicion del titulo
PLAIN TEXT
CODE:
1.
source titulosrc
2.
{
3.
type = mysql
4.
sql_host = host
5.
sql_user = user
6.
sql_pass = pass
7.
sql_db = wikidb
8.
sql_port = 3306
9.
sql_query_pre =
10.
sql_query = \
11.
SELECT page_id, page_title \
12.
FROM page WHERE page_namespace = 0 \
13.
AND page_is_redirect = 0
14.
15.
}
16.
17.
index titulo
18.
{
19.
source = titulosrc
20.
path = /ruta-sphinx/var/data/titulo
21.
docinfo = extern
22.
morphology = none
23.
min_word_len = 1
24.
charset_type = utf-8
25.
charset_table = 0..9, A..Z->a..z, a..z, U+C9->U+E9, U+C1->U+E1, \
26.
U+DA->U+FA, U+D1->U+F1, U+D3->U+F3, U+CD->U+ED, U+E1, \
27.
U+E9, U+FA, U+F1, U+F3, U+ED
28.
}
Definicion del contenido
PLAIN TEXT
CODE:
1.
source contenidosrc
2.
{
3.
type = mysql
4.
sql_host = host
5.
sql_user = user
6.
sql_pass = pass
7.
sql_db = wikidb
8.
sql_port = 3306
9.
sql_query_pre =
10.
sql_query = \
11.
SELECT page_id, page_title,old_text \
12.
FROM page,revision,text \
13.
WHERE page_id = rev_page AND \
14.
rev_text_id = old_id AND \
15.
page_namespace = 0 \
16.
AND page_is_redirect = 0
17.
}
18.
index contenido
19.
{
20.
source = contenidosrc
21.
path = /ruta-sphinx/var/data/contenido
22.
docinfo = extern
23.
morphology = none
24.
min_word_len = 1
25.
charset_type = utf-8
26.
charset_table = 0..9, A..Z->a..z, _,a..z, U+C9->U+E9, U+C1->U+E1, \
27.
U+DA->U+FA, U+D1->U+F1, U+D3->U+F3, U+CD->U+ED, U+E1, \
28.
U+E9, U+FA, U+F1, U+F3, U+ED
29.
}
Ahora toca crear los índices con el indexer de sphinx. Y es justo aqui cuando me llevo una sorpresa desagradable: tarda muchísimo en general en índice de contenido, unos 15 minutos. Los índices generados ocupan 4.1 megas el del titulo, y 530 megas el del contenido.
Creación de un pequeño sitio web para el buscador
El site se ha hecho plagiando al amigo google un poco (y a todos en general) e intentando que tuviera el interfaz más simple posible. El buscador de la wikipedia permite hacer consultas sin saber absolutamente nada sobre tecnología (aparte claro, de rellenar un campo y darle a buscar) pero posibilita también a la vez el uso de consultas avanzadas. Para ello se usa el modo de consulta extendido.
La función de query a sphinx tiene esta pinta:
PLAIN TEXT
PHP:
1.
function querySPHINX($tag,$indice,$off=0)
2.
{
3.
$port = 3312;
4.
5.
$cl = new SphinxClient ();
6.
$cl->SetServer ( "localhost", $port );
7.
$cl->SetLimits ($off, 10 );
8.
$cl->SetMatchMode ( SPH_MATCH_EXTENDED );
9.
$resultado = $cl->Query ( $tag, $indice );
10.
$num_encontrados = $resultado['total_found'];
11.
12.
13.
if($num_encontrados!=0 && is_array($resultado) && is_array($resultado["matches"]))
14.
{
15.
//como los ids resultantes son los indices, se devuelve con array_keys
16.
return array($num_encontrados,array_keys($resultado['matches']));
17.
}
18.
else
19.
{
20.
return false;
21.
}
22.
}
Las consultas normales llevan un AND implícito: si consultamos seat ibiza sobre el titulo veremos que solo nos saca el resultado que tiene las dos palabras a diferencia de seat | ibiza
Se pueden negar términos. Poniendo un - se pueden excluir palabras de la búsqueda. Por ejemplo si buscamos ibiza obtendremos unos resultados normales pero si ponemos ibiza -seat -dama -ciudad -isla tendremos unos resultados mucho más filtrados.
Es posible hacer busquedas de frase poniendo comillas. Entonces no sólo se buscarán todas las palabras sino que además deberán estar en el mismo orden. Esto permite hacer busquedas de fragmentos mayores (sobre el contenido) "Proverbios que dicen las viejas tras el fuego".
Por último, se dispone de un tipo de consulta, a mi juicio muy útil y potente que es el modo de frase por proximidad. Si el modo de frase buscaba una serie de palabras juntas y en un orden concreto, el modo por proximidad añade un cuantificador que permite que las palabras no estén exactamente igual a la frase pero si cerca. Pero ¿Cuánto de cerca?, pues es configurable. Si hacemos la consulta "kernel linux" se obtendrán los resultados que en el contenido tengan "kernel linux" y en cambio para "kernel linux"~5 se recogerán los resultados de los artículos que tengan las palabras kernel y linux en una distancia máxima de 5 palabras.
Se ha añadido también un pequeño informe de tiempos de ejecución que establece tres fases a medir:
* Consulta a sphinx: tiempo de query a sphinx. Es realmente el parametro a estudiar
* Recuperación de datos: tiempo de recogida de la información de la base de datos.
* Salida a pantalla: construcción de resúmenes (sólo en caso de contenido) e impresión por pantalla
En este informe podemos ver lo realmente rápido que es sphinx, teniendo en cuenta que una búsqueda en el contenido (que es el índice grande) tarda del orden de 2 milisegundos. No es nada comparado con los 20 milisegundos que le cuesta construir los resúmenes y escupir por pantalla la información.
Datos obtenidos
Los tiempos que se ponen a continuación son los de búsqueda en sphinx siempre sobre el índice de contenido y no incluyen en el tiempo ni consulta a base de datos ni impresión por pantalla.
* Tamaño del índice: 530 megas
* Tiempo de construcción del índice 15 minutos
* Consulta normal (AND): seat ibiza 0,001 segundos
* Consulta normal (OR): seat | ibiza: 0.002 segundos
* Consulta normal (NOT): ibiza -isla -seat: 0.0026 segundos
* Consulta PHRASE: "ortega y pacheco": 0,013 segundos
* Consulta PHRASE proximidad: "ortega y pacheco"~5:0,013 segundos
Conclusiones
Sphinx es realmente rápido para búsquedas de texto completo aun cuándo se tiene un índice muy grande. Además nos provee de unos modos de búsqueda avanzada muy útiles al introducir unos operadores muy fáciles e intuitivos. Pero no todo es bueno, el tiempo que se tardó en construir el índice es, a mi juicio, excesivo ( revisaré los parámetros por si es cosa mía, que también es posible).
Por hacer
En breve se le harán un par de retoques al buscador pero adelanto que se le incorporará un stemmer de castellano que yo mismo hice para sphinx. Es posible que escriba las consultas para motor fullext de mysql y postee la comparativa de resultados. Tampoco descarto, ahora que ya tengo la base de datos montada, probar otras alternativas como CLucene. No estaría de más convertir el código de wiki a html en los resúmenes de los resultados (que pereza). "
viernes, 4 de mayo de 2007
Apagado automatico en linux
NO que vaina, no puedo hacer que mi pc se apague solo, únicamente cuando uso algún software de quemado de cd que trae por ahí una opción que dice apagar el ordenador cuanto finalice. de lo contrario tendré que estar en constante supervisión para cuando la orden que le haya dado finalice poder apagar el pc.
si a muchos les ha pasado , ejemplo: están copiándose un repositorio de musik tan grande que el tiempo estimado es de 4 o 5 horas y justo se les ocurre comenzar a las 9 o 10 de la noche, NO creeran que se van a quedar despiertos a hasta que acabe y luego poder apagar el pc. ESO SOLO PASA SI USAS win2$,
EN LINUX basta con digitar en una consola el siguiente comando:
shutdown -h +120
lo que nos dará 2 horas de trabajo luego el pc se apagara, si quieres mas tiempo solo debes calcular la cantidad de minutos que necesitas y reemplazar el 120 que esta despues del +.
si a muchos les ha pasado , ejemplo: están copiándose un repositorio de musik tan grande que el tiempo estimado es de 4 o 5 horas y justo se les ocurre comenzar a las 9 o 10 de la noche, NO creeran que se van a quedar despiertos a hasta que acabe y luego poder apagar el pc. ESO SOLO PASA SI USAS win2$,
EN LINUX basta con digitar en una consola el siguiente comando:
shutdown -h +120
lo que nos dará 2 horas de trabajo luego el pc se apagara, si quieres mas tiempo solo debes calcular la cantidad de minutos que necesitas y reemplazar el 120 que esta despues del +.
Suscribirse a:
Entradas (Atom)