miércoles, 11 de noviembre de 2020

Cuidado con los discos clonado

He tenido un "pequeño" accidente que he tardado en entender. El problema nació de mi decisión de eliminar la grabadora del ordenador, que ya no uso para nada. Eso supone disponer de un SATA libre. Como siempre, estamos escasos de espacio, y decidí recuperar uno de los discos retirados que tengo por ahí. Empecé por uno de 2,5TB, pero tenía algún sector erróneo, así que recuperé el más "moderno" de los disponibles, un Caviar Black de 2TB y fabricado en 2013. Lo incorporo, veo que está en ext4, así que decido no borrarlo y simplemente leo el UUID con blkid y lo incorporo al /etc/fstab

UUID=nume-rito-en-cuestion /mantener2     ext4    defaults        1 2

y reinicio.

En su interior había un directorio home, ya que este era mi antiguo home —véase aquí para ver el cambio de un HD Black Caviar a un SSD— y decido borrarlo... DESASTRE, por que borra todo ese disco y mi /home activo entero, es decir, todo mi trabajo. A otros les hubiera dado un ataque, pero para mi no es nada nuevo, porque me pasa de vez en cuando (esas manos quietas, muchacho!), así que sacamos el disco problema, tiramos de copia de seguridad para recuperar la información básica, instalamos todo de nuevo, porque mi copia de seguridad no guarda las configuraciones, y restaurado lo fundamental dejamos copiando el grueso de la información perdida; en total, unas 7 horas perdidas. Cosas a tener en cuenta:

  1. La sincronización que tengo del OneDrive —véase entrada anterior— supone que al borrar el home borró también TODO, la nube y los otros ordenadores, cosa que no me ha pasado en Dropbox. MUY IMPORTANTE tener una copia de seguridad local y no fiarse solo de la nube.
  2. ¿De dónde viene este problema? Al principio se lo atribuía a que el disco tenía un directorio /home y que la máquina los hubiera "unido" de alguna manera, pero no debería, ya que uno es /home/usuario y el otro es /mantener2/home. Después, mientras estaba intentando instalar Fedora 33 otra vez, anaconda me decía que detectaba dos discos con la misma UUID. ¿Cómo? Pues por que el disco Caviar Black ERA mi antiguo home, y el nuevo es un clon de él (aquí la prueba del delito clonador).
Sí, había clonado uno sobre otro, y eso ha supuesto que tuvieran para el sistema la misma UUID, y debería saberlo, por que como había dicho en la entrada donde explicaba ese cambio, no había sido necesario recurrir a editar fstab, ya que tenía la misma identificación y, además, debería haberlo visto al editar fstab, pero como lo hacemos todo a velocidad terminal, no nos fijamos en el resto del ambiente. Es decir, al decirle al sistema a través de nautilus —ahora llamado Archivos— que borrara el contenido de un disco, el sistema borró los dos que tenían la misma UUID.

En resumen, antes de reutilizar un disco clonado, formatearlo previamente y a ser posible en un ordenador distinto al que contenga la copia, no vaya a ser que también formatee a los dos en paralelo. Y además, copia de seguridad para todo, y no nos fiemos de tener algo en la nube, por que las nubes se las lleva el viento, o un borrado accidental.

jueves, 5 de noviembre de 2020

Onedrive actualizado en Linux

A pesar de ser un usuario de Dropbox desde que esta aplicación nació, y que además tengo contratada una licencia plus de 2TB, por razones profesionales —los documentos oficiales de mi Universidad tienen que localizarse solo en el software y en el servicio de alojamiento contratado por ella— no me ha quedado más remedio que usar también OneDrive. El problema para lograr un trabajo fluido por alguien que usa software libre para todo está en que no existe un demonio cliente oficial que permita sincronizar OneDrive con el disco duro de trabajo en un sistema operativo Linux. He mirado las posibilidades no oficiales. La que parece más sencilla, Insync, no es GPL y además es de pago. La siguiente posibilidad, Rclone (página propia aquí), sí es GPL y gratuita, y que además permite sincronizar Google Drive, la veo complicada en su configuración (véase aquí y aquí, para el que quiera). Lo que he visto más sencillo y rápido es onedrive, el cliente gratuito y libre de OneDrive de MS.

