bash-4.2# curl -O https://dlm.mariadb.com/4787586/Connectors/java/connector-java-3.5.10/mariadb-java-client-3.5.10.jar
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0

bash-4.2# ls
mariadb-java-client-3.5.10.jar  startup.sh

Descarga las versiones de Maven que necesites

Ve a la web oficial de Apache Maven y descarga los archivos .tar.gz (Binary tar.gz archive) de las versiones que quieras. Por ejemplo, supongamos que descargas Maven 3.9.6 y Maven 4.0.0. (o las que necesites!)

Crea un directorio en /opt para organizarlos y descomprime los archivos allí:

# Crear el directorio contenedor
sudo mkdir -p /opt/maven

# Descomprimir la versión 3.9.6 (ajusta el nombre del archivo si descargaste otra)
sudo tar -xvf apache-maven-3.9.6-bin.tar.gz -C /opt/maven/

# Descomprimir la versión 4.0.0
sudo tar -xvf apache-maven-4.0.0-bin.tar.gz -C /opt/maven/

Para que sea más fácil de identificar, deberías tener dos carpetas en /opt/maven/: apache-maven-3.9.6 y apache-maven-4.0.0.

Registrar las versiones en alternatives

Como lo hemos instalado a mano, Fedora aún no sabe que existen. Tenemos que «presentarle» estas versiones al sistema de alternativas usando el comando --install.

El formato es: alternatives --install <enlace_simbólico_global> <nombre_del_grupo> <ruta_al_binario_real> <prioridad>

Ejecuta estos dos comandos para registrar ambas versiones:

# Registrar Maven 3.9
sudo alternatives --install /usr/bin/mvn mvn /opt/maven/apache-maven-3.9.6/bin/mvn 39

# Registrar Maven 4.0
sudo alternatives --install /usr/bin/mvn mvn /opt/maven/apache-maven-4.0.0/bin/mvn 40

¿Qué significan los números del final? Es la prioridad. El número más alto se convierte en la versión por defecto automáticamente tras el registro, pero no te preocupes, ahora la cambiaremos a tu gusto.

3. Cambiar entre versiones de Maven

Ahora que el sistema ya las conoce, puedes usar el menú interactivo igual que hiciste con Java:

sudo alternatives --config mvn

Te aparecerá una lista con las versiones de Maven que acabas de registrar:

Existencias de 2 programas que proporcionan 'mvn'.

  Selección    Comando
-----------------------------------------------
*+ 1           /opt/maven/apache-maven-4.0.0/bin/mvn
   2           /opt/maven/apache-maven-3.9.6/bin/mvn

Presione Intro para mantener la selección actual[+], o escriba el número de selección:

Selecciona el número de la versión que quieras usar y presiona Enter.

4. Verificar que funciona

Para comprobar que el enlace se ha actualizado correctamente, pide la versión de Maven en tu terminal:

mvn -v

Verás que en las líneas de configuración no solo cambia la versión de Maven, sino que también detecta automáticamente la versión de la JDK (Java version) que tengas activa en ese momento con el comando alternatives java. ¡Un combo perfecto!

Instalar Rust

En cualquier Linux:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

O, en fedora:

sudo dnf install -y rust cargo

Instalar Rust en cualquier Linux:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Esto entre otras cosas te instalará cargo. Cargo: la herramienta de Rust para compilar y gestionar paquetes. Cuando instalas Rustup también obtienes la última versión estable de la herramienta de compilación y gestión de paquetes de Rust, conocida como Cargo. Cargo hace un montón de cosas:

• construye tu proyecto con cargo build
• ejecuta tu proyecto con cargo run
• ejecuta los tests de tu proyecto con cargo test
• genera la documentación de tu proyecto con cargo doc
• publica una biblioteca en crates.io con cargo publish

Construir Hola Mundo

Vamos a ver fácil como crear, compilar y ejecutar Hola Mundo:

cargo new hello-world
cd hello-world

si miramos src/main.rs:

fn main() {
 println!("Hello, world!");
}

Ejecutamos y listo:

$ cargo run
 Compiling hello-world v0.1.0 (/home/slimbook/proyectos/Formacion/101-rust/hello-world)
 Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.23s
 Running `target/debug/hello-world`
Hello, world!

ENLACES
https://rust-lang.org/es/learn/get-started/

