Downgrade para el Kernel

Fuente original

Noticia en Euraisa:

robinsod over at xboxhacker.net may have found a way to downgrade the kernel! He have mounted the HYNIX flash in a socket and are sniffing the flash bus during the 360 power on sequence. Apparently the old kernels are still there, the system just select newest one based on the header, so by erasing the header of newer kernels robinsod managed to select 2.0.1888.0 (the oldest known kernel). To verify this he needs to perform more tests like loading the kiosk disk which supposedly requires this old kernel to load


Esto se pone muy interesante.


Robinsod de xboxhacker.net pudo haber encontrado una manera de desactualizar el Kernel. Él ha montado el flash de HYNIX en un zócalo y ha capturando los datos del bus durante la sequencia de arranque de la 360.

Los viejos Kernels todavía están al parecer allí, simplemente el nuevo kernel esta seleccionado en la cabecera. Borrando la cabecera del nuevo kernel ha podido seleccionar el 2.0.1888.0 (el más viejo kernel conocido). Para verificar esto que él necesita realizar más pruebas como cargar el disco del quiosco para comprobar que sea cierto.
ostras que wapo no??jejej podrias traducirlo please.o mas o menos que seria tipo psp?gracias flash porque noticias como las tuyas son la que me hacen mas ilusionado cada dia con mi blanquita gracias
valla, valla esto se pone interesante y me va gustandooo!!
Tiene buna pinta [boing]
Gracias flash78
Vaya noticion, haber si dentro de poco sale algo interesante, un downgrade rollo psp!!Dios necesito meter un disco duro mas grande...
El problema es q con PSP funcionaba el homebrew desde la primera version del Firm, mientras q en XboX nunca lo ha hecho, aunq claro, si cnsiguen hacer correr el kioskdisk en un firm downgreado(vaya palabro), podrian poner un kernel propio y hacer creer a la consola q es el q debe usar?

Yo por hacerme pajas mentales, q no qde [tomaaa]
Mi sueño es que la 360 sea mi próximo pc de sobremesa y dar una patada la mielda torre desde la que escribo. [inlove]
Interesante, haver si se saca algo de esto y pronto podemos trastear.
guau esto se pone muy interesante. Grs Flash78
Para alguien novato como yo... Esto entonces es una buena noticia? Qué puede significar?
mm pues como siempre a esperar XD
Para verificar esto que él necesita realizar más pruebas como cargar el disco del quiosco para comprobar que sea cierto.


Coño! pues que lo ponga haber que pasa!!!!
Lion_omega escribió:

Coño! pues que lo ponga haber que pasa!!!!


El tal robinson se ve que se ha dado de baja de internet,y dice que ahora no puede bajar el quiosk disk, asi que toca esperar!!:D
davilillo escribió:
El tal robinson se ve que se ha dado de baja de internet,y dice que ahora no puede bajar el quiosk disk, asi que toca esperar!!:D


juassssssss
yo le envio el mio.... donde donde hay que enviarlo *^^

buenas noticias...
robinsond ha actualizado con info interesante para los gurús de por aquí:

Doing this yourself:

1) You need to mount the flash in a socket
2) You need a programmer that can support this flash - I made my own. You MUST be able to write both the 512 & 16 byte areas
3) Dump the flash and Identify the "CD" & 2 "CF" (CD appears to be the kernel and the CF sections are part of the patches) sections and the version numbers of each
4) Damage/corrupt/erase the patch(es) you want to invalidate, in other words break the signature so the 360 does not load the patch
5) Prayer, I appear to have made myself a curvy beige brick by applying and removing the 4552 patch

...y parece ser que se ha cargado la consola xD.
Nunca está de más tener un pisapapeles... [triston]
entonces que creeis que al final se tirara mano de un chip que haga de kernel parcheador o todo sera via soft.no se podria hacer como un dualfirm.no me hagais muxo caso no tengo ni idea solo son ideas que no se si son factibles o no.
a todo esto me bajado un zip de la pagina de xboxhacker que pone hynyx_flash_reader.

