¿Es normal que un revisor pida un archivo ejecutable para verificar mis resultados?

Acabo de recibir una carta de decisión para mi manuscrito enviado a una revista de Elsevier. Fue una revisión y reenvío. Sin embargo, uno de los revisores solicitó un archivo ejecutable para verificar mis resultados. (Sentí desconfianza por su comentario..)

Se trata de un artículo de informática sobre la prueba de la eficiencia de un algoritmo en un conjunto de instancias de la literatura. Comparé los resultados del algoritmo con los de otros autores.

Para aclarar: el documento habla de algún software, ¿y el revisor quiere poder ejecutar el software? No sé qué tan común es eso (no soy un científico informático), pero siempre que cualquier licencia del software le permita dárselo al revisor, parece una solicitud razonable.
Bueno, si publica un algoritmo, necesita publicar de alguna manera el código real. ¿Parece que su manuscrito no lo incluye en absoluto?
Si el algoritmo se va a publicar de todos modos, ¡no veo "por qué no"!
@DSVA: "Si publica un algoritmo, necesita publicar de alguna manera el código real"... ¿qué porcentaje de algoritmos publicados cree que vienen con el código fuente?
@Mehrdad "¿qué porcentaje de algoritmos publicados cree que vienen con el código fuente?" mucho menos que el porcentaje que debería venir con el código fuente. En mi humilde opinión, si no puede verificar el reclamo sin implementar el algoritmo, entonces debería tener el código fuente adjunto, y el código fuente debería ser revisable, o de lo contrario no es una buena ciencia. Ningún revisor en su sano juicio aceptaría un documento con "la magia sucede aquí" en medio de la prueba, por lo que tampoco debería permitirse el "software de código cerrado".
Un revisor desconfiado es algo bueno, significa que le darán una dura prueba a su trabajo, y si hay problemas con el trabajo, es más probable que los encuentren, lo que es un beneficio a largo plazo. Dudo mucho que desconfíen de tu honestidad, solo el resultado.
Como alguien con poca o ninguna experiencia en la publicación de software (o algoritmos), ¿no les proporcionaría un ejecutable compilado solo para ejecutar su código, no para verlo?
@Sumyrda "En mi humilde opinión, si no puede verificar el reclamo sin implementar el algoritmo, ..., no es buena ciencia" Desafortunadamente, las cosas a menudo no son tan simples para los algoritmos. Se puede demostrar que muchos algoritmos son correctos, pero aún así no son triviales de implementar. Esta es la razón por la cual la ingeniería de algoritmos es un campo serio. Uno de esos casos es el algoritmo de triangulación de Chazelle. Lo más probable es que su prueba sea correcta, pero no hay implementación por un tiempo (hasta donde yo sé), ¡aunque es un algoritmo 'usado' a menudo!
En términos generales de Science, solo un verdadero revisor por pares puede hacer tal cosa. Un porcentaje excesivo puede señalarlo como demasiado difícil. Hubo un día (según me han dicho) en que la revisión por pares significaba ¡REVISIÓN!. Alguien más confiaba en que sabías lo que hacías y pondría su nombre (aunque de forma anónima) en la conclusión. Esas personas son, por supuesto, muy molestas, pero son parte de la base sobre la que se construye la ciencia real. O solía ser.
¿De qué otra manera sugieres que debería ir para verificar tus resultados?
@Discretelizard "Se puede demostrar que muchos algoritmos son correctos, pero aún así no son triviales de implementar". Pero eso es exactamente lo que dije. O muestra el pseudocódigo y prueba que es correcto, o si no puede hacerlo por algún motivo, especialmente cuando afirma que su algoritmo es más rápido que algún otro algoritmo, entonces debería mostrar su código, o proporcionar algún otro manera de verificar su reclamo si se le ocurre algo.
Por favor aclare: ¿El artículo trata sobre un algoritmo? ¿O un programa? ¿O los resultados que produjo una implementación específica en una entrada específica?
Nunca debes distribuir ejecutables, pero siempre el código fuente. Nadie quiere ejecutar un programa binario sin compilarlo desde la fuente. Podría hacer cualquier cosa en su sistema. Uno puede intentar solucionarlo con una caja de arena, pero ¿por qué no distribuir la fuente, si es parte de su trabajo científico?
@JonasStein Creo que la única razón por la que querría el código fuente sería para poder examinarlo en busca de errores, no porque me preocupe que otro investigador pueda dañar mi sistema. Especialmente uno que no ofreció dicho ejecutable como voluntario, sino que lo está produciendo a pedido.
@PhdStudent "Lo bueno de la ciencia es que es verdad, creas o no en ella". Ciertamente confío en nuestros científicos, pero esa confianza se gana a través de la verificación y la revisión por pares. Cuando publicamos ciencia sin verificación, nos abrimos a la pseudociencia en el mejor de los casos y al engaño deliberado en el peor.
Observo el uso de pronombres masculinos para referirse a un revisor presumiblemente anónimo. Creo que estos son nuestros sesgos implícitos que trabajan en nuestra contra.
@Sumyrda Hay una diferencia entre el código fuente y el pseudocódigo. El código fuente ES una implementación, solo que aún no está en forma ejecutable. El pseudocódigo no es código fuente, es solo un método para describir algoritmos. Pero si quiso decir que al menos debe estar presente algún tipo de argumento verificable (por el lector) para los resultados de un algoritmo, entonces, por supuesto, estoy de acuerdo.
@Discretelizard Exactamente, tiene que ser verificable. No importa si es verificable revisando el pseudocódigo junto con su razonamiento o revisando su código fuente, pero uno u otro tiene que ser posible. No estoy seguro de verificar el reclamo ejecutando pruebas contra un ejecutable de código cerrado; todavía hay demasiada "magia sucede aquí" para mi gusto, pero es mejor que nada.

