Mensajes

Tienes un archivo js, de nombre js, en una carpeta js.



Usa nombres más apropiados para tus archivos, para evitar confusiones.

Inicialmente mi pregunta es si en la actualidad tenia alguna utilidad evidente el utilizar la creacion de procesos a traves de llamados al sistema como fork,exec,etc.. Creo que esta respuesta la ire obteniendo conforme vaya poniendo en practica estos conceptos en algun programa que es lo que actualmente estoy haciendo.

Todos los procesos son forks de otros procesos en Linux. Si quieres empezar un nuevo proceso, la única forma es clonar un proceso e inicializar un programa. Esa es la utilidad de fork y exec. Esa es la forma en la que una shell empieza un nuevo proceso por ejemplo, se clona a si mismo y carga el programa.

Al final, lo que tu pareces es estar discutiendo es usar multiples procesos vs multiples threads para efectos de paralelización.

[8.4 million websites]

No es solo si usas el buscador google o chrome o cualquiera de sus aplicaciones. Son millones de sitios web usando el programa de Real Time Bidding:

The new evidence reveals a surreptitious mechanism that raises additional data protection concerns about Google's "DoubleClick/Authorized Buyers" advertising system. This system is active on 8.4 million websites.

https://brave.com/google-gdpr-workaround/

Otra razón para instalarse un ad blocker.

index.html:8 Uncaught TypeError: Cannot read property 'addEventListener' of null
    at index.html:8

El error lo tienes en la linea 8 de tu HTML, lo que significa que tienes el script en el header. En ese punto, no se ha cargado el DOM, no existe el contenido de tu documento. Si pones el script después del form entonces los elementos ya fueron cargados en el DOM y puedes acceder a ellos.

Otra cosa que puedes hacer es agregar otro listener:

Código (javascript) [Seleccionar] Expandir


document.addEventListener('DOMContentLoaded', function(){
  //DOM cargado aquí
});

Y dentro del listener puedes acceder a cualquier elemento del DOM.

No mezcles los handlers y listeners. Si vas a usar los handlers en los atributos/propiedades on<event> no uses listeners. Y viceversa. Yo también evitaría usar los handlers en general.

No hay nada complicado con estas funciones.

Código (php) [Seleccionar] Expandir


$pass = 'micontraseña';
$mihash = password_hash($pass); //si viene de la DB obviamente no usas password_hash porque ya es un hash.
password_verify($pass, $mihash); //true

¡Les agradezco mucho a los dos!

EDIT: Testee la función y veo que el hasheado es aleatorio a medida que actualizo la pagina o ejecuto el código independientemente si cambia o no el dato que estoy intentando hashear me va a dar siempre códigos diferentes aunque el dato sea el mismo.

¿Como podría aplicar esto a un login?
Porque cuando se usa sha-512 por ejemplo el hasheado es siempre el mismo para x dato/string que le pase, entonces lo que hago o hacía era hashear con el sha-512 la contraseña que el usuario ingresaba en el formulario login y despues una vez hashaeada la contraseña ingresada la comparaba con la contraseña que estaba en la base de datos (contraeña que esta hasheada)

Pero en este caso como podría hacer porque siempre me va a dar diferentes, aunque el dato sea el mismo.

Lo que está pasando es que password_hash está generando un salt aleatorio por cada vez que lo llamas. Lo que significa que tienes 2 salts diferentes y por ende 2 hashes diferentes para un determinado string. Si le entregas el mismo salt a la función entonces recibes el mismo resultado. No te tienes que preocupar por eso porque puedes usar la función password_verify que hace todo por tí, extrae el salt del hash, vuelve a recalcularlo y hasta compara los strings en tiempo constante.

No uses SHA-512. Usa una función como bcrypt, scrypt, Argon2, PBKDF2, etc.

El problema con algoritmos como SHA-512 y similares es que un atacante puede precalcular millones de contraseñas rápidamente. Por lo menos un salt aleatorio por cada contraseña es MUY importante... Para que no te saquen TODAS tus contraseñas de una sola rainbow table.

Edit: Exagero un poco con "TODAS" porque no todo mundo elige contraseña débiles, pero te sorprendería saber cuantas si lo hacen.

Bien, estamos de acuerdo en que para cuando se ejecute la función de ajax ya la ventana/documento ya está cargada/o. Pero para cuando estos nuevos datos (los otros 10 datos o fotos) se muestren por medio de código html entonces la pagina volverá a cargar pero no cargar toda sino estos nuevos datos html que son introducidos.

Por este motivo no se si es redundante, ya que para cuando se muestren estos datos o termine la ejecución del fichero.php le digo que haga tal cosa sólo cuando la ventana este lista porque recordá que estoy metiendo nuevos elementos html

Nose si me doy a entender bien, no soy de explicarme muy bien que digamos 

