Ayer 25/9/2017 se publicó High Sierra (es decir, macOS 10.13).
Obviamente, como un buen fanboy y un adoptador de toda la vida, me apresuré a instalarlo; primero probé con la computadora portátil (una MacBook Pro "early" 2011 con 16 GB de RAM y SSD Crucial MX300 de 525 GB), además del largo tiempo de instalación, se debe decir que APFS hace su trabajo, y ...
"todo es mucho más reactivo"
Sin saber cómo probar el nuevo sistema de archivos sobre la marcha, pensé en duplicar una máquina virtual en la que instalé la distribución Linux CentOS: 5.95 GB duplicados en un abrir y cerrar de ojos; comprobando el espacio ocupado en el disco no parecía haber diferencias, e incluso moviendo el archivo copiado a la papelera y vaciándolo no noté grandes diferencias en el espacio del disco duro.
Y ahora pasemos al punto delicado: ¡APFS no parece ser compatible con Fusion Drive de terceros!
Leyendo la nota técnica oficial de Apple, parece que en el proceso de instalación Fusion Drive no se convierte al nuevo sistema de archivos, y hasta ahora estamos, también porque lo sabemos bien, a partir de notas técnicas difundidas por Apple y pruebas realizadas por varios entusiastas , que APFS no es compatible con Fusion Drive; Es por eso que incluso los Mac con Fusion Drive de Apple no podrán usar (por el momento) el nuevo sistema de archivos.
El problema surge con la fusión Drive "tercero", es decir, la unidad de fusión creado casero con el terminales (o más bien, la shell) utilizando una memoria de estado sólido (típicamente un SSD) añadido de alguna manera a la configuración de hardware de un Mac.
Por ejemplo, puede extraer la unidad óptica de la iMac (hasta que tuvimos que) e instalar en su lugar un SSD, a continuación, proceder a la "fusión" y obtener el motor de fusión agradable y dispuesto sin tener que vender el riñón habitual para pagar el oficial apple.
Esta mañana, al tratar de instalar High Siera en la computadora que uso en el trabajo, no tuve éxito y la instalación fue bloqueada en algún momento con el mensaje de que no era posible actualizar el firmware de la máquina.
Esto me ha hecho sospechar algo, y procedí a instalarlo en otro iMac (la misma serie del primero), con disco duro y eso es todo: funcionó de repente (después de los habituales cuarenta minutos de espera).
La cosa se volvió intrigante. Dupliqué la aplicación que instala el nuevo sistema, lo exhibí como un paquete y comencé a hurgar en las carpetas.
Encontré casi de inmediato, ubicado entre varias subcarpetas, el "InstallESD.dmg", intenté montarlo e instalar el paquete, pero me dijo que no podía instalarlo solo.
Me rindo y vuelvo a hurgar hasta encontrar un script para actualizar el firmware, intento duplicarlo en el escritorio y lanzarlo. A primera vista, el terminal presenta una serie de errores, un par de hits en la terminal y el script se inicia correctamente pero termina dándome un mensaje de error y señalándole que no podría instalarse en ese ID de placa (un número que identifica la configuración exacta del tarjeta lógica principal presente en su computadora) ...
Está bien, me voy a casa y ver el MacMinis y pensar: "Ahora le toca a usted, desde su 16 GB de RAM, su fusión impulsa 1,2TB, no fallan, no se puede fallar, no falla!"; afortunadamente las computadoras no hablan ...
Incluso este intento falló, con el mensaje de error de que la actualización del firmware no fue exitosa.
Comencé a reflexionar sobre por qué, no había intentado ejecutar los scripts o el instalador en el Macmini como lo había hecho en el iMac, pero estaba bastante seguro de que habría obtenido resultados superpuestos.
Por lo tanto, APFS se actualiza "sobre la marcha" durante la instalación del nuevo sistema operativo, para una operación tan pesada es apropiado que el volumen no esté montado en el sistema de archivos, la única forma de actualizar un disco de esa manera es comenzando desde una partición de ... ¡RECUPERACIÓN!
¡Aquí está la clave! En la práctica, en unidades de fusión (tanto de Apple como de terceros) no es posible crear la partición de recuperación y, por lo tanto, no es posible arrancar el sistema desde una partición que no sea la que estamos actualizando. Si comenzamos con la partición que se actualizará, ciertamente no podemos hacer ese cambio.
Todo aquí: ¡partición de recuperación estúpida!
Si tiene alguna otra idea, ¡sea bienvenido en los comentarios!
Una cosa más (cit.):
"Todo es más receptivo" es una frase que contamos en el grupo de noticias it.comp.macintosh, cuando instalamos o actualizamos el sistema operativo; en ese momento no existía el iPhone, teníamos Sony Ericcsson, por lo que solo se actualizó macOS.
Al final, solo sirvió para consolarnos que de las "más de 200 nuevas características" prometidas por Apple, vimos menos de una décima ... ¡buenos momentos!
¡Eso es todo! Estad atentos!
Martes 07/11/2017 hubo la reunión (ahora) habitual del grupo wpbari, y estaba presente Andrea Gandino (link de Twitter) por Evolve, que presentó el tema desarrollado por su empresa: Fenix, dentro del tema de la charla "Cercarsele con il lanternino"; en la práctica, cómo complicar la vida creando temas y complementos para WordPress.
(más…)
Como de costumbre: sí, pero ¿por qué?
Existen varios motivos por los cuales podría necesitar insertar otras tablas en el DB de mi instalación de WP; El primer ejemplo que me viene a la mente es que en el mismo espacio tengo otra aplicación web instalada.
<! - más -> Por ejemplo, puedo tener el sitio en WordPress para mi asociación / empresa / etc., y una gestión de las cuentas que haya instalado (Dolibarr es una gran opción en mi opinión).
¿Y por qué no usar una base de datos separada para cada aplicación web?
De hecho, sería mejor, bajo algunos puntos de vista, pero también hay que considerar que hay algunos complementos que le permiten hacer una copia de seguridad de los archivos y la base de datos de WP.
Por ejemplo, utilizo UpdraftPlus de forma rentable en la versión gratuita; más allá de las personalizaciones permitidas por la versión premium (pagada), la versión gratuita permite la copia de seguridad de WordPress DB cargándola en una cuenta de Dropbox.
Y este es el truco: si las tablas de la administración las pongo en el DB donde residen las tablas de WP, lo entiendo, ¡con cada copia de seguridad, el complemento copiará todo en el destino elegido!
Una cosa más </ em> (cit.):
Supuse que la otra aplicación web está instalada en un subdirectorio de la instalación principal de WP, de lo contrario los archivos relativos no se incluirán en la copia de seguridad del complemento.
¡Eso es todo! ¡Estén atentos!
Sí, pero ¿por qué?
Al preparar este sitio, decidí preparar un sitio de prueba para experimentos, dejando intacto el sitio de producción hasta que se encontró la estructura deseada.
La operación en sí es bastante simple, se trata de copiar el contenido de la instalación de wordpress a otro dominio, crear una base de datos y mover todos los datos de uno a otro.
Quiero aclarar que lo que voy a escribir está dirigido a los usuarios avanzados / sysadmin que saben cómo completar las operaciones descritas; Si no sabe qué y cómo lo está haciendo, el consejo es contactar a una persona que tenga las habilidades y el conocimiento para hacer lo que sea necesario.
Para mi conveniencia, prefiero crear un dominio de tercer nivel (por ejemplo, test.foo.org en comparación con foo.org) para aprovechar el espacio y la banda ya pagados por el cliente; una vez equipado con cualquier cliente FTP, comencemos:
// ** Configuración de MySQL: puede obtener esta información de su proveedor de alojamiento ** //
/** El nombre de la base de datos de WordPress */
define('DB_NAME', 'nombre_db');
/** Nombre de usuario de la base de datos MySQL */
define('DB_USER', 'usuario_db');
/** Contraseña de la base de datos MySQL */
define('DB_PASSWORD', 'contraseña_db');
/** Nombre de host MySQL */
define('DB_HOST', 'localhost');
/** Juego de caracteres de base de datos para usar en la creación de tablas */
define('DB_CHARSET', 'utf8');
/**El tipo de intercalación de la base de datos. No cambies si no tienes idea de lo que es */
define('DB_COLLATE', '');
Dicho, hecho, nuestro sitio de prueba debe estar en línea, en caso de que un wordpress continúe apuntando al sitio de producción y no al sitio de prueba, es útil restablecer el caché del navegador, volver a cargar la página y asegurarse de que en la barra de direcciones del navegador puede ver la dirección test.foo.org y no foo.org
Una cosa más (cit.):
¡Recuerda el enlace permanente! Después de haber llevado a cabo estos cambios, los enlaces permanentes también deben reconstruirse, el método más simple es ir a la máscara admin / modify permalink (test.foo.org/wp-admin/options-permalink.php para permanecer en la primera nomenclatura) y elige cambiar la estructura. En caso de que deseemos volver a la seleccionada anteriormente, recreamos y volvemos.
¡Eso es todo! Estad atentos!