Respuestas (8)

No sé si es normal, pero debería ser normal que todos los revisores hagan esfuerzos razonables para verificar que las afirmaciones que hacen los autores son correctas, así que en la medida en que no sea normal, solo puedo felicitar al revisor por estar dispuesto a hacer un esfuerzo que otros revisores no hacen. Lo que usted siente como "desconfianza" es que el revisor hace su trabajo, ni más ni menos (y probablemente sea algo correcto decir que el trabajo de un revisor es desconfiar de las afirmaciones del autor, por lo que no veo la idea de que desconfíen de él). un revisor como algo de lo que avergonzarse u ofenderse).

Por cierto, también debería ser normal que los autores pongan a disposición cualquier software (incluido el código fuente siempre que sea posible) necesario para replicar y verificar sus resultados. Entonces, si no está satisfecho con que el revisor le responda con solicitudes molestas que retrasan la decisión sobre su trabajo, la próxima vez puede adelantarse a esos problemas al publicar su código fuente (o al menos enviarlo a la revista) junto con su manuscrito. Estoy seguro de que el revisor estaría mucho más feliz y, en última instancia, todos se beneficiarían, incluido usted.

Gracias por tu comentario, tal vez me sentí ofensivo porque es mi primer artículo en una revista. Sin embargo, en mi campo de investigación no es común que los autores pongan a disposición su código. De todos modos, enviaré el ejecutable al revisor porque afirmó que sin esta verificación no se puede aceptar el trabajo. Gracias de nuevo.
Como alguien que trabaja en la industria y lee los periódicos como "un extraño", siempre me ha parecido muy extraño que haya una tendencia a "ocultar el código". Mi sensación es que el código, al igual que un papel, debería estar disponible. Estoy absolutamente con Dan aquí, debería hacerse más. Al menos para mí, no publicar el código siempre tiene un regusto amargo de que está pasando algo dudoso.
Desafortunadamente, la mayoría de los algoritmos y métodos numéricos descritos en revistas como Journal of Computational Physics (¡una revista de gran reputación!) están implementados en códigos fuente cerrados internos. Hice una revisión allí y solo tenía que confiar en los resultados.
Sería bueno que los autores pusieran a disposición software incluso cuando no sea necesario para replicar o verificar sus resultados. Puedo pensar en un documento de algoritmo que una vez traté de implementar, y me di por vencido porque no parecía escribir. Una implementación de referencia habría ayudado a comprender el documento.
De acuerdo sobre el encuadre adecuado del sentimiento de "desconfianza"; es mejor interpretarlo como un sano escepticismo científico, que todo crítico debería tener. Tengo cierto nivel de confianza en los artículos revisados ​​por pares (especialmente en temas con los que no estoy íntimamente familiarizado) precisamente porque han satisfecho el escepticismo de un panel de revisores.
@SBI No es extraño en absoluto. Si invierte 4 años de trabajo en un código, necesita pagar suficientes documentos/citaciones/atención para conseguir un ascenso. Un artículo no hará eso, y si publica su código, deberá pasar otro largo período de tiempo codificando un nuevo resultado publicable mientras sus rivales usan su código para atraparlo. No es tanto "publicar o perecer" como "publicar más que contrataciones alternativas o perecer". (Personalmente, liberé mi código; también perecí).
La respuesta asume que el revisor tiene sólo las mejores intenciones en el fondo junto con una tendencia idealista de mejorar la cultura científica. Si bien recomendaría esas cosas al instante, desafortunadamente vivimos en el mundo real. Se debe considerar que el revisor es una persona anónima que solicita la parte central de un proceso de investigación con una clara experiencia en el campo y el consiguiente interés potencial en él. Aconsejaría considerar cuidadosamente tales solicitudes también desde la perspectiva de que hay personas que podrían intentar explotar su anonimato y privilegio de revisor.
Otra bandera roja que me llama la atención es que solicitan un "archivo ejecutable". El usuario no tiene forma de verificar que el ejecutable no solo imprima los resultados sin ningún algoritmo detrás, además de realizar ingeniería inversa (sin entrar en demasiados detalles aquí). Tal solicitud posiblemente signifique que el revisor intenta adormecer al autor con una falsa sensación de seguridad al no solicitar intencionalmente el código fuente.
@ user3209815: Pueden estar atendiendo al punto de Xerxes: la publicación del código fuente puede no ser aceptable porque otros autores pueden obtener el OP. Hacer que el archivo sea ejecutable significa que tendrán que descompilarlo... lo que puede no ser viable. Aunque, como usted dice, no hay forma de verificar que dicho ejecutable no solo imprima los resultados requeridos.
@Xerxes ¿Cómo puede publicarse su idea en un artículo, si depende tanto del código fuente cerrado? Quiero decir, dejas abierta toda tu idea de todos modos. He escrito código basándome en papeles innumerables veces. Por lo general, el código es más una prueba de concepto que contener más información de la que publica de todos modos. Sin embargo, al revés, se vuelve más complicado. Hacer afirmaciones sin demostrar que realmente funcionan es... difícil.
@SBI Por supuesto, el documento debe ser tal que cualquiera pueda implementar el algoritmo. Pero eso puede ser mucho trabajo aburrido de ingeniería de software.
@Xerxes Idealmente, su trabajo sería respaldado adecuadamente por alguna agencia de financiación (generalmente pública). A cambio, usted abre el código fuente. Prácticamente, entiendo que hagas lo que tengas que hacer.
@Xerxes, es por eso que el código debe publicarse con licencias que requieran atribuciones. Si las personas van a tomar su código y publicar un artículo basado en él, tendrán que atribuirlo a usted como el autor original del código, al igual que tendrían que citarlo si usaron los resultados de sus artículos publicados.
@VladimirF: "Solo tenía que confiar en los resultados". No, no lo hiciste. Si los resultados son producidos por software, entonces debería poder verificar los resultados, y si no puede verificarlos, entonces no lo acepta. Está el dicho "fotos, o no ha pasado".
Agregaría que el ejecutable (código compilado) por sí mismo , aunque permitiría la replicación del esfuerzo, no sería particularmente útil en el gran esquema de las cosas. El código fuente, como han dicho otros, es lo más importante. O es software comúnmente disponible (en cuyo caso, ¿por qué los revisores no pudieron descargarlo ellos mismos?), o es un código raro o propietario, en cuyo caso el código fuente es el detalle más importante. Es el método que debe replicarse, y el binario es una caja negra que oculta el código, que es el método.
Los revisores están sujetos a la confidencialidad: puede proporcionar código a los revisores sin publicarlo. Sí, las trampas de los revisores ocurren a veces, aunque rara vez. Hay múltiples movimientos hacia los revisores que prueban el código; ver artefacto-eval.org para un enfoque.
@gnasher729 ¿Confía en los experimentos incluso cuando los autores no pusieron sus instalaciones a su disposición para volver a hacer sus experimentos? ¿Qué pasaría si ese método numérico se implementara en un código CFD sobre el cual los autores no tienen derechos de redistribución completos? El cálculo puede llevar mucho tiempo de CPU en una supercomputadora y los revisores no volverán a calcularlo de todos modos. No lo haría por ese artículo que revisé. El análisis de los resultados también puede llevar mucho tiempo.
@Xerxes No, no pasó 4 años en su código. Dedicó cuatro años a su algoritmo, que ya le está dando a conocer al mundo a través de su artículo. El código es simplemente una implementación del mismo que podría haber escrito en una fracción del tiempo, si hubiera comenzado con él después de haber establecido el algoritmo.

