Sejak beberapa waktu yang lalu Excellent membuat sebuah project kecil. Setelah projectnya jadi, secara bertahap diujicoba dan disimulasikan. Sudah cukup baik tapi saya merasa kok tampilannya tidak smooth.

Saat diakses, loadingnya agak lambat dan tampilannya seperti tersendat. Padahal itu hanya satu halaman web saja. Saya coba menggunakan browser mobile juga sama saja. Padahal saya membayangkan, saat diketik alamat URL kemudian tekan ENTER, blitz… langsung tampil. Kan saya tekan ENTER, bukan ENTAR. Kalau ENTAR kemudian tampilannya lama sih ya maklum

Saya bilang pada team, saya nggak puas kalau performanya seperti itu. Apakah bisa dicheck nyangkutnya dimana. Apakah bisa diperbaiki? Mereka bilang, “Bisa dong, kan itu memang belum rilis. Masih fase ujicoba jadi memang belum dapat improvement apa-apa karena fokusnya baru ke fungsinya”

Salah seorang team, mas Arif Rahman mereferensikan halaman GTMetrix.

Saat dicoba validasi disana, hasilnya adalah screenshot pertama.

Nilainya F. FARAH.

Performanya 0%. Loading time 11.3 s dan total page size 6.41 MB. Di bagian bawahnya ada detail apa saja yang menyebabkan score seperti itu termasuk solusi perbaikannya.

Beberapa yang mencolok misalnya tidak pakai cache. Kemudian penggunaan image yang tidak efisien dan ukurannya terlalu besar dibandingkan dengan format yang ditampilkan. Misalnya ingin menampilkan icon tapi ukuran gambar yang diupload malah ukuran gambar yang besar.

Secara bertahap hal tersebut diperbaiki, sampai kemudian waktu loading jauh lebih singkat. Memang score-nya masih belum mencapai nilai A dan nilai YSlow score masih parah, tapi minimal sudah dapat insights mengenai sumber masalah dan tindakan perbaikan yang bisa dilakukan.

Dari awalnya loading sekitar 11.3 s turun menjadi dibawah 5 s. Page size juga drop dari 6.41 MB menjadi 1.16 MB. Cukup lumayan meski masih banyak ruang untuk diimprove lagi.

Selain GTMetrix, ada juga Google Pagespeed Insights : https://developers.google.com/speed/pagespeed/insights/

Ini juga bisa dijadikan sebagai acuan untuk mengetahui sumber masalah dan solusi perbaikannya.

Ada solusi lain yang bisa ditempuh, misalnya menggunakan CDN untuk tambahan lapisan keamanan dan peningkatan kecepatan, namun 2 website diatas bisa dijadikan sebagai titik awal karena layanannya gratis dan saat kita baru memulai hal baru tanpa pendapatan, kita bisa cukup puas dengan yang free namun memberikan nilai manfaat yang besar.

Saat saya ujicoba ke website lain baik website personal maupun website Excellent, hasilnya banyak yang parah, hehehe… Jadi ada tambahan kegiatan nih selama WFH.

Veamos cómo podemos hacer una captura de pantalla de una terminal sin servidor gráfico o TTY

Captura de una TTY sin servidor gráfico (pincha para ampliar)

A los Linuxeros y Linuxeras nos gusta mucho mostrar nuestros escritorios. Somo muy dados a compartir capturas de pantalla de nuestros sistemas GNU/Linux, con nuestro mejor fondo de pantalla, combinación de iconos, tema de escritorio y demás personalizaciones.

Para muestra un botón de las capturas de pantalla que compartimos en Mastodon bajo la etiqueta #unixporn:

• https://victorhck.gitlab.io/unixporn/

Y para realizar dichas capturas de pantalla tenemos aplicaciones muy completas como Spectacle, Flameshot, scrot por nombrar algunas opciones…