El problema es típico y sencillo de arreglar: Trabajar en Ubuntu y desarrollas en Java pero tienes proyectos que utilizan diferentes JDKs (o JREs). ¿Cómo arreglarlo de forma fácil? Primero vamos a suponer que tienes 3 versiones de la JDK, yo los he instalado con estos comandos:

sudo apt install -y openjdk-8-jdk-headless
sudo apt install -y openjdk-17-jdk-headless
sudo apt install -y openjdk-21-jdk-headless

Por defecto y de forma automática tendremos disponible la última versión.

$ java -version
openjdk version "21.0.10" 2026-01-20

$ javac -version
javac 21.0.10

¿Cómo cambiar la versión predeterminada?

Para cambiar la versión «seleccionada» por el sistema podemos usar el comando update-alternatives. Con el siguiente comando podemos ver todos los comandos referentes a java:

sudo update-alternatives --get-selections | grep java

Ejecuta los siguientes comandos y seleccionamos el número de la versión deseada (tanto para java y javac):

$ sudo update-alternatives --config java
There are 3 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-21-openjdk-amd64/bin/java      2111      auto mode
  1            /usr/lib/jvm/java-17-openjdk-amd64/bin/java      1711      manual mode
  2            /usr/lib/jvm/java-21-openjdk-amd64/bin/java      2111      manual mode
  3            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java   1081      manual mode

Press  to keep the current choice[*], or type selection number: 1
update-alternatives: using /usr/lib/jvm/java-17-openjdk-amd64/bin/java to provide /usr/bin/java (java) in manual mode

$ java -version
openjdk version "17.0.18" 2026-01-20
OpenJDK Runtime Environment (build 17.0.18+8-Ubuntu-124.04.1)
OpenJDK 64-Bit Server VM (build 17.0.18+8-Ubuntu-124.04.1, mixed mode, sharing)

$ sudo update-alternatives --config javac
There are 3 choices for the alternative javac (providing /usr/bin/javac).

  Selection    Path                                          Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-21-openjdk-amd64/bin/javac   2111      auto mode
  1            /usr/lib/jvm/java-17-openjdk-amd64/bin/javac   1711      manual mode
  2            /usr/lib/jvm/java-21-openjdk-amd64/bin/javac   2111      manual mode
  3            /usr/lib/jvm/java-8-openjdk-amd64/bin/javac    1081      manual mode

Press  to keep the current choice[*], or type selection number: 1
update-alternatives: using /usr/lib/jvm/java-17-openjdk-amd64/bin/javac to provide /usr/bin/javac (javac) in manual mode

$ javac -version
javac 17.0.18

Y ya está, hay más formas como usar jEnv o SDKMAN, pero eso lo dejo para otra entrada.

¡Espero que sea de ayuda!

Con TNS adhoc:

sqlplus user/pass@"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myhostname)(PORT=1530))(CONNECT_DATA=(SERVICE_NAME=serviceName)))"

O usando el formato easy connect:

sqlplus user/pass@myhostname:1530/serviceName

No todo es siempre un IDE, a veces, la base de todo está en la consola. En python existe el concepto de «entorno virtual» esto es que para un proyecto dado guarda las bibliotecas o paquetes necesarios para este proyecto. La idea es similar a quien conozca npm de Node.js.

La cosa es que en python con pip podemos instalar paquete usando:

pip install <nombre_paquete>

Pero por defecto python lo instala de forma global para el interprete de python (en la carpeta lib donde tengas instalado python). Entonces: ¿Qué pasa si en un proyecto necesito Pandas 2.3 y en otro 1.4 y en el interprete global tengo instalado Pandas 2.2. Pues por defecto se usará la versión 2.2, para evitar estos problemas, existe venv.

venv

venv nos permite crear un proyecto python dentro de un «entorno virutal» (similar a la idea del chroot de unix). Lo que hace es crear un entorno de desarrollo/ejecución que está relativo a nuestra carpeta de trabajo y no usa ni guarda nada en la carpeta global de python: Instala el interprete y todas las dependencias que usemos en una subcarpeta de nuestro proyecto.

De este modo nuestro proyecto siempre será independiente de la instalación global de python. Todo gracias a la idea del virtualenv.

Paso 1: Prepara el Terreno (Instala virtualenv)

Primero, asegúrate de tener Python instalado en tu sistema. Si no lo tienes, descargalo desde: https://www.python.org/downloads/

python -v
sudo apt install -y python3 python3-pip

Una vez que tengas Python, abre tu terminal o línea de comandos. Vamos a instalar virtualenv (si no lo tienes ya):