Vengo de un campo diferente, en el que el código que usamos no es un resultado importante. Pero si un árbitro pidiera el código, se lo proporcionaríamos con gusto. La mayor parte de nuestro trabajo se realiza en python, por lo que un ejecutable no sería habitual, la fuente lo sería (también es cierto para matlab).

De hecho, lo único que encuentro un poco extraño aquí es el uso de ejecutable en lugar de fuente .

No se ofenda por la solicitud por un par de razones: no es el trabajo de los revisores confiar en usted; es su trabajo revisar su papel. Si un revisor se interesa lo suficiente en su trabajo como para querer ejecutar su código, no ha descartado su artículo sin más.

Me gusta el punto final. Incluso me parecería un poco honroso si el árbitro estuviera dispuesto a probar mi software :)
@Džuris, de hecho, significa que se están tomando su artículo muy en serio.
¡Gracias por tu segundo párrafo! Nadie aquí parece ver esto. Cuando leí el título de la pregunta, asumí que OP encontró extraño que alguien solicitara un ejecutable en lugar del código fuente porque eso indica que no les importa lo suficiente como para verificar el código fuente en busca de errores / errores / errores deliberados y de hecho son demasiado estúpidos o perezosos para compilar el código fuente (que supuse que se proporcionó) ellos mismos.
@ UTF-8 También es posible que no tengan un compilador (tal vez no puedan debido a problemas de licencia/plataforma) o que no tengan la habilidad en ese idioma para dar sentido a la fuente. Incluso entonces todavía querría el código
Votado a favor y un ++ por el hecho de que es raro que quieran un ejecutable y no la fuente. Diablos, cuando califico la tarea, quiero la fuente y cualquier otra cosa necesaria para que se compile, incluidos los comandos/declaraciones/opciones/argumentos del compilador si es algo más complejo que "g ++ foo.cpp -o foo"

