Si siguen tirando mas del sedal, pasará que cuando intenten controlarlos, será demasiado tarde y tendremos un problema muy grave.
Posiblemente la tercera guerra mundial, como dijo un compañero.

Es algo tosco, es lo que tiene usar una maquina virtual llamada Java, la cual abarca que las aplicaciones corran en móviles de 50€ para el mercado de gama baja hasta móviles que corren muy fluido de 300€ o mas de gama alta. Diversidad de un sistema operativo que se adapta a varios tipos de hardware con diversos precios para gente de todo tipo, no solo centrándose en gente que pueda pagar 600€ y dejando fuera a los demás .
Centrándonos en fluidez, esta muy bien que un launcher corra fluido, abramos un navegador y sea "tope" rapido para la vista, sea de Apple, Google... Pero si nos vamos a correr juegos algo pesados, o materia donde buscamos multitarea de verdad, donde 2GB de RAM en un dispositivo de verdad se nota, en uno de 1GB de RAM se nos cierra... Mismo me da mucha fluidez si el hardware a la hora de verdad no soporta dos aplicaciones fuertes en segundo plano.
Código abierto?, lo mejor que le puede pasar a cualquier software... Se llame Google, Apple o Microsoft la empresa que lo patrocine.
Si eres desarrollador, sabrás a que me refiero. Deberías de compilar un kernel para Android, adaptarle un driver de un adaptador wireless, y auditar una red con tu móvil... Seguro que si consigues eso, otras cosas se te quedarían pequeñas.
O mejor ejemplo aún, sigo teniendo en funcionamiento un Samsung Galaxy S Plus de hace seis años gracias al código abierto y el desarrollo no oficial.
Seguro que no puedes decir lo mismo de "otros dispositivos" de similar antigüedad, que seguramente no tengan soporte de nadie.
Y hablamos un poco de seguridad... Oistes el caso de las fotos de chicas famosas filtradas desnudas, por un error grave en cierto S.O que permitió a un listo obtenerlas fácilmente?.
Todos los sistemas tienen fallos, pero los S.O cerrados tardan mas en corregirse.

Bueno, alguno mas compartirá mi opinión. A la hora de la verdad lo que vende mas es lo que gana.

Cabe decir que tengo un UMI Hammer, teléfono chino con recambio (baratos, por si se nos parte por algo...) que ha valido 120€, con sus 2GB de RAM, y no lo cambiaría por una manzana, y si lo hiciese, seria para venderla y comprarme otro con "otro S.O".

Saludos!!

Bueno, te explico un poco comparando la manera matemática de como funcionan generalmente y luego como yo he llegado a entenderlo. Mi fuerte no son los algoritmos pero con los años y tras leer un poco, de lo poco que me ha llegado a interesar, he entendido la base creo. Y si estoy equivocado y alguien me corrige, será un conocimiento nuevo muy agradecido .

Todo algoritmo de compresión puede tener pérdidas... En algunos las pérdidas es la clave de la compresión, cuanto menos material, al ser posible el mas irrelevante, menos espacio ocupan... Es lo que sucede con el MP3, JPEG en imagen y demás... Que se basan en eliminar calidad ganando mas memoria. Esto da lugar a archivos apenas corruptos, puesto que en el proceso de compresión ves lo que se pierde y si te beneficia esa pérdida o no.

En cambio con los algoritmos de compresión sin pérdida es diferente. La condición de si se producirá una pérdida depende principalmente del contenido que vayas a comprimir (mas complejo como volúmenes virtuales, binarios... ) a simples textos... Y del ratio que quieras comprimirlo.

Explicándome mejor... Imaginemos que queremos comprimir un volumen cifrado de Truecrypt, y luego aparte un archivo de texto.
Hagamos el ejemplo de que lo abrimos con un editor en hexadecimal y el contenido es algo así:

"7y-#+€-72+%&38*+......"

El algoritmo de cifrado, al intentar comprimir esto, tendrá una tolerancia limitada a operaciones simples, por ejemplo si tenemos en una cadena siete sietes, o caracteres repetidos, se limitará ha hacer una operación que al descomprimirlo, el algoritmo pueda generar la misma cadena sin problemas.
En este punto, si aumentamos el ratio de compresión, se aplicarán operaciones mas complejas, operaciones que el algoritmo quizás no tolere dada la complejidad de lo que vas a comprimir y lo estipulado en el algoritmo... Arriesgando a que al comprimirlo, genere alguna cadena defectuosa corrompiendolo.

Un ejemplo es probando a comprimir al máximo con 7zip algo complejo... Lo que consigues en un archivo de 4GB es sacar solamente 200M de memoria menos, y si aumentas el diccionario del algoritmo, puede que logres 400M, pero al ser un archivo de composición compleja, lo mas probable es que quede corrupto al descomprimirlo.

En cambio, por contra, si comprimimos un archivo de texto (algo morfológicamente mas simple), y en el cual se produzcan muchas repeticiones de palabras, y demás... Aunque comprimamos con un ratio muy alto, tenemos menor probabilidad de que quede corrupto, puesto que el contenido a comprimir es mas simple y dispone de muchas repeticiones, funcionando el algoritmo mucho mejor.

Si comprimes un archivo de 4GB de texto, el resultado sera un archivo de aproximadamente 1GB o menos incluso, y con pocas probabilidades de corrupción.

El ejemplo que has dicho tu con una variable "double" es lo mas acertado a mi explicación.
Un pequeño fallo en una operación por exponer un valor no estipulado en el algoritmo, o que suceda un desbordamiento de alguna variable omitiendo algún dato, es suficiente para corromperlo.
Y ahí entra en juego mayormente la complejidad del archivo a comprimir, y el forzar un ratio mayor al que mas o menos por lógica, la morfología del archivo y el algoritmo toleren...