La instalación y preparación es sencilla. Una buena página que indica lo más importante es ésta. Por pasos:

1. Instalamos

su -c 'dnf install onedrive'


2. Ejecutamos:

$ onedrive

y en el terminal aparece una URL muy grande que nos conecta al sistema Microsoft. Hay que abrir la cuenta y luego (o si ya la tienes abierta también) queda una página en blanco. Copiamos la URL de esa página en el terminal donde decía Enter the response uri:

y con ello permitimos la conexión y sincronización de onedrive con nuestro disco duro.


 

3. Sincronizamos

$ onedrive --synchronize

y aparece en nuestro nautilus —ahora llamado Archivos—. Esta orden actualiza en ambas direcciones TODO el contenido de OneDrive. Si queremos sincronizar solo parte de los directorios o ficheros de nuestro OneDrive, generamos un fichero sync_list en el directorio /home/usuario/.config/onedrive. Ese fichero podría líneas similares a: 

Apuntes
Imagenes
Documenots/fichero1.odt

Siendo los primeros directorios y el último un fichero en concreto que queremos que se sincronice. 

Hasta ahora estoy sincronizándolo todo.

Después de cada cambio, se resincroniza mediante

$ onedrive --synchronize --resync

4. Si queremos evitar la resincronización continua, podemos incluir el cliente onedrive en systemd. De este modo se sincroniza de manera continua desde el inicio y nos olvidamos de resincronizar

$ systemctl --user enable onedrive # permiso
$ systemctl --user start onedrive # inicio servicio

Si queremos comprobar que onedrive está monitorizando los cambios:

$ systemctl status --user onedrive

Si tenemos la monitorización activada y aparece un problema al ejecutar una sincronización al ejecutar onedrive --synchronize --resync—que no es necesario hacer, ya que el sistema se monitoriza automáticamente—, podemos apagar el servicio onedrive en systemd

$ systemctl --user stop onedrive

luego resincronizar OneDrive

$ onedrive --synchronize --resync 

y luego reiniciar el servicio
 
$ systemctl --user start onedrive

Sencillo.

viernes, 25 de septiembre de 2020

Discos antiguos. ¿Qué hacemos con los WD MyBook?

Al contrario de lo que decía en esta entrada en la que hablaba de la sustitución de las cajas para discos externos, diciendo que menos es más, en ocasiones eso no es cierto, y más es más. A lo largo del tiempo de uso del material informático, vamos sustituyendo los discos duros, a veces por velocidad, donde más rápido en respuesta y búsqueda siempre es más, y otras veces por tamaño de almacenamiento, donde siempre más es más. Por razones de almacenaje, mi disco de almacenamiento interno de 8TB, que es el espejo —mejor dicho, copia de seguridad interna— del trabajo diario, se ha quedado pequeño y ha sido sustituido por uno de 12TB. Eso deja un par de discos WD Red 8TB —la copia interna tiene un clon externo— prácticamente nuevos, de octubre de 2018, sin uso. Al revés que en el ejército, en mi caso los discos duros entran como generales y los vamos degradando hasta que los expulsamos de la división, así que estos comandantes pasaron a ser tenientes y había que buscarles un uso. Mantengo copias de material multimedia en otros discos, entre los cuales los más antiguos son 4 dispositivos WD MyBook de 3TB, modelos fabricados en 2012. Lo más sencillo para reutilizar las unidades casi nuevas de 8TB es transferir el materil de cada 2 de ellos a uno y aun quedan 2TB para reutilizar. El problema es que hacemos con los WD MyBook. 


La mejor idea será degradarlos a soldado raso para copias temporales y movimiento de material de aquí para allá. Como ya dije en esa entrada antes señalada, las cajas son un estorbo que además provoca un volumen innecesariamente grande. Mi preferencia está en sacar el disco duro y usarlo sin más en unas cajas abiertas Orico que tengo conectadas al ordenador. El problema inicial está en no saber que tipo de discos hay dentro; muchas veces en este tipo de dispositivos el disco duro es distinto a un HDD interno normal y no se puede usar fuera de la caja que lo envuelve, porque lleva un chip de control y una carcasa de comunicación no estándar.