alguien sabe para que sirve?

y no tiene un exe son todo archivos sueltos.
Vamos a ver señores, calma.
Lo que se ha descubierto es que la consola guarda los kernels viejos(seguramente por que en realidad tendrá un kernel base y el resto son parches sobre este haciendo así que si una actualización se jode por medias no te joda la consola por ejemplo) pero nada mas, es decir esto sería interesante si se descubriera un fallo en alguno de los kernels que existen hasta la fecha pero para nada mas y por ahora ningún kernel a tenido ningún tipo de fallo.
Lo del kiosk disk tampoco os emocionéis, simplemente ese disco en su firma permitía que se cargase desde un dvd-r y en actualizaciones posteriores M$ vetó la ejecución de ese disco directamente vía kernel y lo quiere usar para ver si realmente la consola tiene cargado ese kernel.
Por ahora lo bueno simplemente es que se sabe un poco mas de como guarda las cosas la consola en la flash pero de aplicación futura por ahora no tiene casi nada
bueno aqui pongo unas fotos del cacharro con el cual a hecho el down:
Imagen


Imagen
Juas! sera por soldaduras X-D

Algo es algo, a ver q sacan de ahi :)
El caso es explotar la utilidad , pero vamos esto es un buen avanze , poder grabar nuestra propia bios y tal aunque no funcione pero algo es algo. Con un willem y una estacion eso esta mamao aver si tengo tiempo y le meto mano.
elchewi escribió:El caso es explotar la utilidad , pero vamos esto es un buen avanze , poder grabar nuestra propia bios y tal aunque no funcione pero algo es algo. Con un willem y una estacion eso esta mamao aver si tengo tiempo y le meto mano.


Facil? a mi solo de pensar q habria q hacer eso me entran taquicardias [mad]
Todo lo que ha hecho Microsoft tiene fallos de seguridad por todas partes. Tapa un fallo y le salen 2.

¿Seguro que la 360 la ha fabricado Microsoft? :Ð :Ð :Ð

UN SALUDO
jajajjaja yo de solo ver todas las soldaduras me da algo peo despues pienso y si se puede hacer ummmhhh........
ajjajajajajaj

hombre por lo menos yo creo que es como un modchip no?ahora lo ideal seria sacar la info del kernel y apartir de hay como dicen sin tocar nada del primer kernel intentar parchear cosas para poder meterle mano.esto se esta poniendo cada vez mas interesante.he visto en una pagina que haber si la consigo de nuevo donde un tio ha conseguido modificar los shaders y sale en pantaya como un menu.yo creo que al final se creara un dualfirm.vosotros que opinais?

aqui os dejo lo que ha hecho(yo no tengo ni pajolera)

I now have 2 360s which have been upgraded to the 2.0.4552.0 Kernel. Neither box will boot if a flash without the 4552 patch is used!!! I verified this with a brand new 360 Core (This one was bought in Munich, today and came with K/D 2.0.2241.0 and a Samsung MS25 - there's still some old stock floating around)

Test procedure:

1) Remove flash and dump, copy to spare flash
2) Install update 2.0.4552.0 (using copy on spare flash)
3) Reinstall original flash (2.0.2241.0) 360 will not boot, black screen for approx 45 seconds followed by flashing red lights
4) Reinstall updated copy on spare flash (2.0.4552.0) and 360 boots normally

WTF??? The original (completely untouched) flash delivered with the console will NOT boot after the 4552 patch has been applied. Something has been changed outside the flash that invalidates the Kernel if the 4552 patch is absent. Analysing the bus activity shows that the read sequence has changed, the Kernel is loaded as normal and both patches are read fully (previously only the most recent was loaded) the boot sequence then repeats.

One other oddity observed in the new flash is in the 512 byte at page 0

Bytes from block 0 of Xbox A:

00000000 FF 4F 07 60 00 00 00 00 00 00 80 00 00 06 C0 00 ÿO.`......€...À.
00000016 A9 20 32 30 30 34 2D 32 30 30 35 20 4D 69 63 72 © 2004-2005 Micr
00000032 6F 73 6F 66 74 20 43 6F 72 70 6F 72 61 74 69 6F osoft Corporatio
00000048 6E 2E 20 41 6C 6C 20 72 69 67 68 74 73 20 72 65 n. All rights re
00000064 73 65 72 76 65 64 2E 00 00 00 00 00 00 00 00 00 served..........
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000096 00 00 00 00 00 06 C0 00 00 02 07 12 00 00 40 00 ......À.......@.
00000112 00 00 00 00 00 00 00 00 00 00 30 00 00 00 10 00 ..........0.....

Base Kernel is 2.0.1888.0 (0x760)
Bring up code ("CB" Section) is at 0x8000, length 0x61E0, Version 1888
Kernel ("CD" Section) is at 0xE1E0
Patches ("CF" Sections) are at 0x6c000 and 0x7c000

Bytes from block 0 of Xbox B:

00000000 FF 4F 07 60 00 00 00 00 00 00 80 00 00 07 00 00 ÿO.`......€.....
00000010 A9 20 32 30 30 34 2D 32 30 30 35 20 4D 69 63 72 © 2004-2005 Micr
00000020 6F 73 6F 66 74 20 43 6F 72 70 6F 72 61 74 69 6F osoft Corporatio
00000030 6E 2E 20 41 6C 6C 20 72 69 67 68 74 73 20 72 65 n. All rights re
00000040 73 65 72 76 65 64 2E 00 00 00 00 00 00 00 00 00 served..........
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000060 00 00 00 00 00 07 00 00 00 02 07 12 00 00 40 00 ..............@.
00000070 00 00 00 00 00 00 00 00 00 00 30 00 00 00 10 00 ..........0.....

Base Kernel is 2.0.1888.0 (0x760)
Bring up code ("CB" Section) is at 0x8000, length 0x9310, Version 1903
Kernel ("CD" Section) is at 0x11310
Patches ("CF" Sections) are at 0x70000 and 0x80000

The "CB" code is aparently used to boot the main CPU

So, yeah Tiros, there is at least a pointer to the first patch and the second is always found 0x10000 bytes later

The pin header on the motherboard connects via 40 way ribbon to a board on the top of the 360 that carries the flash.

As for the programmer, really it's just the Embedded Artists LPC2148 module plus prototype board and some pin headers. See the "homegrown hynix reader" thread

fuente:xboxhacker.net

si alguien puede traducirlo se lo agradeceriamos y que nos diga el nivel de difilcultad que tendria el crear un cacharro de esos.
gracias
nax gente:
Esto creais o no es SUPER interesante!
Hasta ahora la gente (los que pilotan de agujeros de seguridad y estas cosas) no estaban buscando agujeros de seguridad en kernels viejos sino en la propia consola.
Con esto (si es real y factible) lo mas probable es que cargen el primer kernel en la consola y se pongan a descubrir agujeros. Lo que esta claro es que si existe algun agujero de seguridad sera en la primerisima version.

No me extrañaria demasiado que si este metodo de "downgradear" la consola se hace viable, se consigan avances importantes en el verano (aprox) utilizando el primer kernel conocido de la consola.

un saludo
-DAVIZINHO-
Esto huele a psp por todos lados xD, al final que paso con el chaval ese, se cargó la consola o esta en ello¿?
Si se ha cargado la consola podemos ir olvidandonos de avances por una temporada.
DAVIZINHOX escribió:nax gente:
Esto creais o no es SUPER interesante!
Hasta ahora la gente (los que pilotan de agujeros de seguridad y estas cosas) no estaban buscando agujeros de seguridad en kernels viejos sino en la propia consola.
Con esto (si es real y factible) lo mas probable es que cargen el primer kernel en la consola y se pongan a descubrir agujeros. Lo que esta claro es que si existe algun agujero de seguridad sera en la primerisima version.

No me extrañaria demasiado que si este metodo de "downgradear" la consola se hace viable, se consigan avances importantes en el verano (aprox) utilizando el primer kernel conocido de la consola.

