Mensajes

Por favor, no digas que no hay libros, más bien que no los conoces...


Bridges, Routers, Switches and Internetworking Protocols 2e - de Perlman
Wireless Networks For Dummies - de Lewis
Wireless Networking - Know it All - de Newnes
Networking For Dummies 7e - de Lowe
Ethernet Networks 4th ed. - de Held
Network Security Bible - de Cole
Hacker's Handbook,The - Breaking and Defending Networks - de Young
Practical TCP-IP and Ethernet Networking - de Reynders
Network Routing - Algorithms, Protocols and Architectures - de Medhi
Complete Guide to Network Wiring,The - 3rd ed - de Barnett (y otros)
Kismet Hacking (wireless networks) - de Haines
Tracking Hackers - de Spitzner
Computer Viruses and Malware - de Aycock
Computer Viruses - From Theory to Applications - de Filiol
Communication Systems 4e - de Carlson
Computer Systems Architecture - Networking Approach 2e - de Williams
Internetworking with TCP-IP - Vol. I - Principles, Protocols and Arch. 4e - de Comer (son 3 volúmenes)
Network Analysis, Architecture and Design 3e - de McCabe
Governing Global Electronic Networks - de Drake
Book of Wireless 2e,The - de Ross
Web Application Hacker's Handbook,The - de Stuttard
Cryptography and Network Security Principles and Practices, 4th Ed - de Stallings
Network Security Technologies 2e - de Fung
Data Networks, IP and the Internet - Protocols, Design and Operation - de Clark
Broadband Bible - de Gaskin
Best Damn Cybercrime and Digital Forensics Book - de Syngress
Communicating Systems and Networks - Traffic, Performance - de Fiche (y otros)
Definitive Guide to Linux Network Programming - de Davis
Network Administration with FreeBSD - de Farrokhi
Linux Networking Cookbook - de Schroder
Linux TCP-IP Stack - Networking for Embedded Systems - de Herbert
Network Security with OpenSSL - de Chandra
Applied Cryptanalysis - Breaking Ciphers in the Real World - de Stamp
Buffer Overflow Attacks - Detect, Exploit, Prevent - de Foster
Botnets - The Killer Web App - de Schiller
Teach Yourself Wireless Java with J2ME in 21 Days - de Morrison
Insider Attack and Cyber Security - Beyond the Hacker - de Stolfo
Intro to Network Analysis 2nd ed. - de Chappell
Network Infrastructure and Architecture - de Iniewski
Hackers Beware - Defending Your Network from the Wiley Hacker - de Cole
Encyclopedia of Multimedia Technology and Networking - de Pagani
Networking and Internetworking with Microcontrollers - de Eady


Aquí un amplio listado, la mayoría sobre redes y unos pocos enfocados en seguridad o más específicos en su temática.
La idea de este listado es que selecciones los de tu interés, ya comprarlos o ver si los localizas en pdf es cosa tuya.
Tienen sus años. He procurado que no sean anterior al 2000, aunque creo que alguno se me habrá escapado. Las bases siempre conviene conocerlas y ver como el tiempo lo cambia, o se incluyen añadidos... Es bueno por ello, leer primero los más viejos (de los que adquieras), pero queda a criterio del que lea.

[dejar atrás 32 bits, no es para nada mala idea]

el dejar atrás 32 bits, no es para nada mala idea el heredado trae mas problemas que beneficios... por otro lado es emulable

Deja obsoleto todo lo diseñado... es tirar a la basura millones de horas de trabajo. Si lo mismo se aplicara en todas las áreas, no quiero ni pensarlo.
...pero una pequeño desvelo de imaginario: Un nuevo vehículo trae un nuevo diseño de tornillos que solo valen para los vehículos fabricados en ese y los 4 años siguientes, luego dejamos de fabricarlos y los nuevos modelos tendrán otros tornillos distintos...