Para resumir la situación con sus datos: -

1) Se te ocurrió un algoritmo en papel/Matlab/lo que sea.

2) Implementaste ese algoritmo en algún lenguaje de programación.

3) Creaste un conjunto de datos de prueba para ejercitar tu algoritmo y obtuviste algunos resultados de lo que debería hacer en teoría.

4) Pusiste esos datos de prueba a través del código y obtuviste algunos resultados de lo que hace en la práctica.

En este proceso, hay varios lugares donde las cosas pueden salir mal con su metodología. Es posible que su código no refleje correctamente su algoritmo. Es posible que sus datos de prueba se hayan trabajado hacia atrás desde el código en lugar de hacia adelante desde el algoritmo. Sus datos de prueba para su algoritmo y sus datos de prueba para su código pueden no ser los mismos.

A menos que el revisor tenga el algoritmo y el código fuente y todos los datos de prueba para ambos y todos los datos de salida para ambos, no puede verificar que su trabajo sea sólido y que sus conclusiones sean válidas. Esto no está sujeto a disputa - es lógicamente imposible, si quieren revisar adecuadamente su trabajo. Cualquier otra cosa es hacer suposiciones que pueden no ser válidas.

Personalmente, me he visto afectado por esta situación, cuando mi empresa compró una propiedad intelectual de teoría de control de un investigador. Había escrito artículos sobre cómo se suponía que funcionaba esto y la teoría detrás de esto, y luego había construido algo de electrónica para implementar su teoría. Sus artículos cubrieron la teoría y también incluyeron esquemas para la electrónica. Cuando leí esto para averiguar cómo implementar su teoría en el software, descubrí que el esquema tenía un filtro adicional. La acción de este filtro resultó ser fundamental para que el sistema fuera estable o incluso eficaz, pero no se documentó en ningún momento de su trabajo. No fue hasta que tuvimos una llamada telefónica con él que descubrimos cuál era el propósito del filtro y cómo se suponía que debíamos ajustarlo.