un saludo
-DAVIZINHO-

Pos viniendo de M$ es bastante mas factible que los fallos sean en las actualizaciones que en su primera versión.
Además tener una consola de primera versión la tiene muchísima gente, simplemente con no haberla actualizado.
Aún así no esperéis algo estilo psp ni de coña que la psp y eso se parecen como un monje a un puercoespin en la manera de funcionar.

PD: Seguramente de los kernels que existen hasta ahora el mas "estudiado"(de lo poco que se sabe de ellos hasta ahora) sea con diferencia el primero
bueno os pongo mas de lo que he encontrado si alguien sabe traducir algo mejor que mejor.

actualizacion diciembre del 2006

Dump of file December2006.xex

FILE HEADER VALUES
1 module flags
title module
92000000 load address
AB5000 image size
FFFFFFFF game region
North America
Japan
rest of Asia
Australia/New Zealand
rest of Europe
rest of world
10000000 image flags
4KB pages
4 allowed media types
DVD/CD

XGD2 media ID: 00000000000000000000000000000000

Signature digest: A8EACCCF B7E821EE 88AD02DB 2EE45C2E 18B603D1

D number of optional header entries

OPTIONAL HEADER VALUES
92000000 image base address
92018EE0 entry point
000CA54F image checksum
457DD57D image timestamp
40 number of TLS slots
00010000 default stack size

COMPRESSED, ENCRYPTED

Original PE image name: installupdate.exe

Image includes Xbox 360 Logo

LAN key: 00000000000000000000000000000000

EXECUTION ID
1746B9BF media ID
20139600 version (2.0.5014.0)
20139600 base version (2.0.5014.0)
FFFEFFFE title ID
0 platform
0 executable type
0 disc number
0 discs in set
00000000 save game ID

SYSTEM IMPORT LIBRARIES
xam.xex version 2.0.3215.0 (minimum 2.0.1861.0)
xboxkrnl.exe version 2.0.3215.0 (minimum 2.0.1861.0)
xam.xex version 2.0.3215.0 (minimum 2.0.1861.0)

LIBRARY VERSIONS
XAPILIB 2.0.3215.0 [expired]
LIBCMT 2.0.3215.0 [expired]
XBOXKRNL 2.0.3215.0 [expired]
D3D9 2.0.3215.1 [expired]
D3DX9 2.0.3215.0 [expired]
XUIRUN 2.0.3215.0 [expired]
XUIRNDR 2.0.3215.0 [expired]
XAUD 2.0.3215.0 [expired]
XGRAPHC 2.0.3215.0 [expired]

RESOURCE SECTION #1
UPDATES name
920CA000 base address
9DB0BC size

RESOURCE SECTION #2
MEDIA name
92AA5100 base address
F620 size


y este otro:

XUIKeyboard example program compiled using the XDK360

Dump of file xuikeyboard.xex

FILE HEADER VALUES
1 module flags
title module
82000000 load address
350000 image size
FFFFFFFF game region
North America
Japan
rest of Asia
Australia/New Zealand
rest of Europe
rest of world
0 image flags
64KB pages
8000605 allowed media types
hard disk
DVD/CD
SMB filesystem
direct-from-RAM
Live-signed package

XGD2 media ID: 00000000000000000000000000000000

Signature digest: 4793FEA6 99BEF6FC D3A7B8C3 9F4782F7 D2B21DF3

A number of optional header entries

OPTIONAL HEADER VALUES
82000000 image base address
82091E98 entry point
0034D751 image checksum
4582AFBE image timestamp
40 number of TLS slots
00040000 default stack size

NOT-COMPRESSED, ENCRYPTED

Original PE image name: XuiKeyboard.exe

LAN key: 00000000000000000000000000000000

SYSTEM IMPORT LIBRARIES
xam.xex version 2.0.4929.0 (minimum 2.0.1861.0)
xboxkrnl.exe version 2.0.4929.0 (minimum 2.0.1861.0)