La apertura es muy sencilla, y hay muchos vídeos donde se puede ver que lo único que necesitas en un destornillador plano —después de haber roto los enganches, recomiendo usar una pieza de plástico o una tarjeta, por si queréis mantener la caja para usos posteriores— y separar las pestañas de fijación a lo largo de los dos bordes hasta extraer el disco y parte de la carcasa para fuera. Por supuesto, y por seguridad, si el contenido interno es importante, siempre primero hacer un transvase de la información. Luego, en el caso de la unidad que tengo, el disco interno es simplemente un WD Caviar Green estándar que estaba fijado a la caja con unos ajustadores de goma. Los únicos tornillos que he tenido que sacar son los que unen el disco a una estructura de comunicación externa.

Y como resultado tenemos una unidad WD Caviar Green del año 2012 con poco uso, por que siempre ha sido una unidad de almacenamiento externa, que se puede usar fácilmente y que ocupa la mitad de volumen que antes. 

En resumen, se pueden abrir sin problemas. No he tenido ningún cuidado, por que no pienso reutilizar las cajas, pero si alguno de vosotros queréis ponerle algún disco nuevo dentro, tener cuidado al abrir para no romper los anclajes, que son muy débiles.

miércoles, 22 de julio de 2020

Linux, Wayland y compartir escritorio en Teams

Como decíamos en la última entrada, hemos tenido problemas en el teletrabajo. El más importante ha sido el uso de Teams y compartir escritorio. La Universidad, al menos la mía, ha puesto como paquete de software oficial Office 365, que incluye un conjunto completo de aplicaciones, además de Word, PowerPoint y Excel. Para dar clase o para enseñar como se hacen ciertas cosas en clases prácticas o simplemente en una discusión de como se hace algo en aislamiento es necesario una aplicación de reuniones, y ahi tenemos Teams. Pero el problema fundamental en Teams se presenta para los usuarios de Linux con sistema gráfico Wayland cuando se quiere compartir un escritorio. Como es bien sabido, Wayland no deja fácilmente compartir y al tocar la opción compartir, Teams salta inmediatamente, y aunque se reinicia, te ha mandado fuera de la reunión y hay que volver a entrar; un problema si el profesor eres tú. Y como puedes enseñar si no puedes mostrar como lo haces tú. De hecho, he intentado cambiar permisos, y nada; he intentado arrancar la aplicación de escritorio de Teams, y Wayland no lo permite (completamente lógico). Finalmente, y para evitar un ordenador con Windows, requerí a la última esperanza, arrancar Fedora 32 en xorg (con el que accedemos a x11). ¡Y FUNCIONA!


Es decir, por ahora, mientros Microsoft, este nuevo amante profesional (póngale el sinónimo que quieran) de Linux, no arregle esta situación, y mientras gnome nos permita tener en la recámara un arranque en x11, tenemos una solución; cuando nos toque una conversación, clase, discusión o lo que sea con Teams, y por si durante el transcurso de la misma tenemos que compartir información a través del uso de cualquier programa en el ordenador y mostrarlo, arranquemos en xorg.

martes, 21 de julio de 2020

Fedora, R, los cambios de versión e infierno de dependencias

Bien. Como podéis ver esta pandemia nos ha llevado a que hagamos menos entradas. El teletrabajo consume más tiempo y te deja más cansado y un poco harto del ordenador.
En nuestro teletrabajo ha dominado la situación Teams, del amigo Microsoft, que para los linuxeros, o al menos para mi han sido un problema. De eso hablaremos más tarde. Mi otro teletrabajo es seguir haciendo estadística en mis ordenadores. Esta vez he tenido un dos problemas. Fedora ha tardado en introducir la versión 4 de R en sus repositorios, y eso ha supuesto dos dificultades en momentos distintos.
Primer peoblema; al haber instalado Fedora 32 de manera limpia, he tenido que instalar de nuevo R sin paquete alguno, por lo que los tuve que añadir todos, que son bastantes.


