Portada
mis comunidades
otras secciones
#3:
Pero rápidamente quedó claro que pasar de las buenas intenciones iba a ser complicado: Linus Torvalds y el resto de mantenedores del kernel Linux juzgaron inintegrable el código del driver; en primer lugar por ser demasiado extenso (27.000 líneas de código) y porque los desarrolladores de Paragon no eran capaces de integrarse en la dinámica de trabajo de GitHub.
No han trabajado en una consultora española en su puñetera vida
No han trabajado en una consultora española en su puñetera vida
#27:
NTFS-3G: Usado desde Linux, sólo era capaz de leer unidades NTFS
Esto no es cierto, NTFS-3G lleva años (MUCHOS años) pudiendo leer y escribir NTFS. Lleva años siendo el driver de facto en el mundo Linux para montar particiones NTFS. Que es lento sí que es verdad, es muy lento.
Esto no es cierto, NTFS-3G lleva años (MUCHOS años) pudiendo leer y escribir NTFS. Lleva años siendo el driver de facto en el mundo Linux para montar particiones NTFS. Que es lento sí que es verdad, es muy lento.
Comentarios
Pero rápidamente quedó claro que pasar de las buenas intenciones iba a ser complicado: Linus Torvalds y el resto de mantenedores del kernel Linux juzgaron inintegrable el código del driver; en primer lugar por ser demasiado extenso (27.000 líneas de código) y porque los desarrolladores de Paragon no eran capaces de integrarse en la dinámica de trabajo de GitHub.
No han trabajado en una consultora española en su puñetera vida
#3 ¿Pero como no van a ser capaces de "integrarse en la dinámica de trabajo de GitHub"? ¿A quién pusieron a hacer el driver?
#8 Pero si precisamente Linus reniega de Github, no le parece mantenible y prefiere las listas de correo inmanejables.
https://github.com/torvalds/linux/pull/17#issuecomment-5654674
https://github.com/torvalds/linux/pull/17#issuecomment-5659933
https://github.com/torvalds/linux/pull/17#issuecomment-5659970
https://github.com/torvalds/linux/pull/17#issuecomment-5660417
#10 https://www.theregister.com/2021/09/06/github_merges_useless_garbage_says/ Por lo que parece los de Paragon enviaron un pull request de GitHub y a Torvalds no le gustan, además de no poner textos lo suficientemente descriptivos en los merges
#12 A mí sus criterios de word-wraping no me molan, leerle me parece peor que un dolor de muelas. El texto se debería escribir en líneas y párrafos sin limitación de caracteres: Si ves un comentario con líneas limitadas en un móvil es un shitshow (adjunto imagen). Que él use terminal y tenga sus políticas de 72 caracteres en sus proyectos me parece genial, pero que todo lo que no sea eso lo critique con menosprecio diciendo que es objetivamente peor, pues que le den morcilla.
Otra tontería es el tema de poner los correos en plano por todas partes. Estamos en 2021, los spambots están a la orden del día. El mundo no funciona así. Comentar en Bugzilla que pone tu correo en plano en vez de nombre de usuario destruye cualquier cuenta de correo a causa del spam masivo.
Por otro lado, los PR editados en GitHub son un cáncer, y ahí sí estoy de acuerdo. Puedes editar un código y se guarda como PR, pero creo que sólo un archivo por commit, lo cual es estúpido porque los commits tienen que ser soluciones autocontenidas y para ello hace falta editar varios archivos.
#16 Pues lo siento, pero quien pretenda desarrollar código en un móvil se merece sufrir
#38 No hablo de desarrollar, hablo de leer. Yo he tenido que mirar alguna cosa estando de viaje sin PC para dar mi opinión o visto bueno. Y si no mira Torvalds escribiendo en GitHub como si fueran commits.
#39 Yo también, y lo he resuelto girando el móvil 90 grados
#38 Totalmente de acuerdo.
#16 Bah. Las listas de correo de OpenBSD son gestionadas por majordomo y funcionan de PM.
AntiSPAM y todo.
Tu comment no es mas que un lloriqueo de la gen-z.
>El mundo no funciona así.
Linux parece que si. Igual que OpenBSD, O los slackbuilds de Slackware, o cientos de proyectos que usan listas de correo.
Los moviles no son una herramienta valida de trabajo para tratar con texto de cierta magitud y no digamos ya programar.
#16
«A mí sus criterios de word-wraping no me molan, leerle me parece peor que un dolor de muelas. El texto se debería escribir en líneas y párrafos sin limitación de caracteres»
¿Dónde ha indicado que el texto tiene que tener un límite de caracteres? Que yo sepa lo que se limita es el código.
#81 #16 no habla de las listas de correo, si no de dejar a la vista en un archivo público las direcciones de correo. Para una empresa de publicidad es facilísimo hacer ronda por las listas de correo y recoger las direcciones. También decir que la LKML tiene mucho más tráfico que una lista de correo normal.
#10 Ir no va bien. Sin ir más lejos, uno de los primeros mensajes que encuentro según accedo a lkml.org:
«It seems that these patches are consistently being ignored[1][2][3]. So,
I'll take this in my -next tree[4] before it gets lost again.»
Que se pierdan correos en una lista de mucho tráfico es normal, pero no aceptable. Suerte que hay cosas como patchwork.kernel.org, que ayudan a mantener las cosas mejor ordenadas.
#10 vendor lock-in es mejor, donde va
La LKML funciona bien. No es bonita ni tiene colorines y botones pero va bien.
#21 Va bien si llevas suscrito desde 1995 y en tu lector de correo tienes un buscador cojonudo. La LKML no es más que una barrera de entrada muy alta para evitar la colaboración de nadie que no tenga verdadero interés o necesidad.
¿Cómo puede ser esto usable? https://lkml.org/
A no ser que vivas de ello y no quieras que gente nueva te venga a quitar el pan de manera rápida...
#25 >Va bien si llevas suscrito desde 1995 y en tu lector de correo tienes un buscador cojonudo.
Las listas de correo de SL suelen tener replica en MARC.
#10 parece bastante razonable todo lo que dice de Github.
#8 Eso es un gazapo de la traducción. Lo que Linus les pedía es que siguieran las convenciones de Git (no Github) usadas en el kernel. Esto viene a ser romper en código en varios parches sucesivos que pueden ser audicionados por los responsables del kernel.
NTFS-3G: Usado desde Linux, sólo era capaz de leer unidades NTFS
Esto no es cierto, NTFS-3G lleva años (MUCHOS años) pudiendo leer y escribir NTFS. Lleva años siendo el driver de facto en el mundo Linux para montar particiones NTFS. Que es lento sí que es verdad, es muy lento.
#27 No lo tenía claro, pero creo recordar que era así, aunque si mal no recuerdo te advertían de que podías sufrir pérdida de datos...
#27 Nunca había visto un artículo tan horrible. Mejor ignorar todo lo que pone en este artículo.
#27 También era incapaz de leer discos duros que no se hubieran "cerrado" correctamente desde Windows (por apagado inesperado).
#44 Bueno, este es un problema mutuo me [arece recordar. Si un dispositivo no es "desmontado" y queda marcado el flag "in use" entonces hay que desmontarlo y cerrarlo correctamente. Esto me parece algo hecho intencionadamente y deseable, aunque a veces cause problemas si no sabes de qué va.
#44 Si podia.
#27 A mi con eso me ha sobrado de siempre para hacer cuatro arreglos o migraciones, no me veo montando FS de Windows en mis servidores Linux pero habrá quien lo necesite, digo yo.
#0 En la UE deberia ser obligatorio que los dispositivos( camara, mp3, moviles, etc) y SO leyesen un formato libre como un EXT?
Tanto NTFS con los FAT tienen sus pegas, pero al final gana la compatibilidad que tampoco es tanta con FAT y NTFS.
#2 Las cámaras deberían permitir cifrado por defecto. No es normal que ninguna marca soporte algo tan básico para la seguridad como eso.
Con claves asimétricas sería lo ideal.
#4 ¿Para que el usuario medio pierda los certificados y sea imposible acceder a sus fotos?
#6 Un reportero de guerra estará de acuerdo
En cualquier caso que haya opción no quiere decir que esté obligado a usarlo.
#7 cada vez que decís "usuario medio", todos nos vemos forzados a esperar o dar pasos atrás, mientras las compañías gordas que han cebado al usuario medio con malos hábitos y acostumbrado a usar un ordenador como si fuese un electrodoméstico más, se enriquecen a nuestra costa.
Gracias.
#6 Y voy más allá: ¿Para que el usuario no medio malintencionado pueda colocar cámaras en sitios inadecuados y no haya pruebas contra él por estar cifradas?
#9 Eso ya lo puede hacer, a esta gente les pillan cuando difunden las imágenes, no cuando las graban.
#11 También les pillan cuando lo graban...
#6 el usuario medio de iPhone tiene todas sus fotos cifradas... y todo lo demás también
#36 y no lo sabe 😁
#43 Ni le importa
#36 en Linux también es bastante usual. Al activar la huella digital te suele pedir clave y cifra el teléfono. Con la diferencia de que este cifrado es con un algoritmo público.
#4 Por qué claves asimétricas ???
#17 Por complicarlo más y que sólo los verdaderos gurús de la fotografía puedan manejarlas.
#17 Porque si la clave es simétrica tiene que tenerla la propia cámara y por ello la seguridad se reduce drásticamente.
Con la clave asimétrica la cámara graba con un cifrado que no puede descifrar, solo cuando el propietario las extraiga en su ordenador y use la otra parte de la clave podrá acceder al contenido, nadie más podría a menos que le roben la llave que tiene en el ordenador.
Un ladrón que robe la cámara no podrá acceder a las fotos. Seguramente pueda resetear el dispositivo y crear nuevas claves y usar esa cámara pero no tendrá acceso a las fotografías del anterior propietario.
#24 De esa manera no puedes ver ni las fotos ni los videos que grabas hasta que los descargas al ordenador. O eso o tienes la otra parte de la clave almacenada en el dispositivo.
Lo mejor es un disco cifrado con clave, algo que ya casi todos los móviles hacen cuando le pones clave de bloqueo al teléfono, y esa clave es la utilizada para poder descifrar y acceder a los datos almacenados en el dispositivo.
#29 De esa manera no puedes ver ni las fotos ni los videos que grabas hasta que los descargas al ordenador.
Podría guardar la última foto en memoria, borrándola de la memoria al pararse la cámara. Pero tienes razón, eso sería un problema.
#17 Por simplificar, una clave simétrica sería como una llave que puede abrir y cerrar un candado. Una clave asimétrica es un par de llaves de forma que si cierras con una solo puedes abrir con la otra y viceversa. Así que no importa si te roban la que usas para cerrar, no van a poder "abrir" el acceso a tus datos.
#28 El cifrado asimétrico es ineficiente.
Bastaría con solicitar la clave al encender el dispositivo, y que no se almacenara en ninguna parte.
#31 Pensé que lo preguntabas porque no sabías lo que eran, eso sería otro tema, pero en algún lado tendrá que estar aunque sea en memoria volátil y no es imposible de recuperar. Al final depende cuánta seguridad quieras, y qué estés fotografiando, si es un sitio que no respeta los derechos humanos creo que te puede dar igual...
Te destruyen la cámara y la tarjeta de memoria, o si no las enseñas, te detienen igual. A veces, es mucho más fácil dejar que te borren las fotos, cooperar, y luego se pueden recuperar con relativa facilidad.
#2 o algo con la seguridad de un sistema ext, pero sin problemas de permisos
#5 #50 #58 UDF es compatible hasta con OpenBSD y NetBSD.
#64 Buen chiste. El de NVidia es literalmente el mismo blob binario en todo, los de Radeon tienes varios para elegir y no tienen nada que envidiar a Windows. En soporte Intel se folla a los drivers de Windows.
#66 UDF para tarjetas flash o pendrive, no se me había ocurrido
#1 #2 Ya está. Reciente pero ya está integrado.
Excelente noticia, a ver ahora exFat pa cuando.
#1 exFAT se añadio al kernel en may-2020, y FUSE-exFAT esta disponible desde el 2013.
#1 quién usa exFat ?
#42 Todos los pendrives que compras.
#49 Ayer mismo compré un Sandisk de 128 GB que venía pre-formateado en FAT32.
No tardé nada en formatearlo a exFAT, pero cualquiera que no sepa de qué va el tema se enfadará porque no puede meter pelis de más de 4GB en su modernísimo "pincho" USB.
#51 ¿Por qué? Según tengo entendido no es transaccional, no usa journaling ni soporta ACL en versiones de Windows de escritorio ni de servidor.
#72 FAT se usa por su sencillez. EXFat pretende ser lo mismo que FAT pero soportando archivos más grandes.
#72 Tampoco FAT32 es transaccional. exFAT es una evolución de FAT32. Uno que si parece enfocado a unidades tipo flash o SSD es F2FS.
#86 De ahí mi pregunta.
#49 Exfat es incompatible con muchos aparatos, Fat32 es el más compatible y no suelo tenner problema con la limitación de los 4gb por archivo, aún así es más problable que el aparato admita antes NTFS que exfat
#59 FAT32 es basura, es algo criado en Windows 98 y casi MSDOS desde FAT16.
Si formateas en UDF no tienes las limitaciones de FAT.
Con Rufus (software libre) puedes formatear en Windows en UDF sin problemas:
https://rufus.ie/en/
#68 ¿Pero después lo pinchas en tu televisor y lo lee?
#76 No. Pero si se pidiese a los fabricantes que usan un Linux emporado en la TV, se podria avanzar mucho mas.
No tendrian que pagar patentes a MS por los sistemas de ficheros.
#77 Ya pagan patente hasta por decodificar la TDT. No les preocupa una patentita más.
#77 Se podrían pedir tantas cosas ... así cualquiera
#76 Depende del televisor, exFAT cada vez es más soportado. Evidentemente si no lo soporta, lo formateas en FAt32 y listos.
#87 hablaban de UDF.
#42 y que usas en un pendrive si no es un sistema diseñado para soportes flash?
#50 cualquier sistemas de archivos ?, la cuestión es que muchos reproductores multimedia no aceptan exfat y otros tantos tampoco ntfs. con Fat 32 funcionan en cualquier sitio.
#58 no tienes mucha experiencia con FAT32, por lo que veo. Te invito a que averigües los obvios motivos por los que se dejó atrás hace mucho ese sistema de archivos
#60 Ya se que FAT32 es una mierda obsoleta, pero para eso están otros sistemas de archivos como ntfs, hpfs, ext4 ...
Pero es que ExFat es incompatible con muchísimos dispositivos . Así que prefiero la mierda de FAT32 y que almenos me funcione que un sistema de archivos mejor pero que no va.
#61 repito, como dije en el primer mensaje, que en plataformas flash ha de usarse sistemas de archivos flash, si usas ntfs o ext4 vas a rendir peor y con mas riesgos y desgastes que usando exfat. Lo de la compatibilidad sinceramente me extraña que te ocurra, no he encontrado ningun aparato que no tuviera soporte, y tengo televisiones de mas de 10 años, pero bueno me lo creo, pero si soportan ntfs deberia de soportar exfat, que es un estandar...
#80 "Lo de la compatibilidad sinceramente me extraña que te ocurra, no he encontrado ningun aparato que no tuviera soporte, y tengo televisiones de mas de 10 años, pero bueno me lo creo, pero si soportan ntfs deberia de soportar exfat, que es un estandar... "
Es un estandar cubierto de patentes de Microsoft, por el que Microsoft cobra(ba) royalties por cada dispositivo que soportase ese sistema de archivos o el estandar SDXC que lo requiere.
Esos royalties o bien reducían el margen de beneficios o bien aumentaban el precio, así que muchos dispositivos no lo implementaban si no era estrictamente necesario. Los smartphones de gamas bajas (y quizás medias) tienen margenes de beneficios bajos al ser un sector tan supercompetitivo, por lo que hay bastantes dispositivos android que lo evitan (por ejemplo, la tableta que usa mi madre desde hace 4 años).
#1 La noticia no es excelente, es una mierda, yo llevo escribiendo en NTFS desde Linux desde hace mil años sin problemas.
#48 Venía a decir esto mismo. Salvo que sea un disco de arranque de windows hibernado, se puede hacer de todo.
#1 A mi también me gustaría que el mpt funcionase mejor.
#1 https://itsfoss.com/linux-kernel-5-4/
Menos mal, no podía dormir
Me pregunto si se integrará con NTFS-3G, mejorando para que sea más rápido o crearán un sistema nuevo.
A ver si arreglan también libmtp, que transferir archivos de un Linux a Android a veces es una tortura por lento y/o por fallar en el peor momento.
#15 Pues yo he dejado de tener problemas desde la última versión, aunque ahora de memoria no me acuerdo que versión tengo de Ubuntu. Y si mal no recuerdo en la última LTS tampoco había mayores problemas.
Estoy de acuerdo contigo en las versiones anteriores, era insufrible la mayoría del tiempo.
#15 ni en Windows va bien. Y eso que mtp lo han diseñado ellos, Microsoft.
#22 Eso venía a decir, qué protocolo más malo, inestable y estúpido. Te cuelga todo el Explorer porque no es capaz de hacer dos cosas a la vez (transferir mientras miras carpetas).
#15 échale un vistazo a warpinator desarrollado por el equipo de Linux Mint, permite el envío de ficheros por red local, hay versión Android.
#33 Uso Linux Mint, así que me lo apunto. Gracias.
#67 Con ntfsfix puedes corregir lo del acceso desde Linux.
#69 Gracias, tomo nota, pero de momento ya digo que mi política de mantener los OS y sus discos separados me ha evitado problemas durante años. Claro que esto lo puedo hacer en mi caja de sobremesa porque la gente que usa portátiles lo tiene más complicado. al tener que compartir un solo disco.
En los foros de Linux Mint a menudo se ven preguntas sobre problemas de acceso a otro disco con NTFS y recuerdo que una vez puse que lo mejor para que un SO no te corrompa el disco del otro es desenchufar el disco y físicamente sacarlo de la caja, llevarlo a otra habitación y guardarlo en un cajón bien cerrado. La que preguntaba pensó que iba en serio y me preguntaba sobre la importancia de guardarlo en un cajón en otra habitación. Como si Linux fuera capaz de corromper discos a distancia.
Antes dedicaba más tiempo a probar, experimentar y estudiar cosas nuevas pero este Linux me va bien y ahora ya procuro no tocarlo
Cuando mi principal SO era Windows y empecé con Linux y los problemas de compatibilidad de formatos pensé en montarme un NAT para guardar todos mis ficheros en el NAT pero finalmente me aburrí de estudiar el tema y lo dejé y nunca lo hice. Tenía una idea un poco de James Bond de que instalaría un NAT encerrado/tapiado en una pared y quizá accesible por WIFI o fibra óptica y así mis ficheros estaban seguros aunque me robaran los ordenadores. Pero nunca llegué a hacerlo
Como digo, el Linux me va muy bien y procuro no tocarlo. Dedico mis estudios y experimentos a otras cosas. en este momento ando aprendiendo y jugando con fibra óptica.
#70 > Como si Linux fuera capaz de corromper discos a distancia.
Mas bien la mania de automontar todo. Yo no dejo que eso ocurra, suelo montar los discos a mano desde la linea de comandos.
>Dedico mis estudios y experimentos a otras cosas. en este momento ando aprendiendo y jugando con fibra óptica.
Pues por no usar Linux te estas perdiendo simuladores como GNS3 que te emulan hasta routers cisco con IOS e integracion de maquinas virtuales en red con Qemu.
#71 >> la mania de automontar todo
Efectivamente, puede dar lugar a problemas indeseados. A mi tambien me gusta montar manualmente cuando voy a usar algo y desmontarlo después pero en lugar de usar la línea de comandos me hago un ficherito/lanzador o como se llame y así solo tengo que picar en el icono y se monta. También porque tengo volúmenes Veracrypt que requieren mucho texto de parámetros y así solo tengo que picar y poner la clave y se monta. Por cierto que no lo he pensado pero me imagino que Vercrypt usa el formato de Ext4 para metadatos. No é si habrá Veracrypt para Windows y NTFS.Con Windows uso PGP.
Yo llevo meses usando ese driver porque el ntfs-3g es lentísimo sobre todo para escribir, con este va a tope. El driver se llama ntfs3, en distros tipo Arch Linux se instala fácilmente desde AUR con el paquete ntfs3-dkms.
, tal que así: mount -t ntfs3 "$@"
Lo que no supe es cómo hacer para que por ejemplo si monto una partición desde Dolphin se hiciera con ntfs3 en vez de ntfs-3g, al parecer Fuse directamente siempre montaba con ntfs-3g, entonces me di cuenta que para montar lo que hacía era ejecutar el binario /usr/bin/mount.ntfs, así que lo cambié por un script que ejecuta mount con el driver ntfs3
A ver para cuándo drivers decentes, sobre todo para tarjetas gráficas.
Yo uso Linux Mint desde hace años (ahora Linux Mint 20.1 Ulyssa, Kernel: 5.8.0-59-generic x86_64) y nunca he tenido problemas de acceso a NTFS que yo recuerde. Cual es la novedad?
#56 La diferencia es que, hasta ahora, se usaba NTFS-3G, que es un driver de espacio de usuario, y es muy lento. Técnicamente, Linux (el kernel) no tiene soporte completo de NTFS, concretamente no puede escribir (además de muchas otras limitaciones). Este nuevo driver vendría a integrarse en el kernel en sí, lo cual trae muchas ventajas, especialmente de rendimiento.
#63 Yo empecé con Linux poco a poco hace años y tuve problemas del tipo de que un disco mal cerrado no me lo leía el SO "contrario" por lo que empecé a separar cosas y ahora mis reglas generales son (1) cada SO en su disco duro físicamente separado, (2) No acceder al disco duro de un SO desde el otro, (3) para transferencia de ficheros entre discos empecé teniendo un pendrive conectado permanentemente y que servía de intermediario. Después me di cuenta de que siempre tengo otro ordenador en la red y lo que suelo hacer ahora es usar otro ordenador de la red como intermediario.
Esta política me ha salvado de muchos quebraderos de cabeza aunque la realidad es que en esta máquina, por ejemplo, hace muchísimo que no arranco Windows y que no tengo necesidad de acceder a su disco. Como digo, suelo tener otro equipo corriendo Win XP y las transferencias las hago por ahí. La única pega que me surge a veces es que los metadatos de los ficheros son diferentes en WIndows/NTFS y en Linux/Ext4 y a veces eso me ha causado problemas.