Pero ¿cómo hacer una captura de pantalla de una terminal (no un emulador de terminal) TTY sin entorno gráfico? Hace poco me encontré en esa situación y ninguna de esas opciones me sirvió. Todas necesitan un servidor gráfico corriendo para poder ejecutarse.

Al final di con una solución que lo que hace es “convertir” el framebuffer en una imagen .png. La aplicación se llama Fbcat que tiene una aplicación llamada fbcat y fbgrab, que es la que realmente me interesa.

Buscando, la primera opción que me dieron fue fbgrab, pero no estaba empaquetada para openSUSE en su versión más reciente, así que después de 2 días conseguí empaquetarla en la versión 1.3.3 disponible en mi repositorio local.

Después de haberme pasado 2 días intentando empaquetarla, hasta que lo conseguí, cuando la instalo y la pruebo veo que no funciona, ya que sí guarda la imagen, pero queda distorsionada y no se ve nada y no sé el motivo…

Sigo buscando opciones y me encuentro con fbcat, que contiene tanto fbcat como fbgrab y está disponible para Debian y derivadas y para openSUSE.

La instalo desde los repositorios y eureka! esta sí funciona correctamente. Con esta herramienta puedo estar trabajando en una TTY o una terminal sin servidor gráfico funcionando y poder hacer una captura de pantalla de la terminal en una imagen .png (tal como se ve en la imagen que abre el artículo)

Además desde tu sesión gráfica (normalmente la 7) puedes capturar cualquier TTY que tengas, sin necesidad de ir a esa sesión, y correr el comando desde allí. Pero veamos en detalle los parámetros.

Nos dirigimos a una TTY (normalmente puedes ir a una mediante la combinación de teclas Ctrl+Alt+F1 y regresar a tu sesión gráfica con Ctrl+Alt+F7) y nos logueamos.

En esa TTY, no tenemos un servidor gráfico, eso no es un emulador de terminal, es una terminal pura y dura, donde correr comandos y ejecutar aplicaciones que no requieran un servidor gráfico, como por ejemplo: moc para escuchar música, neomutt para el correo, podboat para leer canales RSS, etc…

Si por algún motivo queremos hacer una captura de esa terminal, es ahora cuando fbgrab nos viene a solucionar el problema. Ejecutamos:

sudo fbgrab captura.png

No podemos ver la captura en esa sesión, pero regresando a nuestra sesión gráfica (Ctrl+Alt+F7 ¿recuerdas?) podremos abrirla con nuestro visor de imágenes preferido y ver la captura.

Podemos desde esta sesión gráfica hacer una captura de la TTY, para ello ejecutamos uno de estos dos comandos:

sudo fbgrab -c 1 captura.png
sudo fbgrab -C 1 captura.png

Ambos son similares, pero el de la C mayúscula tarda un poco más para poder hacer una captura buena en framebuffers más lentos. Y 1 si queremos la TTY 1, si queremos otra, pondremos el número que queramos…

También tenemos la opción de poder retrasar la captura unos segundos mediante la opción -s

Así que pude solucionar mi inquietud y pude hacer una captura de pantalla de una terminal de Linux sin servidor gráfico corriendo.

Esto también puede ser útil si estamos “cacharreando” en una Raspberry Pi en la que no tenemos servidor gráfico y queremos hacer una captura por algún motivo.

Como siempre digo, espero que quizás esta sea la respuesta que estabas buscando si también a ti te ha surgido esta inquietud o este “problema”. Utiliza los comentarios del blog para dejar información…