La versión 4.0 ha introducido algunas características especiales que hacen que la mayor parte de los paquetes tengan que actualizarse, y como yo aun estaba en la 3.6.3, muchas veces me he encontrado en los repositorios con el mensaje de "no hay versión para R 3.6.3". Normalmente cambio de espejo y voy a Nueva Zelanda, de donde R empezó, y suelen tenerlo todo, pero esta vez no ha sido así. Y eso obliga a bajar el código fuente de la versión anterior e instalarlo, a veces con problemas de dependencia. Un pequeño problema...
Segundo problema, después de haber solucionado el primero; ayer R puso a nuestra disposición R 4.0.2. Una vez instalada la versión 3.6.3 y todos los paquetes que uso, al actualizar el sistema, y cambiar R, empezaron los siguientes problemas. Muchos de los algoritmos que he estado utilizando estos días, (MCA, Cluster...) han requerido versiones preparadas para la versión 4 de R. Teóricamente se debería haber solucionado con update.packages(), pero no es así. He tenido que ir instalando paquete a paquete, uno a uno, con infierno de dependencias de hasta 7 niveles de profundidad. Por suerte, al haberlo hecho por la mañana en el ordenador del trabajo, ya dejé apuntadas las ramas de los árboles de dependencia, y en vez de dos horas he tardado una en casa por la tarde (ahora, desde que nos dejan mover, solo teletrabajo por la tarde), pero he acabado con 4 páginas de ramas hasta terminar el árbol de dependencias.
Es lo que hay. ¿Por qué no se ha solucionado con update.packages? ¿En que me he equivocado? Si lo llego a saber, lo desinstalo todo y lo vuelvo a instalar desde el inicio, y no me aparecería continuamente, más o menos, por que no me acuerdo exactamente (y en inglés, claro),
"El paquete x, es necesario para instalar el paquete y; la versión disponible es anterior a R v 4. Por favor instale una versión más moderna..." decenas de veces, y hasta 7 veces z, para y, b para z, d para b, k, para d... Y en Linux, no como en Windows, los paquetes se compilan.
Como antiguamente en Linux, más o menos
Eso sí, esta vez RStudio no ha protestado.

domingo, 31 de mayo de 2020

Fedora 32. Recomendable

Después de dos semanas en Fedora 32 puedo recomendar —encarecidamente, además— actualizar a Fedora 32. He notado cierta mejora y una respuesta más rápida a casi todo. Además, por ejemplo kpat, que me saltaba frecuentemente, va muy bien, sin errores, emule a través de wine consume menos recursos. Cierto es que he estado centrado en el uso de R y RStudio, más un uso bastante continuo de Teams —es el que tiene oficialmente mi Universidad—, así que no he probado todo, pero en general estoy muy contento con Fedora 32. El DNIe funciona perfectamente, he instalado una Canon i-sensys mf443dw, por lo que ya no sufro por la impresora, y funciona bien, aunque aun no he conseguido la instalación del driver del escáner, entre otras cosas por que Canon España no ofrece un driver oficial. Pero eso queda para más tarde y no es muy importante, por que escaneo a unidades USB y queda muy bien. Lo importante, los que estén ahora mismo en Fedora 31 y estén dudando de actualizar o esperar un poco más, recomiendo la actualización ya.


domingo, 17 de mayo de 2020

Cambio a Fedora 32: actualización e instalación limpia al mismo tiempo

Ha sido un cambio forzado. Vamos por partes; debido a la alerta, y el teletrabajo, no había cambiado a Fedora 32, ya que los primeros días siempre encontramos algunas inconsistencias, y esperaba a acabar la evaluación para actualizar. Para ensayar el cambio, quise actualizar directamente mediante comandos el portátil. De manera sorprendente, en el primer comando (está descrito como seguir el proceso aquí)

su -c 'dnf upgrade --refresh'

me apareció un problema con wine, y la versión nueva estaba en conflicto con la antigua. Para ver lo que pasaba, actualicé (solo dnf update) el ordenador principal, para ver si me aparecía el mismo problema, cosa que no pasó y di la orden de reiniciar; mientras, seguía con el portátil, que actualice siguiendo el comando

su -c 'dnf update --exclude wine*'

Y luego seguí la actualización a Fedora 32

su -c 'dnf install dnf-plugin-system-upgrade'
su -c 'dnf system-upgrade download --releasever=32 --allowerasing'
su -c 'dnf system-upgrade reboot'

por cierto, todo perfecto.