Esto estaba en un artículo que teóricamente había sido revisado por pares cuando se publicó. ¡Claramente no había sido revisado por pares lo suficientemente a fondo! Sus resultados mostraron que, dados los mismos datos, el resultado de la implementación estaba bastante cerca del resultado esperado teórico y el efecto del filtro estaba en un lugar diferente en la respuesta. Sin embargo, la implementación nunca habría funcionado sin este filtro presente, y no habría sido nada difícil incluir esto en el modelo teórico. Incluso podría haber dicho "este filtro es necesario por estos motivos, pero se puede ignorar en esta área de la respuesta que estamos viendo por estos motivos" y se habría cubierto. Lo que no es aceptable es lo que hizo, que es no mencionarlo en absoluto,

Como dije, todavía publicó su artículo y nadie se quejó en ese momento. Sin embargo, sus revisores originales deberían haberlo visto. En su caso, su revisor debería estar buscando discrepancias como esta: es el punto central de la revisión por pares. Entonces, si las personas le preguntan por cosas que no ha puesto a disposición, (a) es una buena señal de que están revisando a fondo, y (b) debería haberlas puesto a disposición en primer lugar como mejor práctica.

Las presentaciones de artefactos son una cosa en CS. Lo que he visto es que prepararías una máquina virtual, donde tu software ya está configurado y listo para hacer experimentos. Entonces, el revisor puede estar refiriéndose a que la revista tiene algún procedimiento oficial para la presentación de artefactos. Alternativamente, algunos autores simplemente ponen a disposición el código fuente de sus herramientas y puntos de referencia a través de servicios como github, y el revisor puede sugerirle que también debería hacer esto. Con respecto a la desconfianza, la gente de computación naturalmente desconfía de los puntos de referencia y las comparaciones de herramientas, ya que las cifras finales pueden depender mucho de cómo se configure su experimento (por ejemplo, si lo compara con su propia implementación de un algoritmo existente, ¿lo implementó correctamente? ). También puede ser que los números que das en el papel parezcan un poco raros,

Enviar un ejecutable no es lo mismo que enviar el código fuente. Un ejecutable realmente no le da al destinatario ningún acceso a su código original (como un estudiante de informática ya debería saber, por supuesto). No veo ningún problema con esta solicitud.

Veo un problema importante: la ejecución del ejecutable en los mismos casos de prueba producirá los mismos resultados. incluso si esos resultados son incorrectos debido a un error en el programa.
Tengo curiosidad por saber cómo enviaría un "ejecutable" de, digamos, código Python, sin dar acceso a su código original. ¿Se espera que lo ofusques?
@jamesqf Podrían probar otros casos, no cubiertos por los autores.
Cualquier ejecutable se puede descompilar para producir funcionalmente el mismo código. Cualquier código que se compile en JVM o .NET se puede descompilar en algo relativamente parecido al original, e incluso el código de máquina se puede desgarrar con suficiente trabajo. Si bien creo profundamente que el código fuente debe publicarse con publicaciones como esta, si se niega a hacerlo, no puede ofrecer un ejecutable como si ocultara lo que desea ocultar de su código fuente.
@CaptainEmacs pero no pueden hacer eso si no pueden ver lo que realmente hace el programa. También podría tener datos incrustados en el ejecutable o hacer algo más de lo que se afirma.
@mathreadler Por supuesto, todo podría ser desafortunado. Sin embargo, tuve exactamente esta situación durante mi doctorado, y los autores me enviaron un ejecutable y pude probar mis ejemplos con él. Si hay una codificación incorrecta (constantes codificadas), a veces aún es posible editar el binario para solucionarlo (también lo he hecho una vez).

Dada mi experiencia personal con comunidades de código abierto y la suposición de que el documento incluye la totalidad del algoritmo en cuestión, enviar el código fuente o la compilación relacionada de dicho software no produciría muchos efectos negativos.

Esto permitiría al revisor verificar los resultados y las afirmaciones realizadas por el autor del artículo. El problema clave que el revisor podría estar buscando es que haya implementado correctamente el algoritmo en el código fuente y que no esté confiando erróneamente en una característica del lenguaje de programación, el sistema operativo o el hardware para hacer afirmaciones sobre su tiempo de ejecución u otras características.

En la parte superior de mi cabeza, diría que en los casos vinculados a E/S es fácil confundir los algoritmos eficientes con, por ejemplo, la capacidad de Javascript para hacer que casi todas las llamadas a funciones sean asincrónicas. Por supuesto, esto se ve principalmente en operaciones vinculadas de E/S en lugar de bucles computacionales proliferativos. Entonces la eficiencia medida no es la del algoritmo como prueba formal sino; en su lugar, se basa en una característica específica del idioma.