First we will need to populate the conainer 
with an openSUSE base system.
TARGETDIR=$HOME/OBS_CONTAINER/OBSCONTAINER/
SOURCEREPODIR=/etc/zypp/repos.d/
#lazily copy existing *.repos
for f in *.repo
do
sudo cp $SOURCEREPODIR$f $TARGETDIR/$SOURCEREPODIR
done
cd $TARGETDIR
sudo mkdir -p sys proc dev
sudo mount -t proc proc proc/
sudo mount -o bind /sys sys/
sudo mount -o bind /dev dev/
sudo zypper --no-gpg-checks --non-interactive --cache-dir /var/cache/zypp --root $TARGETDIR in --allow-unsigned-rpm --auto-agree-with-licenses filesystem bash permissions coreutils bash-completion cpio coreutils glibc permissions systemd systemd-rpm-macros systemd-presets-branding-openSUSE rpm zypper nano system-group-wheel system-group-hardware system-user-bin system-user-root system-user-nobody sudo systemd-network yast2-network NetworkManager nmcli-dmenu mariadb systemd-container obs-service-obs_scm obs-service-tar_scm

Okay so far so good. The base system is already bootable via nspawn.
We need some set-up of the system before we do it though:
sudo chroot $TARGETDIR /usr/bin/bash -c "systemd-machine-id-setup"
sudo chroot $TARGETDIR /usr/bin/bash -c "ln -sf /etc/machine-id /var/lib/dbus/machine-id"

Now it's time to install OBS itself
sudo zypper --cache-dir /var/cache/zypp --root $TARGETDIR ar https://download.opensuse.org/repositories/OBS:/Server:/Unstable/openSUSE_Factory/OBS:Server:Unstable.repo
sudo zypper --no-gpg-checks --non-interactive --cache-dir /var/cache/zypp --root $TARGETDIR in --allow-unsigned-rpm --replacefiles --auto-agree-with-licenses -t pattern OBS_Server
sudo zypper --no-gpg-checks --non-interactive --cache-dir /var/cache/zypp --root $TARGETDIR in --allow-unsigned-rpm --replacefiles --auto-agree-with-licenses obs-service-set_version obs-service-recompress 

We are now able to boot the systemd container and set-up OBS.
With the same commands you will be able to boot it in the future too.
RUNDIR=$HOME/OBS_CONTAINER/run
sudo systemd-nspawn -D $TARGETDIR -b --resolv-conf=bind-host --capability=all --property="DeviceAllow=/dev/loop-control rwm" --property="DeviceAllow=/dev/loop-* rwm" --property="DeviceAllow=block-loop rwm" --property="DeviceAllow=block-* rwm" --bind="$RUNDIR/obs/:/run/obs" --bind="$RUNDIR/passenger/:/run/passenger/" --bind="$RUNDIR/mysql/:/run/mysql/" --property="DeviceAllow=/dev/port rwm" --property="DeviceAllow=block-blkext rwm" --property="DeviceAllow=char-pts rwm" --property="DeviceAllow=/dev/null rwm" --property="DeviceAllow=/dev/zero rwm" --property="DeviceAllow=/dev/random rwm" --property="DeviceAllow=/dev/urandom rwm"

And since we have not set a root password, but one is expected,
we connect from a different console and start the setup.
Unless you want to customize ports/ip etc. you can leave 
everything at the default from setup-appliance.sh 
sudo machinectl --machine OBSCONTAINER shell
/usr/lib/obs/server/setup-appliance.sh --force #inside the machine

Hoy os invito a escuchar el podcast de abril de GNU/Linux València, otro audio más dentro del universo de de audios dedicado al mundo GNU/Linux como KDE España, Podcast Linux, Compilando Linux, Salmorejo Geek, SystemInside Podcast, Birras y Bits, Mancomun o el de NeoSiteLinux.

Podcast de abril de GNU/Linux València

En estos días de confinamiento el número de podcast de todo tipo de temática abundan, los relacionados con el Software Libre no es una excepción.

Hoy me complace compartir con vosotros el podcast de abril de GNU/Linux València dedicado a :

• Al próximo Ubuntu 20.04 que sale en apenas 3 días.

• Como puede cambiar nuestra privacidad como consecuencia de la pandemia del Covid-19.

• Como es la colaboración Google y Apple.

• Y una visión del estado de  Asociación GNU/Linux València.

Como siempre, os intento dejar aquí mismo el audio para que los podáis escuchar.

¿Qué es la Asociación GNU/Linux València?