Hasta donde yo tengo entendido el evento se dispara una sola vez, en la carga inicial de la pagina. En el código que estás mostrando, los elementos ya existen y están cargados. En ese código no estás cargando ningún elemento al DOM. Y si estuvieras cargando los elementos al DOM con jQuery o innerHTML o similar, esas APIs no son asincronas. Lo único que pudiera necesitar un evento es si tu codigo HTML carga recursos de otras partes. Por ejemplo, tu código HTML puede incluir IMG tags que cargan imagenes de algún lado. Tu puedes insertar las etiquetas IMG en el DOM inmediatamente, pero el navegador puede o no estar cargando las imagenes todavía. Si quieres mostrar la imagen cargada vas a tener que escuchar al evento load de las imagenes. Pero eso ya es otro tema.

En esta parte tal vez no me explique muy bien. Quisiera hacer referencia al planificador como tal, por ejemplo:
El planificador tiene un 'X' algoritmo pero resulta que utiliza todos los procesadores para distribuir los diversos procesos en la cola de lista entre los diversos nucleos. Para ser mas concreto podria ser que existieran 4 nucleos:
1 Nucleo. Es el nucleo maestro, es el unico que tiene acceso a la cola de procesos listos y le asigna a cada uno de los otros 3 nucleos un conjunto de esos procesos listos.
2,3,4 Nucleo. Solo ejecutan procesos que le son pasados por el nucleo maestro.

¿Donde leíste esto? Los procesos no van en los núcleos hasta donde yo tengo entendido. Los procesos son artefactos de los sistemas operativos.

En este caso o en algoritmos donde se haga uso de todos los nucleos para la planificacion de una forma parecida que succede si entra un proceso que tiene 4 hilos en paralelo en un mismo instante de tiempo?. Supongamos que este proceso estaba destinado para estar en el nucleo 2 pero esta requiriendo hilos a nivel de kernel. En ese caso cambia todo el algoritmo de planificacion para que ahora 2 procesos se queden despachando procesos y los otros dos nucleos intenten satisfacer los hilos de dicho proceso o simplemente es rechazada su paralelismo y se le asigna un unico nucleo para todos sus hilos. Aclarando que ese cambio va ser solo una porcion de segundo(quantum). O definitivamente no se usa este tipo de estructura para sistemas operativos que permiten el paralelismo en hilos/procesos.

Aquí no te entendí NADA. Lo único que alcance a entender más o menos es que estás preocupado por la estrategia del planificador que ponga todos tus hilos a trabajar en un solo núcleo. Y lo puede hacer, dependiendo de la estrategia. Pero no tiene nada que ver si es un proceso o un thread o un kernel thread.

Entonces al parecer cuando se habla de paralelismo la opcion mas viable siempre es la de los hilos pero que razon de ser pueden tener la creacion de procesos a partir de un padre?. He visto un poco las funciones fork,wait,exec,etc.. Y comprendo que la generacion de un nuevo proceso permite crear esa jerarquia de hijos-padre pero realmente hasta ese punto aun no se esta hablando sobre paralelismo, verdad?. Entonces que sentido tendria crear varios procesos de esta manera que pudiera presentar una ventaja conforme a los hilos. O este proceso es heredado por codigo que fue desarrollado desde antes de la existencia de hilos y ya solo es visto como contenido educativo?.

Como usuario, tienes más control sobre tus procesos. Por ejemplo, puedes matar un proceso que se quede ciclado. Le puedes cambiar la afinidad (o su niceness) al proceso. Puedes cambiar permisos al proceso, etc. Tengo entendido que lo puedes hacer desde el contexto del proceso pero no es algo que un proceso externo pueda cambiar. Con los threads tienes la ventaja que son ligeros pero también incrementas la complejidad de tu programa para sincronizar el acceso a al memoria.

Como un punto y aparte me surge la duda de si el planificador de procesos de corto plazo de linux hace uso de los varios nucleos disponibles en la computadora. He visto varios puntos de vista en donde algunos hablan de la insercion de los PCB en arboles ordenados conforme a su tiempo en CPU que se les ha dado, mientras que algunos otros lados se enfocan mas en explicar que se trata de un mapa de bits con cada prioidad en donde cada posicion se encuentra almacenados los procesos con dicha prioridad pero mi principal duda surge en el momento de que se usan los distintos nucleos para la parte de la planificacion, he leido sobre el hecho de que esto puede ser implementado de distintas maneras como por ejemplo a traves de un nucleo maestro,etc. Pero en Linux se implementa esta forma de utilizar varios nucleos en la planifacion? y en dado caso que llega a pasar cuando el planificador funciona con varios nucleos y llega un proceso que tiene varios hilos y requiere paralelismo?. Se comparten los nucleos entre el planificador y ese nuevo proceso con hilos o se le da todos los nucleos momentaneamente al proceso con varios hilos?

Para efectos de planificación, hasta donde yo tengo entendido, los procesos y threads son indistinguibles. No veo porque no se puedan paralelizar multiples procesos de un solo thread.