El punto destacado es que hay muchos casos en los que el algoritmo formal y la implementación pueden diferir de representarse uno al otro fielmente y, al hacerlo, la conclusión, si se basa en métricas empíricas como el tiempo de ejecución, puede encontrarse con muchos problemas en los que una implementación incorrecta puede dar fe de una conclusión incorrecta.

El código fuente puede tener errores, y para revisar un algoritmo de manera verdaderamente efectiva, una descripción en prosa del método por sí sola puede ser insuficiente. Compartir algo más allá del texto es beneficioso; un buen documento con el código fuente real (+entradas de muestra) es el estándar de oro para la reproducibilidad.

Un detalle divertido: dependiendo de dónde esté tu revisor, es posible que no puedas darle un binario. Por ejemplo, algunos códigos usan bibliotecas propietarias que tienen licencia gratuita en la academia, pero alguien en la industria podría requerir una licencia separada incluso para usar un binario existente, y mucho menos para compilarlo. (esto me pasó una vez, aunque no como parte de la revisión por pares)

Es una petición idiota de su parte.

  1. Podría contraer un virus.
  2. No hay una forma realista de que pueda verificar que el ejecutable implemente lo que se describe en su artículo, ergo , de ninguna manera la solicitud tiene ningún valor científico.

Debería estar pidiendo el código fuente, y eso es todo lo que deberías estar de acuerdo en darle.

#2 es a menudo falso. Un número importante de problemas tienen la característica de que comprobar una solución es mucho más fácil que encontrarla. En tal caso, un revisor puede verificar que una caja negra realmente produce soluciones correctas y mide la complejidad del tiempo de ejecución. Esto sería particularmente valioso si, por ejemplo, el revisor notara que todos los ejemplos utilizados en el documento tenían características particulares que los hacían más fáciles de resolver que el caso general, ya que podría formular sus propios casos de prueba.
@BenVoigt ¿Pero qué caja negra? ¿Cómo puede saber el revisor que tiene la caja negra implementando lo que afirma el artículo?
Hay un punto válido de que el uso de un recuadro negro no garantiza que el artículo contenga una descripción y una explicación precisas del método utilizado, pero el revisor puede estar mucho menos preocupado por el riesgo de haber falsificado la descripción dado que un método novedoso se ha demostrado que existe, al menos en comparación con el riesgo de falsificar tanto el método como la descripción.
@BenVoigt No puedo entender eso después de la palabra 'pero'. Un recuadro negro no prueba nada sobre las afirmaciones del documento. Solo prueba que existe una caja negra que produce los resultados alegados, de alguna manera.
El revisor podría ejecutar el ejecutable con un conjunto diferente de parámetros para reproducir un resultado conocido. OP no parece darnos suficiente información para saber que es el caso. En cuanto a la parte del virus, un usuario de Linux puede sentirse más seguro que un usuario de Win.
@Magicsowon Me gustaría venderles el Puente de Brooklyn. Tengo los títulos de propiedad. No te los mostraré, pero puedo enviarte un .exe que imprimirá "sí" cada vez que preguntes si soy el propietario.
@Magicsowon "un usuario de Linux puede sentirse más seguro que un usuario de Win" Usuario de Linux aquí. no estoy de acuerdo en absoluto Podría escribir fácilmente un programa que dañe documentos personales o los envíe a través de una conexión de red en ambas plataformas, si el destinatario tiene la amabilidad de ejecutarlo por usted. Linux es más seguro para el malware "generalizado" que no se dirige específicamente a usted, también porque hay más que están hechos para Windows.
@AndreaLazzarotto La palabra clave es "si". Los usuarios de Linux que dependen de sus máquinas para la investigación a menudo son lo suficientemente paranoicos como para tener una copia de seguridad de sus datos en 3 lugares diferentes y ejecutar software de terceros solo donde no puede dañar nada. Eso no descarta a las personas como yo que nunca han perdido datos de la manera que usted describe y simplemente se sienten seguros por eso.
@EJP Lo haré en cuanto mi tía muy lejana de Liberia me mande mi herencia para poder pagarte.
¿Es normal que un revisor pida un archivo ejecutable para verificar mis resultados?
RespuestasAquíPolítica de privacidad1y, 0v