En palabras de ellos mismos GNU/Linux Valencia, era un grupo que pretendía:

«…la difusión de GNU/Linux, para lo cual se pretende realizar reuniones mensuales, para realizar desde instalaciones de distribuciones GNU/Linux en equipos portátiles o de sobremesa, resolver problemas en el uso diario, y dar a conocer la facilidad de uso y funcionamiento de esta distribución de GNU/Linux.

Esta idea ha evolucionado hasta convertir el grupo en la Asociación GNU/Linux València, que sigue teniendo los mismos objetivos pero gana libertad de acción para organizar eventos, pedir locales e incluso ofrecer servidores libres para reuniones virtuales.

Su cuota de inscripción anual es de 20€ para personas físicas, y 40€ para empresas o personas jurídicas. Ambas cuotas tienen carácter anual y servirán para promocionar de forma más eficiente el Software Libre y mantener los gastos económicos que tiene constituirse como asociación (sí, aún siendo sin ánimo de lucro las asociaciones tienen gastos).

Para hacerte socio/a solo tienes que acceder a la pestaña ASOCIARSE, que puedes encontrar en el menú principal de su página web.

Más información: GNU/Linux València

The Corona (Corvid-19) virus has forced a lot of us to work from home. My preferred way of working, is by using openSUSE. Because my company has decided a while ago that Office365 and Microsoft Teams would be the default applications for collaboration, I am able to do so.

Installing Microsoft Teams Preview

The first thing to do is to go to the Microsoft Teams website to download the Teams software package.

Save the RPM file to your computer.

Now open the Dolphin file browser and either press F4 or click on: Control –> Panels –> Terminal.

Now install Teams by using the command:

sudo zypper install teams-versionnumber.x86_64.rpm

First enter your root password. When asked to confirm the installation, type ‘y’ and then press Enter.

After installation, type ‘Teams’ in your launcher to start the Microsoft Teams – Preview application.

You can login by entering your (work) e-mail address and your password and if needed the Two Factor Authentication approval.

My experience

Teams on Linux works very well. Video conferencing also works like a charm. It also works great with SharePoint (for accessing your Teams files), Outlook (for knowing when your next meeting starts), Word, Excel and PowerPoint. Everything works as you would expect.

The Word, Excel, PowerPoint versions are comparable with the browser versions of Office365. So the desktop apps still work a bit better. For instance when creating rich formatted Word documents or when creating visually impressive PowerPoint presentations. But I am able to do minor edits without a problem.

Conclusion

Microsoft Teams on Linux works just as well as the Windows version. And that is one of the biggest compliments that you can give to a Microsoft Office application. The only difference is that you cannot open files in the desktop versions of Word, Excel or PowerPoint. So now we wait for those to come to Linux as well!

Published on: 20 April 2020

We have to use Jupyter notebooks for Machine Learning at our university. Jupyter needs a lot of space on the hard disk and I was able to remember (from vocational school) that we were able to install PHPMyAdmin on a USB stick. You have a transportable web application on this way. I had this goal for Jupyter and the Python environment on Linux.

So I want to give you the installation guide for Jupyter on openSUSE Leap 15.1 (incl. Python) in a virtual environment.
Install the following packages as a foundation:

 sudo zypper install python3-pip python3-devel

After that install the virtual environment with pip3:

sudo pip3 install --upgrade pip
sudo pip3 install virtualenv

Create a project directory for Jupyter in your home directory and mount the external disk/ USB stick there:

sudo mkdir ~/Jupyter
sudo mount /dev/sda1 ~/Jupyter

You have to umount /dev/sda1, if the disk has been mounted automatically in /run/media/ (in my case):

sudo umount /run/media/user/TOSHIBA\ EXT/
sudo mount /dev/sda1 ~/Jupyter

If the external disk is mounted, you can create the virtual environment for Python and Jupyter in the special project directory:

virtualenv ~/Jupyter