pip install virtualenv

Paso 2: Crea tu Carpeta de Proyecto

Ahora toca crear una carpeta para nuestro nuevo proyecto. Puede llamarse como quieras. En este ejemplo, la llamaremos mi_primer_proyecto.

mkdir mi_primer_proyecto
cd mi_primer_proyecto

Paso 3: Crear el Entorno Virtual

Una vez que estamos dentro de la carpeta del proyecto podemos crear nuestro entorno virtual. Dentro de la carpeta mi_primer_proyecto, vamos a crear nuestro entorno virtual. Puedes llamarlo venv (es una convención común).

virtualenv .venv

Verás que se crea una carpeta llamada .venv dentro de tu proyecto. Ese el «entorno virtual» donde tenemos un interprete de python y las librerías de python del proyecto para que no colisionen con las del sistema. En concreto tiene esta forma (en Windows):

MI_PROYECTO_NUEVO
|   
\---.venv
    |   .gitignore
    |   CACHEDIR.TAG
    |   pyvenv.cfg
    |   
    +---Lib
    |   \---site-packages
    |       |   pip-25.3.virtualenv
    |       |   _virtualenv.pth
    |       |   _virtualenv.py
    |       |   
    |       +---pip
    ...
    |                                   
    \---Scripts
            activate
            activate.bat
            activate.fish
            activate.nu
            activate.ps1
            activate_this.py
            deactivate.bat
            pip-3.14.exe
            pip.exe
            pip3.14.exe
            pip3.exe
            pydoc.bat
            python.exe
            python3
            python3.exe
            pythonw.exe
            venvlauncher.exe
            

Paso 4: Activa tu Entorno Virtual

Para empezar a usar tu entorno virtual, tienes que «activarlo». Los comandos varían un poco según tu sistema operativo:

En Windows:
.\.venv\Scripts\activate.bat

En Linux:
source .venv/bin/activate

** En Linux es importante usar «source» porque no queremos ejecutar un script queremos ejecutar unos comandos que afecten al shell actual

Una vez activado, al principio del prompt del shell veremos (venv), esto indica que estamos dentro de un entorno virtual. Cualquier librería que instalemos ahora se quedará dentro de esta «burbuja».

Paso 5: Programar

Ahora que tenemos nuestro entorno listo por fin estamos en condiciones de empezar a programar e instalar tantas dependencias como necesitemos. Vamos a crear un pequeño script de Python. Crea un archivo llamado main.py (o como quieras) dentro de tu carpeta mi_primer_proyecto. Puedes usar un editor de texto simple para esto, o el que prefieras..

#!/usr/bin/env python

def saludar(nombre):
    print(f"¡Hola, {nombre}! Este es tu primer proyecto en Python.")

if __name__ == '__main__':
    saludar("Programador")

Podemos ejecutarlo así:

python main.py

Deberías ver el saludo en tu consola.

Por cierto, ahora mismo podemos abrir el proyecto en un IDE como pycharm y empezar a usarlo (por ejemplo) y nos reconoce todo el trabajo, en la siguiente imagen se puede ver:

Extra: Guardar y recuperar las dependencias (paquetes pip)

Como un un entorno virtual tiene sus propios paquetes en la carpeta .venv es importante al compartir código tener un catalogo de los paquetes usados para que nuevos usuarios/desarrolladores utilicen las mismas versiones. Para ello podemos hacer:

pip3 freeze -l > requirements.txt

Genera un fichero así:

certifi==2025.8.3
charset-normalizer==3.4.3
colorama==0.4.6
colorlog==6.9.0
docopt==0.6.2
idna==3.10
pipreqs==0.4.13
PyYAML==6.0.2
requests==2.32.5
urllib3==2.5.0
xlwt==1.3.0
yarg==0.1.10

Y para instalar estos paquetes una vez se ha copiado alguien el proyecto o clonado desde git, hacemos:

pip3 install -r requirements.txt -v

¡Espero que haya sido de ayuda! ¡Adiós!

¿Qué pasa si queremos modificar la fecha de modo:

(Get-ChildItem -Path informe.docx).LastWriteTime='2023-05-20 08:30:00'

Corregir esto en git es muy sencillo, teniendo en cuenta dos escenarios diferentes:

1. Cambiar el autor del último commit
2. Cambiar el autor de uno o varios commits más atrás del HEAD

Corregir el autor en el ultimo commit

