Pagar a otros por no hacer bien su trabajo de inicio. No está mal, Samsung, no está mal. Supongo que el dinero que repartáis se lo quitaréis justamente a vuestros ingenieros informáticos
#8 Colaboro con 1 proyecto open source que "apenas" pasa del millon de lineas y la cantidad de bugs y crashes raros que salen cuando se lleva a cierta cantidad de jugadores es increible, y eso que buscamos fallos de programacion con herramientas de analisis de codigo.
#10 Fallos de programación como te digo. Forman parte de la gran diversidad de variables a tener en cuenta al realizar un programa.
Pero vamos, siendo Samsung, con el batallón de expertos ingenieros de prestigio que debe tener, y que cada uno se dedica a una parte de la programación, tiene delito que pase esto.
Como los videojuegos: antes no había bugs ni actualizaciones, porque se hacían BIEN. ¿Ahora? Ni uno se salva de la quema porque priman las prisas y el lanzamiento.
#11 la ultima linea, que la gente no los encontrase no quiere decir que no existiesen, llevo usando ordenadores desde hace 3 decadas y las actualizaciones por bugs han existido por muchisimo tiempo.
#11 Antes los videojeugos eran super simples, cabían en disketes. Por no hablar de que todos eran copias de todos hasta que John Carmack decidía volvernos a maravillar con mejoras en el motor. Antes un motor lo hacía una sola persona, ahora los motores los deben desarrollar equipos grandes debido a su complejidad y diversidad de tareas que antes no contemplaban. Esto es como decir que no entiendes como puede fallar el hardware de un ordenador cuando con una calculadora solo se te gasta la pila. Una comparación sin sentido.
#16 ¿He dicho eso? Parece que no has desarrollado software grande. Se desarrolla por piezas, y esas piezas se prueba de manera unitaria. Tu puedes haber programador de puta madre que si hay un fallo de diseño o de especificación por bien que lo hayas hecho en las pruebas de integración (cuanto interactua con el resto de piezas) fallará. Por no hablar que te limitas a un tipo de error (mala codificación). ¿Que pasa cuando no ha sido contemplado un caso? Eso no es que esté mal programado, es que no está hecho. No hay un manual de "previsión" que te haga verlo todo y toda posibilidad entre los centenares de parametros de configuración y otras mil cosas. De ahí que se use tanto software para diferentes tareas como:
- Desarrollo de prubas unitarias
- Software de integración cotinua (que efectuara acciones o alertas en función de los resultados devueltos tras el lanzmientod e las pruebas realizadas previas al despliegue.
- Software de calidad de código
- Realización de pruebas integradas por testers
- Realización de pruebas de estres
Vamos, lo que se llaman pruebas de regresión. Y aun así se escapan cosas. Todo ser humano es falible. Hablas como si tu lo hicieses todo perfecto.
#17 Te equivocas. Hablo en nombre de una multinacional dirigida a millones de personas como es Samsung. Ni más ni menos. Y lo mismo digo de Apple y de quien sea. Antes de sacar nada, depura sus fallos, testéalo, no saques nada que después te va a costar trabajo volver a reprogramar.
#18 Pero vamos a ver, que muchas veces dependes de piezas de terceros. Ellos han probado y depurado, pero hay cosas que no se detectan. Que hablamos de millones y millones de lineas de codigo interactuando entre ellas. ¿en que mundo vives tío? Tu sigue pidiendo peras al olmo, que comerás hojas.
#20 Comeré lo que me dé la gana. Pero no me negarás que no se testea, melón. Si lo testearan como deben antes de sacarlo a la luz se ahorrarían mucha pasta y quebraderos de cabeza. A ver en qué mundo vives tú.
#21 Yo no sé lo que hacen los demás en sus proyectos. Solo puedo hablar de los proyectos por los que he pasado yo. Y generalizar por el mal hacer de algunos es un error.
#24 Creo que el problema de base es primar los tiempos sobre la calidad. Al menos aquí en España. De ahí viene todo. Malas planificaciones que te hacen no tener el tiempo suficiente y por lo tanto programas con prisas. Por falta de tiempo las pruebas no se hacen con una cobertura del 100% del codigo (muchas veces no lo exige el cliente). Por falta de tiempo no se documenta o no se hace como es debido, haciendo que toda información tecnica y funcional se distribuya como hacían los druidas, lo que implica mas errores y mas retrasos. Y eso por no hablar de toda la capa que en España gusta llamar "jefatura intermedia" que no son mas que parasitos amigotes de los gerentes que lo unico que hacen es mover correos entre grupos funcionales, haciendo la comunicación menos fluída. Vamos, personas perfectamente sustituibles por un software programado en una tarde. Haciendo que el dinero destinado a nominas en lugar de caer donde esta toda la carga productiva, caiga en los putos inutiles que no valen para nada. De currantes descontentos y mal pagados no se puede esperar gran cosa. Como se dice en esta profesión, si pagas con cacahuetes...
No pasa nada por documentar mal, no pasa nada por hacer codigo guarro porque necesitan un hotfix de un puto informe de mierda ya, no pasa nada por hacer pruebas guarras. Eso sí, que no se te olvide actualizar la fecha de entrega por una que este dentro de tiempo. Eso es lo importante.
#25 Pues mira, te doy la razón al 100% y por fin tú solo has dado con la solución al problema: el tiempo, mala planificación, programar con prisas más que con eficacia... es decir, que tú mismo reconoces que no se programa bien, o que los programas tienen fallas y fallos porque se juega con el usuario.
Yo puedo decir al 100% que hay sites con una excelente programación y seguridad, porque se les ha dedicado tiempo y trabajo. No hay más. Y Samsung debería estar adelantándose a eso programando los dispositivos de aquí a lo que serán en 3-4 años. Tiempo suficiente para que luego no ofrezcan "recompensas" por el trabajo mal realizado por esa falta de tiempo-planificación.
#26 Que se programe mal no significa que no se sepa programar. Muchas veces te ves obligado a hacerlo mal porque el bloque de codigo con el que interactua tu parte esta mal diseñado o lo que sea y pertenece a otra persona, otro grupo, incluso otra empresa. Y podria pasar facil una semana o dos desde que creas la incidencia hasta que alguien la resuelve. Otras veces programas lo que te dicen, porque tienes un analista que te da la solucion en pseudocodigo o algo similar. Y te limitas a picar lo que dice. Si eso esta mal es cosa del analista, no del programador.
#27 Nadie dice lo contrario. Solo que no se testea bien antes de sacar el producto, pero nadie dice que no se sepa programar, solo que se programa mal y que no se verifican bien las cosas antes de sacarlas.
#28 Si, pero quitando las pruebas unitarias, el resto de pruebas no suelen depender del programador, o no deberían. Para eso estan los testers. Pero claro, como en todo los hay buenos y los hay malos (si es que los hay). Y siempre dependiendo de las exigencias de la empresa. En un mismo proyecto los he visto de dos tipos. Por una parte una empresa que solo estaba en el proyecto para eso. Los testers (en su gran mayoría) muy preparados, con conocimiento de la logica funcional, de las pantallas, etc. Luego estaban los de la empresa en la que estaba yo, que ponía a cualquier inutil que tuviese por las oficinas sin nada que hacer. El resultado era que con los primeros si tenías que explicarles algo era un desarrollo nuevo y eran capaces hasta de detectar errores de sinergias entre procesos rebuscadas. Y por otro lado tenías a los de mi empresa, que si antes el servicio devolvía null, y ahora devuelve null : null es que está bien porque ya no devuelve null. A eso sumale las presentaciones a cliente que son un chiste. Porque como se dio una fecha muy apretada, evidentemente hay cosas que o no estan o no estan como deberían. Por lo que se trampean las pruebas y los datos para que con unas pruebas concretas se consiga el OK. Y como a la presentación no ha venido un usuario si no un jefecillo que ademas viene con prisas. Pues no se sale de la estrategia marcada por las empresas que hacen la presentación. Teniendo como resultado que se aprueben aplicaciones erroneas o incompletas.
#29 Totalmente de acuerdo con todo el razonamiento expuesto, pero eso no quita para que ANTES de sacar un producto se testee bien, a fondo, porque todo lo que encuentran los usuarios lo pueden encontrar los testers. Si fallas en los testers de nada te sirven, con lo cual para el siguiente lanzamiento se debe prescindir de ellos.
Y hablamos de una de las tecnológicas más importantes del mundo. ¡Qué menos que exigirles eso!
#30 Hombre, yo te he puesto un ejemplo de una aplicación de gestión, que pese a estar compuesta por miles de archivos de código es infinitamente mas simple que un sistema. De verdad, nos os haceis a la idea de lo complicado que es detectar determinados errores. Es imposible sacar un software perfecto, y no porque no se intente.
Un ejemplo es Linus, que es muy estricto con la calidad del código que se escribe en el kernel de linux. Y aun así, hay errores.
#31 Vuelta a lo mismo. Que sí, que hay errores, pero lo que no debe una empresa es ofrecer dinero a hackers por encontrar fallas de seguridad, cuanto menos del SO en sí. Porque me están diciendo indirectamente que ni ellos se fían del trabajo realizado.
Es mi punto de vista, sé que el programador siempre va a confiar en su criterio y en su trabajo, pero leñe, que hablamos de Samsung.
#32 Y hacen bien en no fiarse. Uno de los principales fallos de seguridad es la confianza. Yo no veo que tiene de malo en que haya una doble revisión por gente super especializada en la materia.
#33 Pues a mí lo que me indica que todo lo escrito durante cientos de horas es menos fiable que una bomba en manos de un yihadista. Lo siento, pero es así.
#36 Esperar que salga un sistema perfecto es como esperar que a una casa no le salga una pequeña grieta en 100 años.
En los sistemas lo importante es la velocidad de actualización, porque como ya te he dicho varias veces, es imposible librarte de fallos. Y la verdad, lo ultimo que me preocupa son los errores que puedan detectarse en los sistemas nuevos, porque se que los parchearan. El problema de Samsung y otras miles, no es que salga el software con errores, es que despues de un ciclo corto de años, hay dispositivos que da como obsoletos y no los vuelve a actualizar. ¿de que me sirve a mi que detecte errores de seguridad si no los va a parchear para mi dispositivo?
#37 "se premiarán los bugs de nivel crítico en la seguridad del dispositivo, y no cualquier tipo de bug, además de que tendrán que realizarse remotamente, es decir usando aplicaciones o servicios de Samsung Mobile, sin conexión física alguna".
Vamos, que más restringido imposible, como para hacerlo mal solo en eso. ¿Es que no ves a lo que me refiero?
#38 Estan restringiendo a lo que puede ser problematico para los usuarios. Un exploit local no lo pueden ejecutar en tu maquina magicamente. Los problemas son los exploits que puedan usarse remotamente. Respecto a lo de las aplicaciones Samsung Mobile, ¿pretendes que te pague Samsung porque encuentres un fallo en la app de facebook que te permita hacer x en el terminal? Eso lo tiene que corregir facebook, ya que si puedes hacer algo en el terminal, no es porque Samsung lo permita, es por un error de Facebook y porque tu como usuario le has dado determinados permisos a esa aplicación. Y aunque parece algo lógico que no haya que explicar hay que hacerlo, para evitar reclamaciones de "listillos". Que en EEUU gastan mucho de esos por ejemplo.
#39 Ahí estamos, y te doy toda la razón. Eso es lo que quieren, pero chico, para eso tienes tu batallón de programadores que deben cerrar esas puertas. ¿Que por una app "x" resulta que me entra un hacker? Leñe, para eso tiene que estar pendiente la 1ª app de tener cerrado todo para que no influya en todo lo demás.
Si al final todo es lo mismo, que por unos sufren otros, pues si se hiciera bien desde el inicio en una no pasaría en la otra. La pescadilla que se muerde la cola.
PD: hay verdaderos expertos en cerrar agujeros de seguridad de una app en lo que a dispositivos externos o remotos se refiere. Pero claro, parece que les gusta hacer todo mal.
#40 "para eso tiene que estar pendiente la 1ª app" --> Osea, quieres que Samsung desconecte el dispositivo por completo no vaya a ser que por culpa de otras empresas te ataquen. No hay otra manera de lograr lo que pides, aislandolo. ¿y para que quieres un smartphone que no puede comunicarse? Creo que el kilo de arcilla está más barato.
Comentarios
Hackers obsoletos.
¿Las fallas no son las que provocan terremotos? ¿O los muñecos que se queman en Valencia?
#19 Muy bien, sigo alegrándome. ¿Dónde quieres llegar, si no es problema preguntar eso?
Pagar a otros por no hacer bien su trabajo de inicio. No está mal, Samsung, no está mal. Supongo que el dinero que repartáis se lo quitaréis justamente a vuestros ingenieros informáticos
#6 cuando un proyecto crece demasiado es imposible tenerlo todo controlado al 100%
#7 Lo cual no implica que se programe decentemente y no se ofrezca dinero por buscar donde no debería haber fallos de programación.
#8 Colaboro con 1 proyecto open source que "apenas" pasa del millon de lineas y la cantidad de bugs y crashes raros que salen cuando se lleva a cierta cantidad de jugadores es increible, y eso que buscamos fallos de programacion con herramientas de analisis de codigo.
#10 Fallos de programación como te digo. Forman parte de la gran diversidad de variables a tener en cuenta al realizar un programa.
Pero vamos, siendo Samsung, con el batallón de expertos ingenieros de prestigio que debe tener, y que cada uno se dedica a una parte de la programación, tiene delito que pase esto.
Como los videojuegos: antes no había bugs ni actualizaciones, porque se hacían BIEN. ¿Ahora? Ni uno se salva de la quema porque priman las prisas y el lanzamiento.
#11 la ultima linea, que la gente no los encontrase no quiere decir que no existiesen, llevo usando ordenadores desde hace 3 decadas y las actualizaciones por bugs han existido por muchisimo tiempo.
#12 Bien, me alegro por ti
#15 https://www.ionlitio.com/secretos-y-bugs-de-super-mario-bros/ toma, bugs de un juego de 1985.
#11 Antes los videojeugos eran super simples, cabían en disketes. Por no hablar de que todos eran copias de todos hasta que John Carmack decidía volvernos a maravillar con mejoras en el motor. Antes un motor lo hacía una sola persona, ahora los motores los deben desarrollar equipos grandes debido a su complejidad y diversidad de tareas que antes no contemplaban. Esto es como decir que no entiendes como puede fallar el hardware de un ordenador cuando con una calculadora solo se te gasta la pila. Una comparación sin sentido.
#14 ¿Justificas acaso que un buen equipo no sepa programar correctamente?
#16 ¿He dicho eso? Parece que no has desarrollado software grande. Se desarrolla por piezas, y esas piezas se prueba de manera unitaria. Tu puedes haber programador de puta madre que si hay un fallo de diseño o de especificación por bien que lo hayas hecho en las pruebas de integración (cuanto interactua con el resto de piezas) fallará. Por no hablar que te limitas a un tipo de error (mala codificación). ¿Que pasa cuando no ha sido contemplado un caso? Eso no es que esté mal programado, es que no está hecho. No hay un manual de "previsión" que te haga verlo todo y toda posibilidad entre los centenares de parametros de configuración y otras mil cosas. De ahí que se use tanto software para diferentes tareas como:
- Desarrollo de prubas unitarias
- Software de integración cotinua (que efectuara acciones o alertas en función de los resultados devueltos tras el lanzmientod e las pruebas realizadas previas al despliegue.
- Software de calidad de código
- Realización de pruebas integradas por testers
- Realización de pruebas de estres
Vamos, lo que se llaman pruebas de regresión. Y aun así se escapan cosas. Todo ser humano es falible. Hablas como si tu lo hicieses todo perfecto.
#17 Te equivocas. Hablo en nombre de una multinacional dirigida a millones de personas como es Samsung. Ni más ni menos. Y lo mismo digo de Apple y de quien sea. Antes de sacar nada, depura sus fallos, testéalo, no saques nada que después te va a costar trabajo volver a reprogramar.
No había acritud alguna.
#18 Pero vamos a ver, que muchas veces dependes de piezas de terceros. Ellos han probado y depurado, pero hay cosas que no se detectan. Que hablamos de millones y millones de lineas de codigo interactuando entre ellas. ¿en que mundo vives tío? Tu sigue pidiendo peras al olmo, que comerás hojas.
#20 Comeré lo que me dé la gana. Pero no me negarás que no se testea, melón. Si lo testearan como deben antes de sacarlo a la luz se ahorrarían mucha pasta y quebraderos de cabeza. A ver en qué mundo vives tú.
#21 Yo no sé lo que hacen los demás en sus proyectos. Solo puedo hablar de los proyectos por los que he pasado yo. Y generalizar por el mal hacer de algunos es un error.
#23 Mira, pues en eso, aunque no lo parezca, estoy de acuerdo. Generalizo porque es la norma en las grandes empresas, no por otra cosa.
Y me joroba porque pago por un producto físico y un software depurado.
#24 Creo que el problema de base es primar los tiempos sobre la calidad. Al menos aquí en España. De ahí viene todo. Malas planificaciones que te hacen no tener el tiempo suficiente y por lo tanto programas con prisas. Por falta de tiempo las pruebas no se hacen con una cobertura del 100% del codigo (muchas veces no lo exige el cliente). Por falta de tiempo no se documenta o no se hace como es debido, haciendo que toda información tecnica y funcional se distribuya como hacían los druidas, lo que implica mas errores y mas retrasos. Y eso por no hablar de toda la capa que en España gusta llamar "jefatura intermedia" que no son mas que parasitos amigotes de los gerentes que lo unico que hacen es mover correos entre grupos funcionales, haciendo la comunicación menos fluída. Vamos, personas perfectamente sustituibles por un software programado en una tarde. Haciendo que el dinero destinado a nominas en lugar de caer donde esta toda la carga productiva, caiga en los putos inutiles que no valen para nada. De currantes descontentos y mal pagados no se puede esperar gran cosa. Como se dice en esta profesión, si pagas con cacahuetes...
No pasa nada por documentar mal, no pasa nada por hacer codigo guarro porque necesitan un hotfix de un puto informe de mierda ya, no pasa nada por hacer pruebas guarras. Eso sí, que no se te olvide actualizar la fecha de entrega por una que este dentro de tiempo. Eso es lo importante.
#25 Pues mira, te doy la razón al 100% y por fin tú solo has dado con la solución al problema: el tiempo, mala planificación, programar con prisas más que con eficacia... es decir, que tú mismo reconoces que no se programa bien, o que los programas tienen fallas y fallos porque se juega con el usuario.
Yo puedo decir al 100% que hay sites con una excelente programación y seguridad, porque se les ha dedicado tiempo y trabajo. No hay más. Y Samsung debería estar adelantándose a eso programando los dispositivos de aquí a lo que serán en 3-4 años. Tiempo suficiente para que luego no ofrezcan "recompensas" por el trabajo mal realizado por esa falta de tiempo-planificación.
#26 Que se programe mal no significa que no se sepa programar. Muchas veces te ves obligado a hacerlo mal porque el bloque de codigo con el que interactua tu parte esta mal diseñado o lo que sea y pertenece a otra persona, otro grupo, incluso otra empresa. Y podria pasar facil una semana o dos desde que creas la incidencia hasta que alguien la resuelve. Otras veces programas lo que te dicen, porque tienes un analista que te da la solucion en pseudocodigo o algo similar. Y te limitas a picar lo que dice. Si eso esta mal es cosa del analista, no del programador.
#27 Nadie dice lo contrario. Solo que no se testea bien antes de sacar el producto, pero nadie dice que no se sepa programar, solo que se programa mal y que no se verifican bien las cosas antes de sacarlas.
#28 Si, pero quitando las pruebas unitarias, el resto de pruebas no suelen depender del programador, o no deberían. Para eso estan los testers. Pero claro, como en todo los hay buenos y los hay malos (si es que los hay). Y siempre dependiendo de las exigencias de la empresa. En un mismo proyecto los he visto de dos tipos. Por una parte una empresa que solo estaba en el proyecto para eso. Los testers (en su gran mayoría) muy preparados, con conocimiento de la logica funcional, de las pantallas, etc. Luego estaban los de la empresa en la que estaba yo, que ponía a cualquier inutil que tuviese por las oficinas sin nada que hacer. El resultado era que con los primeros si tenías que explicarles algo era un desarrollo nuevo y eran capaces hasta de detectar errores de sinergias entre procesos rebuscadas. Y por otro lado tenías a los de mi empresa, que si antes el servicio devolvía null, y ahora devuelve null : null es que está bien porque ya no devuelve null. A eso sumale las presentaciones a cliente que son un chiste. Porque como se dio una fecha muy apretada, evidentemente hay cosas que o no estan o no estan como deberían. Por lo que se trampean las pruebas y los datos para que con unas pruebas concretas se consiga el OK. Y como a la presentación no ha venido un usuario si no un jefecillo que ademas viene con prisas. Pues no se sale de la estrategia marcada por las empresas que hacen la presentación. Teniendo como resultado que se aprueben aplicaciones erroneas o incompletas.
#29 Totalmente de acuerdo con todo el razonamiento expuesto, pero eso no quita para que ANTES de sacar un producto se testee bien, a fondo, porque todo lo que encuentran los usuarios lo pueden encontrar los testers. Si fallas en los testers de nada te sirven, con lo cual para el siguiente lanzamiento se debe prescindir de ellos.
Y hablamos de una de las tecnológicas más importantes del mundo. ¡Qué menos que exigirles eso!
#30 Hombre, yo te he puesto un ejemplo de una aplicación de gestión, que pese a estar compuesta por miles de archivos de código es infinitamente mas simple que un sistema. De verdad, nos os haceis a la idea de lo complicado que es detectar determinados errores. Es imposible sacar un software perfecto, y no porque no se intente.
Un ejemplo es Linus, que es muy estricto con la calidad del código que se escribe en el kernel de linux. Y aun así, hay errores.
#31 Vuelta a lo mismo. Que sí, que hay errores, pero lo que no debe una empresa es ofrecer dinero a hackers por encontrar fallas de seguridad, cuanto menos del SO en sí. Porque me están diciendo indirectamente que ni ellos se fían del trabajo realizado.
Es mi punto de vista, sé que el programador siempre va a confiar en su criterio y en su trabajo, pero leñe, que hablamos de Samsung.
#32 Y hacen bien en no fiarse. Uno de los principales fallos de seguridad es la confianza. Yo no veo que tiene de malo en que haya una doble revisión por gente super especializada en la materia.
#33 Pues a mí lo que me indica que todo lo escrito durante cientos de horas es menos fiable que una bomba en manos de un yihadista. Lo siento, pero es así.
#34 ¿Cientos de horas? ¿Crees que un sistema actual se hace en cientos de horas?
#35 Ponle cientos de cientos de horas, miles de horas, miles de días... qué más da, lo que se haga, que se haga bien, leñe.
#36 Esperar que salga un sistema perfecto es como esperar que a una casa no le salga una pequeña grieta en 100 años.
En los sistemas lo importante es la velocidad de actualización, porque como ya te he dicho varias veces, es imposible librarte de fallos. Y la verdad, lo ultimo que me preocupa son los errores que puedan detectarse en los sistemas nuevos, porque se que los parchearan. El problema de Samsung y otras miles, no es que salga el software con errores, es que despues de un ciclo corto de años, hay dispositivos que da como obsoletos y no los vuelve a actualizar. ¿de que me sirve a mi que detecte errores de seguridad si no los va a parchear para mi dispositivo?
#37 "se premiarán los bugs de nivel crítico en la seguridad del dispositivo, y no cualquier tipo de bug, además de que tendrán que realizarse remotamente, es decir usando aplicaciones o servicios de Samsung Mobile, sin conexión física alguna".
Vamos, que más restringido imposible, como para hacerlo mal solo en eso. ¿Es que no ves a lo que me refiero?
#38 Estan restringiendo a lo que puede ser problematico para los usuarios. Un exploit local no lo pueden ejecutar en tu maquina magicamente. Los problemas son los exploits que puedan usarse remotamente. Respecto a lo de las aplicaciones Samsung Mobile, ¿pretendes que te pague Samsung porque encuentres un fallo en la app de facebook que te permita hacer x en el terminal? Eso lo tiene que corregir facebook, ya que si puedes hacer algo en el terminal, no es porque Samsung lo permita, es por un error de Facebook y porque tu como usuario le has dado determinados permisos a esa aplicación. Y aunque parece algo lógico que no haya que explicar hay que hacerlo, para evitar reclamaciones de "listillos". Que en EEUU gastan mucho de esos por ejemplo.
#39 Ahí estamos, y te doy toda la razón. Eso es lo que quieren, pero chico, para eso tienes tu batallón de programadores que deben cerrar esas puertas. ¿Que por una app "x" resulta que me entra un hacker? Leñe, para eso tiene que estar pendiente la 1ª app de tener cerrado todo para que no influya en todo lo demás.
Si al final todo es lo mismo, que por unos sufren otros, pues si se hiciera bien desde el inicio en una no pasaría en la otra. La pescadilla que se muerde la cola.
PD: hay verdaderos expertos en cerrar agujeros de seguridad de una app en lo que a dispositivos externos o remotos se refiere. Pero claro, parece que les gusta hacer todo mal.
#40 "para eso tiene que estar pendiente la 1ª app" --> Osea, quieres que Samsung desconecte el dispositivo por completo no vaya a ser que por culpa de otras empresas te ataquen. No hay otra manera de lograr lo que pides, aislandolo. ¿y para que quieres un smartphone que no puede comunicarse? Creo que el kilo de arcilla está más barato.
Buf! Pues se van a arruinar...
Para que si luego no son capaces de parchearlos
se van a forrar los bomberos
Que los contraten y así no trabajan gratis
#4 recompensa? Hay que ver como se ahorran el dinero