Portada
mis comunidades
otras secciones
#9:
#6 Basicamente reservas memoria a saco, pero pides un bit cada vez. Como hay una paginación y la reserva de memoria es en bloques iguales, en vez de eso, reservas en realidad un bloque entero de forma infinita, y cada vez hay menos áreas de memoria libres para los procesos y más paginación en disco...la máquina de va parando sin que nadie sepa realmente qué pasa..el consumo de memoria es exponencial pero depende del algoritmo puede no cantar mucho, porque no ocupas, sólo reservas memoria.
Además cuanto más rápida es la máquina más rápido se reserva. Es muy rápido pedir un bit dado que no tienes casi que escribir nada de nada: es un apunte en la tabla de paginación: una divertida forma de ver si el sysadmin es un cutre o no
Además cuanto más rápida es la máquina más rápido se reserva. Es muy rápido pedir un bit dado que no tienes casi que escribir nada de nada: es un apunte en la tabla de paginación: una divertida forma de ver si el sysadmin es un cutre o no
#30:
#15 Completamente, yo lo he probado sin miedo alguno y con convicción. Total, no tengo SWAP así que ni SSD me iba a tocar...
Tengo 16GB de RAM, en cuanto ha llegado a 14...
[ 199.364065] Out of memory: Kill process 2277 (a.out) score 893 or sacrifice child
[ 199.364071] Killed process 2277 (a.out) total-vm:14668320kB, anon-rss:14664152kB, file-rss:8kB, shmem-rss:4kB
[ 200.144652] oom_reaper: reaped process 2277 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Lo ha matado con una puntuación de 893, el siguiente con más puntos tenía... 23
Es que lo tiene a huevo yo creo... a ver qué programa legítimo ejecuto para que tenga más puntuación en el OOM que un bucle reservando memoria todo el rato.
He hecho otra prueba, he dicho "bueno, si lo ha puesto tan convencido... algo habrá..." me he abierto un vídeo de Youtube, uno de estos que salen en portada de gamers diciendo cosas mientras juegan... por desgracia ni un paroncito he notado.
Distribución instalada hace un par de días, sin configurar nada, por supuesto, es un PC doméstico.
No me imagino un entorno en el que el OOM killer pudiese equivocarse... igual en un nodo de altas prestaciones donde haya algún proceso muy grande consumiendo mucha memoria... pero ahí suele haber cuotas. Me suena que también tenía en cuenta la antigüedad del proceso (y entonces sí que no se equivoca), pero ahora mismo no encuentro nada y tampoco me voy a poner a bucear el código.
Tengo 16GB de RAM, en cuanto ha llegado a 14...
[ 199.364065] Out of memory: Kill process 2277 (a.out) score 893 or sacrifice child
[ 199.364071] Killed process 2277 (a.out) total-vm:14668320kB, anon-rss:14664152kB, file-rss:8kB, shmem-rss:4kB
[ 200.144652] oom_reaper: reaped process 2277 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Lo ha matado con una puntuación de 893, el siguiente con más puntos tenía... 23
Es que lo tiene a huevo yo creo... a ver qué programa legítimo ejecuto para que tenga más puntuación en el OOM que un bucle reservando memoria todo el rato.
He hecho otra prueba, he dicho "bueno, si lo ha puesto tan convencido... algo habrá..." me he abierto un vídeo de Youtube, uno de estos que salen en portada de gamers diciendo cosas mientras juegan... por desgracia ni un paroncito he notado.
Distribución instalada hace un par de días, sin configurar nada, por supuesto, es un PC doméstico.
No me imagino un entorno en el que el OOM killer pudiese equivocarse... igual en un nodo de altas prestaciones donde haya algún proceso muy grande consumiendo mucha memoria... pero ahí suele haber cuotas. Me suena que también tenía en cuenta la antigüedad del proceso (y entonces sí que no se equivoca), pero ahora mismo no encuentro nada y tampoco me voy a poner a bucear el código.
#25:
#16 4 bytes. El tipo de 1 es entero, los enteros ocupan 4 bytes.
Sobre lo que ha dicho:
No es un virus.
No reserva memoria de "manera exponencial" sino secuencial.
Cuánto más rápida la máquina, no tiene por qué caer antes.
Es muy fácil saber qué está pasando.
No sé qué quiere decir con ejecutarlo en distribuido, ¿en un cluster?
No sé qué tiene que ver el sudoers con todo esto.
Realmente es una chorrada asustaviejas.
Sobre lo que ha dicho:
No es un virus.
No reserva memoria de "manera exponencial" sino secuencial.
Cuánto más rápida la máquina, no tiene por qué caer antes.
Es muy fácil saber qué está pasando.
No sé qué quiere decir con ejecutarlo en distribuido, ¿en un cluster?
No sé qué tiene que ver el sudoers con todo esto.
Realmente es una chorrada asustaviejas.
#5:
Virus en una línea:
import import void main void }
Compilar con: gcc -o ralentizahost.c ralentizahost
Con esto cuanto más rápida la maquina antes cae: muy pocos sys admin cuidan de poner limites hard o soft a las memorias de usuario de las máquinas. Puedes incluso correrlo en paralelo o distribuirlo. Disfrutad!!
import import void main void }
Compilar con: gcc -o ralentizahost.c ralentizahost
Con esto cuanto más rápida la maquina antes cae: muy pocos sys admin cuidan de poner limites hard o soft a las memorias de usuario de las máquinas. Puedes incluso correrlo en paralelo o distribuirlo. Disfrutad!!
#35:
Ni siquiera Intel (o AMD pal caso) sabe exactamente todo lo que hay dentro de sus procesadores. Se subcontrata el diseño de muchas partes a otras empresas, a menudo de otros países (incluyendo tachán: China), y es imposible comprobar al 100% lo que hacen. Yo a estas alturas de la vida doy por hecho que mi PC tiene no uno, sino varios caballos de troya a todos los niveles: hardware, SO, aplicaciones... Intento mantenerlo "limpio" del malware más cutre, pero no me emparanoio pensando que queda más.
Comentarios
#6 Basicamente reservas memoria a saco, pero pides un bit cada vez. Como hay una paginación y la reserva de memoria es en bloques iguales, en vez de eso, reservas en realidad un bloque entero de forma infinita, y cada vez hay menos áreas de memoria libres para los procesos y más paginación en disco...la máquina de va parando sin que nadie sepa realmente qué pasa..el consumo de memoria es exponencial pero depende del algoritmo puede no cantar mucho, porque no ocupas, sólo reservas memoria.
Además cuanto más rápida es la máquina más rápido se reserva. Es muy rápido pedir un bit dado que no tienes casi que escribir nada de nada: es un apunte en la tabla de paginación: una divertida forma de ver si el sysadmin es un cutre o no
#9 muchas gracias
#11 Muchas de nadas!! cuando quieras ahí estaremos para ayudar
#12 yo tengo una mudanza en 2 semanas
#53 Pues si quieres ayudamos entre todos. Hacemos un crowdfunding o un crowd moving
#9 los SO modernos no suelen dejar que un programa reserve más de una x cantidad de memoria.
Además que canta enseguida cuál es el proceso que se está comiendo la memoria y basta con matarlo.
#14 Esa es la teoría. Y es cierto que hay límites, pero la realidad es que muchas veces se dejan limites y permisos ridículos, así que suele colar. Alguien que conozco me contó una vez que un host de una universidad de esas buenas pública sufrió cositas así hace tiempo porque el sysadmin (aburrido funcionario) pasaba de lo más básico... todo es cuestión de que el algoritmo de reparto de memoria tenga una u otra política. Todo puede ser más que divertido...y más si alguien explota algo del sudoers
#19 lo gracioso es que reservar no es ocupar! Por lo que básicamente lo que haces es que la tabla de paginación de memoria y su algoritmo empiezan a tirar otros procesos y aunque sí que ocupas mucho con un simple ps -aux o un top, estas reservando sin más
#19
"porque el sysadmin (aburrido funcionario)"
Dejemos de generalizar sobre los trabajadores que son funcionarios. También hay trabajadores de empresa privada que son muy aburridos y un desastre.
#41 Claro que si...pero qué curioso que suele pasar...serán historias inventadas seguro ...no hagas caso
Los funcionarios no se institucionalizan en general y Nadie ha oído a personal interino cagarse en algunos funcionarios por tenernos que sacar su curro adelante. Es un mito!! El sistema de funcionariado es más que mejorable, y está mejorando, pero le falta muuuucho. Empezando por eliminar el corporativismo.
Si la historia es con un funcionario es con un funcionario, te fastidie o no
#41 No ha generalizado sobre los funcionarios, ha dicho que el sysadmin era un ABURRIDO FUNCIONARIO, o sea, que el sysadmin, ademas de Sysadmin, era ABURRIDO, y ademas de sysadmin Y aburrido, era FUNCIONARIO.
No ha dicho que todos los sysadmin sean tipicamente aburridos, ni que todos los aburridos sean tipicamente funcionarios, ni que todos los funcionarios sean tipicamente sysadmin, ni ninguna combinacion de todas ellas.
Simplemente que ESE sysadmin, ESE aburrido, y ESE funcionario, que resulto ser todas las cosas a la vez, era, TAMBIEN, un incompetente.
Y ahora, te pones la tirita, y la proxima vez, te vienes llorado de casa.
#19 Pues aquí la culpa sería más bien de los jefes de ese "funcionario". Porque en una organización seria tienes puesto un sistema operativo de verdad, con un contrato de soporte y actualizaciones de seguridad que ya se cuidan de este tipo de vulnerabilidades.
Pero si la organización se escandaliza con lo que vale el soporte anual y deja que el sysadmin instale en los servidores la última Ubuntu, "que ya la administro yo que tengo la misma versión en casa", pasan estas cosas. ¿Es culpa del sysadmin, o de los gestores? Yo no lo tengo tan claro.
#57 Si el gestor ha delegado la gestion al sysadmin (que es, basicamente, para lo que se contrata un sysadmin), la responsabilidad es del sysadmin, EXCEPTO que el sysadmin pueda demostrar que hubo negligencia en su contratacion o en la gestion y pueda pasar el marron hacia arriba, pero como comprenderas, eso no suele pasar.
#15 #14 #38 #8 #5. Goto #40.
#62 ¿He dicho yo que no ocurra?
Quizás si no contestases a metralleta no te pasaría que contestases a algo que nadie ha dicho.
#14 El problema no es ese.
El problema es que mientras el SO determina que hay que matar a un proceso por falta de RAM, normalmente ha tirado la cache de disco por el retrete.
los 'linuxes' modernos si traen proteccion OOM 'por defecto', pero creo que un windows de 64bits se caeria con todo el equipo, al menos, las versiones de escritorio. las versiones server... no se yo... pero no apostaria a favor del windows server...
#9 Pero lo mataría el oom killer no? Vamos, no voy a hacer la prueba, pero me figuro que el kernel cuando se pase de reservar memoria y ponga en riesgo procesos vitales le tirará un rayo.
#15 si lo tienes bien configurado sí: para eso es estudiarlo bien y mezclar todo esto bien con llamaditas recursivas y forks, para que la pila haga de todo y si haces enjaulamientos chulos todavía más divertidos: con mallocs en cada fork y por ejemplo un screen para que no se cierren sesiones de usuario que abren mallocs y forks y combinarlo con escrituras en disco de cat /dev/urandom > /home/diversion
#29 Para eso están las cuotas de CPU, RAM, disco y red... y el sysadmin de equipos compartidos que no las configure, se merece una patada en el culo.
#78 Pues de eso va la cosa..un poquito de PAM un poquito de uname, un poquito de tuning vamos...pero ni imaginarse pueden algunos lo que hay por ahí
#15 Completamente, yo lo he probado sin miedo alguno y con convicción. Total, no tengo SWAP así que ni SSD me iba a tocar...
Tengo 16GB de RAM, en cuanto ha llegado a 14...
[ 199.364065] Out of memory: Kill process 2277 (a.out) score 893 or sacrifice child
[ 199.364071] Killed process 2277 (a.out) total-vm:14668320kB, anon-rss:14664152kB, file-rss:8kB, shmem-rss:4kB
[ 200.144652] oom_reaper: reaped process 2277 (a.out), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Lo ha matado con una puntuación de 893, el siguiente con más puntos tenía... 23
Es que lo tiene a huevo yo creo... a ver qué programa legítimo ejecuto para que tenga más puntuación en el OOM que un bucle reservando memoria todo el rato.
He hecho otra prueba, he dicho "bueno, si lo ha puesto tan convencido... algo habrá..." me he abierto un vídeo de Youtube, uno de estos que salen en portada de gamers diciendo cosas mientras juegan... por desgracia ni un paroncito he notado.
Distribución instalada hace un par de días, sin configurar nada, por supuesto, es un PC doméstico.
No me imagino un entorno en el que el OOM killer pudiese equivocarse... igual en un nodo de altas prestaciones donde haya algún proceso muy grande consumiendo mucha memoria... pero ahí suele haber cuotas. Me suena que también tenía en cuenta la antigüedad del proceso (y entonces sí que no se equivoca), pero ahora mismo no encuentro nada y tampoco me voy a poner a bucear el código.
#30 positivo por andar trasteando.
#9 reserva un byte cada vez ¿no?
#16 depende: en una arquitectura de 64 bit, conpilando en 64 bit, cuando compilamos esto malloc(sizeof(1)) devolvemos un puntero a 8 bytes, que ponemos en el heap. Si no puede devuelve null, siendo el tipo del puntero void*.
El tamaño de la longitud de la memoria direccionada dependerá de la arquitectura .
Lo que quería decir es que pides aparentemente un byte pero reservas un puntero de tamaño de lo que Sea la arquitectura.
Es jugar con todo esto lo que hace que aprendas con cosas aparentemente muy simples
Y lo gracioso es esto:
By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer. For more information, see the description of /proc/sys/vm/overcommit_memory and /proc/sys/vm/oom_adj in proc(5), and the Linux kernel source file Documentation/vm/overcommit-accounting.
Vamos, que puede matar otros procesos o ralentizar y paginar... diversión total!!
Y volver loca la pila!
Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3). Allocations performed using mmap(2) are unaffected by the RLIMIT_DATA resource limit (see getrlimit(2)).
#23 Si juegas con mmap a la que no le afecta el limite RLIMIT_DATA ya puedes ser la juerga padre!
Tonterías súper simples pero que tiran máquinas no afinadas mínimamente ...
Porque por ejemplo una oracle no producción se caerá si no afinas estas cosas y por ejemplo tienes un proceso que hace una select brutal con un usuario sin límites soft y hard de memoria (siempre lo recomiendo al 100% en la instalación) y creación de cualquier usuario
#23 donde dije conpilando quiero decir compilando!!! Es el colmo de un informático: casarse y con Pilar!! (Este chiste es malo, mío y se lo hice a un compañero que se casó con Pilar y fue verdad!!)
#23 devuelve un puntero a la memoria reservada, pero no reserva un bit sino la cantidad de bytes que le pases a la función, en este caso 1 (8 bits).
#31 malloc(1) reserva 1 byte.
malloc(sizeof(1)) es lo mismo que malloc(sizeof(int)), que es lo mismo que malloc(4) (o 2 u 8, depende del compilador), así que pedirá 2, 4 u 8 bytes.
#16 4 bytes. El tipo de 1 es entero, los enteros ocupan 4 bytes.
Sobre lo que ha dicho:
No es un virus.
No reserva memoria de "manera exponencial" sino secuencial.
Cuánto más rápida la máquina, no tiene por qué caer antes.
Es muy fácil saber qué está pasando.
No sé qué quiere decir con ejecutarlo en distribuido, ¿en un cluster?
No sé qué tiene que ver el sudoers con todo esto.
Realmente es una chorrada asustaviejas.
#25 Una cosa es el puntero a la memoria reservada, otra el tamaño del parámetro que recibe la función y otra diferente la reserva de memoria que haga: malloc(1) recibe un entero de tamaño 4 bytes en el que se indica cuántos bytes se quieren reservar (1) y devuelve un puntero cuyo tamaño depende de la arquitectura empleada pero la reserva se realiza de los bytes que se le hayan indicado en la llamada (más bytes extra de alineamiento y mantenimiento)
#32 No es "malloc(1)" es "malloc(sizeof(1))" el código propuesto.
#47 cierto, es malloc(sizeof(1)) y no malloc(1), me había fijado mal. Pero es que se me ha pasado también el import (#include), el studio.h (stdio.h), los paréntesis de main y el orden de los operandos en la llamada a gcc. Hoy es el día que los de Bankia me tratan de vender unas preferentes y se les quito todas de las manos...
#54 A raíz de tu respuesta, me acabo de fijar en algo que no hemos hecho caso ninguno.
Proclama ser un "virus en una línea", lo de virus ha sido rebatido varias veces pero...
https://stackoverflow.com/questions/9638369/one-line-c-program-with-include
Jejeje...
De todas formas, gcc yo creo que ya linka con stdio y malloc sin especificar nada, yo tampoco puse operandos.
#25 Depende de la arquitectura.
No es un virus es verdad. Para serlo hay que dotarle de capacidad de infección y auto replicarse.
Tienes razón que es secuencial... habría que hacerlo de otra forma para ser exponencial.
Por qué no tiene que caer antes, porque depende de muchos factores?
En un cluster o paralelizarlo en un cluster Beowulf
Sudoers porque dependiendo de los privilegios puedes ver qué límites y qué puede hacer cada usuario y jugar con ello.
Chorrada es. No pretendo asustar a nadie, sino mostrar lo sencillo que puede ser hacer algo, sin mucho más.
Para “cosas más divertidas” aquí está el código del famoso I love you :
http://www.cexx.org/loveletter.htm
O Mirai
https://github.com/jgamblin/Mirai-Source-Code?files=1
#44 gcc, si no recuerdo mal, compila por defecto en 32 bits. Para 64 hay que usar un flag.
Depende de muchos factores, claro.
Completamente seguro, y en el móvil también.
#1 pero es por nuestro bien. imaginate que intel quiere cambiar la velocidad del ventilador en nuestros ordenadores, como lo van a hacer sin sus puertas traseras y saltandose los cortafuegos? hay que dejar de ser tan desconfiados, a fin de cuentas todas las empresas de los EE.UU. estan obligadas legalmente a colaborar con la NSA para protegernos
Virus en una línea:
import import void main void }
Compilar con: gcc -o ralentizahost.c ralentizahost
Con esto cuanto más rápida la maquina antes cae: muy pocos sys admin cuidan de poner limites hard o soft a las memorias de usuario de las máquinas. Puedes incluso correrlo en paralelo o distribuirlo. Disfrutad!!
#5 me interesa saber lo que hace, me hago una idea pero no terminé programación.
#6 Es la profesión del futuro, te invito a que lo retomes. Tal vez tuvieras malos profesores, empezaste con un lenguaje demasiado complicado, o no estabas lo suficientemente motivado. En cualquier caso, nunca es tarde.
#73 mi pensamiento no se amolda bien a la programación. Hice un año de informática pero fracasé estrepitosamente. Seguramente ahora no sería igual pero ya he hecho otra carrera. Supongo que algún día intentaré aprender algún lenguaje.
#5 Eso se puede hacer desde bash mismamente.
Y es bastante más fácil que en un sistema dado tengas una Shell que permita fork a que tengas compilador.
#7 Sí cierto, pero bash tiene límite por defecto. Un procesito inocente no lo tiene tanto por admin descuidados.
Prueba a hacer un while(1) por defecto Linux o Unix (cualquiera) se reinician
#8 No, el limite lo tiene PAM.
Si se lo pones.
#5
Lo acabo de hacer y el proceso muere.
#40 Todo depende de cómo tengas la máquina y sus límites...con un mínimo de límites por defecto eso es lo suyo, que muera
#40 ¿Es una máquina virtual? (#46) Porque intuyo, si no tuvieras límites, que sólo colgaría la vitual pero el host no, dado que le VM ya tiene una cantidad fija de RAM.
#61
Sí.
#5 Un virus tiene que saber reproducirse y contagiar otros hosts. Tu programa es un malware (hace DoS) pero, llamarlo un virus es, sin ánimo de ofender, un insulto a los hackers.
#72 Además va mutado y disimulado, porque depende de los conocimientos de los que lo hemos probado para poder compilarse: faltan signos que se habrá comido menéame y hay una errata.
Aún así, si fuese más interesante el código igual pasaba a comentarse en otros sitios, convirtiéndose en una especie de virus offline, pero siendo algo tan básico...
Si aceptamos pulpo diría que el virus offline más extendido es aquel llamado "hola mundo" en sus variantes y mutaciones
Y por esto niños, es por lo que necesitamos hardware open source.
En mi opinión, un buen candidato serían las CPU's RISC-V https://riscv.org/
Ni siquiera Intel (o AMD pal caso) sabe exactamente todo lo que hay dentro de sus procesadores. Se subcontrata el diseño de muchas partes a otras empresas, a menudo de otros países (incluyendo tachán: China), y es imposible comprobar al 100% lo que hacen. Yo a estas alturas de la vida doy por hecho que mi PC tiene no uno, sino varios caballos de troya a todos los niveles: hardware, SO, aplicaciones... Intento mantenerlo "limpio" del malware más cutre, pero no me emparanoio pensando que queda más.
#52 Hace tiempo vi una entrevista a un dependiente de "la milla de oro" de Barcelona y comentaba que muchos trajeados entraban a su tienda solo por mirar, pero otros con 'pintas' de chandal y tal, son los que se dejaban los dineros..
Paradógicamente, yo quiero empezar a usar el IME para lo que de supone que es: administrar equipos sin acceso físico. Veo tutoriales por ahí para ir haciendo pero aún no he visto un "manual oficial" (igual mi problema es querer leer todo antes de tocar y la documentación resulta que esté en las aplicaciones correspondientes, pero me resulta curioso). Hay que pulsar combinaciones de teclas en el arranque que ni la BIOS pone, instalar programas de Intel en tu SO para configurarlo... me resulta curioso.
Ya que los amigos de Intel pueden controlar mi PC en remoto, que menos que me dejen a mí también y fácil.
#24 Nop, pq el IME es para uso empre$arial, si quiere$ activarlo y u$sarlo tienes que pa$sar por caja.
#42 Ya, pero viene de serie en todos los equipos. Además que mi CPU tiene soporte vPro (ahora a ver las placa).
#48 Viene de serie, pero se basa en un blob propietario, cuya interfaz sabe Intel y sólo Intel. Por eso hay que pasar por caja, no hay herramientas libres/abiertas para aprovecharlo.
#58 Es, en parte, lo que quería señalar: me meten un monitor hardware y un KMV forzadamente (que he pagado, deduzco) y encima no me dicen bien como usarlo ni dejan que lo use siempre.
#70 Claro que te lo dicen, pero sólo si pasas por caja. Y tampoco es que te obliguen a nada, porque en el mercado hay más marcas de procesadores.
No creo que sea precisamente la maniobra comercial más brillante de Intel, pero tampoco es la pérfida conspiración que pintan algunos. Es un producto objetivamente útil, implementado y comercializado de forma chapucera.
#79 No me están intentando vender nada cuando busco la documentación de cómo usar el vPro. Ya he pasado por caja al comprar hardware compatible con esa característica.
Por cierto, aún la parte que puedo acceder con las herramientas que Intel entrega gratis... no es toda la funcionalidad. Claro, si pasar por caja se refiere a comprar a Intel y a todos sus ingenieros... pues sí, igual así me dicen cómo funciona...
#80 Cierto, no te había leído bien. Efectivamente dudo mucho que te expliquen cómo funciona el vPro, no parece que sea algo a la venta. Como mucho te van a dejar usar sus herramientas, previo paso por caja.
Uno?
La manada entera más bien.
Probablemente no.
- Betteridge.
Todos mis ordenadores personales son AMD desde los tiempos del K6-2.
No se Rick, a mi todo este artículo me ha olido demasiado a publicidad viral sobre Intel y sus ventajas para administradores.
Pero estaré paranoico
Desenchufa el ordenador de la corriente y a ver si el procesador ese es capaz de trabajar sólo con la pila interna del ordenador.
"Incluso puede hacerlo con el ordenador apagado"
Hooolaaa superdotado. Espera, que te voy a comprar una bolsa de chuches.
Se puede eliminar usando:
https://github.com/corna/me_cleaner
Yo lo he hecho usando una Raspberry Pi:
https://www.flashrom.org/RaspberryPi
Si usas Windows sí.
#2 ¿qué protección brinda usar Linux en este caso? A nivel de hardware si se puede ejecutar código arbitrario, da igual el sistema ¿no?
¿O te referías al titular?
#2 Que tiene que ver linux en eso? ME, ILO y similares son un ordenador aparte del sistema operativo.
#4 De hecho ILO es un sistema Linux.
#2 otro que no se ha leído artículo!!!
#2 Y si usas Facebook a lo loco también. Y Twitter e Instagram. Aunque esto último suele ser porque la gente es imbécil. Yo he llegado a ver a un tio de sus 30 y algo, muy formalito con su traje y corbata, listo, preparado académicamente y arreglado en su entrevista de trabajo, que a pesar de que gustó inicialmente, se cayó debido a que poniendo su nombre en Google salía en su Twitter con mil payasadas y tuits a sus espaldas y una foto de perfil casi en bolas y unas gafas de sol tipo Dioni. Le faltaban las bailarinas de reguetón detrás (o como se escriba).
La gente afín a las redes sociales, especialmente aquellos con tan poca vista como para poner su nombre, deberían buscarse periódicamente en Google. Más de uno se llevaría una sorpresa.
#18 Aunque tienes razón en lo de no colgar lo que no quieras que se conozca, vaya mierda de empresa, que no permite tener la vida personal que se quiera aunque uno sea formal en el trabajo.
#36 Yo tampoco no me fio mucho de la gente sólo por ir trajeados, creo que eso ya pasó a a la historia.
#51 Y haces bien...
#36 Totalmente de acuerdo. Sin embargo, y a sabiendas de que esas situaciones existen, es un riesgo que resulta muy fácil de evitar, almenos a este nivel de jefe que busca en Google. Sólo poniendo un alias o configurando la privacidad podría haberse arreglado en este caso. El problema es que la gente no es en absoluto consciente de esto.
#2 Y si usas cualquier otro OS tambien.
#2 Use Windows o uses Linux, estás igual de jodido, por cierto, deberías de cambiar tu 'nick' de Trigonométrico a Chorramétrico
#2 has visto que el comentario kharma-whore te ha salido rana y ya no tienes cojones para contestar a la gente?
#2 Se te ve entendido en la materia .
#2 Y si tienes el PC apagado, también.