Si yo fuera fabricante de chips, la aparición de una arquitectura donde duplica el tamaño del bús, no haría desaparecer la previa, simplemente seguiría conteniendo internamente un chip de 32 bits conjunto al de 64 bits... y cuando apareció el de 32, a su vez alojaría también uno de 16 bits y aquél a su vez el de 8 bits.
Es más lo desieñadría para que uno de 64 bits pudiera funcionar como también como dos de 32 bits, o como uno de 32 bits y 2 de 16 bits, o uno de 32 + 1 de 16bits, + 2 de 8 bits...  Dicho comportamiento sería configurable desde la BIOS... Lógicamente el diseño debe acompañar a la intención.

No hay que perder de vista que los chips de hoy día llevan miles de milones de transistores... por ejemplo el 8086 llevaba solo 29.000 transistores, el 80386 se iba ya a los 275.000 y el 80486 a algo más de los 4 millones de transistores... en resumen una minuta, comparada con los procesadores de hoy día, por poner un ejemplo el ryzen 1000 (el mas peque de la gama) contiene 4.800 millones de transistores. Los procesadores previos, como se suele decir: "caben en el hueco de la muela" de los actuales.

Una comparativa del número de transistores que calzan los procesadores andando en el tiempo...


Claro que la forma y diseño actual en que evolucionan complica en exceso imposibilita esta tentativa (no se diseñan pensando en esto), porque tras salir una nueva arquitectura que duplica el tamaño de las líneas de sus buses, luego acaban saliendo múltiples versiones, que atienden la mitad de las veces a cuestiones mercantiles (una versión más barata o con menor consumo para...) y la otra mitad a razones tecnológicas (corregir errores, añadir alguna instrucción, ampliar la memoria caché, y más modernamente el número de núcleos), lo que practicamente imposibilita adjuntar en uno nuevo qué versión de los previos?. No se diseñan con esa intencionalidad, luego resulta imposible, pero a mi nunca me ha parecido mala idea.

Los científicos opinan que en el centro de cada galaxia hay (al menos) un agujero negro (y al menos intuitivamente tiene lógica).
Siendo así, y el carácter 'tan extraño' de los agujeros negros, no es de extrañar que en sus inmediaciones (aunque actualmente fuera del cerco de atracción sin retorno), se produzcan diversos fenómenos que no aparezcan en otros lugares de las galaxias y cuyas explicaciones tarden en ser definidas sin ambigüedad.
Después de todo, la galaxia entera está a merced de su gravedad, y pasando el tiempo todo lo que ahora está en los brazos espirales acabarán ocupando el sitio de donde ahora vienen esas señales.

Las dos borran con una ligera diferencia:
La tecla 8, borra a la izquierda del cursor (si hay algo).
La tecla 46, borra a la derecha del cursor (si hay algo).

Gracias. Pero no, tengo la PC en bucle con Pantalla Azul al arrancar.....( ¿ Dev-C++ Embarcadero; o cualquier .cpp y su .exe generado pudieron haber generado esta Imposibilidad de arranque ?? )

Mira qué error arroja el BSOD... ese texto que aparece como:
*** STOP: 0x000... (0x0..., 0x0..., 0x0..., 0x0...)
En google puedes buscarlo, y te señalará las más que probables causas (que te ayuden a repararlo), típicamente (en estos casos) es un fichero dañado que el S.O. precisa para arrancar, menos frecuente suele ser un cambio de configuración. Pero si el problema te apareció justo al hacer pruebas con tu código, va a ser lo primero...
En realidad es conveniente preguntar en los propios foros de Microsoft, pues la diversidad de detalles pueden escapar a la solución específica que a alguien le funcionó.

cin y cout no son funciones (las funciones se llaman con sus parametros entre parentesis), son objetos y de hecho son variables del namespace std. Obviamente los operadores >> y << estan sobrecargados,