LIBRARY VERSIONS
D3D9 2.0.4929.0 [approved]
D3DX9 2.0.4929.0 [approved]
XAPILIB 2.0.4929.0 [approved]
XBOXKRNL 2.0.4929.0 [approved]
XUIRUN 2.0.4929.0 [approved]
XUIRNDR 2.0.4929.0 [approved]
LIBCMT 2.0.4929.0 [approved]
XGRAPHC 2.0.4929.0 [approved]
XACT 2.0.4929.0 [approved]
XAUD 2.0.4929.0 [approved]
X3DAUD 2.0.4929.0 [approved

Personally I'm trying to get my hands on the Key.bin, plus figure out the password so that I can compile using the XDK360 so my programs will run on the retail kit. Developer Kits are quite expensive and in short supply atm, so development on the hardware is very slow especially with a number of programmers using the same DevKit. Having a realistic alternative would be very valuable to me.

Especially as I was hoping to create a game for my lass for christmas, and due to my retarded ISP not supported by Microsoft using XNA just isn't an option (until they put the creators club runtime on xbox.com to download).

ironically, if these two aspects were figured out it would be possible to alter the xdk recovery iso so that it would install to xbox 360 retail premium packs (or any xbox360 with a HDD)

si alguien entendido puede sacar algo en claro mejor jejej gracias y un saludo que quiero que no se duerma el hilo sino que se debata cosas.

"¿alguien me puede decir donde conseguir el xexdump?"GRACIAS

bueno os pongo nuevas cosas para los entendidos:

A small update:

During power on the 360 loads the base Kernel from the "CB" section (could this also contain the dreaded Hypervisor?) examines the 2 patch slots (specifically the header of the "CF" sections) and selects the most recent to apply to the base Kernel. The address of the patch slot is in the first 512 byte page, the second slot occurs 0x10000 bytes later, typically these are at:

0x6c000 and 0x7c000 for "CB" section (version 1888, length 0x61E0) or
0x70000 and 0x80000 for "CB" section (version 1903, length 0x9310, even though "CB" section header indicate version 1903 the dash reports BK as 1888)

So what's in the rest of the flash and how does the correct data get loaded?

Quote from GaryOPA:
"The 16mb NAND flash is not completely encrypted, it basically is a Microsoft compressed ROMDISK system.

It contains a small header, then a "encrypted" loader, and then a number of stored files in a "compact flash" file system, these files match byte for byte the updated files in the "system_update", and are basically the dashboard files in stored signed-XEX2 file format."

So how does the 360 find it's ROM file syatem?

Within my Flash dump I can see a total of four "root directories" at:

0xD9C000
0xD98000
0xABC000
0xA20000

During the boot process (shortly after the most upto date patch is selected and loaded) the 360 scans it's entire ROM from 0xFFC000 to 0x000000 in 0x4000 byte or NAND flash block sized chunks. When it finds something "interesting" in the first page of that block it reads the whole 0x4000 bytes in page sized chunks. In my 360 I see the following "interesting" blocks being read:

D9C000 Start of FS root? Contains xex, xexp2 & xttp2 files
AC0000 Start of Dashboard Settings? (hehe, the dashboard video resolution is visible in here)
A20000 Start of FS root? Contains xex, xexp1, xexp2, xttp1 & xttp2 files
91C000 Unknown

Note: Every time the dashboard settings are modified (I changed video settings) a new 3*512 block is appended to the end of the list starting at 0xAC0000, presumably the 360 scans this list and picks the last valid one. How the FS root is selected is currently unknown and FFS

When an update is applied the patch data is copied to the "CF" section and encrypted (applying the same patch twice results in different data, presumably the encrytion key changes each time, the associated "CG" section appears to remain the same). The xexp files found in the system update folder are copied to the ROM FS and renamed either xexp1 or xexp2. It seems that the xexp1/2 file extension is selected based on the patch slot. In my case slot 1 (0x6c000) was to be populated and xexp patch files are renamed xexp1 when copied to the ROM FS.

When a file, such as bootanim.xex is read from the ROM filesystem a check appears to be made and if a patch is being applied the corresponding xexp1/2 file is also read (there is speculation with a fair degree of certainty that these two files are then combined in RAM to give the correct version). The choice of xexp1 or 2 is fixed by the patch slot selected

fuente:xboxhacker

no se si seran cosas interesnates pòrque no entiendo ni jota pero si alguien nos lo resume se agradeceria.GRACIAS
Robinsod posted an update about his hack to downgrade a 2858 (or lower) kernel back to the 1888 'Base Kernel'. By being able to boot the 'Kiosk disc' from recordable media he proofs his 360 is no longer running the 2858 kernel (which blacklisted these XEXs) and boots without applying the kernel patches that have nulled headers:
Confirmed, downgrading allows the Kiosk disk to run again!

So I have now proved that kernel 2.0.2858 (won't boot the kiosk disk) can be downgraded to 2.0.1888 and that WILL boot the kiosk disk (or bits of it) from CD-R. This was proved with a mobo for which the DVD key is NOT known.


However, with newer kernels (4552 and after) it seems to be (currently) impossible to downgrade back to 1888. From Robinsod and Speedy22:
Until the 4552 update that is exactly what I was doing, erasing/corrupting part of the patch and rebooting. The 360 fell back to the previous patch or, if no patch has been applied, the Base Kernel.
After the 4552 the 360 WILL NOT BOOT unless the 4552 patch is present in flash.

More than likely MS has blown an efuse or two with the 4552 update. The efuses are located in the CPU. Anyone interested in learning more should download my 360 CPU datasheet V1.5 from the beginning of March 2005.

The Hypervisor only needs to test a flag in the processor (blown eFuse) against a flag in the patch to make a boot/no boot decision, there could be any number of these flags but at a rate of 1 eFuse / year then 32 would be more than ample. There's no need to actually modify the hypervisor code at all.

The efuses act like standard memory and probably contain the HID register data as well. I would guess there are 1K-2K worth of efuses.


Note: Right now there's no use (or easy way) for end-users to downgrade their kernel ... but it's very interesting research and might be useful in the future or for further research.


Fuente
Puf... Imagino que viniendo de flash78 sera una noticia importante, pero en inglis pitinglis ni papa :(
no dice nada nuevo, detalles sobre su progreso, pero nada q pueda ser util a corto plazo para la scene o el hackeo del kernel :( una pena
Dyson escribió:no dice nada nuevo, detalles sobre su progreso, pero nada q pueda ser util a corto plazo para la scene o el hackeo del kernel :( una pena


Gracias por la informacion :)

Pos nada, a seguir esperando...
Dyson escribió:no dice nada nuevo, detalles sobre su progreso, pero nada q pueda ser util a corto plazo para la scene o el hackeo del kernel :( una pena


Hombre, tampoco es eso :P. Dice que finalmente ha conseguido bajar el kernel y cargar el kiosk disc. Si hay algún agujero en el kernel desde luego lo primero que hay que hacer para explotarlo es poder usar ese kernel, así que es un gran avance. Es cierto que todavía no sirve para nada y que si se tiene instalado la última actualización de Microsoft no se puede downgradear, pero es un gran paso :).

Saludos.
Hombre lo que si es importante tambien es que se empieza a ver claramente la estrategia de microsoft y es de no abrir nada aunque la competencia si este abriendo puertas.
Ya que con esta ultima actualizacion "capan" el posible downgrade.

Me da a mi que microsoft esta vez esta haciendo MUY BIEN su trabajo y esto no va a ser NADA facil.

un saludo
-DAVIZINHO-
Mi inglés es horroroso

Los que actualizaron en octubre/noviembre (no recuerdo bien) pero no han actualizado ahora en enero ¿sí podrían hacer un posible downgrade o no me he enterado de nada?

GRACIAS
weno mi consola entoncs es downgradeable ya q no actualize las 2 ultimas veces.Al final como saquen un agujero por ahi, mi x360 va a ser como una PSP 1.5 al principio, una mina de oro.
Lo raro es que con lo gañanes que son los de mcrosöft programando hayan hecho con la 360 semejante trabajo...
Pero tiempo al tiempo. [360º]
MI SUEÑO ES JUGAR DESDE EL DISCO DURO
shrapnel escribió:MI SUEÑO ES JUGAR DESDE EL DISCO DURO

Gracias, procedemos a anotar tu petición...
Se puede volver a meter un kernel más nuevo una vez hecho el downgrade?
pues yo me la actualice en enero.. con toda la ilusion de entrar al live y tal y actualice.. xD pero weno, al principio solo era un sueño downgradear una PSP 2.71, y mira ahora... tiempo al tiempo..
Supongo q si quieres actualizar despues de corromper o borrar actualizaciones, se puede, aunq lo haria a traves de live a la ultima version.

El problema de PSP es q Sony no se pone las pilas para estas cosas y siempre hay algun agujero, como paso con XboX, lo malo es q con XTS parece q MS se ha puesto serio.

Con razon decian los hacker q esta maquina les hiba a dar muchas horas de diversion :-?
weno k se diviertan, mientras consigan cargar homebrew ñ_ñ
Jodeeeeeeeer.
Me acabode comprar la consola hoy y sale esto.....sera una señal..... [angelito] [angelito]

Gracias por la info flash78.

salu2.
A ver en que queda todo esto, yo mientras no haya nada seguro, seguire con mi Xbox virgen y mi Live cariñoso.

manugarrote escribió:Lo raro es que con lo gañanes que son los de mcrosöft programando hayan hecho con la 360 semejante trabajo...
Pero tiempo al tiempo. [360º]


Otra cosa no se... pero gañanes no son. Puedes tener tus mas y tus menos con Windows, pero te aseguro ke si estuviera programado por gañanes... por mucho marketing, mucho engaño y mucha ostia ke tuviera, no lo podria utilizar tanta gente.

Saludos!
Te equivocas. Que lo utilice mucha gente no implica que sea el mejor, en mi opinión por lo menos tiene demasiados fallos para que lo utilice...aunque claro, siempre hay algún rarito Unix/linuxero por aquí. Vamos que eso de que la masa vea OT, no quiere decir que OT sea bueno para todos.

Sobre deshacer las actualizaciones creo haber leído por algún lado que no va a ser posible para los que en algún momento hemos actualizado últimente, debido a algún check que se realiza desde la cpu con los últimos kernels y que evita esto...en fin, que m$ con el live hace más cosas que 'corregir bugs'
dreamer escribió:Te equivocas. Que lo utilice mucha gente no implica que sea el mejor, en mi opinión por lo menos tiene demasiados fallos para que lo utilice...aunque claro, siempre hay algún rarito Unix/linuxero por aquí. Vamos que eso de que la masa vea OT, no quiere decir que OT sea bueno para todos.

Sobre deshacer las actualizaciones creo haber leído por algún lado que no va a ser posible para los que en algún momento hemos actualizado últimente, debido a algún check que se realiza desde la cpu con los últimos kernels y que evita esto...en fin, que m$ con el live hace más cosas que 'corregir bugs'



Pues ke putada...
dreamer escribió:Te equivocas. Que lo utilice mucha gente no implica que sea el mejor, en mi opinión por lo menos tiene demasiados fallos para que lo utilice...aunque claro, siempre hay algún rarito Unix/linuxero por aquí. Vamos que eso de que la masa vea OT, no quiere decir que OT sea bueno para todos.


Tranki, ke ni te he llamado raro, ni he dixo ke porque lo utilice la gente Windows es mejor (ni mucho menos) solo digo ke porque una cosa tenga fallos no kiere decir ke haya sido programado por gañanes... cualquiera que se dedique a programar sabe las complicaciones que tiene un SO y que no es algo ke una panda de gañanes pueda hacer.

despues del Offtopic de la muerte, decir ke esto es solo un principio ke puede ke no llegue a nada, pero lo malo es ke haya que realizarlo flaseando a palo seco... en cualquier caso si finalmente llegan algo es posible ke veamos cosas interesantes!!

Saludos
47 respuestas