Si el error está solo en el commit más reciente, es muy sencillo. Usaremos el comando –amend (modificar):

git commit --amend --author="Jose PEREZ MARTINEZ <miemail@midominio.com>"

Una vez hecho esto, ya hemos corregido el autor del último commit, pero, esa cambio está en nuestro repositorio local. Si queremos actualizar este commit en nuestro repositorio remoto y compartir el cambio necesitamos hacer esto:

git push --force

Corregir el autor en uno o varios commits antiguos

Si necesitas corregir el autor en varios commits que ya están en el historial, la herramienta a usar es git rebase -i (rebase interactivo). Este paso es más «complicado» que el anterior, porqué implica usar un editor para modificar la metainformación de los commits e indicarle a git que queremos hacer para cada commit, pero vamos paso a paso.

Lo primero, necesitamos saber qué commit queremos modificar o si son varios en lote, saber cual es el punto de inicio en el historial. Pero, ¿qué siginifica saber qué commit es? Pues buscar el identificador que usa git, que se llama código Hash. Este código es una cadena alfanumérica que tiene un formato más largo y otro más corte y es único (puedes leer más en esta entrada: Git Hash Commit, identificando commits)

Supongamos que has consultado el historial de git y el hash de tu commit base es 70aeebd, entonces ejecutar el siguiente comando:

git rebase -i -p 70aeebd

Se abrirá el editor por defecto que tengas configurado en git (si no lo has configurado, pues puede ser vi, vim, emacs, notepad, …. depende de tu sistema). En mi caso, por ejemplo tendrá un pinta como esto:

pick 2231360 some old commit
pick ee2adc2 Adds new feature


# Rebase 2cf755d..ee2adc2 onto 2cf755d (9 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit

En el archivo que se abre, verás una línea para cada commit que se va a procesar, comenzando con la palabra pick. Cambia la palabra pick por edit (o e) en cada commit al que quieras cambiarle el autor. Guarda y cierra el archivo. Git comenzará el proceso, pausándose en el primer commit marcado.

Cuando git encuentra una linea marcada para editar, para y ejecuta el comando git commit --amend. Una vez termine, debemos cerrar la sesión del rebase para continuar y enviar los cambios al servidor, ejecutamos:

git rebase --continue

Puede que tengas que repetir este paso alguna vez, según lo que necesite hacer git durante el proceso.

Al finalizar, debes hacer push:

git push --force

Con esto habriamos actualizado el autor en los commits que nos es necesario.

REFERENCIAS

• git rebase (en atlassian.com) [visto en oct 2025]

• Es una cadena de caracteres generada con el algoritmo SHA-1.
• Representa de forma única el contenido del commit (incluyendo archivos, autor, fecha, mensaje, etc.).
• Sirve para referenciar ese commit en el historial.

Por ejemplo, un hash «largo» tiene la forma: e3a1b2c4d5f67890123456789abcdef123456789.

¿Qué es un hash largo y un hash corto?

Ambos identifican el mismo commit, pero el corto es más práctico para usarlo normalmente. Git se asegura de que el hash corto sea único dentro del repositorio, así que no hay problema en usarlo mientras no haya colisiones.

Para poder ver estos código hash accedemos al log de git y en función de las opciones que usemos nos mostrará una version larga o corta del hash. Con los comandos

1. Para ver el hash corto:

   git log --oneline
   

2. Para ver el hash largo:

   git log
   

Espero que haya sido útil la lectura, ¡adiós!

Solución

Hay que ajustar la sensibilidad del ratón, por defecto DosBox la pone al 100%. Podemos poner un valor entre 0 y 100. En mi caso probé a bajarlo al 50% y me lo solucionó.

En el fichero dosbox.conf editar la secciçon [sdl] y modificar sensitivity, su valor por defeto es 100 bajaro a 50:

sensitivity=50

Para más información consultar [1]. (esto no lo he probado pero lo dejo aquí anotado por si es de ayuda) Otras opciones serían ajustar en tiempo real DosBox usando shortcuts de teclado. Presiona:

• Ctrl + F10 → captura/libera el ratón.
• Ctrl + F11 / Ctrl + F12 → bajan o suben la velocidad de emulación (afecta todo, no solo el ratón).
• Ctrl + F8 / Ctrl + F7 (según versión) → pueden ajustar la sensibilidad del mouse directamente.

¡Espero haber sido de ayuda!

REFERENCIAS

1. Configuración del SQL en DosBox