Como después de este rato, el ordenador principal no daba señales de vida, lo apague a machete y lo quise encender de nuevo quedó en negro pidiendo rescate. El  mensaje era más o menos en UUID nº de uuid correspondiente a la partición del disco correspondiente a / (sda3), no encuentro ficheros...
En resumen, me había cargado la partición raíz por no haberme parado un poco y ver que estaba haciendo el sistema.
La solución era instalar de nuevo, y ya puestos quise instalar Fedora 32. Esto trajo una nueva sorpresa; Fedora no ofrece un ISO netinst escritorio, y tardé un rato en descubrir que la solución actual es Fedora-Everything-netinst-x86_64-32-1.6.iso, una imagen que da muchas posibilidades de instalación, incluyendo la de Workstation (hay que elegirla en anaconda, entre otras muchas).
Prefería haber actualizado el sistema más tarde, pero por tener tan poca paciencia, hemos terminado con Fedora 32 instalado, y va bien. De hecho, algunas cosas van mejor que antes. A cambio he tardado más tiempo en instalar la impresora nueva (si tengo tiempo hablaremos de ella) y aun hay cosas que no he terminado de instalar (lector de DNI electrónico, por ejemplo). Para cuando haga falta...
PD. Y wine funciona perfectamente, como lo confirma emule

martes, 7 de abril de 2020

Cambiando el disco /home en Fedora 31. Ni siquiera fue necesario editar fstab

Como había dicho el otro día, había varias cosas pendientes sin hacer en las que me ocuparía si encontraba tiempo en este aislamiento físico y psicológico en el que estamos. Me había propuesto cambiar el disco que contiene /home en mi ordenador. He mirado los recibos y compré un SSDV-NAND SSD 860 QVO SATA 6Gb/s de 2 TB el 19 de noviembre de 2019, hace 4 meses y medio. Estaba esperando a la liberación de Fedora 32, pero he estado pensando que ahora dependemos del teletrabajo, así que probablemente no instale Fedora 32 hasta que pasen unos dos meses de su salida, cuando esté más estable y con menos necesidad de "pulido". Además, el equipo funciona perfectamente y tiene todo lo que necesito, y la instalación limpia siempre lleva a que la primera semana estemos añadiendo cosas que nos hemos olvidado de incorporar en la lista de instalación inicial. De esta manera, cuando se libere el nuevo Fedora, simplemente actualizando en unos 60 a 90 minutos estará todo preparado. Al terminar de trabajar la noche anterior, para hacerlo lo más rápido posible y perdiendo poco tiempo de trabajo, extraje el disco home —mi equipo tiene todos los magnéticos en posición frontal para sacar incluso en caliente, aunque en mi caso no es posible, ya que forman todos parte del equipo—; era ese hueco que queda arriba, ya que están colocados por orden sdb, sdc, sdd y sde. El sda es otro sólido que es el sistema y está fijo en posiciones inferiores.


Ahora había que clorar el disco. Siempre se podría haber acudido al raspbeerypi que preparé ayer y clonar con una orden dd, pero por suerte tengo una caja lectora de discos duros SATA modelo TOOQ TQDS-802B, que permite clonar un disco sobre otro sin usar un ordenador; ya la he usado más veces. Funciona perfectamente, clona rápidamente —siempre con el cuidado de poner el origen en A y el destino en B, o adios muchachos, todo perdido—, como vemos en la foto; se aprieta el botón frontal unos segundos, y corren los colores hasta que termina.