By specification of std::cin, std::cin.tie() returns &std::cout. This means that that any input operation on std::cin executes std::cout.flush() (via std::basic_istream::sentry's constructor).

La sintaxis oculta la semántica subyacente, al caso no cambia nada, excepto la comodidad y tal vez claridad en según que casos...

Tengo la sensación que con la excusa de la seguridad, Microsoft evoluciona hacia un tipo de plataforma cerrada tal como Apple (y si me apuras Android), donde se imposibilita en demasía que el hardware pueda ser 'fácilmente' explotado por otros interesados. Dado que MS, no crea hardware, qué mejor que aliarse con el fabricante de un chip, que al final hace dependiente (esclavo)a otro hardware que no fue creado ni por MS ni por dicho fabricante del chip...

Así pasa la papeleta a los grandes montadores de placas base que se verán forzados a decidir cuáles y cuántos de sus diseños (placas base), quedarán así orientados a calzar un S.O. de MS u otro que no contemple tal posibilidad.

Sería deseable como mínimo que el chip TPM, fuere portado en un zócalo (así sería opcional por el que adquiere un equipo) si se monta en la placa base y no como una placa base en sí mismo (conectado por ejemplo en un puerto PCIE-1).

Si 'el mundo' evoluciona en esa dirección cualquier nuevo competidor que trate de sacar su propio S.O. tiene un nuevo hándicap que sumar a la ya difícil y dura competitidad existente. Será interesante saber que opina el 'mundo Linux' al respecto.

En cuanto al requisito de los 64bits, básicamente (en mi opinión), es una treta para dejar atrás (o por lo menos iniciar un distanciamiento) definitivamente la compatibilidad de los 32 bits y olvidarse del lastre heredado de los winXp, Vista, seven y 8 con una sola tirada de póker.

Falta por terminar de aclarar, que 'cin' y 'cout' son funciones no variables, no están sometidas a restricción alguna por el bucle. Aunque las funciones al igual que las variables tienen un ámbito de uso, las que suelen proveerse a través de una cláusula include tienen un ámbito a nivel del módulo donde se declaran.

Lo que sucede con 'cin' y 'cout' es similar a si vas a comprar a un comercio, cada producto que compras sería como usar ese 'cin' dentro del bucle y cuando vas a a pagar sería ese 'cout' fuera del bucle...
¿No sería absurdo que por cada producto que compraras tuvieras que ir a pagarlo a la caja (tras un cin forzar un cout), acaso no es mejor 'acumular' todos tus productos y finalmente cuando 'termines' pasar por caja y pagar?.

Hay varios... pero siempre se trata de heurísticas, pués como te dije no hay solución conocida al margen de la fuerza bruta.

Uno bastante asequible de implementar es:
---------------------------------------------------------
1 - Dividir el área en sectores (3x3 típicamente).
2 - Mientras cada sector tenga más de x nodos (5 o 6 típicamente), subdividir el sector de nuevo en más sectores (es una función recursiva, como se desprende).
3 - Cada sector finalmente se resuelve por fuerza bruta (5 o 6 nodos es algo muy rápido de resolver por fuerza bruta).
4 - Finalmente se van uniendo los sectores entre sí.

Esta última parte es la más compleja pues permite cierto margen de maniobra. Si el número de sectores al hacer la división no queda claramente acotado (esto es si son demasiados), se complica tomar decisiones, por eso la limitación de 3 es considerada muy aceptable.

Si el PC es del gobierno, entonces es lógico que esté protegido y que cualquier cambio o actualización esté supervisado por el gobierno aunque sea delegando a alguna empresa autorizada, pero desde luego no a título personal que cada cual pretenda hacer cambios a su antojo. Más que nada porque anque lo lograras, podrías tener algún serio disgusto si se enteran...
Imagina que luego otro usuario quiere hacer algo similar, pero ese otro trabaja en equipos de Hacienda, y que al final lo que pretende es burlar la seguridad para manipular datos a su antojo, para sus propios intereses sea con sus datos, los de sus familiares y conocidos o bajo precio a todo el que pague...
En resumen es bastante serio burlar la seguridad de un equipo tutelado por el gobierno, bajo pena de acusación de graves delitos, multa o hasta cárcel.

Límitate a seguir el conducto reglamentario, comenta a tus superiores los problams actuales y que ése a su vez comente a los suyos... esto normalmente cuando hay exceso de burocracia es una forma clara de que la aspiración se agote antes de llegar al que tiene capacidad de tomar decisiones (principal objetivo de la burocracia, estorbar a los de abajo y que no molesten a los de arriba).