En las últimas horas ha corrido el rumor de que Windows 8 empezará a soportar procesadores de 128-bit ( Windows 8 con 128 bits nativo
), todo a partir de un perfil de LinkedIn de un trabajador de Microsoft. ¿Qué credibilidad tiene este rumor? En principio ninguna, ya que es difícil y ridículo adaptar software… a una arquitectura que ni existe ni se la espera en los próximos años. La limitación que imponía los 32-bit es que solo puede trabajar con 4GB de memoria RAM, con los 64-bit este límite se queda en 16 exabytes.
Comentarios
Jo, pues entonces tendré que deshacerme del unicornio rosa invisible que tengo guardado en mi armario.
#4 Déjalo que total al ser invisible no molesta y quien sabe quizá el rumor sea cierto...
#12 Pues no veas la peste que echa el armario y lo que le tengo que dar de comer para que no se levante por la noche y moleste a los evcinos...
"16 EB ought to be enough for anybody"
#6: O no. Despues de la pifia monumental de Gates y los 640 Kb, parece que lo quieren compensar comiendose toda la RAM que les pongas al alcance.
#9 En realidad Gates dijo eso el mismo día que Zapatero llamó "hombre de paz a Otegui"
#11: Y tanto.... ¿o quizá fue cuando Ansar llamó "Movimiento de liberación vasco" a la banda terrorista ETA?
Tal vez sí #6. Cuando salieron los primeros micros (8 bits, 256 bytes) los computadores que los usaban ya tenían mas memoria que la que podía direccionarse y necesitaban paginar. Para los de 16 bits (64k) los computadores estaban muy cerca del límite (~32k), cuando salieron los de 32 bits (4g), los computadores domésticos usaban cerca de 1 Mb y los servidores algunas decenas de Mb (unos 20 bits), es decir unas 500 veces menos memoria que el límite teórico.
Esa diferencia de 20 a 32 bits tardó mas de 15 años en llenarse. Es decir algo mas de un año por bit, que corresponden con la duplicación de memoria cada 18 meses. Ahora con direccionamiento de 64 bits llegamos 16 Eb. Asumiendo la misma tasa de crecimiento en las memorias, estamos hablando de una diferencia de unos 30 bits, que perfectamente se puede demorar mas de 40 años en cerrarse a menos que aparezca una tecnología revolucionaria (que siempre puede pasar).
Eso sin considerar que esos límites son solo para el tamaño de la página (el 286 podía direccionar 16 Mb en páginas de 64k) y que una página de 4Gb es enorme y no hay aplicaciones (al menos que yo conozca) que que necesiten bloques de memoria de ese tamaño.
La venta de unicornios rosas invisibles bajará en picado ahora, todo aquel que tenga inversiones en el sector que tiemble
Habéis hecho llorar a mi unicornio rosa, cabrones. Se había comprado 128 Exabites de memoria todo ilusionado.
8??? Si no han estrenado el 7 y ya hablan del 8????
En principio ninguna, ya que es difícil y ridículo adaptar software…
Pues eso mismo hace con las gráficas cuando sale una nueva versión del directX 10, inventar el hardware a partir de las especificaciones del software (o bueno, dejarles el marrón a ATI y nvidia y que ellos se apañen)
Del sistema de ficheros basado en bases de datos que iba a ser la revolución en el Vista aún nada. Hablaremos en el Windows 10, ¿no?
#1 La pega es que creo que el Windows 7 ha tenido poca innovación, salvo guardar lo que iba bien en el Vista y cambiar algunas constantes del XP (tipo MAX_CPUs = 2 y cosa así)
#19 Tengo 2 servidores xeon de 32 bits de hace 5 años con 8 GB de ram corriendo una debian.
uname -a
Linux adonis 2.6.24-19-server #1 SMP Wed Aug 20 23:54:28 UTC 2008 i686 GNU/Linux
cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 3.20GHz
stepping : 5
cpu MHz : 3189.562
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pebs bts sync_rdtsc cid xtpr
bogomips : 6382.92
clflush size : 64
cat /proc/meminfo
MemTotal: 7793496 kB
MemFree: 5012236 kB
Buffers: 227020 kB
Cached: 1994900 kB
SwapCached: 0 kB
Active: 1550536 kB
Inactive: 1124720 kB
HighTotal: 6946788 kB
HighFree: 4489308 kB
LowTotal: 846708 kB
LowFree: 522928 kB
SwapTotal: 3935916 kB
SwapFree: 3935916 kB
Dirty: 68 kB
Writeback: 0 kB
AnonPages: 441492 kB
Mapped: 223264 kB
Slab: 60664 kB
SReclaimable: 47348 kB
SUnreclaim: 13316 kB
PageTables: 2536 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 7832664 kB
Committed_AS: 1307784 kB
VmallocTotal: 118776 kB
VmallocUsed: 4744 kB
VmallocChunk: 113912 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
#21 y yo tenia un ZX Spectrum +2 de 128Kb de RAM con un procesador Z80 con un bus de direcciones de 16 bits 2^16= 65535 =64 Kb... ¿como es posible?...
Las chapuzas de este tipo son bastante antiguas
#22 El PAE no deja de ser otro parche o chapuza que causa inestabilidad en algunas aplicaciones que se pensó cuando los procesadores de 64 bits no eran comunes. Pero hoy en dia que TODOS los procesadores que se fabrican y venden son de 64 bits, utilizar esto del PAE es una chapuza pudiendo usar un SO de 64bits linux, windows y demás...
Lo que pasa que hay mucha gente conservadora en este sentido.
#40 Tampoco te quejes tanto de los negativos, negar la importancia de la limitación de 4 GiB para pasar a 64 bits es absurdo.
Durante la historia siempre que un sistema andaba justo para direccionar memoria han aparecido extensiones, son útiles para aprovechar tanto hardware como software pero a la larga añaden complejidad y otra serie de problemas como cargarse la compatibilidad con versiones que no soporten estas extensiones. Sin embargo como puedes notar no tenemos procesadores de 16 bits e interminables indirecciones, en cierto punto los inconvenientes de las extensiones y la emulación hacen mucho más apetecible el cambio.
En este caso se me ocurren dos factores que pueden haber acelerado el proceso. El cambio desde la carrera de los GHz a los multinúcleo que supuso un pequeño parón y tiempo para evolucionar y el auge de la virtualización.
#40
Pues teniendo en cuenta tus conocimientos, deberías de saber los inconvenientes de usar las extensiones (memoria extendida de toda la vida, más o menos), algunos de los cuales ya te los menciona #50 a grandes rasgos.
#49
Si quieres hacer cálculos complejos coge tu tarjeta gráfica y hazlo, que para algo son procesadores vectoriales y no de propósito general como tu AMD Phenom o Intel Core con su "pequeño" juego de instrucciones SIMD (Single Instruction Multiple Data), pequeño en comparación con una GPU claro.
Mírate el CUDA para nVidia, para ATI creo que se llama Stream SDK. También tienes OpenCL.
#51 Y cuando he negado yo eso? Evidentemente que PAE tiene ciertas penalizaciones, pero también ciertas ventajas. De lo único que me he quejado y es de donde viene toda la discusión, es que no es cierto que sea necesario pasar a 64 bits para utilizar más de 4 GB.
La noticia es errónea por parte del unicornio. El color es un reflejo de la luz en diferentes longitudes de onda que apreciamos como colores. Así que el unicornio puede ser rosa o invisible pero no las dos cosas a la vez.
#8 Sí, ese error va a causar la quiebra de Microsoft. No importa ni todos los windows 7 que se van a vender este año ni la xbox.
En fin.
HOYGAN TENGO UN UNICORNIO ROSA ENCHUFADO AL USB1.34 CON WINDOWS 8 Y NO ME FUNCIONA, YO TENGO 500 GB DE MEMORIA QUE ME VENDIO UNO DE MI VARRIO, ¿ALGUIEN ME PUEDE DE AYUDAR?. GRACIAS DE ENTRETIEMPO
PD - OS LEO MUCHO Y ME REGUSTA MUCHO SU FORO.
#30 ¿Has probado a apagarlo y encenderlo?, ¿está enchufado?
PD: Tienes varios errores, has escrito bien enchufado y vendió .
#30 el problema que tu unicornio rosa no es invisible, los unicornios rosas normales son incompatibles con Win 8!!!
Me dijo el hermano del primo de un amigo que dice que trabaja en microsoft, que WIndows 8 va a soportar el chip gordo, siempre y cuando, el celulino de la placa se mantenga intacto.
#35 el hermano del primo de tu amigo es el primo de tu amigo...
¡¡Queremos un Canon que nos compense a todos los que compramos URI's (Unicornios Rosas Invisibles)!!
Bueno, lo siento si he ofendido, pero a veces, parece que contestáis por contestar. Y creo si no estoy equivocado que todo MMX, SSE1-2-3-4, 3DNOW. En modo kernel no se puede utilizar. Lo digo por que yo he trabajado con el kernel de linux. Las sumas de floats no se podían hacer con esas instrucciones
Reconozco que el marketing en internet es cada vez mas ingenioso, pero esto es una mierda.
ah, ¿pero si con unicornios rosas visibles? uff, menos mal, ya me temia lo peor
Son las 7:00 y me he leído todos los comentarios (que para mi eran mas importantes) de esta noticia y me voy a tomar un cafe ahora mismo para despejarme un poco porque me ha enganchado los pikes y puntos de vista de cada uno, por supuesto ni que decir tiene que cada uno lleva su parte de razón lo que ocurre es que los Informáticos cuando se les mete algo en la cabeza es muy difícil hacerles cambiar de opinión a menos que se lo des en forma de papilla y copos de maiz con forma de 0 y 1, podría opinar sobre algunos temas aquí tratados pero tal y como ha estado el patio prefiero seguir leyendo de paso aprendiendo y sobre todo catalogando, por cierto soy mas de Software, mi blog así lo demuestra.
50# No es un paron GHz sino que es lo más lógico que tenían que hacer, por que como he dicho la física manda y el calor (llamemos le potencia consumida) que se desprende con relojes a más 3 GHz, era demasiado para el tamaño de integración, el primer paso que intentaron es reducir la diferencia de voltaje entre 0 y 1 que antes era de 5 V a 0 V y ahora es mucho menos que puede que sea de 1 V o 2 V como mucho esto hace reducir el consumo de potencia pero a esas velocidades de cambio calienta demasiado (consume potencia como una barbaridad y recordar consumir potencia y disiparla es importante para no joder una cpu) y además a estos niveles de miniaturización las perdidas de corriente son grandes, con lo cual más consumo de potencia. Entonces por lógica y por limitación física el paso coherente es pasar de 32 a 64. Ahora el paso es hacer multinúcleos (multithreading es otra cosa y recordar que esta relacionado con 64 bits). Que esta muy bien, pero como sabréis no todas las aplicaciones en potencia de cálculo son aptas para multithreading y es mejor subir el clock de reloj. Por eso se hacen pruebas con nuevos materiales que disipen mejor la potencia, es decir, que consuman menos potencia y poder subir clock. También lo que estan realizando son nuevas arquitecturas tipo Cell que lo importante es la arquitectura de bus. O Sun con sus nuevos sparc bueno no me acuerdo del nombre.
Por el último comentario se nota que no tienes ni idea de lo que hablas. Gracias por aclararmelo. CUDA y Stream SDK no hacen que tu sistema operativo como sistema operativo funcione más rápido o permita más cosas. Sino que hacen calculos a saco. Por cierto no se que driver necesita realizar calculos de ese tipo. Ni que sistema de archivos, ni que pila de protocolos de red, No sigo más porque me sulfuro. Por favor, habla de lo que sepas no de lo que te suene.
#52
¿Uh? Yo te estoy hablando precisamente de eso, de realizar operaciones matemáticas, no del sistema operativo y las tareas que haga, el cual no hace nada complejo precisamente y por eso las CPUs de hoy día ya hacen bien su cometido, el de procesado general que es para lo que están hechas.
Por otro lado, para utilizar una tarjeta gráfica como co-procesador no necesitas más que instalar el driver y el entorno de desarrollo. Luego es cuestión de utilizar las librerías que tienes a tu disposición en tu programa.
Tengo una nVidia 8800GTS y la he utilizado para colaborar con Folding@HOME y ya te digo que no necesitas nada especial.
Por último, más vale que rectifiques tu "no tienes ni idea de lo que hablas" porque:
1) No me conoces.
2) No sabes a lo que me dedico.
Espero que sólo fuera un malentendido.
#53 Vuelvo no sabes de lo que hablas. Por ejemplo, con una arquitectura de 64 bits puedes crear instrucciones para que de una vez se hagan dos sumas de enteros un tipo de cálculos vectoriales pero en enteros. Esto también con comparaciones, etc, etc... Las formas de direccionamiento aumentan haciendolas más complejas. Y un largo etc.
Osea que si tu aumentas el tamaño de palabra de una CPU ganas más potencia de procesamiento de otra forma que aumentando la GHZ o el número de CPUs. Por lo tanto, 64 bits no es solo para direccionar más memoria sino para aumentar la capacidad de procesamiento.
Lo mismo te digo con que:
1) No me conoces.
2) No sabes a lo que me dedico.
Por lo tanto, lo único que quería decirte es que no es solamente tu posición sino hay varias circunstancias. Y que yo no estoy de acuerdo que la más importante sea la de direccionamiento de memoria, que también. Sino que hay más cosas que hacen que sea una opción muy rentable y una mejora muy substancial para hacer arquitecturas de 64 bits. Por que sea para tí y tus circunstancias importante no quiere decir que haya otros motivos que hagan que sea importante el cambio.
#54 Me meto en la discusión, con permiso de ambos.
Efectivamente el rendimiento del procesador al pasar a 64 bits aumenta, principalmente porque el paso a 64 bits ha traído un ancho mayor de palabra para la trasferencia de información de memoria, registros de propósito general mayores y nuevas instrucciones. Todo ello ha mejorado el rendimiento.
Sobre CUDA, no estoy muy metido (conozco a alguien que si) y la verdad es que canta maravillas. La paliza que le dan al procesador en calculo vectorial es exagerado. Para desarrollo con CUDA, poco mas que el driver y las librerias.
Asi que lo dicho, CUDA esta muy bien, los 64 bits esta muy bien y ambos teneis vuestro punto de razón.
Y yo sigo en mis trece, el direccionamiento en x86 ya era bastante cutre sin PAE, y que pasar a 64 bits son todo ventajas.
#54
Por ejemplo, con una arquitectura de 64 bits puedes crear instrucciones para que de una vez se hagan dos sumas de enteros un tipo de cálculos vectoriales pero en enteros.
Eso ya existe, como ya he dicho antes: las SIMD. Un vector no es más que un porrón de elementos seguidos y juntitos en memoria. El llamarlo vector es por llamarlo de alguna forma, pero no dejan de ser bytes. Si quieres hacer dos sumas o las que sean en paralelo (siempre que entren), utilizas una instrucción SIMD sobre dos vectores de enteros y fuera, cogiéndote los dos elementos, los mete en sus registros de hasta 128bits y suma carracos de cagarte las patas abajo.
Por otro lado, los procesadores tienen varias unidades de ejecución. No tienen un único sumador, tienen varios, del mismo modo ocurre con los comparadores. Hoy día ya se tienen cientos de instrucciones ejecutándose en paralelo, varias por etapa (Fetch, Decode, Execution, etc.), no tiene nada que ver con el ancho de palabra que, básicamente, significa poder mover datos más grandes, aparte de poder direccionar mayor cantidad de memoria. En x86_64 (AMD64, bautizada por AMD que fue quien la ideó) también se traduce en más registros. Con IA64 no sé porque no conozco esa microarquitectura.
Para aclararte un poco, las instrucciones SIMD son:
MMX, SSE1-2-3-4, 3DNOW, etc. y no funcionan sólo con números de coma flotante, también funcionan con enteros. Yo he programado con esas instrucciones, y es un gustazo ver como mejora el rendimiento del programa.
PS: Releo tu comentario y creo que te equivocas de persona->Para mí los 64 bits no son sólo mayor capacidad de direccionamiento como ya comento en este mismo mensaje.
¿Y será compatible con sirenas israelíes?
Segire creyendo en el Espagetti.
Habria que preguntar a los unicornios rosas invisibles si ellos quieren algo con Windows, que aqui todo el mundo obvia su opinion...
Hay rumores que aseguran que los pingüinos funcionan mejor que los unicornios rosa, los leopardos de nieve y las ventanas...
Y con unicornios rojos?
¿Qué credibilidad tiene este rumor? En principio ninguna, ya que es difícil y ridículo adaptar software…
O sea que al final todos rumorean, nadia sabe nada a ciencia cierta
#42 Hace ya como 3 años que no estoy por ahí. Estaba en el grupo de computación distribuida pero al final con el trabajo no daba a basto y tuve que decidir entre dejar de trabajar o dejar de investigar y evidentemente antes prefiero comer.
Después de hacer la técnica empecé con la superior, pero al final lo dejé (problemas personales con un elemento de los de "usabilidad" tu ya me entiendes) me decanté por la UOC.
Los compañeros me llamaban torrente, así que a lo mejor te suena o no, depende del año que comenzaras.
¡¡¡Woah, 16 exabytes de PR0N!!!
Sólo de imaginarlo... fap, fap, fap
al unicornio rosa no le gusta este meneo http://bit.ly/FeyW2
Que ? tira un bluescreen con el unicornio rosa invisible?... digo ... porque si es invisible como saben que es rosa? .....
jeje.. nahhh.. es un chiste ... buena noticia
¿que? ¿que mi amado unicornio rosa invisible no podrá disfrutar del windows 8? ¡¿Por que le discrimináis?!
Ahora me enfado y no respiro hasta que mi unicornio tenga su windows 8
Espara ser un poco trolls
logra rendimiento en cierto tipo de operaciones matemáticas, concretamente las operaciones de matemáticas de enteros que también añaden todas las operaciones para calcular direcciones de memoria sin tener que inventarse nuevas instrucciones cuando quieres calcular direcciones o valores más grandes de 32 bits. Además el movimiento o transferencia de memoria a CPU o de CPU a memoria se puede decir que múltiplica por 2. Además de que se puede aumentar el número de instrucciones existentes.Ya se que no es del todo cierto pero digamos que a grandes rasgos sí.
Por lo tanto, díria que no es solamente por memoria, ya que estaba solucionando con el bit PAE aunque la gente crea que es una guarrada, sino que lo que hace es que mejora ampliamente la potencia de calculo en MIPS (el nombre no me acuerdo bien) no en FLOPS que para eso se inventaron una cosa que se llama MMX y todo lo que vino después y que nunca llego a recordar. Para lo desconocen de informatica las operaciones que realiza un sistema operativo son todas del tipo entero (MIPS) ya que muchas veces no tienen acceso a los registros e instrucciones para el calculo de coma flotante (FLOPS).
Ya sé que es un poco no es del todo cierto pero por ahí van los tiros. Si no recordaros porque se paso de 16 bits a 32 bits. O lo mismo que las consolas utilizan 128 bits en sus CPUs (algunas) y no son realmente solamente sus GPU (gráficas).
Por que no hacer CPUS 128 bits problemas cuando se fabrica o se diseña la CPU. Que la física por ahora manda y hasta que no se minituaricen más pues las cpus complejas como las tenemos no podran aumentar su tamaño de palabra o de instrucción.
Ya se que hay CPUS de este tipo pero no es lo mismo.
windows no va ni con pilas, ni siquiera con manivela. pasense a linux o mac
Desde luego es otra cagada propagandística de Microsoft, o así lo veo yo.
#5 No, es una cagada de alguien con un poco de idea de "informática" y nula idea de arquitectura de computadores, de procesadores, o de informática en general, lee "128-bits" en algún sitio y automáticamente genera el titular "Windows 9 (y posiblemente Windows será compatible con procesadores de 128-bits". Tarjeta roja además para sitios como OSNews que van de profesionales pero les cuelan cada cosa en portada que ríete tu de la prensa amarilla.
Microsoft quebrará antes de que pueda sacar Windows 8
#3 Va a ser que no. http://www.idg.es/computerworld/Microsoft-factura-mas-de-60.000-millones-de-dolare/seccion-/noticia-69985
#7 espérate a ver las cifras del año que viene Microsoft hace públicos los datos privados de miles de usuarios de Bing
Microsoft hace públicos los datos privados de mile...
techmez.com#7 http://www.theinquirer.es/2009/09/30/rebaja-de-sueldos-para-ejecutivos-de-microsoft.html
En otros sistemas operativos no existe el límite de 4GB en arquitecturas de 32 bits, por lo que la excusa de haber pasado a 64 bits para poder superar esa barrera de la memoria es más falsa que un duro de madera.
#17 eso que dices, ¿lo leíste en algún foro verdad? ¿o te lo contó algún amigo?
La cantidad memoria que puede manejar un sistema operativo tiene mucho que ver con la arquitectura del procesador, ya que los procesadores de 32 Bit, están preparadas para correr memorias de 4 GigaBites. Mientras que los procesadores de 64 Bits, están preparados para manejar ram con un limite de 17 Exabites
asi que tu comentario es mas falso que un duro de madera
#19 y cuantos BocaBites forman un BocaByte? =D
#20 Prefiero las 3D Aunque algunos prefieren los pelotazos. (De matutano no de esos de los de "arriba")
#17 #19
#21 (mira el CPU flag PAE)
http://es.wikipedia.org/wiki/Extensi%C3%B3n_de_direcci%C3%B3n_f%C3%ADsica
En informática, extensión de dirección física (en inglés, Physical Address Extension o PAE) se refiere a una característica de los procesadores x86 que permite a los sistemas de 32-bit utilizar hasta 64 gigabytes (64 GiB) de memoria física, suponiendo que el sistema operativo proporcione el adecuado soporte. PAE está disponible en las CPUs Intel Pentium Pro y superiores (incluyendo todos los procesadores de la serie Pentium posteriores excepto las versiones con bus de 400 MHz del Pentium M), además de ciertos procesadores compatibles como los de AMD. El flag CPUID PAE se utiliza para identificar a las CPUs con esta habilidad.
#19 Joder tio, me parece que #22 te ha hecho un OWNED en toda regla (si, asi con mayusculas).
Ahora bien, aunque es cierto que con PAE se puede redirigir bastante mas memoria, tiene dos limitaciones básicas.
Primera, para resolver el problema de gestionar mas memoria se hace lo que se hace siempre en informática: añadir un nivel mas de indirección. Vamos, que al final tienes un puntero que apunta a un puntero que apunta a un puntero de la memoria.
El segundo, es que aunque el sistema gestione mas de 4GB, en principio las aplicaciones no son conscientes de ello. El truco esta en decirle a cada aplicación: "Tienes absolutamente toda la memoria a tu disposición" (si las aplicaciones fueran inteligentes se preguntarian que le queda al SO, pero bueno, no lo hacen). La applicación por tanto usa hasta 4GB de memoria sin problema, y puedes tener otra aplicación concurrente a su vez usando 4GB de memoria (y otra, y otra...), pero individualmente cada aplicación no usa mas de 4GB. Hay formas de saltarse este limite, pero vamos, ya son autenticas aberraciones y necesitan que la aplicación este preparada para ello.
Por lo tanto, ¿era necesario cambiar a 64 bits?
Sin duda
¿Vino este cambio motivado por el tema de 4GB?
Fue el factor mas importante
¿Alguna ventaja adicional?
Se limpia bastante el sistema de direccionamiento de paginas de memoria que en x86 ya daba algo de asco y se logra rendimiento en cierto tipo de operaciones matemáticas.
¿Algo mas que comentarnos?
No, muchas gracias a todos
#39 Como bien dices, depende de la aplicación. En esas máquinas (comentario num #21) tengo jboss corriendo, con 6 GB de memoria asignados a la JVM (cuestión de tocar los parámetros del heap y el stack) y como ya he dicho antes es una máquina de 32 bits.
Respecto a mi comentario num #17 me ha quedado claro que hay muchísima gente que no tiene ni idea de arquitectura de computadores, simplemente hay que ver la cantidad de negativos que me han puesto sin tan siquiera informarse, pero nada, que va a saber un tío que simplemente estuvo haciendo investigación en el departamento de computación distribuida de la politécnica de Lleida (EPS) modificando el modo en que el Kernel de Linux (rama 2.4) hacía los accesos a memoria para optimizar el rendimiento del cluster. Por lo que veo debo de ser más tonto que pichote y no tener ni idea aún teniendo Ingeniería informática y 2 masters de programación.
#40 ¿Nos conocemos? ¿Sigues aún por la EPS?
PD: Esta mañana me lo he pasado teta leyendo los comentarios en Noticias3D:
http://www.noticias3d.com/noticia.asp?idnoticia=35692
Hay cada perla...
#40 Supongo que a la mayoría que votaron negativo tu comentario les sonaba a "linux/mac fanboy".
#39, muy bien explicado, y el cierre del comentario muy gracioso
Como bien dice #39 , #22 ha echo un Repowned a #19 . Pero la verdad , el sistema de karma de meneame es una maravilla , solo falta que uno demuestre de verdad que las patochadas de otro son mas falsas que las zapatillas de plastico de pinocho .
Que bien que uno acostumbra a leer bien antes de escribir y de escribir poco y solo cuando se tiene algo seguro. Aunque no quiero desviarme del tema , muchas veces aprendo mas de los comentarios de meneame que de las propias noticias .
Un aplauso para los que SI saben .