Por la mañana ya esta el nuevo SSD clonado (luces estáticas). Lo inserto en el ordenador, y yo estaba esperando tener que editar fstab, ya que teóricamente ha cambiado el UUID que define el disco y el sistema en teoría, no debería arrancar, como aquí.
Sorprendentemente, arrancó a la primera, como si no hubiera pasado nada; bueno, en mi opinión arranca más rápido, ya que la lectura de la configuración la tiene que hacer en /home/usuario, donde está todo anotado, y tarda unos segundos menos. Otro cambio es el sonido del equipo, que ha disminuido. Ahora mismo aun tiene 3 discos magnéticos, pero dos son de almacenamiento de lo que ya está terminado, modelos WD Red 8TB, a 5400 rpm, que no hacen demasiado ruido y queda aun un WD Green 4TB a 7200 rpm, donde mantengo lo del intercambio de pares. Simplemente se nota un cierto silbido en el ambiente.
Respecto al comportamiento, sí que puedo recomendar cambiar los discos de trabajo a SSD, no solo el del sistema, si no también el /home, para aquellos que tengan discos diferentes para cada función. Respecto al almacenamiento, en mi caso cambiar 20TB que dispongo es prohibitivo, ya que los discos sólidos de 4TB están cerca de 500€, y los de 8TB suben de ese precio en marcas poco conocidas y mucho más si nos fijamos en WD, Sandisk o Samsung. En resumen, bueno, bonito y fácil —lo de barato es relativo, ya que me compré el disco en una oferta de esas de amazon de compra en 4h59 minutos o despídete de este precio y no me quejo—. El equipo, el sistema y el usuario lo agradecen pero el cambio total a sólido aun va a tardar.

PD. Y de paso, desmonté alguna cosa, hice hueco y le pasé la aspiradora por dentro al equipo, que esta algo polvoriento. Por suerte, no fumo, y el polvo no se adhiere a la "machina".


PDD. Ahora queda libre un WD Black, con 7 años de uso ininterrumpido 24x7. Habría que darle un retiro respetuoso, pero con 2TB de volumen, poca utilidad puede tener. Eso si, cuando lo compré, costó más que su sustituto; de aquella eras un disco de servidor, y en que te has quedado...

lunes, 6 de abril de 2020

RaspberryPi 4 en un Pi-topCEED

Como había dicho hace unos días, tenía algunas cosas pendientes y he estado solucionando algunas. Empecemos por RaspberryPi 4. La verdad es que tengo muchos RaspberryPi. Para ser exactos tengo 2 2B, 2 3B y un 4B. ¿Para que los uso? Realmente los usaba fundamentalmente para recrear lo que hago en las prácticas que imparto en un equipo menos potente para comprobar que lo que hago se puede hacer en los ordenadores de las salas de informática. Estas salas de informática han sido transformadas en los últimos años y como tenemos equipos modernos y relativamente potentes, en estos últimos cursos no he necesitado hacer este control previo. La segunda utilidad para mi es usar Debian. Estoy usando Fedora desde finales de 2011, y el universo Fedora/rpm es muy distinto, en el terminal, claro, que el Universo Debian/deb (algunos, la mayoría, dirían Ubuntu/deb). Es decir, usar de vez en cuando Debian me refresca un poco en apt-get y todas esas cosas que formaban el universo Linux en el que entré. Hay gente que lo usa como servidor de red, pero no es mi caso. Otros preparan camaras de vigilancia, robots etc... Tampoco es mi caso; en estos momentos los tengo como mero juguete para divertirme cuando tengo tiempo. El mes de junio de 2019 me compre el último, un 4 modelo B con 4GB de RAM, que ya es una máquina con ciertas prestaciones, pero no lo había sacado de la bolsa desde ese día. Aprovechando este aislamiento, ayer, Domingo de Ramos, decidí no teletrabajar más, después de la Misa del Papa, estuve reparando muebles, arreglando la wifi —eso lo dejamos para la siguiente entrada— y sacando de la bolsa el raspi. Me había comprado el kit completo en kubii, la tarjeta-ordenador, alimentador, caja, adaptador USB a USB-C, y al cable HDMI a microHDMI. La idea era ponerlo al lado de mi ordenador principal, usándolos simultáneamente, sirviéndome del mismo monitor Philips 241P. Este monitor tiene muchas entradas de vídeo, y mi ordenador principal usa la HDMI desde su salida DisplayPort. Eso deja libre una DVI que podría conectar al Raspberry y luego ir indicando al monitor lo que quisiera que me enseñase cada vez. Sin embargo, yo siempre tengo al lado de mi ordenador un pi-topCEED con un RaspberryPi Modelo 3B con el que juego un poco cuando tengo tiempo.