Por eso siempre viene la opción en los compresores, la mas básica como predeterminada... Las demás las dejan a elección porque dependiendo del archivo no te pueden asegurar mayormente lo que sucederá.

Mi deducción es si vas a usar un ratio alto, y es algo medianamente importante, cuando se comprima, descomprimelo y comprueba que tal funciona el resultado...

No se si me he explicado bien, si me he equivocado y alguien me corrige perfecto, pero con lo que he leído con el tiempo y demás es la deducción lógica que he encontrado, y por pruebas propias.

Espero te sirva. Cualquier cosa comenta.

Un saludo

Hombre, yo veo multitud de código tanto del kernel como de ROMs de Android por varios repositorios y de innumerables dispositivos. Pero ninguno de Apple.

Mas cerrado o menos, yo lo veo como siempre ha sido. Android (abierto) , Apple (cerrado y restrictivo).

Si puedes especificar que es lo que es cada vez más cerrado de Android, será algo para debatir, y me parece interesante para conocer tu opinión.

Un saludo.

Lo de suplantar el certificado... Es mejor que lo dejes. Usa creo que SHA256, y bueno, es impensable...
Puedes buscar algún cliente modificado reciente y aprovechar si alguien ya lo ha tocado y puedes meterle la librería... Si no, poco puedes hacer.

Desde hace unos años el cliente de Valve esta bastante trabajado... Para frenar la piratería masiva de sus juegos.

Un saludo

Es un tipo de tabla de particiones. Una buena manera de solucionarlo es bajarte "gparted" y creas una nueva tabla de particiones de opción "ms-dos". Y ya ahí  desde el disco de Windows debería de dejarte formatearlo, o directamente creas una partición NTFS desde gparted y vas al cd de Windows e instalas.
Si no quieres hacerlo desde gparted, casi cualquier programa que te haga redimensionar o crear particiones ("que no sea el predeterminado de windows") te permitirá crear una tabla de particiones con otro formato.

Espero que te sirva.

Un saludo!

Depende del lenguaje que estés programando y las limitaciones del programa. Editar la DLL original si es en un lenguaje como C o C++, tendrías que usar un debbuger como Olly y por supuesto saber lo que tocas.
Si es en .Net, la decompilas, extraes sus funciones y modificas una a la que el .exe siempre llame, a poder ser sin editar nada de la original para no corromper las funciones normales del programa, y en esa función llamas a otra en la que hayas programado tu programa... (Esa misma lógica es la que seguirias con Olly en C y C++, pero es mucho mas complicado).

En el caso que el programa tuviese algún reconocimiento de sus DLL o archivos por firma digital, deberías modificar la parte del programa que lo hace.

Lo mas adecuado para lo que quieres hacer, creo que es la inyección de código (algo muy común en los chetos de juegos, si te suena mas).
Creas una librería modificada con tu código y con una función similar a la de la original... La cargas en memoria del programa y al llamar a esa función entra tu código en vez de la original (resumen rápido), pero para eso deberías especializarte un poco en inyección de código en el lenguaje que programes.

Un saludo.

Como dominen los pozos de petroleo, preparense que la vida en Europa va a ser muy cara. Y si consiguen una bomba nuclear... 

Lo que hay que hacer es cargarse los ahora que estamos a tiempo, o esos pseudo terroristas nos darán por...

Si conoces las modificaciones técnicas o diferencias entre uno y otro, puedes ir a las funciones que realizan esas acciones en el código modificado y contemplar las diferencias ejecutando el ejecutable original y el modificado con el depurador el código, e ir eliminando las funciones "extras" o dejándolas lo más parecidas a las originales...
Si eres nuevo programando, y no sabes como funciona, lo mejor es que vayas leyendo código de la versión modificada poco a poco e interpretando que hace, y luego de la versión original, interpretar ls diferencia y "googlear" poco a poco para interpretarlo correctamente.. Aprenderás mucho y acabarás encontrando las diferencias del original.

Por ejemplo; "sustituir botón click por radiobutton" (ejemplo cutre, pero vale...)
Y a partir de ahí vas modificando.

Si no es un lenguaje .NET, no podrás decompilar el código tal y como fue escrito y por lo tanto no podrás hacer lo que pides de la manera que quieres.
Lo más parecido a lo que pides seria usar ingeniería inversa del ejecutable, y si sabes hacerla no creo que preguntases.

Por cierto, si quieres mas opiniones, el termino de fusionar dos ejecutables esta mal... Deberías de cambiarlo por "Encontrar diferencias entre ejecutable compilado y código fuente modificado"...

Fusionar dos ejecutables es lo que hacen los lammers para saltarse el AV, y la gente no suele ni leer el tema... Aparte de no ser el término correcto de lo que quieres hacer.

Un saludo!  

Si te refieres a que la compresión quede corrupta, y que al descomprimirla futuramente el resultado sea un archivo dañado o diferente, es posible.

Siendo un simple .zip, con bajo ratio de compresión, (tipica compresion predeterminada) es muy poco probable... Pero según se aumenta el ratio o grado de compresión en un archivo comprimido, será mas propenso a errores por perdida de datos en el mismo.

Por ejemplo, hace tiempo se publicaban en la red juegos ultra comprimidos en archivos de pocos megas cuando en realidad ocupaban cientos.
3/4 de esos juegos al descargarlos y descomprimirlos, aparte de tardar siglos en descomprimirse, quedaban corruptos e injugables, por utilizar un ratio de compresión altos donde se han perdido datos del archivo original.

Espero haber sido técnico con la respuesta.

Un saludo