Inside, it will install a local version of Python and a local version of pip. We can use this to install and configure an isolated Python environment for Jupyter.
Before we install Jupyter, we need to activate the virtual environment:

source ~/Jupyter/bin/activate

You are ready to install Jupyter into this virtual environment.
You can install Jupyter on the external disk with the following command:

pip install jupyterlab

Call Jupyter via command line inside of the project directory then:

jupyter notebook

That will open your web browser with http://localhost:8888/tree.
Do you need additional packages or Python libraries? You can install them in this project directory, too.
Change to this directory and install them with pip3 (in my case these ML packages):

pip3 install scipy numpy matplotlib sklearn pandas
pip3 install keras tensorflow

Enjoy Jupyter on an external disk.

Git es una gran herramienta para la gestión de control de versiones de software. Ahora con esta colección de scripts para Bash puedes expandir sus funcionalidades

Git es una herramienta creada por Linus Torvalds para el control de versiones del kernel Linux que libero para que cualquiera la pudiera utilizar.

Despues de 15 años, es una herramienta necesaria en cualquier proyecto de software. Pero que puede que en alguna situación necesites alguna utilidad extra para hacer esa herramienta mas potente y adaptarla a tus necesidades ahorrándote trabajo.

Para eso están una colección de scripts en Bash llamada git-extras y que esta disponible en un repositorio de GitHub.

Puedes consultar la forma de instalar la coleccion de scripts en tu sistema, ya que esta disponible para muchos sistemas GNU/Linux. Entre ellos openSUSE.

O si no quieres todos, puedes echar un vistazo a aquella funcionalidad que quieras y copiar el script en cuestión en tu equipo en una carpeta de tu $PATH y utilizarlo cuando lo prefieras.

Hay scripts, para crear automáticamente un archivo .gitignore, para ofrecer información de un repositorio, para ver el estado en el que se encuentra, para crear o renombrar ramas de desarrollo, borrar, mover, copiar…

Lo mejor es instalar el conjunto completo de scripts, pero en el siguiente ejemplo, veremos como copiar el script git-summary y ejecutarlo para ver la información que nos muestra de nuestro repositorio.

En el ejemplo descargo en script en una carpeta de Scripts, pero lo mejor es copiarlo a una carpeta de nuestro $PATH.

Si tienes alguna idea para otro script o quieres mejorar alguno existente, ya sabes que puedes contribuir con el código.

Here it is! Qactus v2.0.0 has been released
The main focus of this version has been on improving the browser.

New features:

• Improved UI: revamped toolbar, new action toolbars for projects, packages, files and build results, new side bar icons
• Bookmarks: first version for the watchlist
• New package actions: submit, copy, link and properties
• New project action: properties
• MetaConfigEditor (beta): now it is possible to edit a project/package properties such as general info, repository, repository flags, users and groups
• New search widget (Ctrl+F) for BuildLogViewer
• Showing outgoing and declined requests

Miscellaneous bugfixes and «hidden features»

Source code – RPM packages

En estos tiempos de reclusión en casa el ocio digital está llenando muchas horas de nuestros largos días, y por tanto es adecuado seguir presentando algunos juegos de la división más lúdica y divertida de KDE. Ya han pasado por este humilde blog un buen número de juegos de la división KDE Games como Kbounce, KSnakeDuel, KMahjongg,  Kmines,  KBreakout,  KTuberling, Granatier, KSudoku, KGoldrunner, Kolor Lines (o Klines), KBlocks, Bovo, Kapman, Knights, Palapeli, KSquares, KBlackbox o Kubrick. Hoy ha llegado el turno a Naval Battle, la versión digital del clásico juego de hundir los barcos que tanto hemos jugado.

Naval Battle, el juego de los barcos de KDE

Lo cierto es que este juego tiene varios nombres, parece ser que los desarrolladores no se han puesto de acuerdo con el nombre. Lo podemos encontrar como Naval Battle, kbattleship o, el nombre con el que se instala, knavalbattle.