Así que en vez de compartir monitor me propuse reutilizar el pi-top para el nuevo Raspi. Como ya ha publicado pi-top, se puede incorporar sin muchos problemas un Rasp4 al pi-top3, el portátil que se había creado basado en un rasp3, así que no debería haber problemas "técnicos" en el uso del rasp4 en el pi-topCEED. Los problemas fueron físicos, de espacio. Primero, la orientación física del rasp4 es diferente al rasp 3, así que la parte con la conexión ethernet, que ocupa algo menos que los doble USB están cambiado de lado y el rasp4 entra con dificultad por que la entrada es más estrecha justo ahí, pensando en el ethernet que tenía el rasp3. Bueno, empujando con cuidado entra.


El segundo problema es que la entrada de imagen en el pi-topCEED es un HDMI-HDMI y como la conexión se debe colocar en un sitio estrecho, trae un cable con entradas en ángulo que favorece la colocación.


El cable que compré esta pensado para su uso en una caja externa y es muy grande y gordo, así que la primera intención fue pedir por Amazon un posible cable adaptador, pero con la alerta, no me llegaría hasta no se sabe que día, así que anulé el pedido y me armé de cuchillo y tornillo y decidí hacerle una entrada al pi-topCEED. No ha quedado muy bonito, por que no tenía las herramientas necesarias, pero es la parte de atrás y no se ve, y es solo un recorte de plástico.



Para verlo mejor, desde delante queda mejor. Si nos fijamos un poco, vemos que la conexión microHDMI está un poco forzada (véase flecha roja), pero no quería perforar más.


Lo más importante, FUNCIONA. La primera foto puesta en esta entrada es de hecho la configuración del Raspbian en el Raspi4, pero tengo más


no será por fotos...
No sé si tendré mucho tiempo para probarlo. El verdadero interés para este RaspberryPi 4, que ya presenta una cantidad de memoria suficiente para hacer muchas cosas para usuarios normales, además basado en un Debian que precisa pocos recursos, sería preparar un portátil barato y funcional. El problema es que el pi-top4 no está pensado como tal y no parece que lo vayan a hacer; el pi-top3 se puede adaptar, pero de manera algo complicada y el precio hace que con ese dinero te puedas comprar un portátil básico pero funcional. Veremos que depara el futuro al raspberry.

domingo, 29 de marzo de 2020

Puertos para el intercambio de pares. ed2k y el paso del tiempo



Sí, a mi me ha gustado siempre el intercambio de pares. Bueno, siempre no, solo desde que nació, sobre el año 2000, y nos permitió intercambiar material sin depender del protocolo ftp que usábamos antes, en descargas accidentales en fragmentos de 49MB, simplemente para descubrir que te faltaba uno y todo el tiempo usado —modems de 32kbps, con suerte 4Kb/s— no había servido para nada; sí, batallitas de los viejos. Personalmente, mi favorito por aquel entonces era overnet, ya que incluía intercambio descentralizado basado ya en kademlia y no eras esclavo de servidores que a veces desaparecían; vamos, igual que ahora, por ejemplo, este enero pasado. Bien, desde hace mucho mucho tiempo, desde que se pudieron controlar, tenía configurados los puertos siempre de la misma manera, controlados por el cortafuegos y el router. Ahora que no los voy a usar digamos que eran TCP 5521 y 5524 y UDP 4242 y siempre habían funcionado de maravilla y seguía lo de no cambies lo que funciona. Sin embargo desde hace un tiempo, yo me he dado cuenta desde este enero, los servidores no aceptan estos puertos y el intercambio era fundamentalmente por kademlia, y no alcanzaba las prestaciones que tenía antes. En un momento libre, de esos que tenemos ahora en nuestro confinamiento, he probado diferentes variaciones y siguiendo algunas recomendaciones que he visto en la red, los he elegido en la banda que va desde 60000 a 65000, y sí, todo ha vuelto a la normalidad. Para antiguos como yo que siguen las costumbres antiguas, a veces hay que revisarlas y mejorarlas. Habrá que cambiar los puertos dedicados al ed2k a superiores a 60000.

PD. ¿Qué cliente ed2k uso ahora? Después de muchos años de usar amule, debido al uso salvaje que hace de la memoria RAM, estoy usando el emule habitual a través de WINE, y va de fábula; bueno, ahora que he cambiado los puertos.

$ wine '/ruta/hasta/emule.exe'

y listo.

PDD. No, no insistáis. No me gusta el torrent. No tengo nada más que decir