El funcionamiento de este juego es sencillo, después de colocar nuestros barcos, se inicia un intercambio de disparos en el que buscamos hundir la armada rival.

Las opciones de personalización son muy interesantes ya que podemos:

• Jugar contra el PC.
• Seleccionar entre 3 niveles de dificultad.
• Jugar online.
• Activar o desactivar el sonido.
• Situar o no barcos adyacentes.

Estaría bien poder seleccionar el número de barcos y tipos con los que jugar, y poder seleccionar el tamaño del mapa.

El juego es una creación de Paolo Capriotti  <p.capriotti@gmail.com>, Nikolas Zimmermann  <wildfox@kde.org> y Daniel Molkentin  <molkentin@kde.org>, con un gran número de colaboradores.

Más información: KDE Games

Cómo instalar Naval Battle

Al ser un juego de la rama de KDE la  instalación de KSnakeDuel es sumamente sencilla. Básicamente debemos abrir una sesión de la consola y escribir:

En KDE Neon, Kubuntu y Linux Mint: $sudo apt install knavalbattle

En openSUSE: $sudo zypper install knavalbattle

En Mageia (gracias a Hurr) tenéis 3 opciones:

$ sudo dnf in knavalbattle

o
$ sudo dnf install knavalbattle

o
$ sudo urpmi knavalbattle

[… comenta y añadimos cómo se instala en tu distribución favorita]

Contents

Once most of the features that were planned for SUSE 15 SP2 and openSUSE 15.2 are ready, the team is shifting its focus to SP3 and 15.3. Of course, we are still polishing the releases around the corner, so in the summary of this sprint, you can find a mixture of bug fixes, small features, and preparation for the future work. These topics are:

• NCurses installation in old graphic chips
• Booting from Remote Encrypted devices
• Smarter network configuration in Linuxrc with the new try keyword
• Better support for auto-configured devices in S/390 systems
• Researching about how to improve XML YaST’s parser

Coming Back to Haunt Us: NCurses Installation and Old Graphics Chips

Some months ago (for Leap 15.1 / SLE-15 SP1), we started using fbiterm for all NCurses (text-based) installations. We had always used it for certain languages like Chinese, Japanese, Korean that need special support for their fonts, but since there were font-related problems even for other languages, we are now using it in all cases.

This fixed those font-related problems, but it turns out it brought back another issue that seemed long forgotten: poor performance in text mode for specific graphics chips.

Remember the Matrox G200? It was a good choice for Linux systems back years ago. Back many years ago; that GPU had its 20th anniversary in 2018, so it dates back to 1998 (that was when Windows 98 was new). Its graphics performance was… let’s call it quite okay for a budget card even back then.

Well, it turned out that it is still used today by some rack server manufacturers as on-board graphics. Most on-board graphics these days uses Intel GPUs (and they work great), but not all: some indeed use that old Matrox G200.

We had a business customer inquiring why screen redraws while installing their rack servers were so slow with SLE-15 SP1 compared to SLE-15 GA, and that’s the explanation: Those machines have that Matrox G200 on-board graphics, and it doesn’t seem to have the hardware acceleration that would be good to have for a framebuffer console. And with fbiterm you can now really see the difference.

In that setup, you can observe the NCurses library at work in slow motion: You can see how it partially removes text from the cursor position to the end of the line (leaving part of the screen black) and then redraws content from there. It’s not wrong or buggy, it’s just slow. Unbearably slow, like back then having a very slow (4800 baud) terminal connection (remember those?).

So our recommendation for that kind of hardware is: Better not use a framebuffer console. Just leave the machine in plain text mode with 80x25 with the nomodeset boot parameter, or do an SSH installation.

Those old ghosts keep coming back to haunt us, even from back in the very late MS-DOS days. :smile:

Improve Booting from Remote Encrypted Devices

But not all ghosts are that old. We also got the visit of the spirit of the past sprints. In one of our November posts, we explained you how we had addressed the existing problems booting from remote encrypted devices by adding the _netdev option to the fstab and crypttab files for all network-based file systems.

For some months, it looked like the definitive solution. But recently it was reported that, as much as that option indeed pleases systemd, it confuses dracut when it is used in the root file system. Although they say you cannot make everybody happy, we found that adding that option to all file systems except the root one actually seems to be the right solution for both systemd and dracut. The latter does not get confused anymore and turns out the root file system is the only one for which omitting the option is safe for systemd.

With all that, SLE-15-SP2 (and Leap 15.2) should exhibit a pretty solid behavior for all scenarios involving installation on top network disks, encrypted or not. For more technical details, you can check the corresponding pull request.

Let’s try ifcfg in Linuxrc

Linuxrc is a piece of software responsible for booting the installation media. It offers a friendly interface to set up some basic stuff (e.g., the language) and takes care of initializing the hardware and preparing all the stuff that YaST needs to do its magic.

Alternatively to the good looking interface, it provides a really powerful command line too. If you have not done it before, we recommend you to check the Linuxrc wiki page.

One of the things you can set up using the command line is the network, which is really handy when you want to do an installation from a network source.

ifcfg=eth*=192.168.0.2/24 install=http://192.168.0.1/iso

With these settings, Linuxrc configures the first device that matches the eth*. But what happens if you have multiple network interfaces? Is the configured interface the right one to reach the installation media?

To deal with these situations, we have added a try feature to the ifcfg option:

ifcfg=eth*=try,192.168.0.2/24 install=http://192.168.0.1/iso

In this case, Linuxrc tries to find the device which matches the pattern and makes the installation source reachable.

The try keyword works for static configurations as well as for DHCP. When used with DHCP the difference is that the DHCP setup is done for just one device. Without the try keyword, the DHCP configuration is assigned to all devices which match the device pattern. So, if you use:

ifcfg=eth*=try,dhcp

you’ll end up with one DHCP configured device (the one that has a working network connection). On the contrary, omitting the try option will configure via DHCP all the devices matching the given pattern.

You can use any of Linuxrc’s network-aware options as criteria for the try option (install, dud, info, and autoyast). However, you cannot explicitly determine which one will be used if more than one is given. It merely depends on which one is used first by Linuxrc.

Better Support for Auto-Configured Devices in S/390 Systems

A few weeks ago, we announced that we had extended Linuxrc and YaST to play nicely with the new I/O device auto-configuration mechanism on zSeries systems. After gathering some feedback from our S/390 experts, we did some adjustments to the current implementation.

On the one hand, the auto-configuration is now optional. Linuxrc offers a new DeviceAutoConfig that allows the user to indicate whether to apply the configuration. The possible values are 0 (no), 1 (yes) and 2 (ask). The last of those values is the default.

On the other hand, QA detected a problem when AutoYaST tried to configure a device that has been already configured. Apart from solving the issue, we invested some time doing cleaning-up part of the yast2-s390 module.

Improving YaST’s XML Parser

XML is an important language in the YaST world. The best example is the so-called control file, which defines many aspects of the installation process. You can check the control file for openSUSE if you are interested.

YaST implements its own XML parser which is adapted to our needs. For instance, it is able to understand an special config:type attribute which serves as a hint about to interpret the content of the XML tag. If you have used AutoYaST, you know what we are talking about.

<initialize config:type="boolean">true</initialize>

However, it has its own set of problems, especially when it comes to error reporting. For that reason, we have started a new initiative to improve our XML parser. There are some discussions which are taking place in the yast-devel mailing list (like YaST XML Parser and Yast XML parser and strictness). Feel free to join and share your point of view.

Conclusions

To plan for the future, the team has started to do some research about the current status of YaST modules and AutoYaST. You might already have read something about them if you are subscribed to the yast-devel mailing list. If you want to share your point of view, you are welcome to the discussion.

In any case, we plan to present our conclusions during the upcoming weeks. So stay safe and tunned!